Analysis of Asp. Net-based Comet technology, asp. netcomet

Analysis of Asp. Net-based Comet technology, asp. netcomet
Technical Principle of Comet

From Wikipedia: Comet is a web technology that enables the server to transmit updated information to the client in real time without sending requests from the client. Currently, there are two implementation methods, long polling and iframe streams.

In short, it is a long polling technology based on the existing Http protocol, the main reason for this technology is that the Http protocol is stateless, so there is no way to establish a long-term connection between the client and the server. For example, if we want to create a chat room, we usually cannot push messages from the server to the browser in the Web environment. Instead, we can only use each client to continuously poll the server to obtain the latest messages, in this way, the efficiency is very low, and the constant sending of requests to the server will also cause a large amount of resource occupation for applications with large traffic volumes.

As a result, people discovered this technology and initiated a request to the server. Then the server never responded to this request, so that a persistent connection was formed between the client and the server, the connection ends after the server responds to the request. Borrow an image from IBM:

 

The Ajax technology can be used to implement the server push model of long polling. Data interaction can be achieved between the client and the server by continuously initiating long polling, this process is an Asynchronous Operation implemented by Ajax, so the experience is good and the efficiency is high. Sorry, I cannot tell you clearly. Please find an online document:

In general, the Comet method is a persistent connection mechanism (long lived http ). In the same way, the Browser initiates a request, but the Server provides a very slow response. In this way, the server can use the same connection to actively send the data to the Browser during this period. Therefore, the request may wait for a long time, during which no data is returned, but once new data is generated, it will be immediately sent to the client. Comet has many implementation methods, but in general, the Server load will increase. although only one connection is recommended for a unit operation, the resource usage on the server is increased because the connection is maintained for a long time.

Advantages: good real-time performance (low message latency) and good performance (supporting a large number of users)

Disadvantage: the connection is used for a long time and the high concurrency is lost.

Application: Stock System and real-time communication.

References:

Comet: server push technology based on HTTP persistent connections

Technical basis for implementing Comet Based on Asp. Net

Asp. Net itself is a technology born for the web, so it is inherently satisfying. Asynchronous request processing based on Ajax and Asp.net can provide more powerful capabilities for Comet. Here we will launch the IHttpAsyncHandler interface.

• IHttpAsyncHandler interface Introduction

IhttpAsyncHandler inherits from IhttpHandler, but the difference is that IHttpAsyncHandler has the inherent asynchronous ability. He has two more methods than IHttpHandler:

IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData);void EndProcessRequest(IAsyncResult result);

The BeginProcessRequest method returns the IAsyncResult interface. Generally, the BeginProcessRequest method processes some heavy and time-consuming tasks, such as IO operations and reading Web Services. Once the asynchronous operation is complete, you can use the EndProcessRequest method to obtain the asynchronous result.

The advantage of IHttpAsyncHandler is that when it processes asynchronous methods, the request processing thread can be temporarily released, and other requests can be processed idle. After the Asynchronous Method is completed, the following request is processed by the thread.

• Asp. Net Comet

With the technical foundation, let's take a look at how to implement this technology:

On the client side, we need to send requests. In this regard, Ajax technology can be used to implement asynchronous request operations through javascript, which is relatively simple and convenient.

The server listens to a specific request type and implements IhttpAsyncHandler to process the request. The BeginProcessRequest method has an AsyncCallback parameter cb, which is a callback function, in asp.net, if the callback function cb is not called, the request is not responded, that is, the content is not returned to the client, which implements persistent connection. The client will not receive the response packet until the server has data to return to the client, and the server calls the cb function to trigger the execution of the EndProcessRequest method.

After the client receives the data, it can initiate a request to the server. repeat this process to simulate a persistent connection.

AspComet component Introduction

In asp.net, there is an open-source component AspComet that provides a better implementation of Comet. The open-source site for this component is https://github.com/nmosafi/aspcomet.

The core of AspComet is to initiate a request through Ajax. The server processes the request based on IhttpAsyncHandler and processes a complete set of Web push technologies through a message bus. Components are divided into two parts: the server side and the client side, both of which have good scalability. The server side has flexible delegate processing, and you can also use your own inheritance to rewrite the business processing you need, it is very convenient for secondary development. The client also provides good encapsulation and supports a variety of mainstream js script libraries, such as Jquery and dojo. The implementation of these two types of script libraries is provided in the official demo.

After reading the source code of Aspcomet, I still sighed. Although it seems very difficult, I also feel that this Code provides great support for secondary development. Basically, it is object-oriented to implement the entire component. Even JS also applies a lot of design patterns. The following describes the main implementation of this component:

Server  

1. The IhttpAsyncHandler interface must be implemented first.

CometHttpHandler: IhttpAsyncHandler. This class is the processing unit for asynchronous requests. Simply put, it is the endpoint of the server. Here, the BeginProcessRequest method is used to hold the request content and callback. Of course, here we should pay attention to MessageBus. We have to check the hold of all messages, because some messages need to be immediately returned to the client, some are forwarded after being processed by the message bus, and some are left for persistent connections. The details will be explained later when talking about the message bus.

In the end, CometHttpHandler calls the EndProcessRequest method when the request ends, and returns the message to the waiting connection. The client receives and processes the response packet of the request.

CometHttpHandler implements an entry and exit, and implements the persistent connection state through the asynchronous processing capability of IhttpAsyncHandler.

2. message packets

There must be a message packet for the interaction between the client and the server. Otherwise, the two parties cannot make some conventions. After all, the Http protocol is loose and stateless. In AspComet, a class: Message is implemented.

The developer of this kind of AspComet is called bauyeux message (Introduction), which seems to be a set of protocols proposed by Dojo.

In this message packet, we mainly introduce the following:

Channel: the message Channel used for the Channel where the message is broadcast.

ClientId: Client id

Data: data packet (an object type, which is easily used for extended data packets)

Version: version number, which is useful for downstream message compatibility.

Advice: the processing method after the return, which is also called notification.

Timestamp: timestamp

Ext: It seems to be an extension.

The content of packets is rich. Sometimes the protocol is an agreement. In fact, it is a class for us. You can even understand it as a string, the client and the server can parse and identify each other through certain conventions.

3. Message Bus Design

When talking about IhttpAnyscHandler, I mentioned the message bus, which is abstracted as an interface in AspComet: IMessageBus.

public interface IMessageBus{void HandleMessages(Message[] messages, ICometAsyncResult cometAsyncResult);}

 

One method, that is, the core method that AspComet uses to process messages. The method means to process messages, in this method, the received messages are distributed to different message handlers for processing. For example, the messages must be sent to MetaHandshakeHandler for processing when a handshake is initiated. This is a message transfer center.

Parameter messagesIt is a message packet, because it may be multiple messages, so an array is used.

CometAsyncResultIt is a secondary encapsulation of the callback function of an asynchronous request. The main purpose is to connect the callback to prevent it from responding, so that you can control when to return the response package. The ICometAsyncResult interface has two methods.

 

SendAwaitingMessages is used to write the messages to be sent to the sending pipeline.

CompleteRequestWithMessages is used to complete the request process. It mainly involves calling callback to tell IhttpAsyncHandler that the request can be returned.

By combining these two methods, you can send messages to the client.

Here, we mention that the method for sending data to the client is very simple. The Http packet is divided into Request packages and response packages, and the Request sent from the client to the server is called Request ), the Response that the server sends to the client is called Response. You should understand it now. SendAwaitingMessages writes data to Response, so that the client does not receive the data?

4. Processing of various types of messages

I mentioned the message processor in the message bus. Why does this stuff exist? In fact, this is related to the entire communication process, including the handshake process, connection establishment process, and disconnection process. This requires a complete set of processing methods, that is, we need to separate each type of process. In AspComet, there is an interface: ImessageHandler, which defines a unified method for message processing:

 

By inheriting this interface to implement specific message processing classes, you can complete some specific services. The following lists various message processing classes:

MetaHandshakeHandler	Handshake protocol processing
MetaConnectHandler	Connection protocol processing
MetaDisconnectHandler	Disconnect
MetaSubscribeHandler	Subscription Processing
MetaUnsubscribeHandler	Stop subscription Processing
ForwardingHandler	Message forwarding
ExceptionHandler	Exception Message Processing
SwallowHandler	Swallowed up message processing, not returned to the client

You can understand the meaning of message sending and processing.

When it comes to message classification processing, it must be explained that in MessageBus, how can we differentiate the Message Type and find the corresponding processor? This is the credit of ImessagesProcessor.

 

In this interface, the Process method is used to Process the forwarding of each message. This design is also good. We can even implement a MessagesProcessor to completely forward and Process the message as required. Here, let's take a look at the official default implementation. The AspComet component has a default implementation MessagesProcessor. The Code is as follows:

 

In the code, we can see that MessageProcessor obtains the actual ImessageHandler instance through a HandlerFactory, and then processes the message. This process is not complicated. The official implementation is the MessageHandlerFactory class:

 

The processing method here is to call the corresponding handler according to different channels.

When you return to ImessageHandler, You need to describe the delegated design released by AspComet when processing individual messages. When Handler executes the Handlemessage method, it calls the corresponding delegate, external programs can subscribe to the delegate implementation for some processing. For example, I want to verify the client legality during the handshake, but the client legality must be verified by external applications. What should I do? You can use the HandleMessage method in MetaHandshakeHandler to release two delegates for processing. The Code is as follows:

 

In this Code, there are two EventHub. Publish (...) This is Two delegate calls. To verify the client validity, We must process the first delegate. For example, there are two lines of code in the above Code:

This is to call a delegate. The parameter is handshakingEvent. The program that subscribes to this delegate will process the corresponding logic. If it does not meet the requirements, set the Cancel attribute to true, which indicates that the message sending process should be canceled, you can also write the corresponding causes. The following is an example of implementation:

 

The CheckHandshake method subscribes to the delegate method. The parameters are transmitted from EventHub. Publish (handshakingEvent. In CheckHandshake, you can obtain the corresponding Client object and perform some checks. If not, you can set ev. Cancel to true and write the cause to the CancellationReason attribute and send it back to the Client.

5. Client Object Management

The server needs to manage the client information so that the message can be sent to a specific client during message broadcasting. To maintain the application independence of the client, AspComet defines the Iclient interface:

Iclient description

 

Some basic definitions of the Client are defined here. inherit this interface to implement a Client class.

The client does not refer to the actual browser, but the server identifies the client with persistent connection and the objects used to manage the corresponding information of each client.

IclientRepository description

There is a special value for attention. Just like a chat room, you can create different rooms. People entering the room will only receive messages related to the room. To achieve this, messages must be differentiated by certain rules. In AspComet, we will use the channel to do this. There is a channel definition in the Message packet. With this field, the Message can be sent to all clients subscribed to the channel during Message forwarding. Therefore, you need to define a list on the server to manage connected clients. Each client records its own subscription channel and provides some methods for other programs to access this list, aspComet designed IclientRepository to do this. Let's take a look at the Code:

 

The server maintains a client repository for managing connected clients. You can query the clients that subscribe to a channel through the WhereSubscribedTo method, then, send messages to the list to broadcast messages to specific channels. By default, AspComet implements a memory repository class:

 

Is a collection where all clients are placed.

To persist data, you can inherit IclientRepository to store a database or file.

Client  

The AspComet component does not explicitly provide a set of js-based client APIs, but only adds a set of JS-based APIs in its Demo. The following files are used:

 

I did not list Dobj, the most important of which is cometd. js. This is basically the core API, and the main functions are implemented here. The following describes cometd. js:

1. org. cometd. Cometd class Introduction

This class is the most important, including all the functions, code and functions, which are not listed one by one. It is generally divided into the following parts:

• Initialization Method

Some variables and parameters need to be initialized when using the org. cometd. cometd class. The configure method is the core method used for external configuration. The url of the Ajax request is passed in by calling configure. There are also some parameters such as the maximum number of connections _ maxConnections:

 

Many parameters can be set for initialization through input. Of course, if this parameter is not configured, the default value is also displayed. Therefore, the url must be set.

• Common Methods

Public methods are also provided in this class. Of course, some processing related to components will be built in:

 

• MPs queue object

In the js Code provided by AspComet, a transport object is designed and defined as the pipeline for communication with the server. Therefore, an abstract base class org is abstracted. cometd. in this way, you can customize different pipelines for them to send requests and handle server responses. The advantage is that Transport can develop one set on its own. For example, our team only uses jQuery, then you can create a set of transport based on jQuery and register it at runtime.

In addition, the pipeline design method abstracts the functions of the entire transmission layer, which conforms to the object-oriented idea and places similar services on one object, which facilitates reuse, it is also conducive to business encapsulation.

This design is very accurate.

• Event Management

Because the whole request and response process is encapsulated in org. cometd. cometd class, and is based on asynchronous requests, so for the called program to obtain the corresponding results, you must be able to callback or some kind of listening method. AspComet subscribes to the response by publishing events. The event-related fields and methods in the org. cometd. Cometd class include the following:

Event listening list

Maintain an array in the Code and store the events subscribed externally in this array.

Event Notification

Once an event needs to be notified, a method _ notify y is called, which calls the subscription method in _ listseners one by one and calls the callback that meets the requirements. This process actually realizes the principle of the event.

Event subscription

So how do I subscribe to events when an external program is called? It is the addListener method. This method will pass in three parameters. See the following comments:

Parameter description:

Channel: The subscribed Channel.

Scope: It seems to be a callback function, which can be omitted.

Callback: it is obviously a Callback function, which is a method used for event response.

Event subscription Removal

With subscription, you can remove the event subscription. _ removeListener is not explained much.

• Message sending/receiving management

The most important thing is the overall message management mechanism. The implementation of this Part in the org. cometd. Cometd class is still relatively complicated. On the one hand, it is necessary to send and process various types of messages, and on the other hand, it is necessary to continuously establish a persistent connection to respond to push.

However, it is not easy to use. You only need to instantiate the org. cometd. Cometd class and call the handshake method to shake hands with the server. After successful use, you can call the publish method to send messages.

But it's not that easy internally. What does handshake send to the server? Why can the publish method broadcast messages? Let's explain them separately:

Let's talk about handshake first.

Because the server will verify the client connection, it is required that the client make a handshake before communicating with the server to ensure mutual trust between the client and the server. This process is called handshake. The procedure is as follows:

1) first, you must instantiate an org. cometd. Cometd object and set the request url for the object instance.

2) Call the handshake method to start handshaking.

3) After handshaking, the callback function is executed to process the response package based on the returned status. _ HandleFailure

4) if the handshake succeeds, _ receive (message) will be called; _ connectResponse (message) will be called in the _ receive method; long connection will be initiated

5) if it fails, the system will handle the problem.

After the handshake is complete, a persistent connection is established. Establishing a persistent connection is an interesting method. The call process is as follows: _ connectResponse-> _ delayedConnect-> _ delayedSend.

Let's take a look at the code of the _ delayedConnect method:

 

Generally, the _ delayedSend method is used, and a _ connect () method is passed in. Here it is very important that the _ connect () method initiates a connection request to the server, after the server receives the message sent by this method, a persistent connection is established.

The code for _ delayedSend is as follows:

 

Note: The _ setTimeout method sets the expiration time for this method. I think this is mainly because I don't want to make persistent connections to the server more than once after a period of time. In the actual running status, the _ connect () method is called every 10 seconds to initiate a persistent connection.

I think the advantage is to reduce the duration of long connections on the server. In these 10 seconds, if the server has a response, it can be accepted immediately. If not, the reconnection will be interrupted once every 10 seconds, which can reduce the pressure on the server connection.

The persistent connection process is so simple and constant _ connect.

Publish Method

Another method is the publish method, that is, message broadcast. This method is used to send the encapsulated message to the server through _ queueSend (message. Code:

We can see that in this method, message packets only define the channel and data. Therefore, after the Server accepts the message, it only broadcasts the message to the corresponding channel, and then does not process the message. It is not a persistent connection.

Clients that send messages through publish receive their own messages through subscription.

2. org. cometd. TransportRegistry class Introduction

Take a look at the official notes:

 

It is an object manager. Common methods include searching, adding, deleting, and resetting.

3. org. cometd. Transport class

 

The main responsibility of this class is to abstract common functions of the channel. It is almost a base class. In this class, message packets are sent through persistent connections in the background.

Here are several main methods:

Function _ transportSend (envelope, request)	This is the main method for sending messages, parameter Envelope: message packets Request: Request
This. send = function (envelope, longpoll)	Send message Longpoll: true indicates that a persistent connection is initiated, otherwise it is not
Function _ queueSend (envelope)	Send messages directly, not persistent connections
Function _ longpollSend (envelope)	Send messages in persistent connection mode
This. transportSend	Real message sending method of MPs queue This is a virtual method that can be rewritten by the derived class. Therefore, the actual sending is implemented in the derived class.

 

In the official code, two classes are derived from org. cometd. Transport: org. cometd. LongPollingTransport and org. cometd. CallbackPollingTransport. These two classes are similar to each other, and both of them override the transportSend method, and both call the new virtual methods defined in the two classes respectively:

This. xhrSend = function (packet) defined in org. cometd. LongPollingTransport)

This. jsonpSend = function (packet) defined in org. cometd. CallbackPollingTransport)

It may be to support different formats. It seems to be related to cross-origin access.