Re: [hybi] Clarify the role of closing handshake
Yutaka_Takeda@PlayStation.Sony.Com Tue, 15 February 2011 20:24 UTC
Return-Path: <Yutaka_Takeda@PlayStation.Sony.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 3BBB13A6D75; Tue, 15 Feb 2011 12:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.093
X-Spam-Level:
X-Spam-Status: No, score=-5.093 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, 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 dOSk-laGkwWe; Tue, 15 Feb 2011 12:24:45 -0800 (PST)
Received: from paris.playstation.sony.com (nat.playstation.sony.com [69.36.131.254]) by core3.amsl.com (Postfix) with ESMTP id AA2F53A6D73; Tue, 15 Feb 2011 12:24:45 -0800 (PST)
Received: from constantine.playstation.sony.com ([162.49.67.15]) by paris.playstation.sony.com (Lotus Domino Release 8.5.1FP5) with ESMTP id 2011021512250663-574269 ; Tue, 15 Feb 2011 12:25:06 -0800
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C1126E1534D@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
MIME-Version: 1.0
X-KeepSent: 5442EF1E:2B5095C9-88257838:006DA28B; type=4; flags=0; name=$KeepSent
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
Message-ID: <OF5442EF1E.2B5095C9-ON88257838.006DA28B-88257838.00702999@playstation.sony.com>
From: Yutaka_Takeda@PlayStation.Sony.Com
Date: Tue, 15 Feb 2011 12:25:06 -0800
X-MIMETrack: Serialize by Router on SCEA919ML04/SCEA(Release 8.5.1FP3|May 23, 2010) at 02/15/2011 12:25:06 PM, Serialize complete at 02/15/2011 12:25:06 PM, Itemize by SMTP Server on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 02/15/2011 12:25:06 PM, Serialize by Router on SCEA919ML02/SCEA(Release 8.5.1FP5|September 29, 2010) at 02/15/2011 12:25:12 PM, Serialize complete at 02/15/2011 12:25:12 PM
Content-Type: multipart/alternative; boundary="=_alternative 0070299788257838_="
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 20:24:54 -0000
> If an app really cares, it should handle its data > draining itself, and only issue the WS_Close() afterwards. So, now the question here is WHO should be responsible for the 'last-bit draining'. If application wants to send a data to a server when browser is closing (triggered by user), for example, is there a way to be sure that the server app received it? I have embarrassingly limited knowledge of JavaScript but from my understanding, you can catch such event by using window.onbeforeunload = function() { return do_something() } With XmlHttpRequest, you can send data *synchrnously" to be sure that the data has reached the server. But WebSocket, there's no way to block send() operation (there's no build-in response to websocket). What could be the possible workaround to this case? (Brwoser/JS/WSAPI expert should chime in here...) I personally think that WS-layer should be responsible for the last-bit draining rather than pushing the responsibility to the application. WebSocket being "bidirectional" raises this issue we did not see in request/response based HTTP. With the same reason why TCP has rather complicated graceful shutdown mechanism, WebSocket should also take care of this issue, IMO. Best. - Yutaka hybi-bounces@ietf.org wrote on 02/14/2011 05:31:50 PM: > 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 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] On Behalf Of > > Takeshi Yoshino > > Sent: Monday, February 14, 2011 11:33 > > To: 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 > > https://www.ietf.org/mailman/listinfo/hybi > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Gabriel Montenegro
- [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake John Tamplin
- Re: [hybi] Clarify the role of closing handshake Greg Wilkins
- Re: [hybi] Clarify the role of closing handshake Gabriel Montenegro
- Re: [hybi] Clarify the role of closing handshake Greg Wilkins
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Brodie Thiesfield
- Re: [hybi] Clarify the role of closing handshake Gabriel Montenegro
- Re: [hybi] Clarify the role of closing handshake Greg Wilkins
- Re: [hybi] Clarify the role of closing handshake Brodie Thiesfield
- Re: [hybi] Clarify the role of closing handshake Salvatore Loreto
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Gabriel Montenegro
- Re: [hybi] Clarify the role of closing handshake Andy Green
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Gabriel Montenegro
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake John Tamplin
- Re: [hybi] Clarify the role of closing handshake Brian
- Re: [hybi] Clarify the role of closing handshake Peter Saint-Andre
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Ian Fette (イアンフェッティ)
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Justin Lee
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Brodie Thiesfield
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Takeshi Yoshino
- Re: [hybi] Clarify the role of closing handshake Gabriel Montenegro
- Re: [hybi] Clarify the role of closing handshake Yutaka_Takeda