Hi - I've been working with some tcp network test programs that 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 unless its loopback on the Linux server. This issue crops up both on 2.4 and 2.6 kernels; the main feature seen in tcp dumps is that the server gets inundated with retrys, and then starts sending RST responses to everything (labelled as ZeroWindow in a Ethereal dump). One interesting feature is that many clients thinks the 3-way connection handshake 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. Another interesting feature is a group of retries from various client ports, followed by a group of ACK,RST responses from the server, followed by the ZeroWindow RST to everything. On Linux, the only way to succeed is to use remote clients - thus avoiding extra work on the server -and changing test parameters to put in a longer server delay, which is inserted between the closing of one connection and the opening of the next. I'm assuming that the tcp network queues are just getting overloaded with the data retransmissions, but I don't know enough about the queue management yet. Any suggestions/pointers/fixes? Regards - Tom McNeal Former NFS dude, current Kernel Support dude -- Tom McNeal (650)906-0761(cell) (650)964-8459(fax) Email: trmcneal@xxxxxxxxxxx - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
