Re: DataChannels in Workers

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 <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), 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.

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.

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?

Thank you,


> On 30 Sep 2015, at 07:43, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> 
> On 25/09/15 18:01, Randell Jesup wrote:
>> Use-case:
>> A number of applications using RTCDataChannels would benefit from being
>> able to process the data and send data from a Worker.  An example of
>> this is a game which handles state updates and other processing in a
>> Worker, keeping the mainthread application free to handle rendering and
>> UI interactions, and avoiding or minimizing GC pauses.
>> 
>> Basic Mechanism:
>> The RTCDataChannel would be a transferrable object, which can be sent
>> via postMessage:
>> 
>>    channel = createDataChannel("MyChannel", {});
>>    // or we're in an ondatachannel callback/event triggered by the other
>>    // side creating an RTCDataChannel
>>    worker.postMessage(channel, [channel]);
>>    // channel is now owned by the worker; no more events will occur on the
>>    // sender's version of 'channel'
>> 
>> The worker will receive the object, and can set event handlers on it.
>> 
>> Handling of Events:
>> After a transfer, all events occur in the worker, and the worker must
>> set up event handlers to process them.  Any events that occur during the
>> transfer, or that were queued to be fired in the sender, will be held
>> until the worker gets the transferred object.  This means the worker
>> should set EventHandlers on the channel immediately on receiving the
>> channel.
>> 
>> Close:
>> The worker can call channel.close(), which will operate normally. If the
>> PeerConnection is shut down via peerconnection.close(), or if the
>> RTCDataChannel m=application line is renegotiated 'off', then the worker
>> will receive a close event for the channel, as normal.
>> 
>> An RTCDataChannel may be transferred at any time, and may be transferred
>> more than once.
>> 
>> ToDo: write a PR for the spec.  I believe this will be a fairly small
>> change to the spec itself (and we've been indicating we want it), so I'd
>> like to have this in 1.0.
> 
> This may be a rather small addition, but experience tells us that what 
> seems small at the surface often has a lot of details that are not 
> trivial to sort out.
> 
> Before the Seattle/Redmond meeting agreed that we would use the meeting 
> to decide what is in and out of 1.0, and we agreed that for a new 
> feature to be under consideration for being "in" there would have to be 
> a concrete proposal on the table before the meeting.
> 
> For "DataChannels in Workers" there was not proposal before the meeting, 
> and it was not discussed during the meeting.
> 
> For these reasons we think that it should not be part of 1.0. We like 
> the idea, and encourage working further on it to learn more (and ideally 
> gain both implementer and user experience), perhaps as a separate 
> document describing an extension to 1.0.
> 
> Stefan for the chairs