Pure JS data channel implementation #1
Description
WebRTC let's us do browser<–>browser p2p communication.
But what about browser<–>server and server<–>server?
WebRTC everywhere
There are significant advantages to using the same transport (i.e. WebRTC) for all peer connections in a decentralized system, including:
- reduces the importance of centralized servers (they're just normal peers with excellent uptime)
- code re-use (don't need to write a TCP/UDP/WebSocket and WebRTC transport layer)
- option to use unreliable semantics (UDP-like) for browser<–>browser and browser<–>server
- free NAT hole punching (useful for desktop communications apps, which are like servers in almost all ways, except they're usually behind NATs)
Why a pure JS data channel implementation?
The data channel can be used in node.js via the wrtc module by @modeswitch. It's impressive work, but not without it's drawbacks.
It takes 25+ minutes to install on my system, and pre-built binaries are not available :(. It has to download and compile Google's libwebrtc from scratch. libwebrtc is huge! It contains libjingle, chromium's depot_tools, lots of video/audio codec stuff, and more! And there are install issues for users without a suitable compiler installed.
A pure JS implementation (relying only on node.js built-ins like dgram
and net
) would greatly simplify installation for end users.
Open questions
- Is a pure JS implementation even possible? If raw ip is required, then we'll need a module like raw-socket and we're depending on native modules again.
- What pieces are already available on npm? A quick search shows: stun and node_dtls (native).
- Would it be useful to have a mostly-JS implementation?
- Would it be useful to make a standalone c library for data channel (extracted from libwebrtc) that multiple languages could bind to? If this reduced compile time from 25 minutes to <1 minute, maybe that's enough and we don't need a pure JS implementation.
Related discussion: jbenet/random-ideas#13