Comet: Low Latency Data for the Browser

An old web technology is slowly being resurrected from the depths of history. Browser features that have gone untouched for years are once again being employed to bring better responsiveness to UIs. Servers are learning to cope with a new way of doing things. And I’m not talking about Ajax.

New services like Jot Live and Meebo are built with a style of data transmission that is neither traditional nor Ajax. Their brand of low-latency data transfer to the browser is unique, and it is becoming ever-more common. Lacking a better term, I’ve taken to calling this style of event-driven, server-push data streaming “Comet”. It doesn’t stand for anything, and I’m not sure that it should. There is much confusion about how these techniques work, and so using pre-existing definitions and names is as likely to get as much wrong as it would get right.

Defining Comet

For a new term to be useful, at a minimum we need some examples of the technology, a list of the problems being solved, and properties which distinguish it from other techniques. As with Ajax, these aren’t hard to find. A short list of example applications includes:

So what makes these apps special? What makes them different from other things that might at first glance appear similar? Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.

From the perspective of network activity, we can modify JJG’s original Ajax diagram to illustrate how Comet differs:

As is illustrated above, Comet applications can deliver data to the client at any time, not only in response to user input. The data is delivered over a single, previously-opened connection. This approach reduces the latency for data delivery significantly.

The architecture relies on a view of data which is event driven on both sides of the HTTP connection. Engineers familiar with SOA or message oriented middleware will find this diagram to be amazingly familiar. The only substantive change is that the endpoint is the browser.

While Comet is similar to Ajax in that it’s asynchronous, applications that implement the Comet style can communicate state changes with almost negligible latency. This makes it suitable for many types of monitoring and multi-user collaboration applications which would otherwise be difficult or impossible to handle in a browser without plugins.

Why Is Comet Better For Users?

Regular Ajax improves the responsiveness of a UI for a single user, but at the cost of allowing the context to go “stale” for long-lived pages. Changes to data from others users is lost until a user refreshes the whole page. An application can alternately return to the “bad old days” and maintain some sort of state mechanism by which it tells client about changes since the last time they’ve communicated. The user has to either wait until they preform some action which would kick off a request to see the updated state from other users (which might impact the action they wanted to preform!) or request changes from the server at some interval (called “polling”). Since the web is inherently multi-user, it’s pretty obvious that regular Ajax imposes usability and transparency hurdles for users. Applications that employ the Comet technique can avoid this problem by pushing updates to all clients as they happen. UI state does not go out of sync and everyone using an application can easily understand what their changes will mean for other users. Ajax improves single-user responsiveness. Comet improves application responsiveness for collaborative, multi-user applications and does it without the performance headaches associated with intermittent polling.

But Does It Scale?

New server software is often required to make applications built using Comet scale, but the patterns for event-driven IO on the server side are becoming better distributed. Even Apache will provide a Comet-ready worker module in the upcoming 2.2 release. Until then, tools like Twisted, POE, Nevow, mod_pubsub, and other higher-level event-driven IO abstractions are making Comet available to developers on the bleeding edge. Modern OSes almost all now support some sort of kernel-level event-driven IO system as well. I’ve even heard that Java’s NIO packages will start to take advantage of them in a forthcoming release. These tools are quietly making the event-driven future a reality. This stuff will scale, and most of the tools are in place already.

I’ll be giving a more on this topic at ETech and describing the various techniques that Comet applications can employ to push data from the server to the client. As always, I’ll post the slides here as well.

The future of the read-write web is multi-user. There is life after Ajax.

Endnotes

First, a word on terminology and its importance. “Ajax” was coined to describe background request/response data transfer. Many of us had worked on solutions to do exactly this, but it wasn’t until a simple name and accompanying description were provided that it was possible for people not directly building applications to describe what it was they liked about it. Common terminology acts not only as a shortcut in discussions between technical folks, but also as a bridge for those who may not be able to give a technical rundown of exactly how it works.

As with Ajax, those of us who build technology are now faced with another communication challenge. We have a hard problem for which solutions are available (and have been for some time) but no way to communicate about them. Terminology is again the missing link. Today, keeping an HTTP connection open for doing low-latency data transfer to the browser has no digestible name. When I describe a cool new hack, there’s nothing to associate it with. When people say “how the hell did they do that?”, we don’t have a compact answer. Therefore, in the spirit of improved communication (and not technology invention), I’m proposing a new name for this stuff.

Next, for those who are network-level programmers or are familiar with sockets and/or basic TCP/IP programming, you will probably scoff at the concept of web applications finally getting this kind of datagram packet support. Fair enough. It is however interesting to note that while more responsive UIs have been available on a variety of platforms to date, the Web has “won” the broad majority of market share for most classes of applications in which the browser provides enough native (non-plugin) support to make the performance and/or UI feasible. Comet may be a new name for an old set of concepts wrapped in some pretty grotty hacks, but that in no way diminishes the market impact it will have (and is already having).

Lastly, as current Dojo users might expect, Dojo already supports Comet via dojo.io.bind(). More than a year ago we designed the API with Comet in mind. In the next couple of weeks I’ll be showing how bind‘s pluggable transport layer can be combined with Dojo’s event topic mechanism to provide message delivery on top of a message bus.

139 Comments

  1. Posted March 4, 2006 at 6:23 am | Permalink

    I wish we had a public version of AjaxWar up. Wouldn’t it qualify as Comet?

  2. John Christopher
    Posted March 4, 2006 at 8:14 am | Permalink

    This is great stuff. I work on DOD weather applications and have had to implement similar “hacks” to support this type of transfer. I believe we will be moving our stuff to dojo in the near future :)

  3. Posted March 4, 2006 at 8:56 am | Permalink

    Alex:

    Will you be presenting on Comet at the Ajax Experience?

  4. Posted March 4, 2006 at 10:23 am | Permalink

    Isn’t this just HTTP 1.0 style keep alive? I believe KnowNow implements this with HTTP 1.0… anyway… now we have something to call this. PeopleSoft apps use this style of communication for their Help Desk online chat apps (they OEM’d KnowNow’s pub/sub tools back in 2001). Like XMLHTTPRequest, it’s nothing new… but now we have a name for it… cool name btw.

    Rich

  5. Posted March 4, 2006 at 3:06 pm | Permalink

    Jeff: yes, I think AjaxWar qualifies

    Rob: If you like!

  6. Posted March 4, 2006 at 3:11 pm | Permalink

    Rich: yes, sort of. The difference is that you don’t initiate a new HTTP transaction for every datagram. Further, the client doesn’t initiate the connections. In the HTTP 1.1 model, a TCP connection is indeed held open for multiple requests, but it is always the client requesting discrete blocks of content and then rendering them once the transaction is complete. Comet breaks these assumptions.

  7. Pat
    Posted March 4, 2006 at 3:19 pm | Permalink

    So how well will a server cope with 1000’s of open sockets? Obviously, the problem of the server having a thread allocated (for threaded servers) will have to be fixed, but assuming they are, and we learn the new models of how to deal with this, I’m wondering if servers will really be able to handle the sheer number of open sockets.

    There’s definitely something to be said for stateless …

  8. Posted March 4, 2006 at 3:37 pm | Permalink

    Pat: If your server is using a threaded network responder layer, you’re pretty effed. OSes will handle that many open (10K+) fd’s without any problem whatsoever, however the deamons that read/write from them often run into scalability issues. Select and poll are O(n) in these cases, and we really want something closer to O(1). Linux’s epoll and FreeBSD’s kqueue give this to us at a kernel IO level. Your web daemon has to take advantage of them, however.

    This is where tools like Apache’s mpm\_event, Twisted Python, and POE come into play. They are event driven web daemons. That is to say that they don’t allocate an OS thread or process per connection. Instead, they deliver data asynchronously to waiting listeners on an event driven basis. These are the kinds of tools that let your server handle this kind of load without breaking a sweat. If, OTOH, you go with something like a traditional Apache+mod_whatever infrastructure, you’re just not going to scale.

    Consider that your traditional web server is designed to take a request, satisfy it as fast as possible, and close the connection and you can easily see that they just aren’t optimized for this kind of workload. I expect that all of our tools will lurchingly come up to speed for use with things like Comet, but the transition isn’t going to be pretty for folks who don’t grok the problems (and the potential solutions).

    Regards

  9. grumpY!
    Posted March 4, 2006 at 3:42 pm | Permalink

    time for yaws?

    one day the crayon crowd is going to have to start thinking about profiling and performance. be it insane server loads (for comet) or insane load on the client (massive DOMs, canvas, SVG, etc), users may start balking at some of this frosting.

    and once again i will offer the offtopic comment i always offer when i see “meebo” – you are insane if you hand over your password to a third party, and frankly the manin IM services should block them. meebo is not gaim or trillian – they connect directly with the authentication servers from the IM provider.

  10. grumpY!
    Posted March 4, 2006 at 3:44 pm | Permalink

    this page also provides a nice write-up of comet (before it was called comet)

  11. Steve
    Posted March 4, 2006 at 3:49 pm | Permalink

    Yet another great article (YAGA) Alex.

    A quick question about “Even Apache will provide a Comet-ready worker module in the upcoming 2.2 release”. To what module are you referring to as Apache 2.2.0 has been out for some time now.

    I’d love to see a small demo of using Comet with Dojo if anyone has one.

    As for handling large numbers of open connections I’d look into [Open]Solaris 10. It introduces a highly scalable and enhanced networking stack, which lowers overhead by reducing the number of instructions required to process packets. This efficiency also increases scalability, allowing more connections and enabling server network throughput to grow linearly with the number of CPUs and NICs.

  12. Posted March 4, 2006 at 3:51 pm | Permalink

    grumpY!: is Google a member of the “crayon crowd”?

    Just because your stock web server can’t do it today, that doesn’t mean it can’t be made to scale. While we weren’t looking the OSes picked up the slack and things like libevent got written. The only really surprising thing is that it didn’t happen back when dialup users (whose longer-lived connections look similarly like Comet) ruled the roost.

    The biggest scalability issue is going to be for people running poorly written proxies. Regardless, I don’t think that reflects on the engineering ability (CPS resurrected!) of those building the servers to host Comet apps. The proxies will catch up.

    You should give Twisted a long, hard look. It barely breaks a sweat on most of these workloads.

    Regards

  13. Posted March 4, 2006 at 3:52 pm | Permalink

    That *is* a very good writeup.

  14. Posted March 4, 2006 at 3:57 pm | Permalink

    Steve: last I checked the event\_mpm wasn’t marked stable yet? I hesitate recommending people use something like that when things like Twisted exist and are stable.

  15. grumpY!
    Posted March 4, 2006 at 3:57 pm | Permalink

    alex- this is why i mentioned yaws. erlang has been providing insane threading support for some time now, the yaws graph is mind blowing. soon erlang will have smp. with multicore being the order of the day, erlang will either rise on its own or influence others. i would argue that yaws could handle this model gracefully.

    is google in the “crayon crowd”? google gets a free pass because they have an unlimited hardware budget. that said, i suspect they are in fact doing tuning and profiling. the others…who can say? meebo’s traffic is a rounding error.

  16. Posted March 4, 2006 at 4:00 pm | Permalink

    grumpY!: I wasn’t aware of yaws. I’ll have to check it out. That also reminded me of the IO language that the author of LivePage was raving about recently.

    /me revises ETech slides

  17. grumpY!
    Posted March 4, 2006 at 4:03 pm | Permalink

    alex – this is the yaws vs apache graph i spoke of.

    once again, people doing serious http streaming should look at yaws

  18. Posted March 4, 2006 at 4:05 pm | Permalink

    I’d love to see how this stacks up against lighttpd, Twisted Web and the event\_mpm.

  19. grumpY!
    Posted March 4, 2006 at 4:09 pm | Permalink

    >> I’d love to see how this stacks up against lighttpd, Twisted Web

    ericsson runs telco switches on erlang, as do some other telcos, so my guess is that erlang would demolish these tools by a considerable margin, which is why yaws can stay alive long after apache has fallen over due to too many connections.

    erlang runs as one process and manages its own threads. this is why it can offer “better than OS” thread performance.

  20. Posted March 4, 2006 at 4:14 pm | Permalink

    FWIW, Twisted does the same thing. It uses CPS-style programming to keep everything in a single process.

    I would still like to see the benchmarks = )

  21. kramer
    Posted March 4, 2006 at 7:00 pm | Permalink

    The expensive web farm load balancers don’t have much to do anymore.

  22. Mike Lowry
    Posted March 4, 2006 at 9:31 pm | Permalink

    You must be freaking kidding. (I wish I could use a swear word there.)

    But this technology has been available for a long time and all you are trying to do is attach your name to it, by labeling it. Trust me, there are plenty of people already creating applications by utilizing the long lived http connections. Keep your stupid label “Comet” to yourself, all we need is more tards hopping on this bandwagon, like the Ajax one.

  23. Posted March 4, 2006 at 9:38 pm | Permalink

    Mike: if you had read the post in it’s entirety, you’ll see that I both understand the origins of the technique and acknowledge them. I personally worked on a re-write of the mod_pubsub client 2+ years ago. It was old technology then.

    What is different today is that it’s being widely deployed.

    As for my personal affiliation with it, I would only like to see its use become more common. I’m quite happy to continue hacking on Open Source DHTML in its various forms. I’m not trying to sell you or anyone else anything.

    The only shot the web has at remaining open is for it to deliver better user experiences. If terminology allows us to do that before it becomes co-opted by any number of the large companies currently salivating at the prospect, so be it.

    I’ll be your whipping boy if it’s better for the web.

  24. Marcus
    Posted March 5, 2006 at 6:19 am | Permalink

    To go from client-poll to server-push it seems everybody has forgotten about multipart/x-mixed-replace. It is sitting there ready for use since years – no HTTP overhead, minimum latency. Php example on: php.net/flush look for comment from 20-Nov-2005 04:06.

    AFAIK it is supported together with xmlhttprequest by firefox (but not IE6).

    The problem will be the inter process message passing on the server though, as in today’s scripting web (PHP, ASP, etc.) there is a copy of the program running for every client connection.

    Second problem will be handling several thousand parallel connections at once.

    Nevertheless, thanks for the cool article.

  25. Posted March 5, 2006 at 7:18 am | Permalink

    Just a note to mention that Nevow Athena implements this kind of bi-directional client-server communication link. As far as coping with “1000s of open sockets”, the problem isn’t any more severe than any other kind of protocol where connections are persistent and long-lived; true, a lot of web tools today may not be geared up to handle this mode of operation, but this certainly wouldn’t be the first time anyone has had to deal with it.

  26. Posted March 5, 2006 at 10:21 am | Permalink

    We included “comet” functionality into Millstone 3.0 UI component library released back in 2002. Basically you could you do any changes to components on server and they are automatically pushed to client through already open pipe. Unfortunately making this communication robust across all browsers is challenging. For an online demo and source-code, see “Game of Go” -demo on librarys online demo-page: http://examples.millstone.org/

  27. Posted March 5, 2006 at 1:05 pm | Permalink

    Marcus: there is actually an analagous XML envelope available in IE. It’s not multipart (which I think would be preferred), but it beats a kick in the teeth. It’s also possible to poll responseText before the connection is closed. Regardless, I’m still more a fan of the hidden iframe technique since it allows you to set document.domain and avoid gobbling one of your precious connections when served from a subdomain.

  28. Posted March 5, 2006 at 4:41 pm | Permalink

    I wish I had this about 6 months ago! I had to develop my own push based system based on pushlets to implement a real-time auction system.

    Good to know this type of functionality is moving forward :)

  29. Posted March 6, 2006 at 3:28 am | Permalink

    Comet is a stupid name, that is the name of bathroom cleaner. Don’t give up your day job guy. I will use your comet to clean my toilet and serve my pages of the web. Good technology, stupid name. Why not call it mullet or bandaid© or mr. clean© ??? I realize that AJAX is name of cleaner too, but at least stands for something, but comet? It is lame and annoying. I see no humor or irony in this. Excuse my English, I from USA.

  30. Mike Ter Louw
    Posted March 6, 2006 at 11:45 pm | Permalink

    haha…I missed the obvious cleanser pun until I read bronze_web’s comment. The whole time I was thinking of a meteor shower of data coming from the server. I like the name, though it does seem to not do justice to the bi-directional nature of the communication link (i.e., if you’re thinking of falling meteorites). Let’s see if it sticks. :)

  31. Martin Tyler
    Posted March 7, 2006 at 2:55 am | Permalink

    No this isnt new, but I don’t think anyone was really claiming it was. But just like Ajax it is becoming more popular and can only benefit from things like this.

    My company has been doing this for over 8 years in various ways. Starting off with Java applets/LiveConnect, and moving on to pure JavaScript implementations using both multipart replace and iFrame script tag methods.

    It is certainly possible to acheive the necessary performance on a server, numbers of open sockets are not really a problem if implemented well, eg up to 30000 concurrent users. The problems are more related to the amount of data sent to the clients. Low message rates are fine, but to increase the messages rate you have to be more intelligent with the protocol and other techniques. With decent message rates overall bandwidth can be high.

  32. alexditto
    Posted March 7, 2006 at 8:12 am | Permalink

    I have read the JS source code for Jot Live. I find the nature of Comet is quite similar with AJAX. The only difference between them is that the Comet will start a new XMLHttp request immediately after the previous one finished.

    Would it be a burden for the server? Due to the frequently requests.

  33. Codist
    Posted March 7, 2006 at 9:53 am | Permalink

    Jetty 6’s continuations would probably work well with this technique.

  34. grumpY!
    Posted March 7, 2006 at 2:12 pm | Permalink

    http://orbitz-erlang.blogspot.com/2005/09/twisted-matrix.html

    some more intelligent notes on erlang vs twisted

  35. Posted March 8, 2006 at 2:40 am | Permalink

    i wrote a very small chat application with nevow’s athena. i use vhosts to overcome the 2- connection-limit per host (at least it seems to work). chat.sifu.co.at

  36. Winter
    Posted March 9, 2006 at 6:24 am | Permalink

    Just call it a “Hanging-GET” because that’s what it really is.

    “Comet” (gag) is just a new name for Pushlets.

    http://www.pushlets.com

    Granted, the new name is intended for marketing purposes, but let’s not forget it’s the exact same idea with a different name. Both Pushlets and Comet both depend on a Hanging-GET (which I think is a better, more technology neutral term anyway.)

    Don’t forget also that this can’t really be used as a generic eventing mechanism because it doesn’t support gauranteed delivery. Most applications don’t require it but there are a lot that do.

    I’d like to see an implementation of HTTPLR

    http://www.dehora.net/doc/httplr/draft-httplr-01.html

    which woudl provide gauranteed delivery. It would require explicity acknowlegement of receipt, but with HTTP keep-alive, you’d end up talking over the same sockets anyway. So you still have the same threading issues to deal with but it’s a more robust solution for a general client.

  37. Martin Tyler
    Posted March 10, 2006 at 4:00 am | Permalink

    HTTPLR looks interesting, but that doesnt look like it could support Comet/Hanging-GET style push communication since all the gauranteed messaging is done on standard HTTP request/response headers. In comet you want to send multiple messages from server to client within the same response. Is HTTPLR going to address this?

  38. John Li
    Posted March 10, 2006 at 12:23 pm | Permalink

    I am really looking forward to your follow-ups on how dojo supports comet…I’m ready to try that already!

  39. Posted March 12, 2006 at 7:26 am | Permalink

    Please take a look at http://www.lightstreamer.com too.
    Several online demos are available.

    Lightstreamer is a commercial poduct that has five years of maturity and very soon a free edition will be released.
    It can be integrated with any AJAX framework to implement true “push/streaming” capabilities, for updating a page with real-time data without relaying on any form of polling.
    Lightstreamer Server is highly scalable, due to its NIO-based staged event driven architecture.

    Any feedback will be appreciated.

  40. Posted March 13, 2006 at 11:06 am | Permalink

    ICEfaces is a commercial product that deploys “comet” applications that are developed in pure Java (no JavaScript) using standard JSF components.

    There is a free Community Edition available as well as a Professional Edition (commercial license). One of the advantages of the commercial version is that it provides a highly-scalable solution to the thread-consumption problem identified above related to holding connections open on the server.

    Check it out for an example of a complete comet application development and deployment solution.

    Online Demos: http://www.icesoft.com/products/demos_icefaces.html

    ICEfaces information:
    http://www.icesoft.com/products/icefaces.html

    Regards,
    Ken

  41. Posted March 16, 2006 at 6:26 am | Permalink

    TelePort is an Open Source product that supports Comet, JSON, SOAP, REST etc. etc.

    (For the veterans amongst you guys: it is an evolution of the 2001 vcXMLRPC library)

    It is released under the GPL and available on Sourceforge:
    http://sourceforge.net/projects/teleport/

    For more information, wander over to
    http://www.javeline.org/modules/products/

  42. rage
    Posted March 20, 2006 at 7:43 am | Permalink

    I think ‘Comet’ is as good a name as any other. Using Ajax on my kitchen floor did not make me confuse it with AJAX which I use in my work.

    I do see why ppl immediately brought up performance issues with open connections. I’m sure this will be solved soon. AJAX spread so much faster since implementing only involved some php class and a couple lines of jacascript. But with ‘Comet’ it seems I need some apache module, or a similar technique outside of the reach of the ordinary web-developer.

    Right now I would see the use of it in the support-admin system I’m currently working on, as it has just a few users (certainly not some thousand) and they work with the same queue of tasks in which the action of one support personell would need to influence the data displayed on the UI of the others.

    I would really like to see some examples on how to implement ‘Comet’. A few hints or a short summary would do, although to see a full tutorial would really thrill me.

    Thx,
    rage

  43. Derek
    Posted March 24, 2006 at 12:20 pm | Permalink

    I love this bleeding edge web development stuff. Does anybody know of any companies in the Boston metro area doing this kind of stuff, or recommend a way I might be able to go about finding out?

    Thanks in advance.

  44. Posted March 25, 2006 at 5:46 am | Permalink

    Derek: Google may lend a hand there

  45. Posted March 25, 2006 at 9:46 am | Permalink

    with ajax can’t you just have a refresh in the javascript?, I know its not the same as having a listener to listen for events but it would solve the problem for many of the sites out there,

    it seems a good method of pushing new data to the client, however with all these live connections once an event has occured won’t the bandwidth die with pushing data out to 40000 clients at the same time?

  46. Posted March 25, 2006 at 11:34 am | Permalink

    so is there any support for this *currently* in PHP. if i understand the idea properly (eg: the server and browser send each other an xmlhttp data but keep writing data until the user leaves the page) then aren’t you going to get two ‘instances’ of the php script (one that stays open to receive data from the browser, and a seperate instance of the script that simultaniously replies to a different xmlhttp call)? is there some way in php for the two instances to share data, other than writing and sharing the server harddisk?

  47. Posted March 25, 2006 at 5:24 pm | Permalink

    Theres also an approach to this using macromedia flash and liveconnect. Ive had this tech working for years and have recently added SOAP/WSE support so you can develop these push type apps with standard service oriented architecture methods.

    http://www.kevin-mcarthur.com/Stream2.0 for more info.

  48. Posted March 25, 2006 at 8:47 pm | Permalink

    AJAX in theory is an Acronym.

    Does COMET really do justic to this technology.

    True, Deja Vous’ buzzwords ARE digestable and easier to remember, but perhaps it should reflect the DNA of the technology.

    Pehaps, this could be an open invitation for all to come up with an encompassing term for this very spectacular technology.

    “PUSHED” – should certainly be included.

  49. John "Z-Bo" Zabroski
    Posted March 25, 2006 at 9:07 pm | Permalink

    I originally thought this story about “Comet” was a joke. This is basically exactly AJAX, except more clearly defined. The end effect is the author, Alex Russell, is going to make a bigger name for himself by mainly extending JJG’s idea without keeping JJG’s meme. What better way to *promote*. Not necessarily the best way to teach.

    People are so concerned with being on the bleeding edge of data transmission technology that they forget creating buzzwords is secondary to understanding technology. The article is the epitome of a bad idea virus, although your article does point out JJG’s insufficient description of using asynchronous data transfer.

    Your article does absolutely nothing to differentiate between “AJAX” and your so-called “COMET.” But that is neither here nor there. That is just me voicing an opinion.

    So here is a fact:

    You and Jesse James Garrett both have inaccurate diagrams to describe how XmlHTTPRequest works within a web browser and how web pages can use it to create a rich asynchronous experience. In all this hype of your new Web 2.0 buzzword creation, no one has pointed out your model is wrong. There should be two displays for each data transmission, one before the transmission and one after the data transmission. This is to show that the transmission is asynchronous. The first display would be of an hourglass or dots running in a circle or something. It’s important for users to know when something has started and when something has finished, and that is typically considered part of the “AJAX Engine.” It might also be desirable to “freeze” the state of the web page during the data transmission. Furthermore, the only difference between your diagram and JJG’s is that you are more descriptive and specific of what the server-side processing is doing.

    It’s funny that the web is such a powerful medium to create a meme — that your “Comet” idea is already catching on heavily is proof. Whereas JJG’s AJAX acronym actually stood for something somewhat sensical, your Comet stands for nothing technical. I find that disappointing.

    As for your endnote, “Common terminology acts not only as a shortcut in discussions between technical folks, but also as a bridge for those who may not be able to give a technical rundown of exactly how it works”; I would counter by pointing out there are a lot of common buzzwords that have different meaning to different people. The buzzword “Web 2.0″ is a great example. It started off as one man’s vision, and now it is a meme that means many things to many people. Coincidingly, trying to start a *focused* conversation about “Web 2.0″ can’t involve everybody.

    {{Sorry if I slammed you a bit here. I just felt the need to come across strong. I respect your role as a senior software engineer in http data transfer technology.}}

  50. Posted March 26, 2006 at 12:15 am | Permalink

    John,

    I think you completely misunderstand the point of what I’m outlining here. Both in the sense that you assume that I’m somehow grandstanding for attention and that you somehow assume that on a network protocol level the technique isn’t different. It clearly is.

    Ajax transmissions are much like “traditional” http transactions in that both sides of the transaction are optimized for closing the connection as fast as possible. Whether or not the server batches state transfer is a different question, and can be accomidated in either model, but the Ajax scenario uses a much higher average latency to deliver these batched state changes. This often leads to stale UI context for making decisions.

    As for your discussion of “Web2.0″, I’m not sure it’s worth rebutting. Instead of even obliquely attempting to describe a technology or pattern it was plucked out of the ether as a marketing term to describe a conference. I certainly hope that with “Comet” (or whatever it winds up being called eventually), we will have created enough technical context and consensus for the term to be useful in discussion. As you perhaps attempt to point out, that is by no means a foregone conclusion, but to bucket my attempts to smooth conversation with the coining of “Web2.0″ seems a snarky stretch at best.

    Regards

  51. John "Z-Bo" Zabroski
    Posted March 26, 2006 at 11:01 am | Permalink

    I probably should have crafted a friendlier statement. Re-reading what I wrote I probably sounded like a jerk, or, in all capitals, JERK. I am sorry and apologize. My lack of finesse must have seemed appalling.

    I understand what your overall thesis statement is: Most people have assumptions about the kinds of transactions that can be done to give web sites the richness and responsiveness to rival Desktop applications… and it is time to break those assumptions because they limit one’s creative vision. Alex, as a senior software engineer, you need a bigger canvas to apply your paint. I share your sentiment; whatever problem “Ajax” can’t clean, grab another cleaner (“Comet”) to rid yourself of the messes associated with bandwidth and hourglass-waiting.

    In terms of Ajax using a “much higher average latency” to deliver state changes, half of all state changes are done without a client-server transaction: Client makes an action, and the event is an input to the Ajax engine, which then calls a state change back to the Browser UI (hourglass, dots running in a circle, &c) *before* making an XML request to the server. That’s entirely a client transaction, between the Browser UI and Ajax/Comet client.

    I am also not sure that the client-server transaction has a “much higher latency” to deliver the second state change, which is the end result of a client making an action. There is always ways to lower latency if it is a worry. On the server-side processing end, caching data can help.

    I have also seen so-called Ajax applications with continuous server-side connections, despite the fact that Jesse Jame Garrett’s model shows discontinuous server-side activity.

    What you are describing is basically the server pushing data to clients who asked to be notified of new data. (In my opinion, the action of asking to be notified can be seen as an Ajax event.) In terms of latency there, there is still going to be latency in many transmissions because most routers are not optimized for broadcasting. Latency could be reduced if routers could split TCP/IP packets at appropriate hops and forwarded each split to a destination address. I don’t believe most routers support this functionality. Yet your “Comet” idea would benefit greatly from the reduced bandwidth necessary to transmit the information. There’s many ways latency is effected between client, network and server.

    Take care and best regards =)

  52. Derek
    Posted March 27, 2006 at 10:00 am | Permalink

    I wonder just how instantaneous any of this data really needs to be? Are their really applications in which the difference between 1 second and 5 is life and death. I would think the latency introduced by the human consumer of the data will dwarf any advantage Ajax gives you over Comet. Or is there another benefit to the technology I’m missing here? I’ve written an AJAX based chat application and have been very satisfied with a gradually decaying Ajax polling mechanism.

  53. Posted March 27, 2006 at 11:21 am | Permalink

    Derek: If you spend any amount of time thinking about chat in the pantheon of collaborative apps, it pretty quickly turns up as a corner case. Not only is it append-only, stale context rarely means a bad decision.

    There are many forms of collaborative apps that need better responsiveness (see JotLive, for instance), and even your chat app could benefit. 5 seconds to get a message that might have taken 5 seconds to type is pretty shitty total latency. Comet allows us to do better.

    Regards

  54. Derek
    Posted March 27, 2006 at 11:56 am | Permalink

    Good points Alex. Its so exciting to be able finally be able to do any of this stuff. I remember looking around 2 or 3 years ago to do stuff in the Ajax model and Pushlets (Comet) was a very viable candidate. I remember spending days if not weeks trying to solve that annoying IE Iframe click issue to no avail! Its great to see people finally pushing the envelope.

    I remember reading a post on one of the Comet blog entries marking a pretty convincing argument that Comet may actually be a lower bandwidth solution when you factor in the cost of sending around all of the HTTP headers associated with an XHR request. I would love to see a detailed examination of the costs associated with each.

  55. Stevie
    Posted March 29, 2006 at 12:05 am | Permalink

    So far so good. Where is the working “Hello World Example”. Your Code-Snipp doesn’t work.
    rg. st.

  56. Posted March 29, 2006 at 5:29 pm | Permalink

    Great article. Finally someone named the technique many are working on, including me. I created a real-time multi-user environment with “Comet”. Check it out:
    http://dutchpipe.bubblestart.com/
    As for scalability, it turns out to be pretty light. When ‘nothing’ happens, it uses almost nothing. However there will be a limit of users which is lower than normal webapps as from a certain number of users it would become kind of a distributed denial of service attack. But this is just for starters. There’s so much to say on the subject.
    Hope your name catches on.

  57. Posted March 30, 2006 at 12:59 am | Permalink

    I’m not sure this technique needed another buzzword, but then comet is more catchy than “long polling”

    Jetty 6 has a continuation feature that support scalable long polling within the java servlet API, so I guess Jetty 6 is Comet ready. This technique scales better than thousands of clients polling every few seconds!
    http://www.mortbay.com/MB/log/gregw/?permalink=ScalingConnections.html

  58. Gaurav
    Posted April 11, 2006 at 7:14 am | Permalink

    Nice to hear about AJAX from AJAX king. But it would be more informative if you would have informed about Framework you have used in developing meebo.com

  59. Holger
    Posted April 12, 2006 at 2:17 am | Permalink

    Just look at:

    http://schumann.cx/ircg/

    So – to be fair, “comet” should be renamed to
    “ircg” because the server-push technology is
    like about several years old and has been
    used in many projects – from flasg based
    messengers to html – irc gateways etc.etc.

  60. Daniel
    Posted April 12, 2006 at 6:25 am | Permalink

    The technology is great, but I see a few bumps before success.

    Many firewalls stop long living HTTP connections :( , I guess that you allways have to fall back on the old poll thing again.

  61. Scott
    Posted April 12, 2006 at 2:17 pm | Permalink

    Alex, when you say “there is actually an analagous XML envelope available in IE. It’s not multipart (which I think would be preferred), but it beats a kick in the teeth. It’s also possible to poll responseText before the connection is closed. Regardless, I’m still more a fan of the hidden iframe technique since it allows you to set document.domain and avoid gobbling one of your precious connections when served from a subdomain.”, can you please describe what that analogous envelope is?

    Also, I’m interested in more information about the document.domain fix for multiple connections. Right now I’m using a Java applet to open long-lived connections, and when more than one page has an applet the entire browser grinds to a halt. Does the iFrame technique solve this issue? I’m also considering using Flash applications as well.

  62. Posted April 14, 2006 at 7:53 am | Permalink

    Comet, “the new ajax” ? well … check out this : http://www.pushlets.com/

    And i m usin it for 5 years :) … i confirm that they are problems with some network equipement like firewall who cut off the http persistant connections .

  63. Posted April 17, 2006 at 10:06 am | Permalink

    COMET and j2me ?

  64. Posted April 18, 2006 at 5:46 pm | Permalink

    Hey Alex,

    Congratulations for the wonderfull DOJO.
    Keep on doing what you’re doing, don’t listen to the stupid voices in the crowd.
    Some people don’t see that it doesn’t matter how it’s called “Comet”, “Pushlets” etc. So what if it’s the name of some bathroom cleaner. The only thing that matters is that things move on, the way they should. The web is not only for java or asp or any other standalone language, it is for all of them and for also all of us.
    Keep on rocking in the free world.
    Doru

  65. William Chen
    Posted April 20, 2006 at 12:12 am | Permalink

    I wrote an Instant Messenger in Java about a year ago. I used http protocol so that messages could tranverse thru proxies and firewalls. Except the client is a java swing app instead of a browser, all of the others are just the same as Comet. There are many problems. First of all not all proxies and firewalls support long-lived http connections. The second is the serverside thread. You can rewrite a light-weight web server and using ‘select’ method to avoid threading problems. The client side first needs to initialize a http request. And after initializing, it keeps using this http connection for polling messages from the server side. Another problem is how many sockets can a server support. This depends the underlying OS.
    I did not test my IM to see the output. It is also very easy to cluster. Before reading your posts, I did not it was so popular a technique. I should look at the other solutions existed.
    Thanks alex for standardize the concept though I don’t think the name ‘Comet’ is good.

  66. William Chen
    Posted April 20, 2006 at 12:26 am | Permalink

    Of course, in my IM, I only used comet when the two chating users are both behind a proxy or firewall and they don’t belong to a same intranet. As for others, if one of them is directly connected to the internet, then it will launch a light-weight web server and the other one will communicate using comet. If both of them can connect to each other using TCP, they will connect to each other using direct TCP connection, eg. if they are both directly connect to the internet or they are both behind a proxy but belongs to a same intranet.
    JXTA is a similar concept except it is a higher abstraction. In this very case, JXTA probably uses http tunneling to wrap datagrams.

  67. Posted April 27, 2006 at 12:06 pm | Permalink

    As I read this I realized that I’ve been doing exactly this for many years. I had build a real time bond trading system that need real time updates to the browser — so having an open connection simply waiting for data worked perfectly. Never thought about naming it — Comet seems very appropo if you think about shooting data out to the browser.

  68. jason
    Posted April 28, 2006 at 6:39 am | Permalink

    Macromedia Flex kind of already solves all this don’t you think?

  69. Shaun
    Posted May 8, 2006 at 12:57 pm | Permalink

    I don’t really care about the buzz word that it’s called. Comet is as good as any; my question is “How do you do an Ajax/Comet push?” What does the code look like? If I was trying to use Apache 2.2 how would I go about pushing updated data to the browser?

    Thanks

  70. Paulo Tioseco
    Posted May 9, 2006 at 9:16 pm | Permalink

    Are there any available resources such as websites, books or articles/tutorials that teach how to implement COMET? I’m looking for a topic for my thesis and I think that this will be a good one. Also, can you give suggestions of useful web applications that I can create using COMET. Thanks!

  71. Posted May 10, 2006 at 3:52 pm | Permalink

    This is a great article. However, I want to see code references. In terms of Dojo, what is the technology running on the server? Could I look at your bind implimentation and see if it could be ported to a .Net environment?

  72. Pedram
    Posted May 14, 2006 at 3:47 pm | Permalink

    I wrote a comet based IRC client that
    is low latency and event based… all
    very nice I’d like to show it to you
    given that Paul wrote a jsbot it might
    be something you guys would like.. email me..

  73. Posted May 25, 2006 at 4:20 pm | Permalink

    The problem with the word comet is that it is not as easily googlable as ajax. The beauty of the word ajax is how googlable the word was. I have regrets that it wasn’t named comt, or commet (signifying the meeting of two in the web?)

  74. Posted May 30, 2006 at 4:38 pm | Permalink

    Kenamea’s bi-directional messaging system is also “Comet-ready” and can scale up to support thousands of connections.

  75. Gregory
    Posted June 1, 2006 at 3:08 pm | Permalink

    Maybe I am missing something, but this technique didn’t work for me when I tried it about 3 years ago.
    I used IE and Tomcat to create a live console for a production system which generates dozens (sometimes hundreds) messages a minute.
    The problem was that from the IE point of view this was like downloading one huge page, so it never released the storage and was getting slower and slower.
    I tried breaking and restarting the connection every n messages, but when IE was releasing the storage it brought the PC to a halt for a second or two, which was very annoying.
    I ended up using an applet with LiveConnect to handle all communications between JS in the browser and Java on the server.

  76. Paddy Hannon
    Posted June 1, 2006 at 5:29 pm | Permalink

    Sounds similair to the old non-parsed header technique wherein you use the multipart/x-mixed-replace mime type in your response and set boundaries. I guess you combine that with ajax and voila you have persistent client server communication. Or is the “slow-load” method different?

  77. Jared
    Posted June 7, 2006 at 12:54 pm | Permalink

    I like Winters term ‘Hanging-GET’. It reduces all the mystery and confusion to something small and simple. I have to admit however, if it were not for the buzz-words ‘Ajax’ and ‘Comet’ I may have never stumbled upon these good ideas. Thank you Winter, Thank you Alex.

  78. Posted June 11, 2006 at 7:21 am | Permalink

    Seems as though some responders are not reading before commenting. I may not know my head from my ass; however, I have read the conversation prior to this comment.

    1. REGARDING THE TERMINOLOGY TOPIC ~ and, considering the comment = “Common terminology acts not only as a shortcut in discussions between technical folks, but also as a bridge for those who may not be able to give a technical rundown of exactly how it works?;
    ——————————————-
    Response: I agree that a “term” is a positive thing as far as it facilitates communication and efficient collaboration. Yet, developers and “developers” are way too sloppy and immature with all of these labels. With web development, I think most of the new buzzwords are merely new skins placed around core development principles; every time a new angle is demonstrated, where the implementation has a degree of exposure, a new skin is stretched around what is merely a particular arrangement of the craft’s available materials, applied with a standard handful of tools: tools that are common to the craft of development, as other crafts have their own array of core tools. A few weeks ago, a Urologist friend of mine had to make do with a pair of bolt cutters in order to finally remove a sexual device that was stuck on some poor dude who ended up in the emergency room after, god knows what, went wrong in bed with his girlfriend. Anyway, he wasn’t sure if the bolt cutter approach was ever taken before, let alone ever needed, but he didn’t go inventing and marketing some buzzword for the method. I think if he had, it would not only confuse a pretty basic solution, but would probably make him look a little ambitious and perhaps a bit amateurish that he thought his approach was so “break-through,? that it needed its own buzzword and subsequent, industry-wide, best-practices? modernization rollout.
    ———————————————————————————————-
    The web context, and the developer profession, seem to foster a particularly zealous and obvious approach. It reminds me of times when I was young and played the trumpet in school. When trumpeters get around each other, there are always some, who must demonstrate their entire arsenal of talent, and, show off their cutting edge equipment. The higher the stakes, the more this seems to happen, and will more likely exhaust players chops and make everybody feel all competitive and intimidated, instead of cohesive and in ‘tune.’ These habits seemed to come most, from those with the least virtuosity and experience.
    Relating back to the developer’s world, there seems to be a lot of competition around – or, at least a lot of developers. On top of that, we see these sporadic start-up ideas pop up out of nowhere and get sold for 350 million dollars. So, perhaps these ‘buzzwords’ are stretched over our work, whenever possible, in hopes they’re mistaken for inventions, and, increase the odds of investment capital coming our way? Maybe there are too many developers around, so, we hear a lot of horn blowing going on? Personally, most of the new terms bother me; and, admittedly, they do sort of intimidate me and do sometimes make me feel like I’m not clued in or not keeping up. Often, though, when I do get around to making sure I know what’s up with the new buzz, it ends up to be some ‘meme’ that your average AOL customer might be impressed by, while, real developers will see it to be no more exceptional to developing than a scale is to trumpet playing.

    A previous post suggested that the process of coining new buzzwords for everything, somehow contributes to an open source environment, while making it more difficult for the big players to snatch up the technology and brand it. Conversely, I think that this excessive labeling and equally excessive wrapper creating and promoting, are attempts to grab ownership of whatever “layer,” or intellectual credit one can, from the tools we all share. Is it fear and/or intimidation that promote this?

    ————————————-

    Although I don’t think the “COMET” idea is any more innovative than the “AJAX” idea, I do think the “PUSH? related option that “Comet? deals with, is relevant and sort of needed if thin clients are to approach the kind of functionality we’ve become used to with our applications. But, all this talk of different servers and wrapper products (i.e. weekend projects) don’t seem relevant to me; perhaps I’m missing the point, but, the server doesn’t seem anymore relevant to this topic, than a reliable server is to any web-served application related topic. Whether a server can handle 100 threads or connections, or a billion, it doesn’t matter; because, as long as the number of threads and connections is an issue at all, then the solution is not correct. With scale, isn’t it all relative? I’m sure the company scoring a billion profitable transactions a day doesn’t want their server to max out and freeze up, anymore than I want my server to fail, if my piss-ass site tops 100.

    I want a push solution for applications that require real-time, n-user interaction. I haven’t been too encouraged by the load-related stats I’ve gotten from small experiments where only a hand full of clients are “polling? the server every .5 to 10 seconds. So, yea, It seems to me that we need ‘multi-cast’ like callbacks – from the server; yet, with the “buss? approach this articles suggests, or any metronomic call approach (which necessitates some kind of object/page-load/threading each time), is not really solving the problems that arise with the “polling? option.

    So, I think a ‘comet’ type technique is relevant, but must cooperate, collectively, with the clients, in a way that doesn’t persist connections, doesn’t use any objects that must be hosted by the server if scoped such that instantiation must happen for each browser instance, or worse yet, callback method, that .is required.

    I have some ideas for ways this might be done, and I’m sure a million of you developers out there do as well.

    But all the discussions seem to be so focused on talking about these buzzwords and specific wrappers or script libraries that I usually don’t bother. Not only do I not have time to try every method, within every wrapper that someone makes – frankly, I don’t want to. We know how to call a method and make use of an object; why don’t we figure out good solutions and strategies, and then perhaps see if there are a few helpful, pre-fab, fancy-named, custom-skinned, buzz-worded, wrappers (services/proxies) etc. out there that are quality and can save us the bother of creating our own?

    Thanks for the discussion
    De

  79. Posted June 11, 2006 at 7:26 am | Permalink

    Sorry about the above formatting – I would appreciate it if someone could fix it.

    thank you

  80. Kevin
    Posted June 24, 2006 at 4:20 pm | Permalink

    Alex, if I am not mistaken, you are saying that mod_pubsub improves the scalability of servers using Comet. I was just wondering how exactly does mod_pubsub accomplish such a thing. The web server still has to manage the constantly opened connections even with mod_pubsub installed, doesn’t it?

  81. Posted July 19, 2006 at 3:06 am | Permalink

    hey Kevin,

    Sorry I didn’t catch your comment earlier.

    Despite it’s name, mod_pubsub was never *actually* an Apache module. All of the versions which I saw were either implemented in Perl using sockets or atop Python’s old asyncore infrastructure. In 2004 an upgrade to the core Python version started to employ Twisted Python as the network-level responder. Twisted improves the performance of these kinds of things by making sure that network I/O never blocks and doesn’t require a thread or process per request. Things need to be written differently to operate on top of Twisted, but once that’s done, holding thousands of concurrent connections open at a time is no longer crippling.

    Regards

  82. Larry Cable
    Posted July 26, 2006 at 4:25 pm | Permalink

    Alex,
    I am curious how does this client/server ‘event’ flow map onto HTTP 1.1 Request/Response?

    In particular is each new browser ‘event’ a pipelined HTTP request to the server? and is a particular ‘stream’ of server ‘events’ considered part of the response to the most recent (server processed) client HTTP request?

    Thanks

    – larry cable

  83. anonymous
    Posted July 27, 2006 at 3:10 am | Permalink

    grumpY!: is Google a member of the “crayon crowd??

    They most certainly are, in fact they have a VIP membership. I curse them everytime I have to kill my Firefox because it’s using 200Mb of memory because of GMail.

  84. Posted August 9, 2006 at 6:20 pm | Permalink

    Where do I see this going? I don’t know of a better set of technologies for building Comet apps. One possibility is massively multiplayer online games for browser-based clients. All types of internet-based collaboration and instanct communication apps could use this great hybrid as well.

  85. Posted August 22, 2006 at 12:55 am | Permalink

    Is there any limitation to use comet?

  86. Posted August 22, 2006 at 4:06 am | Permalink

    Very nice to see this finaly be used by the community. If you want a great example look into the Lycos chatclient found at chat.lycos.co.uk its been using this method for communicating since 1998.

    :)

  87. E T
    Posted September 6, 2006 at 12:43 pm | Permalink

    Interesting article… I found the comments more enlightening, though.  It would indeed be nice to have a more technical, practical discussion of usage rather than general what-if and wait-for-it.

    While I see the benefit of having a term for it, I agree with the people who find ‘Comet’ to be a goofy and unhelpful one.  The industry is full of stupid acronyms that are pretty unhelpful (Service-Oriented Architecture… aren’t most architectures service-oriented?), but at least they’re on track.  ‘Comet’ doesn’t even start to give an impression of what you might be referring to.

    ‘Hanging GET’ clicked for me; while there was enough discussion of what this was about before that was said, it’s the most descriptive moniker I noticed in this thread.

    Conclusion: It’s nice that you’re fostering discussion… but please, next time you try to establish a buzzword, do us all a favor and pick one that makes sense.  If you’re going to rename a long-established set of technologies, at least improve on what’s there.

  88. Posted September 29, 2006 at 9:18 am | Permalink

    Like it, the concept even if it is Re-freshed Push, and the word too – Comet makes sense on a lot of levels. I vote for the word TIDE to represent the next re-boiled artefact of the old web that needs a sexy term to spark reincarnation.

  89. Rocky
    Posted October 4, 2006 at 11:08 pm | Permalink

    I think comet is best for .net application and ajax is gloabl for evry kind of techonogy domain. so ajax is better then comet

  90. Posted October 15, 2006 at 4:03 am | Permalink

    Sounds similair to the old non-parsed header technique wherein you use the multipart/x-mixed-replace mime type in your response and set boundaries. I guess you combine that with ajax and voila you have persistent client server communication. Or is the “slow-load? method different?

  91. Posted November 21, 2006 at 11:52 am | Permalink

    I would appreciate it very much if ther would be a simple “Hello World”-example. Sounds interesting, but I haven’t a clue how to use it. I would only need it for about 10 concurrent user, so I don’t care about server performance.

  92. Posted December 2, 2006 at 9:15 am | Permalink

    Sounds similair to the old non-parsed header technique wherein you use
    the multipart/x-mixed-replace mime type in your response and set
    boundaries. I guess you combine that with ajax and voila you have
    persistent client server communication.

  93. Posted December 16, 2006 at 10:12 am | Permalink

    I like the word LazyHttp better, also I’ve made a couple of implementations which can be found from here

  94. Posted December 21, 2006 at 10:53 am | Permalink

    Hi,

    I know I’m a little late to join the conversation, but I’ve been discussing the methods Comet with some of my colleagues and the key question that came up was proxies will buffer the content in a few KB of data before sending it to the client.

    If you have an application that requires only small pieces of updates (i.e. a chat client or a price for a trading system) the proxy is going to buffer a large amount of updates before it’s sent through.

    We’ve only been able to test in a bespoke Java application and bespoke server, rather than Comet-type approach using Apache (or bespoke server) and JavaScript – but I expect the same rules apply?

    Does anyone have any thought or work arounds to these issues?  Or am I completely wrong in my assumption?

    (Padding the content if the proxy is in use may not be a great idea because the buffer size could be different from sysadmin to sysadmin).

  95. Posted December 21, 2006 at 1:54 pm | Permalink

    Remy,

    Never too late ;-)

    In Cometd (http://cometd.com), we’re using “pluggable” envelopes for most connections in which we you easily add padding, but if you’re using long polling, connection close (when the data is sent in the first place) should cause any sane proxy to forward on everything in the cache. If an RST doesn’t cause a flush, then there’s something really really wrong.

    Regards

  96. learning
    Posted January 24, 2007 at 10:43 pm | Permalink

    i have a classical ajax page..
    and now i’m trying to make a comet page..
    what should i change on my ajax page to make it into comet page?
    thx all.. 

  97. Peter
    Posted March 6, 2007 at 11:44 pm | Permalink

    i thought it was the renkoo folks who built/open-sourced Comet in the first place. i could be mistaken.

  98. Posted March 12, 2007 at 8:44 am | Permalink

    First of all, it’s IMPOSSIBLE to submit comments in IE7…
    The “WYSIWYG” editor is INVISIBLE… ;)
    Second (and my reason to post) is that I actually did an implementation of this a couple of weeks ago which can be seen at http://ajaxwidgets.com/nnug/
    The presentation is in NORWEGIAN but if you Download the link (up left) you’ll get a Visual Studio solution which you can download that contains a “rudimentary” implementation of “Comet” (or LazyHttp which I prefer to call it ;)

    PS!
    [Shameless plug…]
    And while you’re at it if you’re a .NET developer, make sure you check out; http://ajaxwidgets.com
    ;)

    .t

  99. Posted March 17, 2007 at 2:31 pm | Permalink

    Peter,

    The first implementations that I’m aware of were from a company called KnowNow. You can buy their super-scalable Comet server or Lightstreamer’s if you’ve got big apps and a big-ish budget.

    KnowNow open source’d mod_pubsub at one point, and one of their founders is also a founder of Renkoo (Adam Rifkin). It’s no surprise then that Renkoo uses a Comet server based on the published mod_pubsub protocol, but that work came later than KnowNow’s pioneering implementation.

    Regards

  100. Posted March 17, 2007 at 2:32 pm | Permalink

    Thomas,

    IE7 commenting should be fixed. I’ve updated the editor to use the AOL CDN hosted build of Dojo 0.4.2. Let me know if you’re still having problems with it.

    Regards

  101. Posted March 21, 2007 at 6:45 am | Permalink

    It works now ;)Though I had to choose “Normal” (up right) before I could start typing… Anyway the reason I’m replying now is due to my new blog about it at my signature… :)But I still REFUSE to call it anything else than LazyHttp… ;)

  102. Graeme Black
    Posted July 12, 2007 at 10:30 am | Permalink

    Comet, it makes your teeth turn green.
    Comet, it takes like gasoline.
    Comet, it make you vomit.
    So get some comet, and vomit, today.
     
    Sorry, I couldn’t resist (and I couldn’t get the darn song out of my head!)
     
    Seriously, mixing polling and comet for reverse ajax would seem to address problem of long term connections with comet vs bandwidth and resource consumption with polling.  Instead of polling every second or five second, have a 30 second timeout on your comet and reissue the request when you get a response from the server (timeout or otherwise).  This would be like a 30 second poll that would respond as soon as there is an event.  Then it is just a question of tuning the timeout.

  103. Posted July 14, 2007 at 7:14 am | Permalink

    nice..it looks great but is there a helpdesc or something like tutorials about Comet ?

    I want to make my first implementations on my website. So I’ll be glad if someone can show me trial.

  104. Posted July 14, 2007 at 6:10 pm | Permalink

    is there some exemples of Comet used ?

  105. Posted July 15, 2007 at 2:16 am | Permalink

    Isn’t this just HTTP 1.0 style keep alive? I believe KnowNow implements
    this with HTTP 1.0… anyway… now we have something to call this.
    PeopleSoft apps use this style of communication for their Help Desk
    online chat apps (they OEM’d KnowNow’s pub/sub tools back in 2001).
    Like XMLHTTPRequest, it’s nothing new… but now we have a name for it…
    cool name btw.

    Serg

  106. Posted July 15, 2007 at 11:49 pm | Permalink

    I would really like to see some examples too on how to implement ‘Comet’ . A
    few hints or a short summary would do, although to see a full tutorial
    would really thrill me.I want to make my first implementations on my website.

  107. Posted July 16, 2007 at 12:15 pm | Permalink

    Personally, I’m loving the new emerging browser technologies and the emergence of old technology coming back to the forefront. Good ideas don’t die quickly. The whole resurgence of the browser wars etc. is hopefully a sign of things to come within IT – we really need a new late 80’s early 90’s vibe in IT. It’s all become way too corporate, and way too ‘same old, same old.’ I’ll get really excited if Amiga came back into the market – that would be awesome!! And hopefully computer games would get exciting and creative again too.

  108. Posted July 22, 2007 at 6:54 pm | Permalink

    I
    am trying to warm up myself with AJAX. It seems that I can use it to add flavor to
    my site without sacrificing the characteristic of being crawlable.  At first I was kind of hesitant to use it but
    as I use it along wit the newest Yahoo Connection Library, I always end up
    making another reason just to use AJAX.  By the way, have you checked out the latest
    Yahoo Connection Library?  I wonder where
    I can find the tools for Comet.

     

  109. Posted July 29, 2007 at 3:51 am | Permalink

    Despite it’s name, mod_pubsub was never *actually* an Apache module.
    All of the versions which I saw were either implemented in Perl using
    sockets or atop Python’s old asyncore infrastructure.

  110. Posted August 7, 2007 at 9:33 am | Permalink

    People are so concerned with being on the bleeding edge of data
    transmission technology that they forget creating buzzwords is
    secondary to understanding technology. The article is the epitome of a
    bad idea virus, although your article does point out JJG’s insufficient
    description of using asynchronous data transfer.

  111. Posted August 16, 2007 at 9:45 am | Permalink

    I would appreciate it very much if ther would be a simple “Hello
    World”-example. Sounds interesting, but I haven’t a clue how to use it.
    I would only need it for about 10 concurrent user, so I don’t care
    about server performance.

  112. Posted August 21, 2007 at 3:38 am | Permalink

    What is the better to use : AJAX Comet or xmpp.

  113. Posted September 21, 2007 at 1:08 am | Permalink

    I found it at topic with intresting name “Comet vs Ajax”.

    [..]AJAX means Asynchronous Javascript And XML – it’s a way to use the web as a platform to serve applications in the same way that programs work in Windows or Mac OS.

    It’s a hot item right now because lots of developers, programmers and web users are excited about the possibilities of what can be done with AJAX as opposed to just web pages that submit information to a backend script for processing and return data. The idea is that all that can now happen on a single page (and that greater functionality and flow can follow from that).[..]
    I’m thinking why there is nothing about Comet. Comet isn’t popular at web discus groups. There inn’t a lot information about Comet on the web.

    I was trying to use it but nothing advanced.

  114. Posted September 22, 2007 at 5:22 am | Permalink

    Leo en el blog de Alex Russel la definición de comet. Podría decirse que Comet se diferencia de Ajax en que en Comet la comunicación es fluída, es decir, el servidor en cualquier momento puede enviar información al cliente, y no como respuesta a un evento como normalmente ocurre en Ajax. La diferencia en los diagramas de conexión puede apreciarse en la siguiente gráfica !

  115. Posted September 28, 2007 at 10:58 pm | Permalink

    I would appreciate it very much if ther would be a simple “Hello
    World”-example. Sounds interesting, but I haven’t a clue how to use it.
    I would only need it for about 10 concurrent user, so I don’t care
    about server performance.

  116. Posted October 6, 2007 at 11:25 am | Permalink

    I like Winters term ‘Hanging-GET’. It reduces all the mystery and confusion to something small and simple. I have to admit however, if it were not for the buzz-words ‘Ajax’ and ‘Comet’ I may have never stumbled upon these good ideas.

  117. Posted October 22, 2007 at 2:22 pm | Permalink

    What is the better to use : AJAX Comet or xmpp.

  118. Posted October 27, 2007 at 3:16 am | Permalink

    The Lycos chat uses comet for a long time, but is it really better in performance than other languages?

  119. Posted October 29, 2007 at 4:42 am | Permalink

    Will you be presenting on Comet at the Ajax Experience?

  120. Posted November 3, 2007 at 3:03 pm | Permalink

    The industry is full of stupid acronyms that are pretty unhelpful (Service-Oriented Architecture… aren’t most architectures service-oriented?), but at least they’re on track. ‘Comet’ doesn’t even start to give an impression of what you might be referring to.

  121. Posted November 4, 2007 at 7:12 am | Permalink

    Sounds similair to the old non-parsed header technique wherein you use the multipart/x-mixed-replace mime type in your response and set boundaries. I guess you combine that with ajax and voila you have persistent client server communication.

  122. Posted November 21, 2007 at 2:36 pm | Permalink

    I want to make my first implementations on my website. So I’ll be glad if someone can show me trial. nice..it looks great but is there a helpdesc or something like tutorials about Comet ?

  123. Mist
    Posted January 18, 2008 at 11:51 am | Permalink

    Having a buzz-word to describe a concept is a pretty good tactic for making a technique widespread. I myself am now using AJAX because I kept hearing it referred to across the web, and it intrigued me. Googling the word ‘AJAX’ just to find out what it meant was the first step to learning about and eventually using it.

    And while I might have not remembered the concept had someone explained it to me in tech terms, the term “Comet” is a good visual association/mnemonic device for a right-brainer creative type like myself.

    Kudos. I hope the word catches on, and poo poo on the nay-sayers.

  124. Fabio Carvalho
    Posted January 18, 2008 at 1:39 pm | Permalink

    I am working in an IM project and the client is web-based. I did everything using common AJAX techniques and soon I realized that just polling was not a good approach for many reasons. Then I just got the idea to make the server works in a pro-active way registering events and letting user agents be notified (acting as listeners) when some event is shot. As all of you already know, in order to do that using our old-fashion HTTP 1.1 I had to overcome the “request-response” behaviour, making server keep a connection and only sending it back when an event happens. I was very proud of this solution when I decided to look at the web for something similar. Suddenly I realized that many of you have already had this idea, or others similar, during these years. Anyway, I feel part of this community. In addition it is very important to coin a term like this helping it to be spread in IT industry!! Congratulations for the article.

  125. Posted January 28, 2008 at 5:37 pm | Permalink

    In a nutshell, Lighttpd appears to have better support for Asynchronous transactions (aka AJAX) and also built in support for AJAX push technology (aka COMET, which I will expand upon in upcoming posts. In the meantime checkout Alex Russel’s Blog, and the COMET page in Wikipedia) which we would be relying much upon in the Octabox service. The performance gain in those areas have convinced several prominent web-applications to go the Lighttpd way (Youtube, Meebo and Wikipedia among others)

  126. Posted February 21, 2008 at 4:33 am | Permalink

    The expensive web farm load balancers don’t have much to do anymore..

  127. Posted February 25, 2008 at 6:56 am | Permalink

    A quick update to this thread, since this is where it all started (in terms of the name Comet at least)…

    Caplin Systems (http://www.caplin.com) recently released a free version of their high performance Comet server which is used commercially for many financial applications around the world.

    The free version can be found here – http://www.freeliberator.com – and has plenty of documentation, examples and tutorials both online and as part of the kit you can download.

    Plug over :)

  128. Posted April 8, 2008 at 7:57 am | Permalink

    Like it, the concept even if it is Re-freshed Push, and the word too – Comet makes sense on a lot of levels. I vote for the word TIDE to represent the next re-boiled artefact of the old web that needs a sexy term to spark reincarnation.

  129. Posted April 20, 2008 at 2:11 am | Permalink

    I think you are right but this is not good solution for me

  130. Posted June 2, 2008 at 3:34 am | Permalink

    It seems that all these things make challenge on the browsers.

  131. Posted June 3, 2008 at 2:18 am | Permalink

    Thanks for very interesting article. I really enjoyed reading all of your articles. Keep up the good work. See You

  132. Posted June 3, 2008 at 8:13 am | Permalink

    Great information! Now I know what Gmail Talk is made of. But I noticed that you only mentioned the positive side of Comet. Are there any negative aspects of it? When is it not applicable for use?

  133. Posted June 4, 2008 at 8:24 pm | Permalink

    a quick note on comments: I’ve been deleting (or not approving) those that don’t add to the conversation on this particular post. That policy will continue. Say something interesting, useful, or provocative, or don’t say anything at all.

  134. Posted June 25, 2008 at 6:11 am | Permalink

    I really do not understand how does it works.

  135. Posted July 22, 2008 at 7:30 am | Permalink

    I wonder if Google is planning on implementing Comet ideas with their new applications that are (hush hush) supposed to let you (somehow) access your e-mail offline; and access AIR like applications off-line (in fact, this is something I think Adobe is trying to create more and more). I don’t mean Comet exactly, I mean something about the theory. I may not know what I’m talking about, but I certainly think there’s lots to be said about this concept itself.

  136. Posted July 23, 2009 at 5:19 pm | Permalink

    I think its time we had a new term for the whole HTTP streaming push group of techniques, what with emerging technologies such as HTML 5 Web Sockets, Server Sent Events and other techniques for pushing to browsers such as Silverlight and Flex. New technologies like StreamHub Comet Server are using a best-fit approach where they use Comet, HTML 5, etc… to achieve the most reliable connection to a browser. Maybe “Web Push”? Or on the theme of detergents Cillit Bang?

  137. Posted September 5, 2009 at 6:22 am | Permalink

    Great article, you show many arguments. Is there some more information about Comet in wikipedia or somewhere ?

    A lots of programmers (me too) are realy excited about the possibilities of what can be done with AJAX but there is still not enough info about this technic. Actually web users know something about web2.0 and it’s hard to understand for most of them.
    AJAX is great but in fact at advanced projects it is too slow. I have some problems too with a few browsers. That’s why I was interested about comet.
    Comet is great alternative for Ajax but it is very hard to find more info about integration with populat projects (for example google API, open source CMS).

    I think we must wait for that technology to be more popular.

  138. Posted November 30, 2009 at 9:04 am | Permalink

    Hey Alex, you rock. We’ve implemented a full comet server using the Bayeux spec for the .NET platform; it’s called WebSync. Check it out sometime if you have a couple minutes – http://www.frozenmountain.com/websync.

  139. Posted December 26, 2009 at 2:57 pm | Permalink

    I’d look into [Open]Solaris 10. It introduces a highly scalable and enhanced networking stack, which lowers overhead by reducing the number of instructions required to process packets. This efficiency also increases scalability, allowing more connections and enabling server network throughput to grow linearly with the number of CPUs and NICs.

102 Trackbacks

  1. […] Alex Russell has posted an article about what he likes to call “Comet“. […]

  2. […] Alex Russell has coined a term for a flavour of Ajax that’s been getting more attention of late. Comet describes applications where the server keeps pushing – or streaming – data to the client, instead of having the browser keep polling the server for fresh content. Alex identifies several buzzworthy examples: […]

  3. […] Alex Russell has coined a term for a flavour of Ajax that’s been getting more attention of late. Comet describes applications where the server keeps pushing – or streaming – data to the client, instead of having the browser keep polling the server for fresh content. Alex identifies several buzzworthy examples: […]

  4. By nietzsche’s blog » Comet,Ajax之??? on March 5, 2006 at 2:22 am

    […] 無???,Ajax 的出?正在改變用家?web application的感覺。 ??,我始終覺得,Ajax 的polling model 「味???如。 今天看到了Comet: Low Latency Data for the Browser, 這種Event driven 的model ?是比較?乎效益。 […]

  5. […] Alex Russell has coined a term for a flavour of Ajax that’s been getting more attention of late. Comet describes applications where the server keeps pushing – or streaming – data to the client, instead of having the browser keep polling the server for fresh content. Alex identifies several buzzworthy examples: […]

  6. […] Comet – This isn’t new (KnowNow was doing it in 2000), but it is good to see the architectural pattern documented. […]

  7. […] alex.dojotoolkit.org/?p=545 […]

  8. By Bohr’s Blog » links for 2006-03-07 on March 7, 2006 at 1:17 pm

    […] Comet: Low Latency Data for the Browser […]

  9. […] Comet: Low Latency Data for the Browser […]

  10. By Ajaxian » Comet ETech Slides Available on March 8, 2006 at 2:40 pm

    […] Alex Russell has posted slides for his ETech presentation on Comet. Comet (which we mentioned the other day) is Alex’s new term for push-style server-to-browser communication. […]

  11. By ignots abismes » Arxiu » Comet on March 10, 2006 at 12:42 pm

    […] Via ajaxian llegeixo en què consisteix això del Comet, en què s’assembla i en què difereix de l’AJAX. Una mica més de discussió al web de DOJO […]

  12. […] Comet: Low Latency Data for the Browser 早?發?的 server-side push hack,?在有人先發明新 terms […]

  13. By Bohr Yu » links for 2006-03-08 on March 12, 2006 at 7:54 am

    […] Comet: Low Latency Data for the Browser […]

  14. By JSONRequest - Kevin Henrikson on March 12, 2006 at 9:53 pm

    […] Alex Russell calls this same server-push technique Comet. I actually like Comet a bit more than Duplex. Duplex is a bit overloaded with a few other uses in tech. Like the half or full duplex with configuring network cards or terminal echo. Not as if I have a vote(just like AJAX sotra stuck), but let’s hope Comet wins. Spread It!                 […]

  15. By 泽欧里 - zeal 's Blog on March 17, 2006 at 4:01 am

    Comet: keep-alive Ajax

      我在之?的日志里???到:“当这?冗余的数?传输?得相当频?的时候(比如我之?所?的?时比分系统为了让?览器第一时间得到最新的比分?化XML数?必须以2?3秒一次的频率??…

  16. […] che è il linguaggio più bello del mondo, le cui scintille non si riescono a spegnere. Poi un link al draft di httplr, il protocollo di cui qualcuno sente la mancanza (qualcuno no, però), e ateleport, una soluzione GPL che implementa vari protocolli di comunicazione (XMLRPC, SOAP, JSON, REST, per dire) che fa parte del framework Javeline sul quale nutro un po’ di dubbi (non tanto su teleport in sè, sull’intero framework, notare che la reference guide di Javeline è un’applicazione Javeline completa). Insomma, già che se ne parla, che qualcuno prospetta soluzioni anche percorribili, mi sembra un bel passo avanti. Produrremo presto qualche esempio, per valutare con più precisione l’impatto di questi strumenti sullo sviluppo di soluzioni web.   [link] […]

  17. […] Le informazioni presenti in questo articolo le ho tratte da questo articolo in inglese, che offre ulteriori spunti di riflessione e che vi consiglio di leggere se vi interessa la cosa. Technorati Tags: ajax, applicazioni, COMET, communication, design, latency, low, model, pattern, specifica, specification, tecnologia, web, webdesign Bookmark this to:             […]

  18. […] Alex Russell writes, An old web technology is slowly being resurrected from the depths of history. Browser features that have gone untouched for years are once again being employed to bring better responsiveness to UIs. Servers are learning to cope with a new way of doing things. And I’m not talking about Ajax. […]

  19. […] Non entro nemmeno nella polemica di quanto insensato sia chiamare Ajax (ésgiacs) una cosa che non ha una definizione precisa ed esiste dai tempi in cui mia nonna progettava i primi processori Motorola a gasolio. Analogamente non ho alcun interesse a polemizzare nei confronti del nome, Comet, che Alex Russel sul suo blog assegna ad un oggetto altrettanto sfumato e da tanto tempo conosciuto. L’esigenza però è molto chiara, soprattutto a coloro, come me, che hanno progettato e sviluppato soluzioni web attraverso le quali la notifica ai browser di eventi da qualche parte lato server è diventata in alcuni casi una rinuncia dolorosa. Alex disseziona un po’ il problema, nome a parte, in maniera molto chiara, puntanto l’accento sulle performances e sulla scalabilità, sul fatto che i web servers ed in particolare Apache, non sono stati pensati, non sono stati progettati per utilizzi di questo genere, sul fatto che le soluzioni sono comunque in qualche modo hacks. Molti stimoli diversi arrivano dai commenti al post, a partire da un’ottima descrizione delle possibilità oggi offerte da strumenti standard, in particolare Php+Javascript, un confronto tra due strumenti meno standard ma che promettono scintille: Yaws, un web server ottimizzato per questo tipo di streaming scitto in Erlang, linguaggio di cui non so assolutamente nulla ma che promette scintille e Twisted Matrix, un framework per applicazioni di rete scritto in Python, che è il linguaggio più bello del mondo, le cui scintille non si riescono a spegnere. Poi un link al draft di httplr, il protocollo di cui qualcuno sente la mancanza (qualcuno no, però), e a teleport, una soluzione GPL che implementa vari protocolli di comunicazione (XMLRPC, SOAP, JSON, REST, per dire) che fa parte del framework Javeline sul quale nutro un po’ di dubbi (non tanto su teleport in sè, sull’intero framework, notare che la reference guide di Javeline è un’applicazione Javeline completa). Insomma, già che se ne parla, che qualcuno prospetta soluzioni anche percorribili, mi sembra un bel passo avanti. Produrremo presto qualche esempio, per valutare con più precisione l’impatto di questi strumenti sullo sviluppo di soluzioni web. […]

  20. […] Leo en el blog de Alex Russel la definición de comet. Podría decirse que Comet se diferencia de Ajax en que en Comet la comunicación es fluída, es decir, el servidor en cualquier momento puede enviar información al cliente, y no como respuesta a un evento como normalmente ocurre en Ajax. La diferencia en los diagramas de conexión puede apreciarse en la siguiente gráfica: […]

  21. […] From the Folks at Dojo: […]

  22. By [db75] » Blog Archive » Ajax Push on March 26, 2006 at 10:55 pm

    […] This evening I stumbled across Lightstreamer and decided to dig into their product a bit.  It appears they’re doing an Ajax push that updates the page without having to manually refresh.  You can view some of their demos by clicking here.  This is accomplished by creating an HTTP stream to the client.  With as much buzz Ajax has received over the past year I’m certain this will create even more hype.  The term Comet has been coined for Ajax push applications and I’m interested in seeing what innovative applications will leverage the technology. I know that we could potentially leverage push at SensorLogic where we build enterprise applications for remote asset management.  All sorts of devices and machines can talk to our platform over many different wireless networks.  Some of these devices report frequently where operators need to monitor their condition or location.  This data is made accessible to the operator through a standard web browser.  Now think about the operator having to refresh to look for new data every couple of minutes or so.  It would be nice to have the interface automatically when new data is received.  A lot of technology is involved to make this happen, but that’s the concept. […]

  23. By Bloggitation » links for 2006-03-28 on March 27, 2006 at 6:56 pm

    […] Comet: Low Latency Data for the Browser (tags: web comet programming web2.0) […]

  24. […] After just more than an year of the term AJAX being coined, now comes Comet – increasingly being called "the new Ajax". And as it was the case with Ajax, its just the terminology thats new, not the technology. Another detailed article on the same before it was called Comet. […]

  25. […] Pour cela, il faut donc utiliser une sorte de connection HTTP permanente pour reduire la latence des messages entre le serveur et le client. Tant que cette connection est ouverte, le serveur peut pusher des informations au client. Ce graphique, réalisé par Alex Russell, vous parlera sûrement plus que mes lignes ci dessus Je n’ai pas encore put tester cette techno, donc je ne vais pas trop m’avancer. Cet article est le résultat de mes premières recherches sur le sujet. Je vous copie/colle donc la liste des liens que j’ai put trouver et qui me paraissent intéressants. […]

  26. By Programming Ideas » links for 2006-03-28 on March 29, 2006 at 8:33 pm

    […] Continuing Intermittent Incoherency » Comet: Low Latency Data for the Browser (tags: web programming network) […]

  27. […] Check out his blog post: http://alex.dojotoolkit.org/?p=545 […]

  28. […] Comet: datos de baja latencia para el navegador […]

  29. By cat /dev/random » Oltre Ajax on April 9, 2006 at 4:36 am

    […] La prima volta che mi è apparso il box per chattare all’interno di GMail ho subito avuto l’impressione di trovarmi davanti a qualcosa di nuovo… non avevo mai visto un’applicazione web con una funzionalità simile (senza l’aiuto di ActiveX, Applet o Flash). Ajax è una tecnica che permette di interagire con il server web in seguito ad un evento lato client, senza dover ricaricare tutta la pagina visualizzata. Ma siti come GMail vanno oltre questa tecnica: il client mantiene una connessione persistente con il server, e il server può in ogni momento inviare dati ad esso, per notificare nuovi eventi generati, nel caso di GMail, da altri client. Uno sviluppatore di Dojo ha dato un nome a questa nuova tecnica: Comet. E’ probabile che diventi una nuova Buzzword. […]

  30. […] Comet: Low Latency Data for the Browser: So what makes these apps special? What makes them different from other things that might at first glance appear similar? Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client. As is illustrated above, Comet applications can deliver data to the client at any time, not only in response to user input. The data is delivered over a single, previously-opened connection. This approach reduces the latency for data delivery significantly. […]

  31. […] Please read Alex Russell’s article. 4:22 pm […]

  32. […] Today  the DWR project has released version 2.0 milestone 1. The releasenotes claim the most import new feature is ‘reverse ajax’: The biggest new feature is what we call Reverse Ajax. DWR 1.x allowed you to asynchronously call Java code from Javascript. DWR 2.0 builds on this to allow you to asynchronously call Javascript code from Java. Reverse Ajax makes writing interactive applications much easier. It can use polling or Comet (long-lived HTTP) queries. […]

  33. By Ajaxian » DWR 2.0: Reverse Ajax on April 12, 2006 at 8:10 am

    […] The big new feature is Reverse Ajax: DWR 1.x allowed you to asynchronously call Java code from Javascript. DWR 2.0 builds on this to allow you to asynchronously call Javascript code from Java. Reverse Ajax makes writing interactive applications much easier. Reverse Ajax makes writing interactive applications much easier. It can use polling or Comet (long-lived HTTP) queries. […]

  34. […] Comet (har har) seeks to apply a moniker to the batch of technologies bringing up the rear in the AJAX world. Essentially, by keeping an HTTP request open, data can be passed server-to-client, and not just client-to-server. Additionally, this open channel provides a lower-latency communications channel than individually instantianted XMLHTTPRequest objects. Neat. […]

  35. By pitruzzello.org » Miscellanea #2 on April 18, 2006 at 10:01 am

    […] COMET – Se i vostri colleghi sanno già tutto di AJAX, se volete spingervi oltre o se volete semplicemente fare i fighi nell’ambito delle applicazioni web dovreste tenere in considerazione Comet, un sistema nuovo di comunicazione asincrona con il server web. […]

  36. By Alex Le’s Blog / Comet, Improved-Ajax! on April 19, 2006 at 10:40 pm

    […] – from a DojoToolkit Blog at http://alex.dojotoolkit.org/?p=545 http://alex.dojotoolkit.org/?p=545 […]

  37. By ラクラク日記 on April 26, 2006 at 1:37 am

    A new concept – REVERSE AJAX

    新??コンセプトを勉強??。

    Reverse Ajax
    Comet Queryies

    Reverse Ajax??味?Ajaxian?ら?説明を見れ?分?る???。
    The big new feature is Reverse Ajax: DWR 1.x allowed you to asynchronously call Java code from Java…

  38. By Bisna Blog » Blog Archive » Bisna is nearby… on April 26, 2006 at 6:34 pm

    […] My idea is to support the next generation of Ajax Applications, usually called as Comet. In my analisys, in the new version I’ve fixed: Back Button issue, Browser Support and others issues already spoken by everyone. How? Using IFRAMES. Not in the commom way, but creating a wrapper that retrieves me a lot of information (basically, Headers information, so commonly discussed as an IFRAME approach issue). This’s not able to tell me if the server went down immediately, but after a user defined period, it’s possible to return an answer telling the server went down. […]

  39. […] Как ?кажет вам любой программи?т, и?пользовавший select(2), по?то?нный опро? объекта (polling) ча?то ?вл?ет?? очень не?ффективной ?тратегией. Избежать по?то?нного опро?а ?ервера в HTTP можно при помощи т.н. технологии HTTP Streaming или Comet. […]

  40. […] Comet: Low Latency Data for the Browser […]

  41. […] Here is a example demonstrate Ajax-Comet Alex talked about in his blog. […]

  42. By Ben Ramsey on May 2, 2006 at 3:56 pm

    Comet Is the New Ajax

    Renkoo Beta

    Originally uploaded by Ben Ramsey.

    This time last year, a single word began a revolution in Web design. Coined and published on February 18, 2005, by May, the word “AJAX” was on everyone’s lips. It soon…

  43. […] http://alex.dojotoolkit.org/?p=545 […]

  44. By Lazy Coder : Comet on May 3, 2006 at 2:44 am

    […] Comet ” This time last year, a single word began a revolution in Web design. Coined and published on February 18, 2005, by May, the word “AJAX? was on everyone’s lips. It soon became the talk of the entire industry, and has revolutionized Web design as we know it—or, at least, it’s given plenty of bloggers lots to talk about.” (Ben Ramsey)Now it’s time for COMET, “New services like Jot Live and Meebo are built with a style of data transmission that is neither traditional nor Ajax. Their brand of low-latency data transfer to the browser is unique, and it is becoming ever-more common. Lacking a better term, I’ve taken to calling this style of event-driven, server-push data streaming “Comet?. It doesn’t stand for anything, and I’m not sure that it should. There is much confusion about how these techniques work, and so using pre-existing definitions and names is as likely to get as much wrong as it would get right.” Filed Under: Programmable Web […]

  45. […] Personally, I think you’ll see more web-based chat systems like campfire. Why? Mainly because we’re seeing advances on the web that prevented usable web-based chat in the past – mainly AJAX for a snappy interface and Comet ( event driven, server push ) to push chat messages to the browser. Add to that some of the benefits the web-based approach may have over normal IM and you have some compelling reasons to move away from proprietary networks. […]

  46. By Ajax vs Comet at think’blog on May 12, 2006 at 1:19 am

    […] De plus amples informations sont disponible sur le site dojotoolkit : http://alex.dojotoolkit.org/?p=545 […]

  47. By Mongoose on May 16, 2006 at 9:36 pm

    Comet – 下一代Ajax

  48. […] Just Consider this post a personal yellow sticky note on my web space Read These: “Comet is the new Ajax”, and “Comet, Low Latency Data for the Browser” […]

  49. By Ajaxian » Reverse Ajax with DWR on May 24, 2006 at 3:41 pm

    […] 2. Comet, long lived Http, or the slow load technique: Are all names for the same thing. As already mentioned, the server has to wait for the browser to make contact. But this technique allows the server to start answering the browser’s request for information very slowly. Extremely slowly. Actually in the same way I used to answer my French teachers at school, it starts the reply but never actually finishes. This allows the server to keep a communications channel open (unlike me and my French teacher) to pass down additional information when the time comes. The closest we currently get to a server push. See Alex Russell’s article for the coining of the phrase and outline of definition of Comet. See Bryce Nesbitt’s for a brief description and simple demo of slow-load. […]

  50. By Reverse Ajax with DWR on May 24, 2006 at 6:50 pm

    […] 2. Comet, long lived Http, or the slow load technique: Are all names for the same thing. As already mentioned, the server has to wait for the browser to make contact. But this technique allows the server to start answering the browser’s request for information very slowly. Extremely slowly. Actually in the same way I used to answer my French teachers at school, it starts the reply but never actually finishes. This allows the server to keep a communications channel open (unlike me and my French teacher) to pass down additional information when the time comes. The closest we currently get to a server push. See Alex Russell’s article for the coining of the phrase and outline of definition of Comet. See Bryce Nesbitt’s for a brief description and simple demo of slow-load. […]

  51. […] Comet, an “event-driven, server-push data streaming” technique that is a corollary to Ajax, which we’ve discussed often here. […]

  52. […] In a recent post, I explain the difficulties of Comet (Streaming/Push) in IE. IE makes it difficult for two reasons: (a) IE’s XMLHttpRequest component doesn’t tell you anything about the response until the connection has closed – even if you try polling it instead of relying on onReadyStateChange, you’ll still get an empty string (Try it); (B) Okay, switch to plan B and inspect IFrame content – we can’t rely on onload, which is only called once at the end, so we *must* poll. But no, polling won’t help either, as the IFrame content remains empty until (you guessed it) the connection is closed. (Try it). […]

  53. […] Meebo and GMail’s GTalk integration use a different system called Comet or low-latency data transfer. This involves the browser making a request to the server which responds very slowly, keeping the communication channel open. This is definitely a possibility for eribium. […]

  54. […] Other valuable links, Comet and Slow Load, from my del.icio.us links last month refer to a novel technique being referred to as ‘reverse Ajax’ where the HTTP connection is held open to allow the web server to push further data as it becomes available in real-time. I must spend more time to understand and experiment with this concept. [Technorati: reverseajax] […]

  55. By window.onload (Again) on June 15, 2006 at 7:23 am

    […] For those who think that this is not a real issue, consider the following scenario. You have a cute web app called http://www.TickleMyKittens.com. Of course, it uses Ajax, Comet and Domestos to provide a super-slick interface, this is 2006 after all. But your site is full of kitty images many of which are hosted on a server beyond your control. Your interface is not active until all of those kitties have downloaded. You try to drag a kitty to the litter but she’s just not moving. The page has loaded, what gives? That my friend, is the window.onload problem. The onload event waits for all binary content to download before firing. No kitty-tickilng until then. […]

  56. […] 2. Comet, long lived Http, or the slow load technique: Are all names for the same thing. As already mentioned, the server has to wait for the browser to make contact. But this technique allows the server to start answering the browser’s request for information very slowly. Extremely slowly. Actually in the same way I used to answer my French teachers at school, it starts the reply but never actually finishes. This allows the server to keep a communications channel open (unlike me and my French teacher) to pass down additional information when the time comes. The closest we currently get to a server push. See Alex Russell’s article for the coining of the phrase and outline of definition of Comet. See Bryce Nesbitt’s for a brief description and simple demo of slow-load. […]

  57. […] In a recent post, I explain the difficulties of Comet (Streaming/Push) in IE. IE makes it difficult for two reasons: (a) IE’s XMLHttpRequest component doesn’t tell you anything about the response until the connection has closed – even if you try polling it instead of relying on onReadyStateChange, you’ll still get an empty string (Try it); (B) Okay, switch to plan B and inspect IFrame content – we can’t rely on onload, which is only called once at the end, so we *must* poll. But no, polling won’t help either, as the IFrame content remains empty until (you guessed it) the connection is closed. (Try it). […]

  58. […] Comet, the technique of “pushing” data to a web client using simulated persistent connections, has been getting a lot of buzz lately. Comet lets you create truly interactive, web applications without the low latency server->client communications imposed by the more primitive technique of periodic polling. Meebo uses Comet to do its magic, and so does the GTalk integration in Gmail. Most web applications probably don’t need Comet, but if you want to be in on the cutting edge then Comet opens up many possibilities. […]

  59. By kaddar.net » Current Project: Board Game on July 1, 2006 at 11:04 pm

    […] It uses sockets, and the client will be a Java applet using Java2d.  I think the client can be rewritten as any of several languages and interfaces.  I was considering flash, or a downloadable client in SDL, or even in JavaScript, using DHTML. Not really AJAX, but more like comet. There was talk of a ruby on rails technology, Armageddon, that looked interesting. For now, since I’m a single programmer who doesn’t have a lot of time to maintain cross-language implementations, especially with the pace browser technologies are changing, I’m sticking with Java for the client and server. The way I am writing the client, I think that it will be possible to reuse the same client for other games, the server will transmit enough information through the socket to draw a game.  Sorta like my own form of HyperText, but trasmitted through Object Streams.  This means that the client won’t have to be redirected to play different games, and that since the client isn’t updated often, I wouldn’t have to worry about the client caching old versions too often. […]

  60. […] Where do I see this going? I don’t know of a better set of technologies for building Comet apps. One possibility is massively multiplayer online games for browser-based clients. All types of internet-based collaboration and instanct communication apps could use this great hybrid as well. […]

  61. […] Event Driven AJAX is inspired by Comet to provide a mechanism for updating a page based on server side events, rather than waiting for user driven requests or client side polling. In this article an overview of the event driven AJAX concept is provided, along with a proof of concept demonstration of it use. […]

  62. By Deferring Reality » AJAX+Comet = Woah on August 5, 2006 at 9:39 pm

    […] Comet, on the other hand, suggests a different line of thinking. The idea is similar to AJAX, except relies on a client-initiated connection to the server that the server waits on. This could be a simple HTML page stream (like a PHP script with an echo-loop in it!) or, with JavaScript, an XMLHTTPRequest. The client opens an XMLHTTPRequest in the background after a page loads, and the server does not fulfill it. Instead, it waits – either until the connection times out, or a state change happens. If the former, the client simply reopens a new connection. In the case of the latter, the server pushes the details of the state change to the client, and closes the connection – relying on the client to immediately re-open another one to wait for further state changes. This works great. […]

  63. […] With AJAX you can poll the server on a regular interval and just update things when data has changed. Polling approaches can cause scalability problems since they can create a large number of requests to your server. Hopefully this won’t be a problem in this case since i’ll be making small requests and returning a large amount of data, and I don’t need to make them that often. There is also an alternate approach that you can use called comet, that works by each client keeping a connection open to your server and pushing data to them. But a push approach brings about a whole new set of scaling problems, so will stick with tried and true polling, and i’ll cover comet some time in the future. […]

  64. […] Hidden applets are nothing new, but once again we find that an existing technique (combining Javascript and hidden applets) is lacking a name, something that developers can use to know immediately what they talking about. So, in the vain of AJAX and Comet, and similarly lacking a better term, I would like to name the combination of Javascript And Hidden Applets JAHA. […]

  65. […] Today, I finally got around to reading about Comet. Alex Russell, who’s doing amazing things these days, coined the term sometime in the past six months. Sayeth he: An old web technology is slowly being resurrected from the depths of history. Browser features that have gone untouched for years are once again being employed to bring better responsiveness to UIs. Servers are learning to cope with a new way of doing things. And I’m not talking about Ajax. […]

  66. […] These applications are not AJAX, they take advantage of the so-called AJAX to go one step further and keep a persistent connection between client and server to stream data back and forth. Alex Russell, the author of Dojo rebranded this “pattern” as Comet and started a project to write an HTTP-based event routing bus, Cometd. Now there are Perl and Twisted implementations. […]

  67. […] It turns out that the concept of server sent events type applications has been around for some time now. Gmail uses it. Alex Russel even coined a name for it, Comet. And dojo even provides an implementation of it in cometd. […]

  68. […] In Part 1 of this series, we saw how event driven AJAX (a form of Comet) can be used to push data to the client without the need for periodic client side polling. However, we also observed that event driven AJAX broke as soon as the client had multiple views of the same page. Worse still, event driven AJAX in its current form also fails to support having more than one page open on an event driven AJAX site. This this article we will investigate how to solve this issue. […]

  69. […] Com a facilidade de ficar se comunicando com o servidor veio também o aumento do tráfego de rede, chats, geração iterativa de gráficos, jogos web multi-player, edição de textos colaborativa e muitos outros recursos que começam se popularizar neste momento, o que eles tem em comum? o  cliente precisa interagir com outros clientes, ou simplesmente receber “mensagens” do servidor. A opção existente com ajax, configuro na página para ele a cada 5 segundos chamar um método no servidor para saber tem tem algum conteúdo novo, alguma nova mensagem, já pensou no tráfego que isso gera na rede desnecessariamente? fico fazendo neste caso 20 chamadas por minuto sendo que a maioria delas vai ser totalmente inútil, agora imaginem um servidor com muitos clientes. É exatamente daí que surgiu a idéia que Alex Russell deu o nome de COMET. […]

  70. […] AJAX:ssa käyttäjä lähettää asynkronisia pyyntöjä palvelimelle ja palvelin vastaa pyyntöön. Käyttäjä voi dataa haettaessa jatkaa tekemisiään häiriintymättä. COMET poistaa puolestaan pyyntöjen tarpeen eli palvelin syöttää uutta dataa ilman asynkronisia pyyntöjäkin. Alex Russel esittelee tekniikan pintapuoleisesti artikkelissaan täällä. […]

  71. By Comet : 超越 Ajax 的新技術? at bibliophile.new on October 26, 2006 at 11:52 pm

    […] Comet 這個??詞是由 Alex Russell 今年五月所??出,比較熟知的??稱有 HTTP_Streaming?Server Push。讓 Client ?覽器與 Server 建立長時間的連線,因此Server?以直接傳資料給 Client,而?是由 Client ? request 給 Server (除了一開始的連線Request)。 […]

  72. By Life is Beautiful on October 29, 2006 at 4:53 pm

    Live Page-View Counter, Comet server and JSON-push

    Overview A page-view counter or hit counter is a mechanism that displays the number of page-views on an HTML page. It uses a server side of script that counts the page-views, dynamically generates an HTML page on the server side,

  73. By vgod’s blog » Comet (Server Push) on Turbogears on November 4, 2006 at 5:25 am

    […] ?一個方法是最近開始有?被炒熱跡象的技術: Comet。 但說穿了,Comet其實就是許多年?蠻?行的CGI?天室所用的Server Push技術。 這個方法一開始還是由client先?server建立連線,但是server在建立起連線後,?出的header中?把content-type設為”multipart/x-mixed-replace”,??是server之後?分好幾次?出許多片段資料,請client??連線??中斷,並且把?次拿到的新片段?代之?的舊片段。接著,client就??在這????斷的HTTP連線上等著收server??來的資料就好了。Comet利用這種特性,加上Ajax能在背景讀?server資料更新畫?的能力,變?一個開發rich client?常??的技術。 […]

  74. By COMET meets mod_mailbox on November 27, 2006 at 8:14 am

    […] Some time ago we got a request on how to implement COMET with lighttpd. I responded with a idea about a mod_multiplex which would allow the let the client open a COMET-channel and give the backend the possibility to feed multiple channels at once with the client to poll for new data. […]

  75. By The state of "push" on the internet. on December 4, 2006 at 2:21 pm

    […] But fortunately, now it looks like COMET is going to become a whole lot easier to do. This time its thanks to Jan Kneschke, the creator of the webserver lighttpd (which made YouTube possible), with whom we discussed this very prospect at this year’s RailsConf. […]

  76. By WebDevLogs » Ajax Server Monitor on December 8, 2006 at 5:01 pm

    […] Editor Comment: It uses not just Ajax, but COMET, impressive. […]

  77. […] The advantages to this approach have been discussed in detail elsewhere, but the biggest one (particularly for Thinkature) is that it’s a very low-latency way to communicate. Were it not for the server-to-client stream, the client would have to poll the server at regular intervals to find out if anything new had happened. The process of polling introduces some inherent latency, and it also adds to overhead through opening and closing connections and complicates synchronization (there’s no guarantee that messages will arrive in the order you expect them to). […]

  78. […] I’m proud to announce the kick off of the Dojo Offline Toolkit, which SitePen has graciously agreed to sponsor and fund. SitePen is a leader in pushing the web browser in new directions, and I’m extremely excited to be working on this project with the SitePen crew. […]

  79. By Octablog » Now Serving: Octabox on March 9, 2007 at 4:47 pm

    […] In a nutshell, Lighttpd appears to have better support for Asynchronous transactions (aka AJAX) and also built in support for AJAX push technology (aka COMET, which I will expand upon in upcoming posts. In the meantime checkout Alex Russel’s Blog, and the COMET page in Wikipedia) which we would be relying much upon in the Octabox service. The performance gain in those areas have convinced several prominent web-applications to go the Lighttpd way (Youtube, Meebo and Wikipedia among others). […]

  80. By Marc’s java weblog » Blog Archive » Comet on April 6, 2007 at 5:04 am

    […] Comet is a technique to enable server-push technology using the http protocol. Currently, users have to send a request to the server to update their status. For instance you have to press ‘check mail’ in your webmail to check for mail, the server can not notify you of new mail without your request. With Comet, the server can send an event to the browser to notify of new mail. The trick used is that the browser sends a request to the server, but instead of replying to the request the server simply waits and when it finally replies this is interpreted as an event on the client side. There are several limitations with the technique, basically it is a usefull hack. Keeping the http connection open requires resources on the server side and firewalls may drop connections that are open too long. To what extend it will be used in the future remains to be seen. You can find more info on it in the original post <a href=”http://alex.dojotoolkit.org/?p=545″>here</a&gt;. […]

  81. […] อ่านข้อมูลเพิ่มเติมได้ที่นี่ครับ http://en.wikipedia.org/wiki/Comet_(programming) http://alex.dojotoolkit.org/?p=545? Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages. […]

  82. […] Next, can y’all please stop conflating Comet with a particular HTTP-level mechanism for achieving the stated user interaction goal? It’s getting quite tiresome to hear folks say things like “long polling or Comet” as though they’re different. The XMPP HTTP binding guys even go to great lengths to explain how their Comet technique (BOSH, aka: “long-polling”) isn’t Comet. Almost as entertaining as it is wrong. Long polling along with other techniques are ways of implementing the basic Comet pattern. The general description of the pattern contains no preference for one or the other. It only requires that you not naively poll N seconds. […]

  83. […] Comet, technique d’ajax que je qualifierai d’ajax 1.1, mise au point par l’équipe du framework dojo. L’inconvénient de la méthode XHR (XmlHttpRequest) de Javascript est que toute requête se fait à la demande. Que ce soit sur un évènement OnClick, Drag’n’Drop ou même un setTimeOut(), on fait une demande d’informations par l’intermédiaire de cette méthode. On n’est pas vraiment syncho.. Le principe est donc de configurer la structure client/serveur en interlocuteurs qui s’écoutent. Le serveur écoute sans problème mais pas le client. Pour ce faire on devra boucler indéfiniement sur le serveur et dès que le serveur a quelque chose de nouveau à fournir aux clients, il flush la réponse. Le XHR étant terminé, on en recrée un. En théorie, nous ne sommes pas embété par le timeout car il n’y en a pas en XHR ^,..,^ […]

  84. By Server Side Push and Comet « stop motion on August 10, 2007 at 5:54 am

    […] So, I set up on a quest to find other technologies available for server side push, and came across Comet. Comet is essentially a style of programming that allows event-driven server-side push data streaming. The best example of Comet is Google Talk inside GMail. Zhou Renjian has already cracked this and created a plain JavaScript implementation. There is no dearth for implementations of this technology. However, none of those fit our needs exactly. […]

  85. By Push Data avec Comet « Laurent’s Weblog on September 29, 2007 at 8:23 am

    […] Comet: Low latency data for the browser (Alex Russel) […]

  86. By Comet Daily » Blog Archive » Why Comet Daily? on October 19, 2007 at 12:46 pm

    […] Comet, the term coined by Alex Russell in his seminal article on this topic, has followed a somewhat similar adoption trajectory. Like Ajax, Comet is a collection of techniques and technologies rather than a single language or option. In fact, Comet techniques have been around for about 8 years, and like Ajax and JavaScript, there is no one company promoting or explaining Comet to the masses. […]

  87. […] It may be worthy to wrap the file browser as a dojo dijit, and that is also a good candidate for comet. The server may register handlers for file system events(check System.IO.FileSystemWatcher, inotify in Linux) , then push the status change to the client. That is quite a little work, so I would rather leave the placeholder here and implement some other features first. […]

  88. […] Lately we have been doing some work with persistent connections. If you are familiar with Comet the Flash/AS3 URLStream class provides an interesting alternative. The URLStream class exposes raw binary data as it is downloaded. […]

  89. By Day1: @media ajax November 2007 — onenaught.com on November 21, 2007 at 5:07 pm

    […] It was a great discussion on the idea behind Comet (rather than the client polling the server continuously for something, being able to push data and events from the server to the client, all while using the existing HTTP infrastructure, which is not built for this type of communication. In short it involves having a script element request a resource from the server, but the server never returning, just blocking until different messages/events/data needs pushing. Simple in idea but involves some complexities to overcome. I will be trying to look into this further.) […]

  90. By dparrish.com » Blog Archive » Comet with Apache on November 27, 2007 at 10:05 pm

    […] I’ve been mucking around with Comet, and ran into a situation which I couldn’t seem to find a solution on the lazyweb for. The problem was that none of the streamed JavaScript code blocks would be executed until the entire page was loaded. […]

  91. By Link for 2007.12.29 « Derivadow.com on December 29, 2007 at 4:26 pm

    […] » Continuing Intermittent Incoherency » Comet: Low Latency Data for the Browser Comet applications can deliver data to the client at any time, not only in response to user input. The data is delivered over a single, previously-opened connection. […]

  92. By SitePen Blog » Blog Archive » CodeMash 2008 on January 17, 2008 at 1:57 pm

    […] SitePen is at the forefront of changes happening on the browser end of browser-based software. We’re also looking deeply at how things are changing on the server. An increasing number of CPU cores in our systems and techniques like Comet require us to think about concurrency beyond simple threading on the server. Relational databases are powerful and reliable, but non-relational databases have the potential to speed access to our ever-increasing volumes of data or to improve productivity by more closely matching our main programming languages. […]

  93. […] About a year ago, I became aware of Comet, a name for an idea that’s been around for countless years.   I believe http://alex.dojotoolkit.org/?p=545 is where it was first coined.  In contrast to the ignorant and abusive comments posted on that page, in my case, giving the idea a name was an important step in realising that the idea actually exists.  There was a model for setting up low latency bidirectional communication between the web browser and the web server. […]

  94. […] using Jetty and Dojo Jump to Comments The term comet was created by Alex Russell (dojo). There are several different implementations out there. Jetty, Tomcat and Glassfish (for instance) […]

  95. By sourcebottle.net » Blog Archive » Weekend Links on February 29, 2008 at 5:40 am

    […] Comet, a new Web 2.0 buzzword! (and also an electronics store!) […]

  96. […] as he is apparently a self publishing non-notable tech blogger (in wikipedia terms), and thus the original blog is not a sufficient citation. In some part I agree with wikipedia on this, namely that we should […]

  97. By techfounder » Comet is coming on July 15, 2008 at 4:22 pm

    […] term was coined by Alex Russell of Dojo fame, in a blog piece a little more than two years ago. It has since gained minor traction in the development community, with several projects actively […]

  98. By (not quite) Time for Comet : Eclectic Dreams on September 16, 2008 at 4:06 pm

    […] comet is something I’ve been following since Alex Russell coined the term and my interest was re-ignited by Simon Willison’s, Time for Comet […]

  99. […] using standard HTTP.   One of the members of the Dojo Toolkit javascript framework coined the term Comet, a play on the Ajax name, to describe the concept.  With the Bayeux protocol, they have found […]

  100. […] I heard it long ago when it just started out in Ajaxian’s post. They described it best: Alex Russell has coined a term for a flavour of Ajax that’s been getting more attention of late. Comet describes applications […]

  101. By Comet Daily » Blog Archive » Comet = Real Time Web on October 25, 2008 at 12:33 am

    […] primary reference for an accurate definition of Comet, in fact this entry is heavily based on the original definition of Alex Russell and work of other CometDaily contributors like Jacob […]

  102. […] At the time, I only really knew Perl, and was only self-taught at that.  So I wrote the first version as a Perl CGI.  I remember abusing the server-based multipart push feature we used for image animation to allow the Perl CGI to stream new messages to the browser as they arrived in the chat room.  JangaChat, and this system I worked on at INJersey, may have been some of the first uses of hanging GETs. […]