Server push technology based on HTTP persistent connection

August 31, 2007

Many applications, such as monitoring, instant messaging, and instant quotation systems, need to send changes in the background to the client in real time without the need for the client to refresh and send requests continuously. This article first introduces and compares common "server push" Solutions, focuses on the two "server push" Solutions of comet-using HTTP persistent connections and without the need to install plug-ins in browsers: ajax-based long polling mode; IFRAME-based and htmlfile-based stream mode. Finally, I analyzed some issues that need to be paid attention to when developing a comet application, and how to use the open-source comet framework-pushlet to build my own "server push" application.

Application of "server push" Technology

Visit the Ajax technical resource center, an all-in-one center for Ajax programming model information, including many documents, tutorials, forums, blogs, wikis, and news. Any new Ajax information can be found here. Ajax subscriptionArticleAnd the RSS feed of the tutorial

Traditional web systems work in the form of client requests and server responses. This method cannot meet the needs of many practical applications, such:

• Monitoring System: Background hardware hot swapping, led, temperature, and voltage changes;
• Instant Messaging System: other users log on and send messages;
• Instant quotation system: the background database content changes;

These applications require the server to transmit updated information to the client in real time without sending a request from the client. "Server push" technology has some solutions in practical applications. This article divides these solutions into two categories: one is to install plug-ins on the browser side and transmit information based on the set interface, or remote calling using RMI and CORBA, while the other type does not require the browser to install any plug-ins and is based on HTTP persistent connections.

Apply "server push" to the WebProgramThe first consideration is how to receive and process information on browsers with limited functions:

1. Whether a set of interfaces or remote calls are required for the client to receive and process information. The client presents the HTML page, Java Applet, or flash window to the user. If you use the set interface and remote call, how to modify the HTML display with JavaScript.
2. The format of the information used for communication between the client and the server, and the error handling mechanism.
3. Whether the client needs to support different types of browsers, such as IE and Firefox, and whether to support both Windows and Linux platforms.

Back to Top

"Server push" technology based on client interface Sets

Flash xmlsocket

If the web application user accepts that the application can run normally only when the flash player is installed, using the flash xmlsocket is also a feasible solution.

The basis of this solution is:

1. Flash provides the xmlsocket class.
2. Close Combination of JavaScript and FLASH: In JavaScript, you can directly call the interfaces provided by the Flash program.

Implementation Method: embed a Flash program using the xmlsocket class in the HTML page. Javascript calls the set interface provided by the Flash program to communicate with the set interface of the server. After receiving information transmitted by the server in XML format, JavaScript can easily control the display of HTML page content.

For how to build a Flash program that serves as a bridge between JavaScript and flash xmlsocket, and how to call the flash interface in Javascript, see aflax (asynchronous flash and XML) the socket demo and socketjs provided by the project (see resource reference ).

The close combination of JavaScript and flash greatly enhances the processing capability of the client. From Flash Player v7.0.19, The xmlsocket port must be greater than 1023. The Linux platform also supports the flash xmlsocket solution. However, this solution has the following Disadvantages:

1. The Flash Player must be installed on the client;
2. Because xmlsocket does not have the HTTP tunnel function, the xmlsocket class cannot automatically pass through the firewall;
3. Because an interface is used, you need to set a communication port. Firewall and proxy servers may also restrict non-HTTP Channel ports;

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

Java Applet set Interface

Use the Java Applet on the clientJava.net. SocketOrJava.net. datagramsocketOrJava.net. multicastsocketEstablish an interface connection with the server to push the server ".

The biggest disadvantage of this solution is that the Java Applet cannot update the HTML page content through javascript after receiving the information returned by the server.

Back to Top

Server push technology based on HTTP persistent connection

About comet

As the front-end of Web applications, browsers have limited processing capabilities. Browser development requires upgrading the client software. Due to the diversity of client browser software, it also affects the promotion of new browser technologies. In Web applications, the main task of a browser is to send a request and parse the information returned by the server in different styles. Ajax is the result of the development of browser technology. By sending asynchronous requests on the browser side, the responsiveness of single-user operations is improved. However, web is essentially a multi-user system. For any user, the server can be considered another user. The development of existing Ajax technology cannot solve the problem of transmitting updated information to the client in real time in a multi-user web application, so that users may perform operations under "obsolete" information. The Application of Ajax makes it possible to update background data more frequently.

Figure 1. Comparison between traditional Web Application Models and Ajax-based models
 

"Server push" is a technology that exists for a long time. In the past, it mainly used client interfaces or remote calls on the server. Because browser technology is developing slowly, it does not provide good support for the implementation of server push, in pure browser applications, it is difficult to have a perfect solution to implement "server push" and use it for commercial applications. In recent years, the popularity of Ajax technology and the embedded IFRAME in the ActiveX component of "htmlfile" can solve the problem of loading and displaying ie. Some popular applications such as Meebo, gmail and Gtalk use these new technologies in implementation. At the same time, "server push" has many requirements in real applications. For these reasons, the pure browser-based "server push" technology has attracted a lot of attention, Alex Russell (the dojo toolkit project lead) the "server push" Technology Based on HTTP persistent connections does not require plug-ins to be installed on browsers is "Comet ". Some mature comet applications and various open-source frameworks have emerged. Some Web servers such as jetty are also making many improvements to support a large number of concurrent persistent connections. For the latest development of comet technology, refer to the Wiki about comet.

The following describes the implementation models of the two comet applications.

Ajax-based long-Polling (long-polling)

As shown in figure 1, the emergence of Ajax allows JavaScript to call the XMLHTTPRequest object to send an HTTP request. The javascript Response Processing Function updates the display of the HTML page based on the information returned by the server. The difference between implementing "server push" using Ajax and traditional Ajax applications is:

1. The server blocks requests until data transmission or timeout occurs.
2. After processing the information returned by the server, the client's JavaScript Response Processing Function sends a request again and establishes a new connection.
3. When the client processes received data and re-establishes a connection, new data may arrive at the server. The information will be saved by the server until the client re-establishes the connection, the client will retrieve all the information on the current server at a time.

Figure 2. server push model based on long polling
 

Some applications and examples such as "Meebo" and "pushlet chat" all adopt this long polling method. Compared with poll, this long polling method can also be called pull ). This method is based on Ajax and has the following advantages: asynchronous request sending; no plug-in installation required; both IE and Mozilla Firefox support Ajax.

In this long polling mode, the client calls the callback function when the readystate of XMLHttpRequest is 4 (that is, the data transmission ends) for information processing. When readystate is 4, the data transmission is complete and the connection is closed. Mozilla Firefox provides streaming Ajax support, that is, when the readystate is 3 (data is still being transmitted), the client can read data without closing the connection, to read the information returned by the processing server. When the readystate is 3, ie cannot read the data returned by the server. Currently, ie does not support streaming Ajax.

Streaming Based on IFRAME and htmlfile

IFRAME is an early HTML Tag. By embedding a hidden frame in an HTML page, you can set the src attribute of the hidden frame to a persistent connection request, the server can continuously input data to the client.

Figure 3. Stream-based server push Model
 

The Ajax solution mentioned above is to process the data retrieved from the server by XMLHttpRequest in Javascript, and then javascript can easily control the display of HTML pages. The same idea is used on the client of the IFRAME solution. The IFRAME server does not return the data directly displayed on the page, but returns the call to the client's JavaScript function, as shown in"<SCRIPT type = "text/JavaScript"> js_func ("data from server") </SCRIPT>". The server transmits the returned data as parameters of the client's JavaScript function. The JavaScript engine of the client browser will executeCode.

As shown in figure 3, the connection will not be closed for each data transfer, and the connection will only be closed in case of communication errors or connection reconstruction (Some firewalls are often set to discard too long connections, you can set a timeout time on the server to notify the client to re-establish the connection and close the original connection after the timeout ).

Using IFRAME to request a persistent connection has an obvious deficiency: The progress bar at the bottom of IE and morzilla Firefox will show that the loading is not completed, and the icons above IE will keep turning, loading in progress. Google's talents used an ActiveX called "htmlfile" to solve the problem of loading and displaying in IE, and used this method in Gmail + Gtalk products. Alex RUSSELL: "What else is burried down in the depth's of Google's amazing JavaScript ?" This method is introduced in the article. The comet-iframe.tar.gz provided by the Zeitoun website encapsulates a javascript comet object based on IFRAME and htmlfile. It supports IE and Mozilla Firefox browsers and can be used as a reference. (See reference resources)

Back to Top

Use the comet model to develop your own applications

The above describes two "server push" architectures based on HTTP persistent connections, and more about the client's technology for handling persistent connections. For a practical application, the stability and performance of the system are very important. Using HTTP persistent connections in practical applications requires many details.

Do not use more than two HTTP persistent connections on the same client.

We can use IE to download files in this way. to download files from the same web server, we can only download two files simultaneously. The download of the third object will be blocked until the previous download is complete. This is because the HTTP 1.1 specification stipulates that the client should not establish more than two HTTP connections with the server, and the new connections will be blocked. IE strictly abides by this provision in its implementation.

HTTP 1.1's restrictions on two persistent connections bring the following phenomena to Web applications that use persistent connections: if the client opens more than two IE Windows to access the same web server with persistent connection, the HTTP request of the third ie window is blocked by the persistent connection of the first two windows.

Therefore, when developing a persistent connection application, you must note that when multiple frames are used, do not create an HTTP persistent connection for each frame page, in this way, other HTTP requests will be blocked. In terms of design, update of multiple frames will share a persistent connection.

Server performance and scalability

Generally, a Web server creates a thread for each connection. If comet is used in large commercial applications, the server needs to maintain a large number of concurrent persistent connections. In this case, the server must consider the Server Load balancer and cluster technologies, or make some improvements for persistent connections on the server.

The development of applications and technologies always brings new demands, so as to promote the development of new technologies. There is a big difference between the HTTP 1.1 and 1.0 specifications: In the 1.0 standard, the server will close the interface connection after processing each get/POST request; in the 1.1 Standard, the server will keep the connection. During the interval between processing two requests, the connection is idle. Java 1.4 introduces Java. Nio packages that support asynchronous Io. When the connection is idle, the thread resources allocated for the connection will be returned to the thread pool for use by new connections. When a customer in the idle connection sends a new request, A thread resource is allocated from the thread pool to process the request. This technology is very effective in scenarios with a high chance of idle connections and a large number of concurrent connections.

However, Ajax applications make requests frequently, while comet occupies a connection for a long time. The above server model will become very inefficient in the new application background, A limited number of threads in the thread pool may even block new connections. Jetty 6 Web servers have made many innovative improvements to the characteristics of Ajax and comet applications. For more information, see the document "ajax, comet and Jetty" (see resource reference ).

Control information and data information use different HTTP connections

When using persistent connections, there is a very common scenario: the client web page needs to be closed, and the server side is still blocked from reading data. The client needs to notify the server side to close the data connection in time. After receiving the close request, the server first needs to wake up from the blocking status of the read data, then release the resources allocated to the client, and then close the connection.

Therefore, in design, we need to make the client control request and Data Request use different HTTP connections so that the control request will not be blocked.

In terms of implementation, if it is a persistent connection based on the IFRAME stream mode, two IFRAME and one control frame must be used on the client page to send control requests to the server, and the control request can quickly receive a response, it will not be blocked. One is a display frame, which is used to send persistent connection requests to the server. If the Ajax-based long polling method is used, the client can send an XMLHttpRequest request asynchronously to notify the server to close the data connection.

Keep heartbeat information between the customer and the server

Maintaining a persistent connection between the browser and the server brings some uncertainty to communication: because data transmission is random, the client does not know when the server will transmit data. When the client no longer works, the server needs to release the resources allocated to the client to prevent memory leakage. Therefore, we need a mechanism for both parties to know that everyone is running normally. Implementation:

1. The server sets a time limit when blocking reading. After the timeout, the blocked reading call will return the heartbeat information sent to the client without new data arriving. If the client is closed, an exception occurs when the server writes data to the channel, and the server releases the resources allocated to the client in time.
2. If the client uses the Ajax-based long polling method, after the server returns data and closes the connection, the client does not receive the next request after a certain time limit, and the client cannot work normally, resources allocated and maintained for the client will be released.
3. When an exception occurs in server processing information, you must send an error message to notify the client, release resources, and close the connection.

Pushlet-open-source comet framework

Pushlet is an open-source comet framework. It has a lot to learn from in terms of design and has great reference value for developing lightweight comet applications.

Observer Model

Pushlet uses the observer model: the client sends a request and subscribes to events of interest. The server assigns a session ID for each client as a tag, the event SOURCE sends new events to the subscriber's event queue in multicast mode.

Client JavaScript Library

Pushlet provides Ajax-based JavaScript library files for "server push" in long polling mode, and IFRAME-based JavaScript library files for "server push" in stream mode ".

The javascript library has done 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 allocated by the server. The session ID is attached to each request after the connection is established to indicate the identity;
3. ProvidedJoin (),Leave (),Subscribe (),Unsubsribe (),Listen ()And other APIs for page calls;
4. Provides JavaScript function interfaces for response processing.Ondata (),Onevent ()...

Web pages can easily use the APIS encapsulated by these two JavaScript library files to communicate with the server.

Format of client-server communication information

Pushlet defines a set of information formats for communication between customers and servers, in XML format. Defines the types of requests sent by the client:Join,Leave,Subscribe,Unsubscribe,Listen,RefreshAnd RESPONSE event type:Data,Join_ack,Listen_ack,Refresh,Heartbeat,Error,Abort,Subscribe_ack,Unsubscribe_ack.

Server-side event queue management

Pushlet is implemented using Java Servlet on the server side. Its data structure design framework can still be applied to backend clients written in PHP and C.

Pushlet allows the client to select the stream, pull (long polling), and polling modes. The server performs different processing when reading the event queue (fetchevents) according to the method selected by the customer. In "polling" ModeFetchevents ()Will return immediately ." Stream "and" pull "modes use the blocking mode to read events. If it times out, it will send a" Heartbeat "event to the client, if it is in" pull "mode, the "Heartbeat" and "refresh" events are sent to the client together, notifying the client to send a new request and establish a connection.

Session management between customer servers

The server sends messages on the client.JoinWhen a request is sent, a session ID is assigned to the client and sent to the client. Then, the client sends a session IDSubscribeAndListenRequest. The server maintains a subscribed topic set and event queue for each session.

The event source on the server sends the newly generated events to the event queue of each session (that is, the subscriber) in multicast mode.

Back to Top

Summary

This article describes how to select an appropriate solution based on existing technologies to develop a "server push" application. The optimal solution depends on the application requirements. Compared with traditional Web applications, developing comet applications is still challenging.

"server pushing" has a wide range of application requirements. In order to make the comet model suitable for large-scale commercial applications and facilitate the construction of comet applications, in recent years, many new technologies have emerged in both servers and browsers, as well as many open-source comet frameworks and protocols. Demands promote the development of technology, and I believe that the application of comet will become as popular as Ajax.