On Mon, 04 Sep 2006 11:06:51 -0400 Sten wrote:
OS> This all happens because the first event (that runs run_alarms() and
OS> agentx ping) calls send(), select(), and recv() all in the same function
OS> call (agentx_synch_response()).
OS>
OS> It seems to me that it shouldn't be calling select() or recv(). I
OS> realize it was designed to do this, but it seems wrong to do this. The
OS> send() would be OK, but then the code should wait for until the FD
OS> manager (which may be the user's application) select()s "read" to
OS> process the response to the send().

I agree. I'm sure the use of synch_response is just because that's how it was
originally written.

I can envision 2 possible fixes for this.. 'the right way', which would be
making the changes you described for asynchronous operation. 'the easy way'
would be to add a non-blocking select on the agentx fd before the synchronous
send, sidestepping the issue.

Another idea would be to change the way the ping interval works. I think it is
a fixed interval, and changing it to reset the timer whenever there is any
agentx traffic would reduce the window of opportunity for this bug to occur.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=...057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders