[e2e] tcp connection timeout

[Joe Touch]

rick jones wrote:
>> shutdown(SHUT_WR) isn't specified in the TCP API; I don't have the Linux
>> source code, but it should issue a CLOSE() call as well.
> 
> 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
'close'?)

>> 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 when
it interferes with a new connection. Cleaning up old state isn't part of
how TCP is designed.

>> That happens on the local end when an app tries to open a new connection
>> or send data on the old one; either return an error, at which point the
>> application can decide to issue an ABORT() so it can proceed with a new
>> connection. The same would occur when an application dies, i.e., when it
>> 'disconnects' from the socket, where the OS can issue an ABORT.
> 
> Perhaps it is implementation specific, but how about when another
> application, or instance of that application tries to start a listen
> endpoint.  I guess you would consider that a new connection being tried
> that collides?

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 SYN
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.

>> It happens on the remote end when the old connection tries to open a new
>> 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 cleanup.

>> 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 for
> 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' (OS,
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.

Joe