[e2e] tcp connection timeout

[Joe Touch]

rick jones wrote:
> How, if at all, might the TCP FIN_WAIT_2 state fit into all of this? 
> Either in the "detached" case of the application having called close(),
> or in the simplex case of the application having called shutdown(SHUT_WR)?

FIN_WAIT_2 should happen only after a CLOSE() call is issued, that side
sends a FIN, and then that side receives an ACK of that FIN. There is no
 timeout for FIN_WAIT_2 (at least none I could find in RFC 793).

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.

The FIN_WAIT_2 results in kept state until a new connection is tried
that collides.

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.

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.

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.

Joe