Hi - After looking at the problem of encountering server RST replies to all requests during some TCP stress tests, the key feature for the server was indeed the multiple SYN+ACK retries preceding the server defaulting to RSTs for all requests. Note that I mentioned this: >> 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. I was able to make the server pass the tests (100K connections & writes & disconnects in a loop, using 2 clients) by cutting back the number of synack retries from the default of 5, using sysctl: sysctl -w net.ipv4.tcp_synack_retries="3" This works fine when testing with remote clients, but not with loopback clients; I think the extra load plus the smaller network delays may cause issues. My question is, what resource is getting exhausted? Since the connection has not been established, its not socket buffers, but there must be some lower level IP buffers that are getting exhausted by all the incoming writes and write retries from the client who thinks a connection has been made. Any suggestions about where to look? Tom -- Tom McNeal (650)906-0761(cell) (650)964-8459(fax) - : 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
