Easing into Comet

by Kris ZypDecember 5th, 2007

One of the most important keys to the adoption of a technology is minimizing the cost of implementation. While Comet scalability has received a lot of attention, and is certainly integral to Comet usage, the extent to which Comet is embraced will rely largely on how minimal the barriers are to using it. In his article on the growth of Comet, Joe Walker characterized the adoption of Comet as being induced by an increase in both the time spent on a single page and the frequency of changes to that page. There are certain applications where data is changing constantly and Comet is essential, such as stock tickers and chat clients. However, for most sites, page view time will not greatly exceed page change frequency overnight. Many applications will linger in the gray area for a while, where Comet may add some benefit, but not a huge benefit. There may be occasional server-originated messages, but not many.

For this large sector of potential Comet users, the question will be, is Comet worth it? The answer to this question will largely depend on the cost of Comet. How much resource utilization and effort will be required to use Comet? The potential cost of Comet includes client code increases, connection utilization, increased server loading, and more effort. What are the best ways to minimize these costs? In regards to effort, using a Comet framework can speed development, but I will focus on resource utilization. While a forever frame may be the highest performing approach for Comet, it is not necessarily the lowest cost. We will look at the path of least resistance to implement a form of Comet, and show the steps that Comet developers can take to advance from introductory Comet with light usage and towards the more powerful forms of Comet for heavy usage. With an understanding of the migration path, Comet developers can begin with simple forms of server-originated messaging, while utilizing abstractions that will allow smooth upgrades in the future.

Polling

While Comet is typically considered to be based on maintaining an open connection to a server so that the server can send a message to the client at any time, it is certainly viable for a client to listen for server-originated messages from a server through polling. Polling can be the easiest and least costly way to create a form of Comet. Polling has a number of advantages:

  • It can utilize the existing Ajax/XHR mechanisms in a framework
  • It takes very little code to implement
  • It does not usually have a connection open and therefore does not consume one of the precious two connections
  • Servers can provide immediate responses so they do not need to be retrofitted with asynchronous, non-thread consuming, long lived connection capabilities.

The following is an example of a simple polling mechanism:

setInterval(function() {
  doAjax("/checkForMessages",...);
},20000); // poll every twenty seconds

Smart Polling

Polling at a constant frequency is a naïve approach to polling, and can either be too infrequent or place an excessive load on the server. Polling can be more intelligent. While the optimal intelligent polling technique may be dependent on your application, one approach is to monitor user activity and employ an exponentially increasing poll time during inactivity. This can be done by starting with a short poll time (like 5 seconds) and multiplying the poll time after each poll (multiplying by 1.5 is a good ratio). An event listener can be attached to the events such as mousemove and keydown for the document body, and whenever these are triggered the poll time is reset to the initial value. This allows the polling to remain frequent for active users, but an inactive browser will gradually slow down its polling so as not to unnecessarily load the server. Smart polling can provide low impact, easy entry into Comet.

Long-Polling

Long-polling is a request that does not receive an immediate response, but rather the server responds when it has a message to send. This is a lower latency approach than polling because the server can send a message at anytime (as long as there is an active long-poll). Long-polling also does not usually require an additional transport mechanism, but rather can utilize an existing Ajax wrapper. From the client, long-polling works almost the same as polling, except that the next poll request is issued after receiving a response from the current poll request. Therefore, it is still easily implemented on the client.

Long-Poll Abortion

One of the main disadvantages of simple XHR based long-polling is that it consumes one of the two available connections. One can circumvent this problem by using a different domain for the requests in combination with JSONP, or doing the requests from a frame with a different host name (but same document.domain). These are viable options, although they do incur some cost in name lookups and additional transport mechanisms. However, if you have your own XHR wrapper, or can modify it, another approach called long poll abortions can be used. With long-poll abortions, anytime an XHR call needs to be made the open long-poll is simply aborted. The XHR object has an abort method that is called to end the connection. By ending the connection, the connection is freed for other resources to be requested. In situations where the only resources that will be requested will be through XHR requests (no images or CSS will be requested after initialization), the XHR wrapper could abort long-polls only when a second XHR request is being made. Once the XHR request is finished, the long-poll request can be created and opened once again.

On the Server

Thread-Based and Asynchronous Connections

Even when Comet messages are not frequently sent from the server, if you are using long-polling or HTTP streaming, every Comet-enabled user will be keeping a HTTP connection open indefinitely. This can create a large number of open connections on the server, and large scale applications must use asynchronous connection handling rather than the traditional server architectures which utilizes a thread for each connection. Greg Wilkins has published calculations for resource utilization of Comet. However, when “easing into Comet”, many applications may not necessarily have large enough traffic volume to warrant a need for asynchronous Comet request handling. If your site is expecting 100,000 visitors a day and each one keeps a connection open for an average of two minutes, this would equate to approximately 138 connections open at once on average. Even if each of these connections equates to a thread, this is still very much within the capability of most servers (although it may require the max thread count to be raised), assuming most Comet threads are usually in a wait state. If significant effort is required to port an application to asynchronous Comet capability, it may be easier and viable to use more traditional thread-based connections.

Asynchronous Server Connection

While thread-based connections may be easier and more portable, true Comet asynchronous request handling is certainly more scalable and puts less load on servers. There are numerous emerging technologies available for building truly scalable Comet applications. Tomcat and Jetty include Comet support, and Cometd, Meteor, LightStreamer, Orbited, and others are built specifically for Comet messaging. If your application grows in popularity, you may eventually need to use this technology.

Back to the Client

When your web application has reached a point of heavy Comet utilization, you may eventually want to upgrade to streaming with forever frames for continuous connections and sub-domains to avoid connection consumption. In the meantime, you can ease into Comet with lightweight techniques, but remember to properly abstract your Comet code to ease the upgrade of implementation in the future.

12 Responses to “Easing into Comet”

  1. Alessandro Alinone Says:

    Just a note on taxonomy. In Lightstreamer we use the term “Smart Polling” as a synonym of “Long Polling”.

  2. Kris Zyp Says:

    Perhaps “Intelligent” Polling would be a better word to use for polling that is of non-fixed frequency, and is based on knowledge of the current need for frequency?

  3. Comet Daily » Blog Archive » Comet works, and it’s easier than you think Says:

    [...] Articles Easing into Comet by Kris Zyp December 5th, 2007 Cross Site Scripting Joy by Andrew Betts December 4th, 2007 The [...]

  4. Alessandro Alinone Says:

    Kris, yes, I think “Intelligent Polling” is currently an available term ;-)

  5. Jose M. Arranz Says:

    I think “polling” shouldn’t be used to talk about COMET, I think the “spirit” of the COMET term is “server originated/server push”, “AJAX timer” is better.

  6. DylanSchiemann Says:

    I think that any type of polling such as long pulling or intelligent polling is in scope for discussion as a Comet technique, as the point of Comet is to get better performance than you get with traditional polling. Given that Cometd supports long-polling, I think it’s not worth the effort to exclude that from the Comet discussion. That said, traditional polling as a starting point for Comet discussions still seems appropriate… it’s just the reference point we always want to beat.

  7. Jose M. Arranz Says:

    For me:

    * long polling = AJAX COMET (complementary to the “never loaded page” or “never finished XHR request/XHR streaming” techniques)
    * polling = AJAX Timer
    * smart Polling = AJAX Timer mixed with user actions

    Long polling is a true “server push”, true COMET, because the server is responsible of delivering the data to the client when this data is generated in the server.

    I like more “long polling” because is true COMET, “never loaded page” and “never finished XHR request” are a bit dirty hacks for me.

    I think the “polling/smart polling” technique included in the COMET term is confusing to the people.

  8. Mark Says:

    Jose is right. Half of this blog post is misrepresenting regular AJAX techniques as Comet.

  9. Kris Zyp Says:

    I certainly do not have any problem with not calling polling “Comet”. But the article is about how to implement asynchronous server side events, and how to progressively move from simple low cost techniques towards an implementation that uses advanced Comet techniques. Whether or not you call the entry level techniques as “Comet”, is not terribly significant to me.

  10. Jose M. Arranz Says:

    Kris Zyp: “But the article is about how to implement asynchronous server side events, and how to progressively move from simple low cost techniques towards an implementation that uses advanced Comet techniques.”

    Good point.

  11. Comet Daily » Blog Archive » Buzzword Overload Says:

    [...] Long Polling: Long polling mostly means Comet without full streaming, i.e. the server is sending messages to the browser asynchronously, however in order to flush proxies the server is closing the connection soon after data is sent, and asking the browser to reconnect. Sometimes the phrase ‘long polling’ is used synonymously with Comet, though, and the phrase Long-Poll Abortion may be used. DWR has an early closing mode which implies long polling. Intelligent Polling and Intelligent Long Polling are similar and have a variable polling frequency based on user need. Kris Zyp talked about them in his article “Easing into Comet.” [...]

  12. Reverse Ajax s DWR, Spring, iBatis | Vlastův blog Says:

    [...] Easing into Comet [...]


Copyright 2015 Comet Daily, LLC. All Rights Reserved