Generally speaking, web-side instant messaging technology is not easy to implement due to the design limitations of browsers. There are roughly four mainstream web-side instant messaging solutions: traditional Ajax short polling, Comet technology, and WebSocket technology. , SSE (Server-sent Events).
This article will introduce how to choose a suitable solution to develop a "server push" (Comet technology) application based on the existing technology. The optimal solution still depends on the application requirements themselves. Compared with traditional Web applications, the development of Comet applications has certain challenges.
Before the WebSocket technology completely solves the browser compatibility problem, there is a wide range of application requirements for "server push" (Comet technology), and the demand promotes the development of the technology. Comet technology is almost indispensable in the solution of instant messaging on the Web side.
Application Scope of "Server Push" (Comet Technology)
The traditional mode Web system works in the way that the client makes a request and the server responds. This method does not meet the needs of many real-world applications, such as:
Monitoring system: background hardware hot swap, LED, temperature, voltage changes;
instant messaging system: other users log in and send information;
instant quotation system: background database content changes.
These applications all require that the server can transmit updated information to the client in real time without the client making a request. There are some solutions for "server push" technology in real applications. This paper divides these solutions into two categories: one requires installing plug-ins on the browser side, transmitting information based on sockets, or using RMI and CORBA to make remote calls; The other type does not require the browser to install any plug-ins and is based on HTTP long connections.
When applying "server push" to a web program, the first consideration is how to receive and process information on the browser with limited functions:
How the client receives and processes information, whether it needs to use sockets or use remote calls. Whether the client presents to the user an HTML page or a Java applet or Flash window. If you use sockets and remote calls, how to modify the display of HTML in combination with JavaScript.
The information format of the communication between the client and the server, and what kind of error handling mechanism is adopted.
Whether the client needs to support different types of browsers such as IE and Firefox, and whether it needs to support both Windows and Linux platforms.
Flash XMLSocket
If the users of the Web application accept that the application can only run properly if the Flash player is installed, then using Flash's XMLSocket is also a feasible solution. Instant messaging chat software app development can add Weikeyun's v:weikeyyun24 consultation
The basis for this implementation is:
Flash provides the XMLSocket class.
The close integration of JavaScript and Flash: JavaScript can directly call the interface provided by the Flash program.
Specific implementation method: Embed a Flash program using XMLSocket class in the HTML page. JavaScript communicates with the server-side socket by calling the socket interface provided by this Flash program. JavaScript can easily control the content display of HTML pages after receiving the information sent by the server in XML format.
For how to build a Flash program that acts as a bridge between JavaScript and Flash XMLSocket, and how to call the interface provided by Flash in JavaScript, we can refer to the Socket Demo and SocketJS provided by the AFLAX (Asynchronous Flash and XML) project (see Resources).
The close combination of Javascript and Flash greatly enhances the processing capability of the client. Beginning with Flash Player V7.0.19, the restriction that the port of XMLSocket must be greater than 1023 has been removed. The Linux platform also supports the Flash XMLSocket scheme. But the disadvantages of this scheme are:
The client must install the Flash player;
because XMLSocket has no HTTP tunnel function, the XMLSocket class cannot automatically pass through the firewall;
because the socket is used, a communication port needs to be set, and the firewall and proxy server may also restrict the non-HTTP channel port.
However, this scheme has been widely used in some online chat rooms and online interactive games.
Java Applet Socket
Use Java Applet on the client side to establish a socket connection with the server side through java.net.Socket or java.net.DatagramSocket or java.net.MulticastSocket, so as to realize "server push".
The biggest disadvantage of this scheme is that the Java applet cannot update the content of the HTML page through JavaScript after receiving the information returned by the server.
About Comet
As the foreground of Web applications, browsers have limited processing capabilities. The development of the browser requires the client to upgrade the software, and at the same time, due to the diversity of the client browser software, in a sense, it also affects the promotion of new browser technologies. In a web application, the main job of the browser is to send requests and parse the information returned by the server to display them in different styles. 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 to any user, the server can be thought of as another user. The development of the existing AJAX technology cannot solve the problem of transmitting the updated information to the client in real time in a multi-user Web application, so that the user may operate under the "outdated" information. The application of AJAX makes it possible to update the background data more frequently.
"Server push" is a technology that has existed for a long time. In the past, it was mainly implemented through client sockets or remote calls on the server side. Because the development of browser technology is relatively slow, and there is no good support for the implementation of "server push", it is difficult to have a complete solution to realize "server push" and use it in commercial programs in pure browser applications. In recent years, because of the popularization of AJAX technology, and embedding IFrame in the ActiveX component of "htmlfile" can solve the loading and display problem of IE, some popular applications such as meebo, gmail+gtalk have used these new technologies in their implementation; At the same time, "server push" does have many demands in real applications. For these reasons, the pure browser-based "server push" technology has begun to receive more attention. Alex Russell (Dojo Toolkit's project Lead) called this "server push" technology based on HTTP long connections and without the need to install plug-ins on the browser side. for "Comet". At present, some mature Comet applications and various open source frameworks have appeared; some Web servers such as Jetty have also made many improvements to support a large number of concurrent long connections.
Comet technology implementation model 2: Streaming method based on Iframe and htmlfile
iframe is a kind of HTML tag that has existed for a long time. By embedding a hidden frame in the HTML page, and then setting the SRC attribute of the hidden frame to a request for a long connection, the server can continuously send the client to the client. terminal input data.
The AJAX solution mentioned in the previous section 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 side of the iframe scheme. The iframe server side does not return the data directly displayed on the page, but 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 a parameter of the client-side JavaScript function; the JavaScript engine of the client-side browser will execute the code when it receives the JavaScript call returned by the server.
As can be seen from Figure 3, the connection will not be closed for each data transfer, and the connection will only be closed when a communication error occurs, or when the connection is re-established (some firewalls are often set to discard long connections, and the server can set a timeout time, notify the client to re-establish the connection after the timeout, and close the original connection).
Using iframe to request a long connection has an obvious disadvantage: the progress bar at the bottom of IE and Morzilla Firefox will show that the loading is not completed, and the icon above IE will keep rotating, indicating that the loading is in progress. The geniuses at Google solved the loading display problem in IE using an ActiveX called "htmlfile" and used this method in the gmail+gtalk product. Alex Russell describes this approach in the article "What else is burried down in the depth's of Google's amazing JavaScript?". The comet-iframe.tar.gz provided by the Zeitoun website encapsulates a JavaScript comet object based on iframe and htmlfile, supports IE, Mozilla Firefox browsers, and can be used as a reference.
Do not use more than two HTTP persistent connections on the same client at the same time
When we use IE to download files, we will have such an experience. When downloading files from the same Web server, at most two files can be downloaded at the same time. The download of the third file will be blocked until the previously downloaded file has been downloaded. This is because the HTTP 1.1 specification stipulates that the client should not establish more than two HTTP connections with the server, and new connections will be blocked. IE strictly abides by this requirement in its implementation.
HTTP 1.1's restriction on two persistent connections will 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 that uses persistent connections, the third The HTTP request of the IE window is blocked by the long connection of the first two windows.
Therefore, when developing applications with long connections, you must pay attention not to establish an HTTP long connection for each frame page in pages that use multiple frames, which will block other HTTP requests. The update of the frame shares a long connection.
Server-side performance and scalability
Generally, a Web server will create a thread for each connection. If Comet is used in large-scale commercial applications, the server side needs to maintain a large number of concurrent long connections. In this application background, the server side needs to consider load balancing and clustering technology; or make some improvements for the long connection on the server side.
The development of applications and technologies always brings new demands, thereby driving the development of new technologies. There is a big difference between HTTP 1.1 and 1.0 specifications: under the 1.0 specification, the server will close the socket connection after processing each Get/Post request; while under the 1.1 specification, the server will maintain this connection, and the interval between processing two requests , the connection is idle. Java 1.4 introduced the java.nio package that supports asynchronous IO. When the connection is idle, the thread resources allocated for this connection will be returned to the thread pool, which can be used by new connections; when the client of the original idle connection sends a new request, a thread resource will be allocated from the thread pool to process this connection. ask. This technique is very effective in reducing the resource load of the server in scenarios where the connection is likely to be idle and the number of concurrent connections is large.
However, the application of AJAX makes requests appear frequently, and Comet will occupy a connection for a long time. The above server model will become very inefficient in the new application background, and the limited number of threads in the thread pool may even block. new connection. Jetty 6 Web server has made many innovative improvements for the characteristics of AJAX and Comet applications, please refer to the article "AJAX, Comet and Jetty".
Use different HTTP connections for control information and data information
When using a long connection, there is a very common scenario: the client web page needs to be closed, and the server is still in a blocked state of reading data. The client needs to notify the server to close the data connection in time. After receiving the close request, the server must first wake up from the blocking state of reading data, then release the resources allocated for the client, and then close the connection.
Therefore, in design, we need to use different HTTP connections for the client's control request and data request, so that the control request will not be blocked.
In terms of implementation, if it is a long connection based on iframe streaming, the client page needs to use two iframes, one is a control frame, which is used to send a control request to the server, and the control request can receive a response quickly and will not be blocked. ; One is a display frame, which is used to send a long connection request to the server. If it is AJAX-based long polling, the client can asynchronously issue an XMLHttpRequest request to notify the server to close the data connection.
Maintain "heartbeat" information between client and server
Maintaining a persistent connection between the browser and the server introduces some uncertainty to the communication: because the data transfer is random, the client does not know when the server has data to transmit. The server side needs to ensure that when the client is no longer working, the resources allocated for the client are released to prevent memory leaks. So there needs to be a mechanism for both parties to know that everyone is functioning properly. On implementation:
The server will set a time limit when blocking the read. After the timeout, the blocking read call will return, and at the same time, it will send a heartbeat message to the client that no new data arrives. At this time, if the client is closed, the server will write data to the channel abnormally, and the server will release the resources allocated for the client in time.
If the client uses the AJAX-based long polling method; after the server returns data and closes the connection, and does not receive another request from the client after a certain period of time, it will think that the client cannot work normally, and will release the allocation for the client , maintenance resources.
When the server processes information abnormally, it needs to send an error message to notify the client, release resources and close the connection at the same time.