Technically I agree with leaving the UDP buffers alone (unless they are explicitly set in the configuration) like you suggest. However, the consequences will be that more traps will get lost and bigger packets might not make it when people upgrade to version 5.2, just because their OS default happens to be smaller than our originally hardcoded 128K.
Not a problem for me at all, but definitely not easy to debug as an enduser why traps are lost "with this new version". What is the "upgrade/backward compatibility" strategy for the net-snmp project ? If such a change in operational behaviour is acceptable, then I'm all for it. -- Geert -----Original Message----- From: Robert Story (Coders) [mailto:[EMAIL PROTECTED] Sent: Sunday, October 03, 2004 4:21 PM To: Geert De Peuter Cc: [EMAIL PROTECTED]; 'Geert De Peuter'; 'John Naylon' Subject: Re: default sock buffer size: what should it be? On Sun, 3 Oct 2004 10:07:25 +0200 Geert wrote: GDP> In case someone has a default socket buffer size which is greater GDP> than our default (currently 128K) then we should probably respect GDP> that. I think this is another good argument for leaving the OS default alone, unless a buffer size is explicitly set in the conf files (or at application startup). GDP> This leaves an OS buffer which is bigger than the DEFAULT_BUFFER GDP> untouched. Except that it is conceivable that and application actually wants a smaller buffer size that the default. -- 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
