Re: [hybi] Clarify the role of closing handshake

[John Tamplin <[e-mail]>]

On Wed, Feb 9, 2011 at 7:21 PM, Gabriel Montenegro <
[e-mail]> wrote:

> +1 on Dropping feature B (data draining) and only keeping the simple
> semantics of feature A as you say below:
>
>
>
> a) peer B assume that no more data is coming from peer A when B receives
> closing initiation from A
>
>
>
> Either side has to be ready for the other side going away without warning
> (a user just yanking the page in the browser). Any value for data draining
> is suspect and better handled at the application. There may be value in
> having it as a signal to intermediaries so they can claim state earlier than
> they might have otherwise (they also have to have timeouts as they cannot
> rely on the Close message being cleanly sent), but then the simplest form is
> enough.
>
>
>
> My suggestion on Close is to simplify it along these lines:
>
>
>
> ·         Using simple close semantics (whoever sends it, closes the
> entire session).
>
> ·         No half-close semantics as in TCP
>
> ·         Assuming that any data draining must be taken care of by the
> app, so no need for acking a close.
>
> ·         Assuming that the primary purpose of a Close is to inform
> intermediaries that the session is now terminated.
>
>
>
> Proposed text is:
>
>
>
> 4.5.1.  Close
>
>
>
>    The Close message contains an opcode of 0x01 and no body.
>
>
>
>    The websocket is considered fully closed when an endpoint has either
> sent or received a Close message.
>
>    Accordingly, upon sending or receiving a Close message, no more data or
> control messages can be sent on  the websocket.
>
>
>
> Comments?
>

I would say it is fully closed when both sent and received a Close message,
or when the underlying channel is closed.

-- 
John A. Tamplin
Software Engineer (GWT), Google