W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Sending very large chunks over the data channel

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 28 May 2014 14:04:17 +0200
Message-ID: <5385D0C1.6090001@alvestrand.no>
To: public-webrtc@w3.org
On 05/28/2014 01:46 PM, IƱaki Baz Castillo wrote:
> 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.

That's what the API looks like now. Until it fails, it works.

We're discussing what to do when the browser is unable to do that.

There's only so many gigabytes of storage available on the devices these 
days.

>
> 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?
Please show me your Javascript that sends a large video file using HTTP 
POST.

Code speaks louder than words here.
Received on Wednesday, 28 May 2014 12:04:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC