Re: [hybi] Reliable message delivery (was Re: Technical feedback.)

Maciej Stachowiak <mjs@apple.com> Tue, 02 February 2010 00:29 UTC

Return-Path: <mjs@apple.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8CC3A686C for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 16:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWeQ8ctK8rsd for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 16:29:53 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4205C3A63EC for <hybi@ietf.org>; Mon, 1 Feb 2010 16:29:53 -0800 (PST)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 780768317DE3 for <hybi@ietf.org>; Mon, 1 Feb 2010 16:30:29 -0800 (PST)
X-AuditID: 11807130-b7b0aae00000102c-4d-4b677225fe29
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id B0.B2.04140.522776B4; Mon, 1 Feb 2010 16:30:29 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.246.17.218] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX6001KBUQTKS80@elliott.apple.com> for hybi@ietf.org; Mon, 01 Feb 2010 16:30:29 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <8B0A9FCBB9832F43971E38010638454F032E5065ED@SISPE7MB1.commscope.com>
Date: Mon, 01 Feb 2010 16:30:28 -0800
Message-id: <9B4F25B1-8A2D-4BB0-8995-897CCF1CB3C3@apple.com>
References: <4B62C5FE.8090904@it.aoyama.ac.jp> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com> <8449BE19-3061-4512-B563-02973FBB707B@apple.com> <5c902b9e1001292310l5442d476n8375139f3480671b@mail.gmail.com> <26D406E7-2319-476E-9ADF-80D84200C270@apple.com> <5c902b9e1001292333k79569316lf371938c9aa766@mail.gmail.com> <128BFD31-9835-47B1-B7A9-F20F5CDA8D8C@apple.com> <20100130144936.GD19124@shareable.org> <5c902b9e1001301552n6efb7969o34110373e3ab4945@mail.gmail.com> <4B672C9D.9010205@ericsson.com> <op.u7gy9bag64w2qv@annevk-t60> <96935605-E8B8-4718-B60F-570FD2C199E4@apple.com> <8B0A9FCBB9832F43971E38010638454F032E5065ED@SISPE7MB1.commscope.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Reliable message delivery (was Re: Technical feedback.)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2010 00:29:54 -0000

On Feb 1, 2010, at 4:00 PM, Thomson, Martin wrote:

>> If A wants to close the connection it does the following:
>> 
>> 1) transmits 0xFF 0x00 to B.
>> 2) Calls shutdown(SHUT_WR) on its socket (instead of close)
>> 3) Reads anything else transmitted from B until it gets EOF, at which
>> point it calls close().
>> 
>> When B receives 0xFF 0x00, it sends any remaining buffered messages and
>> calls close.
> 
> Anne's described solution works better.

How is it better? Can my solution lead to data loss?

> The 0xff00 frame is the indication that close() can be called safely.  Besides, it's two extra octets, hardly an imposition on either end.

It's not the octets that are wasteful, it's the extra round trip. The only material difference in my protocol is that the party responding to, rather than initiating the close doesn't have to send a special message, it just counts on the close initiator getting an EOF. Since the initiator has to stop sending after the close request, there's no risk of data loss in the other direction either (assuming I understand the TCP issue correctly.)

Regards,
Maciej