Distributed Cloud Infrastructure Over Web Browsers

A.S. Ariyawansa
108252L

Thesis submitted in partial fulllment of the requirements for the degree of Master of Science

Department of Computer Science and Engineering

University of Moratuwa Sri Lanka

Feb

2011

DECLARATION

I declare that this is my own work and this thesis/dissertation does not incorporate without acknowledgment any material previously submitted for a Degree or Diploma in any University or other institute of higher learning and to the best of my knowledge and belief it does not contain any material previously published or written by another person except where the acknowledgment is made in the text.

Student Name

Date

Approved by:

Supervisor Name Date Department of Computer Science and Engineering University of Moratuwa

iii

COPYRIGHT STATEMENT

I hereby grant the University of Moratuwa the right to archive and to make available my thesis or dissertation in whole or part in the University Libraries in all forms of media, subject to the provisions of the current copyright act of Sri Lanka. I retrain all proprietary rights, such as patent rights. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation.

Student Name

Date

I have supervised and accepted this thesis/dissertation for the award of the degree.

Supervisor Name Date Department of Computer Science and Engineering University of Moratuwa
iv

ABSTRACT

The abstract goes here. Usually, one page.

ACKNOWLEDGEMENT

The acknowledgement goes here. Usually, one page.

vi

Contents

DECLARATION

.............................................

iii iv v vi 1 1 1 2 3 4 5 5 6 6 7 7 8 8 9 9 10 10 10 11 12 12

COPYRIGHT STATEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACKNOWLEDGEMENT 1

1.1 1.2 1.3 1.4 1.5 ....................................

.......................................................... Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.......................................................... 2.1 2.2 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.4 2.5 Public Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Private Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Focus in Deep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Http Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flash Socket Communication . . . . . . . . . . . . . . . . . . . . . . Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Web Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Web Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Researches on Web Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Real-time Collaborative Editing with Web Sockets, Node.js and Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

viii

Contents

2.5.2

EarthControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 17

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Figures

1.1 2.1 2.2 2.3

Concept Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud Service Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Socket Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EarthControl Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 6 11 14

ix

List of Tables

Chapter 1

1.1 Introduction

The concept of cloud computing has become one of the most innovative and attractive concepts in past few years. It evolved with three basic concepts called Software as a Service(SAAS), Platform as a Service(PAAS) and Infrastructure as a Service(IAAS). As far as the IAAS is concerned it is simple as such that, the task which needs high availability of resources eg:- CPU power, storage etc are submitted to the cloud, gets computed there and asks the results from it. But in this paradigm the missing part is that how the cloud handles or computes tasks with its infrastructure. Currently the cloud infrastructure provides have large sets of clusters set up in there environment. So the computation is still centralized and cloud providers have to spend lot of money to maintain their infrastructure. What if we can change this paradigm such that the cloud is also distributed among the users of the Internet? In other words, if we can come up with a framework where the high computational jobs are distributed among the Internet users and get the computation done using their own CPU power and get contribution to the nal task completion, the need of having high cost cloud infrastructure can be minimized. Ultimately the results coming from each of these users/clients will outputs the total result of the given task. This is what the main intention of the Web Based Distributed Cloud Computing Framework.

1.2 Motivation

As far as the history of volunteer Computing is concerned it has been evolved since 2000. But all the solutions given were totally based on TCP so that the client installations are also needed to deal with client server communication. This lets users to go away from this concept.

On the other hand HTTP is concerned it was one way communication mechanism so far where the client or the web browser needs to initiate the request all the time from the server to get the output. But this is not the situation hereafter. With the emergence HTML5 and web sockets, there is a full duplex communication medium between client (web browser) and sever so that it is possible to pull and push data between each other. Web Based Distributed Cloud Computing Framework combines above technologies and extends the solution to work on web browsers collaboratively. As a result the Internet users can voluntary participate to complete a job which is published on the Internet. (Job publishing process is discussed later).

1.3 Concept

Fig. 1.1 Concept Overview

 Job/Task hosting web site can be any web site on the Internet. Since it is needed users to stay at the site as much as possible, most preferable sites would be blog sites, mail clients etc. With the implementations of fault tolerant activities discussed later this can be any the web site.

1.4

Challenges

 Job Providers can be an application which has high computational power consuming tasks stored or can even be a human. Job provider can submit a job to one of the Job/Task hosting web sites. It is preferred that these jobs are easily easily distributed. Submitted jobs are published on a public web page where most of the users are vising. Eg:- common blog page.  Clients are just web browsers which supports HTML5(web sockets) technology or alternative technologies which are discussed later. When users visiting the site using their browsers, jobs hosted on that site gets invoked and begins the streaming process of data (which are to be processed) and the code needs for the execution to the client environment.( Standard algorithms for task distribution will be used here.) After that the client/browser starts to execute the job. Same way each user who visits the site will be given a part of the job to be executed. As a result main job gets executed parallels in distributed environment. (Standard synchronization and communication algorithms related to distributed computing will be applied here.) The results of each process will be sent back to job hosted server which can then obtain the nal result. This paradigm tries to achieve the cloud concept IAAS in geographically distributed environment. Here the job hosted site becomes the coordinator and client browsers themselves become the nodes on the cloud which share their computational power.

1.4 Challenges

Since web browser is the most frequently used application in users environment, by visiting these job hosted sited should not lead to slow down the whole browser application. Specially when it comes to browsers like GoogleChrome it creates a separate process for each of the tab it uses to site the sites. So slowness in one site would not aect the whole browser application. Since here we are using the users computational power, there should be a mechanism of asking the permission from them before executing the jobs. Therefore when the user logs on to the site, he/she will be asked for permission. On the other hand users frequently go for those sites to get some services done. Eg:- email, blog reading. So it is believed that the users will grant their permission in order to compensate those services. As far as fault tolerance is concerned there are possibilities like closing the browser or vising another web page while executing the jobs. In these there should be mechanisms to make the jobs working in background or notifying the user about the consequences. Lots of redundant techniques will be used to obtain more reliable output.

1.5 Domain Areas

Few of the business use cases where the concept can be applied are are described below. 7.1. Real Time Market Data Analysis Today people use web based clients to track the changes in stock market data. This applicatio will become more convenient if the users can see the history of the stocks and how they were uctuated in a pictorial manner, while getting the updates. Since this is more computational power needing task this can be distributed among the users who are visiting the web site, so that real time calculation will be done. As a results same users can view the historical details in a separate part of the web application while doing the other ordinary operations. 7.2. Real Time Data Mining Data mining is one area where high computational power is needed. Also data mining techniques are always dealing with embarrassingly parallel, easily distributable algorithms. When it comes to the business point of view typical web applications have tons of data. Many organizations want to analyze these data and nd out some patterns which will help nding potential opportunities. This analytical process needs more CPU power, but since it is not part of main operations they may not use their local resources for this purpose. As a solution they can publish such data mining operations on their web applications so that analytical process will also be executed in background while serving other day to day services. 7.3. High Computational tasks related to world wild web. There are so many CPU bound algorithms relevant to the INTERNET(www) where the concept can be applied. Creating Inverted Index, vector image processing, weather data analysis algorithms are some of them.

Chapter 2

2.1 Cloud Computing

"A Cloud is a type of parallel and distributed system consisting of a collection of interconnected and virtualized computers that are dynamically provisioned and presented as one or more unied computing resources based on servicelevel agreements established through negotiation between the service provider and consumers. [1] Lewis Cunningham, an Oracle data architect denes cloud computing (more succinctly, but slightly less accurately), as  using the Internet to access someone else's software running on someone else's hardware in someone else's data center while paying only for what you use. [2] The rst denition illustrates the true distributed nature of the whole cloud concept by having collection of interconnected computers which are intended for common task. Whereas the second denition makes this concept more useful while making it available on the internet. Moreover it further points out that the task to be performed will be running on some hardware which are beloned to someone else .............. Eventhough today the cloud computing evolved in many subcategories, still three main fundamental concepts remain same. They are, 1. Software as a Service (SAAS) 2. Platform as a Service (PAAS) 3. Infrastructure as a Service (IAAS)

Fig. 2.1 Cloud Service Model

2.2 Deployment architectures

When the concept of cloud began to grow in rapid manner people tend to think about dierent deployment architectures which reects the ways of maintaining cloud services. As a result several model were used based on the requirements.

2.2.1 Public Cloud

Since Internet usage went really high with in last few decades some companies thought sharing there resources as cloud services. As a result all three main kinds of services (IAAS,PAAS,SAAS) were available on the Internet. These providers are called cloud service providers. In public cloud environments Data and Processing are totally handled by the cloud service provider it self. The main advantages of this scenario are, No installation and maintenance cost needed.

2.2

Deployment architectures

If you need more computing power, it can be obtained on demand.

2.2.2 Private Cloud

In fact private cloud is becoming more and more popular among the organizations due to some key disadvantages of the public cloud. One common such fact is that privacy. All the data is handled by the service provider itself hence no guarantee that the data is protected. On the other hand already existing legacy apps are hard to make an integration with the modern public clouds. As a result private cloud architecture emerged. in Private cloud environments the set of computer resources like high performance CPUs,Storage etc are placed which is only accessible to the an organization so that it works as the infrastructure to the internal cloud. Cloud service providing applications are running on top of that. So any the most of the task which need more power in terms of CPU for an example are given to the SAAS application which runs on top to that internal infrastructure. That is why this is called Cloud in House.

2.2.3 Focus in Deep

Whether it is private or public, as far as the infrastructure of the Cloud computing environment is concerned it is just stack of CPUs,Storage etc which are combined together as a grid on a well controlled environment. The exposure to the public or within the organization is the fact which diers it's privateness. Only the upper layers like SAAS provides the hardware abstraction to make run dierent type of applications which are otherwise hard to perform on a single personal computer. Thus the Cloud is a centralized point which provides services to it's community. What if we can change this centralized dimensions of cloud infrastructure and make it available on the hardware which it self is distributed? On the other hand as mentioned main disadvantage of private cloud is that it needs dedicated hardware with in the organizational network (or any other place which is only accessible to the organization). Due to lack of resource in many small level organizations are go away of the concept of private cloud. What if we can nd a solution where no any further dedicated hardware is needed, but the personal computers themselves become a nodes of a distributed cloud when they are idle? In 1989, Tim Berners-Lee, a British computer scientist invented the world wild web[3]. On that day onwards www is being used for so many purposes. With the emergence of graphical web browser in 1993[4], in fact total Internet

is almost conquered by it. Among them on line emails, blog reading, information leaning are become most common as well as valuable. Doing those activities means just the reading the context which displays the on the web browser. In other words when doing so the user computer CPU does nothing relates to that particular work. Can we contribute this CPUs to do another meaningful work without interrupting their main work on the www? Finding the answers to the above questions brings the concept of Distributed Cloud Over Web Browsers(DCWB). Here the cloud environment is established among the web browsers so that each client browser becomes a node in it.Hence cloud environment infrastructure becomes distributed.No extra dedicated hardware is needed. The jobs on the cloud environments will be the sites so they gets executed which the users are staying on those sites.

2.3 Web Technologies

Since the core of DCWB is totally based on http, its worth to look at series of current web related technologies to achieve the goal. On the other hand nodes of DCWB is just the web browsers, the close interaction between those technologies and the browser technologies is really vital. The main functionality of the DCWB is getting a part of a distributed task from a hosted place and make it execute on the browser client and send the results back to the server. So is it needed to send and receive both the code and data between browser and the server. In order to accomplish this communication several technologies can be proposed. [5] Provides a comparison between series of Push and Pull Techniques related to web which can be used for DCWB's purpose.

2.3.1 Ajax
AJAX is an approach to Web application development Using a combination of established web technologies: Standards-based presentation using XHTML and CSS, dynamic Display and interaction with the document object Model, data exchange and manipulation, asynchronous Retrieval using XMLHttpRequest and JavaScript binding all together. XMLHttpRequest is an API implementation by most modern Web-browser scripting engines Data transmission to and from a web server via HTTP, establishing an independent communication channel in the background between a client and server. The combination of these technologies enables we adopt the main paradigms of software engineering, as as a component and event-based, for the development of Web applications. Our previous work on a style of architecture AJAX SPIAR

2.3

Web Technologies

called, provides an overview of the band to new ways Applications can be architected using AJAX. The adoption of AJAX has become a serious option not only for new developments Applications but also for migration of existing websites increase responsiveness. The development of the Web the advent of Web 2.0, AJAX, and in particular the Users an experience similar to using a desktop application. Now Known examples are Gmail and new Yahoo! E-mail. The REST style is a server at the initiative of the HTTP request impossible. Each request must be initiated by a client precluding servers from sending asynchronous messages without a client request. There are several solutions used in practice, still get the customer to updates in real time from the server. In this section we will Some of these solutions to analyze.

2.3.2 Http Pull

Many AJAX applications check with the server to the user dened time intervals to refresh (TTR) is known. This test is independent of whether the state has changed in blind. To achieve high accuracy of the freshness of data and data, making the frequency must be high. This in turn induces high network trac and possibly unnecessary messages. The petition also calls waste time for completion of the event so that a direct inuence on the response to the user. Ideally, the interval between trains is equal to the rate Publish Rate (PR), or in which state changes. If the frequency is too low, the client can miss some updates. This rule is often used in Web-based systems because they are robust, easy to implement, may for oine operation, and scales well to large numbers of subscribers. Mechanisms such as Adaptive TTR TTR changing servers, the client may be on dierent frequencies, according to deduct from the rate of change data. This dynamic approach TTR in turn, yields better results than a static model of TTR. However, it will never reach complete data accuracy, and it will create unnecessary trac.

2.3.3 Page Streaming

This method simply consists of streaming server data in the response of a long-lived HTTP connection. Most web servers do some processing, send back a response, and immediately exit. But in this pattern, the connection is kept open by running a long loop. The server script uses event registration or some other technique to detect any state changes. As soon as a state change occurs, it streams the new data and ushes it, but does not actually close the connection. Meanwhile, the browser must ensure the user-interface reects the new data, while still waiting for response from the server to nish.

10

2.3.4 Service Streaming

Streaming Service based on the XMLHttpRequest object. This time it's an XMLHttpRequest connection that is longlived in the background instead of loading the initial page. This provides some exibility regarding the duration and frequency of connections. The page will be loaded normally (once) and diusion can be achieved with a predened lifetime for the connection. The server will loop indenitely, as in streaming page, the browser has to read the last response (responseText) to update its content.

2.3.5 Flash Socket Communication

Under the control of JavaScript, the client establishes a TCP connection to a unidirectional relay on the server. The relay server does not read anything from this socket; instead it immediately sends the client a unique identier. Next, the client makes an HTTP request to the web server, including with it this identier. The web application can then push messages addressed to the client to a local interface of the relay server, which relays them over the Flash socket. The advantage of this approach is that it appreciates the natural read-write asymmetry that is typical of many web applications, including chat, and as a consequence it oers high eciency. Since it does not accept data on outgoing sockets, the relay server does not need to poll outgoing TCP connections at all, making it possible to hold open tens of thousands of concurrent connections. In this model, the limit to scale is the TCP stack of the underlying server operating system[6].

2.3.6 Discussion
As far as the traditional push technologies discuss above are concerned except the raw ash sockets, all the others are really the extended versions of Ajax. which means all of them are just patch solutions for the HTTP communication base Request rst and then respose. Due to that a huge network bandwith wastage happened when the same technology is being used for the push functionality from server to client browser. Flash sockets overcome this issues while providing true duplex communication between server and client. Because ash player initiates a socket to communicate. But the problem here is that it asks the users to install additional component (ash player) on theie browsers. On the other hand the installed componenet leads to a big security threat too.

2.4

Web Sockets

11

Thus, non installable, safe but a true socket communication mechanism is needed for the DCWB to obtain the goal of code and data communication. This is where the web sockets come into play.

2.4 Web Sockets

HTML5 Web Sockets specication denes an API that allows web pages to use the Web protocol Sockets for bidirectional communication with a remote host. It presents Web Socket interface and denes a communication channel full-duplex operating through a single outlet on the Web. HTML5 Web Sockets, allow a considerable reduction of unnecessary network trac and latency compared to the interrogation impassable and solutions long survey that were used to simulate a full duplex connection by maintaining two connections. HTML5 Web Sockets consider risks such as network proxies and rewalls, which enables streaming over any connection, and with the capacity for communication upstream and downstream over a single connection, applications HTML5 Web Sockets instead of reducing the burden on the servers, allowing existing machines to support more simultaneous connections. The following gure shows a basic architecture Web Socket based browsers use a connection Web Socket for full-duplex, direct communication with remote hosts.

Fig. 2.2 Web Socket Overview

A unique feature of the Web Sockets provide is its ability to traverse rewalls and proxies, a problem area for many applications. Comet-style applications typically vote along as a defense against the rudimentary rewall

12

and proxies. The technique is eective but not well suited for applications in MS-500 latency or high throughput requirements. Technology-based plug ins like Adobe Flash to support a certain level of output, but with the proxy very long and the problem of rewall traversal web were charged Sockets solve this problem now. A WebSocket detects the presence of a proxy server and automatically switch a tunnel through the proxy. The tunnel is a statement published HTTP CONNECT proxy server that handles requests to the proxy server on a TCP / IP to a host and a specic port open set. Once the tunnel is established, the communication can ow freely through the proxy. Since HTTP / S works in a similar way using sockets through SSL secure web technology the same HTTP CONNECT. Note you, that supports Web Sockets are only at the beginning of modern browsers (Chrome WebSocket now supports native). However, implementations of backward compatibility, browsers today that the benets of this new technology becomes available. Web-based, like other parts of the HTML5 eort of local storage and geolocation, was originally part of the HTML 5 specication, but was moved to a separate document standards, so that the precise specications. Web Sockets, Internet Engineering Task Force (IETF) has been presented by its creator, the Web Hypertext Application Technology Working Group (WHATWG). The authors, evangelists and businesses in the standardization is still on the original set of features, including Web-taken, as the "HTML5".

2.5 Researches on Web Sockets

2.5.1 Real-time Collaborative Editing with Web Sockets, Node.js and Redis
A research carried out by university of Moratuwa, faculty of Information Technology. The main intention of this project was that making real time code editor where all the developers are connecting to a single interface through their web browsers and do the changes on the code the at the same time. All the changes being done dy a person, gets displayed to all the others in reatime. The integration steps are as follows. when one user makes a change; a di will be created for his change and sent to server. Then the server posts this di to other connected collaborators of the pad. When a user receives a di, his content will be patched with the update. So both taking dis and applying patches gets executed on the client side[7].

2.5

Researches on Web Sockets

13

2.5.2 EarthControl
A multi-player, real-time game which runs within the Facebook social networking website. Although this is an entertainment application, the architecture of the program uses many of the elements that a technical or business application might employ and therefore this demonstration has relevance to the implementation of more serious applications.Operation of the application is as follows. Players in an EarthControl game generate ship control and re commands using the arrow keys and space bar, respectively, on the keyboard. These commands are sent via WebSocket and the Kaazing Gateway server to a STOMP (Streaming Text Orientated Messaging Protocol) server. The STOMP server then passes the command to the specic EarthControl game instance to which the player has been assigned. Open receiving a keystroke signal from a browser, the game instance computes the resulting coordinates of each of ship and plasma in the game and sends this complete coordinate data set out to each browser, again using WebSocket via the STOMP server and the Kaazing Gateway. Each group of eight players is assigned to an instance of the EarthControl game software, as illustrated at right. An administrator program assigns incoming users to empty positions in an existing game instance or starts a new game instance if no existing positions are available. Scoring and other user data is managed by a MySQL database on the server[8].

14

Fig. 2.3 EarthControl Architecture

References

[1] R. Buyya, C. S. Yeo, and S. Venugopal, Market-oriented cloud computing: Vision, hype, and reality for delivering it services as computing utilities, in High Performance Computing and Communications, 2008.
HPCC'08. 10th IEEE International Conference on, 2008.

[2] C. C. Requires, I ITIF, [3] Tim [4] Web Berners-Lee browser wikipedia, wikipedia, the the free free encyclopedia. encyclopedia. http://en.wikipedia.org/wiki/Tim_Berners-Lee. http://en.wikipedia.org/wiki/Web_browser#History. [5] E. Bozdag, A. Mesbah, and A. V. Deursen, A comparison of push and pull techniques for ajax, in Web Site Evolution, 2007. WSE 2007. 9th
IEEE International Workshop on, 2007.

[6] Push

technology

wikipedia,

the

free

encyclopedia.

http://en.wikipedia.org/wiki/Push_technology. [7] L. Perera, Real-time collaborative editing with web sockets, node.js & redis. http://laktek.com/2010/05/25/real-time-collaborative-editingwith-websockets-node-js-redis/. [8] Bergmans mechatronics LLC | WebSocket application research. http://bergmans.com/WebSocket.html.

15

References

[1] R. Buyya, C. S. Yeo, and S. Venugopal, Market-oriented cloud computing: Vision, hype, and reality for delivering it services as computing utilities, in High Performance Computing and Communications, 2008.
HPCC'08. 10th IEEE International Conference on, 2008.

[2] C. C. Requires, I ITIF, [3] Tim [4] Web Berners-Lee browser wikipedia, wikipedia, the the free free encyclopedia. encyclopedia. http://en.wikipedia.org/wiki/Tim_Berners-Lee. http://en.wikipedia.org/wiki/Web_browser#History. [5] E. Bozdag, A. Mesbah, and A. V. Deursen, A comparison of push and pull techniques for ajax, in Web Site Evolution, 2007. WSE 2007. 9th
IEEE International Workshop on, 2007.

[6] Push

technology

wikipedia,

the

free

encyclopedia.

http://en.wikipedia.org/wiki/Push_technology. [7] L. Perera, Real-time collaborative editing with web sockets, node.js & redis. http://laktek.com/2010/05/25/real-time-collaborative-editingwith-websockets-node-js-redis/. [8] Bergmans mechatronics LLC | WebSocket application research. http://bergmans.com/WebSocket.html.

17