Re: [hybi] Clarify the role of closing handshake

[Takeshi Yoshino <[e-mail]>]

On Tue, Feb 15, 2011 at 14:49, Justin Lee <[e-mail]> wrote:

>
>
> On Tue, Feb 15, 2011 at 5:45 PM, Takeshi Yoshino <[e-mail]>wrote:
>
>> On Tue, Feb 15, 2011 at 13:45, <[e-mail]>wrote:
>>
>>>
>>> Okay, I admit my example was bad.
>>>
>>> Just to be clear, even with this code:
>>>
>>>       websocket.send("a-message-needs-to-reach-server")
>>>       websocket.close()
>>>
>>> From your opinions, programmers should not expect that the message always
>>> reach the server. (granted)
>>>
>>>
>> Yes, this point should be noted in the spec, or developers may
>> misunderstand.
>>
>
> In the grizzly version, I actually just queue up the close frame behind the
> others.  Is this not what should happen?  Should the close frame jump to the
> front of the line?
>
>

At least I can say that is not incorrect behavior. Whether "Send something"
in *start the WebSocket closing handshake* algorithm should break in or just
queue behind the others is not specified in the spec, I think. IMO, we
should queue Close frame behind the others. If close() breaks in, preceding
send()s are cancelled. That's bad programming model though I can imagine
some implementation might have urgent_close() or something that breaks in if
they need. FYI, we queue a Close frame behind the others in pywebsocket,
too.

Here what we're talking about is how to let the client know if
"a-message-needs-to-reach-server" is received by the other peer or not by
using closing handshake. Even "a-message-needs-to-reach-server" is queued
before a Close frame, it's possible that it cannot make it to the other peer
for some network problem, etc.