Re: [hybi] Clarify the role of closing handshake

[Takeshi Yoshino <[e-mail]>]

On Mon, Feb 14, 2011 at 16:14, <[e-mail]> wrote:

> > In a bit different context but I see that
>
 > Jamie is also saying so in http://www.ietf.org/mail-
> > archive/web/hybi/current/msg01044.html. On what platform this really
> > occurs for example? Just curious. Linux socket allows us to recv
> > data PSH-ed before RST, then ECONNRESET is returned, so I missed this
> point.
>
> Yes, my linux, too it lets receiver to read data received before RST.
> My windows, though, does not seem to let receiver to read the data and
> recv()
> returned 'ECONNRESET' right away.
>
> # If we need some experiment, I can help.
>
> Thanks for the information

> IIRC, there was discussion in designing -00 closing handshake that
> > we should avoid underlying transport layer's semantics in realizing
> > WebSocket layer event. To follow this philosophy, we could replace
> > the last FIN with Close frame. i.e. we again ask both sides send a
> > Close frame so that both sides can safely invoke close(2) after
> > seeing Close frame.
>
> In browser usage, can we actually wait for Close frame from the peer
> after sending Close frame (=app already closed.) ?
> When user jumps to another page,


Though it depends on design as you say, network stack may continue to take
care of those abandoned socket (send 2xx Close and wait for Close). I'm fine
with making draining (either your idea based on SHUT_WR or my idea using
Close frame) optional so that people who takes this just a kind of waste of
resource/time.


> or close browser,


I think sudden close like this can be grouped with network trouble.


> is WS-layer able
> to wait for Close frame to begin with? It just occurred to me...
> (I have no knowledge in browser design/policy.)
>
>