Analysis of Comet technology based on ASP

Comet Technology Principles

From Wikipedia: Comet is a web-based technology that enables the server to deliver updated information to clients in real time, without requiring the client to make requests, there are two implementations, long polling and IFRAME streams.

In short, a long polling technology based on existing HTTP protocols, all of which are the main reason for this technology is that the HTTP protocol is stateless, so there is no way between the client and the server to establish a long-time connection. For example, we want to make a chat room, in the web environment we usually can not push the message from the server to the browser, but only through the constant polling of each client servers to obtain the latest news, which is very inefficient, and the constant sending of requests to the server can also cause significant resource usage for applications with large access levels.

So people found this technology, to the server to make a request, and then the server has not responded to this request, so that the client and the service side formed a long connection, until the service side to respond to the request to end the connection. Borrow pictures from IBM:

Through the Ajax technology can realize the long polling server push model, the client and the service side through the continuous initiation long polling can realize the data interaction, this process is the AJAX implementation asynchronous operation so the experience will be better, the efficiency is very high. Gee, I can't say for sure, find an online profile:

The comet mode is popular as a long connection mechanism (long lived HTTP). The request was also initiated by the browser side, but the server side responded with a seemingly very slow response. So during this period, the server side can use the same connection to send the data to be updated actively to browser. So the request may wait for a long time without any data return, but once the new data is available, it will be sent to the client immediately. There are many different implementations of comet, but in general there is an increase in load on the server side. Although for the unit operation, it is necessary to suggest only one connection at a time, but because connection is maintained for a long time, Server-side resource usage is increased.

Advantages: Good real-time (message delay is small), good performance (can support a large number of users)

Disadvantage: Long-term occupancy of the connection, loss of the characteristics of high concurrency without state.

Application: Stock system, real-time communication.

Resources:

Comet: "Server Push" technology based on HTTP long connections

Realization of comet technology based on ASP.

ASP. NET itself is a web-born technology, so innate is to meet drops. The asynchronous request processing based on AJAX technology and ASP. NET can provide more powerful capabilities for comet. In this grand launch: IHttpAsyncHandler interface.

• IHttpAsyncHandler Interface Introduction

IHttpAsyncHandler is inherited from IHttpHandler, but the difference is that IHttpAsyncHandler has innate asynchronous capabilities. He's 2 more ways than IHttpHandler:

IAsyncResult BeginProcessRequest (HttpContext context, AsyncCallback cb, Object extradata); void EndProcessRequest ( IAsyncResult result);

The BeginProcessRequest method returns the IAsyncResult interface, which typically handles some of the more onerous tasks in beginprocessrequest, such as IO operations, reading Web services, and so on. Once the asynchronous operation is complete, the asynchronous result can be obtained through the EndProcessRequest method.

The advantage of IHttpAsyncHandler is that when it handles an asynchronous method, the thread that handles the request can be temporarily freed, and there is idle time to handle the other request, and when the asynchronous method finishes running, the next request is processed by the thread.

• ASP. NET implements Comet

With a technical foundation then look at how to implement this technology:

In the client we need to implement the sending request, which can be achieved through AJAX technology, can be easily and easily implemented by JavaScript asynchronous request operation.

On the server to listen to the specific request type, by implementing IHttpAsyncHandler processing request, BeginProcessRequest method has a AsyncCallback type of parameter CB, which is a callback function, If you do not call this callback function in ASP. CB does not respond to the request, that is, the content is not returned to the client, which enables long connections. Until the server has data to return to the client, the service side calls the CB function to trigger the execution of the EndProcessRequest method, at which point the client receives the response packet.

After the client receives the data, it can continue to initiate a request to the server, and repeat the process to simulate the state of a long connection.

Aspcomet Component Introduction

There is an open source component in ASP. Aspcomet is a better implementation of comet, this component of the open source site: Https://github.com/nmosafi/aspcomet.

At the core of Aspcomet is the request by Ajax, the service side based on IHttpAsyncHandler to process the request, through a message bus processing a full set of Web push technology. Components are divided into two parts: server and client, both have good extensibility, the service side has more flexible delegate processing, can also be rewritten by their own implementation of the needs of the business processing, very convenient two times development. And the client also provides a good encapsulation, support a variety of mainstream JS script library, such as Jquery,dojo, in the official demo provides the implementation of these two script libraries.

After reading the source code of the Aspcomet is still more exclamation, although it looks very laborious, but also really feel that the code for two times the development provides a good support. Basically is object-oriented to achieve the entire component, even JS also applied a lot of design patterns. Here are some examples of the main implementations of this component:

Service Side

1, first must implement the IHttpAsyncHandler interface

Comethttphandler:ihttpasynchandler, this class is the processing unit for asynchronous requests, which is simply the portal of the server. Here, the requested content is hold by the BeginProcessRequest method, and the callback is also hold. Of course, there is a point to note is that Messagebus, all the news how to hold it depends on it, because some of the message is to be returned to the client immediately, and some are to be processed by the message bus and then forwarded, there are some to stay as a long connection. The specific will be explained when the message bus is spoken.

Eventually Comethttphandler calls the EndProcessRequest method at the end of the request, returning the message to the waiting connection, and the client receives and processes the response packet for the request.

Comethttphandler is the realization of an ingress and egress, through the ihttpasynchandler of the asynchronous processing power to achieve a long connection state.

2. Message Wrapping

The interaction between the client and the server must have a message packet, otherwise the two parties cannot make some conventions, after all, the HTTP protocol is loosely stateless. A class was implemented in Aspcomet: Message

This kind of aspcomet developer called it: Bauyeux message, which seems to be a set of protocols proposed by dojo.

Here are a few of the main examples in this message pack:

Channel: Message channel for the channel on which the message is broadcast

ClientId: ID of the client

Data: Packet (is an object type, it is easy to use for extended packets)

Version: Revision number, which is useful for backwards compatibility of messages

Advice: After the return of the processing method, called notification can also

Timestamp: Time stamp

Ext: It seems to be an extension.

The content of the package is very rich, sometimes the agreement is a kind of convention, in fact, for us is a class, and even you can understand is a string, the client and the service side through some kind of convention can parse each other to identify.

3. Message bus Design

When it comes to Ihttpanyschandler, we refer to the message bus, which is abstracted as an interface in Aspcomet: Imessagebus.

public interface imessagebus{void handlemessages (message[] messages, Icometasyncresult cometasyncresult);} 

In one way, this is the core method that Aspcomet uses to process the message, which means to process the message, in which the received message is mainly assigned to different message handlers for processing. For example: when initiating the handshake protocol, the message is sent to Metahandshakehandler, which is a message relay center.

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

The parameter Cometasyncresult is a two-time encapsulation of the asynchronous request callback function, the main purpose of which is to catch the callback and not let it respond, so that you can control when the response packet is returned. Icometasyncresult interface on two methods

Sendawaitingmessages is the message that is used to send the wait, mainly for the message to be sent to the Send pipeline

Completerequestwithmessages is the process used to complete the request, mainly by tuning callback to tell IHttpAsyncHandler that the request can be returned.

The combination of these two methods enables you to send messages to the client.

Here is a point: in fact, the way to send data to the client is very simple, HTTP sub-Request packet and response package, the client to the server called the request (requests), the server sent to the client's call response (Response), this should be understood. Sendawaitingmessages is to write data into the response, so that the client does not have to receive data?

4. Processing of various types of messages

In the message bus that mentions the message processor, why does this stuff exist? In fact, this is related to the entire communication process, there is a handshake process, connection establishment process, disconnection process and so on, this will have a set of processing methods, that is, each of the different processes to do a separate type of processing. There is an interface in Aspcomet: Imessagehandler, which defines a unified method for message processing:

By inheriting this interface to implement a specific message processing class, you can accomplish some specific business, and the following list of message processing classes:

Metahandshakehandler	Handshake Protocol Processing
Metaconnecthandler	Connection Protocol Processing
Metadisconnecthandler	Disconnect Processing
Metasubscribehandler	Subscription processing
Metaunsubscribehandler	Stop subscription Processing
Forwardinghandler	Message forwarding Processing
Exceptionhandler	Exception Message Handling
Swallowhandler	Swallow message processing, do not return to client

From the literal meaning should be able to understand the general, what message to do what to deal with, this means.

When it comes to the categorization of messages, there is one thing that must be said about how to differentiate the message types in Messagebus and find the corresponding handlers. This is the credit with Imessagesprocessor.

In this interface The process method is used to process the forwarding of each message, this design is also very good, we can even implement a own messagesprocessor completely according to their own requirements for message forwarding and processing. Here I would like to look at the official default implementation, there is a default implementation messagesprocessor in the Aspcomet component, the code is as follows:

As can be seen in the code, Messageprocessor is a handlerfactory to get the actual Imessagehandler instance, and thus processing the message, the process is not complicated, An official implementation is the Messagehandlerfactory class:

The method to be handled here is to call the corresponding handler according to the different channel.

Back to the Imessagehandler, you have to explain the Aspcomet the design of the delegate that is released when the individual message is processed, the corresponding delegate is invoked when handler executes the Handlemessage method, and the external program can subscribe to the delegate implementation to do some processing. For example, I am in the handshake process to verify the legitimacy of the client, but the legitimacy of the client needs external applications to test, how to do? You can handle the two delegates that are freed up by the Handlemessage method in Metahandshakehandler, with the following code:

There are two eventhub.publish (...) in this code. Call, this is the two delegate invocation, we want to implement the client legitimacy validation will be processed at the first delegate, such as the above code has two lines of code:

This is called a delegate, and the argument is handshakingevent. Programs that subscribe to this delegate externally handle the appropriate logic, and if they do not, set their cancel property to true to indicate that the message sending process is canceled and can be written to the appropriate reason. Here is an example of an implementation:

The Checkhandshake method is to subscribe to the method of the delegate, where the parameters are from Eventhub.publish (handshakingevent); In the checkhandshake can obtain the corresponding client object and do some checks, etc., if not meet the requirements can be EV. Cancel is set to True and the reason written to the Cancellationreason property is sent back to the client.

5. Client Object Management

On the server side to manage the client's information so that it can be sent to a specific client when the message is broadcast, in order to maintain the application independence of the client, Aspcomet defines the IClient interface:

IClient description

This defines some of the basic definitions of the client, and it is OK to inherit this interface to implement a class of clients.

What is said here is that the client does not refer to the actual browser side, but rather the server is used to differentiate between long-connected client identities and the objects that manage the corresponding information for each client.

Iclientrepository description

There is a special attention to the problem, just like a chat room, you can set up a different room, and people who go into a specific room will only receive messages related to this room. To achieve this, the message is to be differentiated by some sort of rule. This is done through the channel in the Aspcomet. There is a definition of channel in the message packet, and with this field, messages can be sent to all clients subscribed to the channel when the message is forwarded. So on the server also define a list to manage the connections of the client, each client will record its own subscription channel, and then this list provides some methods for other programs to access, Aspcomet designed iclientrepository to do this, look at the code:

A client's repository is maintained on the server to manage the connected client, to know which clients subscribe to a channel to be queried through the Wheresubscribedto method, and then send a message to the list to broadcast to a specific channel. Aspcomet implements a memory warehouse class by default:

is a collection that puts all the clients in this collection.

If you want to persist data, you can implement a database or repository of files by inheriting iclientrepository.

Client

In the Aspcomet component does not explicitly provide a set of JS-based client API, but in its demo put a JS-based set of APIs. Mainly the following files:

Dobj I did not list, one of the most important is cometd.js, this basic is the core API, the main functions are implemented in this area. Let's highlight the cometd.js here:

1, ORG.COMETD.COMETD class introduction

This class is the most important, including all the functions, code and functions are particularly numerous, not listed, broadly speaking, divided into these parts:

• Initialize method

Some variables and parameters need to be initialized when using the Org.cometd.cometd class, and the Configure method is the core method for external configuration. Passing the URL of the AJAX request is done by calling configure. There are some parameters such as maximum number of connections _maxconnections and so on:

Many of these parameters can be initialized by passing in the settings. Of course, if you do not configure it will also have a default value. So at the moment it seems certain to set the URL is.

• Public methods

Public methods are also available in this class, and of course, some of the processing that is related to components is built-in:

• Pipe objects

In the JS code provided in Aspcomet, a transport object is designed to be defined as a conduit for communicating with the server. This also abstracts an abstract base class Org.cometd.Transport, so that it can be customized for different pipelines to achieve the request of the sending and processing server response, the advantage is that Transport can develop a set of their own, for example, our team will only use jquery, then we can build a set of jquery based on Transport, the runtime registers in it.

And the pipeline design method also for the entire transport layer of the function of abstraction, which is in line with the idea of object-oriented, the same kind of business on an object, that is convenient reuse, but also conducive to business encapsulation.

This design is very fine seconds ah.

• Event Management

Because the entire request and response process is encapsulated in the Org.cometd.Cometd class, and is based on an asynchronous request, the calling program must have a callback or some kind of listener to get the corresponding result. Aspcomet a subscription to a response by publishing an event, there are several event-related fields and methods in the ORG.COMETD.COMETD class:

Event Listener List

Maintains an array inside the code, placing events for external subscriptions in this array.

Event notification

Once you have an event that needs to be notified, you call a method _notify, which invokes the subscription method in _listseners, calling the callback that meets the requirements. This process actually realizes the principle of the event.

Event Subscription

So how do you subscribe to events when external programs are called? Is the AddListener method, this method passes three parameters and looks at the comment:

Parameter description:

Channel: Subscribed Channel

Scope: Seemingly a callback function, can be omitted, do not know the specific use

Callback: Obviously a callback function, which is the method for event response

Event subscription Removal

With a subscription, of course you can remove the event subscription; _removelistener, not much to explain.

• Message Send/Receive management

The most important thing is the entire management mechanism of the message, the implementation of this part in the Org.cometd.Cometd class is still relatively complex. On the one hand to achieve the various types of message delivery and processing, on the other hand to constantly establish a long connection in response to push.

But the actual use is not cumbersome and simple, as long as the org.cometd.Cometd class is instantiated, and then call its handshake method and the server implementation handshake, successful call publish method can send a message.

But in the interior is not so simple, handshake is sent to what to the server? Why can the Publish method broadcast messages? Let's explain it separately:

Well, let's start with handshake.

Because the server will authenticate the client connection, it is required that the client should do a handshake before the normal message communication with the server to ensure that the client and the server are trusted, this process is called handshake. The following steps are performed:

1) First, be sure to instantiate a Org.cometd.Cometd object, set the request URL for the object instance

2) Call the handshake method to start the handshake

3) After the handshake, the response package is processed according to the returned state execution callback function. For handshake successful response processing call _handleresponse, call _handlefailure on Failure

4) If the handshake succeeds then _receive (message) is invoked, and _connectresponse (message) is invoked in the _receive method;

5) If you fail, you will be treated.

After the handshake is complete then there will be a long connection established, the establishment of a long connection is a more interesting method, the call process is as follows:_connectresponse-> _delayedconnect->_delayedsend.

First look at the code for the _delayedconnect method:

The main is the general _delayedsend, and inside will pass a _connect () method, here is very important, _connect () method is to initiate a connection request to the server, the server receives the message sent by this method will establish a long connection.

The code for _delayedsend is as follows:

Note the _settimeout method, which sets the expiration time for this method. I think this approach is mostly not to let long connections on the server for a long time, it will be called once over a period of time. In the actual running state, the discovery will call the _connect () method every 10 seconds to re-initiate the long connection.

The advantage I think should be to reduce the length of the connection on the server to stay on the time it. This 10 seconds if the server has a response can be accepted immediately, if not then 10 seconds to break the reconnection, should be able to reduce the pressure on the server connection.

The long connection process is so simple and constantly _connect.

Publish method

Another way is to publish the method, which is the message broadcast. This method is called to send packets of good messages through _queuesend (message) to the server. Code:

You can see that the message packet in this method only defines channel and data, so the server will only broadcast it to the appropriate channel after it has been accepted, and then it will not be processed, not a long connection.

Clients that send messages through publish receive their own messages by subscribing.

2, Org.cometd.TransportRegistry class introduction

Take a look at the official notes:

is an object manager, the common method is to find, add, delete, reset.

3, Org.cometd.Transport class

The responsibility of this class is to abstract out the common functions of the channel, almost the base class bar. This class is mostly done to send long connections to message packets in the background form.

Introduce some of the main methods in this:

function _transportsend (envelope, request)	This is the main method of sending the message, the parameter Envelope: Message Packets Request: Requests
This.send = function (envelope, longpoll)	Send Message Longpoll:true indicates that a long connection is initiated, otherwise it is not
function _queuesend (envelope)	Send a message directly, not a long connection
function _longpollsend (envelope)	Send a message in a long-connected way
This.transportsend	Pipeline Real Send Message method This is a virtual method for the derived class to override, so the real send is implemented in the derived class.

Two classes were derived from Org.cometd.Transport in the official code: Org.cometd.LongPollingTransport and Org.cometd.CallbackPollingTransport. I feel like these two classes, and two classes rewrite the Transportsend method, and all of them call the newly defined virtual methods in the two classes separately:

Called This.xhrsend = function (packet) defined in the Org.cometd.LongPollingTransport

Called This.jsonpsend = function (packet) defined in the Org.cometd.CallbackPollingTransport

It might be to support different formats, as if they were related to cross-domain access.

Analysis of Comet technology based on ASP