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