Standardized module interface--Unified Messaging

Would like to write tonight how to engage in dynamic loading and dynamic patches, but unfortunately, turned over the hard disk, did not find the previous code, even the network disk is not backed up. This time, only Huanran dawu--six months ago I changed into the current notebook, the elimination of the old desktop computer. Fortunately, the hard drive was not lost, but it was impossible to read the data at one o'clock. Wait a few days, read the data inside and then talk about dynamic loading and dynamic patching techniques. Today, talk about simple, can be used in software design immediately, inter-module communication technology-Unified Messaging.

The Unified Messaging model was first inspired by UT's Wacos SSI. It's a good communication model, allowing the communication between modules to be unified into queue traffic, and physically, the modules may be in different entities in various networks, or different processes, threads. Remember that will debug the core network program, on the board is not what debugging environment, in addition to Windshell (with Cshell), there is no support. We then loaded the software with GDB to the target machine (diskless workstation) and started testing. Some people do not understand, this is not what ah! The reality is that the value of large-scale system embedded development, can win the room space, equipment and board card is always scarce, at the time of the situation, we three or four people can be divided into a set of equipment. Wacos_ssi Queue communication Technology, so that we can make the target machine function plate, and only need a very small amount of modification, and the actual system of the main control board to communicate with the test, the efficiency of the promotion goes without saying.

Later, brother in Nortel when the TIPC agreement, as if e///and IBM churn out of things. Idea, and Wacos SSI very close. The difference is that Wacos SSI uses an IP address in the header, while TIPC is a custom node address, and therefore contains an additional node address and an address translation process between specific networks. Another difference is that Wacos SSI considers the difference between remote node communication and local communication, and transmits the message entity only for remote communication, while local is the pass-through identity (Handle) for quick completion. TIPC did not describe this level of programming problems, and therefore in the application of engineering practice.

Today, UT is gone, and Nortel is gone. Especially UT, more than 10 years later, the elder brother especially misses that period, and my that team. Helpless, elder brother is Bane, with likes of company phase Gram. Many outsiders say UT is not good, a small well-informed, but the eyes of the elder brother, that many software development team, the combat effectiveness is not worse than Huawei. Said brother do the net Guancheng domain switch, only 10 people, and Huawei is dozens of people, several times ah, the final market performance is still equal. Of course, I still quite admire Huawei's, their things really do beautiful, maintenance interface humanization, unlike ours, a lot of things to command line to achieve. But we also have the feature that the architecture is doing so well that the customer's needs are always quickly realized, and basically 0 risk to the existing functionality. Oh, it is said that many people died of gas!

There are three major contributors to this:

• Wacos SSI;
• State machine;
• Data-driven models.

State machine code, has been in last night's memory leaks in the link provided, interested can be downloaded or used in favorite places, elder brother only hope that it has more opportunities to play the value.

Well, Wacos SSI is ranked first! Yes, Wacos SSI's message communication makes our systems very flexible, with little or no complex coupling between modules and modules. Think about the recruitment requirements of those companies now, what multi-tasking multithreaded programming ability, proficient in what signal volume and synchronization technology, brother want to cry, this is our software level, always ready to play dead himself. Brother do the program, only consider the CPU has a few thread cores, as for the system has a few process threads, is this decision, and the merge disassembly task, is a minute can change the implementation of the Code. With elder brother to do software, just remember a few points: no matter who you communicate with, you just know his address, and then send a message to him, and you just look at their own queue, the news on the job, no news on the rest. As for sending messages, it is a standard function, and the message encapsulation format is also uniform. As for what semaphores are available in the system library, do not try to use them in the application, or the compiler will use compilation errors to tell you that it is not working.

A bit far away, back to the chase.

The definition of Unified Messaging consists of two parts, message labels, and message headers, as follows:

structstruct  _msg_head_type_{byte_t sysrsvd[8//    struct  _msg_head_ex_type_{zaddr_t srcaddr;zaddr_t dstaddr; word_t msglen;word_t msgId; dword_t srcinst;dword_t dstinst;byte_t msgbuf[1];} PACKED zmsghdrex_t;

The zmsg_t structure is the message label, the application receives, sends the message, all is sends and receives this data structure, as follows:
int Zmsgsend (zmsg_t *msg);
Generally speaking, we should make this message label smaller, because it is too big to copy its content back and forth is CPU time. For example, you can define zaddr_t as a DWORD, which requires only 8 bytes to be defined as word,zhandle_t. But remember the byte alignment, in general, to ensure that the length is a multiple of 4.

The message header is the header format segment of the message content, except for this header, and the rest is the application of the custom Payload section. zmsghdr_t and zmsghdrex_t are essentially the same. This part of the address, is not necessary, only when the message through the network or bus transmission, is necessary, otherwise it can not be restored by the boundary module. For applications where there is no special agreement, the few bytes are meaningless and the content is indeterminate.

Message labels and messages are associated through Msghandle. Thus, when the message is passed locally, msghandle points to a piece of normal memory, and when the message is communicated between local processes, it points to shared memory, and as for the network or a bus pass, the boundary module is responsible for the conversion between local memory data and network data. In this way, minimizing the copy overhead of the actual message body makes message delivery efficient and the detail processing corresponds with transparency.

The address portion of the Wacos SSI is filled with an IP address, and of course it defines a module number to use with this address. The entire communication process is simple, the application only needs to request a queue, and informs SSI, this queue and which destination module number is used. Under normal circumstances, this approach can meet the requirements, but encountered the program module re-planning or special vulgar testing purposes, it is a little too weak. Therefore, brother in the zmsg_t tag completely abandoned the Ip+module address composition, changed to TIPC address mode. However, this also allows the system to maintain a routing table that accomplishes the mapping of specific destination addresses to queues.

The Unified Messaging routing table is defined as follows:

structstruct  z_msgq_addr_type{void *struct  z_msgq_ out_type{zaddr_t addr; zudpaddr_t udpaddr;zqueaddr_t queaddr;} zmsgroute_t;

The routing table entry is first the address, which corresponds to the destination address of the message. Next is the network address and the queue address, which can have either one or both.

• Queue-only Address: Description is a message that is local (or is required to be forwarded by an invisible boundary proxy), and the destination address is the queue owner;
• Network Address only: Description is a remote message, and should be sent directly to the network, without the boundary agent, the destination address is the remote module address;
• Contains two types of address: remote message, the application sent through the queue address into the boundary module, and then sent through the network address, the destination address is the remote module address.

The overall relationship above shows that the relationship between the queue and the address is a one-to-many relationship where messages from multiple addresses may be delivered to the same queue. This makes it exceptionally easy to merge the modules, and of course, when the rules are out of order, the module will be useless in any way. In general, if there is a communication requirement for an IP network, the system needs to create a basic network boundary module. The module itself may not require an address, but only a queue that provides a message aggregation. Of course, in an open network environment, this boundary module may also need to do some security work, such as filtering illegal messages, which can be configured in the module additional source IP address, port or source destination address and other implementations. If the remote does not support zmsg_t work, then the boundary module will need to do a good job of the translation process of the message, the Remote module allocation Map module address. Of course, these are local and do not belong to the routing table content.

Mapping from an address to a real destination queue or network address is a frequent operation and must be highly efficient in design. For systems with very few addresses, such as a total of seven or eight modules, a compact data can be used, simple and without prejudice to efficiency. However, for systems with dozens of or hundreds of addresses, the traversal method is not available. This should be a two-point search, or a balanced binary tree. such as Metro switch, there are ten blocks of sub-function cards, each card has more than 10 modules, the entire system has more than 100 address space, using a two-point search, up to 8 times is enough! This portion of the overhead is completely acceptable compared to the number of instructions in the message-handling function. From another point of view, Unified Messaging makes the program simple and controllable, the system reduces the copy operation of the message, resulting in system efficiency and performance improvement, far greater than the cost of the query routing table.

When the embedded world has unified messaging, what are the multi-threaded development techniques that are of great value? Does the general application developer really need to understand this knowledge?

Standardized module interface--Unified Messaging