Date:	Fri, 19 Oct 2012 08:50:13 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Vijay Subramanian <subramanian.vijay@...il.com>
Cc:	enh <enh@...gle.com>,
	Venkat Venkatsubra <venkat.x.venkatsubra@...cle.com>,
	netdev@...r.kernel.org
Subject: Re: listen(2) backlog changes in or around Linux 3.1?

On Thu, 2012-10-18 at 23:02 -0700, Vijay Subramanian wrote:
> >> They all remain on ESTABLISHED state on the client side.
> >
> > yeah, that's what i see with netstat -t too.
> >
> 
> > (https://android-review.googlesource.com/#/c/44563/), but i'd love to
> > at least understand what's going on here, even if it's just that i
> > have a fundamental misunderstanding of what the listen backlog is
> > supposed to mean.
> >
> 
> The listen backlog represents the number of received SYNs that have
> not been processed i.e. for which a SYN-ACK has not been sent.
> Actually, the number of SYNs
> that can be pending for processing is actually backlog+1. With a
> backlog of 1, there can be 2 SYNs that can be pending for processing.
> 
> Once a SYN is processed by the server socket (in LISTEN state) and a
> syn-ack is sent back, a request_sock is created to represent it. Once
> the client replies with the last step of connect() i.e. with  an ack,
> a fully established socket is created. The number of queued
> request-socks for a LISTEN socket can be much more than the backlog
> limit given in listen() (which is 1 in your case). If after a short
> period (after SYNACK_RETRIES), the three way handshake is not
> completed, request_socks can be silently discarded.
> 
> When a SYN is received, it is processed by   tcp_v4_conn_request()
> where we have..
> if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)
>  got drop;
> 
> So, for the SYN to be dropped, backlog limit must be exceeded _and_ we
> must have recently accepted another SYN request. So, even when backlog
> limit is exceeded, SYNs are processed and syn-acks are sent back. It
> seems that the listen backlog limit is applied definitively only in
> the third step in tcp_v4_syn_recv_sock() and not in the first step.
> In  tcp_v4_syn_recv_sock(), we have
>  if (sk_acceptq_is_full(sk))
>                 goto exit_overflow;
> 
> This prevents the socket from being created fully. On the client side
> however, since the three way handshake has finished, the socket goes
> into ESTABLISHED state which is what you see with netstat. In your
> test case, typically 2 connections are in state where SYN has to be
> processed  and rest are as request_sock where synacks have been sent.
> However,
> they may not become fully created sockets as they will fail in step 3
> as described above.
> 
> man listen() says
> " The  backlog  argument  defines  the maximum length to which the
> queue of pending connections for sockfd may grow. " In your case where
> backlog is 1, there can be a max of 2 pending connections (SYNs not
> yet processed) and this is what we see. By this interpretation,
> behavior seems correct.
> 
> Not sure if this behavior is a bug but the processing in
> tcp_v4_conn_request()  does look suspicious. Should we terminate
> earlier without doing three way hand shake?
> Perhaps someone who knows this better can clarify.
> 
> Hope this helps.
> Vijay

I came to the same analysis than you.

Current behavior is stupid, because the traffic for such 'sockets' is
insane :

As we sent a SYNACK, client sends the 3rd packet (ACK), and we ignore
it.

Then we keep retransmitting SYNACKS....

Oh well.

21:38:27.459937 IP glaptop.53627 > 172.30.42.23.9877: Flags [S], seq
1124582230, win 14600, options [mss 1460,sackOK,TS val 84038374 ecr
0,nop,wscale 7], length 0
21:38:27.460007 IP 172.30.42.23.9877 > glaptop.53627: Flags [S.], seq
1077519728, ack 1124582231, win 14480, options [mss 1460,sackOK,TS val
4230664 ecr 84038374,nop,wscale 7], length 0
21:38:27.460235 IP glaptop.53627 > 172.30.42.23.9877: Flags [.], ack 1,
win 115, options [nop,nop,TS val 84038374 ecr 4230664], length 0

21:38:28.661139 IP 172.30.42.23.9877 > glaptop.53627: Flags [S.], seq
1077519728, ack 1124582231, win 14480, options [mss 1460,sackOK,TS val
4231866 ecr 84038374,nop,wscale 7], length 0
21:38:28.661428 IP glaptop.53627 > 172.30.42.23.9877: Flags [.], ack 1,
win 115, options [nop,nop,TS val 84038494 ecr 4231866,nop,nop,sack 1
{0:1}], length 0
21:38:30.661138 IP 172.30.42.23.9877 > glaptop.53627: Flags [S.], seq
1077519728, ack 1124582231, win 14480, options [mss 1460,sackOK,TS val
4233866 ecr 84038494,nop,wscale 7], length 0
21:38:30.661412 IP glaptop.53627 > 172.30.42.23.9877: Flags [.], ack 1,
win 115, options [nop,nop,TS val 84038694 ecr 4233866,nop,nop,sack 1
{0:1}], length 0
21:38:35.061135 IP 172.30.42.23.9877 > glaptop.53627: Flags [S.], seq
1077519728, ack 1124582231, win 14480, options [mss 1460,sackOK,TS val
4238266 ecr 84038694,nop,wscale 7], length 0
21:38:35.061413 IP glaptop.53627 > 172.30.42.23.9877: Flags [.], ack 1,
win 115, options [nop,nop,TS val 84039134 ecr 4238266,nop,nop,sack 1
{0:1}], length 0
21:38:43.061118 IP 172.30.42.23.9877 > glaptop.53627: Flags [S.], seq
1077519728, ack 1124582231, win 14480, options [mss 1460,sackOK,TS val
4246266 ecr 84039134,nop,wscale 7], length 0
21:38:43.061357 IP glaptop.53627 > 172.30.42.23.9877: Flags [.], ack 1,
win 115, options [nop,nop,TS val 84039934 ecr 4246266,nop,nop,sack 1
{0:1}], length 0
21:38:59.061135 IP 172.30.42.23.9877 > glaptop.53627: Flags [S.], seq
1077519728, ack 1124582231, win 14480, options [mss 1460,sackOK,TS val
4262266 ecr 84039934,nop,wscale 7], length 0
21:38:59.061434 IP glaptop.53627 > 172.30.42.23.9877: Flags [.], ack 1,
win 115, options [nop,nop,TS val 84041534 ecr 4262266,nop,nop,sack 1
{0:1}], length 0


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists