The client implements the result of using a common poll, which is relatively simple. The advantage of using setinterval uninterrupted refresh to get the resources of the server is simple and timely. The disadvantage is that the links are mostly invalid duplicates; The result of the response is not sequential (because it is an asynchronous request, and the subsequent request is sent when the request is sent without returning the result.) At this point, if the subsequent request is more than the previous request to return results, then when the previous request returned result data is already obsolete invalid data, the request is more difficult to maintain, waste server and network resources.
Server-side code
@RequestMapping ("/ajax")
public void Ajax (long timed, httpservletresponse response) throws Exception {
PrintWriter writer = Response.getwriter ();
Random rand = new Random ();
Dead loop query with no data changes
while (true) {
Thread.Sleep (300); Sleeps 300 milliseconds, simulates processing business, etc.
int i = rand.nextint (100); Generate a random number between 0-100
if (i > && i < 56) {//If the random number is treated as valid data between 20-56, the analog data is changed
Long responsetime = System.currenttimemillis ();
Returns data information, request time, return data time,
Writer.print ("Result:" + i + ", Response time:" + ResponseTime + ", Request time:" + timed + ", use time:" + (response time-timed));
Break Jump out of the loop, return data
} else {//simulate no data changes, put sleep hold connection
Thread.Sleep (1300);
}
}
}
Server-side implementation, here to simulate the changes in the program monitoring data. The above code belongs to a method in the controller in Springmvc, which is equivalent to a Dopost/doget method in the servlet. If no program environment adapts to the servlet, copy the code from the method body into the doget/dopost of the servlet.
The server side in the long-connection programming, should pay attention to the following points:
1. The controllability of the server program to polling
Since polling is implemented in the form of a dead loop, it is necessary to ensure that the program has complete control over when to exit the loop, and avoids running out of server resources in a dead loop.
2. Select the "Heartbeat" frequency reasonably
As can be seen from Figure 1, the long connection must be maintained by the client constantly request, so the client and the server to maintain a normal "heartbeat" to be critical, the parameter polling_life should be less than the Web server time-out, generally recommended in about 10-20 seconds.
3. Impact of network factors
In the actual application, from the server to answer, to the establishment of the next cycle, there is a time delay, the length of the delay is affected by a variety of factors such as network transmission, in this period of time, the long connection is temporarily disconnected in the empty file, if there is data in this period of time changes, the server can not immediately push, so, The problem of data loss due to delay may be addressed in the design of the algorithm.
4. Performance of the server
In a long-connected application, the server maintains a persistent connection to each client instance, which consumes a lot of server resources, especially in some large applications, where a large number of concurrent long connections can cause new requests to be blocked or even crash, so In the process of programming, special attention should be paid to the optimization and improvement of the algorithm, as well as server load balancing and cluster technology when necessary.
Is the result of the return, you can see that the request was made first, not necessarily the result first. This does not guarantee the order, resulting in dirty data or useless connection requests. Visible waste of resources on the server or network.