Comet: "server push" technical notes based on HTTP persistent connections

This article mainly describes the HTTP server push technology. Comet is a term in the world for server pushing technology.

1. Flash-based. Flash provides the xmlsocket class, which can be combined with JavaScript to implement comet.

2. Java Applet-based. This can be done, but the disadvantage is that the browser needs to install the JRE plug-in, and the applet cannot update the webpage after obtaining data. There should be a way to do this. I remember searching for the applet and JavaScript communication methods on Google before.

3. Ajax-based long polling mode. This is one of my concerns. Previously, I used an Ajax query. The server returns the query result and then updates the interface. Ajax queries are timed. As mentioned in this Article, the disadvantage of doing so is that the Ajax query is periodically sent out, so it is possible that the user has started to operate on the current data before the next query, in fact, the client does not know that the data has changed. In short, what users see and operate in this way is not real-time data. It is better not for the client to go To the timed query, but for the server to change the data and push it to the client. Therefore, this method-Ajax long polling method is used in this article. This method means that after the server receives an Ajax request, it does not return until data is updated or times out. In this way, the client's Ajax request will be blocked until the server returns. If a timeout is returned, the client immediately creates a link. Obviously, this is the result of simulating "server push" using persistent connections. Why set timeout? Isn't blocking good? This is because some routers on the network will discard connections that have been too long.

Therefore, this method is not a new method, but a disguised comparison. One thing that is not mentioned in this article is that AJAX requests are the same as HTTP requests. Although they occur in the background, if no response is returned in the background, the requests will block other requests, that is, if the Ajax request is not returned, click the link on the page and the browser will not respond. I think, to solve this problem, we can only put the JS Code that sends an Ajax request in a separate frame and define it as a hidden frame. In this way, other frames will not be blocked, this is our interface.

4. The fourth method is more crude, namely defining an IFRAME. Of course, this IFRAME is hidden and invisible on the interface. Then, set the SRC of the IFRAME to a persistent connection request. When the server receives this request, it is blocked until data is updated or times out. The disadvantage of doing so is that because the server never returns, the browser will think that the IFRAME has not been fully loaded. Therefore, the loading information will always be displayed on the browser interface. Google is said to have solved this problem because Gtalk and Gmail use this technology.

The advantage of this method is that you can directly set the SRC of IFRAME as an HTTP request without returning Ajax. Essentially, it is similar to method 3 in Ajax.

For details, see Appendix 1. As mentioned in the article, the current HTTP requests are not for such persistent connections, because the HTTP request links are always short and fast. Currently, some HTTP servers, such as jetty, are optimizing the persistent connection.

It is also worth mentioning that the article mentioned an open source project-pushlet, which is a comet implementation. You can refer to the website of this project and there are many demos on it to demonstrate the comet technology, that is, the client does not need to be refreshed manually, and the interface is automatically refreshed.