Message communication system and method between terminal nodes

Abstract

The invention relates to the field of message communication, in particular to a system and a method for message communication between terminal nodes, which can improve the expandability and usability of the system while ensuring the communication efficiency and real-time performance. The system has the advantages of light weight, high efficiency and low delay, integrates RPC and message queue functions, and is particularly suitable for various embedded intelligent terminal application scenes with limited resources and high communication real-time requirements. The method has the greatest advantages that the expandability of communication between the nodes is realized, after the source node appoints a message publishing or information acquisition interface, the existence or realization condition of the subsequent nodes is not needed to be concerned, and after the subsequent nodes are added, the message subscription and the message feedback can be realized only by realizing related interfaces.

Description

Technical Field

[0001] The present invention relates to the field of message communication, and in particular to a system and method for message communication between terminal nodes. Background Art

[0002] With the development and widespread application of various intelligent terminal devices, the information services provided by terminals are becoming increasingly rich. Accordingly, a simple information service is usually composed of multiple module nodes, and the collaborative processing and message communication between these module nodes become particularly important. In different scenarios, the communication methods and technical choices between module nodes are also different.

[0003] When module nodes are located in the same processor, communication problems are traditionally handled using pipelines, shared memory, message queues, and other methods. The advantages of these methods are high data transmission efficiency and low transmission latency. However, they also have some obvious disadvantages: low development efficiency, deep coupling between nodes, and when the number of nodes is large, the network logical topology becomes very complex and has poor scalability.

[0004] When module nodes are located between different processors, the industry usually uses remote procedure calls (RPC) and message queues to handle communication problems. Typical RPC implementations include Dubbo, Thrift, GRPC, etc. These methods have the following advantages: simple use, high transmission efficiency, and the decoupling of service providers and consumers based on the service registration center. However, the RPC method also has its limitations, such as focusing on point-to-point request replies between nodes, and generally not having message publishing and subscription functions. Representative implementation methods based on message queues include message middleware such as Kafka, RabbitMQ, ActiveMQ, RocketMQ, etc. These methods have the following advantages: information persistence, decoupling of message producers and consumers, and traffic peak elimination. However, for terminal devices, these message middlewares have the following shortcomings: they are "heavy" due to the resource constraints of the operating environment; messages are written to storage devices from the sender to the service center, and consumers then pull messages from the service center. The delay in message transmission between application modules is relatively high, and is not suitable for occasions with high timeliness requirements (such as internal communications in smart cars); the main design purpose is to solve one-way data flow problems such as logging, message publishing, and traffic peak elimination. For needs such as instant request responses, it is often necessary to use various RPC services in addition, which increases the complexity of the communication network between nodes.

[0005] Later, ZeroMQ (ZMQ) was developed. ZeroMQ (ZMQ) is a lightweight message framework library that simply encapsulates and expands traditional sockets, and implements basic communication modes such as request-response, publish-subscribe, push-pull, and dedicated peer-to-peer. ZMQ has the following advantages: maintaining high transmission efficiency, providing better ease of use, high communication efficiency, and good customization flexibility. However, ZMQ also has some disadvantages: it only provides the most basic communication mode, and users need to design and organize the network topology by themselves when using it. The network structure designed for specific applications does not have good versatility and scalability.

[0006] In summary, when processing message communication between terminal nodes, the existing technology has problems such as low development efficiency, high coupling between nodes, complex network logic, high message persistence latency, poor versatility and scalability. Summary of the invention

[0007] In view of this, the present invention provides a system and method for message communication between terminal nodes, which can improve the scalability and usability of the system while ensuring communication efficiency and real-time performance.

[0008] To achieve the above object, the technical solution of the present invention is:

[0009] 1. A message communication system between terminal nodes, characterized in that it includes a bus topology structure and a message communication protocol. The bus topology structure includes a bus service and application nodes, wherein the application nodes are peer-to-peer and are all connected to the bus service. The nodes do not communicate directly, and all messages are forwarded based on the bus service, thereby indirectly realizing communication between any nodes or node groups; the message communication protocol defines the message structure of all data flowing in the bus.

[0010] 2. The system as claimed in claim 1, characterized in that the bus service creates pull mode and publish mode sockets respectively and binds them to specific ports, the pull socket port is responsible for receiving all messages sent by each node, and all data received from the pull socket is pushed outward by the publish socket;

[0011] The application node creates a push mode socket and connects to the pull socket port of the bus service, creates a subscription mode socket and connects to the publish socket port of the bus service; the data stream is generated from the sending node and pushed to the bus service in push or pull mode, and the bus service then publishes the data from the publish socket, and the data is transmitted to the destination node or destination node group that has subscribed to the relevant topic; if there is a message reply requirement, the destination node or destination node group reply message is also forwarded through the bus service and fed back to the original message sending node.

[0012] 3. The system as described in claim 1 or 2 is characterized in that the message structure of the flow data is as follows: each message consists of two parts: a message header and a message body, the message header contains protocol-agreed attributes, and the message body is a user-defined message; the message header contains a message domain, a destination node or destination node group identifier, a source node identifier, a session identifier, and a message locator in sequence.

[0013] 4. The system as claimed in claim 3, characterized in that the message domain defines a sending range enumeration, which can be selected as sending to a specified node E, sending to a specified node group G, and sending to all nodes A;

[0014] The node identifier is used to uniquely identify the actual physical node. Each node has a unique node identifier, which is different from each other. The node group identifier is used to uniquely identify the logical node group. Each node group has a unique node group identifier, which is different from each other. Each node can join multiple node groups by subscription. Correspondingly, when the message domain is E, the destination node identifier indicates the destination node for point-to-point message sending; when the message domain is G, the destination node group identifier indicates the destination node group when one-to-many message is published; when the message domain is A, the message is broadcast to all application nodes connected to the bus.

[0015] The source node identifier indicates the node sending the message;

[0016] The session ID uniquely identifies a request-response process;

[0017] The message locator indicates the registered service or function identifier of the destination node or destination node group for processing the message.

[0018] 5. The system as described in claim 4 is characterized in that a session is defined as a process in which a message is sent from a source node to a destination node or a destination node group, the destination node or the destination node group receives the message, processes it and returns a reply message, and the reply message finally returns to the source node; when the source node only sends but does not expect a message to be returned, the session identifier should always be a specific non-expected reply identifier, and the destination node does not reply after identifying this identifier; when expecting a return, the session identifier is an expected reply identifier, and each request from the same message sending node within the foreseeable time range should have a different session identifier; for the destination node, the original session identifier should remain unchanged when the reply information is returned.

[0019] 6. The system as described in claim 5 is characterized in that after the destination node receives the message, it first matches the corresponding processing service or function based on the message locator. If the match is successful, the message will be handed over to the relevant service or function for processing. If the match fails, it means that the destination node does not currently have the processing capability of this message and the message will be discarded. When the message locator is empty, it specifically refers to a response reply message. At this time, the session identifier retained when the existing request was sent is matched based on the session identifier carried in the return message. If the match is successful, it means that the message is a valid reply to the corresponding request. If the match fails, it means that the message is an invalid reply and is discarded.

[0020] 7. A method for communicating messages between terminal nodes using the system according to claims 1 to 6, characterized in that it comprises the following steps:

[0021] S1, initialize bus service;

[0022] S2, initialize each application node and connect to the bus service;

[0023] S3, the source node constructs a message;

[0024] S4. Optionally, when the source node expects to receive a response message, the source node registers the session identifier in the session pool;

[0025] S5, the source node sends a message to the bus service;

[0026] S6. Optionally, when the source node expects to receive a response message, it synchronously or asynchronously waits for the response message;

[0027] S7, the bus service transfers and sends the message to the destination node or destination node group or all nodes;

[0028] S8, all destination nodes receive and process the message;

[0029] S9. Optionally, when the source node expects to receive a reply message and the destination node also supports replying, the destination node constructs a reply message;

[0030] S10. Optionally, the destination node sends a response message to the bus service;

[0031] S11. Optionally, the bus service forwards the response message to the source node;

[0032] S12. Optionally, the source node matches the session identifier after receiving the response message, and the session pool caches the response message;

[0033] S13. Optionally, the response message triggers a preset monitoring condition, and the source node obtains all response messages and cancels the session identifier in the session pool;

[0034] Among them, when there is only message distribution without message response, all necessary steps are executed; when a response message is expected to be received after message distribution, all necessary steps and optional steps are executed.

[0035] 8. The method according to claim 7, characterized in that initializing each application node and connecting to the bus service further comprises the following steps:

[0036] 1. The application node constructs a session pool, which can be a key-value pair data structure dictionary, where the key is the registered session identifier and the value is the response message set matching the session identifier;

[0037] 2. The application node constructs a processing pool, which can be a key-value pair data structure dictionary, where the key is the registered message locator and the value is the corresponding message processing service or callback function;

[0038] 3. The application node registers the corresponding data processing service in the processing pool;

[0039] 4. The application node creates a subscription mode socket and connects to the publishing mode socket port of the bus service;

[0040] 5. The application node creates a push mode socket and connects to the pull mode socket port of the bus service;

[0041] 6. The application node subscribes to a topic whose message domain is E and whose destination node ID is its own node ID, and is used to receive point-to-point messages sent to itself.

[0042] 7. The application node subscribes to a topic with a message domain of G and a destination node group ID of its own node group ID, and is used to receive messages sent to its node group;

[0043] 8. The application node subscribes to the topic with message domain A to receive all broadcast messages.

[0044] 9. The method according to claim 7 or 8, characterized in that the source node matches the session identifier after receiving the response message, and the session pool caches the response message, and specifically further comprises the steps of:

[0045] 1. The source node receives relevant messages from the subscription mode (Sub) socket;

[0046] 2. Filter out all reply messages based on the message locator being empty;

[0047] 3. If the reply message session identifier has been registered in the session pool, the reply message will be cached in the session pool, otherwise the message will be discarded.

[0048] 10. The method according to claim 9, characterized in that the response message triggers a preset monitoring condition, the source node obtains all response messages and cancels the session identifier in the session pool, and specifically further comprises the steps of:

[0049] 1. When the response message collection status meets the preset conditions, a signal is triggered and the waiting ends;

[0050] 2. The source node obtains all response information and processes it;

[0051] 3. The corresponding session identifier and cache information are removed from the source node session pool, and the session ends.

[0052] Beneficial effects:

[0053] 1. The system of the present invention has the advantages of lightweight, high efficiency, and low latency, and integrates RPC and message queue functions. It is particularly suitable for various embedded intelligent terminal application scenarios with limited resources and high communication real-time requirements. The biggest advantage of the present invention lies in the scalability of communication between nodes. After the source node agrees on the message publishing or information collection interface, it does not need to care about the existence or implementation of subsequent nodes. After the subsequent nodes join, they only need to implement the relevant interfaces to realize message subscription and message feedback.

[0054] 2. The bus structure of the present invention has good scalability, which is conducive to the decoupling of software application modules and nodes; it has both data publishing and subscription and request-response communication modes, and supports point-to-point and one-to-many message interactions between nodes.

[0055] 3. The system of the present invention has low transmission delay and high real-time performance, and is suitable for various application scenarios with high requirements on transmission delay.

[0056] 4. The system of the present invention is lightweight in design and can adapt to various embedded terminal devices with limited resources; the stateless design of the bus service can facilitate distributed deployment and achieve high availability and load balancing.

[0057] 5. The method of the present invention is implemented based on the system of the present invention, and is suitable for various embedded intelligent terminal application scenarios with limited resources and high communication real-time requirements. After the source node agrees on the message release or information collection interface, there is no need to care about the existence or implementation of subsequent nodes. After the subsequent nodes join, they only need to implement the relevant interfaces to realize message subscription and message feedback.

[0058] 6. The method of the present invention combines data publishing and subscription with request-response communication modes, and supports point-to-point and one-to-many message interactions between nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 Schematic diagram of bus topology of the system of the present invention.

[0060] Figure 2 Schematic diagram of the message communication protocol of the system of the present invention.

[0061] Figure 3 It is a schematic diagram of the communication protocol message header definition in an embodiment of the present invention.

[0062] Figure 4 This is a flow chart of the message communication method of the present invention. DETAILED DESCRIPTION

[0063] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0064] The invention provides a message communication system between terminal nodes, including a bus topology structure and a message communication protocol.

[0065] Among them, the bus topology is as follows Figure 1 As shown, the bus topology includes bus services and application nodes, wherein the application nodes are peer-to-peer and are all connected to the bus service. Nodes do not communicate directly with each other, and all messages are forwarded based on the bus service, indirectly realizing communication between any nodes or node groups.

[0066] Specifically, the bus service creates pull mode (Pull) and publish mode (Pub) sockets and binds them to specific ports. The pull socket port is responsible for receiving all messages sent by each node, and all data received from the pull socket is pushed out by the publish socket. The application node creates a push mode (Push) socket and connects to the pull socket port of the bus service, and creates a subscription mode (Sub) socket and connects to the publish socket port of the bus service. The bus structure is as follows: Figure 1 As shown, the data stream is generated from the sending node and pushed to the bus service via the Push or Pull mode. The bus service then publishes the data from the Pub socket, and the data is transmitted to the destination node or destination node group that has subscribed to the relevant topic. If there is a message reply requirement, the destination node or destination node group reply message is also forwarded through the bus service and fed back to the original message sending node.

[0067] The message communication protocol defines the message structure of all data flowing in the bus. Figure 2 As shown, the message structure of all the flow data in the embodiment of the present invention is as follows: each message consists of a message header and a message body. The message header contains the protocol agreed attributes, and the message body is a user-defined message. The message header contains the message domain, the destination node or destination node group identifier, the source node identifier, the session identifier, and the message locator in sequence.

[0068] The message domain defines the sending range enumeration, which can be selected as sending to a specified node (E), sending to a specified node group (G), and sending to all nodes (A).

[0069] The node identifier is used to uniquely identify the actual physical node. Each node has a unique node identifier, which is different from each other. The node group identifier is used to uniquely identify the logical node group. Each node group has a unique node group identifier, which is different from each other. Each node can join multiple node groups through subscription. Correspondingly, when the message domain is E, the destination node identifier indicates the destination node for point-to-point message sending; when the message domain is G, the destination node group identifier indicates the destination node group when one-to-many message is published; when the message domain is A, the message is broadcast to all application nodes connected to the bus.

[0070] The source node ID indicates the node that sends the message.

[0071] The session identifier is a unique identifier for a request-response process; a session is defined as the process of sending a message from the source node to the destination node or destination node group, the destination node or destination node group receiving the message, processing it and returning a response message, and the response message finally returning to the source node. When the source node only sends but does not expect a message to be returned, the session identifier should always be a specific non-expected reply identifier, and the destination node will not reply after recognizing this identifier; when expecting a return, the session identifier is an expected reply identifier, and the same message sending node should have a different session identifier for each request within the expected time range. For the destination node, the original session identifier should remain unchanged when the response information is returned.

[0072] The message locator indicates the registered service or function identifier of the destination node or destination node group for processing messages. After receiving the message, the destination node first matches the corresponding processing service or function based on the message locator. If the match is successful, the message will be handed over to the relevant service or function for processing. If the match fails, it means that the destination node does not currently have the processing capability for this message and the message will be discarded. In particular, when the message locator is empty, it refers specifically to a response reply message. At this time, the session identifier carried in the return message is matched with the session identifier retained when the existing request was sent. If the match is successful, it means that the message is a valid reply to the corresponding request. If the match fails, it means that the message is an invalid reply and is discarded.

[0073] In this embodiment, the message protocol is defined to consist of a 2-frame ZMQ multi-part message, wherein the message header sequentially includes the message domain, the destination node or destination node group identifier, the source node identifier, the session identifier, and the message locator, using the little-endian byte order and single-byte alignment mode, constituting the first frame of the message, which is a protocol agreed attribute; the message body is a custom binary message content, constituting the second frame of the message, which is a user-defined binary content.

[0074] The communication protocol message header of this embodiment is specifically defined as follows: Figure 3 As shown, the specific attributes in the first frame message header are as follows:

[0075] Define the message domain as a 1-byte char type, and the value set is limited to the characters 'E', 'G', and 'A'. Send to a specified node (E), send to a specified node group (G), and send to all nodes (A).

[0076] Define the node identifier as a 2-byte uint16 type.

[0077] The session ID is defined as a 4-byte uint32 type. When the source node is in send-only mode, the session ID is fixed to 0. When expecting a reply, the session ID increases cyclically from 1 to the maximum value of uint32, and returns to 1 after reaching the maximum value. When the destination node recognizes that the source message session ID is 0, it should not respond to the message. If the session ID is not 0 and a response is required after processing, the session ID should be kept unchanged and returned.

[0078] The message locator is defined as a char[] type with a variable byte length. When the byte length is 0, it specifically refers to a reply message.

[0079] Among them, (Domain) represents 1-byte data with the message domain being Domain; (Domain, Dest) represents 3-byte data with the message domain being Domain and the destination node or node group being identified as Dest; (Domain, Dest, Src, Session, Url) represents 9+N-byte data with the message domain being Domain, the destination node or node group being identified as Dest, the source node being identified as Src, the session being identified as Session, and the message locator being Url, where N is the number of bytes of Url data.

[0080] The present invention also provides a method for communicating messages between terminal nodes. Based on the message communication system between terminal nodes of the present invention, communication of message distribution, message reception and message response between nodes is realized. The process is as follows: Figure 4 As shown, the following steps are included:

[0081] S1, initialize bus service;

[0082] S2, initialize each application node and connect to the bus service;

[0083] S3, the source node constructs a message;

[0084] S4. Optionally, when the source node expects to receive a response message, the source node registers the session identifier in the session pool;

[0085] S5, the source node sends a message to the bus service;

[0086] S6. Optionally, when the source node expects to receive a response message, it synchronously or asynchronously waits for the response message;

[0087] S7, the bus service transfers and sends the message to the destination node or destination node group or all nodes;

[0088] S8, all destination nodes receive and process the message;

[0089] S9. Optionally, when the source node expects to receive a reply message and the destination node also supports replying, the destination node constructs a reply message;

[0090] S10. Optionally, the destination node sends a response message to the bus service;

[0091] S11. Optionally, the bus service forwards the response message to the source node;

[0092] S12. Optionally, the source node matches the session identifier after receiving the response message, and the session pool caches the response message;

[0093] S13. Optionally, the response message triggers a preset monitoring condition, and the source node obtains all response messages and cancels the session identifier in the session pool;

[0094] Among them, when there is only message distribution without message response, all necessary steps are executed; when a response message is expected to be received after message distribution, all necessary steps and optional steps are executed.

[0095] Furthermore, the initialization of the bus service specifically includes the steps of:

[0096] 1. The bus service creates a Pub socket and binds it to a specific port.

[0097] 2. The bus service creates a pull mode socket and binds it to a specific port;

[0098] 3. The bus listens to the pull mode socket message and publishes it from the publish mode socket.

[0099] Furthermore, the initialization of each application node and connecting to the bus service, in each application node, specifically includes the steps of:

[0100] 1. The application node constructs a session pool, which can be a key-value data structure dictionary, where the key is the registered session identifier and the value is the response message set matching the session identifier;

[0101] 2. The application node constructs a processing pool, which can be a key-value data structure dictionary, where the key is the registered message locator and the value is the corresponding message processing service or callback function;

[0102] 3. The application node registers the corresponding data processing service in the processing pool;

[0103] 4. The application node creates a subscription mode (Sub) socket and connects to the publishing mode socket port of the bus service;

[0104] 5. The application node creates a push mode socket and connects to the pull mode socket port of the bus service;

[0105] 6. The application node subscribes to a message with a domain of (E), and the destination node is identified by the topic of its own node, which is used to receive point-to-point messages sent to itself;

[0106] 7. The application node subscribes to a message with a domain of (G), and the destination node group identifier is the topic of the node group identifier to which it belongs, and is used to receive messages sent to the node group to which it belongs;

[0107] 8. The application node subscribes to the topic with the message domain (A) to receive all broadcast messages.

[0108] Furthermore, the source node constructs a message, specifically including the steps of:

[0109] 1. Construct the message header, determine the message domain and the destination node or destination node group ID according to the message sending scope, the source node ID is its own node ID, the session ID is a specific ID when only sending data, and the session ID must be globally unique when expecting a reply. The message locator is determined according to the message processing service registered by the receiving object;

[0110] 2. Construct the message body, which is a user-defined message;

[0111] 3. The message header and message body are combined to complete the message construction.

[0112] Furthermore, the registering of the session identifier in the session pool specifically includes the steps of:

[0113] 1. Construct a key-value pair, where the key is the registration session identifier and the value is the response message cache set;

[0114] 2. Store the constructed key-value pair in the session pool;

[0115] Furthermore, the source node sends a message to the bus service, which specifically includes the steps of:

[0116] 1. The source node sends a message to the bus service from the push mode socket;

[0117] 2. The bus service receives the corresponding message from the socket in pull mode.

[0118] Furthermore, synchronously or asynchronously waiting for a response message specifically includes the following steps:

[0119] 1. Set preset conditions to monitor the status of the session pool response message collection;

[0120] 2. The source node waits for all reply messages synchronously or asynchronously.

[0121] Furthermore, the bus service forwards and sends the message to the destination node or destination node group or all nodes, specifically including the steps of:

[0122] 1. The bus service sends all received messages out from the publish mode (Pub) socket;

[0123] 2. Based on the message domain and the destination node or destination node group identifier in the message header, the message is published to all destination nodes that have subscribed to the relevant topic.

[0124] Furthermore, all the destination nodes receive and process the message, which specifically includes the steps of:

[0125] 1. The destination node receives the relevant message from the subscription mode (Sub) socket;

[0126] 2. The destination node parses the message header content and searches for the message processing service or callback function in the processing pool based on the message locator;

[0127] 3. If there is a related message processing service or function, process the message; otherwise, discard the message.

[0128] Furthermore, the destination node constructs a response message, which specifically includes the steps of:

[0129] 1. Construct a message header. The message domain is (E). The destination node identifier is the source node identifier of the message being processed. The source node identifier is the node identifier of the message being processed. The session identifier is the same as the session identifier of the message being processed. The message locator is empty.

[0130] 2. Construct the message body, which is a user-defined message;

[0131] 3. The message header and message body are combined to complete the response message construction.

[0132] Furthermore, the source node matches the session identifier after receiving the response message, and the session pool caches the response message, which specifically includes the steps of:

[0133] 1. The source node receives relevant messages from the subscription mode (Sub) socket;

[0134] 2. Filter out all reply messages based on the message locator being empty;

[0135] 3. If the reply message session identifier has been registered in the session pool, the reply message is cached in the session pool, otherwise the message is discarded;

[0136] Furthermore, the response message triggers a preset monitoring condition, the source node obtains all response messages and cancels the session identifier in the session pool, and specifically includes the steps of:

[0137] 1. When the response message collection status meets the preset conditions, a signal is triggered and the waiting ends;

[0138] 2. The source node obtains all response information and processes it;

[0139] 3. The corresponding session identifier and cache information are removed from the source node session pool, and the session ends.

[0140] In the specific implementation of point-to-point request-reply, the mutual request calling process between nodes is implemented to replace the reliance on the RPC framework in traditional development. Taking node a and node b as an example, the whole process of node a sending a message to node b and node b returning a reply message to node a is described. Assume that the node ID of node a is 1 and the entity ID of node b is 2; the location symbol of node b registration message service is 'or req-rep-demo'. The specific process is as follows:

[0141] S1. Initialize bus service:

[0142] 1. The bus service creates a ZMQ publishing mode (Pub) socket and binds it to a specific port;

[0143] 2. The bus service creates a ZMQ pull mode socket and binds it to a specific port;

[0144] 3. The bus service listens to the pull mode socket message and publishes it from the publish mode socket;

[0145] S2. Initialize each application node and connect to the bus service:

[0146] 1. Nodes a and b construct a session pool, which is a key-value pair Map, where the key is the registered session identifier and the value is the response message set that matches the session identifier;

[0147] 2. Nodes a and b construct a processing pool, which is a key-value pair Map, where the key is the registered message locator and the value is the corresponding message processing service or callback function;

[0148] 3. Register the corresponding data processing service in the processing pool of node b, where the key is 'or req-rep-demo' and the value is the relevant processing service;

[0149] 4. Nodes a and b create ZMQ subscription mode (Sub) sockets and connect to the publishing socket port of the bus service;

[0150] 5. Nodes a and b create ZMQ push mode (Push) sockets and connect to the pull socket port of the bus service;

[0151] 6. Node a subscribes to topic ('E', 1), and node b subscribes to topic ('E', 2) to receive point-to-point messages;

[0152] 7. Nodes a and b subscribe to topic ('A') to receive all broadcast messages.

[0153] S3. Node a constructs the message to be sent:

[0154] 1. Construct the message header according to the information of the destination node b;

[0155] First frame ('E',2,1,1,'or req-rep-demo')

[0156] 2. Construct the message body, which is a user-defined message;

[0157] Second frame 'request-content'

[0158] 3. The session ID of node a is incremented by 1 to ensure that a different value is used in the next request.

[0159] S4. Node a registers the session identifier in the session pool:

[0160] 1. Construct a key-value pair, where the key is the registration session identifier 1 and the value is the response message cache set;

[0161] 2. Store the constructed key-value pair in the session pool.

[0162] S5. Node a sends a message to the bus service:

[0163] 1. Node a sends a message to the bus service from the push mode socket;

[0164] 2. The bus service receives the corresponding message from the socket in pull mode.

[0165] S6. Node a waits for a response message synchronously or asynchronously:

[0166] 1. Set the preset conditions, and end the waiting when the expected number of returned results is greater than or equal to 1, or the waiting time exceeds 2 seconds

[0167] 2. Node a synchronously waits for response information.

[0168] S7, bus service transfers and sends the message to node b:

[0169] 1. The bus service sends the received message out from the Pub socket;

[0170] 2. The message is pushed to the node that subscribes to the ('E',2) topic. Since the node identifier is unique, only node b receives the relevant message.

[0171] S8. Node b receives the message and processes it:

[0172] 1. Node b receives relevant messages from the subscription mode (Sub) socket;

[0173] 2. Node b parses the message header content and searches for the message processing service in the processing pool based on the message locator 'or req-rep-demo';

[0174] 3. Node b has relevant message processing services or callback functions to process the message body 'request-content'.

[0175] S9. Construct a response message:

[0176] 1. Build the message header. When returning, exchange the destination node identifier and source node identifier of the original request message, keep the session identifier unchanged, and leave the message locator empty.

[0177] First frame ('E',1,2,1)

[0178] 2. Construct the message body, which is the user-defined return message.

[0179] Second frame 'response-content'

[0180] S10, node b sends a response message to the bus service:

[0181] 1. Node b sends a message to the bus service from the push mode socket;

[0182] 2. The bus service receives the corresponding message from the socket in pull mode.

[0183] S11, bus service transfers the response message to source node a:

[0184] 1. The bus service sends the received message out from the Pub socket;

[0185] 2. The message is pushed to the node that subscribes to the ('E',1) topic. Since the node identifier is unique, only node a receives the relevant message.

[0186] S12, node a receives the response message and matches the session identifier, and the session pool caches the response message:

[0187] 1. Node a receives relevant messages from the subscription mode (Sub) socket;

[0188] 2. Parse the message header and filter out the response message if the message locator is empty;

[0189] 3. Find the session ID 1 in the session pool and cache the response message in the session pool.

[0190] S13: The response message triggers the preset monitoring condition, and node a obtains all response messages and cancels the session identifier in the session pool:

[0191] 1. The number of results returned when the monitoring condition is triggered is greater than or equal to 1, and the waiting period ends;

[0192] 2. Node a obtains the response message 'response-content' from the session pool based on session identifier 1;

[0193] 3. Node a removes session identifier 1 and the corresponding message cache set from the session pool, and the session ends. In the specific implementation of one-to-many message publishing between nodes, the basic message publishing and subscription applications between nodes are covered. Taking nodes a, b, and c as examples, the entire process of node a publishing messages to nodes b and c is described. Assume that the node entity identifiers of nodes a, b, and c are 1, 2, and 3 respectively, and they have the same node group 1. The node b and c registered message service location symbol is 'or pub-sub-demo'. The specific process is as follows:

[0194] S1. Initialize bus service:

[0195] 1. The bus service creates a ZMQ publishing mode (Pub) socket and binds it to a specific port;

[0196] 2. The bus service creates a ZMQ pull mode socket and binds it to a specific port;

[0197] 3. The bus service listens to the pull mode socket message and publishes it from the publish mode socket.

[0198] S2. Initialize each application node and connect to the bus service:

[0199] 1. Nodes a, b, and c construct a session pool, which is a key-value pair Map, where the key is the registered session identifier and the value is the response message set that matches the session identifier;

[0200] 2. Nodes a, b, and c construct a processing pool, which is a key-value pair Map, where the key is the registered message locator and the value is the corresponding message processing service or callback function;

[0201] 3. Nodes b and c register the corresponding data processing services in the processing pool, where the key is 'or pub-sub-demo' and the value is the relevant processing service;

[0202] 4. Nodes a, b, and c create ZMQ subscription mode (Sub) sockets and connect to the publishing socket port of the bus service;

[0203] 5. Nodes a, b, and c create ZMQ push mode (Push) sockets and connect to the pull socket port of the bus service;

[0204] 6. Node a subscribes to topic ('E', 1), node b subscribes to topic ('E', 2), and node c subscribes to topic ('E', 3) to receive point-to-point messages;

[0205] 7. Nodes a, b, and c subscribe to topic ('G', 1) to receive all messages sent to node group 1;

[0206] 8. Nodes a, b, and c subscribe to topic ('A') to receive all broadcast messages.

[0207] S3. Node a constructs the message to be sent:

[0208] 1. Build the message header, construct the message domain and destination node group ID according to the destination node group 1, do not accept replies, and the session ID is fixed to 0;

[0209] First frame ('G',1,1,0,' or pub-sub-demo')

[0210] 2. Construct the message body, which is a user-defined message;

[0211] Second frame 'publish-content'

[0212] S4. Node a sends a message to the bus service:

[0213] 1. Node a sends a message to the bus service from the push mode socket;

[0214] 2. The bus service receives the corresponding message from the socket in pull mode.

[0215] S5. The bus service transfers and sends the message to nodes a, b, and c:

[0216] 1. The bus service sends the received message out from the Pub socket;

[0217] 2. The message is pushed to the nodes subscribed to the ('G',1) topic, i.e., all member nodes a, b, and c of node group 1.

[0218] S6. Nodes a, b, and c receive the message and process it:

[0219] 1. Nodes a, b, and c receive relevant messages from the subscription mode (Sub) socket;

[0220] 2. Nodes a, b, and c parse the message header content and search for the message processing service in the processing pool based on the message locator 'or pub-sub-demo';

[0221] 3. Node a does not have any related processing service with the message locator of 'or pub-sub-demo', so the message is discarded;

[0222] 4. Nodes b and c have related processing services to process the message body 'publish-content'.

[0223] In the specific implementation of one-to-many request-reply between nodes, it is a combination and extension of the point-to-point request-reply implementation and the one-to-many message publishing implementation. Based on the one-to-many message publishing and subscription application, it supports feedback information collection and is suitable for searching and discovering between nodes, confirming the status of node devices, and synchronous information collection of sensor nodes. Taking nodes a, b, and c as examples, the whole process of node a sending messages to all nodes and nodes a, b, and c returning response messages to node a is described. Assume that the entity identifiers of nodes a, b, and c are 1, 2, and 3 respectively, and all register the message processing service with the positioning symbol 'or req-rep-multi-demo'.

[0224] S1. Initialize bus service:

[0225] 1. The bus service creates a ZMQ publishing mode (Pub) socket and binds it to a specific port;

[0226] 2. The bus service creates a ZMQ pull mode socket and binds it to a specific port;

[0227] 3. The bus service listens to the pull mode socket message and publishes it from the publish mode socket.

[0228] S2. Initialize each application node and connect to the bus service:

[0229] 1. Nodes a, b, and c construct a session pool, which is a key-value pair Map, where the key is the registered session identifier and the value is the response message set that matches the session identifier;

[0230] 2. Nodes a, b, and c construct a processing pool, which is a key-value pair Map, where the key is the registered message locator and the value is the corresponding message processing service or callback function;

[0231] 3. Nodes a, b, and c register the corresponding data processing services in the processing pool, where the key is 'or req-rep-multi-demo' and the value is the relevant processing service;

[0232] 4. Nodes a, b, and c create ZMQ subscription mode (Sub) sockets and connect to the publishing mode socket port of the bus service;

[0233] 5. Nodes a, b, and c create ZMQ push mode (Push) sockets and connect to the pull mode socket port of the bus service;

[0234] 6. Node a subscribes to topic ('E', 1), node b subscribes to topic ('E', 2), and node c subscribes to topic ('E', 3) to receive point-to-point messages;

[0235] 7. Nodes a, b, and c subscribe to topic ('A') to receive all broadcast messages.

[0236] S3. Node a constructs the message to be sent:

[0237] 1. Build the message header according to the sending range;

[0238] First frame ('A',0,1,1,'or req-rep-multi-demo')

[0239] 2. Construct the message body, which is a user-defined message;

[0240] Second frame 'request-content'

[0241] 3. The session ID of node a is incremented by 1 to ensure that a different value is used in the next request.

[0242] S4. Node a registers the session identifier in the session pool:

[0243] 1. Construct a key-value pair, where the key is the registration session identifier 1 and the value is the response message cache set;

[0244] 2. Store the constructed key-value pair in the session pool.

[0245] S5. Node a sends a message to the bus service:

[0246] 1. Node a sends a message to the bus service from the push mode socket;

[0247] 2. The bus service receives the corresponding message from the socket in pull mode.

[0248] S6. Node a waits for a response message synchronously or asynchronously:

[0249] 1. Set the preset condition and end the waiting time when the expected waiting time exceeds 2 seconds;

[0250] 2. Node a synchronously waits for response information.

[0251] S7, bus service transfers and sends messages to nodes a, b, c:

[0252] 1. The bus service sends the received message out from the Pub socket;

[0253] 2. The message is pushed to the nodes that subscribe to the topic ('A'), so all nodes receive the relevant message.

[0254] S8. Nodes a, b, and c receive the message and process it:

[0255] 1. Nodes a, b, and c receive relevant messages from the subscription mode (Sub) socket;

[0256] 2. Nodes a, b, and c parse the message header content and search for the message processing service in the processing pool based on the message locator 'or req-rep-multi-demo';

[0257] 3. Nodes a, b, and c all have relevant message processing services or callback functions to process the message body 'request-content';

[0258] S9. Nodes a, b, and c construct response messages respectively:

[0259] 1. Construct a message header, with the message domain as E, the destination node identifier as the source node identifier of the original request message, the source node identifier as its own node identifier, the session identifier as unchanged, and the message locator as empty;

[0260] 2. Construct the message body, which is the user-defined return message.

[0261] Node a first frame ('E', 1, 1, 1), second frame 'response-content-a'

[0262] Node b first frame ('E',1,2,1), second frame 'response-content-b'

[0263] Node c first frame ('E',1,3,1), second frame 'response-content-c'

[0264] S10, nodes a, b, c send a response message to the bus service:

[0265] 1. Nodes a, b, and c send messages to the bus service from the push mode socket;

[0266] 2. The bus service receives the corresponding message from the socket in pull mode.

[0267] S11, bus service transfers the response message to source node a:

[0268] 1. The bus service sends the received message out from the Pub socket;

[0269] 2. The message is pushed to the node subscribed to the ('E',1) topic. Since the node identifier is unique, only node a receives the relevant message.

[0270] S12, node a receives the response message and matches the session identifier, and the session pool caches the response message:

[0271] 1. Node a receives relevant messages from the subscription mode (Sub) socket;

[0272] 2. Parse the message header and filter out the response message if the message locator is empty;

[0273] 3. Find the session ID 1 in the session pool and cache the response message in the session pool.

[0274] S13: The response message triggers the preset monitoring condition, and node a obtains all response messages and cancels the session identifier in the session pool:

[0275] 1. If the waiting time for triggering monitoring conditions exceeds 2 seconds, the waiting time ends;

[0276] 2. Node a obtains the response message set returned by all nodes from the session pool based on session identifier 1;

[0277] ['response-content-a','response-content-b','response-content-c']

[0278] 3. When the session ends, node a removes session identifier 1 and the corresponding message cache set from the session pool.

[0279] In summary, the above are only preferred embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A message communication system between terminal nodes, characterized in that: It includes a bus topology structure and a message communication protocol. The bus topology structure includes bus services and application nodes. The application nodes are peer-to-peer and are all connected to the bus service. The nodes do not communicate directly with each other. All messages are forwarded based on the bus service, indirectly realizing communication between any nodes or node groups. The message communication protocol defines the message structure of all data flowing in the bus.

2. The system according to claim 1, characterized in that The bus service creates pull mode and publish mode sockets respectively and binds them to specific ports. The pull socket port is responsible for receiving all messages sent by each node, and all data received from the pull socket is pushed out by the publish socket. The application node creates a push mode socket and connects to the pull socket port of the bus service, creates a subscription mode socket and connects to the publish socket port of the bus service; The data stream is generated from the sending node and pushed to the bus service via push or pull mode. The bus service then publishes the data from the publishing socket, and the data is transmitted to the destination node or destination node group that has subscribed to the relevant topic. If there is a message reply requirement, the destination node or destination node group reply message is also forwarded through the bus service and fed back to the original message sending node.

3. The system according to claim 1 or 2, characterized in that: The message structure of the flow data is as follows: each message consists of two parts: a message header and a message body. The message header contains the protocol-agreed attributes, and the message body is a user-defined message. The message header contains the message domain, destination node or destination node group identifier, source node identifier, session identifier, and message locator in sequence.

4. The system according to claim 3, characterized in that The message domain defines the sending range enumeration, which can be selected as sending to a specified node E, sending to a specified node group G, or sending to all nodes A; The node identifier is used to uniquely identify the actual physical node. Each node has a unique node identifier, which is different from each other. The node group identifier is used to uniquely identify the logical node group. Each node group has a unique node group identifier, which is different from each other. Each node can join multiple node groups by subscription. Correspondingly, when the message domain is E, the destination node identifier indicates the destination node for point-to-point message sending; when the message domain is G, the destination node group identifier indicates the destination node group when one-to-many message is published; when the message domain is A, the message is broadcast to all application nodes connected to the bus. The source node identifier indicates the node sending the message; The session ID uniquely identifies a request-response process; The message locator indicates the registered service or function identifier of the destination node or destination node group for processing the message.

5. The system according to claim 4, characterized in that A session is defined as the process of sending a message from a source node to a destination node or a destination node group, the destination node or the destination node group receiving the message, processing it and returning a reply message, and the reply message finally returning to the source node. When the source node only sends a message but does not expect a message to be returned, the session identifier should always be a specific non-expected reply identifier, and the destination node will not reply after recognizing this identifier. When expecting a reply, the session identifier is an expected reply identifier, and each request from the same message sending node within the expected time range should have a different session identifier. For the destination node, the original session identifier should be kept unchanged when the response information is returned.

6. The system according to claim 5, characterized in that After receiving the message, the destination node first matches the corresponding processing service or function based on the message locator. If the match is successful, the message will be handed over to the relevant service or function for processing. If the match fails, it means that the destination node does not currently have the ability to process this message and the message will be discarded. When the message locator is empty, it specifically refers to a response reply message. At this time, the session identifier carried in the return message is matched with the session identifier retained when the existing request was sent. If the match is successful, it means that the message is a valid response to the corresponding request. If the match fails, it means that the message is an invalid response and is discarded.

7. A method for message communication between terminal nodes using the system as claimed in claims 1-6, characterized in that: The steps include: S1, initialize bus service; S2, initialize each application node and connect to the bus service; S3, the source node constructs a message; S4. Optionally, when the source node expects to receive a response message, the source node registers the session identifier in the session pool; S5, the source node sends a message to the bus service; S6. Optionally, when the source node expects to receive a response message, it synchronously or asynchronously waits for the response message; S7, the bus service transfers and sends the message to the destination node or destination node group or all nodes; S8, all destination nodes receive and process the message; S9. Optionally, when the source node expects to receive a reply message and the destination node also supports replying, the destination node constructs a reply message; S10. Optionally, the destination node sends a response message to the bus service; S11. Optionally, the bus service forwards the response message to the source node; S12. Optionally, the source node matches the session identifier after receiving the response message, and the session pool caches the response message; S13. Optionally, the response message triggers a preset monitoring condition, and the source node obtains all response messages and cancels the session identifier in the session pool; Among them, when there is only message distribution without message response, all necessary steps are executed; when a response message is expected to be received after message distribution, all necessary steps and optional steps are executed.

8. The method according to claim 7, characterized in that Initialize each application node and connect to the bus service, which specifically includes the following steps:

1. The application node constructs a session pool, which can be a key-value pair data structure dictionary, where the key is the registered session identifier and the value is the response message set matching the session identifier; 2. The application node constructs a processing pool, which can be a key-value pair data structure dictionary, where the key is the registered message locator and the value is the corresponding message processing service or callback function; 3. The application node registers the corresponding data processing service in the processing pool; 4. The application node creates a subscription mode socket and connects to the publishing mode socket port of the bus service; 5. The application node creates a push mode socket and connects to the pull mode socket port of the bus service; 6. The application node subscribes to a topic whose message domain is E and whose destination node ID is its own node ID, and is used to receive point-to-point messages sent to itself.

7. The application node subscribes to a topic with a message domain of G and a destination node group ID of its own node group ID, and is used to receive messages sent to its node group; 8. The application node subscribes to the topic with message domain A to receive all broadcast messages.

9. The method according to claim 7 or 8, characterized in that After receiving the response message, the source node matches the session identifier, and the session pool caches the response message, which specifically includes the steps of:

1. The source node receives relevant messages from the subscription mode (Sub) socket; 2. Filter out all reply messages based on the message locator being empty; 3. If the reply message session identifier has been registered in the session pool, the reply message will be cached in the session pool, otherwise the message will be discarded.

10. The method according to claim 9, characterized in that The response message triggers a preset monitoring condition, and the source node obtains all response messages and cancels the session identifier in the session pool, which specifically includes the steps of:

1. When the response message collection status meets the preset conditions, a signal is triggered and the waiting ends; 2. The source node obtains all response information and processes it; 3. The corresponding session identifier and cache information are removed from the source node session pool, and the session ends.

Images