Smart energy efficient gateway for Internet of mobile things
Adaptive Switching of Traffic between WebRTC and WebSocket Status of Portable Devices A Semantic Engine for Internet of Things: Cloud, Mobile Devices and Gateways
This thesis project explores two well-known real-time web technologies:
WebSocket and WebRTC. It explores the use of a mobile phone as a gateway
to connect wireless devices with short range of radio links to the Internet in order
to foster an Internet of Things (IoT).
This thesis project aims to solve the problem of how to collect real-time data
from an IoT device, using the Earl toolkit. With this thesis project an Earl device is
able to send real-time data to Internet connected devices and to other Earl devices
via a mobile phone acting as a gateway. This thesis project facilitates the use of
Earl in design projects for IoT devices.
IoT enables communication with many different kinds of “things” such as cars,
fridges, refrigerators, light bulbs, etc. The beneﬁts of IoT range from ﬁnancial
savings due to saving energy to monitoring the heart activity of a patient with
heart problems. There are many approaches to connect devices in order to create
an IoT. One of these approaches is to use a mobile phone as a gateway, i.e., to act
as a router, between IoT and the Internet.
The WebSocket protocol provides efﬁcient communication sessions between
web servers and clients by reducing communication overhead. The WebRTC
project aims to provide standards for real-time communications
technology. WebRTC is important because it is the ﬁrst real-time communications
standard which is being built into browsers.
This thesis evaluates the beneﬁts which these two protocols offer when using
a mobile phone as a gateway between an IoT and Internet. This thesis project
implemented several test beds, collected data concerning the scalability of the
protocols and the latency of trafﬁc passing through the gateway, and presents
a numerical analysis of the measurement results. Moreover, an LED module
was built as a peripheral for an Earl device. The conclusion of the thesis is that
WebSocket and WebRTC can be utilized to connect IoT devices to Internet.
The Internet of Things (IoT) is an evolving concept that enables interaction with
objects around us through sensors, actuators, mobile devices, and so forth. It is
a broad vision that assumes that there will be sensors on many different kinds of
things, and that these sensors are connected to the Internet or to other computer
systems. This potentially large amount of sensor data may help us to understand
the world around us. Additionally, these things may have actuators - so that we
can act on the physical world. This vision has been known by different names
over the past decades: pervasive computing, ubiquitous computing, smart objects,
and now IoT.
According to Cisco’s Internet Business Solutions Group, in 2010 the number
of devices connected to the Internet was 12.5 billion, while the world’s human
population was 6.8 billion, thus the average number of connected devices per
person was 1.84 1. Looking to the future, it is predicted that by 2015 there will
be 25 billion devices connected to the Internet and by 2020 this number will be
50 billion 1. This expected growth is due to both smartphones and IoT.
IoT can be seen as a set of systems that collect data, process this data,
and then allow us to react to this data (in many cases potentially by acting on
something in the real-world). IoT utilizes many computer and communication
technologies. Having such large numbers of devices introduces a number
of new requirements, such as analyzing big data, new server architectures,
larger networking address spaces (such as provided by IPv6), and new mobile
experiences. These technologies frequently utilize real-time web protocols, data
computing, and hardware toolkits. This thesis project was driven by the
introduction in another thesis project (described in the next section) of a new
hardware toolkit. This thesis project will focus on real-time web protocols.
12 CHAPTER 1. INTRODUCTION
1.1 Problem Description
With the evolving technology, many toolkits have been introduced into the market,
such as Arduino 2, mBed 3, and littleBits 4. Interaction designers at the
ICT Sweden Mobile Life research institute 5 wanted to have their own toolkit.
Mobile Life is a research institute with a focus on mobile services involving
researchers from computer science and interaction design. In this institute a
master’s student, Deniz Akkaya, implemented a toolkit called Earl 6. Earl is
a library of sensors and actuators that can be connected to the Internet through
a mobile phone or a tablet. An Earl instance is implemented with a low power
wireless network interface, such as ANT+ 7 or Bluetooth low energy (BLE)
8, and a low power microcontroller such as Texas Instruments’ MSP430 9.
Such a device sends sensor data to a mobile phone via a wireless communication
link - typically BLE. This data is forwarded to one or more web services by a
mobile phone. Earl aims to provide the user with a means to connect different
types of sensors or actuators and to see how these different sensors impact users’
interactions. Earl enables designers to create proof of concept systems faster than
implementing a system from scratch.
The Mobile Life research institute was asked to conduct a project for ABB
Sweden10 in order to prevent boredom of workers working with ABB’s control
systems in factories. Ethnographic studies were carried out to understand the
reason for this boredom in control rooms. However, these studies did not help
to decide on a feasible product to help the control room workers avoid boredom.
Moreover, a step-by-step design process would not work because there was not
enough time or a predeﬁned problem where a product was speciﬁed. Therefore,
it was decided to use a co-designing method using technology probes 11.
Technology probes are simple and ﬂexible devices used in a design process aiming
to understand the needs and desires of users. Technology probes involve the users
actively in the design process and inspire users and designers to formulate new
product ideas. In the case of this project for ABB Sweden, the main aim was to
let the workers ﬁnd out what would entertain them as they worked.
Some of the important features of technology probes are that:
Technology probes usually have only one function and they are easy to
Technology probes should collect data about these users in order to help
designers generate new product ideas.
Technology probes should be open-ended in order to enable the data
that is collected to be reinterpreted and they should be open for various
combinations of usage.1.1. PROBLEM DESCRIPTION 3
A variety of technology probes were discussed before development began,
and Earl (with a mobile phone) was selected to implement the technology probes.
Since data collection is important when using technology probes, Earl needed a
connection oriented web service that it could push its collected data to in real-
time. This web service was needed to extend the usage of Earl for further design
projects which were thought to require real-time data collection. The requirements
of this web service were:
For the technology probes of ABB project, the delay in collecting data from
Earl needed to be under a second on average. However, for future probes
the web service should be analyzed in terms of minimizing any additional
The web service should support hundreds of Earl connections simultaneously
and in the future the service should be able to scale up in order to support
thousands of connections.
Moreover, one of the technology probes was an arm band built using Earl
with a motor to cause vibrations. This probe (called the arm-probe) enables
workers to communicate using arm movement and vibration. The arm-probe
senses movement of the arm and sends information about this movement to other
Earl devices as a message which triggers vibration. The requirements for this
probe are listed below:
Data should be transferred quickly and the user should not perceive the
delay. One way delay should be less than half second.
Since there are 10 workers in a shift, each mobile phone acting as a gateway
should be able to communicate with 9 other mobile phones simultaneously
(if a full mesh architecture is used).
In addition to the requirements above, another technology probe was a small
ball with LEDs that could be controlled by an Earl device. This probe (called
the ball-probe) was designed to change color and shine based on the interactions
of the user. It should be able to adjust each LED’s brightness and color based
upon Earl commands. Thus, Earl needed an LED module which could provide
different colors and different outputs to cause the LEDs to have different visual
effects, such as blinking and fading.
This thesis project investigates the usage of real-time web technologies to
provide solutions to support web services for IoT toolkits, such as Earl. A number
of test beds have been implemented, data has been collected about WebSocket
(for the case of a web service collecting data) and WebRTC (for the case of the
arm-probe). The analysis of this data showed how these real-time web protocols4 CHAPTER 1. INTRODUCTION
can provide real-time access to data emitted by IoT devices. Moreover, this thesis
project developed an LED module for Earl. A software library has been written
and a printed circuit board (PCB) was made for this LED module.
1.2 Problem Context
A family of standards, architectures, and wireless technology, called IP version
6 over Low Power Wireless Area Network (6LoWPAN) 12, enables the latest
Internet protocols to be used in low power embedded devices by adapting IP
version 6 (IPv6) 13 to suit these constrained devices. It is expected that most
future embedded devices will be seamlessly integrated into the Internet. However,
the past decade shows that there may not be a single technical standard for IoT
due to the fact that IoT spans a broad technological domain.
Two basic approaches have been used to connect things to the Internet:
embedding web servers in smart things and using smart gateways 14. The ﬁrst
approach embeds a lightweight web server into each device and enables access
to the embedded device through a web application 15, 16. In this approach,
embedded devices implement TCP/IP and HTTP stacks and an embedded web
server. Typically such devices are equipped with low-power Wi-Fi modules.
For instance, the OpenPicus project produced a low-cost system on a module,
called FlyPort, with embedded Internet connectivity 17. FlyPort comes with full
TCP/IP support and a web server making it easy to seamlessly integrate such a
device into the Internet.
While devices with embedded web servers are likely to continue to be popular,
the second approach uses intermediate gateways rather than an embedded web
server 16, 18. These gateways receive requests from the Internet and forward the
requests to embedded devices via low-power link layer communication protocols,
such as ANT+ or BLE. These gateways abstract the details of the underlying
wireless link layer communication protocols. Earl utilizes this gateway approach
and the gateway runs on a mobile phone. Web requests and responses sent via
the gateway are used to control wirelessly connected sensors and actuators. The
main advantage of this approach is that it connects low power constrained devices
to the Internet without requiring these devices to implement web protocols nor
even implement TCP. An Earl mobile application contains an embedded web
thesis project builds upon Earl’s gateway approach, but focuses on those web
technologies which connect the mobile phone to the Internet rather than focusing
on the wireless link technologies connecting an Earl device to the mobile phone.
Moreover, Earl was designed to work with peripheral components such as LED
modules, vibration motors, etc. This thesis also builds an LED module for Earl1.3. GOAL 5
which uses Inter-Integrated Circuit (I C). General overview of this architecture is
depicted in Figure 1.1 below.
Figure 1.1: The relationships between LED module, Earl, mobile phone, and
Internet for this thesis project. This ﬁgure also illustrates the relationship of this
project to the earlier Earl thesis project 6
The main two goals of this master’s thesis project are to provide a server
architecture that will transfer real-time data collected by Earl and to provide a P2P
WebRTC architecture to realize the arm-probe technology probe. Another goal
of this thesis project is to evaluate today’s real-time web protocols, speciﬁcally
WebSocket and WebRTC, in terms of scalability and their compliance with
IoT toolkits using the gateway approach. Tests of these protocols should
provide numerical data to enable an analysis of the latency and scalability of
these technologies. These tests will assume that an Earl device is already
communicating with a mobile phone, hence this thesis project will examine the
communication from when a mobile phone initiates communication with a web
server (in the case of WebSocket) or a peer (in the case of WebRTC). In addition
to these goals, an LED module was implemented for Earl. The following activities
were deﬁned as the project’s deliverables (and they can be used as indicators of
the success of the project):
Performance measurements of the implemented WebSocket architecture
with various number of connected clients. Analysis of the results to assess
the limits of this architecture.6 CHAPTER 1. INTRODUCTION
Performance measurements of the WebRTC architecture to enable the arm-
probe. Analysis of the results to assess this architecture.
Software implementation and PCB design of an LED module which is
compatible with Earl. This effort should reveal the ease of implementing
modules for Earl.
1.4 Thesis Structure
Chapter 1 gave a brief introduction to the problem. Chapter 2 describes the tests
that will be conducted to evaluate WebSocket, while Chapter 3 will focus on those
tests that will be conducted to evaluate WebRTC. In these two chapters, there will
be detailed information about the background of the protocols, the tools, data
collection process, analysis of data, and discussion of the results. Chapter 4 will
describe the work to develop the LED module for Earl. Finally, Chapter 5 will
present conclusions and suggest possible future work. Chapter 5 will also discuss
the economic, social, and ethical issues associated with this thesis project.
This thesis project utilizes quantitative research methods. It uses an empirical
approach to measure the performance of the protocols because quantitative data
must be collected to achieve the goals of the project. This thesis project deﬁnes
performance metrics and conducts experiments to collect data about these metrics.
Then, the collected data is analyzed with respect to the project’s requirements. In
this thesis project, qualitative research methods are not used since the experiments
focus on the results of experiments yielding numeric data rather than qualitative
This chapter describes the design, implementation, and evaluation of a web
service that an Earl device can push its collected data to in real-time. We have used
the WebSocket protocol due to its reduction in HTTP overhead and low network
latency, while building upon existing web protocols. The chapter examines scaling
of WebSocket connections when multiple servers are behind a load balancer. The
chapter starts with a background presentation of Internet technologies, and then
reviews related work. This is followed by a description of the tools that will be
used and the experimental setup created to perform the experiments. Next the
experiments are described step by step as we build up the architecture shown
in Figure 2.1. The chapter concludes with an analysis of the results of these
Figure 2.1: Overall view of the architecture for the WebSocket tests
78 CHAPTER 2. WEBSOCKET EXPERIMENTS
HTTP 19 was designed for a request and response paradigm for Web access,
where a user requests a web page and gets some content in a response. With
the need for more interactive web pages, AJAX 20 was introduced to make
asynchronous requests without refreshing the whole current web page. However,
AJAX was still based upon requests being sent by the client. HTTP was
originally designed for document sharing, rather than for interactive applications.
Techniques that attempt to provide real-time web applications include polling,
long-polling, and Comet 21. Long polling is an approach where the client
keeps a connection to the server open until getting a response or a timeout
occurs. Polling methods provide almost real-time communication. Polling and
long polling are compared in Figure 2.2. However, the problem with polling is that
this approach is not suitable for low latency applications because of the overhead
of HTTP’s header data. In addition, the client must wait for responses to return
before it can send a new request which increases the latency. Hence, some new
protocols have been introduced to overcome this limitation. This chapter explores
one of these, speciﬁcally WebSocket.
Figure 2.2: Polling (shown above on the left) versus long polling (shown above
on the right)2.1. BACKGROUND 9
WebSocket is a technology which provides a full-duplex channel over a single
TCP socket. A WebSocket is a persistent connection over which the server and
client can send data at any time. A single request is sent to open a connection
and this connection is reused for all subsequent communication. The WebSocket
protocol has been standardized by the Internet Engineering Task Force (IETF) in
RFC 6455 22 and the WebSocket API 23 is being standardized by the World
Wide Web Consortium (W3C). Modern browsers support the WebSocket API.
The WebSocket API is event-driven, hence there is no need to poll the server.
This means that the server can push data to the client (and vice versa) at any time
as depicted in Figure 2.3.
Figure 2.3: WebSocket trafﬁc
WebSocket utilizes a TCP connection. The protocol begins with a HTTP
request which is upgraded to the WebSocket protocol during the initial handshake
as shown in Listing 2.1. The Upgrade header indicates that this connection
should be changed to use the WebSocket protocol. The response code, 101,
(shown in Listing 2.2) indicates that upgrade of the connection was successful.
The Sec- headers are part of the handshake to conﬁrm that the server
understands the WebSocket protocol. After the upgrade, WebSocket messages can
be sent with a data-framing format. This data-framing format is necessary because
the TCP connection does not have message markers, but rather simply transports
a stream of bytes which are delivered in order. To terminate the connection, an10 CHAPTER 2. WEBSOCKET EXPERIMENTS
endpoint that wants to close the connection sends a numerical code representing
the reason for termination. The details of this protocol can be found in the
WebSocket Protocol speciﬁcation 22.
Listing 2.1: Request to server
1 GET /chat HTTP/1.1
2 Host: server.example.com
3 Upgrade: websocket
4 Connection: Upgrade
5 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
6 Origin: http://example.com
7 Sec-WebSocket-Protocol: chat, superchat
8 Sec-WebSocket-Version: 13
Listing 2.2: Response from server
1 HTTP/1.1 101 Switching Protocols
2 Upgrade: websocket
3 Connection: Upgrade
4 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
5 Sec-WebSocket-Protocol: chat
WebSocket supports sending encrypted trafﬁc over Transport Layer Security
(TLS). This is called WebSocket Secure (WSS). TLS is also used in HTTPS, to
protect data conﬁdentially and to verify its authenticity.
Today many companies providing real-time web solutions take advantage
of WebSocket 24, 25, 26. For instance, Xively, which is a secure, scalable
platform as a service that connects devices with applications, provides WebSocket
support to provide real-time control and data storage 25. In his doctoral
dissertation, Dominique Guinard proposes to add support for WebSockets to the
IoT architecture in order to offer a web based real-time eventing mechanism
to communicate with IoT 14. Additional related work about WebSocket is
discussed in Chapter 2.
2.1.1 Scaling WebSocket Connections
To support a large number of IoT devices, WebSocket servers need to be scaled
either out or up. Load balancing solves issues of scalability and availability. Load
balancing has been used since the early days of the Internet. In practice, there
are two ways of load balancing: hardware or software load balancing. In this
thesis project, I use software load balancing due to the ease of its deployment,
while its performance is similar to that of hardware load balancing. Software load2.1. BACKGROUND 11
balancing can be provided by software (bundled as part of an operating system or
software installed as an add-on such as HAProxy). HAProxy will be discussed in
Load balancers can be thought as reverse proxy servers. A proxy server is
a server acting on behalf of other computers. A reverse proxy is a proxy that
prevents direct access to a website by forcing clients to go through the proxy
in order to communicate with the website. The operation of a proxy server is
transparent to the client and the client can only see the proxy’s IP address(es). A
forward proxy is a proxy on the client’s side and is placed between the client and
Internet. The difference between reverse and forward proxies can be seen in the
Figure 2.4: Forward proxy acting on behalf of the client. Reverse proxy acting on
behalf of server.
Load balancers can make routing decisions based on layer 2, layers 3-4 (IP,
TCP/UDP), or layer 7 (mainly HTTP). As described in the previous section, a
WebSocket utilizes two protocols: HTTP for setting up the connection and TCP
for the actual data exchange (and possibly TLS for security). Therefore, the
load balancer needs to forward the TCP trafﬁc to an appropriate server without
breaking the TCP connection. The TCP connection from the client is to the proxy
and not directly to the end server. Hence a new TCP connection is created between
the proxy and the server. Therefore the proxy is stateful and must be involved in
forwarding all of the trafﬁc ﬂowing from the client to the server. Load balancers12 CHAPTER 2. WEBSOCKET EXPERIMENTS
can utilize one of several algorithms to choose a server to route the TCP trafﬁc to.
Some algorithms, such as round robin or random choice, are not deterministic and
they do not use client side information (such as cookies or IP addresses) to pick
the server. There are also deterministic algorithms, such as sticky sessions, that
use client side information and choose a given server based on this information.
Load balancing can also offer many additional beneﬁts, such as providing TCP
buffering, acting as a ﬁrewall, and TLS/SSL acceleration. In the context of this
thesis, the main aim of load balancing will be to suitably distribute loads across a
number of servers.
2.2 Related Work
This section gives a brief overview of previous projects concerning the WebSocket’s
Gutwin, Lippold, and Graham 27 carried out a study to compare the
performance of web-based networking methods used in groupware applications.
They describe several requirements for different kinds of real-time systems. They
show that WebSocket can support most groupware systems, and suggest that
the browser should be used by groupware developers. Their studies show that
WebSockets can perform better than plug-in approaches, such as Java applets.
However, they note that the use of TCP rather than UDP may have latency
problems in real-world situations, due to limited bandwidth and varying trafﬁc
Greco and Lubbers 28 compare the performance of WebSocket and polling.
They showed that WebSocket reduces HTTP header trafﬁc and has lower network
latency when compared to polling. Their experiments showed a 500 to 1 reduction
in overhead and a 3 to 1 reduction in latency. This latency reduction does not
reduce the propagation latency of data, as the propagation latency is the same for
polling and WebSocket. However, the queueing latency (the time that a server
waits before sending a message) is different. In the case of WebSocket, the server
can send a message as soon as the message becomes available. However, in the
case of polling, the polling interval determines how long the server must wait for a
client’s request. All of the reduction in latency results from removing the queuing
Puranik, Feiock, and Hill 29 quantitatively compared AJAX and WebSocket
by integrating them into a distributed real-time embedded system. They show
that WebSocket provides higher throughput (215.44% more) and better network
performance (while using 50% less bandwidth). However, these results are for
their example application and there is no guarantee that other applications would
experience the same performance.2.3. GOAL 13
Jomier and Marion 30 present a real-time collaborative visualization tool
based on WebSocket and WebGL. Their results show that using WebSocket
compared to AJAX has better performance in terms of lower latency.
Autobahn Testsuite 31 is a project to test the correctness of WebSocket
protocol implementations and is based upon over 300 test cases. Autobahn
includes some tests to measure the round trip time for different message sizes
and fragment sizes.
These projects all show that WebSocket performs better than polling in
terms of providing lower latency and greater user data bandwidth in most cases.
Building on these results, this thesis project uses WebSocket to implement a
gateway architecture for IoT. This thesis project describes tests that have been
performed to measure the scalability and the latency of this architecture in terms
of the following metrics: throughput, message service time (including event
loop latency), response latency, and CPU usage. The choice of these scalability
metrics are mainly based on Greg Barish’s book, Building Scalable and High-
Performance Java Web Applications 32. An article about WebSocket test by
Cubeia (a software development company focusing on scalability solutions) also
leads to these same metrics 33.
The goal of these experiments are to stress test the potential WebSocket architecture
that has been proposed to support IoT communication. Some benchmarks have
already been used to investigate the scalability of WebSockets 34, 35, 36, 37.
Some of these benchmarks use a server that simply echoes incoming messages
35, 36, while some use a server which broadcasts each message to all connected
clients 34, 37.
Instead of echoing or broadcasting all messages from all connected clients, in
the tests described here the clients are separated into two types: publishers and
subscribers. In this way, we can simulate a number of IoT devices which act
as publishers sending data to a number of clients that act as subscribers. Figure
2.5 shows the case of a publisher and several subscribers. Subscribers receive
messages published to those topics to which they subscribe. The tests will focus
on the costs of sending messages from the publishers to the subscribers using the
metrics described in the previous section.
The tests follow a quantitative research method with a numerical data analysis
and investigate the following:
How many WebSocket connections can a server support?14 CHAPTER 2. WEBSOCKET EXPERIMENTS
How can load balancers be exploited to scale up the numbers of WebSocket
connections that can be supported by a WebSocket architecture?
What operations create a bottleneck? Is opening connections, holding
connections open simultaneously, or sending messages the limitation of a
How does the CPU usage of servers change during WebSocket communication?
This thesis project does not give a comparative analysis of different technologies
for server side programming languages or load balancers. (A comprehensive
project comparing the performance of different server side technologies has been
done as part of the TechEmpower web application framework benchmarks project
38.) Instead this thesis investigates a proposal for a scalable architecture that
can support a number of IoT devices by presenting data showing the limits of this
Figure 2.5: Publishers and subscribers
2.4 Tools and Experimental Setup
This section presents the tools used in the tests. The section begins with a
description of a number of a useful command line tools, then describes the other
software that was used for testing. This section also describes the steps taken to
setup an experimental environment in order to perform these tests.
2.4.1 Command Line Tools
A number of command line tools were used for the tests, speciﬁcally: SSH,
sar, kSar, git, ntp, and gnuplot. Each of these is brieﬂy described below. The2.4. TOOLS AND EXPERIMENTAL SETUP 15
speciﬁcation of the local computer and the servers used for the test environment
can be found in Table 2.1 below and Table 2.3 on page 32.
Table 2.1: Hardware speciﬁcation of the local computer
Model MacBook Pro
Operating System OSX 10.8.3
CPU 2.2 GHz Intel Core i7
Memory 4 GB DDR3
SSH is an acronym for secure shell. SSH is a secure network protocol to connect
to a remote machine over an unsecured network. SSH is commonly used to access
shell accounts on Unix/Linux systems (in this case a Ubuntu Linux system). Some
examples of its usage are:
1 Connecting to shell server of KTH
2 ssh gunaykshell.it.kth.se
3 Connecting to my Amazon instance with a key file created
for this instance.
4 ssh -i ./gunay-amazon-s1.pem \
Sar is a tool to monitor performance statistics including: CPU usage, memory
consumption, network trafﬁc, etc. Sar was used to collect performance data about
the servers during the tests. Sar is part of the linuxsystat package which can
be installed with the command :
1 sudo apt-get install sysstat
Here are some examples of its usage:
1 print CPU usage every one second
2 sar -u 1
3 print info about sockets in use for IPv4
4 sar -n SOCK 1
5 print to file
All of the command examples given are for a Ubuntu linux system.16 CHAPTER 2. WEBSOCKET EXPERIMENTS
6 sar -n SOCK -o results.sar 1
7 read the file to extract info about sockets
8 sar -n SOCK -f results.sar
9 read the file to see memory cpu utilization
10 sar -f results.sar
11 put the sar data into file
12 sar -o results.sar 1 /dev/null 2&1 &
kSar 39 is a Java based tool to graph the output of sar. It can export the graph in
a variety of formats, such as PDF, JPEG, etc. This tool can be used as shown with
the following commands:
1 print sar data to a text file by using C locale
2 LC_ALL=C sar -f ˜/datafile -A sar.txt
3 execute kSar with the sar.txt file given as input and
sar.pdf as output
4 java -jar kSar.jar -input sar.txt -outputPDF sar.pdf
Git is an open source distributed version control system developed by Linus
Torvalds. The purpose of Git is to store all versions of the source code
and easily access any past version. While Git can be used locally, a remote
(centralized) repository is needed to protect against data loss. GitHub is a
popular service for Git repositories 40. Git and GitHub were used to provide
a backup and to maintain a complete history of the software development for
this project. Git was also used to push the local code to the test servers. All
the code for these experiments can be found in the public GitHub repository:
https://github.com/gmertk 41. The most frequently used commands during this
1 to initialize a Git repository which is a hidden
directory in the folder where Git is executed
2 git init
3 to add and commit changed files into the repository.
4 git commit -am "message"
5 to add a remote repository to push the local repository
6 git remote add origin
"https://github.com/gmertk/websocket-test"2.4. TOOLS AND EXPERIMENTAL SETUP 17
7 to push the local changes to the remote repository
8 git push -u origin master
9 to check for changes on the GitHub repository and pull
any new changes
10 git pull
To synchronize the clocks of each of the computers the Network Time Protocol
(NTP) 42 was used. The NTP daemon synchronizes the local system’s time with
a remote server.
To install this NTP daemon the following command can be used:
1 sudo aptitude install ntp
After installation, the daemon can be started or stopped with the following
commands (as usual for Linux services):
1 sudo /etc/init.d/ntp start
2 sudo /etc/init.d/ntp stop
In the tests, one of the servers was chosen as master NTP server, and the
other servers synchronize to this master to guarantee that all of the servers have
their time set to the same value. The advantages of this setup are a reduced
number of outgoing connections 43. The master NTP server was conﬁgured
to synchronize with a stratum 1 server (nist1-sj.WiTime.net). /etc/ntp.conf
ﬁle was conﬁgured to set the server addresses. Before the tests, the time difference
between the servers was below 1 ms as established from the output of thentpq
Gnuplot 44 is a widely used and powerful tool to generate plots of data. It can
export the plot in a variety of formats, such as PNG, JPEG, etc. The test results,
presented in Section 2.6, were plotted using gnuplot.
2.4.2 Node.JS Server
Node.js is an event-driven, non-blocking infrastructure for building highly concurrent
software. It is used by many large companies to create fast and scalable networked18 CHAPTER 2. WEBSOCKET EXPERIMENTS
a large number of third-party modules available for it.
Event-driven programming is a programming model where events determine
the ﬂow of the program. Events are handled by callbacks which are functions
that are invoked when an event happens, such as when a connection occurs
or when a database query produces a result. The example below shows how
event-driven programming is different from traditional blocking input/output (I/O)
programming 46. In traditional blocking I/O programming, a database query
stops the current process until the database processing is completed:
1 result = query(’SELECT FROM users WHERE name = "mert" ’);
In event-driven systems, logging this query would be written as:
1 queryFinished = function(result)
4 query(’SELECT FROM users WHERE name = "mert"’,
In the event-driven approach when the query has completed, the callback
queryFinished function will be called. This model of programming is called
event-driven or asynchronous programming. Event-driven programming is one
programming, because it supports closures and functions as arguments.
Event-driven programming is realized by having an event loop which detects
events and invokes callbacks when a speciﬁc type of event happens. An event
loop is simply a thread running inside a process, thus when an event happens the
event handler runs without requiring an interrupt. In this model at most one event
handler is running in a process at any given time, thus the programmer does not
have to consider concurrent threads of execution changing the shared memory
state as they would have to do in multi-threaded programming. However, this
also is a limitation since only one handler is running and it runs to completion -
therefore other events have to wait until this event handler has voluntarily given
up the CPU.
Node.js can be installed on Ubuntu via the package manager apt-get by
entering the following commands:
1 sudo apt-get install -y python-software-properties
2 this command installs the latest stable version from
Chris Lea’s Ubuntu Personal Package Archives (PPA).
3 node v0.10.5 was the stable version when I performed the2.4. TOOLS AND EXPERIMENTAL SETUP 19
4 sudo add-apt-repository ppa:chris-lea/node.js
5 sudo apt-get update
6 npm is the node package manager to install third-party
7 sudo apt-get install -y nodejs npm
Node.js has many packaged modules which can be installed via the npm
package manager. The modules that have been used in our testing are Optimist,
Gauss, Socket.io, Websocket-worlize, Forever, and Node-redis. Each of them is
described in more detail below.
Optimist – Optimist is a Node.js module for simple option parsing. With
optimist, options are similar to a dictionary. An example from the optimist website
47 is shown below. The ﬁle short.js contains:
1 /usr/bin/env node
2 var argv = require(’optimist’).argv;
3 console.log(’(%d,%d)’, argv.x, argv.y);
1 ./short.js -x 10 -y 21
1 npm install optimist
Gauss – Gauss makes it easy to calculate and explore collected data by
providing functions for data analysis such as standard deviation and arithmetic
1 npm install gauss
usage of WebSocket and provides fail-overs to other protocols such as Adobe
Flashsockets, JSONP polling, and AJAX long polling. It also offers heartbeats,
timeouts, and disconnection support, none of which the WebSocket API provides
directly. Initially the testing used Socket.io because I thought Socket.io was better
because of its support of old browsers and it provided a better abstraction for
native WebSocket API. However, I subsequently realized that the Socket.io library
has a signiﬁcant problem which causes it to disconnect clients when there was a
large number of connections 49. Unfortunately, this issue is not ﬁxed yet, so I
changed to another WebSocket library (Websocket-worlize - described next).