29
Oct
This entry is part 6 of 5 in the series HTML5 Series

What are we going to talk about in this blog?

In this blog, I shall introduce you to the power of WebSockets – a new technology providing bidirectional, full-duplex communication channels over a single TCP socket, solving most of the issues faced in real time communication.

What’s in it for me?

I have heard a lot of people assuming that HTML5 just deals with UI components and has nothing for programmers. This article puts this apprehension to rest.

Is it really worth it?

Real-time applications such as stock trading, banking, financial applications, online gaming, gambling, etc. need very reliable and high performance systems. Imagine you playing an online poker game on Facebook and waiting for the other player to finish their turn. It is, at times, frustrating just to wait for your turn as the communication is not fast enough and even though it is nearly happening in real time, you can still feel the delay. The above example is not that critical, but imagine the delay in stock trading, banking, financial applications, currency exchanges, etc. To cite another example, the Indian currency exchange rate changes 10 to 15 times in a minute. Even a small delay could be crucial.

Anatomy of HTTP

HTTP, which is widely used, is only half duplex, i.e., the data can flow only in one direction at a given time, thereby making real time communication difficult. Also, each request and response has header information which adds to the network traffic. To find out the HTTP request and response headers, you can use an application like the Live HTTP Headers add-on in the Firefox browser and then see the results. There is a lot of unnecessary HTTP request and response header information overhead, at times, as much as 2000 bytes.

But I already have applications running on the Web! Why use WebSockets?

Some techniques used such as polling, long-polling and streaming have their own limitations:

Polling: This technique is used in Ajax applications to simulate real-time communication. I was really impressed when I had first used the Ajax concept and was happy that only the part of the Web page which needs to be refreshed is refreshed, and not the whole page. The XmlHTTPRequest was God’s own gift! But even Ajax needs us to keep polling to check whether the server has sent any response. This is achieved by the value of the readyState property of the XMLHttpRequest object:

If(http.readystate == 4) // meaning request is complete
{
	Call the function to process the data
}

Long polling: This is also known as asynchronous polling. The browser sends a request to the server and the servers keeps the request open for a long set period hoping that the process is completed within the period.  Thus the name long polling (but polling nevertheless).

Streaming: This is better than the above two techniques but faces possible complications when firewalls and proxies come into picture. The responses keep on getting built up and must be flushed periodically.

A step forward – beyond hacks

Enter HTML5 WebSocket to solve the above issues. It is a W3C API and IETF protocol, details of which can be found at http://dev.w3.org/html5/websockets/ or http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-03.

WebSocket is a fully duplex single socket. It creates a channel between the browser and the server where two-way communication can be performed. The client (on the browser) does not poll whether the response has come or not. The client and server can send data to each other through WebSocket freely. It shares the port with the existing HTTP content. It easily traverses through firewalls, routers, proxies, etc. This is also known as Push technology. The server just pushes the data to the client and does not mandate the client to keep polling for data.

There are 2 schemes provided by WebSocket:

  • WebSocket scheme  - ws://www.websocket.org/text
  • WebSocket secure scheme – wss://www.websocket.org/encrypted-text

WebSocket Architecture

WebSocket Architecture

The browser clients communicate with the WebSocket server using the WS scheme and the WebSocket server communicates with the backend servers using TCP. There are various WebSocket servers available and the best of the lot is undoubtedly the Kaazing WebSocket Gateway. An evaluation copy of the same can be downloaded from www.kaazing.com.

There are some backend servers which understand the WebSocket scheme and can accept the requests directly from the browser clients. ActiveMQ 5.4.0 is one such server which I have come across. The WebSocket architecture diagram would then be as follows:

WebSocket connection uses the same TCP connection as it upgrades from the HTTP protocol to the WebSocket protocol. Once it is upgraded to the WebSocket protocol, then the data can be sent back and forth between the client and the server in full-duplex mode.

WebSocket data is sent in frames, where each frame of data starts with a 0×00 byte and ends with a 0xFF byte. In between the start and end bytes, it contains the UTF-8 data, for example:

\x00Hello, WebSocket World\0xff

There is no limit defined for the size of the data which can be sent as long as the user agent can manage it. Since JavaScript does not allow more than 4GB of data, so that is limit.

With WebSocket, each data packet (frame) has only 2 bytes of packaging and so the overhead is a minimum, when compared to the header information in HTTP request and response headers. There is no latency in establishing the new TCP connections for each HTTP message. Hence there is significant reduction in network traffic and latency.

There was a talk recently when W3C came out with a warning to go slow while embracing HTML5, but the good news is that all the important players such as Microsoft, Google, Mozilla and Apple are going ahead full steam supporting WebSocket in their browsers. The browsers which support the WebSocket as of now are:

  • Chrome 4.0 +
  • Firefox 4.0 Beta 1+
  • Safari 5.0 +
  • IE 9.0

There are two ways to check whether your browser supports WebSocket or not. The first way is to just go to www.websocket.org and on the top right side, you will get a message saying whether your browser supports WebSocket or not. The second way is to write a simple JavaScript code and check it yourself.

if (window.WebSocket)
{
alert("Yahoo !! Your browser does support WebSocket!");
}
else
{
alert("Sorry!! Your browser does not support WebSocket");
}

Now let us see how easy it is to use the WebSocket object.

var objWebSocket = new WebSocket(url);

The URL above is the address of the server to which you want to create the WebSocket connection to. For e.g., talk.google.com:5223 (the Google Talk server).

WebSocket programming is event based. Once the WebSocket is opened, we just wait for events and do not poll the server for data. There are 3 events associated with WebSockets and we need to code listeners for each one of them and associate the listeners with the events. The 3 events are open, message and close. The open event is fired when the WebSocket connection is opened successfully. The message event is fired when the server sends data. The close event is fired when the WebSocket connection is closed.

For e.g.:

objWebSocket.onopen = function(evt)
{
alert("WebSocket connection opened successfully");
};
objWebSocket.onmessage = function(evt)
{
alert("Message : " + evt.data);
};
objWebSocket .onclose = function(evt)
{
alert("WebSocket connection closed”);
};

Once the WebSocket connection is opened, the onMessage event is fired when the server sends the data to the client. If the client wants to send data to the server, it can do that easily as follows:

objWebSocket.send("Hello World");

With WebSocket, you can communicate with WebSocket servers and via that to any back-end servers or any message brokers. You can extend any TCP-based protocol to the Web like XMPP, Jabber, Publish/Subscribe protocols like Stomp & AMQP, gaming protocols like Darkstar, etc.

References:

Chirag Trivedi
Chirag Trivedi– Lead – HTML5 Group

Related posts:

  1. HTML5 Series: Part 3: New HTML5 Form Elements Hope you have been enjoying the series on HTML5 so far, where we covered HTML5 GeoLocation and the Javascript library Modernizr. In this part of the series, we shall cover...
  2. HTML5 Series: Part 4: More on Geolocation Welcome to Part IV of this series. We covered the basics of HTML5 Geolocation support in Part I of this series. In that article, we looked at how an HTML5...

4 Responses to “HTML5 Series: Part 6: WebSockets”

Add reply