Reverse Ajax to enable the server to push messages to the client Comet

" Server Push " technology is "Comet" based on HTTP long connections and no need to install plugins on the browser side .

　　　　

The implementation models for the two Comet applications are described below.

AJAX-based long polling (long-polling) mode

The advent of AJAX makes it possible for JavaScript to invoke the XMLHttpRequest object to make an HTTP request, and the JavaScript response handler updates the display of the HTML page based on the information returned by the server. Using AJAX to achieve "server push" differs from traditional AJAX applications in that:

1. The server side blocks the request until there is data delivery or a timeout to return.
2. The client-side JavaScript response handler functions to re-establish the connection after processing the information returned by the server, making a request again.
3. When the client processes the received data, re-establishes the connection, the server side may have new data arrival; The information is saved by the server until the client re-establishes the connection, and the client will retrieve all the information from the current server at once.

Figure 2. A server push model based on long polling

Some applications and examples such as "Meebo", "Pushlet Chat" have adopted this way of long polling. This type of long polling can also be called pull when compared to polling (poll). Because this scenario is based on Ajax, it has the following advantages: The request is sent asynchronously, no plugins are installed, IE, Mozilla FireFox supports Ajax.

In this long polling mode, the client invokes the callback function when the XMLHttpRequest readystate is 4 (that is, the end of the data transfer) for information processing. When readystate is 4 o'clock, the data transfer ends and the connection is closed. Mozilla Firefox provides support for streaming AJAX, which means that readystate is 3 o'clock (the data is still in transit) and the client can read the data so that it can read the information returned from the processing server without shutting down the connection. IE in readystate for 3 o'clock, can not read the data returned by the server, IE is not supported based on streaming AJAX.

Stream (streaming) mode based on Iframe and Htmlfile

An IFRAME is an early HTML tag that, by embedding a hidden frame in an HTML page, then sets the SRC attribute of the hidden frame to a request for a long connection, and the server can continuously input data to the client.

Figure 3. A server push model based on streaming mode

The AJAX scheme mentioned in the previous section is to process XMLHttpRequest data retrieved from the server in JavaScript, and JavaScript can easily control the display of HTML pages. The same idea is used by the client in the IFRAME scenario, the IFRAME server does not return the data directly displayed on the page, but instead returns a call to the client-side Javascript function, such as " <script type="text/javascript">js_func(“data from server ”)</script> ". The server side passes the returned data as parameters to the client JavaScript function, and the client browser's JavaScript engine executes the code when it receives the JavaScript call returned by the server.

As you can see from Figure 3, each time the data transfer does not close the connection, the connection is closed only when there is an error in communication, or when the connection is rebuilt (some firewalls are often set to discard too long connections, the server can set a time-out, notify the client to reestablish the connection after timeout, and close the original connection).

Using an IFRAME to request a long connection has a very obvious disadvantage: ie, Morzilla Firefox lower progress bar will show that the loading is not completed, and the icon above IE will not stop rotating, indicating that the load is in progress. Google's geniuses use an ActiveX called "htmlfile" to solve the load display problem in IE and use this method in the Gmail+gtalk product. Alex Russell at "What else was burried down in the depth's of Google's amazing JavaScript?" This method is described in the article. Zeitoun Web site provides the comet-iframe.tar.gz, encapsulates an IFRAME and Htmlfile based JavaScript Comet object, support IE, Mozilla Firefox Browser, can be used as a reference. (See also reference resources)

Use the Comet model to develop your own applications

The two "server Push" architectures based on HTTP long connections are described above, and more describe the techniques that clients handle for long connections. For a practical application, the stability and performance of the system is very important. Using HTTP long connections for real-world applications, many details need to be considered.

Do not use more than two HTTP long connections on the same client at the same time

When we use IE to download files, we will have the experience to download files from the same Web server, up to two files can be downloaded at the same time. The download of the third file is blocked until the previously downloaded file is downloaded. This is because the HTTP 1.1 specification specifies that the client should not establish more than two HTTP connections to the server, and the new connection will be blocked. IE in the implementation of strict adherence to this rule.

The limitation of HTTP 1.1 to two long connections would be the following for Web applications that use long connections: If the client opens more than two IE windows to access the same long-connected Web server, the HTTP request of the Third IE window is blocked by a long connection to the first two windows.

Therefore, when developing long-connected applications, it is important to note that in pages that use multiple frames, do not set up an HTTP long connection for each frame's page, which blocks other HTTP requests, and is designed to allow multiple frame updates to share a long connection.

Server-side performance and scalability

The general Web server creates a thread for each connection, and if you use Comet in a large commercial application, the server side needs to maintain a large number of concurrent long connections. In this application context, server-side needs to consider load balancing and clustering technology, or on the server side for a long connection to make some improvements.

The development of applications and technologies always leads to new requirements, thus driving the development of new technologies. There is a big difference between the HTTP 1.1 and the 1.0 specification: The 1.0 specification is that the server shuts down the socket connection after each Get/post request is processed, and the server maintains the connection under the 1.1 specification, and the connection is idle during the interval between processing two requests. Java 1.4 introduces a Java.nio package that supports asynchronous IO. When the connection is idle, the thread resources allocated for the connection are returned to the thread pool, which can be used for new connections, and when a new request is made by a customer who originally was in an idle connection, a thread resource is allocated from the line constructor to process the request. This technique is very effective in reducing the server's resource load in scenarios where the connection is at a high probability of being idle and a large number of concurrent connections.

But the application of AJAX makes the request become frequent, while Comet takes up a connection for a long time, the server model above will become very inefficient in the new application background, the thread constructor the limited number of threads may even block the new connection. Jetty 6 Web Server for AJAX, Comet application features a lot of innovative improvements, please refer to the article "Ajax,comet and Jetty" (see Reference resources).

Control information and data information using a different HTTP connection

When using long connections, there is a common scenario where the client Web page needs to be shut down and the server side is still plugged in to read data, and the client needs to notify the server to close the data connection in a timely manner. When the server receives the shutdown request, it first wakes from the blocking state of the read data, and then releases the resources allocated for the client and closes the connection.

So in design, we need to make the client's control requests and data requests use a different HTTP connection in order for the control request not to be blocked.

On the implementation, if it is a long connection based on the IFrame stream, the client page needs to use two IFrame, one is the control frame, to send the control request to the server side, the control request can receive a response quickly, will not be blocked; one is a display frame for sending long connection requests to the server side. If it is an AJAX-based long polling method, the client can send an XMLHttpRequest request asynchronously, notifying the server to close the data connection.

Maintain "heartbeat" information between the customer and the server

Maintaining a long connection between the browser and the server creates some uncertainty for communication: Because the data transfer is random, the client does not know when the server will be able to transmit data. The server side needs to ensure that the resources allocated to this client are freed when the client is no longer working, preventing memory leaks. So a mechanism is needed to make both parties aware that everyone is working properly. On the implementation:

1. The server side sets a time limit for blocking reads, which blocks the read call when it expires and sends a heartbeat message to the client that no new data arrives. At this point, if the client is closed, the server writes data to the channel with an exception, and the server will release the resources allocated to the client in a timely manner.
2. If the client uses an AJAX-based long polling method, the server returns data, closes the connection, and, after a certain time period, does not receive a request from the client, it will assume that the client is not working properly and will release the resources allocated and maintained for this client.
3. When the server handles information anomalies, it needs to send an error message to notify the client while releasing the resource and closing the connection.

Reverse Ajax to enable the server to push messages to the client Comet