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
Dr.NoahGates Profile Pic
Dr.NoahGates,Netherlands,Researcher
Published Date:06-12-2017
Your Website URL(Optional)
Comment
Abstract 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 benefits of IoT range from financial 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 efficient 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 first real-time communications standard which is being built into browsers. This thesis evaluates the benefits 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 traffic 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. iChapter 1 Introduction 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 management, in-memory 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 predefined problem where a product was specified. Therefore, it was decided to use a co-designing method using technology probes 11. Technology probes are simple and flexible 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 find 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 interact with.  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 delay.  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 first 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 page within it to be used by the browser. Earl provides a JavaScript API. This 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 2 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 figure also illustrates the relationship of this project to the earlier Earl thesis project 6 1.3 Goal 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, specifically 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 defined 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. 1.5 Methodology 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 defines 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 data.Chapter 2 WebSocket Experiments 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 experiments. Figure 2.1: Overall view of the architecture for the WebSocket tests 78 CHAPTER 2. WEBSOCKET EXPERIMENTS 2.1 Background 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, specifically 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 traffic 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 confirm 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 specification 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 traffic over Transport Layer Security (TLS). This is called WebSocket Secure (WSS). TLS is also used in HTTPS, to protect data confidentially 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 Section 2.4.4. 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. 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 traffic 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 traffic flowing 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 traffic 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 benefits, such as providing TCP buffering, acting as a firewall, 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 performance. 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 traffic patterns. Greco and Lubbers 28 compare the performance of WebSocket and polling. They showed that WebSocket reduces HTTP header traffic 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 latency. 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. 2.3 Goal 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 WebSocket server?  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 architecture. 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, specifically: SSH, sar, kSar, git, ntp, and gnuplot. Each of these is briefly described below. The2.4. TOOLS AND EXPERIMENTAL SETUP 15 specification 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 specification of the local computer Model MacBook Pro Operating System OSX 10.8.3 CPU 2.2 GHz Intel Core i7 Memory 4 GB DDR3 2.4.1.1 SSH 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 \ ubuntuec2-54-216-102-8.eu-west-1.compute.amazonaws.com 2.4.1.2 Sar Sar is a tool to monitor performance statistics including: CPU usage, memory consumption, network traffic, 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 & 2.4.1.3 kSar 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 2.4.1.4 Git 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 project were: 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 called origin 8 git push -u origin master 9 to check for changes on the GitHub repository and pull any new changes 10 git pull 2.4.1.5 NTP 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 configured to synchronize with a stratum 1 server (nist1-sj.WiTime.net). /etc/ntp.conf file was configured 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 -p command. 2.4.1.6 Gnuplot 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 services 45. Node.js is written in JavaScript and it provides elegant APIs and has a large number of third-party modules available for it. Event-driven programming is a programming model where events determine the flow 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" ’); 2 log(result); In event-driven systems, logging this query would be written as: 1 queryFinished = function(result) 2 log(result); 3 4 query(’SELECT FROM users WHERE name = "mert"’, queryFinished); 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 of the defining features of Node.js. JavaScript is well suited for event-driven 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 specific 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 experiments. 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 modules 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 file 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 To install: 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 mean 48. To install: 1 npm install gauss Socket.io – Socket.io is a popular JavaScript library which simplifies the 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 significant problem which causes it to disconnect clients when there was a large number of connections 49. Unfortunately, this issue is not fixed yet, so I changed to another WebSocket library (Websocket-worlize - described next).