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
No comments:
Post a Comment