CN112422411A

CN112422411A - Message distribution mechanism based on large-scale communication system

Info

Publication number: CN112422411A
Application number: CN202011239101.6A
Authority: CN
Inventors: 熊奥斯; 杨国文
Original assignee: Tianjin Transcend Communication Technology Co ltd
Current assignee: Tianjin Transcend Communication Technology Co ltd
Priority date: 2020-11-09
Filing date: 2020-11-09
Publication date: 2021-02-26

Abstract

The invention relates to the technical field of communication, in particular to a message distribution mechanism based on a large-scale communication system. According to the communication scene among modules of large-scale communication system software, a one-to-one full-duplex pair model, a one-to-one request/reply model, a one-to-many half-duplex broadcast publishing/subscribing model and a one-to-many inquiry/confirmation model are abstracted; according to the communication mode, dividing the transmission mode into interprocess communication of communication in the equipment and tcp communication of communication between the equipment; creating a linux-like operating system socket interface, comprising an nn _ socket ()/nn _ close () interface for creating/closing a model, an nn _ setsocketopt ()/nn _ getsocketopt () interface for setting/acquiring model parameters, a binding model address nn _ bind () interface, an interface for connecting a model nn _ connect (), and an interface for sending/receiving model data nn _ send ()/nm _ recv (); the invention is realized in a state machine mode, and the state machine is excited in an event-driven mode, thereby serializing the program execution process and being easy to debug and maintain.

Description

Message distribution mechanism based on large-scale communication system

Technical Field

The invention relates to the technical field of communication, in particular to a message distribution mechanism based on a large-scale communication system.

Background

At present, large-scale communication system software comprises a large number of two-layer and three-layer communication protocols taking processes as carriers, the protocols have state dependence and time sequence dependence, a plurality of protocols can share a certain system state attribute, and the large-scale communication system software is required to provide a communication model meeting the scene.

The interprocess communication mode comprises a pipeline, a message queue, signals, semaphores, a shared memory and sockets, the single use of the modes can not completely meet the communication requirement of a large-scale communication software system, and the comprehensive use is complicated and the tight coupling is inconvenient for the daily maintenance and the updating of the system.

Pipes, message queues, semaphores, shared memory, and sockets are ways that operating systems provide users with interprocess communication.

Assume that protocol a is maintained by process a, protocol B is maintained by process B, and protocol C is maintained by process C. Protocol a and protocol b are required to be capable of communicating with each other, the message length and the message quantity change in a wide range, and protocol a queries the state of protocol c at regular time.

If the named pipes are used for realizing the scene interprocess communication, although the limit of interprocess homology is overcome, the communication mode still is a half-duplex working mode, and the duplex communication mode must use two pipes, one is used for transmitting data, and the other is used for receiving. The above scenario requires at least four pipelines, and if the protocol for mutual communication increases, the pipelines will also increase by times, which results in serious consumption of system resources and does not meet the requirement of large communication software system for saving and using system resources.

If the scene interprocess communication is realized by using the message queues, the requirement of the protocol expandability of a large-scale communication software system is not met because the total length of all data blocks contained in all the message queues in the system has an upper limit.

The data volume carried by the signal and the semaphore is too small to meet the scene carrying a large amount of message data, and the requirement of large message range change of a large-scale communication software system is not met.

The allocation of the shared memory is based on the page size, even if the communication data volume is several bytes, a memory with the size of 4k must be allocated, and the memory waste is large; and the shared memory does not support data synchronization, and the protocol itself needs to be synchronized by means of semaphores and the like, so that the use complexity is increased. And the requirements of saving resources and easy expansion of a large-scale communication software system are not met.

The socket can realize the scenes, but various communication models are not abstracted to form a uniform programming interface, so that different developers realize the communication scenes in different modes, the use complexity is increased, and the requirement that a large-scale communication software system is easy to expand is not met.

The information disclosed in this background section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

Disclosure of Invention

The invention aims to provide a message distribution mechanism based on a large-scale communication system, so as to solve the technical problems in the prior art.

In order to achieve the purpose, the invention adopts the following technical scheme:

the invention provides a message distribution mechanism based on a large-scale communication system, which comprises an operation interface of a linux-like operation system socket, a protocol model, a transmission mode and an event-driven state machine; wherein the content of the first and second substances,

an operation interface of a linux-like operating system socket comprises an nn _ socket ()/nn _ close () interface for creating/closing a model, an nn _ setsocketopt ()/nn _ getsocketopt () interface for setting/acquiring model parameters, a binding model address nn _ bind () interface, an interface for connecting a model nn _ connect (), and an interface for sending/receiving model data nn _ send ()/nn _ recv ();

a protocol model comprising a one-to-one full duplex pair model, a one-to-one request/reply model, a one-to-many half duplex broadcast publish/subscribe model, and a one-to-many query/confirm model;

a transmission mode, which is divided into inter-process communication of communication in the equipment and tcp communication of communication between the equipment according to the communication mode;

the event-driven state machine is used for layering the implementation of the message distribution library, each layer operates in the mode of the state machine, and the state machine is excited in the mode of an event.

As a preferred technical scheme: an operation interface of a socket of the similar linux operating system, an address of the socket of the similar linux operating system and an address of the similar linux operating system adopt a mode of 'transmission type +//: plus actual address', for example, if the communication between processes is carried out, the operation interface is 'ipc//: test'; if inter-process communication is used, it is "tcp//: 192.168.1.10: 3000".

As a preferred technical solution, the message distribution mechanism based on the large scale communication system uses a pair model, which includes the following steps:

step 1: one end A calls an nn _ socket () interface to create a socket of the message distribution library;

step 2: one end A calls an nn _ bind () interface binding address;

and step 3: one end A calls nn _ send () to send data to the opposite end B, and at the moment, a socket of a message distribution library of the opposite end B is not established;

and 4, step 4: the opposite terminal B calls an nn _ socket () interface to create a socket of the message distribution library;

and 5: the opposite terminal B calls an nn _ connect () interface to connect the address bound by the terminal A;

step 6: the opposite terminal B calls an nn _ recv () interface to receive data;

and 7: the opposite terminal B calls an nn _ send () interface to send data;

and 8: one end A calls an nn _ recv () interface to receive data;

and step 9: one end A calls an nn _ close () interface to close the socket of the message distribution library;

step 10: peer B calls the nn _ close () interface to close the socket of the message distribution library.

As a preferred technical solution, the message distribution mechanism based on the large scale communication system uses a request/reply model, which comprises the following steps:

step 1: the REP _ A terminal calls an nn _ socket () interface to create a socket of the message distribution library;

step 2: the REP _ A terminal calls an nn _ bind () interface binding address;

and step 3: the REQ _ B terminal calls an nn _ socket () interface to create a socket of a message distribution library;

and 4, step 4: the end REQ _ B calls an nn _ connect () interface to be connected to the address bound by the end REP _ A;

and 5: the REQ _ C terminal calls an nn _ socket () interface to create a socket of a message distribution library;

step 6: the REQ _ C terminal calls an nn _ connect () interface to be connected to the address bound by the REP _ A terminal;

and 7: the REQ _ C terminal calls nn _ send () to send data to the REP _ A terminal;

and 8: the REQ _ B terminal calls nn _ send () to send data to the REP _ A terminal;

and step 9: the REP _ A terminal calls an nn _ recv () interface to receive data and can receive data sent by a REQ _ C terminal and a REQ _ B terminal;

step 10: the REP _ A terminal calls an nn _ send () interface to send data;

step 11: the REQ _ B terminal calls an nn _ recv () interface to receive data;

step 12: the REQ _ C end calls an nn _ recv () interface to receive data;

step 13: the REQ _ C end calls an nn _ close () interface to close the socket of the message distribution library;

step 14: the REQ _ B terminal calls an nn _ close () interface to close the socket of the message distribution library;

step 15: the REP _ a terminal calls the nn _ close () interface to close the socket of the message distribution library.

As a preferred technical solution, the message distribution mechanism based on the large scale communication system uses a publish/subscribe model, which includes the following steps:

step 1: the PUB _ A terminal calls an nn _ socket () interface to create a socket of the message distribution library;

step 2: the PUB _ A end calls an nn _ bind () interface binding address;

and step 3: the SUB _ B terminal calls an nn _ socket () interface to create a socket of a message distribution library;

and 4, step 4: the SUB _ B terminal calls an nn _ connect () interface to be connected to the address bound by the PUB _ A terminal;

and 5: the SUB _ C end calls an nn _ socket () interface to create a socket of a message distribution library;

step 6: the SUB _ C terminal calls an nn _ connect () interface to be connected to the address bound by the REP _ A terminal;

and 7: the PUB _ A terminal calls nn _ send () to send data;

and 8: the SUB _ C end calls nn _ recv () to receive data without data;

and step 9: the SUB _ B terminal calls nn _ recv () to receive data without data;

step 10: the PUB _ A terminal calls an nn _ send () interface to send data;

step 11: the SUB _ C terminal calls nn _ recv () to receive data and receives data sent by the PUB _ A terminal;

step 12: the SUB _ B terminal calls nn _ recv () to receive data and receives data sent by the PUB _ A terminal;

step 13: the SUB _ C terminal calls an nn _ close () interface to close the socket of the message distribution library;

step 14: the SUB _ B terminal calls an nn _ close () interface to close the socket of the message distribution library;

step 15: and the PUB _ A terminal calls an nn _ close () interface to close the socket of the message distribution library.

As a preferred technical solution, the message distribution mechanism based on the large scale communication system uses an inquiry/confirmation model, which comprises the following steps:

step 1: the SURV _ A terminal calls an nn _ socket () interface to create a socket of the message distribution library;

step 2: the SURV _ A end calls an nn _ bind () interface binding address;

and step 3: the RESP _ B terminal calls an nn _ socket () interface to create a socket of the message distribution library;

and 4, step 4: the RESP _ B terminal calls an nn _ connect () interface to be connected to the address bound by the SURV _ A terminal;

and 5: the RESP _ C terminal calls an nn _ socket () interface to create a socket of the message distribution library;

step 6: the RESP _ C terminal calls an nn _ connect () interface to be connected to the address bound by the SURV _ A terminal;

and 7: the SURV _ A end calls nn _ send () to send data;

and 8: the RESP _ C terminal calls nn _ recv () to receive data and receives data sent by SURV _ A;

and step 9: the RESP _ C terminal calls nn _ send () to send data;

step 10: the SURV _ A terminal calls an nn _ recv () interface to receive data, and the data are blocked at the time;

step 11: the RESP _ B terminal calls nn _ recv () to receive data and receives data sent by the SURV _ A terminal;

step 12: the RESP _ B terminal calls nn _ send () to send data;

step 13: the SURV _ A terminal calls an nn _ recv () interface to receive data, and the blockage is relieved at the moment;

step 14: the RESP _ C terminal calls an nn _ close () interface to close the socket of the message distribution library;

step 15: the RESP _ B terminal calls an nn _ close () interface to close the socket of the message distribution library;

step 16: the SURV _ A terminal calls an nn _ close () interface to close the socket of the message distribution library.

By adopting the technical scheme, the invention has the following beneficial effects:

the invention abstracts the communication scene between large-scale communication software system protocols into a pair model of direct communication, a publish/subscribe model of subscribing interested events, a request/reply model of both sides responding and an inquiry/confirmation model of investigating the condition of each node, and provides a uniform programming interface for developers, thereby improving the expansibility and easy maintenance of the system.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.

FIG. 1 is a system framework diagram provided by an embodiment of the present invention;

FIG. 2 is a publish/subscribe model provided by an embodiment of the present invention;

FIG. 3 is a pair model provided by an embodiment of the present invention;

FIG. 4 is a request/reply model provided by an embodiment of the present invention;

FIG. 5 is a request/reply model application 1 provided by an embodiment of the present invention;

FIG. 6 is a request/reply model application 2 provided by an embodiment of the present invention;

FIG. 7 is a query/validation model provided by an embodiment of the present invention;

FIG. 8 is a diagram of system calls and event response callbacks provided by an embodiment of the present invention;

fig. 9 is a timing diagram of the initial transmission layer of the first start end of the pair model according to the embodiment of the present invention;

FIG. 10 is a timing diagram illustrating the connection initialization of the first initiator of the pair model according to the embodiment of the present invention;

fig. 11 is a timing diagram of the first boot end detection initialization of the pair model according to the embodiment of the present invention.

Detailed Description

The technical solutions of the present invention will be described clearly and completely with reference to the accompanying drawings, and it should be understood that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The following detailed description of embodiments of the invention refers to the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating the present invention, are given by way of illustration and explanation only, not limitation.

With reference to fig. 1 to 11, the present embodiment provides a message distribution library with a uniform programming interface supporting multiple communication models, including a pair model for direct communication, a publish/subscribe model for subscribing to an event of interest, a request/reply model for both parties to respond, and an inquiry/confirmation model for investigating the condition of each node; the programming interface is similar to a socket API and comprises an nm _ socket ()/nm _ close () interface for creating/closing a model, an nm _ setsocketopt ()/nm _ getsocketopt () interface for setting/acquiring model parameters, a binding model address nm _ bind () interface, an interface for connecting a model nm _ connect (), and an interface for sending/receiving model data nm _ send ()/nm _ recv ().

In this embodiment, the basis of communication of each node in the model is a socket programming interface provided by linux, and the node is switched between different states of the node from model creation, to binding connection, to duplex communication, and finally to model closing. Obviously, a state machine is a suitable scheme for enabling node communication.

The implementation uses epoll technology to realize multiplexing of data transmission and reception of the nodes.

The large-scale communication system software concerns kernel mode events such as network card state or routing state, and the requirement that the kernel mode sends the events to the user mode can be basically met by using a netlink technology. The triggering of the kernel events of the large-scale communication system software has a great quantity of concurrent characteristics, so that kernel tasks for issuing the events are busy, and the events received by the user mode daemon process which concerns the events can be out of order, so that data errors are caused. The invention adapts to and modifies the kernel netlink event distribution flow, creates a kernel task and a global message linked list, adds the event message to be distributed by the kernel into the global message linked list, and then executes the specific event distribution work by the created kernel task.

Specifically, the present embodiment divides the message distribution mechanism system into six large functional modules, including utility packets (utils), protocol layers (protocols), transport layers (transports), connection layers (core), state machines (fsm), and thread pools, as shown in fig. 1. The utilis kit includes a list, queue, hash, mutex, atomic, and the like; the protocol layer implementation comprises a pair protocol model, a req/rep protocol model, a pub/sub protocol model and a surfey protocol model, and the virtual function implementation in the nn _ sock base interface is completed according to the initialization model example input by a user; the transport communication layer realizes communication types including interprocess and tcp types, and completes the realization of virtual functions in the nn _ epbase interface; core is a connection layer between the transport code, the protocol code and other codes and is responsible for communication among all layers; the state machine maintains the state to operate correctly between the connection, binding and acceptance states and the disconnection states of the other side; the thread pool provides threads for each protocol task to run.

First, the implementation of each model of the protocol layer is described in detail. Assume that protocol a is maintained by process a, protocol B is maintained by process B, and protocol C is maintained by process C.

It is now required that the protocols a and b can communicate with each other and that the message length and message amount vary widely. The invention thus abstracts the pair model, which is a simple one-to-one duplex communication model, as shown in fig. 3.

Protocol a is now required to rely on some status _ b of protocol b, and protocol a continues to execute after acquiring the status value of protocol b. The invention abstracts a request/reply model (response model), the response model creates stateless service for the request of a user, a client sends the request, a server receives the request, performs some processing and returns a response, as shown in fig. 4; if the protocol a obtains the state value status _ b of the protocol b and depends on the state value status _ c of the protocol c, the subsequent execution flow of the protocol a is determined according to the result calculated by the status _ b and the status _ c, and the subsequent execution flow can be realized by a topological diagram formed by a response model and shown in fig. 5; if the protocol a depends on the status _ b and the status _ c and also depends on the status value status _ d of the protocol d (when the protocol d is started, the protocol b and the protocol c exist, the protocol a depends only on the protocol d; when the protocol d is not started, the protocol a depends only on the protocol b and the protocol c), the protocol d can be realized by a topological diagram formed by response models as shown in fig. 6, and a higher priority is set for the protocol d.

Protocol b and protocol c are now required to care for interface 1 state status _ if1 and protocol c care for interface 2 state status _ if2 of protocol a. The present invention abstracts the publish/subscribe model, allowing subscribers to subscribe to events of interest to publishers, and when a publisher triggers the event, it will distribute messages like all users subscribing to the event. As shown in fig. 2.

Now, protocol a is required to manage the creation and deletion of the device resource _ dev, and protocol b, protocol c and protocol d are all used. If the protocol a deletes the resource _ dev, the protocol b, the protocol c and the protocol d are all required to stop using the resource _ dev. The protocol a sends out a deletion request and then blocks, and after receiving the protocol b, the protocol c and the protocol d, if a resource _ dev is used, the use is stopped, and success is returned to the protocol a; if not, success is returned directly to protocol a. And after receiving all the responses of sending the deletion requests, the protocol a releases the blockage and starts to delete the resource _ dev. If the protocol d is closed after receiving the deleting request and before the response is not returned to the protocol a, the protocol a waits for the time _ a after receiving the responses of the protocol b and the protocol c, and the protocol a releases the blockage after the time _ a is overtime, and the subsequent deleting process is determined according to whether the returned result fails or not. The present invention abstracts the inquiry/confirmation model (survey model) allowing to check the status of multiple applications in a single request, equivalent to a combination of a publish/subscribe model and a request/reply model, publishing information from one node to multiple nodes, then returning information by each node, which can quickly and easily get the status of multiple systems after one query, and the surveyor has to react within a specified time. As shown in fig. 7.

Next, the implementation of the state machine is detailed. The state machine and the mechanism based on event driving are applied to software, so that the risk of using callback to conceal ring formation can be eliminated, the flow can be called clearly, and the routine maintenance is facilitated.

The system is layered, the function calling mode is adopted from the upper layer to the lower layer (from the root node to the leaf node), and the event issuing mode is adopted from the lower layer to the upper layer (from the leaf node to the root node), as shown in fig. 8. Each layer of the system is provided with a state machine, after the upper layer enters a certain state, the lower layer initialization function is called, and after the lower layer immediately enters the certain state, the initialization of the lower layer is called until the leaf node; after the leaf node executes the relevant program, an event is issued to stimulate state migration of a state machine adjacent to the upper layer, and the adjacent state machine migration may issue an event to stimulate a state machine further on the upper layer until the root node or no state needs to be changed. After the upper-layer state machine is initialized, the migration of the upper-layer state machine is stimulated by depending on the lower-layer release event, and the condition that the upper-layer state machine is nested in the lower-layer state machine is formed. The layering mode of the invention strictly stipulates the function calling direction, clearly distinguishes the states of state machines of all layers and simplifies the relation of all layers of the system.

Taking the case that the pair model firstly creates one end of the pair instance, the whole process is analyzed. A user calls nn _ socket () for the first time to initialize the socket of the linux system, initialize memory management, start a thread pool and other system initialization works; then call nn _ bind () to start running the pair model, which is actually a stimulus state machine, as shown in fig. 9, 10, 11.

Creating an NN _ SOCK structure, and enabling an NN _ SOCK STATE machine to enter an NN _ SOCK _ STATE _ ACTIVE STATE from an NN _ SOCK _ STATE _ INIT STATE;

creating an NN _ EP structure by the NN _ sock, and enabling an NN _ EP STATE machine to enter an NN _ EP _ STATE _ IDLE STATE;

creating an NN _ BIPC structure by NN _ ep, and entering an NN _ BIPC _ STATE _ ACTIVE STATE by an NN _ BIPC _ STATE _ IDLE STATE through an NN _ BIPC _ STATE _ IDLE STATE;

an nn _ usock structure is created by nn _ bipc, which manages the socket allocated by the linux system, is responsible for snooping,

the NN _ USOCK STATE machine enters an NN _ USOCK _ STATE _ starting STATE after the NN _ USOCK _ STATE _ IDLE STATE creates a linux system socket, and then enters the NN _ USOCK _ STATE _ LISTENING after a linux system function is called ();

creating an NN _ AIPC structure by the NN _ bipc, temporarily taking over the NN _ bipc for taking over a connection event, and enabling the NN _ AIPC STATE machine to enter an NN _ AIPC _ STATE _ IDLE STATE;

creating an NN _ USOCK structure by the NN _ aipc, and enabling an NN _ USOCK STATE machine to enter an NN _ USOCK _ STATE _ IDLE STATE;

creating an NN _ SIPC structure by the NN _ aipc for managing a connection event, and entering an NN _ SIPC _ STATE _ IDLE STATE by an NN _ SIPC STATE machine;

creating an NN _ streamhdr structure by the NN _ sipc, wherein the NN _ streamhdr structure is used for exchanging protocol headers, detecting whether the protocols are matched or not, and enabling the NN _ sipc STATE machine to enter an NN _ STREAMHDR _ STATE _ IDLE STATE;

an NN _ pipe structure is established by NN _ sipc and used for receiving and sending messages, sock of NN _ ep is taken over by NN _ pipe, an NN _ sipc STATE machine enters an NN _ pipe _ STATE _ IDLE STATE, an entering direction STATE machine enters an NN _ pipe _ INSTATE _ DEACTIVATED STATE, and an exiting direction STATE machine enters an NN _ pipe _ OUTSTATE _ DEACTIVATED STATE.

Therefore, the initialization of each layer of state machine is basically completed, and when a system socket receiving and sending packet event arrives, an event is issued to a working thread to excite the upper layer of state machine.

Again, utility packets (utils), transport layers (transports), connection layers (core), and thread pools are introduced.

The utility packet contains the basic data structure (list, queue, hash) mutual exclusion and atomic operation (atomic) of the invention, and belongs to the encapsulation of the basic structure.

The invention considers the difference of communication forms and classifies two transmission types, namely interprocess communication and tcp communication. The transmission type of the interprocess communication mode is applied to the local equipment; the transmission type of the tcp communication mode is applied to different devices. The classification of the transmission layer makes the code logic clearer and the use more convenient.

A function list, namely an nn _ sock base structural body, is abstracted uniformly by each model of the protocol layer, and different instances can be instantiated by a user by using different models and are used for sending or receiving messages and setting or acquiring options; the transport layer abstracts a list of functions, the nn _ transport structure, instantiates different instances according to different transport types. These belong to the connection layer.

And the thread pool creates thread numbers according to the model number of the protocol layer, and the thread numbers are used for processing messages of a lower layer object issuing an excitation state machine to an upper layer object. And simultaneously, monitoring the input and output events of the socket or the file in the system through the epoll technology.

Finally, the interface of the linux-like socket of the present invention is briefly introduced. An nn _ socket ()/nn _ close () interface containing a create/close model, an nn _ setsocketopt ()/nn _ getsocketopt () interface that sets/acquires model parameters, a binding model address nn _ bind () interface, an interface that connects the model nn _ connect (), and an interface that sends/receives model data nn _ send ()/nn _ recv ().

The invention simplifies the communication mode among all modules of the large-scale communication software system, unifies the programming interfaces, ensures that the large-scale communication software system is easy to develop and maintain, and saves the development cost.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A message distribution mechanism based on a large scale communication system, characterized by: the system comprises an operation interface of a linux-like operation system socket, a protocol model, a transmission mode and an event-driven state machine; wherein the content of the first and second substances,

2. A message distribution mechanism based on a large scale communication system according to claim 1, characterized in that: the operation interface and the address of the socket of the similar linux operating system also are similar to the address of the linux operating system, and the mode of 'transmission type +//: plus actual address' is adopted.

3. A message distribution mechanism based on large scale communication system according to claim 1, using pair model, characterized in that: comprising the following steps:

step 2: one end A calls an nn _ bind () interface binding address;

and 7: the opposite terminal B calls an nn _ send () interface to send data;

and 8: one end A calls an nn _ recv () interface to receive data;

4. A message distribution mechanism based on large scale communication system according to claim 1, using request/reply model, characterized in that: comprising the following steps:

step 2: the REP _ A terminal calls an nn _ bind () interface binding address;

step 10: the REP _ A terminal calls an nn _ send () interface to send data;

step 11: the REQ _ B terminal calls an nn _ recv () interface to receive data;

step 12: the REQ _ C end calls an nn _ recv () interface to receive data;

5. A message distribution mechanism based on large scale communication system according to claim 1, using publish/subscribe model, characterized by: comprising the following steps:

step 2: the PUB _ A end calls an nn _ bind () interface binding address;

step 6: the SUB _ C terminal calls an nn _ connect () interface to be connected to the bound address of the PUB _ A terminal;

and 7: the PUB _ A terminal calls nn _ send () to send data;

and 8: the SUB _ C end calls nn _ recv () to receive data without data;

step 10: the PUB _ A terminal calls an nn _ send () interface to send data;

6. A message distribution mechanism based on a large scale communication system according to claim 1, using a query/acknowledge model, characterized in that: comprising the following steps:

step 2: the SURV _ A end calls an nn _ bind () interface binding address;

and 7: the SURV _ A end calls nn _ send () to send data;

and step 9: the RESP _ C terminal calls nn _ send () to send data;

step 12: the RESP _ B terminal calls nn _ send () to send data;