On ons, 2008-05-14 at 15:03 +0200, Jan Safranek wrote: > 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.
Do the rewrite affect both stream and packet sockets or only stream sockets? > 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)? What action should be taken if the remote party fails to read and to respond? Is this when OP_SEND_FAILED is called? > Comments? Thoughts? Could you please show us what you have got? /MF ------------------------------------------------------------------------- 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
