A Peer-to-Peer Live Video Streaming Library built on WebTorrent
---------------------------------------------------------------

#### _Intro_

We built [Nile.js](http://nilejs.com/), a peer-to-peer live video streaming library designed to handle scaling. Our library uses [WebTorrent](https://webtorrent.io/), a distributed file delivery protocol inspired by [BitTorrent](http://www.bittorrent.com/) and built with [WebRTC](https://webrtc.org/). We chose WebTorrent as our means of broadcasting the stream because video streams can get progressively stronger as more peers join the stream. This also makes it a better fit than implementing typical WebRTC peer connections due to the approximately 10 to 20 connection limit per peer that WebTorrent has been able to mitigate.

#### _How we use WebTorrent to stream_

First, torrent files used by WebTorrent are immutable, making it less than ideal for live streaming. To emulate streaming, we take the video stream and split it into clips that are distributed to viewers through their own generated torrent files.

Once the WebTorrent client begins to seed, a magnet link (an identifier in the form of a string) is generated. We propagate the magnet to the viewing peers through a series of WebSocket and WebRTC connections. The magnet is first passed to a Node/Express server which is connected to a limited number of WebSockets. The server emits the magnet to the initial WebSocket connections which pass the magnet along through WebRTC peers in a linked list structure. After receiving the magnet, each viewer client will begin to leech (download) and seed (upload) the stream.

![](https://hackernoon.com/hn-images/0*WP-Bd9KkPRCiPY1m.)

Distributed Video Streaming via WebTorrent

#### _Considerations_

Because of the linked list structure of our WebSocket to WebRTC connection, if a peer disconnects, the chain would be broken. Our library is designed to automatically reconnect on service disruptions. The disconnected webRTC peer will open a WebSocket connection with server, where it will be reassigned to a new WebSocket peer.

If there are only a few peers viewing the stream, initial upload speed is highly dependent on the broadcaster’s bandwidth and network speed, creating a major bottleneck. To offset this poor initial performance, we allowed the broadcaster enough time to send each peer enough data to view without missing a second. From this experience, we further acknowledge the effectiveness of combining peer-to-peer delivery with a CDN, a la [Peer5](https://peer5.com/), to handle the spectrum of low to high numbers of viewers.

#### _Problems_

As we rack up the number WebTorrent seeds on the broadcaster side, there seems to be a client side memory leak which eventually causes the browser to crash. We’ve checked the CPU and memory usage but have found no error messages or anomalies.

Unsuccessful approaches that we have taken to solve the issue:

*   Server side seeding in place of client side seeding
*   Seeding with Web Workers
*   Seeding in iframes
*   Destroying WebTorrent client on each new seed
*   Destroying WebTorrent file on each new seed

One solution that we have found, is browser specific. If using Chrome Canary to test the library, it seems to run indefinitely. If anyone in the open source community is able to provide some insight, please make a pull request on our [GitHub](https://github.com/gitsummore/nile.js) repo.

#### _Conclusion_

As a proof of concept, we would like other developers to try our library and leave feedback on how we can improve the project or even build upon it. Come check us out at [our website](http://nilejs.com), [GitHub](https://github.com/gitsummore/nile.js) and [npm](https://www.npmjs.com/package/nile.js).

_Nile.js is_ [_Derek Miranda_](https://medium.com/@derekmiranda)_,_ [_Kevin Qiu_](https://medium.com/@kami.kevinq)_, and_ [_Justin Pierson_](https://medium.com/@jpmitchellpierson)_._

Introducing Nile.js

Too Long; Didn't Read

Company Mentioned

Coins Mentioned

@nile.js.webrtc

RELATED STORIES