W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2015

Re: DataChannels in Workers

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 25 Sep 2015 10:56:03 -0700
Message-ID: <CABkgnnVbmtsdGqvzq+Yy9T-xyPtt=A69yb9kU8iY7EC=ywrmeQ@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I think that this is a good idea.

The primary change [Transferable] might be easy to do, but I think
that we will want some security considerations.  Transferring a socket
to another origin using postMessage() is a non-trivial thing to reason

That said, I think that it's perfectly fine: an origin could easily
accept the messages and forward them individually using postMessage().

On 25 September 2015 at 08:54, Randell Jesup <randell-ietf@jesup.org> 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.
> --
> 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 17:56:31 UTC

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