[e2e] tcp connection timeout

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



rick jones wrote:
>>> 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?

That was largely TIME_WAIT.

There were versions that had problems with FIN_WAIT_2, but mostly due to
poor application behavior.

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

That only helps if you're in TIME_WAIT.

If you want to do a listen and your OS tells you there's an error
(because you've bound to the whole tuple, rather than leaving some
aspects open), you get an error which should help YOU decide to issue a
corresponding abort call - IF YOU WANT.

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

TCP is not optimized for this anywhere else. If you want to redesign the
WHOLE protocol to minimize the amount of spare state hanging around,
that'd be interesting, but a significant redesign. TCP is currently
designed to clean state _only_ when it interferes with a new connection.

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

You chose to use TCP as a simplex channel by leaving it in half-closed
and continuing to send new data and "it hurts when I do that"-- so don't
_do_ that.

I.e., if your application decides to half-close the connection, it has
little right to complain it no longer has that data channel to play with.

> That TCP could send something to at
> least reasonably guess if the remote is still there is a don't care.

Sure - TCP could do lots of things to compensate for a poorly written
application; as others have noted, it's not an issue as to what can put
into TCP, but rather what should. Adding features to compensate for the
deliberate misbehavior of an application seems a particularly poor
motivation.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEEdlBE5f5cImnZrsRAkiVAJ94WipB+8/4WCvB4Q2w7RrInvp8sACglG5I
Chio3mIyYyzfzaT34fNMMzg=
=pKlX
-----END PGP SIGNATURE-----