IETF Logo Mail Archive

[EME] Re: TCP close semantics

Rémi Després <remi.despres@rd-iptech.com> Mon, 20 November 2006 14:32 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAC8-0000AR-CJ; Mon, 20 Nov 2006 09:32:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAC6-0000AK-VU for eme@irtf.org; Mon, 20 Nov 2006 09:32:22 -0500
Received: from smtp19.orange.fr ([80.12.242.17] helo=smtp-msa-out19.orange.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAC5-0002kx-HN for eme@irtf.org; Mon, 20 Nov 2006 09:32:22 -0500
Received: from [127.0.0.1] (APuteaux-152-1-80-195.w86-205.abo.wanadoo.fr [86.205.81.195]) by mwinf1911.orange.fr (SMTP Server) with ESMTP id 15CF71C000FB; Mon, 20 Nov 2006 15:32:13 +0100 (CET)
X-ME-UUID: 20061120143213893.15CF71C000FB@mwinf1911.orange.fr
Message-ID: <4561BC70.7050909@rd-iptech.com>
Date: Mon, 20 Nov 2006 15:32:16 +0100
From: Rémi Després <remi.despres@rd-iptech.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <E6F7A586E0A3F94D921755964F6BE00662575C@EXCHANGE2.cs.cornell.edu> <455B48BD.5050201@isi.edu> <455B56C9.7080307@rd-iptech.com> <455B6358.4000703@isi.edu> <455C38AC.1090306@rd-iptech.com> <455CDFFF.8000500@isi.edu> <455D9BD5.7000900@wanadoo.fr> <1163775763.8736.114.camel@sioux.systems.cs.cornell.edu> <c70bc85d0611170827t36b9443fm2b5581721142b769@mail.gmail.com> <455DE7D1.6030805@isi.edu> <c70bc85d0611170940s26d906aak4241fe728be5590d@mail.gmail.com> <455DFF44.9060208@isi.edu> <455EEB37.1020504@rd-iptech.com> <455F500E.9050503@isi.edu>
In-Reply-To: <455F500E.9050503@isi.edu>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: eme <eme@irtf.org>
Subject: [EME] Re: TCP close semantics
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0406527873=="
Errors-To: eme-bounces@irtf.org

Joe Touch wrote:
> Rémi Després wrote:
>   
>> 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".
>   
Both of us agree that, if application A closes a connection it has with 
application B, _and knows that B never closes itself before it has been 
returned a CLOSED status_, then A can take the return of a CLOSED status 
as a guarantee that all data sent to B have been received.

Its OK with me if we leave the discussion at this point (our difference 
of view is on something else, probably not worth clarifying here).

RD
 
> Joe
>
>   

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme

v2.23.0 | Report a Bug | By Email