WebRTC data channels are in a strange state where many people are excited about them, but are not sure how to approach them due to their currently volatile nature. The standard has been rapidly changing, leaving many of the examples and resources regarding WebRTC outdated or incomplete. Unfortunately, a developer looking to get started with WebRTC data channels can be having a pretty bad time right now.
Data channels have especially been shadowed by the audio and video capabilities of WebRTC. Many documentation pages and tutorials feature incomplete examples, with the full demos being too complex to easily follow and understand. This article will approach WebRTC from the data channel only view.
So, in the spirit of supporting development, here is a complete example of working WebRTC data channels with the latest Google Chrome, version 43 (demo below).
The best way to show this is with a demo. Open up this link in two separate tabs (or computers!) in Google Chrome, and enter the same unique shared key into each prompt box. If you have your developer console open, you should see a number of debug messages as the WebRTC handshake is done through the signalling channel, and eventually initiated. The message that is sent by the other peer will be displayed on the page!
For those of you not able to run the demo, you would have seen something like this:
The Signalling Server
This demo uses Firebase as the signalling server. While WebRTC is direct peer-to-peer communication, it requires a centralized server to handle the initial delegation of the two peers. There needs to be a 3rd party that helps the two peer-to-peer clients preform the WebRTC handshake. In this case, we have used Firebase. You can use WebSockets, HTTP calls, or anything else that you’d like. Firebase works nicely for this so we’ve used it here.
Using a shared key
The shared key referred to in the code above, that’s the text phrase you type in to the prompt when you load the page, is how the two clients find each other. Numerous peers connect to the Firebase instance, so we need a way of determining who is trying to connect to who. Our ‘shared key’ is used for this, but theoretically you could use anything such as a username or URL query parameter. If your signalling server is more intelligent, you can remove the shared key / announcement channel concept entirely by having the signalling server only send messages to the appropriate peers.
Extending this demo
This demo doesn’t support Firefox, as they use a slightly different syntax for some of the operations. It’s not hard at all to add this in, however! There are actually very few subtle differences if you need to support both Chrome and Firefox. You can check out more information on the WebRTC website.
Data channels are awesome, and exceptionally easy to use once you have managed to actually set them up. As the web has been slightly void of useful information, hopefully this will provide a starting reference point for someone who is looking to build WebRTC support into their latest pet project!