Re: DataChannel: how to know the max size of the sending buffer?

On 05/07/14 17:42, Iñaki Baz Castillo wrote:
> 2014-05-07 17:28 GMT+02:00 piranna@gmail.com <piranna@gmail.com>:
>> I would find it better that process gets blocked until the buffer
>> gets some space available (it's said, it has send something),
> 
> No way. JavaScript event loop MUST NEVER block. If it blocked all
> the web would block (even a mouse click, timers, etc). Just the
> alert() call blocks the JavaScript event loop (and you know how
> "usable" a web is while displaying an alert) ;)
> 
> 
>> or raise an error or throw an exception
Blocking is bad, closing the session is hilariously stupid. How on
earth could you do a simple thing like a file transfer with such an API?
What if the SCTP window shrinks because of a packet loss, and your
datachannel implementation shuts down the session because the JS app
had no way to anticipate this?

Inside OS kernels, we have the same problem and have solved it decades
ago: run the sender when there is space in the queue. Run the receiver
when there is data available (but don't remove the received data from
the queue yet, the receiver might not be able to handle when its
upstream queues are full).

In Javascript, this would translate into two callbacks:
onreceivedata() just tells the JS that it can get a message from the
datachannel now.
onsendspace() tells the JS that it can send a packet now

recv() would fail with an exception, when there is no data available,
send() would fail with an exception, when the JS tried to send without
waiting for a onsendspace() event.


Wolfgang

Received on Saturday, 10 May 2014 12:09:39 UTC