tl;dr webrtc-explorer is a Chord inspired, P2P Network Routing Overlay designed for the Web platform (browsers), using WebRTC as its layer of transport between peers and WebSockets for the exchange of signalling data (setting up a connection and NAT traversal). Essentially, webrtc-explorer enables your peers (browsers) to communicate between each other without the need to have a server to be the mediator.

Usage

Install

> npm install webrtc-explorer

If you want to use the Signalling Server that comes with webrtc-explorer, you can use it through your terminal after installing webrtc-explorer globally

> npm install webrtc-explorer --global
# ...
> sig-server
Signalling Server Started
# now the signalling server is running

Use browserify to load transpile your JS code that uses webrtc-explorer, so that all of the dependencies are correctly loaded.

API

const explorer = require('webrtc-explorer')

listen

Connects your explorer node to the signalling server, and listens for incomming connections from other peers.

const listener = explorer.createListener((socket) => {
  // socket with another peer
})

listener.listen((err) => {
  if (err) {
    return console.log('Error listening:', err)
  }
  console.log('explorer is now listining to incomming connections')
})

dial

Dials into another peer, using the P2P Overlay Routing.

const socket = explorer.dial(<peerId> [, <readyCallback>])

Note: since an explorer node routes messages for other peers and itself, it needs first to be ready to 'listen', in order to be able to use the network to send.

updateFinger

not implemented yet

updates a finger on the finger table (if no finger was present on that row, it is added).

explorer.updateFinger(<row>)

updateFingerTable

not implemented yet

updates all the rows on the finger table that already had a peer

explorer.updateFingerTable(<row>)

Architecture

Signalling

Currently signalling is performed through a central server. The signalling throught the Chord routing is under development.

Routing

To understand fully webrtc-explorer's core, it is important to be familiar with the [Chord][chord-paper].

I've delivered a talk before about an earlier version of webrtc-explorer, where I explain the routing scheme, you can find it here: https://youtu.be/fNQGGGE__zI?t=13m33s

Connection State

Connections in webrtc-explorer are very similar to typical network socket. Before going to the network, the messages are encasulated with srcId and dstId so that they be routed through the Chord routing (parallel to the encasulation with TCP headers, IP headers, etc)

Notes and other properties

• Ids have 48 bits (so that is a multiple of 4 (for hex notation) and doesn't require importing a big-num lib to handle over 53 bits operations)
• The number of fingers of each peer is flexible, however it is recommended to not pass 16 per node (due to browser resource constraints)
• Each peer is responsible for a segment of the hash ring

Initial Development and release was supported by INESC-ID (circa Mar 2015)

David Dias MSc in Peer-to-Peer Networks by Technical University of Lisbon

This work was developed by David Dias with supervision by Luís Veiga, all in INESC-ID Lisboa (Distributed Systems Group), Instituto Superior Técnico, Universidade de Lisboa, with the support of Fundação para a Ciência e Tecnologia.

More info on the team's work at:

• http://daviddias.me
• http://www.gsd.inesc-id.pt/~lveiga

If you use this project, please acknowledge it in your work by referencing the following document:

David Dias and Luís Veiga. browserCloud.js A federated community cloud served by a P2P overlay network on top of the web platform. INESC-ID Tec. Rep. 14/2015, Apr. 2015