W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2018

Re: [webrtc-pc] Add support for WebRTC Data Channel in Workers

From: Feross Aboukhadijeh via GitHub <sysbot+gh@w3.org>
Date: Wed, 23 May 2018 00:23:35 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-391181990-1527035013-sysbot+gh@w3.org>
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 ( 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.

GitHub Notification of comment by feross
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/230#issuecomment-391181990 using your GitHub account
Received on Wednesday, 23 May 2018 00:23:40 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:44 UTC