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 10:52:33 +0200
Message-ID: <5385A3D1.2080108@gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Adding another data transfer protocol on top of SCTP wll not solve your 

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?


On 05/27/14 09:37, Stefan Håkansson LK wrote:
> This was discussed at the f2f, and the Streams API was mentioned, but as
> Harald pointed out yesterday the applicability of Streams with the data
> channel is not clear yet.
> But there is another option that is supported right now. The blob
> (defined in http://dev.w3.org/2006/webapi/FileAPI/) supports slicing up
> data chunks in smaller parts (and of course re-assembling them back).
> So, it is quite simple to split up a large chunk in smaller ones, and
> then add some simple acking on the app layer (hold back sending next
> slice until the previous one is acked).
> This is not elegant, but should work.
> The quota API (https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html)
> allows for a bit more sophistication, but it seems to be supported by
> Chrome only (and then only an older version of the API).
> Stefan
Received on Wednesday, 28 May 2014 08:53:03 UTC

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