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

Maciej Stachowiak <mjs@apple.com> Tue, 02 February 2010 00:31 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 D1A003A68C4 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 16:31:43 -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 VVBVjaiBpKzO for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 16:31:43 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 29BDD3A63EC for <hybi@ietf.org>; Mon, 1 Feb 2010 16:31:43 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 814248317E79 for <hybi@ietf.org>; Mon, 1 Feb 2010 16:32:19 -0800 (PST)
X-AuditID: 11807137-b7bd4ae000000f0d-23-4b677293c73f
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay16.apple.com (Apple SCV relay) with SMTP id 95.92.03853.392776B4; Mon, 1 Feb 2010 16:32:19 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.246.17.218] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX60091EUTUKRA0@gertie.apple.com> for hybi@ietf.org; Mon, 01 Feb 2010 16:32:19 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <Pine.LNX.4.64.1002012354380.3846@ps20323.dreamhostps.com>
Date: Mon, 01 Feb 2010 16:32:18 -0800
Message-id: <F21A8D9A-1E27-48C8-8818-0BB6872A2CE4@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> <Pine.LNX.4.64.1002012354380.3846@ps20323.dreamhostps.com>
To: Ian Hickson <ian@hixie.ch>
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:31:43 -0000

On Feb 1, 2010, at 4:00 PM, Ian Hickson wrote:

> 
> On the client side, I agree in principle (at least to ensure that no 
> client-to-server data is lost in a case where the API is used to send 
> frames then immediately close the connection). However, what if the server 
> never closes its side of the connection, even after the client initiates a 
> close? Should we have some sort of timeout?
> 
> On the server side, I don't think there's any point _requiring_ that the 
> server close gracefully. If the server really doesn't care if data it just 
> sent is received, e.g. because it knows the client side has already GC'ed 
> its WebSocket object, then it should just be able to close abruptly.

How can the server possibly know that the client has already GC'd its WebSocket object, if the server and not the client is the initiator of the close? (If the client initiates the close, then at least in my proposal there's no extra work for the server.)

Regards,
Maciej