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

Maciej Stachowiak <mjs@apple.com> Mon, 01 February 2010 22:33 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 60DA93A69C2 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 14:33:16 -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 WuQdLEfuAVOL for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 14:33:15 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 99C913A6869 for <hybi@ietf.org>; Mon, 1 Feb 2010 14:33:15 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 7693589AC5A7 for <hybi@ietf.org>; Mon, 1 Feb 2010 14:33:51 -0800 (PST)
X-AuditID: 11807137-b7bd4ae000000f0d-c0-4b6756cf0631
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay16.apple.com (Apple SCV relay) with SMTP id 9E.9A.03853.FC6576B4; Mon, 1 Feb 2010 14:33:51 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.246.17.57] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX6000R2PCEVGA0@et.apple.com> for hybi@ietf.org; Mon, 01 Feb 2010 14:33:51 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <op.u7gy9bag64w2qv@annevk-t60>
Date: Mon, 01 Feb 2010 14:33:49 -0800
Message-id: <96935605-E8B8-4718-B60F-570FD2C199E4@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>
To: Anne van Kesteren <annevk@opera.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: Mon, 01 Feb 2010 22:33:16 -0000

On Feb 1, 2010, at 2:25 PM, Anne van Kesteren wrote:

> On Mon, 01 Feb 2010 20:33:49 +0100, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
>> 1) "safely" shutdown a websocket connection.
>>      The possibility to lose data while closing a TCP connection is a well-known problem,
>>      as has also been discussed and described in the thread.
>> 
>>      Some people think there is a value to add to the spec gracefully shutdown the websocket connection.
>> 
>>      However I haven't seen a clear consensus on it.
>> 
>>      So please if you have an opinion on this, speak up!!!
> 
> We discussed this on IRC earlier today. The idea is to introduce a frame for closing. If A wants to close the connection it transmits 0xFF 0x00. Once the B receives that and has no more messages to transmit it transmits 0xFF 0x00 as well. When A receives that it knows it can close the connection.
> 
> This would not be required of servers however as there are scenarios (e.g. news tickers) where it does not really matter whether everything has been received by the client.

I think it's simpler to just always do the close handshake than to have an exception to opt in to random data loss in the rare cases where it is acceptable. Certainly general-purpose frameworks for using WebSocket should always do this.

I also wonder if messages both ways are really needed for a close.

Here is an alternative:

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.

People who understand the TCP issue: would that be sufficient to avoid the TCP reset hazard? From the description I saw, I believe it would, since neither endpoint would send data after the other has closed its connection. If it does work, then it is on less round trip than the close handshake Anne described.

Regards,
Maciej