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

"Anne van Kesteren" <annevk@opera.com> Mon, 01 February 2010 22:25 UTC

Return-Path: <annevk@opera.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 04E973A68B2 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 14:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.266
X-Spam-Level:
X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 OvBAWB-xT-W6 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 14:25:24 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id C8C113A67D4 for <hybi@ietf.org>; Mon, 1 Feb 2010 14:25:23 -0800 (PST)
Received: from annevk-t60 (5355737B.cable.casema.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id o11MMBB3023621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Feb 2010 22:22:12 GMT
Content-Type: text/plain; charset="utf-8"; format="flowed"; delsp="yes"
To: Salvatore Loreto <salvatore.loreto@ericsson.com>, Justin Erenkrantz <justin@erenkrantz.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>
Date: Mon, 01 Feb 2010 23:25:49 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Anne van Kesteren <annevk@opera.com>
Organization: Opera Software ASA
Message-ID: <op.u7gy9bag64w2qv@annevk-t60>
In-Reply-To: <4B672C9D.9010205@ericsson.com>
User-Agent: Opera Mail/10.10 (Linux)
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:25:29 -0000

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.


-- 
Anne van Kesteren
http://annevankesteren.nl/