[e2e] tcp connection timeout
david.borman at windriver.com
Fri Mar 3 14:29:04 PST 2006
On Mar 3, 2006, at 2:46 PM, Joe Touch wrote:
> Vadim Antonov wrote:
>> On Fri, 3 Mar 2006, Joe Touch wrote:
>> It does not matter whose decision it is as long as you have a way of
>> purging it for dead connections. It was merely a counter-argument
>> to the
>> assertion that dead connections are "cheap". There are numerous
>> cases when
>> they are not.
> We HAVE a way for applications to purge resources for connections THEY
> think are dead - CLOSE or ABORT.
Well, of course. But that isn't the issue, the issue is how do they
decide that the connection is dead? Keep-alives are one mechanism.
>> I think it is always a good idea to look at the whole picture,
>> concentrating on one layer is bound to mislead.
> Indeed - I (and others) are suggesting TCP isn't the place to focus in
> this case.
TCP doesn't provide a mechanism for the application to probe to see
if the other side of the connection is still alive, other than by
actually sending data and waiting for the connection to time out due
to retransmissions, or read the connection for a response that never
Whatever the mechanism, there are 3 responses you can get: an ack
(not just a TCP ACK), and you know the connection is still alive; a
TCP RST and you know the connection has gone away, or nothing, and
you have to decide how to deal with that. It is dropping the
connection in the third case that causes angst, when the lack of
response is due to an outage in the network, not due to the other
side having gone away. But that has to be dealt with no matter how
you do the test for connectivity, be it a keep-alive, or a Telnet AYT
command, or whatever. Once the application actually tries to send
data, most TCPs will eventually time out the connection if no
response is received, so an application level probe during an outage
will probably result in the connection being dropped, just like lack
of response to the keep-alives.
Keep-alives provide a specific test for liveliness, and if that works
for the server application, then use it. If it doesn't, then don't.
RFC 1122 addressed the more egregious issues with keep-alives, by
saying that they are off by default, you have to wait at least 2
hours before sending them, and that lack of response from any single
keep-alive is not enough of a reason to drop the connection.
More information about the end2end-interest