. NET Server push

I did not see the source code for server push (server push) under. net on the Internet. I have been reading the source code for two days on and off, but there are many difficulties.
The most profound experience of server pushing technology should be the use of webqq, which pushes information to the client through the server, rather than actively retrieving data (client pull) from the client ).
When Ajax technology is widely used, server pushing technology will be the main character of the future.

Ajax only implements single-user response callback and asynchronous communication with the server, but does not reflect the synergy between multiple users. Multiple Ajax Asynchronization operations on a page may allow users to modify data that is not displayed, logically, there is a concept of "Dirty read" or "Phantom read" in database transactions, and the next request is sent without seeing the data (of course, the request is sent to another page element, hopefully, some page elements still refresh the unmodified Ajax request information .).

So we have the server push technology. On the webpage that uses the comet framework, after page initialization, a connection is maintained and server-side event information is monitored. The server uses the event mechanism to push the browser (or the client. Different clients simultaneously listen to server events and obtain data from the server. Each client's request becomes a server event that is "broadcast" on the network ".
Client-based server pushing technology has appeared on the Internet. In fact, they all use IFRAME, applet, flash and other elements to achieve persistent connections.

Trouble in system design

First, how can we make our browser receive events from the server?
One way is to indirectly connect to the client socket by using components such as flash, IFRAME, or applet without entity size, push information to these components, and use JavaScript threads, obtain the information returned by the component (of course, in some cases, these components directly inject information to the page ).
The final result shows that we have a stable connection to the server and refreshed the page information. But in fact, this implementation method is not "direct ".
Flash (or flex) itself can call WSDL through WebService components, or directly call Java serverlet, which is a convenient condition provided by Flash Player, but implementing server push through Flash Communication is always unacceptable. Why not directly implement Flash Communication.
Not to mention the applet, directly "push" the jar package to the page to run, start the troublesome JRE and download the huge JavaProgram. If you do not have a JRE, You need to download it.
The sliverlight mechanism is similar to that of flash, because Flash Player is not widely used. Users also need to download the corresponding player.
The above three are not completely Web applications. We just want to use the purest JavaScript and HTML to solve the problem. Why bother the public? Simply JavaScript events and threads cannot meet our needs?
As a result, some people think of IFRAME. They send Ajax requests through an invisible IFRAME and get messages through long polling. However, this is not really a comet. At most it is an immature Ajax application.
The essence of comet is to use the server and JavaScript to maintain the browser's persistent connection and complete the browser-side response to server-side events. Such an event broadcast mechanism is cross-network and real-time.
Comet technical difficulties

1. Maintain persistent connections
2. Maintain the "Heartbeat" of the server"
3. browser-Side "Sensing" of "Heartbeat"
4. Maintain the balance between persistent connections and timeout
5. Thread Synchronization
6. General Interface Design


Entity class
1. cometclient: the service entity of Comet. The significance of instantiating a cometclinet is to record necessary service information, such as user name timeout settings.
2. cometmessage: Contains entity classes for service information and trust attributes. It is the subject of message transmission.
3. inproccometstateprovider: inherits icometstateprovider, implements message operation methods, and saves messages in memory.
Interface Class
1. icometstateprovider: defines a series of interfaces to provide operations on cometclient entities and cometmessage.
Exception
1. cometexception: there are no special exception classes.
Event
1. cometclienteventhandler: event listening and broadcasting of cometclient.
Thread-related
1. cometwaitthread: server-side thread pool, waiting in queue for information requests and calls, and providing timeout and other operations.
2. cometwaitrequest: a server-side thread that listens to client message requests.
3. cometasyncresult: The management class of asynchronous requests. It is implemented asynchronously by Inheriting System. iasyncresult.
Subject
Cometstatemanager: A factory class used to manage thread pools, management threads and user connections, message forwarding, and other operations.
The cometmessage class is the communication carrier of comet and abstracts the message body. In fact, this class is the easiest to expand, because it is only a message container in terms of design. Such as geographic coordinates and business data can be directly expanded through this class.
The class design is simple and clear. It is necessary to explain the significance of using the system. runtime. serialization namespace.
The "system. runtime. serialization namespace contains classes that can be used to serialize and deserialize objects. Serialization refers to the process of converting an object or an object image to a linear byte sequence for storage or transmission to another location. Deserialization is the process of accepting stored information and using it to recreate an object ."
This is an explanation given by msdn. It converts an object to a linear byte for convenient transmission and call. Of course, the data types in this example are not complex, but they also contain data types such as long, object, and string. The contents member is an object, which leaves us a lot of imagination. (Image? Complex object types? Custom object type ?......)
Cometclient class: The cometclient class is an abstract class for client information. It also contains two key attributes: connectionidleseconds and connectiontimeoutseconds. Considering the transmission attribute between different clients, system. runtime. serialization is still used to serialize information.
Connectionidleseconds: used to set the connection thread. When the connection is disconnected, the backend thread will survive.
Connectiontimeoutseconds: the timeout time of the client. After the timeout time is exceeded, the client reconnects to the server.
PS: after these two attributes are available, the Client Connection Control is basically completed. The connection times out and reconnects. When there is no connection, the background thread is killed.
Icometstateprovider interface: The icometstateprovider interface is directly created by cometstatemessager. The advantage is that after the cometstatemessager object is instantiated, The cometstatemessager object can directly call the implementation of the icometstateprovider interface, which actually implements the adapter method, we can customize different inproccometstateprovider classes (as mentioned below) to customize our own interfaces.
The icometstateprovider interface class provides the following interfaces.
Initializeclient: Initialize the comentclient.
Getmessages: Get a message queue for messages.
Sendmessage: Send message data.
Sendmessage: You can publish messages (private sessions) based on the client name ).
Getcometclient: returns a client.
Killidlecometclient: kill an invalid client object.
PS: of course, this interface can be expanded and implemented very easily. Obtain client queue information and client status. You can even imagine some more complex applications (such as adding a streaming media message ......).
Inproccometstateprovider class: The inproccometstateprovider class implements the icometstateprovider interface and provides a good example. For this class, we can imagine many great extensions, such as calling the AO component and encapsulating alarm information.
The inproccometstateprovider class contains a private internal class, inproccometstateprovider. In fact, it can be understood as a simple encapsulation of messages, considering the need to associate cometclient and message during design, it can also be designed as an external class. However, the adapter itself should not have too many associated classes, which also balances some expansion requirements.
Cometwaitrequest class: Cometwaitrequest is an abstract of the control information of a request. It contains all the required control information and is directly called by cometwaitthread. A simple understanding of this class requires some threads to manage the publishing of server events. cometwaitrequest abstracts the control information of these events. A user can initiate multiple client requests, the server needs to launch such a request. The information that a user submits to the server must be controlled by the corresponding thread, and the events are queued, followed by the request queue, message Queue requires direct management of threads. This class is the abstraction of management information on the customer end.
Cometasyncresult class: This class is also very interesting. The iasyncresult interface on msdn has the following explanations:
"The iasyncresult interface is implemented by classes that contain methods that can be operated asynchronously. It is the return type of the method to start asynchronous operations, such as filestream. beginread. It is also the type of the third parameter of the method to end asynchronous operations, such as filestream. endread. When the asynchronous operation is completed, the iasyncresult object will also be passed to the method called by asynccallback.
Objects that support the iasyncresult interface store the status information of asynchronous operations, and provide synchronization objects to allow the thread to terminate when the operation is completed ."
The cometasyncresult class inherits many benefits from the iasyncresult interface. First, we can directly use the. NET Framework asynccallback begininvoke and endinvoke to start or end asynchronous operations.
". Net framework allows you to call any method asynchronously. To this end, define the delegate with the same signature as the method you want to call. The Common Language Runtime automatically uses the appropriate signature to define the begininvoke and endinvoke methods for the delegate.
The begininvoke method can be used to initiate asynchronous calls. It has the same parameters as the method to be executed asynchronously. It also has two optional parameters. The first parameter is an asynccallback delegate that references the method to be called when the asynchronous call is complete. The second parameter is a user-defined object that can pass information to the callback method. Begininvoke returns immediately without waiting for the asynchronous call to complete. Begininvoke returns iasyncresult, which can be used to monitor the asynchronous call progress.
The endinvoke method retrieves the result of an asynchronous call. After begininvoke is called, you can call the endinvoke method at any time. If the asynchronous call is not completed yet, endinvoke will stop the calling thread until the asynchronous call is completed. Endinvoke parameters include the out and ref parameters of the method to be asynchronously executed (<out> byref and byref in Visual Basic) and iasyncresult returned by begininvoke ."
Cometwaitthread class: The cometwaitthread Thread class controls cometwaitrequest. After a user submits a message, a cometwaitthread is created.
Cometstatemanager class: Cometstatemanager is the core of the entire comet mechanism. It combines cometwaitthread with icometstateprovider, cometclient, and cometmessage to form a complete comet application framework. Is a class that must be transformed to expand the comet application.

Source code download