COMET: Pushing to the web browser

A technology which is making a lot of advances in the world of the web is COMET. COMET is the name given to a group of techniques for pushing data to the browser using JavaScript. Being a Request/Response architecture, HTTP is not really designed for sending data to the browser on demand, COMET enables this.

So a bit of background here. Traditional “AJAX applications” often continually poll for changes and update the screen accordingly.  In fact, in ASP.NET, a very easy solution is to combine an asp:Timer class with an asp:UpdatePanel and simply re-render the changing content every few seconds and send back the updated HTML.  Taking this to a more advanced level, it’s possible to send data back to the browser (typically as JSON) and then use DOM manipulation to update the elements viewed on the screen.

To give a more concrete example, imagine a simple “chat room” application.  A simple solution could be to render a div with the list of chat messages in it, wrapped in an UpdatePanel, and then provide a text box for entering chat messages.  When the user presses “enter” within the textbox, an AJAX request is made to send the message back to the server, and the server adds this message to the list of chat messages.  The update panel can then be refreshed using a timer.

What are the problems with this?  Two things – scalability and latency.

Firstly, we are sending back the rendered HTML each time - this is not the most efficient use of bandwidth (i.e. each chat message is likely wrapped in a few elements).  Secondly, every time the UpdatePanel is refreshed, the entire chat history has to be sent back.  As this grows this will be become problematic as the amount of data being processed and sent over the network will increase exponentially with the number of users contributing to the chat.  Finally, as we are polling (say once every 5 seconds) there is a lag involved between when a user enters a chat message and when another user receives the message.  These are potentially not major issues, but in this day and age the average web user’s expectations are quite high - they expect lightweight, fast and responsive web user interfaces!

We can solve each of these problems in turn.  To resolve the first issue, we can remove the update panel, and replace it with an AJAX call made using a standard JavaScript “setTimeout()” function.  Instead of sending back HTML using an UpdatePanel, we send back an array of JavaScript objects encoded as JSON.  Each object represents a single chat message and could have the following properties – ID, Source, Message.  The AJAX response handler would render the appropriate HTML from the JSON objects (for example, using ASP.NET 4’s client side templating).

Once you have JSON objects coming back to the browser, the second issue becomes easy to solve.  The browser can send back the ID of the last message it received, and the server only needs to send back those messages which were received after that.

It’s when we try to resolve the latency issue that the this technique becomes problematic.  The only real solution using plain old polling is to increase the polling frequency, which leads to a huge waste of server resources.

So we come back to COMET, which is a technique (some might say hack, but I disagree) of pushing data to the browser using standard HTTP requests.  There are alternatives to this approach, namely using browser plugins.  Flash and Silverlight both have support for raw sockets, and Silverlight has the “polling duplex” WCF transport (which I may discuss in a later post).  However, COMET is a solution which has been designed from the ground up to use standard web technologies and run over HTTP.  I will discuss the technical details of COMET further in the next post… this post is really just an introduction and to point out that I have started working on a project which will enable COMET via ASP.NET hosted in IIS!

More to come…
Neil

MessageBox.Show in Silverlight

Well, it's kind of obvious to anyone that has done any browser based Javascript development, but thought this was worth posting for those of you that do a lot of Windows Development and are wondering how to show a MessageBox in Silverlight. For those of you that have tried it:

MessageBox.Show("Hello world!");

OOPS! Compiler error... that doesn't work, Silverlight does not have a MessageBox class like WPF / WinForms / Win32. Instead, you can ask the browser to do this for you. How do you do this you might ask?

HtmlWindow.Alert("Hello world!");

This is the exact equivalent of the javascript alert function, which would look something like this:

alert("Hello world!");

So what if you want more control? Well, you will find the browser does not provide quite as much as desktop apps for this. In WPF, you can control the message, the title, the icon, the colours, buttons and more! Alert() will simply display a normal dialog with an OK button and the message, and a browser dependent title. The other option the browser gives you is to display a message box with "OK" and "Cancel" options and to be able to read the result of what the user chooses. In WPF you would do:

DialogResult result = MessageBox.Show("Shall I proceed?", "Title", MessageBoxButtons.OKCancel);
if (result == MessageBoxResult.OK)
{
  // process the OK
}

In Silverlight, the equivalent is:

bool result = HtmlPage.Window.Confirm("Shall I proceed?");
if (result)
{
  // process the OK
}