On Mon, 14 Sep 1998, Jonathan Stone wrote:

> >If it has listening sockets, it is a server.
> 
> No, it means it's running some server processes. Doesn't make the
> machine a "server" by any stretch of the imagination.
> 
> Unless you call diskless machines that're running inetd servers? :).

Yes.  

> [...]
> 
> >I understand what you are proposing, and it of course makes sense.
> >However, I am amazed that anyone can think it reasonable to have a default
> >of 5.  I also don't see the point of making it tunable but still having a
> >default hard limit as low as 32.
> 
> I'm totally confused.  The _default_ hard limit, SOMAXCONN, is
> currently 128, and has been since at least 1.3.2.  Even the old SunOS
> 4.1.[34] boxes I still have access to are still running quite happily
> with an SOMAXCONN hard limit on queuelength of 5. So I'd guess that 32
> is a very generous value for many people.

I am going on what Todd said; ie. that SOMAXCONN is set to 5 in
sys/socket.h; I don't use or track NetBSD very closely.  His proposal was
to set it to 32 as a hard max, and default to 5.  That is just silly, as
it would be silly if SOMAXCONN was 5 today.

Apparently, what he said is not correct so any comments I made based on
that have to be adjusted accordingly.  Unfortunately, I can't find any way
to verify this since it doesn't appear that the CVS tree is publicly
available in any way that I can find.

> I have to admit I dont understand the idea of 32 as a default; i'd use
> the compile-time value of SOMAXCONN as an upper bound on the hard
> limit, and use a sysctl to tweak the limit used in uipc_socket.c
> between 1 and SOMAXCONN.  Net overhead, one variable reference instead
> of a manifest constant, plus another sysctl mib number.

That doesn't make much sense.  Why not just have SOMAXCONN set the default
limit (and tell people there is no point in changing SOMAXCONN), then have
the sysctl adjust it to whatever you want?  Where is the need for the
hardcoded limit at all?