Re: Sending very large chunks over the data channel

2014-05-28 12:02 GMT+02:00 Harald Alvestrand <harald@alvestrand.no>:
> I think a lot could be done if we just defined the semantics of send():
>
> - send either succeeds fully or fails fully. There is no partial success.
> (Needed to ensure integrity of messages.)
> - the channel should stay up after a failed send (nothing got sent, this is
> not fatal)
> - the code for "the buffer is full, try later" and "this message is too big
> to ever send" should be different (so that we can know the difference
> between "back off" and "you must be kidding")
>
> There's a difficulty in the callback definition you suggest - I think it
> needs to say what size it is waiting for. Otherwise, we get a sequence like:
>
> -> send(20000) -> fail, temporary too big
> <- spaceAvailable(100)
> -> send(20000) -> fail
> <- spaceAvailable(1000)
> -> send(20000) -> fail
>
> and so on. That's not right.

Honestly I don't understand the send() API in both WebSockets and
DataChannels. As discussed in a previous thread it becomes unfriendly
when sending large chunks of data as it may fail in any moment
(sending buffer full and so on).

So, it we want this to be an API like the send() system call, we must
also provide other facilities (let's say EAGAIN). Well, the API
provides something similar (an exception) but IMHO becomes 100%
unfriendly.

This is JavaScript land. Why does not the browser just allocate space
for *all* the data provided in send() calls and deals with EAGAIN and
similar stuff internally? This is, send() NEVER fails, period. The
browser holds the data and sends it when it can. The JS code still can
check the bufferedAmount attribute in order to detect memory leaks due
to slow sending.

BTW: if I send a HTTP POST request with a large body (a ISO image) via
AJAX, would I get an error if the "sending buffer" is full? AFAIK no,
right? if so, why don't we provide the same behavior for DataChannel's
send() method?


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Wednesday, 28 May 2014 11:47:23 UTC