>>>>> On Wed, 14 May 2008 15:03:37 +0200, Jan Safranek <[EMAIL PROTECTED]> said:
JS> net-snmp by default expects that send() on a socket always send whole JS> provided buffer and is blocking. This leads to deadlocks under heavy JS> load - see bug #1598344. Interesting findings and good work! My thoughts having just thought about it for a few minutes: 1) I think a session would have to be marked with a flag to allow it return it failed to send something. In particular I'm not sure it's safe to do by default and most applications won't hit this kind of snag. 2) I would be tempted to implemented it (if I were the one writing the code) to have an automatic queueing layer between the application and the transport it goes out on (if that flag was set). Rather than make the application handle the queue. (and then use snmp_alarm() to check the queue and attempt to transmit it if not-empty). That way a return code could indicate it really can't be sent not because the transport has an issue, but because the queue is now full. JS> - how many packets to store in the queue? I can't store everything JS> (possible DOS attack), should there be a new config option for this? Yes, I'd make it configurable but have a reasonable default. A default is hard to pick, so I'd lean toward smaller only because it is used on a number of embedded systems as well as larger systems. -- Wes Hardaker Sparta, Inc. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
