You should avoid using
There you are, writing a socket-based server in Python,
and you've decided that you should heed my advice and make its
listen() backlog as
large as possible. So you write the following code:
s = socket.socket(....) s.bind(....) s.list(socket.SOMAXCONN)
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
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
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:
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
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
because it simply doesn't mean what people might think it means, not in
real life on real systems.
Comments on this page:Written on 24 February 2013.