== You should avoid using _socket.SOMAXCONN_

There you are, writing a socket-based server in Python,
and you've decided that you should heed [[my advice
../unix/ConcurrentConnectionLimits]] and make its _listen()_ backlog as
large as possible. So you write the following code:

.pn prewrap on
>  s = socket.socket(....)
>  s.bind(....)
>  s.list(socket.SOMAXCONN)

Given that _SOMAXCONN_ is the traditional BSD sockets API name for 'the
maximum value you can give _listen()_', this looks good and should do
what you want. Sadly it does not.

The problem is that _socket.SOMAXCONN_ is a constant. On many modern
systems, the system-wide maximum _listen()_ value is a kernel tuneable;
it can be adjusted up (or down). If it's adjusted down, there is no
problem with this code since the kernel will reduce the _listen()_
backlog value down to the system setting. But if the system limit has
been raised, the kernel does not adjust your _listen()_ backlog *up*
for you; it quietly stays at what you told the kernel. Which means that
if someone has adjusted the limit up on your system, your code is not
actually specifying a maximum backlog.

I can't blame Python for this one, because Unix doesn't actually expose
an API for finding out the maximum socket _listen()_ backlog that's
allowed. The best that the _socket_ module can do is set _SOMAXCONN_ to
some compile-time value, and in this case it's using the C-level API
_SOMAXCONN_ constant definition (which is usually 128).

So what should your code do? Since the kernel will quietly limit the
_listen()_ backlog to the system maximum for you, the obvious answer is
to specify a large number, or a very large number, or even an absurdly
large number. My tastes run to:

>  s.listen(max(1024, socket.SOMAXCONN))

This is a hack, of course, and you can argue that 1024 is not large
enough and so on (and also that being paranoid about _SOMAXCONN_ being
larger than 1024 is pointless, so I should take the _max()_ out). This
is just what I do.

You may even feel that a large _listen()_ backlog is pointless
because in reality clients will start timing out long before you can
service their requests. This is also a valid view. The whole area is
complicated. But I still think you should avoid using _socket.SOMAXCONN_
because it simply doesn't mean what people might think it means, not in
real life on real systems.