Signaling between client end points has always been an important facet for most interactive web applications. The use cases range from text chatting to multiplayer games to driving a robot remotely. In the world of HTML5, most developers establish signaling through websockets, long polling and server side events. However with the advent of WebRTC, data channels joined the ranks and the question posed by many developers is “Where do data channels fit in the equation?”
Data Channels provide a way to send binary / text data to another peer over the browser. The data channel api is very similar to web sockets when it comes to sending different types of data. It works peer to peer without the need of a centralized server or an additional hop in most cases.
The WebRTC draft specifies 2 types of data channels:
Unreliable Data Channels: These are the lossy, out of order message delivery with no guarantee of delivery. The unreliability although also makes them faster.
Reliable data channels: These have in order guaranteed delivery. These are slower than the unreliable data channels since in case of packet losses, we have to wait for retransmissions before delivering the other messages as well.
Currently data channels are supported in Google Chrome, Firefox & Opera.
Certain use cases like multi player real-time gaming application or driving a robot need a fast signaling channel to sync the game state between players or notify the robot position back to the user. In both of those use cases, latency is more important than reliability of the messages. Certainly not having a server between the end points reduces the latency and the speed of the unreliable data channels can make the experience much better for the players in the game and the robot driver.
Also in the cases where privacy / security is of the utmost importance, using Data Channels might make more sense. This is because data is exchanged directly between the peers and there is no entity that can intercept those messages and decrypt them. In the world of web sockets this is a difficult problem to tackle since the distribution is done through the server.
Although data channels work in the above situations really well, that is not always the case. It comes with a bunch of caveats:
1. Data Channel Establishment:
You need a signaling server to coordinate the establishment of the data channel between the peers. This signaling mode has to use one of the existing solutions like JSON + websockets.
2. NAT traversals / TURN servers
In the world of WebRTC, peer connections might not always be able to establish a direct connection based on the NAT they are behind and in those cases they need to use a TURN server to relay the packets. In such cases, the advantages of low latency due to no server in the middle go down the drain. Also your dream of not having to host a server infrastructure will be shattered in those cases unless you don’t care about connectivity between end users.
3. Browser Support
Today a lot more browsers including IE & Safari support web sockets and XHR requests to exchange data between peers compared to data channels.
4. Broadcast Scenario
The cases where the number of participants in the use case go beyond 2, you are faced with the same solution as in the world of websockets – Add a centralized server to relay the messages. Although this might not be always true, in the cases where the requirement is to send large messages frequently to the other peers, at some point the user upload bandwidth might not be sufficient and might start becoming the bottleneck to sending the messages in time.
5. Viability of current solutions
Some of the use cases like text chat / notifications are already solved successfully by a lot of providers using existing solutions like web sockets and there is very little motivation to move away from existing solutions to start using data channels, more so with the caveats above.
Given all the pros and cons, you can see how data channels play a small role in satisfying the needs that exist in the signaling ecosystem.