The recent addition only allows tweaking of the UDP buffers. First a note on why I "forgot" about TCP On the TCP side I looked at the code and saw the return code of the send is intercepted. Therefore I made the (wrong) assumption that this return code would be interpreted appropriately and an failed PDU would be resend, instead of freed, as I think it is right now :-(. Haven't looked at the required changes for fixing this on TCP level too, but if guaranteed delivery (to the socket layer) is needed for TCP, probably an internal buffer should be kept and the sender should maintain it's registration in the select() loop until the packet has been delivered. (I have to admit have probably not spend enough time in that piece of code to make more assumptions here). So for TCP buffers I have concerns if "we" should tune those on the OS level like we do with UDP (yes, with UDP there is no other alternative).
This patch to allow UDP buffer tuning was written because it was assumed a 1<<17K buf is good enough for everyone. Sadly enough it sometimes isn't and there was no way to change this 1<<17K hardcoded limit (besides changing the code). The new default behaves "exactly" how it used to be. This means you will normally end up with a 128K receive and send buffer (yes, normally, because the tuning parameters in the OS have to allow this size). I'm in favour of not changing default behavior unless there is a reason for it, but have to agree that this might be a bit excessive for most get/set operations. As you said, the SNMP_MAX_PDU_SIZE size is 64K, that means that every application that does a synchronous network call (as far as I can see this is every snmp client application) will not need more than 64K (ever). Therefore the default send and receive buffer should be 64K for client apps using synch network calls. For server applications I would keep the default SNMP_MAX_PDU_SIZE * 2 but recommend higher values (if memory is not an issue). The patch allows everyone to tune their send and receive buffers anyway. If people are really short on memory then they can even change the buffer below SNMP_MAX_PDU_SIZE. So my recommendation is. 1) use SNMP_MAX_PDU_SIZE for send/receive buffers of client apps 2) use SNMP_MAX_PDU_SIZE * 2 for send/receive buffers of server apps This would save you some memory on the client apps (while still staying in the safe range). On the server side I wouldn't change anything by default. High volume trap receivers should be aware of potential buffer overflow issues and should tune their buffers accordingly to minimize loss (SNMP_MAX_PDU_SIZE * 16 for example, which is close to the default Sun suggests for their high performance networking - HPPI/P) ... I'm sure one size won't fit all in this area. Cheers, -- Geert -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Story (Coders) Sent: Sunday, October 03, 2004 3:33 AM To: [EMAIL PROTECTED]; John Naylon Subject: default sock buffer size: what should it be? With the recent addition of the ability to set the buffers size for UDP and TCP sockets in 5.2, it seems like a good time to revisit the question of what the default value should be. The current behavior is to set them to 128k, which seems rather large. The rational, from the CVS log message: - set SO_SNDBUF and SO_RCVBUF to 128Kb for newly-opened UDP sockets, to enable large PDUs to be sent and received. Some implementations default very low (Solaris 2.7 8Kb, Linux 2.4 64Kb). The other important bit of information about socket size is that if affects the number of packets that can be received while a process is busy. The original author of the patch to allow increased buffers sizes was motivated by the fact that his snmptrapd was losing packets due to an insufficient receive buffer. The new patch allows on to set independent buffer sizes for client vs server, and send vs receive. Given that SNMP_MAX_PDU_SIZE is less than 64k, a default buffer size of 128k seems excessive. I suggest that: 1) snmpd and snmptraps both set the default receive buffers size to at least 128k, if not more, to minimize the changes of missing packets. 2) if no buffer size is specified, that the default be to use the default size specified by the OS. I'm guessing that the average PDU is pretty small (<1k), so the OS defaults are probably very safe. Thoughts, opinions and arguments welcomed. -- Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
