Hello all, I work on a Linux application which does an extensive use of net-snmp to monitor and control a bunch of external equipments, all synchronised on a ptp or ntp clock. The "fun" part is that the clock is not always available, and that the system can be completely out of synch at startup (~1h early or late) and catch up later.
We have noticed that the application sometimes froze at this point, and investigating a little, I have found that the culprit was the use of timeval structures set by gettimeofday in snmp_sess_select_info (release 5.3.3) or snmp_sess_select_info2_flags (release 5.7.1), which provided wrong timeout values in this case (computing deltas with timeval structs obtained with gettimeofday before and after the time change). I understand that my case is quite specific, but as a suggestion, I would propose to use a really monotonic clock to compute the actual timeout, e.g. using clock_gettime with the CLOCK_MONOTONIC argument on Unix systems. Of course, in the end, it may not be as simple as it seems! How to reproduce: - Write a basic client sending requests in a loop - Change system time regularly (e.g. add or remove 10 minutes, I haven't bothered determining which way raised the issue) - Occasionnally, the client freezes for 10 minutes. Tested on RHEL 5.3 x64, with net-snmp 5.3.3 and 5.7.1. Tell me if you think I should file a bug report. Thanks in advance for your suggestions. Alban Rochel ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
