Charles-François Natali <neolo...@free.fr> added the comment: > To revive this issue, I tried to write a unit test to verify the behaviour. > Onfurtunately, the test doesn't work and I don't understand why. I hope, > someone here is more enlightend than me...
The semantic of listen's backlog argument has always been unclear, so different implementations apply some "fudge factor" to the value passed, see for example http://books.google.com/books?id=ptSC4LpwGA0C&lpg=PA108&ots=Kq9FQogkTr&dq=berkeley%20listen%20backlog%20ack&pg=PA108#v=onepage&q=berkeley listen backlog ack&f=false Most of the time, passing <backlog> means that the kernel will queue at least <backlog> requests. Under the kernel I'm using (2.6.32), the maximum number of queued requests is actually backlog + 1, and it seems to be the same on FreeBSD (I guess one of the reason is to cope with backlog == 0). Note that under Linux, there's another setting coming into play, net.ipv4.tcp_abort_on_overflow: """ If listening service is too slow to accept new connections, reset them. Not enabled by default. It means that if overflow occurred due to a burst, connection will recover. Enable this option only if you are really sure that listening daemon cannot be tuned to accept connections faster. Enabling this option can harm clients of your server. """ The goal is to avoid dropping connection requests because of a temporary burst. So if you change your script to make as many connections as possible with the default value, you'll probably be able to go well above listen's backlog. To deactivate it, you can use: # sysctl net.ipv4.tcp_abort_on_overflow=1 (But it's not a good idea in a production setting). As for the test, you should add it to Lib/test/test_socket.py (just creating a socket, binding it and passing a backlog of 0 should be more than enough). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8498> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
