Use. Net to implement Ajax persistent connections (part 1-Comet Web Service)

Ajax persistent connections, or some people refer to comet, are used to connect to the server in XMLHttpRequest mode. After the connection, the server does not instantly write the corresponding data and return the data. The server will keep the connection and wait for an event to notify the client. After the event occurs, the data will be written to the response immediately. At this time, the client will receive the event notification in a fairly "real-time" manner. For details about the communication model, refer to this article.Article: Comet: "server push" Technology Based on HTTP persistent connections, which has already been very detailed, so I will not repeat it again.

We will discuss how to use. Net to implement this model. First, we can think of a Web service, which can be ASP. NET web service, WCF web service, and ASP. NET Ajax library. Here, for the sake of simplicity, We will select an example of ASP. NET web service that you are more familiar. Then, we will write down the following two function signatures:

Public void send (message );
Public message wait ();

The send function is used to send a message object, while the wait function is used to wait for a message object. Then let's discuss some details.

Timeout caused by no event

First, it will not work if you keep the connection for a long time. This is not a problem for servers and clients, but we should always remember that there may be various gateways and proxies with weird configurations, which may have various timeout rules, therefore, it is recommended that comet be designed for regular reconnection. Generally, if no event occurs within 30 seconds, the server should notify the client that no event has occurred, end the request, and start a new request to continue waiting.

Can the above function signature be used to return an event-free message? This is obviously acceptable. We can choose to return NULL to indicate no event, or return a emptymessage constant, depending on whether we use class or struct to define message. (Even we can create a message derived class named nomessagemessage To Do This .)

Define Sending target

The above function signature can indeed be used for sending and receiving messages, but it does not indicate who to send messages. It may be said that the sender can be defined by an attribute in the message class. However, the wait () method does not indicate who the receiver is, and the server still does not know which messages should be received by you.

Therefore, we introduce the concept of channel, which is identified by its name. The same channel must have the same name. When sending and receiving data, specify the channel to which the data is sent by using the name. This solves the problem. Modify the function signature as follows:

Public void send (string channelname, message );
Public message wait (string channelname );

Reliable Message Queue

Imagine a possible situation where the server sends a message to you. If you fail to receive the message, the server determines that the message is successfully sent and the message is deleted from the queue, then the message is lost permanently. Some people may emphasize how reliable TCP is. If a message sent by the server has a problem at the TCP level, it will certainly cause a socket-level exception, which is bubbling up, the server can intercept the message, so that the message fails to be sent, and the first message of the queue is not deleted first. But don't forget that there may be a proxy in the middle. If the proxy successfully removes the message, but the proxy fails to send the message to the client, the server may not have an exception.

Therefore, we need to develop a policy to ensure that downstream messages are always sent to the client. Here, we chose to introduce an ack-by-one mechanism to confirm message receipt. That is to say, the message sent from the server to the client carries a serial number. After the client receives the message, it sends the serial number back to the server, and it has been confirmed that it has received the message. At this time, the function signature is changed as follows:

Public int send (string channelname, message );
Public message wait (string channelname, int sequence );

In the message we receive using wait (), there should be a sequence attribute, marking its serial number. Then, when we execute the next wait () operation, we will pass the value of the serial number plus 1 back through the sequence parameter to let the server know that the number of the next message we expect is this. For example, if we receive a message whose sequence attribute is 836, it will be sent to server 837 when wait () is called next time. At this time, the server should keep the message No. 836 at the beginning of the pair. If the client continues to request message No. 836, it proves that it did not receive the message last time, and this time it still sends the message No. 836 to it; if the client requests Message No. 837 to prove that it has successfully received message No. 836, this time it will send message No. 837 to it.

If not, what should I do? This means that this is a wrong request, or even an attack request, because such a request should not appear normally, the server may consider throwing an insignificant exception (do not tell the attacker that he is under attack), or even directly sending a 400 (Bad request) response code.

Similar to wait (), send () can also be added to the ACK mechanism. You only need to change the return type from void to int. This value is used to transmit message numbers, the implementation method is the same as that of wait (), but send () is the queue in which the client saves the messages to be sent.

Summary

So far. Our web service is ready. Is this all written? Only the signature does not have a function body? Yes, the complex work is left for the model. Here, the Web Service is equivalent to a view, which is used to expose the model interface.