Subject: Re: New sysctl "net.listen_backlog"?
To: Todd Vierling <tv@pobox.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-net
Date: 09/14/1998 17:26:43
I think we're down to arguing over the defaults.  By the time I finish
writing this it's probably redundant, but I'd go for:

   *  a default  SOMAXCONN of 128 or more;
   *  document the  knob in the listen(2) manpage where it's
	currently a constant;
   *  add an rc.conf variable and rc machinery to set
      the knob via sysctl;
   * perhaps make the upper limit tunable (add #ifndef/#endif in socket.h)


A big server presumably has the oopmf to recompile quickly.  The admin
would probably configure a custom kernel anyway, to tailor kernel VA
space, buffers and whatnot.  So tailoring the limit for
small-to-medium boxes seems not-unreasonable.

I think Todd's point is that many netBSD boxes are from the same
hardware generation where 5 was an adequate value for SOMAXCONN, and
for those boxes, 128 is Too Big, and 32 may be better.  Todd is
worrying about is someone sending a "fork bomb" to a daemon by opening
full-fledged connections[*] at a higher rate than, say, an 11/750 or a
16Mhz i386 can fork() off children.  So Todd wants the default value
enforced by listen(2) to be conservative to prevent DoS attacks.

I sorta buy that, _if_ anyone has acutally seen this causing thrashing
and DoS.

The other problem is that if the compile-time SOMAXCONN is too low,
you need to recompile all your apps to get its listen(2) calls to ask
for more than the default SOMAXCONN (i.e., 128 now).  So we don't want
the value of SOMAXCONN in sys/socket.h to be too low, or too many
people end up recompiling everything.  If Todd really has a case where
128 is too small, this may be a good time to bump SOMAXCONN to 256.

But then we'd want another option to set the boot-time default used by
listen(2) back to no more than 128. Sigh.


[*] NetBSD uses a descendant of Dave Borman's SYN-attack code,
reworked by Jason Thorpe. The "tcb"s for connections that havent
finished the 3-way handshake are in a separate queue of half-open
connections where the state is compressed. From memory, those aren't
counted in qlen+q0len, for the obvbious reasons.