Building Real Time Web Applications Using HTML 5 Web Sockets

Over the last few decades, software applications evolved from character mode terminal applications , to desktop applications, to client/server (network enabled desktop) applications, and now to Web applications. Client/server applications brought distributed computing to reality first. One of the key differentiators for these client/server applications is connectivity – they connected to the server over a network and received and sent data over full duplex network connections and had access to realtime or near realtime data, depending on the network latency. The server could push a message to the client anytime.

Then came the world wide web and the Internet, which started as a static content delivery mechanism over a stateless request and response architecture of HTTP. Early Internet applications took a step back backwards in terms of interactivity, connectivity and ability to receive realtime data–primarily due to HTTP’s request and response based architecture. Any piece of information that the client needs has to be requested explicitly by the client and the server sends only the requested data.

The promise of the Web applications and the opportunity of bringing applications to everyone on the Internet led to numerous innovations: Java for browsers, Servlets, JavaScript, Java Server Faces (JSF), Dynamic HTML and now Web 2.0 application development (AJAX) toolkits and various plugins (Adobe Flash and Microsoft Silverlight); that pushed the envelope to make Web applications more interactive and dynamic. These developments succeeded in bringing that rich interactive experience users enjoyed in client/server applications, but due to the request and response architecture that they are based on, the latest Rich Internet Applications still cannot match the connectivity and the capability to get realtime data that client/server applications had more than a decade ago.

This article explores techniques used in recent years to address the connectivity (the notsorich) part of the Rich Internet Applications and describes ServerSent Events and Web Sockets—parts of the HTML 5 specification—that finally make the Rich Internet Applications truly rich.

Techniques Used in Building Rich Internet Applications

Polling

Polling is the easiest way to retrieve the latest data and events from the server for a Web application. The Web application essentially polls the server on a regular basis, based on a timer. The timeliness of the data is directly proportional to the polling frequency. This technique works without any issues with proxies, routers, firewalls and other network agents, because it uses a simple HTTP request each time the timer expires.

The cost of polling frequently is very high–both in terms of network bandwidth as well as server infrastructure needed to support a huge number of polling requests. The server must have the capability to buffer the data that it needs to send to the client until the next request comes from the client. PointCast Network was one of the first companies to implement this strategy. With a never ending appetite for network resources PointCast Network clogged up network connections for customers, Internet Service Providers, and corporate networks and as such PointCast Network got listed in the 12th place in PCWorlds’ “The 25 Worst Tech Products of All Time”.

Comet Programming Techniques

Long Polling

In long polling, also known as asynchronous polling, the browser sends a request to the server and the server keeps the request open for a set period. If a notification is received within that period, a response containing the message is sent to the client. If a notification is not received within the set time period, the server sends a response to terminate the open request and the browser resends the request to the server.

In a case where a large number of messages must be sent, long polling does not provide any substantial performance improvements over traditional polling. This lack of performance can be attributed to the number of HTTP headers, present in both long polling and polling, which often accounts for more than half of the network traffic. Additionally, if secure connections (connections using SSL) are used in combination with long polling, the setup and tear down of each connection is costly, unless the client establishes an HTTP 1.1 persistent connection. The server also needs to have the capability to buffer data, if data is generated when it is not serving a long poll request thus holding onto resources , which negatively impacting the scalability of the server. The HTTP 1.1 specification section 8.1.4 states that browsers should not have more than two simultaneous connections to the same server open at one time. With this limitation, an user could run 2 web applications on the same server (each using one connection) or run one application that uses a connection for the application and the other connection for downloading large image files or other content from the server. If an application uses long polling technique to fetch data from the server, it locks up one connection leaving only one other connection for the application and downloading of images and other content. Due to this comet application developers using long polling technique host the server servicing comet requests on a subdomain – which requires additional hardware and adds to the maintenance cost of the whole system.

Streaming

When streaming is used, the browser sends a complete request, but the server sends and maintains an open response that is continuously updated. A request is sent and kept open indefinitely (or for a set period of time) and the response is updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages. One benefit of streaming is reduced network traffic, which is the result of sending packets that only contain data rather than packets that contain both data and HTTP headers. The downside of streaming is that it is still encapsulated in HTTP, so intervening HTTP proxies may choose to buffer the response, increasing the latency of the message delivery.

HTML 5 Specification

The Communication section in the HTML 5 specification section introduces Server Sent Events and WebSockets, these new features enable a new paradigm of Web application programming that will revolutionize the way to develop and deploy Web applications. The following sections examine Server Sent Events and WebSockets in more detail.

ServerSent Events

The HTML 5 specification introduces ServerSent Events, which formalizes the Comet programming technique using longpolling or streaming. The HTML 5 specification introduces a new DOM element called eventsource. The interface for this element is defined as below:

The following modified example from the HTML 5 specification illustrates how to use ServerSent Events.

You can also define the eventsource dynamically as shown in the code example below:

Each event is associated with a reconnection time and a last event ID. Per the HTML 5 recommendation, browsers should request additional information from the server after the reconnection time has elapsed.

Web Sockets

The WebSocket interface defines a fullduplex communications channel that is exposed via a JavaScript interface in HTML 5compliant browsers.

The example below demonstrates a typical usage of the WebSocket interface.

Step 1: Create a WebSocket with a valid URL

Create a new WebSocket connection to WebSocket server at finance.example.com.

var stockTickerWebSocket = new WebSocket(“ws://finance.example.com”);

Note that a ws:// and wss:// prefix indicate a WebSocket and a secure WebSocket connection respectively. The default port for WebSockets is 81 and the default port for secure WebSocket is 815.

Step 2: Attach JavaScript Callback Functions

Associate event listeners to handle each phase of the connection life cycle.

stockTickerWebSocket.onopen = function(evt) { alert(“Stock Ticker Connection open …”); };

stockTickerWebSocket.onmessage = function(evt) { alert( “Received Ticker Update: ” + evt.data); };

stockTickerWebSocket.onclose = function(evt) { alert(“Connection closed.”); };

Step 3: Send and Receive Data

To send a message to the server, simply call the postMessage method on the webocket with the content you wish to send to the server.

stockTickerWebSocket.postMessage(“BUY: GOOG,[email protected]”);

This will send the BUY message to the server. Any message coming from the server will be delivered to the onmessage callback registered in step #2.

Step 4: Disconnect When Done

When completed, call the disconnect() method to close the WebSocket connection.

stockTickerWebSocket.disconnect();

As demonstrated in the example above, there are no HTTP requests made to the server from the client side to retrieve data, instead the data was pushed to the client from the server – when it becomes available.

When a new WebSocket connection is established the browser opens an HTTP connection to the server first and then negotiates with the server to upgrade the connection to a dedicated and persistent WebSocket connection. This process automatically sets up a tunnel through to the server – passing through all network agents (proxies, routers, and firewalls) in the middle (very much like HTTPS establishing a secure, endtoend connection) , solving numerous issues that the various Comet programming techniques encountered. Once established the WebSocket is a fullduplex channel between the client and the server.

Summary

WebSockets and Server Sent Events proposed in HTML 5 specifications will enable development of new breed of web applications. Imagine having a TCP connection in your web application, WebSockets provide just that. Gone will be the days where web applications depended on the request and response architecture like Servlets and JSF did to get data from servers and display on web pages. Future Rich Internet Applications will be using ServerSent Events and WebSockets with dynamic user interfaces made possible by AJAX toolkits to deliver a richer, better, faster, and a truly connected user experience. Opera browser has already implemented the Server Sent Events natively. Firefox has a bug 338583 requesting Server Sent Events be implemented and a patch with implementation is being reviewed. WebSockets and ServerSent events are already on their way to reaching you in a future version of your favorite browser. So, go connect your web applications with real time data!

About The Author
Sidda Eraiah, Director of Management Services at Kaazing Sidda Eraiah has over 17 years experience in software development and has worked extensively on creation of development tools for Java EE, BPM and SOA technologies. Prior to joining Kaazing, Sidda worked as a lead developer at Oracle for 12 years developing successful products for Enterprise Applications development at Oracle: Oracle BPM Suite, Oracle SOA Suite, Oracle ADF, JDeveloper, and Oracle Forms.

Related

* Sidda Eraiah’s session @ IndicThreads Conference 2008, Pune, India

— How to build an enterprise trading solution using HTML 5’s WebSockets

— The Future of the Web: HTML 5, WebSocket, Java and Comet

* HTML 5 WebSocket cracks the HTTP request-response barrier