Re: [hybi] Clarify the role of closing handshake

[Takeshi Yoshino <[e-mail]>]

On Fri, Feb 11, 2011 at 16:17, Takeshi Yoshino <[e-mail]> wrote:

>  - didn't receive Close means (?)
> -- because of RST issue
> -- because of network issue
>
> We have to give (?) some semantics that's not confusing.
>

s/semantics/explanation/


> If this is too complicated, then don't bother sending 'Close' but just
>> close TCP socket,
>> which would be the simplest. My preference is to do above cleanup
>> properly.
>>
>>
> IIRC, there was discussion in designing -00 closing handshake that we
> should avoid underlying transport layer's semantics in realizing WebSocket
> layer event.
>

Citing Hixie's post
http://www.ietf.org/mail-archive/web/hybi/current/msg01526.html

... -- people cited numerous examples of cases where we can't rely on
TCP semantics in practice -- ...


> 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.
>
>
Note that this is the same as "2) drop feature-b)" in my first post in this
thread
- a bit more complicated than what Gabriel proposed and I've cleaned up into
text
- intermediaries have to keep the connection until it sees Close frame on
both direction
- a peer have to wait for reply just to deal with this RST hazard even
though it's not interested in the other peer any more