[e2e] tcp connection timeout
perfgeek at mac.com
Fri Mar 10 07:42:23 PST 2006
>> that basically says it won't be sending any more data but might be
>> receiving more data.
> Why isn't that a CLOSE()? (or is it a TCP CLOSE(), but not a socket
indeed, it is not a socket close(). the socket remains "open" but just
in simplex (receive only).
>>> The FIN_WAIT_2 results in kept state until a new connection is tried
>>> that collides.
>> That could be a very long time indeed.
> The point is that it doesn't matter. The state gets cleaned up ONLY
> it interferes with a new connection. Cleaning up old state isn't part
> how TCP is designed.
Is that why we had such "fun" with FIN_WAIT_2 and web servers?
> Starting a listen isn't a collision - it doesn't do anything at the TCP
> level. The collision happens only when the new connection is attempted,
> which, for that model, assumes the remote side sends the SYN. If the
> is from a different port, there's no interference and it proceeds as
> usual. It's only when the SYN received indicates the port from the old
> connection that the state gets cleaned up - or needs to.
Should the semantics of SO_REUSEADDR be the default then?
>>> It happens on the remote end when the old connection tries to open a
>>> connection, where at some point the other side sends a RST or a FIN.
>> Which may never happen when the remote simply goes poof.
> In which case there's nothing to interfere, and thus no reason to
_No_ reason? Admittedly, the TCP connection state doesn't have to be
particularly large, but there can be a particularly large number of
>>> I.e., overall, the APPLICATION on one side or the other has to decide
>>> what to do. This can be accomplished by a global OS parameter that
>>> effectively emulates the timeout for the application, but to TCP
>>> it's an
>>> application-layer decision.
>> Isn't that global OS parameter that effectively emulates the timeout
>> the application effectively a TCP keepalive?
> A keepalive would send TCP packets with no data, or - in the absence of
> such - decide to terminate the connection. Having the 'application'
> in this case, but as far as TCP is concerned, it's just anything above
> TCP) terminate the connection is the application's decision. It has
> nothing to do with TCP - or how much or little progress it is making.
So the receive-only side of a simplex TCP connection should have an an
application-level timeout that goes pop when no data has been received
from the remote side, since by definition it cannot send an
application-level keepalive yes? That TCP could send something to at
least reasonably guess if the remote is still there is a don't care.
there is no rest for the wicked, yet the virtuous have no pillows
More information about the end2end-interest