tl;dr
webrtc-exploreris 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.
> npm install webrtc-explorerIf 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 runningUse browserify to load transpile your JS code that uses webrtc-explorer, so that all of the dependencies are correctly loaded.
const explorer = require('webrtc-explorer')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')
})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.
not implemented yet
updates a finger on the finger table (if no finger was present on that row, it is added).
explorer.updateFinger(<row>)not implemented yet
updates all the rows on the finger table that already had a peer
explorer.updateFingerTable(<row>)
Currently signalling is performed through a central server. The signalling throught the Chord routing is under development.
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
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)
- 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
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:
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
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent