[whatwg] Flow Control on Websockets

[Takeshi Yoshino]

On Fri, Oct 18, 2013 at 4:02 PM, Michael Norton <norto at me.com> wrote:

> Sent by the hope boat.
>
> On Oct 18, 2013, at 2:46 AM, Takeshi Yoshino <tyoshino at google.com> wrote:
>
> > On Fri, Oct 18, 2013 at 10:36 AM, William Chan (陈智昌)
> > <willchan at chromium.org>wrote:
> >
> >>> Your second question is whether it's possible to stop the browser
> >>> reading from the socket. Yes, just don't return from your onmessage
> >>> handler until you've actually finished handling the message. If you
> >>> fire up a new worker then tell the browser you're done, you're seeing
> >>> the inevitable result of that. You have to wait on the worker - or, if
> >>> you want to process say four messages in parallel, wait on the worker
> >>> pool until it's dropped below four active before returning.
> >>
> >> Pardon the ignorance, but doesn't the onmessage handler run on the main
> >> thread? If you don't return from it, then doesn't that block the main
> >> thread? If so, then I think that's a bad solution. Blocking the main
> thread
> >> is generally terrible IMO and should be avoided.
> > If an app is designed so that main JS thread does actual work (yes, this
> is
> > basically bad choice as Willchan said), we could choose to make back
> > pressure based on buffer consumption (onmessage processing) rate.
> >
>
> Can you please elaborate one what "main JS thread" means?
>

I meant non-worker.


>
> Also,  I am confused as "to make back
> > pressure based on buffer consumption (onmessage processing) rate"
>
> What are you trying to say?  Many years ago I wrote (not on this list)
> about the concept of quantum buffers.  I think maybe you are trying to
> reduce the processing work of a browser?
>

If onmessage takes longer time, the buffer to store data received from the
socket will become longer. The length of the buffer can be used to decrease
receiver window size of TCP. I meant like this.


>
>
> > If an app is designed to be responsive and such work is done by some
> other
> > asynchronous HTML5 API, this method doesn't work.
> >
> > If such blocking work is done in a worker, this method should work. (FYI,
> > Chrome (Blink) doesn't have such flow control between network thread and
> > worker thread yet, so this shouldn't work on Chrome for now).
>
> Perhaps the reason for this lack of flow control is to protect the Chrome
> user's autonomy?  Think about it, it could be a good thing:  it is ok if
> network thread has its own dominion and a worker thread has its own, the
> latter of course dependent on transparency with the Chrome user.
>

Just not implemented yet. We'll investigate it at some point.