Comments for Comet: Low Latency Data for the Browser
Will you be presenting on Comet at the Ajax Experience?
Rich
Rob: If you like!
There's definitely something to be said for stateless ...
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
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.
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.
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
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.
/me revises ETech slides
once again, people doing serious http streaming should look at yaws
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.
I would still like to see the benchmarks = )
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.
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.
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.
Good to know this type of functionality is moving forward :)
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.
Would it be a burden for the server? Due to the frequently requests.
some more intelligent notes on erlang vs twisted
"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.
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.
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
(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/
ããæå¨ä¹å?çæ¥å¿éé?¢æ??å°ï¼âå½è¿ç§?åä½çæ°æ?®ä¼ è¾å?å¾ç¸å½é¢ç¹?çæ¶åï¼æ¯å¦æä¹å?æå?çå?³æ¶æ¯åç³»ç»ä¸ºäºè®©æµ?è§å¨ç¬¬ä¸æ¶é´å¾å°ææ°çæ¯åå?åXMLæ°æ?®å¿ 须以2ã?3ç§ä¸æ¬¡çé¢çä¸?å?ç...
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
Thanks in advance.
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?
http://www.kevin-mcarthur.com/Stream2.0 for more info.
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.
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.)
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
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 =)
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
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.
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
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.
Many firewalls stop long living HTTP connections :( , I guess that you allways have to fall back on the old poll thing again.
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.
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 .
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
æ°ã?ã?ã³ã³ã»ãããåå¼·ã?ã?ã
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...
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...
Thanks
- 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
thank you
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
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
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.
:)
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.
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,
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).
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
PS! [Shameless plug...] And while you're at it if you're a .NET developer, make sure you check out; http://ajaxwidgets.com ;)
.t
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
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
I want to make my first implementations on my website. So I'll be glad if someone can show me trial.
Serg
[..]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.
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 ?
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.
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 :)
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.