Leveraging WebRTC for P2P Content Distribution

in Web Browsers

Christian Vogt, Max Jonas Werner, Thomas C. Schmidt

Department of Computer Science
Hamburg University of Applied Sciences, Hamburg, Germany
[email protected], [email protected], [email protected]

I. I NTRODUCTION 2) Message exchange: Figure 1 demonstrates the exchange

of a message between client 1 and client 3. Here, client 1
WebRTC enables web applications to establish a direct sends a message via the Data Channel to client 2 indicating
communication channel between two browsers without relay- the sender (client 1) and receiver (client 3). Our approach
ing the data through a web server. It consists of an API [1] is designed so that client 2 forwards all messages dedicated
defined by the W3C and a set of underlying protocols defined to other peers via a routing layer to the designated receiver.
by the IETF Rtcweb Working Group [2]. The possibility of Messages that are meant for client 2 itself are passed to the
establishing peer-to-peer channels between two browsers and local application layer on client 2.
the expected broad deployment opens the opportunity for new
use cases that were not possible until now.
Server
In this demo, we present a distributed content sharing
facility using WebRTC Data Channels as well as an emulation

WebSocket
component for test and measurement purposes. This library
provides an API for applications to store content in and retrieve
content from the underlying DHT; it can be used as a drop-in Data Channel Data Channel
for existing web applications. The integration of WebRTC into Peer 1 Peer 2 Peer 3
a majority of browsers on the market can immediately deliver
the benefits of such an approach to a huge user base, without
the need of installing any additional software.
1 2

II. A RCHITECTURE
The architecture proposed in this paper consists of two 3
main components: a bootstrap server that serves as a central
instance for joining the P2P network and the peers (made up
Fig. 1. Client 1 wants to communicate with client 3. Therefore it sends the
of the userss browsers) forming the actual network. data via the open Data Channel to client 2 which in turn routes it to client 3.
The server is not involved in this process at all.
The implementation is based on the built-in capabilities
of web browsers, leveraging the WebRTC API. So called Data 3) Layered approach: To enable the functionality explained
Channels [3] allow for the transfer of generic data (text, binary above we used a layered approach similar to that proposed by
data) in a P2P manner. Point-to-Point Data Channels comprise Dabek et al. in [4]. Figure 2 shows the different layers and
the main transfer mechanism used to build the P2P system APIs. The central component called PeerManager provides
described in this paper. On top of these Data Channels we an API to applications that would like to make use of the P2P
implemented a protocol used for joining the WebRTC network network. Underneath the PeerManager lies a routing layer that
and for maintaining connections between clients. can also be implemented in different ways, later allowing us
to form a structured Peer-to-Peer overlay like Chord [5].
A. Functionality Our next step is to concretize the components APIs to be
1) Join: Clients join the P2P network by establishing a able to assemble the three layers from Figure 2 into a working
WebSocket connection to a bootstrap server that holds a solution. Using a structured P2P system like Chord we are
connection to a certain number of peers that have recently planning to achieve our goal of implementing a pure browser-
joined the network. Afterwards this WebSocket connection is based P2P network that allows us to investigate possibilities of
used to signal the WebRTC handshake, resulting in a direct running information-centric networking components on top.
WebRTC connection between the newly joined client and one
B. P2P mechanisms
of the other clients, forming a mesh of peers. Once a client has
joined the network it may disconnect from the server without P2P systems can be classified by two main categories: Un-
losing the capability of transferring data to/from other peers. structured and Structured systems. Unstructured P2P systems
978-1-4799-1270-4/13/$31.00 2013
c IEEE
 Peer 1 Peer 2
Application Application fetched via JavaScript from one of the participating peers using
the proposed mechanism. Similar approaches are pursued by
PeerManager API PeerManager API PeerCDN1 and SwarmCDN2 .
PeerManager PeerManager
IV. C ONCLUSION /F UTURE W ORK
Routing API Routing API
Our current experience researching on WebRTC and con-
WebRTC WebRTC
Routing Routing
tent distribution in combination with Peer-to-Peer networking
leaves us confident that a deeper exploration of the possibilities
provided is well worth it. We have already planned next
Fig. 2. Our layered approach mimics the proposal towards a common API steps with regards to the implementation of the proposed
for P2P networks by Dabek et al. [5]. component layers especially building a working DHT-based
CDN prototype on top of WebRTC as well as investigating
possible overlapping issues of browser-based P2P networks
use a flooding-based approach or a centralized component for
and information-centric networking [8].
lookup and management purposes. In contrast to unstructured
P2P systems, structured P2P systems can achieve logarithmic Topics that are to be investigated more thoroughly with
scalability in search and lookup complexity without requiring regards to WebRTC are those of security and privacy of users.
any central component. Therefore, we concentrate our work on We will further cover these as part of our ongoing research and
implementing a structured P2P system based on a distributed implementation efforts. The current specification drafts already
hash table (DHT). Such a DHT (like Chord or CAN) will be cover a wide range of these aspects, especially focussing on
the foundation of the routing layer mentioned above. end-to-end encryption and peer authentication.
Since both W3C/IETF as well as browser vendors have not
C. Demonstration agreed on a final specification the APIs and protocols used are
In our demonstration we will show the following compo- very much in flow. This could lead to problems especially
nents: A working server component which acts as bootstrap when trying to lead our implementation to a consistent state
for newly joined nodes and takes care of assigning node IDs. that can be used productively. We are intensely watching the
Moreover weve developed a rough client-side application that ongoing research activities by W3C and IETF as well as the
implements the PeerManager component from Figure 2. We browser vendors implementations.
will show how different browsers join the P2P network and
may establish connections to each other even after shutting R EFERENCES
down the signaling server. [1] A. Bergkvist, D. C. Burnett, C. Jennings, and A. Narayanan, WebRTC
For test and measurement purposes, we also developed an 1.0: Real-time Communication Between Browsers, W3C, W3C Editors
Draft, Jun. 2013.
emulation component that uses Node.js and the WebRTC im-
[2] H. Alvestrand, Overview: Real Time Protocols for Brower-based Ap-
plementation contained in the Libjngle library. This emulation plications, IETF, Internet-Draft work in progress 01, June 2011.
is able to run all of the client code written in JavaScript so that [3] R. Jesup, S. Loreto, and M. Tuexen, RTCWeb Data Channels, IETF,
we can conduct functionality and performance tests as well as Internet-Draft work in progress 04, February 2013.
measurements. The status of this emulation layer will also be [4] F. Dabek, B. Y. Zhao, P. Druschel, J. Kubiatowicz, and I. Stoica,
demonstrated. Towards a Common API for Structured Peer-to-Peer Overlays, in
Peer-to-Peer Systems II, Second International Workshop, IPTPS 2003,
Berkeley, CA, USA, February 21-22, 2003, Revised Papers, ser. LNCS,
III. R ELATED WORK M. F. Kaashoek and I. Stoica, Eds., vol. 2735. Berlin Heidelberg:
Research on leveraging native browser technologies SpringerVerlag, 2003, pp. 3344.
each achieving a different set of goals is already being [5] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan,
Chord: A scalable peer-to-peer lookup service for internet applications,
conducted: [6] examines a way to distribute the load and in SIGCOMM 01: Proceedings of the 2001 conference on Applications,
stream video content between browsers using WebRTC, thus technologies, architectures, and protocols for computer communications.
reducing the bandwidth cost of content providers. The author New York, NY, USA: ACM Press, 2001, pp. 149160.
uses a BitTorrent-like architecture involving a tracking server [6] A. J. Meyn, Browser to Browser Media Streaming with HTML5,
for discovering content. Masters thesis, Technical University of Denmark, DTU Informatics, E-
mail: [email protected], Asmussens Alle, Building 305, DK-2800
Zhang et al. describe the implementation of a browser- Kgs. Lyngby, Denmark, 2012.
based CDN in [7]. The authors have researched on the pos- [7] L. Zhang, F. Zhou, A. Mislove, and R. Sundaram, Maygh: building a
sibilities of building such a CDN service using the Flash cdn from client web browsers, in Proceedings of the 8th ACM European
plugin by Adobe. Their implementation is centered around Conference on Computer Systems, ser. EuroSys 13. New York, NY,
USA: ACM, 2013, pp. 281294.
a coordinator that holds mappings between peers and the
[8] C. Vogt, M. J. Werner, and T. C. Schmidt, Content-centric User
data stored on these peers. Web site owners eager to use Networks: WebRTC as a Path to Name-based Publishing, in 21st
this solution have to modify the sites HTML code so that IEEE Intern. Conf. on Network Protocols (ICNP 2013), PhD Forum.
every asset that shall be distributed in the P2P network is Piscataway, NJ, USA: IEEEPress, Oct. 2013, accepted for publication.

1 http://www.peercdn.com
2 http://www.swarmcdn.com