HTTP and HTTP based server push

Overview
HttpPush refers to the mechanism whereby an Http Server is able to send data to the HttpClient as and when it is available instead of waiting for client to Poll the server, thereby facilitating an http based real time notification platform. This blog discusses and showcase the available approaches for designing an Http Server Push (unlike the conventional Http Pull) based solution for a business model. This document does not make a comparative study between the different approaches as each one of them is suitable for a particular business scenario. It also discusses some finer details of Http protocols (but not all) for better understating of the protocol, the Http push approaches and its limitations. It highlights the end to end flow between an Http Client and Server for each of the approaches.
The below section is divided into two parts - HTTP Overview and Server push approaches.
Http Overview: Please follow HTTP Basic Flow Overview
Server push approaches

ShortPolling
This approach is not exactly an Http Push, but still can be used to get data in near real time from the Http Server. This is applicable for both Http1.0 and Http1.1. Typically; this is chosen when no other option is available due to some constraints on the client side programming. As the name suggest, ShortPolling is a mechanism to continuously poll the Http server. With each Http Request, the server should check if there is any new data available, then it sends the same else send a blank Http Response. HttpClient makes a next request after a delay (say 1 sec) after the HttpResponse for the previous one is received. And this goes on and on and on.

• Though with Http1.1 (Persistent Connection), it can use the same (persistent) connections for all the requests/responses, but still this is a waste of resource, time, bandwidth, network where the chances of getting new data with every request is less. This may be useful where there is chance of high data availability every second like the Stock market
• This can be useful when a server can determine the time for next availability of data and instead of sending back a blank response, it sends the (future) time for availability of new data. The next request from the client can be triggered based on the time received with the previous response.

Long Polling
Unlike Short (regular) polling, Long Polling is the mechanism where the HttpRequest is held by the Http Server until some data is available at the server side. Http Server sends the Http Response only when data is available on the Server. HttpClient then again sends a new Http Request and this process goes on. If the physical connection gets disconnected for whatsoever reason, the client has to detect it and make a new Http Request.

• Long Polling is a good option over Short Polling if the data available at Http Server is not so frequent, since it saves from establishing new connection (in Http1.0) frequently; and bandwidth with unnecessary and worthless Request-Response pair.
• Long Polling tends to become Short Polling if the frequency of new data at the Http Server is high.

Http Streaming
Http Streaming is another popular technique in the industry for server push. However, this is yet to be standardized and endorsed in the Http protocol. As a result, each individual Http Server has its own implementation of Http Streaming (like comet with Apache Tomcat) and is not portable across the servers.

• This technique essentially leverages the enhancements on Http1.1 and henceforth is not possible with Http1.0.

Http Streaming is the mechanism where the Http Connection created by a Http Client 1.1 is held for long long time (, unless it is forcefully disconnected for some non-business reasons) by the Http Server and it sends back the responses essentially through chunked messages as and when it is available. In case of disconnection, the HttpClient has to re-initiate the process.

• To protect the HttpConnection from forceful disconnection for non-business reason when the connection is ideal for long time, a "heart-beat" data or event should be send as a chunked message periodically. Such heart-beat messages should be ignored by the Http Client.
  
  
• In Http Streaming, the data has to be send through "chunked" (Transfer-Encoding=”chunked”) messages in the Http1.1 Response.
• The persistent Http Connection used for Http1.1 cannot effectively be used for other Http Requests as the first Http Response is never completed and supposed to be held for long long period.
• Http Streaming should be used wisely since connection in streaming is very scarce for the fact that at one hand the HttpConnection in streaming is hold for long time and cannot be used for multiple requests as such and on the other hand there is also a recommended limit of 2 connections between an HttpClient and HttpServer.

Facts and Findings

• Who creates the "chunked" formatted messages?
  A "chunked" (0[chunk-extension]CRLF) formatted message is typically created by the Http Server(like Tomcat) and Http Client (like browser) when the "Transfer-Encoding:chunked" is present in the header. However this may vary from server to server and in some cases the handlers (like JSP, Servlet) may need to create it explicitly.
  
  
• When the "chunked" formatted messages are created?
  As mentioned above, it depends upon what HttpServer, HttpClient is being used and how the Handlers are written. It may be required to create the chunked messages completely in the handler itself. In case of Tomact6.0, when the handler (jsp, servlets) calls the HttpResponse.flush(), Tomcat6.0 assumes it to be a Chunked message if "Content-Length" header is not present in the Response headers. In that case, it sets the "Transfer-Encoding:chunked" with the first flush() and internally creates the chunked message with the data to be send, whenever the flush() method is called. On HttpResponse.close(), it sends the last chunk and closes the HttpResponse (but not the connection).
  
  
• What data is actually received by the end user when chunked responses are sent? Does it include the chunked length and chunked extension also?
  Http Server (Tomcat, JBoss etc) and Http Client(browser, apache client) which confronts the HTTP protocol at the first level, actually, receives the raw data which obviously contains the Chunked information like length, extension, CRLFs etc.. However, the client side handlers (java script, or developer classes) and server side handler (jsps, servlets etc) may not receive such Meta information but the actual business data, since in that case Meta information has already been extracted by the Http Client and Http Server. But again it depends on what Server or Client it is confronting.
  
  
• How threading is involved and what it is the impact of Long Polling and Steaming on Threading?
  Typically, the worker thread from the Http server calls the handlers (jsps, servlets) and expects all the processing to be done on the same worker thread. Returning from that thread would close the Http Response. This flow would actually block the worker thread, which is a scarce resource, till the processing with the Response is finished. And hence the impact of Long Polling and Streaming is costly w.r.t threading.
  
  
• How threading is managed in Tomcat in case of Long Polling and Streaming?
  Tomcat6.0 has introduced a native but different approach to deal with threading. Since the approach is native and is not standardized, this is not portable across servers.
  Tomcat6.0 has introduced two new Connector viz. "Http11NioProtocol" and "Http11AprProtocol" for asynchronous processing where the thread(s) employed to read data from socket connection is different from the one which is employed to process those data i.e. the reader and processor threads are different.
  "Http11NioProtocol" which utilizes the java NIO packages for its IO handling. This saves Tomcat6.0 to create different thread with each new socket connection. With NIO connector, Tomcat6.0 can employ a single thread to read through all the Socket connections on time-sharing basis and deliver the data to a different handler thread created by Tomcat6.0.
  "Http11AprProtocol" does the same thing and supports the asynchronous processing but in a different way.
  Apart from this, it has also introduced a new API "CometProcessor API" which can be utilized to process the Requests (business data) and Responses through a thread, not created by Tomcat but User.
  Combination of CometProcessor API with any of the APR connector actually delivers the HttpRequest, HttpResponse and Http data encapsulate in a Comet Event. Comet-encapsulated HttpRequest, HttpResponse and Connection are not closed or disconnected by the Tomcat6.0 automatically when the Tomcat thread returns, but the handler classes has to do it explicitly. Calling HttpResponse.close() on the comet handlers would actually close the communication channel and presence of "Connection:close" header would also close the physical connection.
  
  
• What is the impact of such a header? Who sets the "Connection:close" header?
  Presence of "Connection:close" header in HttpRequest and HttpResponse would require the HttpServer to close the physical(socket) connection after the corresponding HttpResponse has been sent.
  "Connection:close" header may be explicitly set by the server and client side handlers.
  Also, HttpServer and HttpClient can set the header, if required. Say, in case of Http1.0 Request received by the Http1.1 server, the HttpServer should set the “Connection:close” header and closes the connection after Response has been sent.
  
  
• With chunked request and response, is it possible to send chunked messages in response with partial chunked request data being received but not the complete request data?
  As per the Http specification, The Http Response should start after the complete Http Request is received and processed. So, a chunked Request should be received by the HttpServer completely and then it should send the Chunked Response. However some Http Server may allow such kind of functionality but that is not standardized by the Http Sepcification and is not portable across the servers.
  
  

Conclusion

• ShortPolling is easy, simplest, satisfies the Http Vision but leads to wastage of time, resource and bandwidth.



• LongPolling, a modified version of ShortPolling, is good when messages at the server are less frequent. Though it does not consume unnecessary bandwidth unlike ShortPolling but it may sometimes block the worker thread in the server. Hence, it is not that much scalable. However the CometAPI version of long polling overcomes this problem.
  
  
• HttpStreaming is not standardized but is a good option and more complex. It is suitable for scenarios where a single Request is acknowledge with continuous stream of data.
  
  
• Some of the HttpPush model like in “HttpStreaming” may behave and implements differently from server to server. Developers should take a note of the Server features before choosing a particular strategy.