Re: WebRTC and backpressure (how to stop reading? And how to start sending again?)

On 26 March 2014 16:22, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
> On way would be to have an event signalling "you can read some data now if
> you have time" instead of "here's some data, deal with it"
>
> For the sending side, we need something similar: 'you can send at least one
> packet now' instead of just raising an unhelpful exception that doesn't tell
> you when you can try to send again. The File API has 'onwriteend' for this
> purpose.
>
> The libevent api (libevent.org) might be instructive.
>
> The JS API as it is now is clearly broken.

Agreed. Maybe Domenic Denicola (CC'ed in) might be able to comment on
what API style would be fit with current nomenclature? See
https://github.com/whatwg/streams

Other designs could be to tweak onmessage so that if the EventHandler
returns false, onmessage isn't fired again until a `resumeReading()`
method is called.

For the writing side of things, `onwriteend` is exactly what's needed.
Currently, applications can do blocking whenever they feel like, so
that's OK: for example, if you want to write to a WebSocket or WebRTC
data channel, you can check the bufferedAmount property first, and
mark the channel as 'unwritable' in the application-level handling if
there's more than 2MB buffered. Then, when the buffer drops again, you
can resume writing. Having an event that's fired when the
bufferedAmount drops would save polling, and there's no harm having
the application pick its own limit on the amount of buffered data. The
browser should probably expose a constant attribute though that says
how much it's willing to buffer before force-closing the connection!
The current Chrome implementation buffers up to
kMaxQueuedSendDataPackets=100 messages, which isn't much.

The WHATWG WritableStreams interface can currently be implemented for
WebSockets though just by polling the bufferedAmount in a timer
callback. It's a shame, but not a disaster. It's the read side of
things that's really problematic.

Regards,
Nicholas

-----
Nicholas Wilson: nicholas@nicholaswilson.me.uk
Site and blog: www.nicholaswilson.me.uk

Received on Wednesday, 26 March 2014 18:12:17 UTC