Implementation of real-time data push in AJAX applications

This technology can generate a lot of unnecessary traffic and non optimized applications. Fortunately, some rich Internet application (RIA) technology does allow for the opening of a dedicated socket channel, where the backend server provides asynchronous JavaScript and XML (AJAX) applications with access to its APIs and the opportunity to implement server push. This article explores this technique in a variety of ways to help you understand it so that you can begin your own implementation work.

Brief introduction

Ajax technology has been around for some time, and the power of development has really begun to get people's approval. More and more WEB sites are considering using Ajax for design, and developers are beginning to limit their ability to Ajax. With the advent of social networks and collaborative reporting, a new set of requirements emerges. If another user changes any activity that a user is observing, the user wants to be notified. If a Web site displays dynamic data, such as stock prices, then all users must be notified immediately about the change.

These scenarios themselves belong to a class called "Server Push" issues. Typically, the server is a central entity, and the server will first be notified of any changes that have occurred, and the server is responsible for notifying all connected clients of such changes. Unfortunately, HTTP is a standard protocol for client-server communication, which is stateless and, in a sense, a one-way protocol. All traffic in the HTTP scenario must be initiated by the client to the end of the server, but the requirements for the scenario we are referring to are completely the opposite. For server push, it is up to the server to initiate communication and send data to the client. The HTTP protocol is not configured, and WEB site application developers use ingenious methods to circumvent these issues, such as polling, where clients contact the server at fixed (or configurable) intervals to find out whether new updates are available. Most of the time, these polls are pure waste, so the server has no updates. This method is not without cost, it has two main problems.

This approach is extremely wasteful of network resources. Each polling request typically creates a TCP socket connection (unless HTTP 1.1 sets its own keepAlive to true, the socket that was previously created) is used. The socket connection itself is very expensive. In addition, each request transmits some data on the network, and if the request does not find any updates on the server, such data transfer is a waste of resources. If other applications are running on the client machine, these polls reduce the bandwidth available to transmit data.

Even if the request succeeds, the update is actually returned to the client, and the update is not real-time, given the frequency of polling. For example, if the poll is configured to be once every 20 seconds, an update occurs when a request has just returned from the server. The update will not return to the client until the next request arrives in 20 seconds. As a result, the updates that are ready for use by the client on the server must wait for a period of time before they are actually used by the client. Such a wait is not acceptable for applications that need to run in as real-time a way as possible.

Given these two issues, polling is not the ideal approach for enterprise applications that require critical, real-time server-side updates. In this article, I'll introduce a variety of ways to override polling. Each workaround has its own prominence in some scenarios. I'll explain these scenarios and show a set of UI that needs to be pushed by a live server.

Server update technology in AJAX applications

Let's take a look at some of the common techniques used to update information from servers that simulate server push.

Short polling

Short polling, also known as High-frequency polling, is the technique I introduced at the beginning of this article. This approach is best performed in the following situations:

There is sufficient bandwidth available.

Most of the time, according to statistics, requests are updated. For example, stock market data will always have updates available.

Use the HTTP 1.1 protocol. Sets the keepalive=true so that the same socket connection remains active and reusable.

Long polling

Long polling is another way to update server data. The idea of this approach is that the client establishes the connection, the server blocks the connection (by making the request thread wait under certain conditions), the server sends the data over the blocked connection, and then closes the connection. The client will re-establish the connection immediately after receiving the update, and the server will repeat the process to achieve near real-time communication. However, long polling has the following drawbacks:

The General browser defaults to allow two connections per server. In this case, a connection is always busy. As a result, the UI has only one connection (that is, half the capacity) that can be used to provide service to user requests. This may cause performance degradation for some operations.

You still need to turn on and off the HTTP connection, and if you are using a non-persistent connection mode (Keepalive=false), the cost of this approach can be extremely high.

This approach is near real-time, but it's not real real time. (Of course, some external factors are always uncontrollable, such as network latency, and these factors can be found in any method.) ）