[e2e] tcp connection timeout

[rick jones]

>> 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'?)

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

Should the semantics of SO_REUSEADDR be the default then?

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

_No_ reason?  Admittedly, the TCP connection state doesn't have to be 
particularly large, but there can be a particularly large number of 
them.

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

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.

rick jones
there is no rest for the wicked, yet the virtuous have no pillows