p{padding:0;margin:0;} Hello, My Diameter peer sometimes complains about Diameter timeouts, which is 5 seconds. Debugging leads me to the interesting detail - Diameter messages sometimes are processing with delays in Radiator. For instance, Radiator's server Wireshark capture: No. Time Source Destination Protocol Length Info 231521 09:00:58.997242000 xxx.xxx.xx.xx xxx.xxx.xx.xx DIAMETER 1622 cmd=Accounting Request(271) flags=RP-- appl=Diameter Base Accounting(3) h2h=253e8654 e2e=253e8654 But in the Radiator this request appears 5.2 second later: Thu Mar 26 09:01:04 2015 029052: DEBUG: StateMachine::event event R-Rcv-Message R-Open -> R-Open Thu Mar 26 09:01:04 2015 029532: DEBUG: mm2.xxx.xxxx.ee DiaPeer::recv Thu Mar 26 09:01:04 2015 031768: DEBUG: mm2.xxx.xxxx.ee <- sgc2.xxx.xxxx.ee recv_v1msg: Code: 271 (Accounting) Version: 1 Flags: 0xc0 (RP) Application ID: 3 (Base Accounting) Hop-to-Hop ID: 624854612 End-to-End ID: 624854612
Despite the fact that further processing is very fast, the Diameter timeout has already expired and peer send retry request, which cause a duplicate records in the SQL. Used Radiator 4.14 version. Slackware 14.0 (3.2.45 #1 SMP x86_64 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz). My Diameter config: LogStdout LogDir /var/log/radiator DbDir /etc/radiator/raddb LogFile %L/logfile-fe-sbg-%Y%m LogMicroseconds Trace 3 FarmSize 30 AuthPort AcctPort DictionaryFile %D/dictionary DiameterDictionaryFile %D/diameter_attrs.dat <ServerDIAMETER> OriginHost mm2.xxx.xxxx.ee OriginRealm xxx.xxxxx.ee SupportedVendorIds DictVendors PostDiaToRadiusConversionHook file:"%D/dia_to_radius_hook_sbg.pl" </ServerDIAMETER> Normally there's no delays (Diameter service response time less than half of second), but 2-3 times per hour it can be 5-7seconds delay. Is it possible to explain why this happened and how to fix or at least debugging it? br, Arthur
_______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator