Re: connection failure after "tcp: remove max_qlen_log"
From: Kui Zhang
Date: Sun Jan 24 2016 - 05:18:50 EST
We licensed the java software. As far as I can tell, the connection is
for IPC with a child process. There should not be large RTT.
I will contact vendor regarding to listen(fd,0) issue, on Monday.
I am not fully convinced, that is the problem. I saw that man page for
listen. However accept() works, in python, with backlog = 0. The java
software works with kernel build one commit before.
strace for blocking:
listen(3, 0) = 0
accept(3, {sa_family=AF_INET, sin_port=htons(37562),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
sendto(4, "ping\n", 5, 0, NULL, 0) = 5
recvfrom(4, "sd\n", 100, 0, NULL, NULL) = 3
close(4) = 0
accept(3, {sa_family=AF_INET, sin_port=htons(37564),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
sendto(4, "ping\n", 5, 0, NULL, 0) = 5
recvfrom(4, "sd\n", 100, 0, NULL, NULL) = 3
close(4) = 0
accept(3, {sa_family=AF_INET, sin_port=htons(37572),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
sendto(4, "ping\n", 5, 0, NULL, 0) = 5
recvfrom(4, "bbb\n", 100, 0, NULL, NULL) = 4
close(4) = 0
accept(3, {sa_family=AF_INET, sin_port=htons(37574),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
sendto(4, "ping\n", 5, 0, NULL, 0) = 5
recvfrom(4, "aaa\n", 100, 0, NULL, NULL) = 4
close(4) = 0
accept(3, {sa_family=AF_INET, sin_port=htons(37636),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
sendto(4, "ping\n", 5, 0, NULL, 0) = 5
recvfrom(4, "s\n", 100, 0, NULL, NULL) = 2
close(4) = 0
accept(3, {sa_family=AF_INET, sin_port=htons(37638),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
sendto(4, "ping\n", 5, 0, NULL, 0) = 5
recvfrom(4, "\n\n\n", 100, 0, NULL, NULL) = 3
close(4) = 0
strace for non-blocking:
5539 listen(3, 0) = 0
5539 select(4, [3], [], [3], {30, 0}) = 0 (Timeout)
5539 select(4, [3], [], [3], {30, 0}) = 1 (in [3], left {16, 316258})
5539 accept(3, {sa_family=AF_INET, sin_port=htons(50364),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
5539 fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
5539 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
5539 getpeername(4, {sa_family=AF_INET, sin_port=htons(50364),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
5539 select(5, [3 4], [], [3 4], {30, 0}) = 1 (in [3], left {27, 898930})
5539 accept(3, {sa_family=AF_INET, sin_port=htons(50366),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
5539 fcntl(5, F_GETFL) = 0x2 (flags O_RDWR)
5539 fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
5539 getpeername(5, {sa_family=AF_INET, sin_port=htons(50366),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
5539 select(6, [3 4 5], [], [3 4 5], {30, 0}) = 1 (in [3], left {27, 455817})
5539 accept(3, {sa_family=AF_INET, sin_port=htons(50368),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 6
5539 fcntl(6, F_GETFL) = 0x2 (flags O_RDWR)
5539 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
5539 getpeername(6, {sa_family=AF_INET, sin_port=htons(50368),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
5539 select(7, [3 4 5 6], [], [3 4 5 6], {30, 0}) = 1 (in [6], left
{15, 227130})
5539 recvfrom(6, "a1111\n", 1024, 0, NULL, NULL) = 6
5539 select(7, [3 4 5 6], [6], [3 4 5 6], {30, 0}) = 1 (out [6], left
{29, 999984})
5539 sendto(6, "a1111\n", 6, 0, NULL, 0) = 6
5539 select(7, [3 4 5 6], [], [3 4 5 6], {30, 0}) = 1 (in [5], left
{28, 150454})
5539 recvfrom(5, "b11111\n", 1024, 0, NULL, NULL) = 7
5539 select(7, [3 4 5 6], [5], [3 4 5 6], {30, 0}) = 1 (out [5], left
{29, 999997})
5539 sendto(5, "b11111\n", 7, 0, NULL, 0) = 7
5539 select(7, [3 4 5 6], [], [3 4 5 6], {30, 0}) = 1 (in [4], left
{28, 459804})
5539 recvfrom(4, "c11111\n", 1024, 0, NULL, NULL) = 7
5539 select(7, [3 4 5 6], [4], [3 4 5 6], {30, 0}) = 1 (out [4], left
{29, 999996})
5539 sendto(4, "c11111\n", 7, 0, NULL, 0) = 7
What am i missing ?
thanks
On Sat, Jan 23, 2016 at 6:45 PM, Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
> On Sat, Jan 23, 2016 at 6:08 PM, Kui Zhang <kuizhang@xxxxxxxxx> wrote:
>> Per man page, listen(fd, 0) is valid.
>>
>> A backlog argument of 0 may allow the socket to accept
>> connections, in which case the length of the listen queue may be set
>> to an implementation-defined minimum value.
>>
>> http://pubs.opengroup.org/onlinepubs/009695399/functions/listen.html
>>
>
> It is perfectly valid, as you pointed out, to set the implementation
> defined minimum to 0.
>
> Since you do not want to depend on some magic number, just set the
> backlog to 1, or even better 1000
>
>
>
> Linux man page :
>
>
> int listen(int sockfd, int backlog);
>
> DESCRIPTION
> listen() marks the socket referred to by sockfd as a passive
> socket, that is, as a socket that will be used
> to accept incoming connection requests using accept(2).
>
> The sockfd argument is a file descriptor that refers to a
> socket of type SOCK_STREAM or SOCK_SEQPACKET.
>
> The backlog argument defines the maximum length to which the
> queue of pending connections for sockfd may
> grow. If a connection request arrives when the queue is
> full, the client may receive an error with an
> indication of ECONNREFUSED or, if the underlying protocol
> supports retransmission, the request may be
> ignored so that a later reattempt at connection succeeds.
>
> maximum length = 0
>
> For the second problem it was already fixed.
>
> commit acb4a6bfc80ddeea4c44074dd630f916259e909e
> Author: Eric Dumazet <edumazet@xxxxxxxxxx>
> Date: Tue Oct 6 14:49:58 2015 -0700
>
> tcp: ensure prior synack rtx behavior with small backlogs
>
> Some applications use a listen() backlog of 1.
> -----------------------------------------------------------------------------------------------
>
>
> Setting the backlog to 0 is a way to not accept connections, while
> still keeping the port bound.
>
> A listener is now able to temporarily not accept new flows.
>
>
> If you want to accept connections, just set the backlog to something reasonable.
>
> As a bonus, your daemon will not reject a connection attempt just
> because few SYN_RECV sockets are waiting for the 3rd packet of 3WHS,
> when dealing with large RTT.