The
Mooon main message structure is as follows, with the disadvantage that the message itself occupies a larger number of bytes:
Why do we have to distinguish between IPV4 and IPV6? is because if you only need to support IPV4, then an IP address only needs to be represented in a 4 byte,//the source and destination IP address has a total savings of 24 bytes;//support IPV6, while compatible IPV4, but for IPV4 waste 24 bytes;/Source and destination IP,
Either IPV4, or IPV6, not allowed to cross.
#ifdef ipv6_supported #define Ip_bytes (4*4)//IPV6 address length #else #define Ip_bytes 4//IPV4 address length #endif////////////////////////////////////////////////////////////////////////////////SCHED_NAMESPACE_B Egin/*** * Constant definition */enum {invalid_service_id = 0, invalid_session_id = 0,//invalid SE Ssionid Service_id_max = 100,//maximum SERVICE ID value, starting from 1 Session_id_max = 10000//maximum session ID value, taking value from
1 start}; 4-byte Alignment #pragma pack (4)/*** * Distributed message flags structure * Why flags are individually defined as a struct, * because nuint32_t types are not Hold-bit expression, * so use struct to do a layer of conversion to achieve the same purpose * * typedef struct TDISTRIBUTEDMESSAGEFLAGS {//Use Union for easy exercise
As Union flags {uint32_t flags; struct Tflagsbits {uint32_t ip_type:1; IP address Type, value is Net::ip_type_4 or net::ip_type_6 uint32_t reserved:31;
Reserved bits of}flags_bits;
}flags;
Tdistributedmessageflags (uint32_t v): Flags (v) {}}distribted_message_flags_t; /*** * Distributed Message Header structure * * typedef struct TDISTRIBUTEDMESSAGE {Net::common_message_header header; Message head nuint32_t flags; Flag field nuint32_t Source_ip[ip_bytes]; The IP address of the message source, if it is the IPV4 address, then the n value is 1, otherwise 4 nuint32_t destination_ip[ip_bytes]; The IP address of the message destination, if it is the IPV4 address, then the n value is 1, otherwise 4 nuint16_t source_port; The port number of the message source nuint16_t Destination_port; The port number of the message destination nuint32_t source_service_id; Destination_service ID nuint32_t destination_service_id; Service ID nuint32_t source_session_id of the message destination; Destination_session ID nuint32_t destination_session_id; The session ID nuint32_t Source_sequence_number of the message destination; Serial number, starting from 0, sequentially increment, until again, used to solve the timed_wait problem similar to TCP nuint32_t Destination_sequence_number; Serial number, starting from 0, sequentially increment, until again, used to solve the timed_wait problem similar to TCP nuint32_t source_thread_affinity; Thread affinity values in order to establish a binding relationship with the thread nuint32_t destination_thread_affinity; Thread affinity value, in order to establish binding relationship with thread char data[0];
Message content std::string to_string () const;
}distribted_message_t; #pragma pack () inline bool Is_valid_service (uint32_t service_id) {return service_id > 0 && S
ervice_id <= Service_id_max; } inline bool Is_valid_session (uint32_t session_id) {return session_id > 0 && session_id <= SE
Ssion_id_max; }////////////////////////////////////////////////////////////////////////////////SCHED_NAMESPACE_END
Diagram:
This article is from the "Flying Month" blog, please be sure to keep this source http://mooon.blog.51cto.com/1246491/948302