Tuesday, February 28, 2012

Cast of Dynamic Server-Side Invocation

In this post it will just be a discussion on the topic mentioned.

Earlier it was simply client asks something from server and server returns it back. Only if client made a request, server processed it. This still exists in many web applications. But if consider many web applications like Facebook, Twitter & even Google apps, even without user interaction sometimes server makes notifications to user if any. 'If any' is much important otherwise constant checking on server-side update from apps in client-server architecture is not efficient as it consumes considerable system resources repeatedly and less scalable.

Few concepts and technologies for server-side invocation is listed and discussed below.


If you intend to use ajax for server-side invocation, as a developer you have to think twice. Most occasionally think is this what you are really expecting.

Something to be alert

Ajax is a variation of java script. It dynamically pulls data from server side hiding in client side web apps. It also leverage asynchronous interaction as it runs in background without blocking client side. That is where it differs from typical java-script. Therefore be noted that AJAX does not define new kinds of HTTP requests or anything else. It just performs a HTTP request in the background by using XMLHttpRequest API.

Therefore in Ajax as it does not help to pull data to client, but just polling data  from server, in an application like web mail client, logic will be like constant checking on server-side update & poll the results. This polling approach causes an event latency which depends on the polling period. Increasing the polling rate reduces event latency. The downside of this is that frequent polling wastes system resources and scales poorly. Most of the time this result can be empty as no sense on real-time updates.


Comet (aka Comet programming) is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet attempts to deliver “push” communications by maintaining a persistent connection or long-lived HTTP request (long poll) between the server and the browser. Like AJAX, Comet is build on the top of the existing HTTP protocol without modifying it.

Two things to know about HTTP
  • HTTP protocol is not designed to send unrequested responses from the server to the client.
  • A HTTP response always requires a previous HTTP request initiated by the client.
Then how comet addresses these initiative issues in HTTP.

Long Polling

As in general HTTP, client sends request to server, but server does not reply immediately. This is because of event driven process handling. Only if an event occurs in server-side, server will response including the event data. After receiving the response containing the event data, the client will send a request again, waiting for the next event. There is always a pending request which allows the server to send a response at any time.

HTTP Streaming (aka HTTP server push)

Server keeps the response message open. In contrast to long polling the HTTP response message (body) will not be closed after sending an event to the client. If an event occurs on the server-side, the server will write this event to the open response message body. The HTTP response message body represents a unidirectional event stream to the client.

Finally all these mechanisms run on top of existing HTTP. Only thing is they have been adapted to keep a live connections from server to client.


Comet programming has been achieved in HTML5 by using Server-Sent Events (SSE). Browsers which support HTML5 & SSE open an HTTP connection for receiving data from server side push notifications. This implicitly managed by underling SSE API. Server-Sent Events includes the new HTML element EventSource as well as a new mime type text/event-stream which defines an event framing format.

var source=new EventSource("EventGen.php");
source.onmessage=function(event) {


The EventSource represents the client-side end point to receive events. The client opens an event stream by creating an EventSource, which takes an event source URL as its constructor argument. The onmessage event handler will be called each time new data is received. The valid header defined by SSE spec is text/event . However a valid Server-Sent Events implementation has to support the mime type text/event-stream at minimum.Therefore from server-side explicitly define header type to text/event-stream.

SSE are based on HTTP streaming. SSE has performance drawbacks with respect to some existing protocols but yet potential to be become the dominant protocol for use cases such as just a unidirectional server push channel is required. The Sever-Sent Events protocol is much simpler. 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.