Re: WebRTC NV Use Cases

There are some interesting ideas here related to DHTs that I'll add to the
uses cases discussion of the upcoming f2f.  But I have some questions which
I'll add below, more related to ICE than to PeerConnection.

On Mon, Jun 11, 2018 at 12:23 PM William Hilton <wmhilton@gmail.com> wrote:

> 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.
>
>
I think I understand what you're trying to get at.  I think what you need
is to be able to:

1.  Make ICE listen for checks on candidates other than the selected
candidate pair and even if there is no selected candidate pair.
2.  Control when ICE sends checks (turn them off and on).

This won't always work because with certain NATs/firewalls, you must have
both endpoints sending checks to each other at the same time.  But if at
least one side could keep TURN allocations alive or you could schedule
synchronized checks or you just got lucky with some peers that have
reachable ports, then it could work.

The first could be accomplished with a method like
retainLocalIceCandidate(candidate).

The second could be accomplished with a method like
.setIceFrozen(bool frozen) where "frozen" means "not sending checks".

I'll add these abilities to the discussion at the f2f.  And I'm planning on
proposing APIs like this at the f2f as well.

If these are sufficient, or if I'm missing something, please let me know.


> 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.
>
>
I'll include making data channels work in workers as a requirement along
with this use case at the f2f.


> >
>
> > 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.
>
>
 Like I mentioned above, I think a lower-level ICE control API would be
sufficient for your use case.  I'll be proposing options for such APIs at
the upcoming f2f that I think cover your use case.

>   - 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)
>
> >
>
>
These are two different things:  A.  listening and B. forking.

I'll include both in the use cases discussion and I have proposals for ICE
APIs that cover both.  But they are different things.


> > 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>