Esframework (31)-message classification and corresponding Processor

This is an article that has been late for a long time. Article If I did not see the article "esframewok-based client and Client Communication" written by mediar today, I may not remember to write this blog that should have been published very early, it can help esframework researchers/users better use esframework. The mediar friend's article describes how to forward p2pmessage through the server. mediar manually implements a processor. In fact, esframework has a built-in p2pmessage processor, that is, p2pmessagedealer, p2pmessagedealer not only forwards messages to friends connected to the same as, but also to friends connected to remote. Thanks to the example provided by mediar!

So far, esframework has divided messages received from end users into six types, which can be seen through servicetype enumeration: Public   Enum Servicetype
{
Basic, // Ibasicrequestdealer
Function,
P2pmessage, // For P2P messages, the server only forwards, p2pmessagedealer
Friendrelation, // Such as friend list and friend information, and friendrelationdealer
Groupmessage, // For example, synchronous messages in multiplayer online games (Dynamic Group messages) -- activegroupmessagedealer
Customservicetype // Custom Service types
}

let me explain the meanings of these types of messages first:
(1) basic, basic messages are similar to such messages, such as logon, logout, and check messages.
(2) function. A function request message is a message of all request function services. Such a request message has a corresponding reply message, for example, the query results are obtained after the server computing is required. In esframework, almost all function-type messages are processed by function plug-ins.
(3) p2pmessage (point-to-point message) refers to a message sent by a user to another user and transferred through the server, such as a chat message in instant messaging.
(4) friendrelation, a friend relationship request message, such as a friend list or friend information, which is common in many IM applications.
(5) groupmessage: Dynamic Group request message. Esframework supports dynamic group creation and management at runtime.
(6) customservicetype, a custom message type, that is, messages other than the preceding five types used in your application.
(7) Add a message for cross-region (as) requests. messages of this type will be forwarded to the target as by the local. (Review cross-region as)

Esframework provides the default processor (or processor Interface) for each type of message. They are:
(1) for basic message types, esframework provides the ibasicrequestdealer interface. Your application can process all basic messages as long as this interface is implemented.
(2) For function-type messages, because they are usually processed by function plug-ins, esframework provides funaddindealerfactory to process all function request messages.
(3) p2pmessage: For all messages to be forwarded, esframework provides p2pmessagedealer and p2pmessagedealer for local and cross-region (as) forwarding. You can use ioverduemessagehandler to store failed messages for future retry.
(4) friendrelation: For friend relationship requests, esframework provides the friendrelationdealer processor. You only need to implement other component interfaces used by the processor.
(5) groupmessage. For dynamic group request messages, esframework provides activegroupmessagedealer for direct processing.
(6) customservicetype: For custom message types of applications, You need to implement your own message processor.
(7) For cross-region (as) requests, You can implement a specific processor based on the communication mode between. If the as communication uses. Net remoting, esframework provides esframework. architecture. fourtier. foreigndealer to process cross-region requests.

All the above message processors can be assembled into the esbrequestdealerfactory factory. esbrequestdealerfactory reserves a processor slot for each type of messages. You can inject the processor through the corresponding attributes! The figure is as follows:

(The components with the yellow background in the figure have already been implemented in esframework! Basicrequestdealer requires you to implement the ibasicrequestdealer Interface)

If your application only needs to use several types of messages, you only need to assemble the corresponding message processor for esbrequestdealerfactory, so that no extra cost will be paid for unused message types.

Previous Article: esframework (30)-inetmessagespy

Go to: esframework reusable Communication Framework (sequence)