TCP connection timeouts during testing

[trmcneal@comcast.net]

Hi -

I sent this out on the linux-net mailing list, but got no response at all,
so I'm going to try linux-kern.  This problem happens with both 2.4 and
2.6 kernels, using a variety of platforms and NICs.

Anyway, I've been working with some TCP networking tests which have
multiple clients opening nonblocking sockets to a single server port,
sending a short message, and then closing the socket, 100,000 times.
Since the socket is non-blocking, it generally tries to connect and then
does a poll since the socket is busy.  The test fails if the poll times out in
10 seconds.  It fails consistently on Linux servers but succeeds on Solaris
servers; the client is a non-issue.

The tcpdumps I've seen show that the server is getting a lot of retries,
largely because  many clients think the 3-way TCP connection handshake
(SYN from the client, SYN/ACK from the server, ACK from the client)
is complete, when the server actually doesn't get the final ACK; The client 
starts sending and then retransmitting the data, and the server keeps sending
back the SYN/ACK part of the handshake, whereupon the client resends
the ACK (which the server doesn't get), and starts sending and resending
the data again.

Eventually the server starts sending RST to everything and stops listening;
I've been able to make the test pass by bringing down the total number of
synack retries (sysctl -w net.ipv4.tcp_synack_retries="3"), but that doesn't
help much in the test, since the connection doesn't get made, and the data
isn't sent, causing a data confirmation failure rather than a timeout failure.

Any suggestions about what to do?  I tried increasing  the 
net.ipv4.tcp_max_syn_backlog value, but it didn't help.  I thought I saw
that RST getting generated when I ran out of some resource, but I'm looking
at the code again and am not sure what I saw before.  

Tom McNeal

--
Tom McNeal
(650)906-0761(cell)
(650)964-8459(fax)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/