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