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

[Takeshi Yoshino <[e-mail]>]

On Wed, Feb 26, 2014 at 9:54 AM, Zhong Yu <[e-mail]> wrote:

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

The "queue" referred by some texts in the WebSocket API spec is also
underspecified. It doesn't say the queue is not used by close frame
sending. Chromium uses the same queue. There can be implementations that
allow a close frame overtake buffered data. Then, you're right.


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

The API should have some method to get notified of full/partial drain of
the buffer. Also, it's said to be an issue that there's no way to know how
much the upper limit of buffer size is on the UA in use.


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