Re: [hybi] Straw poll: Do you miss interjectable WebSocket level control frame? (was: Re: Discontinuation of mux ...)

[Zhong Yu <[e-mail]>]

To be certain that data is delivered, app needs to perform lingering
close by itself, by polling bufferedAmount, and only call close()
after it reaches 0.

This is strange, due to the flaw that send() is an async method but
without a way to registered a callback.

Zhong Yu


On Tue, Feb 25, 2014 at 4:05 PM, Takeshi Yoshino <[e-mail]> wrote:
> On Tue, Feb 25, 2014 at 5:27 PM, Yutaka Hirano <[e-mail]> wrote:
>>>
>>> Shouldn't ws.close() allow queued messages to be flushed before the
>>> actual closing?
>>
>> It is allowed to wait until the endpoint finishes sending the message.
>> Is it the desired behavior? I thought it is undesired, but I'm not
>> confident now.
>
>
> I think it's underspecified. In the WHATWG WebSocket API spec, close() is
> required to "start the WebSocket closing handshake". RFC 6455 neither says
> the algorithm may terminate ongoing "Send a WebSocket Message" algorithm nor
> says it may not.
>
> ----
>
> Even if we allow close to terminate ongoing send, since the sender requests
> the termination explicitly and the peer replies to the close with a close
> frame after understanding the ongoing send is cancelled, it's fine to call
> it as clean close, I think.
>
> There's no way in the WebSocket API to tell that the message it is receiving
> has been cancelled to the script, but I don't think it's problematic. The
> message sending was clearly cancelled. Both side knows that. The receiver
> just won't deliver the cancelled message.
>
> ----
>
> But I think there're also needs for graceful close, i.e. to send a message
> and do closing handshake after finishing the send. If there's only method
> that terminates ongoing send, the user is required to do app level
> acknowledgement before calling the method.
>
> My gut feeling is that such a cancellation should be provides as a separate
> method and close() should work as a graceful close.
>
> This needs more discussion, but I believe WebSocket users are already used
> to graceful behavior.
>
>>
>> On Tue, Feb 25, 2014 at 2:40 PM, Zhong Yu <[e-mail]> wrote:
>>>
>>> On Mon, Feb 24, 2014 at 10:58 PM, Yutaka Hirano <[e-mail]>
>>> wrote:
>>> >> * Close: Can be used to perform a "clean" close in the middle of
>>> >> sending a
>>> >> message. However, I cannot think of any applications that would
>>> >> consider a
>>> >> situation in which a in-transit message was aborted to close the
>>> >> connection
>>> >> to be a "clean close" scenario.
>>> >
>>> > An endpoint should be able to cancel the ongoing transmission, i.e. The
>>> > close call should abort transferring very_very_long_message in the
>>> > following
>>> > code.
>>> >
>>> >
>>> > ws = new WebSocket(...);
>>> > ws.onopen = function() {
>>> >   ws.send(very_very_long_message);
>>> >   ws.close();
>>> > };
>>>
>>> Shouldn't ws.close() allow queued messages to be flushed before the
>>> actual closing?
>
>