Weirdness with AF_INET listen() backlog [2.4.18]
Hello Alan (et al.),
Thanks for the quick replies.
Quoted 2 lines
Quoted 2 lines
I had expected that if a server creates a listening socket, but does not
accept()the incoming connections, then after the (possibly
fudge-factored)
Quoted 1 line
Quoted 1 line
Is this all expected behaviour? If so, is there a way of getting Linux
to
Quoted 1 line
Quoted 1 line
behave more like other implementations here? (As a wild shot I tried
setting
Quoted 5 lines
Quoted 2 lines
/proc/sys/net/ipv4/tcp_syncookiesto 0, but this made no apparent difference.)The world of tcp synflooding changed how stacks handle this sort of stuff forever. Welcome to the new world order 8)
Yes, I was gathering that it was synflooding that led to these changes.
Quoted 1 line
You will get connections completing, they will time out.
What causes the delay of a few seconds following each of the connect()s in excess of backlog?
Quoted 3 lines
If you expect
the server to say something you'll see the timeout there instead of seeing it on the connect.
Sorry, I don't quite understand this last sentence! Can you elaborate?
Quoted 2 lines
Since a timeout on the data can happen in the real world Im sure your code already correctly handles this case ;)
You mean on a send() or write(), right?
Cheers
Michael
Quoted 5 lines · Michael Kerrisk
Quoted 3 lines
If you expect
the server to say something you'll see the timeout there instead of seeing it on the connect.Sorry, I don't quite understand this last sentence! Can you elaborate?
If your client current does
connect
if timedout error
read
if timedout error
then it will fail on the read, and since the code should already handle that case will work out fine
Quoted 4 lines
Quoted 2 lines
Since a timeout on the data can happen in the real world Im sure your code already correctly handles this case ;)
You mean on a
send()orwrite(), right?
If the client writes first then it may well not fail until the read after the write