On Mon, 14 Sep 1998, Jonathan Stone wrote:

> 
> >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. 
> 
> 
> SOMAXCONN is 128 in 1.3.2, both in sys/socket.h and the manpage.  I
> haven't looked further back, but I think it was 128 in 1.3 as well,
> and it's still 128 in yesterday's source.
> 
> Could you please post your adjusted opinions, given that?

There is nothing wrong with the default, leave it at what it is.  On top
of that, adding a knob to tune woudl be good.

This does depend on what NetBSD has for SYN flood protection and if it is
counted in qlen+q0len or not.

> 
> 
> >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?
> 
> Purely to stop someone setting it to ULONG_MAX and opening themselves
> to the obvious memory-exhaustion attack.  If you don't think that's a
> problem, don't enforce the upper bound, or make SOMAXCONN configurable
> at config time (and set it to ULONG_MAX).

There has to be a default kernel limit on the backlog value.  128 is
reasonable for that.

On top of that, add the ability to dynamically resize it to an arbitrary
value.  I don't know how much that code path is optimized in NetBSD for
long q0len's, but if not then getting up to the 1024 area can have
definite bad O(n^2) or something similar effects that can cause problems.
Regardless, this is something that the admin can set so if they kill
themself that is their problem.

At this point, SOMAXCONN is used for nothing other than the default
setting of the sysctl value.

> Again, there're still boxes where 5 is a very workable limit.  (Proof

Yes, it works, but it is unnecessarily low.