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

Re: WebRTC NV Use Cases

From: William Hilton <wmhilton@gmail.com>
Date: Sun, 10 Jun 2018 23:24:34 -0400
Message-ID: <5b1deb6b.1c69fb81.624cf.75a4@mx.google.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
I just want to second everything that @feross just said. The browser needs
a way to:
  - persist peer connections and
  - periodically ping them to maintain an up-to-date list of peers.

If it worked in Service Workers, then it would work similarly to Web Push
Event API – a quick blast of data from a peer, maybe to notify that there
is new content, and it could decide whether to establish a full connection
and download that content now, or simply acknowledge the message, or 
present a Push Notification to the user.

William Hilton
@wmhilton on github and twitter
Author of Isomorphic-Git

> 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.
> Feross
> I write at feross.org and tweet as @feross <https://twitter.com/feross>.
> I work on WebTorrent <https://webtorrent.io/>, Standard
> <https://standardjs.com/>, and Study Notes <https://www.apstudynotes.org/>.

Sent from Mail for Windows 10
Received on Monday, 11 June 2018 19:20:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC