Re: [hybi] Clarify the role of closing handshake

I can see Gabriel and a few others' point in which WS application 
programmers cannot rely
on WebSocket's data draining for delivery critical data anyway with a 
number of reasons which 
includes poor implementation of a browser, lack of consistency in behavior 
across browsers, 
unexpected user actions, network or server failures, etc, and abandon the 
draining by WS-layer
for more simplicity.

What bothers me, however, though is that immediate TCP socket closure can 
cause RST
which can be avoided in the normal close handshake currently proposed.

I would imagine one WS application would be some kind of streaming where a 
client is consistently
receiving data from a server while allowing client to control the stream 
(switch channels, 
fastfoward, rewind, etc.). When the client needs to go away, the RST would 
be generated
at high chances as there would more likely be some data in the TCP kernel 
buffer. I certainly do 
not want to see RST from the client at least in such normal operation for 
trouble shooting or for more 
robust sanity checking in our system development/deployment. (RST does not 
tell nothing!)

Some people have expressed a desire to have some reason code in Close 
frame to identify 
problems (I have no objection to it, but to some extent where it does not 
reveal too much information
on the wire.) Again. this Close frame also may not reach the other end due 
to the RST hazard.

I have no problem with implementing the close handshake currently proposed 
and
I do not think at all that it is that complicated for my non-browser 
WS-layer library. (I just do not know
exactly if this applies to the implementation for browsers.) We can also 
consider using 
wasClear equivalent  to take some action (re-connect, report the incident 
to a server, logging, etc.), too.

- Yutaka

hybi-bounces@ietf.org wrote on 02/16/2011 07:57:57 AM:

> Hi Takeshi,
> 
> I?m currently on vacation with very limited connectivity and time on
> the net. I?ll look at this again next week.
> 
> It seems like Ian?s proposed text still has the data draining in it.
> I thought a few of us were converging towards some of the text 
> proposed previously by you (without the data draining). TCP RST 
> issues are not WS protocol and could be taken care of by some 
> implementation advice as previously suggested. I?d really question 
> our complicating the WS protocol for anything that is not absolutely
> necessary. 
> 
> Thanks,
> 
> Gabriel
> 
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of 
> Takeshi Yoshino
> Sent: Tuesday, February 15, 2011 18:34
> To: Yutaka_Takeda@playstation.sony.com; Gabriel Montenegro
> Cc: hybi@ietf.org
> Subject: Re: [hybi] Clarify the role of closing handshake
> 
> On Tue, Feb 15, 2011 at 17:41, <Yutaka_Takeda@playstation.sony.com> 
wrote:
> Although the Ian Hickson's message did not explain why TCP FIN 
> (shutdown(SHUT_WR)) was 
> not always possible, it made me realize that I have completely 
> missed cases where we have 
> 
> FYI,
> http://www.ietf.org/mail-archive/web/hybi/current/msg01147.html by 
Maciej
> http://www.ietf.org/mail-archive/web/hybi/current/msg01173.html by Jamie
> etc.
> 
> 
> intermediary nodes (e.g. proxy) along the path which terminate TCP 
> layer. (We can not terminate 
> TCP connection before end-to-end WS-layer close handshake.) 
> 
> Thank you for the heads-up, and please accept my apologies for any 
> confusion I may have caused. 
> 
> Ian Fette's text for -06 looks good to me now. If we are to exchange
> Close frames as a normal 
> close handshake, then spurious RST issue should also be resolved in 
> the normal sequence. 
> In abnormal case, the RST issue may prevent the last bit including 
> Close frame also from reaching 
> the destination, which we need to be aware. 
> 
> Good. Thanks,
> 
> Gabriel, are you fine with Ian Fette's text for -06?
> According to Maciej's message http://www.ietf.org/mail-
> archive/web/hybi/current/msg01181.html and others on the thread, it 
> looks like there was consensus that we should have some method to 
> deal with RST hazard.
> 
> You can still terminate TCP for abandoned WebSocket immediately for 
> some case where it makes sense though that will be taken as abnormal
> case above in Yutaka's message. Making "wait for a Close frame in 
> response" SHOULD is another option.
> 
> Takeshi_______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi