DataChannels in Workers

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.

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

Received on Friday, 25 September 2015 15:57:55 UTC