Hi, net-snmp by default expects that send() on a socket always send whole provided buffer and is blocking. This leads to deadlocks under heavy load - see bug #1598344.
I'm rewriting the snmp_api so the write will be asynchronous and non-blocking. It seems to me that the session API is somehow prepared - it allows to call a session or request callback with NETSNMP_CALLBACK_OP_SEND_FAILED. Question is, if the API users are prepared too - nobody has ever called the callback with this operation. My first tests show, that at least snmpd can live it. My prototype implementation stores all outgoing packets in a queue and writes them to a socket only if the socket is writeable. This leads to some design decissions: - how many packets to store in the queue? I can't store everything (possible DOS attack), should there be a new config option for this? - how long wait for the socket to get writable? My implementation starts the retransmission timer when packet is fully written to the socket, so it's not influenced by possible delay, but I think I still need a timer so the queue does not wait forever if the remote party does not read from its socket. What about another config. parameter? Or can I derive the timeout from session->timeout/request->timeout (timespan between retransmission)? Comments? Thoughts? Jan ------------------------------------------------------------------------- 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 Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
