Monday, June 25th, 2007

Why COMET rarely is necessary…

Category: Comet

Frank M. Thürigen has written a simple opinion on Why COMET rarely is necessary….

The example used is our old favourite….. Chat:

General rule:

If the only way the user has to judge the responsiveness of an application is his own actions – give him an estimated result before the real result appears.

Have a look at it:

The following link will lead you to my “playgrounds”. In the user field top right enter any name you like and hit RETURN. Select “communication” :: “chat” from the menu and watch the chat behaviour when submitting some lines short after each other…

Frank has a chat playground setup for us to play in.

Comet is getting easier to use, and we are seeing it show up in places such as the new Servlet 3 specification. Maybe then we will see more of these architectures, although even then it may make sense not to jump to it.

twoBirds Chat

Posted by Dion Almaer at 5:08 am
13 Comments

+++--
3.3 rating from 27 votes

13 Comments »

Comments feed TrackBack URI

Rendering the text line without going through the server is a neat trick to improve the user experience.
An unrelated question: the chat demo is polling the server every 80/150 ms even if nothing’s going on. It’s not very efficient. Why not using a long-polling request? I’m thinking about Jetty 6’s demo chat application which works well and doesn’t poll the server so much.

Comment by Paolo Montrasio — June 25, 2007

The polling frequency is configurable of course, and on the long range I want to implement a user typing behaviour analysis to automatically adapt for the best frequency depending on usage.

Comment by Frank Thuerigen — June 25, 2007

What I normally do is
– the client makes an Ajax request to the server
– the server keeps the request alive for up to 30 seconds but if data arrives for the client, a response is served immediately.
– the client starts another request

This normally requires one thread per client but Jetty’s continuations help dealing with all those requests with only a few threads.

This adapts to the usage by definition, because both client side and server side events are sent to the other party as soon as they are generated.

Comment by Paolo Montrasio — June 25, 2007

COMET is not necessary, in the same way that AJAX is not necessary. You could implement a chat application with a refresh header and a form. But AJAX is better in this case because it reduces network load (you only send the messages, rather than whole pages) and improves the user experience. The underlying program architecture is almost identical.

COMET is an improvement on AJAX (again, in this case) because it further reduces network load by eliminating the repeated connection setup and tear-down overhead, especially in the case where there is no activity but clients are still polling; simplifies implementation by removing the need to keep around messages after they’re sent; and improves the user experience by removing the polling delay between when a message is sent and received.

COMET is as big an improvement over AJAX for this type of application as AJAX is over a non-scripted implementation. For something like massively multi-player online games, AJAX is not a viable technology, but COMET very well might be.

Comment by dak — June 25, 2007

dak, I wholehartedly agree. The article is meant to show that you may not need COMET to improve your site for regular website usage. It doesn´t say COMET is never necessary – depending on site usage it is a great tool.

Comment by Frank Thuerigen — June 25, 2007

One thing I’m not sure about when it comes to Comet is dealing with scalability.

If you’re running an application that needs to support large quantities of users (ie: million plus), would a standard Ajax approach not be better than a Comet implementation?

Comment by Frank — June 25, 2007

@Frank: one one of those megasites the decision between using plain AJAX or COMET is driven by the system hardware. It depends on whether you have a big cluster of small application servers or one or a few of the real “big iron” machines. If you scale by the number of servers, COMET might be your choice. If you have one or a few real big server(s), plain AJAX might be better. Depending on usage header traffic becomes an argument also.

Comment by Frank Thuerigen — June 25, 2007

Comet/Push is an important technology not just due to the fact that it solves the requirements of close to zero latency (an inherent problem with polling), but also because it scales much better. The time wasted in polling to establish and tear down connections again and again, just to find out that there is really no change the client needs to know about, is eliminated with push. This problem is much more serious when there are a large number of clients involved – the amount of hardware required to support the same number of clients with close to real time requirements is significantly less with push vs. polling. We do however need to ensure that we are running a webserver & appserver that can support keeping connections open without keeping threads bound to them, or very quickly we will saturate the threadpools of the webserver & appserver and we will not even be able to get an image from the webserver. Jetty and Oracle’s OC4J & OHS AS11 already support this asynchronous response mode.

Comment by Tal Broda — June 26, 2007

Again, I didn´t say anything against COMET. The article is focussed on user reception on websites. The technique shown in the article is an improvement without using COMET, and thats it – no more. If you talk about the real big applications (traffic / users) you need to plan in much more detail, and this is out of scope of the article.
@Tal: I am aware that especially when it comes to JIT business process presentation and JIT production controlling there is no way around COMET – hence Oracle´s approaches…

Comment by Frank Thuerigen — June 26, 2007

While it is true that many existing web applications do not need the low latency of comet, this is probably a result of the fact that applications that need real low latency communications have not been considered suitable for web interfaces.

Once comet is established as a technique and the scalable concerns addressed (as they can be), then I think we will see a whole class of interactive and collaborative application emerge that we would not have previously thought possible.

We used to live with international communications with geostationary satellite delay and thought nothing of it. But take away the worlds fibre optic network now and I think you would notice a big difference in every news broadcasts, every game of world of war fare, computer trading and a host of applications that now depend on low latency.

Comment by Greg Wilkins — June 29, 2007

I completely agree with Greg. I add that some industries are moving their application to the Web paradigm thanks to Comet. For example, most of Lightstreamer’s adopters are financial institutions and betting companies whose applications need low latency as a fundamental requirement. Without Comet, they would stick to thick applications or Java applets.
But I also understand Frank’s point of view. Not every interactive application need Comet. I think it’s a balance that takes into account: actual application requirements, scalability, real Comet availability, simplicity of integration. Both the Lightstreamer world and the Cometd world are providing good foundations to make Comet convenient enough even when it is not strictly necessary.

Comment by Alessandro Alinone — June 29, 2007

A pet peeve of mine is tech guys who think (x) is rarely/not necessary. I don’t know about this particular author, but usually the comment is made by folks inexperienced enough to not have learned a) that no one person can realize all (or even very much) of the situations in which (x) can be used, and b) new tech breakthroughs sometimes lead to capabilities and whole areas that had not been considered before.

While it’s valid to point out that (x) is overused, or not needed in certain types of situations, it’s naive to claim ‘rarely/not necessary’.

Comment by RH — July 2, 2007

RH, the title is calling for comments, I have to admit. I´ve been programming long enough to know how and when to choose the right tool for the task at hand and this includes COMET if need be ;-)

Comment by Frank Thuerigen — July 7, 2007

Leave a comment

You must be logged in to post a comment.