[Reprinted] http push technology principle, combined with ASP. NET implementation and comment

Http push technology principle, combined with ASP. NET implementation and comment Favorites

Original article: http://blog.csdn.net/banmuhuangci/archive/2008/09/20/2955719.aspx

 

Some time ago, I saw some people writing about the http push principle. I didn't care about it at the beginning. Because of the inherent problem of HTTP, it is impossible for the WEB server to actively PUSH because the connection is closed after the HTTP response, the WEB server cannot trigger any more events before pushing information to a client browser.

Recently, when I was at home, I suddenly remembered this. Although I felt that this was not an orthodox PUSH technology, it was already used by some people and the effect was not bad. I 'd better try it myself. After a small attempt, I found that HTTP PUSH is actually a very simple principle, but the effect is indeed good, but it also has some problems to solve.

Without talking nonsense, Tang gave birth to a paragraph before and entered the subject.

 

First, I will elaborate on the principle of HTTP PUSH. As we all know, HTTP is stateless. After the browser REUQEST, the WEB server processes the result and then RESPONSE the result to the browser. After the REUQEST, the connection is closed. Before and after a request, the WEB server and the browser are irrelevant. Therefore, when chatting rooms and other applications that need to constantly obtain new data from the server, they all use requests from the server. Of course, the emergence of AJAX makes the user experience go straight up, but it still keeps sending requests, but the user does not know. In this case, how do I PUSH the WEB server? Theme! Each request is independent and stateless. However, if data is constantly updated, it is actually a request? In general, from REQUEST to RESPONSE, the WEB server only sends results after a series of events. The time is relatively short. At the same time, in the REQUEST to RESPONSE process, the browser and the server are linked. Yes, this is a breakthrough. We can use an abnormal method to extend the REQUEST-to-RESPONSE time to obtain the link status during this time period, let the server do something during this time and immediately send the results in progress instead of waiting for the results to be sent after they are all completed.

For example, if a person goes to the post office to pick up a mail, the post office will not take the initiative to send the mail to the home. Once every hour, after arriving at the post office, he will ask the staff whether they have his letter or not, then I will ask again in the next hour. This is the usual method for WEB chat. the browser regularly sends a REQUEST and then obtains the RESPONSE to end. Now let's change our approach. This person does not go to the post office every hour, but has made a place and slept in the post office for a long time. He told the post office staff to give it to him whenever they have a letter, he immediately asked the postman to put the email in his home mailbox. At this time, his wife sitting at home would feel that the Post Office is now sending the email to his home. That's all.

 

The following is a small example implemented using ASP. NET, which is relatively simple.

 

First, you must create two pages. One is to update information and update information of a public area on the server. A page will use the PUSH method to receive information. When the information in the public area on the server changes, the server immediately responds and sends the information to the page. In this example, the ASPX page does not require any client script, so the code on the front-end page is not pasted.

 

The following code is used:

 

Sender:

Protected void Page_Load (object sender, EventArgs e)
{

Application ["msg"] + = "new date:" + DateTime. Now. ToString () + "<br> ";

Response. Write (Application ["msg"]);
}

 

To easily refresh the page to update data, you can use a BUTTON.

 

Acceptor:

 

Protected void Page_Load (object sender, EventArgs e)
{

Response. Buffer = true;

If (Page. IsPostBack)
{

While (Response. IsClientConnected)
{

System. Threading. Thread. Sleep (1000 );

If (Application ["msg"]! = Session ["Current"])
{
Session ["Current"] = Application ["msg"];
Response. Write (Session ["Current"]. ToString ());
Response. Flush ();

}
Else
{
Response. Write (".");
Response. Flush ();
}
}
 
}
Else
{
Session ["Current"] = "";

Response. Write ("Do on Request! <Br> ");
}

}

 

We also need to add a button to ASPX. After the page is loaded for the first time, click the button to make 2nd requests, and 2nd requests will become long requests.

 

 

The code below shows that there is nothing to say about updating the information page. I use APPLICATION for convenience. Of course, I can also use Database XML for convenience.

 

Let's talk about the claim page. First, we will. buffer is set to true, so that we can safely control the Response data is retained in the memory when we disagree. isPostBack indicates that the request is sent for 2nd times, that is, the request must be executed for a while loop. The condition is Response. isClientConnect was established, that is, when the user did not exit the page or stop the request, it always loops. What is the loop? Cyclically check whether the information in the current user's Session is the same as that in the Application global variable. If the information is the same, it indicates that no new information is updated and an ". "(for convenience of testing, nothing can be done). When the information is different, it indicates that there is an update, therefore, we copy the content in the Application to the Session and output the Session immediately. OK. Let's test it. In two windows, one is loading the Update page, the other is loading the receiving page, and the other is clicking the receive page button to start executing the request, at this time, the receipt should also be blank. Then we click the Update page, and a new line of time for us to execute the request appears on the page, and then switch to the receiving page, YEAH, the receiving page immediately displays this time. This is a very important thing to mention, Response. the Flush () method is not often used, but is very useful. It does not need to wait for the request to complete and immediately output the results in the memory to the browser. This is a very important part of PUSH, because the request is required to wait for a long time, it is impossible to send data after the request is completed. Therefore, FLUSH should be used to send the data immediately, this is the postman that the man invited. Another important thing is System. Threading. Thread. Sleep (1000). Here I set up no loop to let the current Thread rest for one second. Why? In fact, when using the while clause, the user will not be able to complete without leaving this request, and will be waiting for the Thread. sleep is not used to control the time, but to ensure the CPU usage. If you run this statement, you will find that your CPU is always 100%. Too frequent checks and updates consume a lot of server resources, therefore, we should give a pause. The Post Office also believes that the guy should not let people get tired.

 

In this way, a long request, that is, a small example of pushing information on the WEB server, is ready. Of course, this example is not perfect, but it is intuitive to understand the working principle.

 

However, this method will block the thread and we will find that the request thread has been suspended all the time, so the user of the same session cannot request other resources of this server any more, because the request thread server of the same session user will let you wait for the previous thread to complete and then execute it, And the thread will be set to not complete or can be completed for a long time, this is like the man's wife wants her husband to help him buy dinner dishes, but his husband cannot return at the post office. Maybe someone may want to create a new thread to do the waiting thing or the new thing. Isn't that all right? The problem is that the man is also needed to hire a nanny ..........

 

So far, this example does not solve the problem of blocking threads, the method I can think of is to separate the blocked thread from other request threads from the server in the same session or not in the same request. This is why we need to open two windows when testing this example.

 

Now, I understand the Principles and Examples of HTTP PUSH. In the future, HTTPPUSH may be well improved, maybe now. It is important to learn more and think more. Finally, let's add a legend to give you a more intuitive understanding of http push.

 

 

General situation: browser REQUEST-> server processing-> Server RESPONSE to Browser

 

Long request push: browser REQUEST-> server processing <============> Server RESPONSE to browser ------> final