The WebRTC standard is much hyped for its ability to
facilitate browser-to-browser media connections—such as placing video
calls without the need to install a separate client application.
Relying solely on the browser is certainly one of WebRTC's strengths,
but another is the fact that the media stream is delivered directly
from one client to the other, without making a pit-stop at the
server. But direct connections are available for arbitrary binary data
streams, too, through WebRTC's RTCDataChannel. Now the first applications to take advantage of this
feature are beginning to appear, such as the Sharefest peer-to-peer
file transfer tool.
Changing the channel
WebRTC data channels are an extension to the original WebRTC
focused first on enabling two-way audio/video content delivery in
real-time. The general WebRTC framework remains the same; sessions
are set up using the WebRTC session layer, with ICE
and STUN used to
connect the endpoints across NAT. Likewise, the RTCPeerConnection
is used as a session control channel, taking care of signaling,
negotiating options, and other such miscellany. The original
justification for RTCDataChannel was that multimedia applications also
needed a conduit to simultaneously exchange ancillary information,
anything from text chat messages to real-time status updates in a
But data and real-time media are not quite the same, so WebRTC
defines a separate channel for the non-multimedia content. While
audio/video streams are delivered over Real-time Transport Protocol
(RTP), a RTCDataChannel is delivered over Stream Control Transmission
Protocol (SCTP), tunneled over UDP using Datagram TLS (DTLS). Using SCTP
enables a TCP-like reliability on top of UDP.
After all, if one video chat frame in an RTP conversation arrives too
late to be displayed, it is essentially worthless; arbitrary
binary data, however, might require retransmission or error handling.
That said, there is no reason that a web application must implement
a media stream in order to use an RTCDataChannel. The API is
deliberately similar to Web Sockets, with the obvious difference being
that the remote end of a RTCDataChannel is another browser, rather
than a server. In addition, RTCDataChannels use DTLS to encrypt the
channel by default, and SCTP provides a mechanism for congestion control.
Obviously there are other ways to send binary data from one browser
to another, but the WebRTC API should be more efficient, since the
clients can choose whatever (hopefully compact) format they wish, and
use low-overhead UDP to deliver it. At a WebRTC meetup in March,
developer Eric Zhang estimated
[SlideShare] that encoding data in
Base64 for exchange through JSON used about 37% more bandwidth than
sending straight binary data over RTCDataChannels.
Browser support for RTCDataChannels is just now rolling out.
Chrome and Chromium support the feature as of version 26 (released in
late March); Firefox currently requires a nightly build.
Sharefest is a project started by a video streaming company called
Peer5. A blog post introducing
the tool says the impetus was two coworkers who needed to share a
large file while in a coffee shop, but Dropbox took ages to transfer
the file to the remote server then back again. With RTCDataChannels, however, the transfer would be considerably faster since it
could take place entirely on the local wireless LAN. A few months
later, Sharefest was unveiled on GitHub.
The Sharefest server presents an auto-generated short-URL for each
file shared by the "uploading" (so to speak) party. When a client
browser visits the URL, the server
connects it to the uploader's browser and the uploader's browser
transfers the file over an RTCDataChannel. If multiple clients connect
from different locations, the server attempts to pair nearby clients
to each other to maximize the overall throughput; thus for a
persistent sharing session Sharefest does offer bandwidth savings for
Currently the size limit for shared files is
around 1GB, though there is an issue open to
expand this limit. A demo server is running at sharefest.me (continuing the
near-ubiquitous domination of the .me domain for web-app
demos). The server side is written in Node.js, and the entire work is
available under the Apache 2.0 license.
Naturally, only the recent versions of Chrome/Chromium and Firefox
are supported, although the code detects the browser and supplies a
friendly message illustrating the problem for unsupported browsers.
This is particularly important because the RTCDataChannel API is not yet
set in stone, and there are several pieces of WebRTC that are
implemented differently in the two browsers—not differences distinct
enough to break compatibility; mostly just varying default
Sharefest is certainly simple to use; it does require that the uploading
browser keep the Sharefest page open, but it allows straightforward
"ephemeral" file sharing in a (largely) one-to-many fashion. From the
user's perspective, probably the closest analogy would be to Eduardo
Lima's FileTea, which
we covered in 2011. But FileTea is
entirely one-to-one; Sharefest does its best to maximize efficiency
by dividing each file into "slices" that the downloading peers exchange
with each other.
This is useful, of course, but to many people the term
"peer-to-peer" effectively means BitTorrent, which is a considerably
more complex distribution model than Sharefest supports (supporting,
for example, super-seeding and distributed hash trackers). One could
implement the existing BitTorrent protocol on top of RTCDataChannels, perhaps, and pick up some nice features like DTLS encryption
along the way, but so far no one seems to have taken that challenge
and run with it.
But there are others pursuing RTCDataChannels as a file
distribution framework. Chris Ball, for example, has written a serverless
WebRTC file-sharing tool, although it still requires sharing the
STUN-derived public IP address of the uploader's machine, presumably
off-channel in an email or instant message. The PeerJS library is a project that may
evolve in the longer term to implement more pieces of the file-sharing
In the meantime, for those curious to test out the new API, Mozilla
and Google have publicized several other RTCDataChannel examples
involving games. But as Zhang noted in his presentation, direct
client-to-client data transfer is likely to have more far-reaching
effects than that: people are likely to write libraries for file I/O,
database drivers, persistent memory, etc. The potential is there for
many assumptions about the web's client-server nature to be broken for
to post comments)