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

Re: Sending very large chunks over the data channel

From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
Date: Wed, 28 May 2014 17:24:19 +0200
Message-ID: <5385FFA3.20707@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org

On 05/28/14 11:18, Harald Alvestrand wrote:
> On 05/28/2014 10:52 AM, Wolfgang Beck wrote:
>> Adding another data transfer protocol on top of SCTP wll not solve 
>> your problem.
>> The Websocket-style API is the problem.
>> It does not allow the JS to delay reception and does not tell you 
>> when it is apporpriate to send more data.
>> Sending a chunk and wait for an ACK? That means you will spend most 
>> of the time waiting for Acks instead of
>> transmitting data. Of course you can somehow negotiate how many 
>> chunks you can send without having to
>> wait for an ACK. Now you have re-implemented a substantial part of 
>> SCTP, probably with more errors and less sophistication.
>> What's wrong with the Streams API?
> The first thing wrong about the Streams API as described in the link 
> below is that it does not preserve message boundaries; a Stream is a 
> sequence of bytes.
> Our chosen abstraction is a sequence of messages.
> Something like the Streams API may be a Good Thing (and applicable to 
> websockets too), but the current proposal just has the wrong model for 
> our purposes.
> If you have a suggestion to bridge the gap, please bring it forward.
Not preserving message boundaries is valid objection. Maybe we can still 
borrow the Stream API's concepts. Either way, it is an API problem, not 
a protocol problem.

File transfer requires interaction with the File API. which has its own 
set of callbacks. Ideally we'd have a common pattern for operations 
where we need to wait for completion (sending a chunk, writing a chunk 
to file) and get informed about available data (a chunk was received 
from a data channel, a chunk was read from a file). Ideally, those 
operations are composable (check if the File API is ready to write 
another chunk, check if there is data on the data channel; check if the 
File API has read a chunk, check if a chunk can be send via the data 

Received on Wednesday, 28 May 2014 15:24:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC