Webrtc-pc: Add support for WebRTC Data Channel in Workers

[feross]

Proposal

Support WebRTC Data Channel in Workers (WebWorker, ServiceWorker, etc.)

WebRTC DataChannel is basically a drop-in replacement for WebSocket, except it's peer-to-peer. For all the same reasons that WebSocket was added to the Worker spec, we should add WebRTC DataChannel.

Use Cases

DataChannel in a ServiceWorker would support the use case of "peer assisted delivery" a la WebTorrent, CDN/P2P CDN video streaming delivery, file transfer, etc.

DataChannel in a WebWorker would support offloading CPU intensive data transfer/processing to another thread.

What about security?

Using WebRTC data channels in a worker is no different from a security/privacy perspective than using WebSocket. There's no user permission prompt to open a WebRTC data channel.

[silverbucket]

+1

[feross]

Another use case for using WebRTC in a SharedWorker is a DHT, a decentralized/distributed lookup service (similar to a hash table). Useful for routing to nodes in decentralized applications.

[dennismartensson]

This would be fantastic! It will really make the WebRTC Data Channel even more powerful.

[stefhak]

Hi! You should push for this feature on the WebRTC WG's mailing list, public-webrtc _at_ w3.org.
That is where the community discuss and decide on added functionality and features.

[gaperik]

Hi.
+1 to Stefans comment. Bringing it to the W3C WebRTC-list will make it more likely we'll see some work on it in a not-to-distant future. Of course, pushing for features in Chrome, FF and Edge developer communities never hurts (https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer), :-).

[feross]

I made a proposal on the mailing list: https://lists.w3.org/Archives/Public/public-webrtc/2015May/0157.html

[feross]

Here are the relevant issues in the various developer communities:

• Chrome webrtc.org
• Firefox
• Microsoft Edge

[shumy]

+11 Access WebRTC API in Workers and support transfer of MediaStream objects through the Message API.

[stefhak]

Given the process on how to determine what is in/out of 1.0 (https://lists.w3.org/Archives/Public/public-webrtc/2015Jul/0060.html) the best thing to do if you'd like to see this feature is probably to create a pull request and try to get some discussion around it.

[shumy]

From the answers, it seems like you have to change the WebRTC API ??
Don't change anything, just extend the availability of WebRTC API on Workers.

[kulicuu]

+1

[pashoo2]

+1

[vsantosu]

+1

[stefhak]

This was discussed at the WebRTC WG meeting during TPAC, and it was decided to add this functionality pending a security review. That security review has been done, and there are active PRs ( #317 and #445 ). However, more work is needed on those PRs.

[silverbucket]

Great news! +1

On Fri, Jan 8, 2016 at 7:42 AM stefan hakansson [email protected]
wrote:

This was discussed at the WebRTC WG meeting during TPAC, and it was
decided to add this functionality pending a security review. That security
review has been done, and there are active PRs ( #317
https://github.com/w3c/webrtc-pc/pull/317 and #445
https://github.com/w3c/webrtc-pc/pull/445 ). However, more work is
needed on those PRs.

—
Reply to this email directly or view it on GitHub
https://github.com/w3c/webrtc-pc/issues/230#issuecomment-169988229.

[feross]

Excellent news. Very much looking forward to this!

[stefhak]

The PRs ( #317 and #445 ) have issues/are incomplete. Anyone that is interested/willing to contribute to improve them?

[alvestrand]

Based on the silence, marking this LATER (beyond 1.0).

[eligrey]

Absolutely +1!

[alvestrand]

Closing with intent to reopen "later".

[interfect]

Is it "later" yet?

There are some really cool tricks one would be able to do with, say, ipfs/js-ipfs and a ServiceWorker, to serve assets from the IPFS network and have them appear to the page like normal HTTP-based assets. Currently you have to figure out how to connect a NodeJS-style stream to, say, an <img> tag. Browsers already know how to connect a stream to a tag, and it would be really useful to be able to use that functionality for streams that come in from peers.

[alvestrand]

No, "later" is after webrtc-pc has gone to CR.
If you want to pursue the change as a separate document (with intent to merge), feel free to write up a draft. It turned out in discussion to be non-trivial in its implications (both spec and implementation).

[davux]

@alvestrand, that's very summed up. Would you share a pointer to that discussion and/or maybe a more descriptive summary?
Thanks!

[ya7ya]

Hello, Has there been any progress on this ? I looked at the mailing list but I couldn't find the aforementioned discussion.

[lgrahl]

I believe this can (and should) be reopened now.

[benjamingr]

As a large consumer of DataChannels We would be willing to provide feedback and work with relevant parties in order to help make this happen.

I see a big net positive for users here.

[v0l]

+1 this would be a very nice way to implement P2P CDN, many websites could make great use of this!

[lgrahl]

To everyone interested: I assume you will reach a broader audience if you write to the mailing list [email protected] (not all of them are following GH issues) that we want to reopen the discussion on worker support for data channels. I will support this intention.

[isaackwan]

Stupid question - why is creating RTCPeerConnection from workers not considered? What's the threat model here?

Workers can get SDP from other methods, such as fetch() from servers, no?

This allows, for example, ServiceWorkers that enables P2P delivery.

In contrast to other solutions, this eliminates the need of: atomic transfer of ownership of DataChannel etc, cross-scope events, etc.

If transferring ownership of DataChannel or even PeerConnection is desired, downstream users (aka applications) can build their own signaling to ensure atomic cutover.

One legit concern is Identity Provider may fail to allow user logins. However, given that this function even is not implemented in Chrome, I guess we might just as well restrict (=do not expose) related APIs to PeerConnections in worker scopes.

[feross]

The WebRTC working group is soliciting use cases for the next version of WebRTC. I just posted my suggestions to the mailing list. If you have an interest in making the next version of WebRTC better-suited to supporting DHTs or other peer-to-peer use cases, then now is the time to make your voice heard.

The mailing list is here: https://lists.w3.org/Archives/Public/public-webrtc/

Here is what I posted:

Here are my use cases for the next version of WebRTC:

Peer-assisted delivery.

• See products from companies like PeerCDN (my company, sold to Yahoo), Peer5, and Streamroot. See open source projects like WebTorrent, PeerTube, etc.
• All of these products would benefit from being able to use a ServiceWorker to intercept HTTP requests and then handle them via a WebRTC Data Channel instead. Currently, this requires creating the Data Channel in the main window and shuttling data back-and-forth between the main window and the ServiceWorker. If we add support for WebRTC Data Channel in Workers (see https://github.com/w3c/webrtc-pc/issues/230) then these use cases become a lot easier to support. Less data copying, simpler architecture, better battery life, etc.

Distributed Hash Tables (DHTs).

• DHTs are decentralized distributed systems that provide a lookup service similar to a hash table. DHTs are useful for finding peers without a central signaling infrastructure, and they're used in almost every widely-deployed peer-to-peer system, including BitTorrent, Bitcoin, IPFS, Dat, etc.
• With the current WebRTC connection model, DHTs are nearly impossible to build. We need the ability to store the "contact information" for a peer, close the connection to that peer, and then re-connect to that peer at some point in the future (if they're still online). With TCP/UDP, this is quite easy to accomplish. Simply store the ip:port (12.34.56.78:9000) and try to connect. If the peer is still online, it will just work.
• Peers need the ability to "listen" for incoming connections. Peers also need the ability to publish a "reusable SDP" that multiple peers can use to connect to listening peers (currently an SDP is usable only once)

Lighter-weight connections.

• It seems that the current WebRTC spec is very complex (or perhaps currently implementations are still immature). But this leads to a situation where it's really hard to open more than a dozen connections at once without the browser process hitting 100% CPU utilization. This prevents applications that would like to open 20+ connections from doing so, which makes Data Channels a lot less useful for use cases like peer-assisted delivery, peer-assisted live streaming, WebTorrent, DHTs, in-browser cryptocurrency networks, etc.

[alvestrand]

Removed the LATER label since this is under active consideration.
Note that the PRs #317 and #445 remain closed, even though I removed the LATER label; the submitters should consider whether it makes sense to rebase them and anwer the issues raised in the PRs or start over.

[nkev]

Creating a browser "refresh resistant" WebRTC data channel in a shared worker could potentially change the way web apps are built forever! It's a shame not much has happened here in over 3 years...

[jimmywarting]

It have been quiet for a while now, haven't heard anything new. Some related PR/issues have been closed. So I got some few question.

• Won't service worker get webrtc support?
• What is blocking? is there any other related issues/PR i can follow?
  > No, "later" is after webrtc-pc has gone to CR.
• Has webrtc-pc gone to CR yet?

[benjamingr]

What is blocking? is there any other related issues/PR i can follow?

Someone actually doing the work and putting in the time and work to spec and then write support for workers.

[aboba]

@jimmywarting @benjamingr The "work" would probably involve implementing the RTCDtlsTransport and RTCDataChannel interfaces from ORTC, in addition to WebRTC-ICE which had an Origin Trial in Chrome last Spring along with WebRTC-QUIC.

The big question is whether there is enough motivation for browser vendors to support RTDataChannel in workers, as opposed to RTCQuicTransport in workers. WebTransport API seems to be garnering interest, the existing WebRTC data channel not so much.

[lgrahl]

WebTransport API seems to be garnering interest [of browser vendors], the existing WebRTC data channel not so much.

Maybe they should focus more on improving what people are actually "stuck with" using right now? Just a thought...

[subins2000]

I was excited today to move the WebTorrent part of my app to a worker for increased performance, but then I saw this issue, a big letdown :/

It's a shame that even after 5 years, this hasn't been implemented :(

[benjamingr]

It's a shame that even after 5 years, this hasn't been implemented :(

You have several options for recourse:

• Put in the work and implement this feature yourself.
• You can pay for it to be implemented for you by another company.
• You can find compelling use cases to get other people to do either of the above two things.

[interfect]

An implementation of a fix to this issue would be making just RTCDataChannel available in just (ordinary, Web, non-Service) Workers, right? Along the lines of #317 or #445, you would be able to send an already open RTCDataChannel to a Web Worker, but a Web Worker would not be able to open any new connections (because of not having RTCPeerConnection) and a Service Worker wouldn't be able to use either. (As pointed out here by @martinthomson, a Service Worker is supposed to only be spun up for a few seconds at a time to handle a request, and giving it a peer to peer connection causes trouble with that model that people did not want to solve at the time.)

I'm not sure a fix to this issue would then really provide what @jimmywarting, @nkev, and others are asking for, which is a way to host a useful peer-to-peer node in a browser in the background (or at least independent of any single tab), in a context where it can idiomatically service requests.

I'm going to open an issue to track providing the whole WebRTC API to all types of workers (including Service Workers) in a way that is useful for p2p content distribution but which doesn't buy you infinite service worker runtime for every site the user ever visits. Actually fixing that bigger issue is where a lot of the hardness is, it seems, and probably shouldn't block a fix for this issue for whoever actually needs exactly the functionality of shipping an RTCDataChannel specifically to a Web Worker specifically.

[nkev]

@interfect Thank you for the useful response and not dismissing this with "build it yourself or pay someone else to build it".

[interfect]

@nkev I'm not actually one of the actual spec group project members either; I want this feature for my use case too. But I can see how it can get on their nerves to have people showing up periodically asking why their pet issue isn't ready yet, so I decided to try to grab a metaphorical shovel to the extent that I can.

Where we might still get stuck is browser implementations. I'm pretty sure I can fiddle with a spec document, but I'm not really a qualified browser dev and even if I were I have no leverage to get an implementation merged. I'm hoping some actual browser devs will come by and implement it for me (which might go better if this is attached to the next version of WebRTC like @alvestrand suggested, which is going to need implementing anyway).

[guest271314]

Can self or globalThis be substituted for all references to window and import() or importScripts() be substituted for document within https://github.com/rustwasm/wasm-bindgen/tree/master/examples/webrtc_datachannel to be able to use the Rust wasm-bindgen version of RTCDataChannel https://rustwasm.github.io/wasm-bindgen/examples/webrtc_datachannel.html in Worker?

All the logs at https://rustwasm.github.io/wasm-bindgen/exbuild/webrtc_datachannel/ are on line 333 in index_bg.js:333.

[guest271314]

@lgrahl FWIW QuicTransport https://github.com/GoogleChrome/samples/blob/gh-pages/quictransport/quic_transport_server.py is defined Worker at Chromium 87.

[lgrahl]

Linking https://github.com/w3c/webrtc-extensions/issues/64
It's time to recite your use cases. At least those that would work with that design. :slightly_smiling_face: