Process for distributing various objects in the herm unified distribution framework

The distribution framework manages a tree of handlers, which are divided into general and specpacific ). A general handler serves all objects, and a proprietary handler serves a specific object (generally role ). The framework structure is described as follows:

Cmd1 -----> handlers

Cmd2 -----> handlers

Cmdn -----> handlers

+ -------> Cmd1 ------> handlers

|

Oid1 -------------- + --------> cmd2 ------> handlers

|

+ ---------> Cmd3 -----> handlers

 

Oid2 ----......

 

The following uses network messages as an example to describe how a unified framework distributes a message. The premise is that various external objects register the oId-type-handler to the distributor.

1. Get a message and get the Object ID and message command.

2. In general handlers, check whether the command has corresponding handlers. If yes, call the handler interface.

3. Locate the specific handlers of the object based on the Object ID. If yes, call the handler interface.

 

This is very simple and seems useless. It has a huge role. In actual development, it greatly simplifies the message processing process and eliminates program coupling.

This is provided by the herm base library and can be used independently by applications. Herm framework also uses this distributor to send messages. Framework is a session that maintains a distributor.

To put it simply, the difference between different servers using the distributor. Online Game servers generally have access servers and logic servers. The access server manages multiple sessions. After receiving a message, it combines the messages of different sessions into a session and sends it to the Logic Server, that is, the logic server has a session. The Access Server sets the number of specific handlers to 0. After the Logic Server obtains a message, it usually needs to use specific handlers to distribute the message to the real processing object.