[EME] Re: TCP close semantics

[Joe Touch <[e-mail]>]

Rémi Després wrote:
> Joe Touch wrote :
>> ...
>> Doing that means keeping TCP semantics, which means that a FIN/ACK means
>> what a FIN/ACK means - that the -endpoint- got the data, not that a
>> middlebox somewhere else did.
>>   
> Sorry to insist that AFAIK this statement is inaccurate, at least if, as
> I understand it, the endpoint refers to the application that uses TCP.
> 
> YES, when an application receives a FIN, it _does mean_ that it has
> received all its incoming data have been received.
> But NO, after an application has sent a FIN, reception of the ACK for
> that FIN by its TCP stack _doesn't mean_ that all its outgoing data have
> been received  by the far end application.

It does mean that the TCP stack has received all outstanding data that
preceded the FIN.

> AFAIK _the application that sends a FIN is not even informed that the
> FIN has been acknowledged _ (no provision for this at its socket API
> with its TCP stack). .

There are no async signals to the app; it's always the app's
responsibility to check the state. The app must issue a READ on the
connection after issuing a CLOSE until the response is that there is no
data and the request returns a status "CLOSED".

Joe

_______________________________________________
EME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/eme