Re: [hybi] Clarify the role of closing handshake

Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> Tue, 15 February 2011 01:31 UTC

Return-Path: <Gabriel.Montenegro@microsoft.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 3B4D03A6E02; Mon, 14 Feb 2011 17:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.42
X-Spam-Level:
X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 7Hw2Ix1BkuMG; Mon, 14 Feb 2011 17:31:36 -0800 (PST)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 75F383A6E00; Mon, 14 Feb 2011 17:31:36 -0800 (PST)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Feb 2011 17:32:00 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 14 Feb 2011 17:32:00 -0800
Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.102]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 14 Feb 2011 17:32:00 -0800
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: "Yutaka_Takeda@PlayStation.Sony.Com" <Yutaka_Takeda@PlayStation.Sony.Com>
Thread-Topic: [hybi] Clarify the role of closing handshake
Thread-Index: AQHLyLZQD4/LNEvRdUK4csWEI+DaLJP6cYsAgAABlOCAAI+qgIAAoGMAgABJG4CAASvVgIAAOECAgAAF0ICAADMNAIAAEuuAgARUZAD//4iRsIAA2P0A//97msA=
Date: Tue, 15 Feb 2011 01:31:50 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C1126E1534D@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
References: <CA566BAEAD6B3F4E8B5C5C4F61710C1126E142C9@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <OF30386040.0060CBE1-ON88257838.0006060F-88257838.00077B4D@playstation.sony.com>
In-Reply-To: <OF30386040.0060CBE1-ON88257838.0006060F-88257838.00077B4D@playstation.sony.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1126E1534DTK5EX14MBXW605w_"
MIME-Version: 1.0
Cc: "hybi-bounces@ietf.org" <hybi-bounces@ietf.org>, "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Clarify the role of closing handshake
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, 15 Feb 2011 01:31:44 -0000

Not sure why the presence update would not have happened beforehand. At any rate, I'm sure there's apps where that last bit of data matters. But there's also apps in which that last bit of data doesn't matter at all. If an app really cares, it should handle its data draining itself, and only issue the WS_Close() afterwards.

From: Yutaka_Takeda@PlayStation.Sony.Com [mailto:Yutaka_Takeda@PlayStation.Sony.Com]
Sent: 14 February, 2011 17:22
To: Gabriel Montenegro
Cc: hybi@ietf.org; hybi-bounces@ietf.org; Takeshi Yoshino
Subject: Re: [hybi] Clarify the role of closing handshake


Hi Gabriel,

> Most of the time, there won't be a gracious Close, as users will
> kill the browser window, exit out of the tab, etc. So I fear we're
> complicating the protocol for dubious benefits. We have to deal with
> sudden termination anyway.  At any rate, even if the RST prevents
> the other peer from receiving the WS_Close, the intermediaries will see it.

I was wondering about it.

> This is a case of added complexity for very little benefit.

Say, a client is trying to send an application data (for example, 'presence' update) before closing
WebSocket. The application data may not reach the server application either in some
condition. It is not just 'Close frame' that may not reach.

If we cannot handle 'closing state' in the case where user kills the browser window, then the
consequence would be the loss of *application data*, which may not be trivial...

Any thoughts?
--
Yutaka Takeda - US R&D Sony Computer Entertainment, Inc.
Office: 650 655 7484   Fax: 650 655 8060


hybi-bounces@ietf.org<mailto:hybi-bounces@ietf.org> wrote on 02/14/2011 12:34:01 PM:

> In A-2 and B, it seems you reversed the Pros and Cons.
>
> I'm not clear on the algorithm for B. Could you formulate in terms
> of peers A and B and clarify which side is doing what?
>
> At any rate, the cons of adding a wait state and additional
> complexity in the protocol is why I prefer the simplicity of A.
>
> Most of the time, there won't be a gracious Close, as users will
> kill the browser window, exit out of the tab, etc. So I fear we're
> complicating the protocol for dubious benefits. We have to deal with
> sudden termination anyway.  At any rate, even if the RST prevents
> the other peer from receiving the WS_Close, the intermediaries will see it.
>
> This is a case of added complexity for very little benefit.
>
> From: hybi-bounces@ietf.org<mailto:hybi-bounces@ietf.org> [mailto:hybi-bounces@ietf.org]<mailto:[mailto:hybi-bounces@ietf.org]> On Behalf Of
> Takeshi Yoshino
> Sent: Monday, February 14, 2011 11:33
> To: hybi@ietf.org<mailto:hybi@ietf.org>
> Subject: Re: [hybi] Clarify the role of closing handshake
>
> I'd like to summarize proposals again. It seems there's consensus on
> dropping acknowledgement feature, so I list only the others.
>
> I prefer [B].
>
> [Proposal A-1]
> Role of Close frame
> - Help intermediaries know the session is no longer used
> - Pass status code to the other peer
>
> Algorithm
> - To initiate close, a peer MUST send Close frame, and then the peer MUST
> -- close the underlying transport channel ... (*)
> - Once a peer received a Close frame, the peer MUST close the
> underlying transport channel
> - A peer MUST NOT send any more data (including control) after
> sending or receiving a Close frame
>
> Pros
> - There's no wait state needs to be handled after a peer decided to
> abandon the WebSocket
>
> Cons
> - When a peer call close(2) with some data left not recv-ed, the
> peer's TCP stack may send out RST. This can impede the other peer
> from receiving Close frame or even some data before a Close frame
>
> [Proposal A-2]
> Replace (*) in A-2 with this
> -- wait until the underlying transport channel is closed (by recv
> until EoS, wait for close event, etc.) with some timeout
>
> Pros
> - There's a wait state needs to be handled after a peer decided to
> abandon the WebSocket
>
> Cons
> - No more data is coming after Close frame, and therefore a peer can
> call close(2) on its TCP socket safely
> - The algorithm depends on the underlying transport channel's EoS signal
>
> [Proposal B]
> Role of Close frame
> - Help intermediaries know the session is no longer used
> - Pass status code to the other peer
> - Let each peer call close(2) on its TCP socket safely
>
> Algorithm
> - To initiate close, send a Close frame
> - Once received a Close frame
> -- (already sent a Close frame) close the underlying transport channel
> -- (otherwise) send a Close frame, and then close the underlying
> transport channel
> - A peer MUST NOT send any more data (including control) after
> sending a Close frame
>
> Reception of a Close frame means
> - All data the other peer sent has arrived
>
> Reception of a Close frame DOES NOT mean
> - All data has been delivered to the other peer
>
> Pros
> - There's a wait state needs to be handled after a peer decided to
> abandon the WebSocket
>
> Cons
> - No more data is coming after a Close frame, and therefore a peer
> can call close(2) on its TCP socket safely
>  _______________________________________________
> hybi mailing list
> hybi@ietf.org<mailto:hybi@ietf.org>
> https://www.ietf.org/mailman/listinfo/hybi