Http connection persistence

The Http environment itself is a connectionless architecture. In this architecture, the server can only passively accept client requests and return results, but cannot actively send data to the client. In many scenarios that require real-time data interaction (such as Web IM), we hope to get the data that the server returns to us in a timely manner. In this case, the most common practice is to use a timer on the client to regularly request the server's services to obtain the latest data. In this way, it is often useless, and frequent requests will also increase the consumption of servers and clients in requesting Web services without any reason. Is there a better way to get the server's return in a timely manner, while reducing useless work and performance problems caused by frequent requests?

I remember a recent article in the garden that introduced the mechanisms for regularly refreshing data in several WEB environments. Some of them mentioned google gmail's clever practice. Now I can't remember how I understood it. I only remember the basic practice of "keeping persistent connections. (Of course, this article cannot be found now. If you want to know it, please remind me ). Today, due to the need of the Architecture Scheme, let's take a closer look at the connection persistence scheme and refer to the gmail request behavior. We have concluded that the client has always maintained a connection with the server, this connection keeps sending requests to the server until the server returns the data. After receiving the returned request, the client sends a connection request to the server before processing the returned data until the next data is returned. Inevitably, if the server does not need to send data to the client for a long time, the request may fail (timeout or other reasons ). The same is true for this case. In the error callback event, send a request connection again. In this way, you can simulate the connection status.

Use pseudocode to describe the idea:

Client script:

   1: function Request()

   2: {

   3:     Ajax.Request(url,OnSuccessed,OnFailed);

   4: }

   5: function OnSuccessed(response)

   6: {

7: // resend a request

   8:     Request();

9: // process the returned data

  10: }

  11: function OnFailed()

  12: {

13: // error (timeout) re-Request

  14:     Request();

  15: }

Web Services:

   1: public class IMService : IHttpHandler

   2: {

   3:     public bool IsReusable{return false;}

   4:     public void ProcessRequest(HttpContext context)

   5:     {

6: // read the latest data

   7:         while(true)

   8:         {

   9:             string message = GetMessage();

  10:             if(!string.IsNullOrEmpty(message))

  11:             {

  12:                 context.Response.Write(message);

  13:                 break;

  14:             }

15: Thread. Sleep (500); // wait for a while before re-reading.

  16:         }

  17:     }

  18:     private string GetMessage()

  19:     {

20: // get the latest data

  21:     }

  22: }

The benefits of this solution are: the client can obtain the data that the server needs to send to the client at the first time (as for how the Web service knows how to send data to the client, that is, the server's round robin design, it is another solution that needs to be considered). It can reduce the client logic, without the need to create and release the timer, and reduce the resulting loss on the client performance; reduce the number of requests to the server, reduce useless work, save bandwidth, and reduce connection requests that need to be processed by server resources.

I believe that many people have used this solution before. You are welcome to express your opinions on this solution.

Supplement: In addition to Round Robin, you can also consider using mutually exclusive access to resources. In this way, you can achieve better performance and timeliness, the specific plan should be considered based on the actual situation.