"Go" Comet: "Server Push" technology based on HTTP long connections

Original link: http://www.ibm.com/developerworks/cn/web/wa-lo-comet/

Many applications such as monitoring, instant messaging, and instant quote systems need to deliver changes in the background in real time to the client without the client continually flushing and sending requests. This paper first introduces and compares the commonly used "server Push" scheme, and emphatically introduces Comet-two "server push" schemes that use HTTP long connection and no browser-installed plug-ins: Long polling based on AJAX, and stream mode based on IFRAME and Htmlfile. Finally, some problems needing attention in developing comet application are analyzed, and how to build your own "server Push" application with the help of the open-source comet framework-pushlet.

Application of "Server Push" technology

Visit the Ajax Technology Resource Center, a one-stop center for information about the AJAX programming model, including many documents, tutorials, forums, blogs, wikis, and news. Any new Ajax information can be found here.

The traditional mode of the WEB system works in a way that the client makes the request and the server-side responds. This approach does not meet the needs of many real-world applications, such as:

• Monitoring system: Background hardware hot plug, LED, temperature, voltage changes;
• Instant communication system: Other users login, send information;
• Instant Quote system: Background database content changes;

These applications require the server to deliver updated information to the client in real time, without requiring the client to make a request. "Server Push" technology in real-world applications have some solutions, this article divides these solutions into two categories: the need to install plug-ins on the browser side, based on the socket interface to send information, or use RMI, CORBA for remote calls, and the other without the browser to install any plug-in, HTTP-based long connection.

Applying "server Push" to a WEB application, the first thing to consider is how to receive and process information on a browser with limited functionality:

1. How the client receives and processes the information, whether it needs to use a socket interface or use remote invocation. Whether the client renders the HTML page or the Java applet or Flash window to the user. If you use a socket and a remote call, how to modify the display of HTML with JavaScript.
2. Customer and server-side communication information format, to take what error-handling mechanism.
3. Whether the client needs to support different types of browsers, IE, Firefox, whether it is necessary to support both Windows and Linux platforms.

"Server Push" technology based on client socket interface Flash XMLSocket

Using Flash XMLSocket is also a viable option if your Web app's user acceptance app only works if the Flash Player is installed.

The basis for this approach is:

1. Flash provides the XMLSocket class.
2. The tight combination of JavaScript and Flash: the interface that the Flash program provides can be called directly in JavaScript.

Implementation method: Embedded in the HTML page a Flash program that uses the XMLSocket class. JavaScript communicates with the server-side socket interface by invoking the set of interface interfaces provided by this Flash program. JavaScript can easily control the display of the contents of an HTML page after it receives information that is sent in XML format on the server side.

about how to build a flash program that acts as a JavaScript and Flash XMLSocket Bridge, and how to invoke the interface provided by Flash in JavaScript, we can refer to Aflax (asynchronous Flash and XML) project provides the Socket Demo and Socketjs (see Reference resources).

The close combination of Javascript and Flash greatly enhances the processing power of the client. Starting with Flash player V7.0.19, the XMLSocket port must be larger than the 1023 limit. The Linux platform also supports Flash XMLSocket scenarios. But the downside of this scenario is that:

1. The client must have a Flash player installed;
2. Because the XMLSocket does not have the HTTP tunneling function, the XMLSocket class cannot pass through the firewall automatically;
3. Because of the use of a socket interface, you need to set up a communication port, firewall, proxy server may also restrict the non-HTTP channel port;

However, this scheme has been widely used in some network chat rooms and online interactive games.

Java Applet Socket Interface

"Server Push" is achieved by using Java applets on the client, either through java.net.Socket or through java.net.DatagramSocket java.net.MulticastSocket a connection to the server-side socket interface.

The biggest disadvantage of this scenario is that the Java applet cannot update the contents of the HTML page via JavaScript after it receives the information returned from the server side.

"Server Push" technology based on HTTP long Connection Comet introduction

The browser as the foreground of the WEB application, its processing function is relatively limited. The development of the browser needs the client to upgrade the software, at the same time due to the diversity of client browser software, in a sense, also affected the promotion of new browser technology. In WEB applications, the main task of a browser is to send requests, and the information returned by the parsing server is displayed in a different style. AJAX is the result of the development of browser technology, which improves the responsiveness of single-user operations by sending asynchronous requests on the browser side. But the WEB is essentially a multi-user system, and for any user, the server can be considered another user. The development of existing AJAX technology does not solve in a multi-user Web application, the updated information in real-time to the client, so that users may be "outdated" information under the operation. The application of AJAX makes it possible to update the background data more frequently.

Figure 1. Comparison between the traditional WEB application model and the AJAX-based model

"Server Push" is a very early technology, previously implemented mainly through the client's socket, or server-side remote call. Because of the slow development of browser technology, there is no good support for the implementation of "Server Push", in the application of pure browser It is difficult to have a perfect scheme to implement "server push" and use it for commercial process. In recent years, because of the popularity of AJAX technology, and the embedding of IFrame in the "Htmlfile" ActiveX components can solve the load display problem of IE, some popular applications such as Meebo,gmail+gtalk in the implementation of the use of these new technologies; and "Server Push" There are many needs in real-world applications. For these reasons, "server Push" technology based on Pure browser is starting to get more attention, Alex Russell (Project Lead of Dojo Toolkit) calls this "server push" technology that is based on HTTP long connections and does not need to install plugins in the browser. There have been some mature Comet applications and various open source frameworks, and some WEB servers such as Jetty are also making a lot of improvements to support a large number of concurrent long connections. For the latest developments in Comet technology, please refer to the wiki on comet.

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

AJAX-based long polling (long-polling) mode

As shown in Figure 1, 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.

Pushlet-Open Source Comet framework

Pushlet is an open-source comet framework that has a lot to learn from the design and is valuable for developing lightweight comet applications.

Viewer model

Pushlet uses the Observer model: the client sends a request, subscribes to an event of interest, and the server assigns a session ID to each client as a token, and the event source sends the newly generated event to the subscriber's event queue in a multicast manner.

Client JavaScript Library

Pushlet provides an AJAX-based JavaScript library file for "server Push" for long polling, and an IFrame-based JavaScript library file to implement streaming "server Push".

The JavaScript library does a lot of encapsulation work:

1. Define the communication status of the client:,,,,, STATE_ERROR STATE_ABORT STATE_NULL STATE_READY STATE_JOINED STATE_LISTENING ;
2. Save the session ID assigned by the server, and attach the session ID to identify each request after the connection is established;
3. Provide,,,, and join() leave() subscribe() unsubsribe() listen() Other APIs for page invocation;
4. Provides a JavaScript function interface for handling responses onData() , onEvent() ...

The Web page makes it easy to communicate with the server using the API encapsulated by these two JavaScript library files.

Client and server-side communication Information format

Pushlet defines a set of information formats that clients communicate with the server, using XML format. Defines the type of client send request:,,,, join leave ,, subscribe unsubscribe listen refresh and the event type of the response: data , join_ack listen_ack refresh heartbeat error abort ,,,,,, subscribe_ack, unsubscribe_ack .

Server-side Event queue management

Pushlet is implemented on the server side using Java Servlet, and the design framework of its data structure can still be applied to the background client written by PHP and C.

Pushlet supports clients choosing to use streaming, pull (long polling), polling methods. The server side handles different processes when reading the event queue (fetchevents), depending on how the customer chooses. "Poll" mode fetchEvents() will return immediately. The "stream" and "pull" modes use blocking read events and, if timed out, send a "heartbeat" event to the client that does not receive new information, and if "pull" mode, the "Heartbeat" and "refresh" events are passed to the client, notifying the client to re-issue the request and establish a connection.

Session Management between Client servers

When the client sends a request, the client assigns a session ID to the client and passes the client the join session ID indicating the identity issue subscribe and the listen request. The server side maintains a subscription's topic collection, event queues for each session.

The server-side event source sends the newly generated events to the event queue for each session (i.e. subscribers) in a multicast manner.

Summary

This article describes how to choose the right solution based on the existing technology to develop a "server push" application, the best solution depends on the application needs themselves. The current development of COMET applications is challenging compared to traditional Web applications.

"Server Push" has a wide range of application needs, in order to make Comet model suitable for large-scale commercial applications, and user-friendly to build comet applications, in recent years, both server and browser have appeared a lot of new technologies, but also a lot of open-source Comet framework, protocol. As demand drives technology, it is believed that Comet's application will become as popular as AJAX.

"Go" Comet: "Server Push" technology based on HTTP long connections