on Aug 3rd, 2007Comet paradigm implementation
There are a lot of schools of thought when it comes to the comet paradigm. There are some who think of comet as a technology in itself that can change the way the web works, while others think its nothing more than another buzzword alongside Ajax and Web2.0. I think, in essence , the latter is more appropriate.
Comet is essentially an design principle which aims at achieving true push technology using http. Comet is not a technology in itself, cometd is an implementation effort to make such a paradigm possible, but comet itself isnt a technology. For real time systems and other applications like stock tickers you don’t need an entire page refresh, its enough if you can get the updated values in your respective places. Ajax seemed to be the answer for sometime with browsers asynchronously requesting for changes and then updating the same in DOM. The problem with Ajax was the polling, since the job was asynchronous, there was a interative pattern of asynchronous requests and replies. Even though there wasn’t any change in the server values, the client would request repeatedly to check if the values changed, which led to the server being overloaded. The solution was to push the updates to a client without the client requesting for it. Sorta like the good old days of socket programming.
There are many solutions to this problem, each one with its own set of advantages and disadvantages but I shall explain a single implementation that I worked on. Its called the Long Looping method.

Long Looping Method :
This method involves making a request to the server which in itself will reply only when there was a change. Your browser will keep showing you the loading icon coz the server hasn’t replied as yet. The server end can achieve the desired result by either suspending a request to a thread that will wait till notified or a putting the request through an infinite loop. Once there is a change of state on the server the loop ends and the reply sent. The client receives the reply and immediately sends another request for further changes and so on.
In this way you can see that, there is always a low latency http connection between the client browser and the server. The delay in state changes to the server is very low and will definitely be ten orders better than the regular ajax looping method.


blFey5O1QwCaz
Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru
Where’s the Beef? First approach uses 4 server threads to provide response data, second approach uses 4 server threads to provide response data.