Introducing websocket (client server two way communication or reverse AJAX)

Today, Web applications needs a more frequent and fast mechanism that can deliver resources to browsers more quickly. The typical application on which we really care about speed and Instant Updates are chatting, games, online trading, stock tickers, live maps and social networks. To handle this kind of situations we need a mechanism that can provide a resource directly to the client without the client asking for the resource.

In traditional HTTP request response model a server can normally send a resource to the client when the client explicitly requests it, but the server cannot start sending the resources until the client actually makes a request for those resources. This wastes time and makes the page take longer to load.  Server push is a mechanism that allows the server to send particular resources to the client without waiting to be asked for them. Following are the techniques that have been using for this purpose over the years.

Traditional Polling

In this approach the browser keeps sending requests continiously on a defined time interval and the server responds immediately each time. Traditional Polling is a helping approach where polling can be done at time intervals. But, the approach becomes inefficient when the application needs extremely frequent update like trading and chatting apps.

Long Polling

To overcome the overhead of multiple request/response, long polling is used.

In Long Polling the browser keeps sending requests but the server responds only if it has new information to send. But there is still overhead of multiple requests made by the browser, moreover browser and server can go away if there is no update for a period of time.

HTTP Streaming

This is something like long polling, browser sends a request to the server and the server keeps the response stream open to send more updates as they arrive. It works by breaking the overall stream into a sequence of small HTTP-based downloadable file. But the client and server need to agree how to interpret the response stream so that the client will know where one update ends and another begins.

WebSocket Protocol

Browser send a request to server to upgrade HTTP to Web Socket and if the Server supports Websocket, it send an response saying ok I am upgrading your HTTP to a single long running HTTP connection. Thereafter browser and server starts send data frames in both directions over a TCP socket. The WebSocket protocol is designed for scenarios where messages need to be exchanged between browser and server at a high frequency. Yet, there are significant challenges since a majority of deployed browsers that do not support WebSockets.

Image Source

As we can see , all popular browsers have a very low acceptance of Websocket and that too on new versions only. Android browser does not support websocket at all, this thing should be taken care of.

Today, i am going to share my findings on ‘What role Websockets plays in Server Push and Two way communication’. All server push technologies are used to establish an two way duplex band between client and server. Ajax, polling and comet like technologies have been using over the years.

What is the need of ‘Websocket’ ?

Frequent data can be achieved with a number of techniques, but that is not sufficient these days .We have to implement a mechanism that can do the same job with less server overhead .Websocket is introduced to gain reverse data with a less number of connection and using a very low bandwidth.

Two way messaging over a single TCP connection, Not Http but relies on HTTP with a less overhead .In this way it simply upgrades HTTP protocol.

If websocket is that great than why ‘long polling’ is being used for consistent connections ?

The first answer to this is browser support of websockets , as you can see the chart below.

If we see the interesting part most of the browser’s latest version do supports web sockets but we can not be so sure if the users are using the latest versions of the browsers.

Others thing is that most of the browsers was made to use HTTP base protocols and do not made for an long open connection , So the browsers can terminate connection if the server does not respond for long time. Moreover because of some security reasons caching , firewalls and filtering can be a cause of connection termination.

The next issue is related to proxy connections ,in this kind of scenario , even if we are able to establish a connection than the initial frame would be send by using actual http protocol but after that the traffic would be based on websocket two way handshaking and if the proxies are not configured properly as they are not configured by default than  the protocol upgrade would be failed.

Another issue is related to Internet Connection Reliabilty as we have seen most of the chat application  makes the activities on hold and shows the used offline if there is no interaction between browser and server for a specific time. So both browser and serven can go away.

At the end even if we are able to fix all these issues and are able to send and receive messages instantly , Than we do not have any kind of confirmation if the message is being delivered successfully or not . So we need to configure a top level protocol over websocket to make the confirmation possible.

In some cases we have a lot of data to transfer continiously in between the client and the server so we need to implement some kind of buffering on both sides.

So these are the sort of pre requirements that we have to setup to make an secured web application.

Web Socket Protocol

The WebSocket protocol has been standardized by the IETF as RFC 6455.

All the communications and data transfer are done over a TCP port number 80. WebSocket also requires web applications on the server  to support it.  WebSocket provides full-duplex communication like TCP but Websocket enables a stream of messages instead of a stream of bytes.We  have two type of data schemes.

Encrypted - wss://

Un Encrypted -  ws://

Advantages of WSS (secured web socket protocol)

To use ‘WSS’, this is a secured web socket protocol , this will help because encrypted traffic is not going to interpreted by intermediate proxies. And most likely to not being buffered or cached on browser level.

As there is a resource cost associated with this WSS (secured web socket protocol), we can explicitly make proxies supportive to web sockets.

WebSocket  and  Java

WebSocket is a combination of  IETF RFC 6455  Protocol and  W3C JavaScript API. The protocol defines an initial handshake and data transfer. The API enables Web pages to use the WebSocket protocol for two-way communication on same host.
The Java API for WebSocket is worked upon as JSR 356 in the Java Community Process. This will define a standard API for building WebSocket  enabling java applications.

W3C API supports binary data communication with server using in BLOB and Array Buffer format of Java Script.We have event handlers like onopen() , onmessage() , onerror() and onclose() to communicate with server.

Hope it helps !

Nagesh Chauhan

www.oodlestechnologies.com