Esframework introduction (2)-network communication message netmessage

Compared with C ++,. Net is a more "dynamic" platform. Its dynamic capabilities are built on the reflection mechanism, while reflection is based on "metadata ".

As mentioned above, if a framework wants to do more things for our applications, it must establish more standards, you must have a better understanding of the messages to be processed by the Framework. Therefore, each message must be self-described, that is, each message must contain its own "metadata ". So where is the "metadata" in the message? You must have thought of it. Yes, it's the messagheader ).

In esframework, the message netmessage consists of a message header + body, and both the message header and body must implement the icontract interface mentioned above. The message header is the metadata of this netmessage, which contains descriptions such as the message length and message type. In order to identify the metadata of each message, esframework must establish a "standard", which is the imessageheader interface. To simplify the subsequent computing and application, esframework requires that the length of all message headers be fixed, for example, 64 bytes. Note that the length of a fixed message header is not required, but this reduces the complexity of the framework.
Let's take a look at what information is contained in the imessageheader:

1 public interface imessageheader: Icontract, Icloneable
2 {
3 int messagebodylength {Get; set;} // length of the message body
4 int typekey {Get; set;} // type of the requested service directory
5 Int servicekey {Get; set;} // request type
6 int serviceitemindex {Get; set;} // request subdivision index
7 int randomnum {Get; set;} // used to match the reply and request one by one
8 int result {Get; set;} // service result. 1 indicates success. Other values correspond to serviceresulttype
9 string destuserid {Get; set;} // Number of the target user who receives the message
10 string userid {Get; set;} // user ID that sends the request
11 bool p2pack {Get; set;} // only valid for P2P messages. 1 indicates the server's ack for forwarding P2P messages. The result indicates whether the forwarding succeeds or fails. The ACK message subject is null.
12 bool zipme {Get; set;} // determines whether to enable compression/decompression for this message. If some messages are short, set imessageheader. zipme to false.
13}

 

Imessageheader already contains a lot of content. In fact, at the beginning, imessageheader only needs 32 bytes. As esframework evolves, more and more information is coming in, currently, the length of the imessageheader is basically 96 bytes. The added content is required for many applications.

For example, destuserid indicates that the message is not sent to the server for processing, but to the user whose ID is destuserid. This introduces the framework to process "P2P messages". Sometimes, A user may need to send a series of P2P messages in order. If the message is based on UDP, the user must wait until the other party confirms to receive the previous message before sending the Next message, so the p2pack field is available. It is a common requirement to compress messages transmitted over the network. Some short messages do not need to be compressed, and the zipme field appears, indicates whether the message is compressed or unzipped.

In your specific application, the content of the message header should be determined by the needs of your application. For example, your application may never need to process P2P messages, when implementing the imessageheader interface, you do not need to pay attention to the destuserid field and p2pack field, and do not need to provide a "location" for the byte stream of your actual message header "; when using esframework to assemble your application, you do not need to "plug in" or "p2pmessage processor ". This is very flexible.

What is the structure of the message header? What is the message subject? At the framework layer, because the framework does not know anything about the content of the message body, even if the Framework knows that the message body can be resolved as an icontract "object", at this layer, there is not enough information for the framework to resolve the subject to icontract. Therefore, the Message Subject in the framework is still represented by a throttling byte [], and the framework does not care about how the message subject is parsed or processed. The framework has a sufficient understanding of the message through the message metadata.
The message netmessage is defined as follows:

1 [serializable]
2 public class netmessage
3 {
4 Public imessageheader header = NULL;
5 Public byte [] body = NULL; // The Hook can be compressed and transformed.
6 Public OBJECT tag = NULL; // this parameter is used to transmit additional information when netmessage is sent to idatadealer without affecting tostream and is rarely used.
7
8 Public netmessage ()
9 {
10}
11
12 # region ctor, tostream
13 public netmessage (imessageheader header, byte [] body)
14 {
15 // omitted implementation ......
23}
24
25 public byte [] tostream ()
26 {
27 // omitted implementation ......
41}
42 # endregion
43
44 # region length
45 public int Length
46 {
47 // omitted implementation ......
57}
58 # endregion
59
60}

The tag field is used to store additional information that may be used in the subsequent message processing chain. For example, when UDP is used, the tag can store the ipendpoint of the customer who sent the message, this information may be used by later message processors.

Roundedmessage contains more information than netmessage. roundedmessage is actually received from the network. Sometimes message distributors or Processors may need information like connectid.

At the client and application layer, netmessage can be converted downward, because at this time, we already know the structure of the message body, which can be parsed as icontract, therefore, netmessage can be converted to message:

Message
Public class message
{
Private imessageheader header;
Private icontract body;

Public message (imessageheader theheader, icontract thebody)
{
// Omitted implementation ......
}

Public netmessage tonetmessage ()
{
// Omitted implementation ......
}

# Region tostream, getstreamlength
Public int getstreamlength ()
{
// Omitted implementation ......
}

Public byte [] tostream ()
{
// Omitted implementation ......
}

Public void tostream (byte [] buff, int offset)
{
// Omitted implementation ......
}
# Endregion

# Region header, body, messagehelper
Public imessageheader Header
{
// Omitted implementation ......
}

Public icontract body
{
// Omitted implementation ......
}
# Endregion

}

As you can see,

Netmessage is already a completely object-oriented message. The specific content of the subject must be converted down to the specific Protocol by icontract. This is usually the work of the message processor.

For more information about message processors and processor factories, see the next article.

Esframework introduction (3)-message processor and processor Factory

Previous Article: esframework introduction (1)-Network Communication Message Protocol Interface (icontract)

Go to: esframework reusable Communication Framework (sequence)