It is the bird that soars the sky, it is the plane that crosses sky ...
Comet is a term used to describe the interaction between the client and the server, that is, to support event-driven communication between the client and the server using a long-running HTTP connection to keep the connection unblocked. Since Alex Russell defined this term in comet:low latency Data for the browse, Comet has become a frequent WEB 2.0 vocabulary. A Comet-style application Sets the connection timeout value to maximum and leverages the infrastructure to provide faster browser updates than other solutions, and less data transfers-which sounds great. However, there are drawbacks to Comet style connections, and you should be aware of these shortcomings before you consider using them.
Problems solved (and problems)
The most common problem that many developers in the WEB 2.0 domain need to address is the streaming events that are generated on the server for the client. There are three common ways to resolve this problem:
Polling
In this method, a Javascript™ running in the browser sends a request at a configured interval to check for events that it should receive. The server's response is immediately sent back: An event that has occurred, or a notification that there is no corresponding event. If the interval that the client sends the request is too short, it can have a significant performance impact. If the interval is too long, the event notification may arrive later than the client's expected time.
Figure 1. Polling
Comet long polling or mixed polling
Applications that use mixed polling also have some of the benefits of Comet style applications and some of the benefits of polling style applications. Javascript in the client's browser initiates initial data requests to the backend server. The server responds almost immediately, but keeps the socket open to complete the response write (if a response occurs during its opening). For example, the server may keep the socket open for 30 seconds, and if an event occurs within that time period, it is immediately fed back to the client. However, if there is no event during this time period, or if the client needs to send more data to the server, the connection is closed and the client will reopen another connection after a period of time. Some implementations open the read channel as a long-term HTTP GET, while the other opens the Write channel as an HTTP POST, which is turned on and off when needed. XMLHttpRequest in Javascript are often implemented this way.
Figure 2. Mixed polling
Comet Flow or Forever Frame