[erlang-questions] listen() backlog limited to 16 bits?

Matthias Lang matthias@REDACTED
Tue Apr 28 07:54:34 CEST 2009


On Monday, April 27, Matthew Dempsky wrote:

> My only point is that (AFAIK) the listen backlog doesn't directly
> affect the number of requests per second or the number of concurrent
> connections you can handle.  It's just the number of TCP connections
> that have completed the SYN/ACK handshake and not yet been accepted by
> user space, and I just wouldn't expect this number to get into the
> hundreds of thousands unless the system is heavily overloaded, and
> then it probably can't do anything useful with such a huge backlog
> anyway.

I had similar thoughts. I can imagine a short backlog limit, e.g. 5,
limiting throughput, but I can only think of contrived situations
where there'd be a difference between millions and thousands.

The OS backlog limit has increased in linux over the
years. Originally, it was five connections (BSDism?). Later
(2.0/2.2/2.4?), it increased to 128. In current Linux versions it's
configurable without an apparent upper limit; the default is 128.

Someone thought it was worth the effort to remove the limit. I googled
a bit and couldn't find the reasoning behind that.  Maybe it was a
"remove all arbitrary limits" mission.

Matt

 * I've tried writing higher values to somaxconn and reading them
   back again. It gets a bit weird for some values:

    contorpis:/proc/sys/net/core# echo "2147483648" > somaxconn 
    contorpis:/proc/sys/net/core# cat somaxconn 
    -18446744071562067968

   I also tried a C program with various backlog arguments.  It feels
   like something strange is going on, e.g. with a call to listen(s,
   1) and then sleep() forever, I can still connect several sockets,
   though it takes about a second per connection after the first
   few. I wasn't sufficiently interested to figure out why, but if
   someone knows, it'd be interesting to hear.



More information about the erlang-questions mailing list