Re: [hybi] Clarify the role of closing handshake

[[e-mail]]

Hi Takeshi-san,

My comments inline..

Takeshi Yoshino <[e-mail]> wrote on 02/11/2011 04:17:44 PM:

> Hi Yutaka,
> 
> Thank you for joining the discussion.
> 
> Good point. I know that close(2) with incoming data remaining unread
> in kernel causes RST for example on Linux. It looks like this is 
> very platform dependent.

Yes, that may be platform dependent. At least, my linux (Ubuntu 9.04)
and my Windows XP SP3 send RST on close() when there's data in the receive
buffer.

> Let me confirm your claim. Here, you mean that RST coming after 
> PSH(Close frame octets) may cause trouble the receiver side in recv-
> ing Close frame octets?

Yes, but not limited to it. recv() may allow receiver to read data reached 

before RST(on Linux), but any send() after RST will fail with ECONRESET 
for sure. 
On this send error, typical implementation may close socket without 
bothering 
to read data in the receive buffer.

> 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.


> If we still take the way to drop Close reply,
> - Just as a hint for intermediaries to know the session is abandoned
> earlier than transport layer phenomenon (as Gabriel first 
> suggested), it's still worth try to send out Close and let 
> intermediaries see it, I think. We don't have to make it sure that 
> it's seen by intermediaries or delivered to the other peer.

# I am still not sure why 'intermediaries' need to see it. I will look 
into Gabriels suggestion.

> - If we decide to let a Close frame carry error code (as Greg and 
> Brodie suggest), yes, it may be problematic that Close frames are 
> dropped even though there's no network/intermediate problem.

Right.

> 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, or close browser, 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.)

Best.
- Yutaka