Re: DataChannels in Workers

On 10/1/2015 7:50 AM, David Dias wrote:
> Hi all,
>
> I’ve been following this thread with great excitement! I know several 
> projects that having DataChannels in /WebWorkers /(!== ServiceWorkers 
> to avoid confusion)//can make them from a practical and fun demo to 
> something thats actually usable by a lot of users.
>
> One of them, would be webrtc-explorer (for ref: 
> http://blog.daviddias.me/2015/03/22/enter-webrtc-explorer) where I 
> found empirically that a ‘Store and Forward’ message network approach 
> can drag the browser down and make all UI interactions unusable, when 
> the number of data events and write is high. Projects like WebTorrent 
> (webtorrent.io <http://webtorrent.io>), PANDO (Scalable and Reliable 
> Dynamic Array-based Computing on the Web, a new endeavour by Erick 
> Lavoie) and IPFS (the browser version) can benefit greatly from it.

Great to hear some more uses for this beyond games!  I agree this could 
really help make tools like this a lot easier to create without causing 
problems (such as blocking the main page content). We hope to have an 
implementation of this soon, but don't have a target release date yet.

> Right now, there isn’t also a way to prioritise messages once we 
> connect to more than one peer at the same time, which becomes critical 
> in a single threaded environment where a browser can have hundreds of 
> Data Channels open.

There are several things that can help here, including the SCTP ndata 
work that's ongoing.  Another is BufferedAmountLowThreshold (Firefox and 
Chrome both recently added support for it, but full support including 
data buffered in the stack requires some new features in the upstream 
SCTP library.  Currently both implementations only include data buffered 
outside of the SCTP stack).

> One thing I haven’t understood completely is what are the actual 
> implications of enabling the WebRTC API to be accessible from a 
> WebWorker, if any?

For RTCDataChannels, the implications are pretty simple:
* You can call channel.send()/channel.close() from the worker
* Events for the channel will occur in the worker (onmessage/etc)
* You have no access to the RTCPeerConnection (and thus can't create new 
channels from there)
* New data channels created from the other side will appear in the main 
context (via ondatachannel/etc); you can immediately transfer them to 
the worker.

Making peerconnection transferrable or creating some sort of 
peerconnection-proxy-for-workers would be more involved.
Allowing createDataChannel or ondatachannel to occur in the worker would 
be more complex, and it's unclear those are time-critical operations the 
way send() and message reception are.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam