Introducing PeerConnect
A Peer 2 Peer Content Distribution Network powered by WebRTC and WebTorrent
Intro
As applications scale and grow in users, the answer has always been to buy more server/computing space. This is one option, but why rely solely on one centralized point? Along with the idea of building a more decentralized web, we built PeerConnect, a P2P Content Distribution Network, as a proof of concept idea to reduce server load by relying on the clients to host static content (videos/images). To do so, we incorporated WebRTC, a collection of protocols that provides real time communications over peer to peer connections, and WebTorrent, a distributed file delivery protocol inspired by BitTorrent and also built with WebRTC.
Why WebRTC and WebTorrent?
We chose WebRTC as a means to send static image assets between peers because it allowed us the purest peer-to-peer data transport, and because of its adoption onto most internet browsers. Furthermore, there was no need for any internal/external plugins. By using WebRTC’s built in data channel API, we were able to send image data between two peers efficiently. When we started looking at utilizing WebRTC for sharing video peer to peer, we realized 2 things. One, video files are much bigger than still images. Two, it would take too long to load an entire video from one peer. Queue drumroll for WebTorrent’s entrance.
We chose WebTorrent because it connected users together to form a distributed, decentralized browser-to-browser network for efficient video sharing. Like WebRTC, it requires no plugin and even better, as more and more individuals joined, it allowed the content being served to become faster and more resilient by utilizing the torrent protocol.
How images are transferred
To enable two peers to connect and share information through WebRTC, a signaling server is necessary to coordinate information between two peers. In our case we decided to use WebSockets to emit real time information between server and peers.
When a client, lets call him peer1, first joins without any other fellow peers, they download all image assets from the server. After downloading all image assets, they are made an initiator peer, and their “offer” is stored on the signaling server. When another client joins, they are created as a receiver peer and the offer stored in the server is sent to peer2, and peer2 responds with an “answer” that is sent to peer1. Once both peers have their respective peer information, the data channel process can begin. Peer1, sends images that have been converted to a data-url through 64K bits, chunks at a time. Peer2 receives these images and sets these images on their client. Once peer2, finishes receiving all information, the peer connection is destroyed and both peers are now available as initiators.
How videos are transferred
Unlike how images are transferred, the video P2P process does not require the signaling server. Like in the case above, when peer1 first connects, if there are no instances of available seeds (peers that hold that video information), it relies on the web seed (the video hosted on the server) to download and stream the video. As peer1 finishes downloading all video pieces on the torrent file, peer1 becomes a seeder and continues sharing information to future peers. As this continues to grow, clients rely less and less on the server for the initial web seed and relies more on other peers.
Conclusions
We strongly believe that P2P has much further room for growth and we believe it has the potential to re-decentralize the web.
As a proof of concept, we would like other developers to try it out and leave feedback on how we can improve the project or even build upon it. Come check us out at our website, GitHub and NPM.
This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
