[e2e] tcp connection timeout
David P. Reed
dpreed at reed.com
Tue Mar 7 07:30:40 PST 2006
David Borman wrote:
>
> But it is valuable to know that the transport connection is down, and
> when the keepalive triggers a TCP RST, then it is providing a useful
> service. No sense in hanging onto the phone if the other side has
> hung up.
David - you obviously missed my note that started this part of the
discussion. TCP connections are NOT phone calls. They are NOT hung up
in that way (a CLOSE is sent as part of disconnection). They don't tie
up wires, they don't tie up routers, they don't tie up bandwidth.
Reasoning about phone calls adds nothing to this discussion. Might as
well think about the analogy to alligator wrestling for all that helps.
>
> Keepalives should be viewed as a way to determine if a connection is
> dead, not if it is alive. It's a subtle but important difference, and
> the main issue is when you get no response, does that indicate that
> the connection is dead? It seems to me that that is where most of the
> objections to keepalives come, where lack of response due to an outage
> kills a perfectly good idle connection.
>
Keepalives don't tell if a connection is dead. If their function is
definable at all, the precise definition is that: they tell you that a
particular internally generated packet is lost or misrouted at a
particular point in time, chosen without the control of the application
that cares, and they do more than that: they don't just tell you, they
KILL the connection, and you discover that later when you get around to
checking or try to send data, if you ever do. They work only when the
application itself is not sending data, which is most likely when the
application doesn't care (if it cared, it would either be sending data,
or doing its own polling of the responsiveness of the *application* at
the other end, which is all it cares about).
Sometimes it really helps to think, not about what something "says it
does", but actually what it does.
They also don't keep a connection alive! But that is a misnaming of
the function.
Can we stop this debate?
More information about the end2end-interest
mailing list