Linux (2.4.18) places incoming connection requests into the syn_recd state
when the server's backlog queue is full. I thought they were supposed to be
discarded if the server's backlog is full, forcing the client to
subsequently retransmit the request after it times out. Why does linux put
the server side into the syn_recd state when its backlog is full?
Do you have tcp_syncookies on? And are you exceeding
the len as configured by tcp_max_syn_backlog?
thanks,
Nivedita
[Please cc or post to netdev, like most networking folk,
dont subscribe to lkml]
From: Paul Albrecht <hidden> Date: 2003-07-06 22:01:06
Nivedita writes:
Do you have tcp_syncookies on?
syncookies = 0.
And are you exceeding the len as configured by tcp_max_syn_backlog?
max_syn_backlog = 256.
My server program sets its backlog to one and pauses ninety seconds before
accepting connections. Within that ninety second interval, I start three
client programs that do an active open to my server. I expect one of
connections to get discarded when the server's connection backlog limit is
exceeded.
My server program sets its backlog to one and pauses ninety seconds before
accepting connections. Within that ninety second interval, I start three
client programs that do an active open to my server. I expect one of
connections to get discarded when the server's connection backlog limit is
exceeded.
We actually have two queues - the syn queue and the socket
acccept queue. We move the connection request from the syn
queue to the accept queue of the socket once the 3 way
handshake is complete - i.e. once the state is ESTABLISHED.
If the syn queue is full, requests will get dropped and
the socket will not change state.
When you set a the backlog to 1 in the listen call, what is
being capped is the accept queue. So I would expect your
server to allow only one of those requests in the accept
queue, and the kernel will drop the other two requests.
Actually, details, but we also apply some other conditions
before we actually drop the connection request - we try not to be
so harsh if the syn queue is still fairly empty..
Think thats so, at any rate :).
Nivedita
From: Paul Albrecht <hidden> Date: 2003-07-07 04:09:28
Nivedita Singhvi writes:
When you set a the backlog to 1 in the listen call, what is
being capped is the accept queue. So I would expect your
server to allow only one of those requests in the accept
queue, and the kernel will drop the other two requests.
What you get when you set backlog to one is operating system dependent.
Tracing the flows with tcpdump, I get two clean handshakes so presumeably,
for linux, one means two. The third connection request *isn't* dropped;
according to netstat, it's placed in the syn_recd state. I thought
berkeley-derived implementations followed the rule that if there is no room
on the backlog queue for the new connection, tcp ignored the the received
syn.
Actually, details, but we also apply some other conditions
before we actually drop the connection request - we try not to be
so harsh if the syn queue is still fairly empty..
Irrespective of whatever conditions linux applies, how can the connection
enter the syn_recd state if the backlog limit would be exceeded? What's the
client supposed to do with the syn/ack from the server? What's the server
supposed to do with the ack it get's back from the client?
When you set a the backlog to 1 in the listen call, what is
being capped is the accept queue. So I would expect your
server to allow only one of those requests in the accept
queue, and the kernel will drop the other two requests.
What you get when you set backlog to one is operating system dependent.
You asked about Linux 2.4.18, and I was speaking
strictly for it. This is after all linux-netdev :).
Tracing the flows with tcpdump, I get two clean handshakes so presumeably,
for linux, one means two. The third connection request *isn't* dropped;
Again, youre limiting the number of connnection requests
that are allowed to wait in the *accept* queue, where
we move to once we're ESTABLISHED. You arent limiting
a request sitting in the SYN queue.
according to netstat, it's placed in the syn_recd state. I thought
berkeley-derived implementations followed the rule that if there is no room
on the backlog queue for the new connection, tcp ignored the the received
syn.
quoted
Actually, details, but we also apply some other conditions
before we actually drop the connection request - we try not to be
so harsh if the syn queue is still fairly empty..
Irrespective of whatever conditions linux applies, how can the connection
enter the syn_recd state if the backlog limit would be exceeded? What's the
client supposed to do with the syn/ack from the server? What's the server
supposed to do with the ack it get's back from the client?
Er, complete the 3 way handshake? If the client gets the syn/ack, it
should send a SYN in response, and move to ESTABLISHED state. If the
server gets an ack back from the client, we process the ack. Our
processing involves moving the request from the syn queue to the
accept queue. Should the accept queue be full (which could occur
anytime - eg it could have occurred *after* the server recvd this
SYN) we would drop the request. Should the client then send data,
it would get a RST, letting it know our side (srvr) has had to
throw the connection away. Its quite possible that the accept queue
clears and a request can be moved from the SYN queue to the
accept queue in the interval of the handshake being completed (?)
If we get a SYN, it doesn't seem unreasonable that we enter
SYN_RCVD state :).
thanks,
Nivedita
From: Paul Albrecht <hidden> Date: 2003-07-07 21:19:36
Nivedita Singhvi writes:
Again, youre limiting the number of connnection requests
that are allowed to wait in the *accept* queue, where
we move to once we're ESTABLISHED. You arent limiting
a request sitting in the SYN queue.
This statement is inconsistent with the description of this scenario in
Steven's TCP/IP Illustrated. Specifically, continuing the handshake in the
TCP layer, i.e., sending a syn/ack and moving to the syn_recd state, is
incorrect if the limit of the server's socket backlog would be exceeded.
How do you account for this discrepancy between linux and other
berkeley-derived implementations?