Push over HTTP

There is a good requirements in industry where you need to update data over web in real time. But because of HTTP limitations you can't directly push data from server to client. so lets understand what all options do we have to simulate the PUSH environment.

If you have worked in any real time web application where data needs to be updated on UI in real time like Share trading platforms, reservation systems, ticketing systems, etc. you would have been easily understand the requirement and power of PUSH. for others lets understand why PUSH is important in many mission critical applications. for ex. a user using a share trading application where with some delay he get the updates of different scripts which he is looking to buy/sell. Now consider a scenario where user made a request to buy particular script at a given price he seen 5 sec's below. But because somebody else is also trading in the same script so the price will get  impacted accordingly. Now because you have seen the price 5 sec's before and placed an order accordingly there is a very higher chance that you may end-up buy that script in higher price. Which means there will be a problem of latest and recent state in the system. System which need continues update at almost zero network latency requires persistent connection between client and server to overcome the limitation of HTTP.

We all know, first, that we majorly uses HTTP as communication protocol for web development and second, its unidirectional and stateless in nature. By Uni-directional we understand that data will flow from one directional only i.e. only client can instantiate request for data and server can only send response against the same. It needs to be clear in mind that in HTTP protocol, server can't send any data without getting request from client which is actually a case of PUSH. So server can't PUSH data over HTTP to client if its not requested. 

Now how can we simulate PUSH in HTTP if Server can’t send the data without client order it, absolutely no, but as we know necessity is the mother of all inventions, there are couple of techniques by which you can achieve near real time push with some pros and cons.

1. Long polling
2. Server Sent Events
3. Web Sockets

1. In LONG POLLING the normal http request constructed using XHR is suspended at server side and the server keeps it suspended until it has data to deliver to the client. Once the server is ready with data it responds to the client on the suspended request and closes the connection. The process is repeated when client has to request for data.

Advantages: It's easy to implement on the client side with a good error-handling system and timeout management. This reliable technique also allows a round-trip between connections on the server side, since connections are not persistent (a good thing, when you have a lot of clients on your application). It also works on all browsers; you only make use of the XMLHttpRequest object by issuing a simple Ajax request.

Disadvantage: There is no main disadvantage but this one still relies on a stateless HTTP connection, which requires special features on the server side to be able to temporarily suspend it.

2. SERVER SENT EVENTS - Server-Sent Events (SSE) is a standard describing how servers can initiate data transmission towards clients once an initial client connection has been established. It is commonly used to send message updates or continuous data streams to a browser client and designed to enhance native, cross-browser streaming through a JavaScript API called EventSource, through which a client requests a particular URL in order to receive an event stream. When communicating using SSEs, a server can push data to your app whenever it wants, without the need to make an initial      request. In other words, updates can be streamed from server to client as they happen. SSEs open a single unidirectional channel between server and client

• The main difference between Server-Sent Events and long-polling is that SSEs are handled directly by the browser and the user simply has to listen for messages.

• Server-Sent Events are based on HTTP streaming. As described above, the response stays open and event data are written as they occur on the server side. Theoretically, HTTP streaming will cause trouble if network intermediaries such as HTTP proxies do not forward partial responses immediately. The current HTTP RFC (RFC 2616 Hypertext Transfer Protocol - HTTP/1.1) does not require that partial responses have to be forwarded immediately. However, a lot of popular, well-working web applications exists which are built on the HTTP Streaming approach. Furthermore, production-level intermediaries always avoid buffering large amounts of data to minimize their memory usage.

• In contrast to other popular Comet protocols such as Bayeux or BOSH, Server-Sent Events support a unidirectional server-to-client channel only. The Bayeux protocol on the other side supports a bidirectional communication channel. Furthermore, Bayeux can use HTTP streaming as well as long polling. Like Bayeux, the BOSH protocol is a bidirectional protocol. BOSH is based on the long polling approach.

• Although Server-Sent Events do have less functionality than Bayeux or BOSH, Server-Sent Events have the potential to be become the dominant protocol for use cases where a unidirectional server push channel is required only (which is the case in many instances). The Sever-Sent Events protocol is much simpler than Bayeux or BOSH. For instance, you are able to test the event stream by using telnet. No handshake protocols have to be implemented. Just send the HTTP GET request and get the event stream. Furthermore Server-Sent Events will be supported natively by all HTML5-compatible browsers. In contrast, Bayeux and BOSH protocol are implemented on the top of the browser language environment.

3.The WEBSOCKET specification defines an API establishing "socket" connections between a web browser and a server. In plain words: There is an persistent connection between the client and the server and both parties can start sending data at any time. WebSockets enables bi-directional, full-duplex communication channels, and many browsers (Firefox, Google Chrome, and Safari) already support it. The connection is opened through an HTTP request, called a WebSockets handshake, with some special headers. The connection is kept alive, and you can write and receive data in JavaScript as if you were using a raw TCP socket.

Advantages : WebSockets provides powerful, bi-directional, low-latency, and easy-to-handle errors. There isn't a lot of connection, like Comet long polling, and it doesn't have the drawbacks of Comet streaming. The API is also very easy to use directly without any additional layers, compared to Comet, which requires a good library to handle reconnection, timeout, Ajax requests, acknowledgments, and the optionally different transports (Ajax long polling and jsonp polling).

Disadvantages:

                                       i.    It is a new specification from HTML5, so it isn't yet supported by all browsers.

                                      ii.    No request scope. Since WebSockets is a TCP socket and not an HTTP request, request-scoped services, like Hibernate's SessionInViewFilter, cannot be used easily

SERVER-SENT EVENTS VS. WEBSOCKETS

Why would you choose Server-Sent Events over WebSockets?

One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn't need to be sent from the client. You simply need updates from some server action. A few examples would be friends' status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexDB object store). If you'll need to send data to a server,XMLHttpRequest is always a friend.

SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.

I had done long polling implementation in one of the requirement where i opted to go with CometD implementation. I observed it a good option for implementing near real time update feature in application. I have not opted out web sockets and server sent events as i dont found it scalable.