WO2025227992A1 - 节点间的建链方法、节点及分布式系统 - Google Patents
节点间的建链方法、节点及分布式系统Info
- Publication number
- WO2025227992A1 WO2025227992A1 PCT/CN2025/084091 CN2025084091W WO2025227992A1 WO 2025227992 A1 WO2025227992 A1 WO 2025227992A1 CN 2025084091 W CN2025084091 W CN 2025084091W WO 2025227992 A1 WO2025227992 A1 WO 2025227992A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- information
- topic
- message
- topics
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
Definitions
- This application relates to the field of distributed communication technology, and in particular to a method for establishing links between nodes, nodes, and a distributed system.
- vehicles can achieve functions such as vehicle start-up, route planning, autonomous driving, and automatic parking through interconnection between multiple communication nodes (such as cockpit domain controllers (CDC), intelligent driving domain controllers (such as mobile data centers (MDC)), vehicle domain controllers (VDC), microcontroller units (MCUs), etc.).
- CDC cockpit domain controllers
- MDC mobile data centers
- VDC vehicle domain controllers
- MCUs microcontroller units
- This application provides a method for establishing links between nodes, a node, and a distributed system, which can improve the efficiency and reliability of establishing links between communication nodes, and can save on memory, computing, and other overhead.
- a method for establishing a chain between nodes includes: a first node receiving first information from a second node, wherein the first information includes M (M is a positive integer) bits, and the M bits respectively represent the availability status of M different first topics related to the second node; the first node determining whether a second topic related to the first node matches the aforementioned different first topics; when the second topic related to the first node matches at least one of the M different first topics, the first node sending a Simple Endpoint Discovery Protocol (SEDP) message to the second node, wherein the SEDP carries information about a second topic that matches at least one of the aforementioned M different first topics.
- SEDP Simple Endpoint Discovery Protocol
- the first piece of information could be a compact bit sequence.
- the first node and the second node are communication nodes in a distributed system. Both nodes generate their respective bit sequences following the same topic-bit mapping rules.
- the distributed system can include, but is not limited to, a data distribution service (DDS) distributed system.
- DDS data distribution service
- the solution provided in the first aspect above involves matching related topics between communication nodes in a distributed system based on small, compact bit sequences to determine whether a publish-subscribe relationship needs to be established between them. This reduces the false alarm rate and enables rapid discovery between communication nodes without affecting the length of messages in the SPDP phase.
- matching based on compact bit sequences allows communication nodes to selectively send SEDP messages, avoiding unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without a publish-subscribe relationship. It also shortens the time required for establishing a link between communication nodes, enabling rapid link establishment.
- the first node receives the first information from the second node during the SPDP phase. Based on this, the first node can determine whether a publish-subscribe relationship needs to be established with the second node, and then selectively send SEDP messages during the subsequent SEDP phase. This avoids unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without a publish-subscribe relationship, and can shorten the time required for establishing a link between communication nodes, achieving rapid link establishment.
- the aforementioned first information is carried in an SPDP message. Based on this, the standard SPDP message can be reused to send the first information, improving the compatibility, simplicity, and convenience of the solution.
- this application does not limit the specific method by which the second node sends the first information to the first node.
- the second node may also send the first information to the first node through a single message.
- the first node stores second information, which includes N (N is a positive integer) bits. These N bits represent the availability status of N different second topics related to the first node.
- the first node determines whether the N second topics related to it match the different first topics by comparing the availability status of the different second topics with the availability status of the different first topics to determine if there is a matching topic among the different second topics. Based on this, it is possible to conveniently, accurately, and quickly determine whether a publish-subscribe relationship needs to be established between communication nodes.
- the first node can determine whether there is a topic that matches a different first topic by performing a bit comparison between the second information and the second information, comparing whether the availability status of different second topics in the second information is the same as the availability status of different first topics in the first information. If there is, it is determined that the first node has a topic that matches the second node; otherwise, it is determined that the first node does not have a topic that matches the second node.
- mapping rules between the topic and bits for the second information and the first information are consistent. Based on this, the accuracy of the result obtained by the first node in determining whether there is a matching topic between the first and second information can be guaranteed, thereby ensuring the accuracy of the subsequent decision on whether to establish a chain based on this result.
- the aforementioned first node is applied to a robot operating system (ROS) scenario.
- the method further includes: the first node calling a file parsing interface to parse a formatted file to generate second information, where the formatted file includes information on N different second topics related to the first node. Based on this, by pre-parsing the file to generate the second information, the problem of not being able to obtain communication node-related topic information before node discovery can be avoided in some special scenarios such as ROS-like interface scenarios, thus preventing accurate discovery and link establishment.
- ROS robot operating system
- the method further includes: a first node receiving third information from a second node, wherein the third information includes K (K is a positive integer) bits, which represent the availability status of at least one third topic related to the second node; the first node determining whether a fourth topic related to the first node matches the at least one third topic according to a Bloom filter strategy; and when the fourth topic related to the first node matches at least one of the at least one third topic, the first node sending an SEDP message to the second node.
- K is a positive integer
- the accuracy of the results obtained by the communication nodes in determining whether there are matching topics can be further improved, and the consumption of memory and computing resources can be further reduced, shortening the time required for link establishment between communication nodes and achieving fast link establishment between communication nodes.
- the third information is a Bloom table, which includes multiple bits that represent the availability status of multiple unknown topics related to the second node (such as a third topic for which no corresponding bit was found in the compact bit sequence).
- the first node and the second node when their respective Bloom tables, they can follow the same Bloom mapping mechanism so that each communication node can quickly and accurately match topics.
- the aforementioned first node is applied to a ROS scenario.
- the method further includes: the first node calling a file parsing interface to parse a formatted file to determine the fourth topic related to the first node, wherein the formatted file includes information about the fourth topic related to the first node. Based on this, relevant topic information can be generated by parsing the file in advance, avoiding the problem of not being able to obtain relevant topic information about the communicating node before node discovery in some special scenarios such as ROS-like interface scenarios, thus preventing accurate discovery and link establishment.
- the formatted file mentioned above includes any one or more of the following file types: XML file, JSON file, YAML file.
- the aforementioned third information can be carried in the same message or in different messages as the first information. Based on this, the flexibility of information transmission methods can be improved, as well as the compatibility, simplicity, and convenience of the solution.
- the method further includes: when the first node's related second topic does not match any of the M different first topics, and the first node's related fourth topic does not match any of the at least one third topic, the first node records the identifier of the second node in the mismatch list; upon receiving an SPDP message from the second node, the first node performs a first preset parsing on the SPDP message according to the mismatch list. Based on this, unnecessary consumption of memory and computing resources caused by parsing messages from communication nodes without publish-subscribe relationships can be avoided, further shortening the time required for establishing a link between communication nodes and achieving rapid link establishment between communication nodes.
- the above method further includes: the first node sending a fourth message to the second node, wherein the fourth message indicates that the second topic related to the first node does not match any of the M different first topics.
- the peer node can promptly learn that there is no publish-subscribe relationship between the two communication nodes, allowing the peer device to reduce memory and computing resource consumption by not sending SPDP messages to the first node, thereby shortening the time required for link establishment between communication nodes and achieving rapid link establishment between communication nodes.
- the method further includes: a first node receiving fifth information from a second node, wherein the fifth information includes a first identifier and information representing a newly added topic related to the second node, the first identifier indicating that the information carried in the fifth information represents a newly added topic related to the second node; the first node, based on the first identifier, determines whether a second topic and a fourth topic related to the first node match the newly added topic; when the second topic related to the first node matches the newly added topic or the fourth topic related to the first node matches the newly added topic, the first node sends an SEDP message to the second node. Based on this, it can be ensured that even when a module (or topic) is added, rapid link establishment between communication nodes can still be achieved with a low false alarm rate.
- the method further includes: the first node deleting the identifier of the second node from the maintained mismatch list. Based on this, the impact on business functions caused by the first node not performing the first preset resolution on second nodes with publish-subscribe relationships due to the failure to promptly delete the identifier of the second node from the mismatch list can be avoided.
- the method further includes: the first node parsing the SPDP message from the second node to identify the first protocol version supported by the second node; when the first protocol version is higher than or equal to the second protocol version supported by the first node, the first node sends SPDP and SEDP messages to the second node based on the second protocol version; when the first protocol version is lower than the second protocol version supported by the first node, the first node sends SPDP and SEDP messages to the second node based on the first protocol version. Based on this, it is possible to support smooth subsequent communication even when software versions between communication nodes are mismatched, through version adaptation.
- a method for establishing a link between nodes includes: a second node generating first information, wherein the first information includes M (M is a positive integer) bits, the M bits respectively representing the availability status of M different first topics related to the second node; the second node sending the first information to the first node, the first information being used by the first node to determine whether to send an SEDP message to the second node, and being used by the first node to determine the topic information carried in the SEDP message when sending the SEDP message to the second node.
- M is a positive integer
- the solution provided in the second aspect above involves matching related topics between communication nodes in a distributed system based on small, compact bit sequences to determine whether a publish-subscribe relationship needs to be established between them. This reduces the false alarm rate and enables rapid discovery between communication nodes without affecting the message length in the SPDP phase. Furthermore, matching based on compact bit sequences allows communication nodes to selectively send SEDP messages, avoiding unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without a publish-subscribe relationship. It also shortens the time required for establishing a link between communication nodes, enabling rapid link establishment.
- the second node sends the aforementioned first information to the first node during the SPDP phase. Based on this, the first node can determine whether a publish-subscribe relationship needs to be established with the second node based on the first information, and then selectively send SEDP messages during the subsequent SEDP phase. This avoids unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without a publish-subscribe relationship, and can shorten the time required for establishing a link between communication nodes, achieving rapid link establishment.
- the aforementioned first information is carried in an SPDP message. Based on this, the standard SPDP message can be reused to send the first information, improving the compatibility, simplicity, and convenience of the solution.
- this application does not limit the specific method by which the second node sends the first information to the first node.
- the second node may also send the first information to the first node through a single message.
- the aforementioned second node is applied to a ROS scenario.
- the second node generates first information by calling a file parsing interface to parse a formatted file and generate the first information.
- the formatted file includes information about different first topics related to the second node. Based on this, by pre-parsing the file to generate the second information, the problem of not being able to obtain relevant topic information about the communication node before node discovery can be avoided in some special scenarios such as ROS-like interface scenarios, which could lead to inaccurate discovery and link establishment.
- the above method further includes: the second node sending third information to the first node, wherein the third information is used by the first node to determine whether to send an SEDP message to the second node, and the third information includes K (K is a positive integer) bits, which represent the availability status of at least one third topic related to the second node.
- K is a positive integer
- the aforementioned second node is applied to a ROS scenario.
- the method further includes: the second node calling a file parsing interface to parse a formatted file to determine at least one third topic related to the second node, wherein the formatted file includes information about the third topic related to the second node. Based on this, by combining the first and third information, the accuracy of the result obtained by the first node in determining whether there is a matching topic can be further improved, and the consumption of memory and computing resources can be further reduced, shortening the time required for establishing a link between communication nodes and achieving rapid link establishment between communication nodes.
- the formatted file mentioned above includes any one or more of the following file types: XML file, JSON file, YAML file.
- the aforementioned third information can be carried in the same message or in different messages as the first information. Based on this, the flexibility of information transmission methods can be improved, as well as the compatibility, simplicity, and convenience of the solution.
- the above method further includes: the second node receiving fourth information from the first node, wherein the fourth information indicates that the second topic related to the first node does not match any of the aforementioned different first topics; the second node recording sixth information based on the fourth information, wherein the sixth information indicates that the second topic related to the first node does not match any of the aforementioned M different first topics, and the fourth topic related to the first node does not match any of the aforementioned at least one third topic.
- the second node promptly learns that there is no publish-subscribe relationship with the first node, facilitating the peer device to reduce memory and computing resource consumption by not sending SPDP messages to the first node, thereby shortening the time required for link establishment between communication nodes and achieving rapid link establishment between communication nodes.
- the above method further includes: the second node sending fifth information to the first node, wherein the fifth information is used by the first node to determine whether to send an SEDP message to the second node, and the fifth information includes a first identifier and information used to characterize a newly added topic related to the second node.
- the first identifier is used to indicate that the information carried in the fifth information characterizes a newly added topic related to the second node. Based on this, it can be guaranteed that even when a module (or topic) is added, fast link establishment between communication nodes can still be achieved with a low false alarm rate.
- the method further includes: when the second node sends an SPDP message to the first node, it carries information representing a first protocol version supported by the second node, which is used by the first node to determine the protocol version used when sending SPDP and SEDP messages to the second node. Based on this, it is possible to support smooth subsequent communication even when software versions between communication nodes are mismatched, through version adaptation.
- a communication node comprising: a memory for storing computer program instructions and data; and a processor for executing the computer program instructions to support a server in implementing the method as described in any possible implementation of the first or second aspect.
- a distributed communication system comprising: a first node and a second node, wherein the first node is configured to implement the method as described in any possible implementation of the first aspect, and the second node is configured to implement the method as described in any possible implementation of the second aspect.
- a computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the method as described in any possible implementation of the first or second aspect.
- a computer program product comprising instructions, which, when run on a computer, causes the computer to implement the method as described in any possible implementation of the first or second aspect.
- a chip system comprising processing circuitry and a storage medium storing computer program instructions; when executed by the processor, the computer program instructions implement the method as described in any possible implementation of the first or second aspect.
- the chip system may be composed of chips or may include chips and other discrete devices.
- Figure 1 is a schematic diagram of a centralized system architecture
- Figure 2 is a schematic diagram of a distributed system architecture
- FIG. 3 is a schematic diagram of the operating logic of a DDS provided in an embodiment of this application.
- Figure 4 is a schematic diagram of an automatic discovery process between communication nodes based on DDS provided in an embodiment of this application;
- Figure 5 is a schematic diagram of a Bloom table rule provided in an embodiment of this application.
- Figure 6 is a diagram of an intelligent vehicle system architecture provided in an embodiment of this application.
- Figure 7 is a schematic diagram of the framework of a communication node provided in an embodiment of this application.
- Figure 8 is a flowchart of a method for establishing a link between nodes according to an embodiment of this application.
- Figure 9 is a schematic diagram of a compact bit sequence generation process provided in an embodiment of this application.
- Figure 10 is a schematic diagram of the discovery and link establishment process between communication nodes in a distributed system according to an embodiment of this application;
- Figure 11 is a schematic diagram of a process for discovering and establishing links between communication nodes based on a mismatch list according to an embodiment of this application;
- Figure 12 is a schematic diagram of a new topic processing procedure provided in an embodiment of this application.
- Figure 13 is a schematic diagram of a protocol version adaptation process provided in an embodiment of this application.
- Figure 14 is a flowchart of another method for establishing a link between nodes provided in an embodiment of this application.
- Figure 15 is a schematic diagram of another process for discovery and link establishment between communication nodes in a distributed system provided in an embodiment of this application;
- Figure 16 is a schematic diagram of another process for discovering and establishing links between communication nodes based on a mismatch list provided in an embodiment of this application;
- Figure 17 is a schematic diagram of another processing procedure for adding a new topic provided in an embodiment of this application.
- first and second are used only to distinguish different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects.
- the described object is a "field”
- the ordinal numbers before “field” in “first field” and “second field” do not limit the position or order of the "fields.”
- First” and “second” do not limit whether the "fields” they modify are in the same message, nor do they restrict the order of "first field” and “second field.”
- the described object is a "level,” then the ordinal numbers before “level” in “first level” and “second level” do not limit the priority of the "levels.”
- the quantity of described objects is not limited by ordinal numbers and can be one or more; for example, in “first device,” the number of "devices” can be one or more.
- objects modified by different prefixes can be the same or different.
- first device and second device can be devices of the same type or different types.
- first information and second information can be information with the same content or information with different content.
- connection can be a direct connection or an indirect connection; in addition, it can refer to an electrical connection or a communication connection; for example, the connection of two electrical components A and B can refer to A and B being directly connected, or it can refer to A and B being indirectly connected through other electrical components or connection media, or it can refer to A and B being indirectly connected through other communication devices or communication media, as long as it enables communication between A and B.
- Centralized architectures include, but are not limited to, robot operating systems (ROS)1, and scalable service-oriented middleware over IP (SOME/IP) in a centralized model.
- Distributed architectures include, but are not limited to, robot operating systems (ROS2), DDS, and decentralized SOME/IP.
- Figure 1 shows a schematic diagram of a centralized system architecture.
- this centralized architecture includes a management node (master) and multiple communication nodes (Figure 1 uses sender node 1, sender node 2, receiver node 1, and receiver node 2 as an example).
- the management node (master) is used to store the node information of multiple communication nodes, such as address information. During the process of establishing links between multiple communication nodes, they need to rely on the management node (master) to provide each other with node information.
- sending node 1 needs to obtain the address information of receiving node 1 from the management node (master), and receiving node 1 needs to obtain the address information of sending node 1 from the management node (master).
- sending node 1 and receiving node 1 can discover the successful connection establishment and proceed with subsequent message communication to implement the corresponding business function.
- sending node 2 needs to obtain the address information of receiving node 2 from the management node (master), and receiving node 2 needs to obtain the address information of sending node 2 from the management node (master). Using the address information obtained from the management node (master), sending node 2 and receiving node 2 can discover the successful connection establishment and proceed with subsequent message communication to implement the corresponding business function.
- the management node (master) needs to store the node information of four communication nodes.
- the management node (master) needs to store the node information of four communication nodes.
- the establishment of links between multiple communication nodes is heavily dependent on the management node (master). If the management node (master) fails, it will affect the normal operation of all communication nodes in the entire centralized architecture.
- Figure 2 shows a schematic diagram of a distributed system architecture.
- the distributed architecture includes multiple communication nodes ( Figure 2 takes sending node 1, sending node 2, receiving node 1, and receiving node 2 as examples).
- Figure 2 can discover communication nodes that can be paired (such as establishing a chain) and store the node information of the communication nodes that can be paired with them.
- sending node 1 needs to send its own node information to sending node 2, receiving node 1, and receiving node 2, respectively, and receive and store the node information of sending node 2, receiving node 1, and receiving node 2, respectively.
- sending node 2, receiving node 1, and receiving node 2 also need to perform similar operations, which will not be elaborated here. That is to say, in the centralized architecture shown in Figure 2, each communication node needs to send node information 3 times, and the entire architecture needs to send node information a total of 12 times. Furthermore, each communication node needs to store 4 pieces of node information (including its own node information), and the entire architecture needs to store a total of 16 pieces of node information. Therefore, the system's computational and storage overhead is also under great pressure. Especially when there are many communication nodes in a distributed system, the pressure on computational and storage overhead will be even greater.
- DDS data distribution service
- OMG Object Management Organization
- HLA High-Level Architecture
- CORBA Common Object Request Broker Architecture
- DDS adopts a publish/subscribe architecture, emphasizes a data-centric approach, and can provide rich Quality of Service (QoS) policies, ensuring real-time, reliable, and flexible data distribution, thus meeting the needs of various distributed real-time communication applications.
- QoS Quality of Service
- the distributed architecture includes participant 1 and participant 2 (i.e., communication nodes). In practical applications, the distributed architecture may include multiple other participants (i.e., communication nodes), without specific limitations.
- Figure 3 only uses participant 1 and participant 2 as examples. Participant 1 and participant 2 each have at least one publisher and/or at least one subscriber deployed. That is, any participant can act as both a publisher and a subscriber, without specific limitations.
- Figure 3 only uses participant 1 as a publisher and participant 2 as a subscriber as examples; in practical applications, no specific limitations are imposed.
- the publisher includes one or more data writer modules
- the subscriber includes one or more data reader modules.
- Each data writer and data reader module corresponds to a topic name and a QoS policy, respectively.
- the publisher and subscriber can automatically discover and pair up based on whether their topic names and QoS policies match (e.g., whether they are identical or have overlap).
- This established communication link facilitates message communication and enables corresponding business functions.
- different data writer modules/data reader modules may have the same or different topic names/QoS policies. Therefore, there may be multiple data reader modules that can be paired with a single data writer module, and vice versa, providing significant flexibility for message communication.
- automatic discovery between communicating nodes based on DDS can include the following two stages:
- SPDP Simple Participant Discovery Protocol
- Figure 4 illustrates a schematic diagram of an automatic discovery process between communication nodes based on DDS provided in an embodiment of this application.
- node A i.e., participant A
- node B i.e., participant B
- node B sends its node information to node A.
- node A can discover node B and save its node information to its local database.
- Node B can discover node A and save its node information to its local database.
- SEDP Simple Endpoint Discovery Protocol
- node A sends information about data writing module 1 to node B.
- node B sends information about data reading module 1 to node A.
- node A can discover data reading module 1 and save its information to its local database, and node B can discover data writing module 1 and save its information to its local database.
- the discovery between data writing module 1 and data reading module 1 is complete.
- other data writing modules/data reading modules in node A can discover each other with other data writing modules/data reading modules in node B through a similar process.
- each participant needs to send SPDP messages to all other participants, and each participant needs to send module information to all other participants via SEDP messages for each data writer/data reader module. Furthermore, each participant needs to store the received information in order to understand the publish/subscribe nodes in the entire system and their respective data writer/data reader modules, making it easier to find a node that matches them.
- P the number of participants in the system
- E the total number of data writers/data readers in each participant
- at least P(P-1) interactions between participants are required in the SPDP phase and at least 2EP(P-1) interactions between participants are required in the SEDP phase.
- both the SPDP and SEDP phases involve “complete graph” message interactions and full message storage, which leads to a huge consumption of computing and storage resources.
- the driving systems of intelligent vehicles (hereinafter referred to as "vehicles") often adopt a distributed architecture, such as a distributed architecture based on DDS.
- a distributed architecture such as a distributed architecture based on DDS.
- the vehicle driving system centrally utilizes technologies such as computers, modern sensing, information fusion, communication, artificial intelligence, and automatic control.
- Multiple communication nodes in the driving system can establish links with each other to achieve functions such as vehicle start-up, route planning, autonomous driving, automatic parking, lane keeping assist (LKA), automatic emergency braking (AEB), forward collision warning (FCW), lane departure warning (LDW), and emergency lane keeping (ELK).
- the upgrade of intelligent driving levels may involve changes in communication models.
- This requires new communication nodes to be able to quickly establish connections without affecting safe operation. For example, when a user gets into the car and starts up, all software undergoes a cold start, and all communication nodes need to begin establishing connections. If the connection establishment time is too long, it will affect the cold start time, resulting in a slow boot speed for the user. Therefore, the aforementioned problems in establishing connections between communication nodes will become increasingly significant.
- a Bloom filter To shorten the time required for establishing links between communication nodes and reduce the consumption of memory and computing resources, one possible approach is to introduce a Bloom filter during the automatic discovery process of communication nodes.
- the main principle of a Bloom filter is to filter data by checking whether an element is in a set, such as using a Uniform Resource Locator (URL) for deduplication, spam detection, and duplicate element detection, in order to avoid unnecessary consumption of memory and computing resources and unnecessary increases in latency caused by processing duplicate elements.
- URL Uniform Resource Locator
- node A When discovering and establishing connections between communication nodes in a distributed system based on Bloom filters, node A can map the topics corresponding to all data writing modules (DataWriter) and data reading modules (DataReader) in node A into a bit array (also called a Bloom table) according to certain rules or algorithms (such as Bloom table rules or algorithms) and send it to node B.
- a bit array also called a Bloom table
- rules or algorithms such as Bloom table rules or algorithms
- Figure 5 uses the topic mapping bits 1, 4, and 7 corresponding to term 1 and the topic mapping bits 3, 4, and 8 corresponding to term 2 as examples. Based on this, node B can use the same rules or algorithms to reverse the calculation based on the fields with a state of 1 in the bit array sent by node A to determine whether the topic corresponding to the field exists, and then determine whether the corresponding topic matches the topic of its own node.
- the communication process between communication nodes based on Bloom table rules or algorithms may be as follows:
- node A can send the generated Bloom table to other nodes (including node B) via the SPDP message.
- other nodes including node B
- node B determines that it has a topic that matches node A's topic, it can execute "Send Endpoint information (SSEDP message) to the remote participant" to send an SEDP message containing information about the matching topic to node A; otherwise (i.e., node B has no matching topic with node A's topic), node B will not send an SEDP message to node A. Based on this, selective sending of SEDP messages can be achieved, shortening the time required for establishing connections between communication nodes and reducing the consumption of memory and computing resources.
- SEDP message Send Endpoint information
- Bloom table lengths are typically large (e.g., 516 bytes). For a false positive rate of 0.1%, the Bloom table length might be 480 bytes. Especially as autonomous driving evolves towards L3, L4, and even L5 levels, the Bloom table length could potentially exceed 1500 bytes. This will significantly increase the length of SPDP messages, leading to increased consumption of memory and computing resources.
- this application provides a link establishment method between nodes. This method maximizes the saving of memory and computational overhead during both the communication node discovery phase and the discovery phase of the data writing/reading modules within each communication node.
- a communication node (denoted as the second node) can send a compact bit sequence to other communication nodes (denoted as the first node) in the distributed system during the communication node discovery phase. Different bits of the compact bit sequence represent the availability status of the topics corresponding to the second node.
- the compact bit sequence includes M bits (M is a positive integer), and the M bits represent the availability status of M different topics related to the second node.
- the first node compares it with its local compact bit sequence to determine whether there is a matching topic. If there is, it enters the discovery phase of the data writing module/data reading module in the subsequent communication node. If not, it does not conduct subsequent communication, and can also not process or simply process the SPDP message received from the second node later.
- a communication node can be understood as a collection of sub-modules capable of implementing a certain type of business task or function, or a collection of sub-modules capable of implementing a specific business task or function.
- a communication node may include at least one data writer module and/or at least one data reader module.
- these multiple sub-modules can typically be used to provide the same or related support for the same type of business task or function.
- the topic corresponding to the communication node can be used to characterize the business task or function supported by the communication node.
- the topic format described in this application embodiment may include, but is not limited to, any one or more of the following: business task name/business function name, message type, publisher-subscriber relationship, logical channel, isolation group, etc., to facilitate multiple communication nodes in deciding whether to establish a publish-subscribe relationship with each other.
- communication nodes can decide whether to establish a publish-subscribe relationship based on whether their topics match. If the topics of the communication nodes match, a publish-subscribe relationship is established; if the topics of the communication nodes do not match, a publish-subscribe relationship is not established.
- Theme matching includes, but is not limited to, identical themes and related themes. For example, if the theme of a communication node is a business task name/business function name, communication nodes can determine whether their themes match based on whether their business task names/business function names are the same; if the theme of a communication node is a message type, communication nodes can determine whether their themes match based on whether their message types are the same, or they can determine whether their themes match based on whether their message types are related, where related message types mean belonging to the same business task/business function category; if the theme of a communication node is a list of publisher-subscriber relationships, communication nodes can determine whether their themes match based on whether their lists include each other's relationship pairs; if the theme of a communication node is a logical channel, communication nodes can determine whether their themes match based on whether they share the same logical channel; if the theme of a communication node is an isolated group, communication nodes can determine whether their themes match based on whether they are in the same group.
- the distributed architecture described in this application embodiment can refer to a distributed system in any application field, such as including but not limited to the fields of intelligent driving, intelligent robots, Internet of Things, smart healthcare, smart education, smart cities, railway dispatching, etc., and this application embodiment does not limit it.
- the distributed architecture described in this application embodiment can refer to any distributed architecture that completes the establishment of a link between communication nodes through the discovery phase of the communication node and the discovery phase of the data writing module/data reading module in each communication node, such as including but not limited to the DDS distributed architecture, the decentralized SOME/IP distributed architecture, the ROS2 distributed architecture, etc., and this application embodiment does not limit it.
- the intelligent vehicle system may include a telematics box (T-Box), a distributed gateway (such as an MCU), and multiple domain controllers with different functions implemented by multiple operating systems on the same hardware platform, such as intelligent driving domain controller, instrument domain controller, cockpit domain controller, chassis domain controller, powertrain domain controller, body domain controller, etc.
- T-Box telematics box
- MCU distributed gateway
- multiple domain controllers with different functions implemented by multiple operating systems on the same hardware platform, such as intelligent driving domain controller, instrument domain controller, cockpit domain controller, chassis domain controller, powertrain domain controller, body domain controller, etc.
- Figure 6 uses intelligent driving domain controller, cockpit domain controller, and chassis domain controller as examples).
- Multiple domain controllers can achieve hardware integration and computing power sharing of on-board computing units while realizing secure isolation between different domains, and effectively reduce the overall vehicle cost.
- the T-Box communicates with multiple domain controllers and distributed gateways via Ethernet.
- domain controllers, or distributed gateways there are also instances of shared memory communication within the operating system of applications, cross-chip communication (in cases with multiple internal chips), and communication between isolated regions.
- the intelligent driving domain controller is primarily used to provide autonomous driving perception and decision-making services, such as receiving, processing, and judging image information, processing and calculating data, navigation and route planning, and rapid judgment and decision-making in real-time situations.
- the intelligent driving domain needs to handle algorithms at the perception, decision-making, and control levels, placing the highest demands on both the hardware and software of the domain controller.
- the instrument cluster domain controller primarily provides instrument-based or interface-based displays of vehicle speed, engine speed, drive energy, etc.
- the cockpit domain controller primarily controls various electronic information system functions in the vehicle's intelligent cockpit, such as the central control system, in-vehicle infotainment system, head-up display, seat system, instrument cluster, rearview mirror system, driving behavior monitoring system, and navigation system.
- the chassis domain controller primarily controls the vehicle's driving behavior and posture, and its functions include, but are not limited to, brake system management, transmission system management, driving system management, steering system management, vehicle speed sensor management, vehicle posture sensor management, air suspension system management, and airbag system management.
- the powertrain domain controller is primarily used to control the vehicle's powertrain components, optimize vehicle performance, and ensure vehicle power safety. This includes functions such as engine management, transmission management, battery management, power distribution management, emissions management, speed limiting management, and fuel and energy saving management.
- the body domain controller is mainly used to control various body functions, including but not limited to the control of headlights, taillights, interior lights, door locks, windows, sunroof, wipers, power tailgate, smart key, air conditioning, antennas, and gateway communication.
- T-Boxes, domain controllers, or distributed gateways can be deployed with applications to implement various business tasks or functions. Multiple nodes can collaborate based on distributed communication to perform the same or related business tasks or functions. The collaboration between T-Boxes, domain controllers, and distributed gateways depends on the correct establishment of links between them, which in turn relies on automatic discovery.
- Figure 6 is only an example of an intelligent vehicle system architecture.
- the embodiments of this application do not limit the specific components included in the intelligent vehicle system architecture.
- the distributed gateway shown in Figure 6 can also work with other domain controllers or T-Boxes to implement the same or related business tasks or business functions.
- a vehicle in this application embodiment is a broad concept.
- a vehicle in this application embodiment can be a means of transportation (such as a car, bus, subway, high-speed rail, motorcycle, flying car, train, etc.), an industrial vehicle (such as a forklift, trailer, tractor, etc.), an engineering vehicle (such as an excavator, bulldozer, crane, etc.), an agricultural equipment (such as a lawnmower, harvester, etc.), an amusement ride, a toy vehicle, a boat, hovercraft, submarine, airplane, helicopter, etc.
- This application embodiment does not limit the specific type, form, or function of the vehicle.
- solutions provided in this application can also be applied to other vehicles, such as water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment.
- Figure 7 shows a schematic diagram of the framework of a communication node provided in an embodiment of this application, taking a communication node in a DDS distributed architecture as an example.
- the communication node may include an interface layer, a remote procedure call (RPC) module, a QoS module, a resource management module, a data transceiver module, an SPDP module, a SEDP module, and a channel abstraction module.
- RPC remote procedure call
- the interface layer is called by the upper-layer application and performs node creation, message sending, message receiving, QoS configuration, etc. based on DDS communication.
- the RPC module can be simply understood as a tool used to connect the interface layer and the data sending and receiving module to send and receive messages back and forth. For example, when the local end requests a service from the remote end, such as data calculation, the remote end will process the data according to the request and reply with the calculated data to the local end. In this process, RPC can be used to handle the packaging of the data.
- the QoS module can be configured through an interface, relies on the resource management module to cache and manage data, and relies on the data sending and receiving module to implement some QoS functions, such as sending and receiving Heartbeat, Acknack and other messages when reliable QoS is enabled.
- the resource management module is mainly used to manage channel resources, cache resources, etc.
- Channel resources include, but are not limited to, User Datagram Protocol (UDP) channel resources and shared memory resources; cache resources are used to cache data sent and received by the data transceiver module.
- UDP User Datagram Protocol
- cache resources are used to cache data sent and received by the data transceiver module.
- the sending end relies on a cache to store sent data packets so that if the other end informs that it has not received the data, it can directly retrieve the data from the cache and resend it.
- the data transceiver module is primarily responsible for sending and receiving business and control messages.
- Data messages are the data that users want to send and receive, while control messages include SPDP and SEDP messages that are automatically discovered and need to be transmitted, as well as management messages such as Heartbeat, AckNack, and Gap.
- control messages include SPDP and SEDP messages that are automatically discovered and need to be transmitted, as well as management messages such as Heartbeat, AckNack, and Gap.
- management messages such as Heartbeat, AckNack, and Gap.
- the SPDP module is mainly used for communication during the SPDP phase, so that communication nodes in the system can discover each other.
- the SEDP module is mainly used for communication during the SEDP phase, so that the data writing modules/data reading modules in the various communication nodes of the system can discover each other.
- the channel abstraction module is mainly used to abstract various low-level channels such as UDP, TCP, and shared memory.
- the scheme provided in this application embodiment can introduce a compact bit list (referred to as improvement 1) in the automatic discovery phase.
- the compact bit list includes multiple bits, each representing the availability status of multiple different topics related to the communication node, with one bit representing the availability status of a single topic related to the communication node.
- the peer node compares it with its local compact bit list to determine if there is a matching topic to decide whether a publish-subscribe relationship needs to be established. If so, the process proceeds to the discovery phase of the data writing/reading module in the subsequent communication node; otherwise, no further communication occurs. Furthermore, when SPDP messages are subsequently received from the communication node, no processing or simple processing can be performed.
- the length of the compact bit sequence can be guaranteed to remain within a certain size (e.g., 50 bytes). Therefore, it will not affect the message length in the SPDP stage and can reduce the false alarm rate, enabling rapid discovery between communication nodes.
- selective subsequent message sending based on the comparison results of the compact bit sequence can reduce the consumption of memory and computing resources, and shorten the time required for link establishment between communication nodes, enabling rapid link establishment between communication nodes. That is, based on this, problems 2 and 3 mentioned above in the traditional Bloom filter scheme can be solved.
- the scheme provided in this application embodiment can also introduce a useless remote list for recording mismatched remote nodes during the automatic discovery phase.
- the identifiers of remote nodes i.e., irrelevant remote nodes
- improvement point 2 the list of remote nodes that do not have a topic matching the local node after compact bit sequence comparison are recorded in the list (referred to as improvement point 2).
- improvement point 2 the list of remote nodes that do not have a topic matching the local node after compact bit sequence comparison.
- improvement point 2 Based on this, if an SPDP message is received again from the remote node, no processing or simple processing can be performed. In this way, selective message processing can be performed in the SPDP phase, which can reduce the consumption of memory and computing resources on the one hand, and shorten the time required for establishing a link between communication nodes on the other hand, thus achieving fast link establishment between communication nodes. That is, based on this, the above-mentioned problem 1 of the traditional Bloom filter scheme can be solved.
- the scheme provided in this application embodiment can also introduce a traditional Bloom filter based on the compact bit sequence introduced in the automatic discovery phase, such as introducing a Bloom bitlist, where multiple bits included in the Bloom bitlist represent the availability status of multiple unknown topics related to the communication node (such as topics for which no corresponding bit position is found in the compact bit sequence) (denoted as improvement point 3).
- the peer node can use the traditional Bloom filtering method to determine whether there is a topic that can be matched between the two to determine whether a publish-subscribe relationship needs to be established between the two; if so, it enters the discovery phase of the data writing module/data reading module in the subsequent communication node; if not, no further communication is performed. Judging whether to establish a publish-subscribe relationship based on the compact bit sequence and the Bloom bitlist can reduce the consumption of memory and computing resources, shorten the time required for establishing a link between communication nodes, and achieve fast link establishment between communication nodes, while further reducing the false alarm rate. That is, based on this, the above-mentioned problem 3 of the traditional Bloom filter scheme can be solved.
- the scheme provided in this application embodiment can also introduce a version adaptation mechanism in the automatic discovery phase (denoted as improvement point 4).
- the local node can determine the DDS protocol version supported by the remote node based on the version identifier (such as Version Label) carried in the SPDP message from the remote node, so as to perform version adaptation when its version is inconsistent with the DDS protocol version supported by the local node, so that the two ends can smoothly carry out the subsequent communication process.
- version identifier such as Version Label
- the local node can determine the DDS protocol version supported by the remote node based on whether the SPDP message from the remote node carries preset information (such as whether it carries a compact bit sequence), so as to perform version adaptation when its version is inconsistent with the DDS protocol version supported by the local node, so that the two ends can smoothly carry out the subsequent communication process. Based on this, compatibility can still be maintained even when the DDS protocol versions supported by the two communication nodes are inconsistent, so as to smoothly carry out the subsequent communication process. That is, based on this, the above-mentioned problem 4 of the traditional Bloom filter scheme can be solved.
- the solution provided in this application embodiment can also introduce a new identifier (denoted as improvement point 5) in the automatic discovery phase.
- a new identifier (denoted as improvement point 5)
- the local node can send the topic (or new topic) of the new module and the new identifier to the remote node.
- the new identifier is used to indicate that the remote node's sending of this new message involves the topic (or new topic) of the new module.
- the remote node will determine whether a publish-subscribe relationship needs to be established between the two based on the topic carried therein.
- the solution provided in this application can also introduce advance parsing of topic information files during the automatic discovery phase (referred to as improvement point 6).
- improvement point 6 For example, before the participant's data writer/data reader is created, node-related topic information can be obtained in advance by parsing formatted files such as XML, JSON, and YAML files that include node-related topics.
- This supports normal discovery and link establishment between communicating nodes based on compact bit sequences and/or Bloom tables in special scenarios such as ROS-like interface scenarios. That is, based on this, the aforementioned problem 6 of the traditional Bloom filter scheme can be solved.
- Figure 7 shows a schematic diagram of a general communication node framework.
- the first node, the second node, and other communication nodes can all have the functional framework shown in Figure 7.
- improvements to the automatic discovery phase described in Figure 7 are merely examples. In practical applications, the various improvements described above can be freely combined; that is, at least two of the improvements 1-6 can be arbitrarily combined to improve the automatic discovery phase.
- embodiments of this application support the introduction of one or more of the following improvements based on the introduction of a compact bit sequence: overlaying a transmission Bloom table, a list of mismatched remote nodes, a version adaptation mechanism, adding a new identifier, and pre-parsing of topic information files.
- embodiments of this application support the introduction of one or more of the following improvements based on the introduction of a transmission Bloom table: a list of mismatched remote nodes, a version adaptation mechanism, adding a new identifier, and pre-parsing of topic information files.
- Embodiment 1 mainly introduces one or more of the following improvements based on the introduction of a compact bit sequence: superimposed transmission Bloom table, a list of mismatched remote nodes, a version adaptation mechanism, added identifiers, and pre-parsing of topic information files;
- Embodiment 2 mainly introduces one or more of the following improvements based on the introduction of a transmission Bloom table: a list of mismatched remote nodes, a version adaptation mechanism, added identifiers, and pre-parsing of topic information files.
- a communication node (denoted as the second node) can send its own (i.e., the second node's) compact bit sequence to other communication nodes (denoted as the first node) in the system during the automatic discovery SPDP phase.
- the second node's compact bit sequence includes multiple bits, each representing the availability status of multiple different topics related to the communication node, with one bit representing the availability status of a single topic related to the communication node.
- other communication nodes (denoted as the first node) compare it with their local compact bit sequence (i.e., the first node's compact bit sequence) to determine if there is a matching topic, and thus whether to establish a publish-subscribe relationship between them.
- first node and the second node have a matching topic, then the first node and the second node will proceed to the subsequent SEDP phase to discover the data writer and/or data reader modules in the second node that match the topic of the first node, complete the chain establishment, and establish a publish-subscribe relationship.
- the first node and the second node do not have a matching topic, then the first node and the second node will not proceed to the subsequent SEDP phase, such as the first node not sending an SEDP message to the second node.
- Figure 8 illustrates a flowchart of a node-to-node link establishment method provided in this embodiment, using the discovery and link establishment between a first node and a second node as an example.
- the node-to-node link establishment method provided in this embodiment can be implemented based on steps S801-S805:
- the second node generates first information, which includes M bits (M is a positive integer).
- M is a positive integer.
- the M bits represent the available status of M different first topics related to the second node.
- the first topic related to the second node is related to the business tasks or functions that the second node can support.
- the first topic related to the second node can represent the business tasks or functions that the second node can support.
- This application does not limit the specific way the first topic represents the business tasks or functions.
- the first topic can represent the business tasks or functions that the second node can support in any one or more of the following ways: business task name/business function name, message type, relationship between publisher and subscriber, logical channel, isolated group, etc.
- this application does not limit the specific representation form of the business tasks or functions.
- the first topic can represent the business tasks or functions that the second node can support using keywords, identifiers, etc.
- the first information can be a dense bitlist, which consists of multiple bits, each representing the available state of multiple different first topics associated with the second node, and one bit representing the available state of one first topic associated with the second node.
- the first information can be generated by the second node querying a preset information table for application-related topics carried by the second node, and mapping multiple different available first topics related to the second node to corresponding bits according to certain mapping rules based on the query results.
- This can be recorded as single bits in a dense bitlist. For example, if a topic can be found in the preset information table, its corresponding bit position is set to the first preset identifier; if a topic is not found in the preset information table, its corresponding bit position is set to the second preset identifier, or its corresponding bit is not recorded in the dense bitlist.
- the first preset identifier is such as 1, and the second preset identifier is such as 0; or, the first preset identifier is such as 0, and the second preset identifier is such as 1.
- all communication nodes in the distributed system (including the first and second nodes) follow the same mapping rules so that each communication node can quickly and accurately match topics.
- the aforementioned preset information table can be pre-input by the developer to the second node or distributed system.
- the preset information table can include information about all topics related to the application deployed in the vehicle (such as topic names).
- the preset information table can be, but is not limited to, XML files, JSON files, YAML files, etc., containing information about all topics related to the application deployed in the vehicle, without specific limitations.
- the second node can call a file parsing interface to parse a formatted file to generate first information.
- This formatted file includes information about all topics related to the application deployed across the entire system (such as topic names), and therefore also information about M different first topics related to the second node.
- the formatted file may be pre-entered into the second node or the distributed system by the developer.
- the formatted file can be, but is not limited to, any one or more of the following file types: XML files, JSON files, YAML files, etc.
- the formatting may be stored as one file corresponding to one communication node, or it may be stored as one file corresponding to multiple communication nodes (such as all communication nodes in a distributed system). This application embodiment does not limit this.
- the developer can add strings describing the characteristics of the communication nodes in advance to the file describing the communication nodes. In this way, when the communication node calls the file parsing interface, it can look up the relevant topic information in the corresponding file based on the string corresponding to the communication node.
- Figure 9 illustrates a schematic diagram of the generation process of a compact bit sequence provided in an embodiment of this application.
- the second node can parse a formatted file to generate a compact bit sequence 1 (i.e., first information) during application preparation, such as application initialization or node creation.
- the compact bit sequence 1 is generated by mapping multiple different available first topics related to the second node to corresponding bit bits according to the formatted file and following certain mapping rules.
- the second node can normally create the data writer module and/or data reader module.
- the ROS interface does not expose the DDS publish-subscribe model. Instead, it creates and declares publish or subscribe nodes at the topic level. This special mechanism may cause communication nodes to start establishing a chain when they have only obtained a small amount of topic information. In other words, the topic information obtained in ROS-like interface scenarios is not complete.
- the topics related to each communication node in a distributed system are usually pre-written into code or configuration files by the developers (such as pre-written into a preset information table or pre-configured in a formatted file). Based on this, the embodiments of this application generate the first information in advance based on the preset information table or pre-parsed formatted file. Therefore, in ROS-like interface scenarios, the discovery and chain establishment between communication nodes can be successfully performed based on the scheme shown in Figure 8.
- Figure 10 illustrates a discovery and connection establishment process between communication nodes in a distributed system provided by an embodiment of this application, where the first and second information are compact bit lists, and the second node sends the first information to the first node via an SPDP message.
- the second node can generate compact bit list 1 (i.e., the first information) by looking up a table or parsing a formatted file.
- the first node generates second information, which includes N (N is a positive integer) bits.
- the N bits represent the available status of N different second topics related to the first node.
- the second topic related to the first node is related to the business tasks or functions that the first node can support.
- the second topic related to the first node can represent the business tasks or functions that the first node can support.
- This application embodiment does not limit the specific way the second topic represents the business tasks or functions.
- the second topic can represent the business tasks or functions that the first node can support in any one or more of the following ways: business task name/business function name, message type, relationship between publisher and subscriber, logical channel, isolated group, etc.
- this application embodiment does not limit the specific representation form of the business tasks or functions.
- the second topic can represent the business tasks or functions that the first node can support through keywords, identifiers, etc.
- the second information could be a dense bitlist, which consists of multiple bits representing the availability of multiple different second topics associated with the first node, with one bit representing the availability of one second topic associated with the first node.
- the second information can be generated by the first node by querying a preset information table for application-related topics carried by the first node, and based on the query results.
- This information can be recorded as a single bit in a dense bitlist. For instance, if a topic can be found in the preset information table, its corresponding bit position is set to a first preset identifier; if a topic is not found in the preset information table, its corresponding bit position is set to a second preset identifier, or its corresponding bit is not recorded in the dense bitlist.
- the first preset identifier can be 1, and the second preset identifier can be 0; or the first preset identifier can be 0, and the second preset identifier can be 1.
- the aforementioned preset information table can be pre-entered by the developer into the first node or the distributed system.
- the preset information table can include information about all topics related to the application deployed in the vehicle (such as topic names).
- the preset information table can be, but is not limited to, XML files, JSON files, YAML files, etc., containing information about all topics related to the application deployed in the vehicle, without specific limitations.
- the first node can call a file parsing interface to parse a formatted file to generate second information.
- This formatted file includes information about all topics related to the application deployed across the entire system (such as topic names), and therefore also includes N different second topics related to the first node.
- the formatted file may be pre-entered into the first node or the distributed system by the developer.
- the formatted file can be, but is not limited to, any one or more of the following file types: XML files, JSON files, YAML files, etc.
- the first node can generate a compact bit sequence 2 (i.e., the second information) by looking up a table or parsing a formatted file.
- a compact bit sequence 2 i.e., the second information
- the first node can parse a formatted file to generate a compact bit sequence 2 (i.e., the second information).
- This compact bit sequence 2 is generated by mapping multiple different available second topics related to the first node to their corresponding bit positions according to the formatted file and following certain mapping rules.
- the first node can normally create the data writer and/or data reader modules.
- S801 may occur before S802, or it may occur after S802, or it may occur simultaneously with S802.
- S803 The second node sends the first message to the first node.
- the second node sends first information to the first node for the first node to determine whether to send an SEDP message to the second node, and for the first node to determine the subject information carried in the SEDP message when it decides to send an SEDP message to the second node.
- the second node can send the first information to the first node during the SPDP phase.
- the first information can be carried in the SPDP message, as shown in Figure 9, where the second node sends a compact bit sequence 1 (i.e., the first information) to the first node via the SPDP message.
- the first information can also be sent by the second node to the first node separately. This application embodiment does not specifically limit the specific method by which the second node sends the first information.
- the second node can send the first information to the first node through data in the form of submessage (such as DDS submessage) or parameter (such as DDS parameter).
- submessage such as DDS submessage
- parameter such as DDS parameter
- Each submessage typically represents a data type in a DDS (Distributed Data System), such as user data, SPDP, SEDP, HeartBeat, AckNack, and Gap.
- DDS Distributed Data System
- INFO_DST indicates the destination of the message
- INFO_TS indicates the timestamp
- DATA contains specific data information, such as SPDP messages, which store specific information about SPDP, such as user business messages.
- Parameters are typically used to identify various types of information about local nodes, such as domain ID, protocol version number, receive address information, and QoS information. For example, by parsing the parameters of captured packets using network packet analysis software, the specific information they carry can be obtained. The parsing result might look like the following example 2:
- Example 2 the various PIDs within serializedData represent different parameter numbers.
- the first node determines whether the second topic related to the first node matches a different first topic.
- a first node can determine whether a second topic related to the first node matches a different first topic by comparing the second information with the first information.
- a first node can determine whether there exists a topic among the different second topics that matches a different first topic by performing a bit comparison between the second information and the first information. If there is, the first node has a topic that matches the second node; otherwise, the first node does not have a topic that matches the second node. Furthermore, the first node can also determine which of its second topics matches its first topic by performing a bit comparison.
- the first node can perform a bit-by-bit comparison between its local dense bitlist 2 and the dense bitlist 1 received from the second node to determine whether there is a second topic in the dense bitlist 2 that matches the first topic available in the dense bitlist 1, and if there is a matching topic, determine which second topic matches the first topic of the first node.
- mapping rules between topics and bits followed by the second information generated by the first node are consistent with those of the first information generated by the first node. Based on this, the first node can directly compare the second information bit by bit to quickly and accurately determine whether the second topic related to the first node matches different first topics.
- the first node After executing S804, if the second topic related to the first node matches at least one of the M different first topics, the first node executes S805; if the second topic related to the first node does not match any of the M different first topics, the first node does not send an SEDP message to the second node.
- the first node sends an SEDP message to the second node, the SEDP message carrying information about a second topic that matches at least one of the M different first topics.
- the first node shown in Figure 10 can send an SEDP message to the second node when there is a second topic in compact bit sequence 2 that matches the first topic available in compact bit sequence 1.
- the SEDP message carries information about the second topic that matches the first topic of the first node. This information is used for mutual discovery and information transfer between the data writer/data reader modules corresponding to the matching topics between the first node and the second node.
- the second node and the first node can match based on the compact bit sequence at the SPDP node. This ensures that the length of the compact bit sequence remains within a certain size, thus not affecting the length of the message in the SPDP stage and reducing the false alarm rate, enabling rapid discovery between communication nodes.
- the first node can selectively send SEDP messages.
- the first node will not send an SEDP message to the second node.
- this avoids unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without publish-subscribe relationships.
- it can shorten the time required for establishing a link between multiple communication nodes providing services for the same or related application tasks/functions, enabling rapid link establishment between communication nodes.
- the first node can also record the information of the second node (such as node address, node identifier, etc., without limitation) in a useless remote list (hereinafter referred to as the "first mismatch list").
- the first mismatch list is used to record the information of remote nodes that do not match the first node.
- Remote nodes that do not match the first node refer to remote nodes that do not have a matching topic with the first node.
- the first node when the first node subsequently receives an SPDP message (such as an SPDP keep-alive packet) from the second node, it can determine that the second node does not match the first node based on the information of the second node recorded in the first mismatch list, and thus will not perform the first preset parsing on the SPDP message (such as the SPDP keep-alive packet).
- the first preset parsing is similar to the parsing processing related to node discovery. In other words, the first node can avoid performing unnecessary parsing and processing related to node discovery on SPDP messages (such as SPDP keep-alive packets) from mismatched communication nodes. This allows for selective message processing during the SPDP phase, which can reduce the consumption of memory and computing resources and shorten the time required for establishing a link between communication nodes, thus enabling rapid link establishment between them.
- the first node can also send fourth information (such as a remote overlap tag) to the second node to notify the second node that the second topic related to the first node does not match any of the M different first topics related to the second node.
- fourth information indicates that the second topic related to the first node does not match any of the M different first topics related to the second node.
- the fourth information (such as a remote overlap tag) can represent the mismatch between the second topic related to the first node and the M different first topics related to the second node in the form of a preset identifier.
- the second node can update the locally managed and maintained mismatch list (denoted as the "second mismatch list") according to the fourth information from the first node, such as recording sixth information, which indicates that the second topic related to the first node does not match any of the M different first topics related to the second node.
- the second node can record the information of the first node (such as node address, node identifier, etc., without limitation) in the second mismatch list. Based on this, the first and second nodes can selectively send SEDP messages according to their respective mismatch lists.
- the first node when the first node receives an SPDP message (such as an SPDP keep-alive packet) from the second node, it can choose not to perform the first preset parsing on the SPDP message (such as the SPDP keep-alive packet) based on the information of the second node recorded in the first mismatch list, such as not processing it or performing simple processing (in some embodiments, it can also be directly deleted to save internal memory).
- SPDP message such as an SPDP keep-alive packet
- the second node when the second node receives an SPDP message (such as an SPDP keep-alive packet) from the first node, it can choose not to perform the first preset parsing on the SPDP message (such as the SPDP keep-alive packet) based on the information of the first node recorded in the second mismatch list, such as not processing it or performing simple processing (in some embodiments, it can also be directly deleted to save internal memory).
- this avoids unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without publish-subscribe relationships.
- it can shorten the time required for establishing a link between multiple communication nodes providing services for the same or related application tasks/application functions, thus achieving rapid link establishment between communication nodes.
- Figure 12 illustrates a schematic diagram of a new topic processing procedure provided by an embodiment of this application.
- a new module such as a new data writer module (DataWriter) or a data reader module (DataReader)
- the second node updates the topic corresponding to the new module (denoted as the new topic) into the first information by querying a preset information table or parsing a formatted file, and sends the fifth information to other communication nodes in the distributed system (such as the first node, Figure 12 uses the first node as an example).
- the fifth information is used by the first node to determine whether to send a SEDP message to the second node.
- the fifth information includes a first identifier (such as runtime new entity tag) and information used to characterize the topic corresponding to the new module (denoted as the new topic).
- the first identifier is used to indicate that the information carried in the fifth information characterizes a new topic related to the second node.
- the first node can identify that the fifth message carries a new topic based on other carried first identifiers (such as runtime new entity tag). Then, the first node can use a method similar to S804 to determine whether the second topic related to the first node matches the new topic corresponding to the second node.
- the first node can send an SEDP message to the second node.
- the SEDP message carries information about the second topic that matches the new topic. Based on this, it can be ensured that fast link establishment between communication nodes can still be achieved with a low false alarm rate when a module (or topic) is added. If there is no usable topic that matches the new topic in the compact bit sequence 2, the first node does not send an SEDP message to the second node.
- the first node can also check whether there is information about the second node in the first mismatch list; if there is, as shown in FIG12, the first node deletes the information about the second node from the first mismatch list; if not, the first node does not perform any processing.
- the first node determines, by comparing and searching the compact bit sequence 2, that there is an available topic in the compact bit sequence 2 that matches the newly added topic, as shown in Figure 12, the first node can also send a message (such as a related tag) to the second node to notify the second node that the first node's related topic matches the newly added topic.
- the second node can update the second mismatch list it manages and maintains locally based on this message. If the second mismatch list includes the first node's information, the second node can delete the first node's information from the second mismatch list; if the second mismatch list did not originally include the first node's information, the second node does not perform any processing.
- the first node can also update the first mismatch list based on the analysis result; for example, if the first mismatch list does not include the information of the second node, the first node can record the information of the second node in the first mismatch list; if the first mismatch list originally includes the information of the second node, the first node does not perform any processing.
- the first node can send a message (such as a related tag) to the second node to notify the second node that the second topic related to the first node does not match the newly added topic.
- the second node can update the second mismatch list it manages and maintains locally based on the related tag from the first node. If the second mismatch list does not include the information of the first node, the second node can record the information of the first node in the second mismatch list; if the second mismatch list already includes the information of the first node, the second node does not perform any processing.
- Figure 12 only illustrates the sending of the fifth message from the second node to the first node in the distributed system when a new module (such as a data writer module or a data reader module) is added.
- the second node may also, when a new module is added, first determine whether the topic corresponding to the new module is a new topic; if it is not a new topic, it does not send the fifth message to the first node; if it is a new topic, it sends the fifth message to the first node.
- the second node can determine whether the topic corresponding to the new module is a new topic by checking whether the first topic represented by the first message includes the topic corresponding to the new module. If it includes it, it determines that the topic corresponding to the new module is not a new topic; if it does not include it, it determines that the topic corresponding to the new module is a new topic.
- each communication node may also remove the information of a communication node that is powered down (including but not limited to normal power-down and abnormal power-down) from the mismatch list when it identifies that a communication node in its mismatch list is powered down, in order to synchronize the state, while minimizing redundant information in the mismatch list and reducing the size of the mismatch list.
- a communication node that is powered down including but not limited to normal power-down and abnormal power-down
- the first node and the second node may support the same protocol version or different protocol versions; this embodiment does not limit this.
- the communication nodes may also have the ability to determine the version information of other communication nodes.
- the second node can send information to the first node to characterize the protocol version supported by the second node (denoted as "first protocol version"), such as sending an identifier of the protocol version supported by the second node (Version Label, such as PID_PROTOCOL_VERSION), which the first node uses to determine the protocol version when sending SPDP and SEDP messages to the second node.
- first protocol version a protocol version supported by the second node
- Version Label such as PID_PROTOCOL_VERSION
- the first node can identify the protocol version supported by the second node (i.e., the first protocol version) based on the parsing results of the message sent by the second node to the first node. For instance, the first node can identify the protocol version supported by the second node based on whether the message sent by the second node to the first node carries first information (such as a compact bit sequence). If the message sent by the second node to the first node carries the first information, then the protocol version supported by the second node is identified as the new protocol version; if the message sent by the second node to the first node does not carry the first information, then the protocol version supported by the second node is identified as the old protocol version.
- first information such as a compact bit sequence
- the first node upon receiving a message (such as an SPDP message) from the second node, the first node can first identify the first protocol version supported by the second node by parsing the message and using the identifier of the protocol version supported by the second node carried in the message, or by using the parsing result that does not carry the first information. Then, the first node can determine whether the protocol version supported by the first node (i.e., the second protocol version) is higher than the protocol version supported by the second node (i.e., the first protocol version).
- a message such as an SPDP message
- the first node can send messages to the second node (such as SPDP messages or SEDP messages) based on the second protocol version. If the first protocol version is lower than the second protocol version, the first node can send messages to the second node (such as SPDP messages or SEDP messages) based on the first protocol version.
- the second node such as SPDP messages or SEDP messages
- Figure 13 illustrates a protocol version adaptation process provided by an embodiment of this application, with the first node supporting a new protocol version and the second node supporting an old protocol version as an example.
- the first node identifies that the second node supports the old protocol version based on the identifier of the old protocol version carried in the SPDP message or based on the absence of a compact bit sequence in the SPDP message. Based on this, the first node subsequently sends messages to the second node based on the old protocol version (the SPDP message and/or SEDP message shown in Figure 13).
- the first node can record information about the old protocol version supported by the second node, such as labeling the second node with an old protocol version label (Old Version Label). Afterwards, the first node can send messages to the second node based on the old protocol version according to the label (Old Version Label).
- Old Version Label an old protocol version label
- the version adaptation mechanism described in this application embodiment can be applied to any scenario in a distributed system, such as the SPDP phase, module/topic addition scenarios, etc.
- the module/topic addition scenario as an example, as shown in Figure 13, assuming the first node receives a new topic and a first identifier from the second node, the first node determines that the second node supports the old protocol version by checking the corresponding tag of the second node. In this case, the first node conducts subsequent communication with the second node based on the old protocol version.
- the first node determines that the second node supports the old protocol version by checking the corresponding tag of the second node. In this case, the first node conducts subsequent communication with the second node based on the old protocol version.
- Figure 13 only uses the case of the second node initiating SPDP as an example.
- the first node first sends the SPDP message to the second node based on the newer protocol version it supports.
- the second node since the second node supports an older protocol version, it cannot successfully parse the compact bit sequence from the first node, and therefore usually does not process it by default.
- the second node still sends the message to the first node based on its older protocol version.
- the first node uses a similar processing procedure to Figure 13 to adapt to the protocol version of the second node, achieving software version compatibility.
- the second node can also send a Bloom bitlist to the first node.
- the Bloom bitlist includes multiple bits representing the availability status of multiple unknown topics related to the communication node (such as a fourth topic for which no corresponding bit was found in the compact bit sequence).
- the first node can determine whether there is a topic match between the multiple unknown topics related to the first node (such as a fourth topic for which no corresponding bit was found in the compact bit sequence) and the third topic of the second node, based on whether the second node matches any of the second node's related unknown topics, and then determine whether to establish a publish-subscribe relationship between the two nodes based on the result.
- Figure 14 shows a flowchart of another method for establishing a link between nodes provided in an embodiment of this application. As shown in Figure 14, this method can be implemented based on the following steps: S801-S802, S1401-S1402, S803, S1403, S1404, and S1405.
- the second node generates first information, which includes M bits (M is a positive integer).
- M is a positive integer.
- the M bits represent the available status of M different first topics related to the second node.
- the first node generates second information, which includes N (N is a positive integer) bits.
- the N bits represent the available status of N different second topics related to the first node.
- S801 may occur before S802, or it may occur after S802, or it may occur simultaneously with S802.
- the second node generates third information, which includes K (K is a positive integer) bits, and the K bits represent the available state of at least one third topic related to the second node.
- the third topic is an unknown topic related to the second node, such as a topic for which the corresponding bit position was not found in the compact bit sequence.
- the third information could be a Bloom bitlist, which consists of multiple bits that represent the availability status of at least one third topic related to the second node based on a predefined Bloom mapping mechanism.
- the third information can be generated by the second node by querying a preset information table for application-related topics hosted by the second node and based on the query results. For instance, if a topic is not found in the preset information table, its availability status is mapped to a Bloom table using a preset Bloom mapping mechanism. For example, a third preset identifier in the Bloom table indicates that the corresponding topic is available, and a fourth preset identifier indicates that the corresponding topic is unavailable.
- the third preset identifier is like 1, and the fourth preset identifier is like 0; or, the fourth preset identifier is like 0, and the third preset identifier is like 1.
- Figure 15 illustrates a schematic diagram of the discovery and connection establishment process between communication nodes in a distributed system provided by an embodiment of this application.
- the second node can generate Bloom Table 1 (i.e., third information) by looking up a table or parsing a formatted file.
- all communication nodes in the distributed system (including the first node and the second node) follow the same Bloom mapping mechanism so that each communication node can quickly and accurately match topics.
- the second node can call a file parsing interface to parse a formatted file to generate third-party information.
- This formatted file includes information about K different third-party topics related to the second node.
- the second node can parse the formatted file to generate Bloom Table 1.
- Bloom Table 1 is generated by mapping multiple different available third-party topics related to the second node to corresponding bits according to the formatted file and following certain Bloom mapping rules.
- the second node can normally create the DataWriter and/or DataReader modules.
- the first node generates the seventh information, which includes L (L is a positive integer) bits, each of which represents the available state of at least one fourth topic related to the first node.
- the fourth topic is an unknown topic related to the first node, such as a topic for which the corresponding bit position was not found in the compact bit sequence.
- the seventh piece of information could be a Bloom bitlist, which consists of multiple bits that represent the availability status of at least one fourth topic associated with the first node based on a predefined Bloom mapping mechanism.
- the seventh piece of information can be generated by the first node by querying a preset information table for topics related to the application it hosts, and based on the query results. For instance, if a topic is not found in the preset information table, its availability status is mapped to a Bloom table using a preset Bloom mapping mechanism. For example, a third preset identifier in the Bloom table indicates that the corresponding topic is available, and a fourth preset identifier indicates that the corresponding topic is unavailable.
- the third preset identifier is like 1, and the fourth preset identifier is like 0; or, the fourth preset identifier is like 0, and the third preset identifier is like 1.
- the first node can generate Bloom Table 2 (i.e., the seventh information) by looking up a table or parsing a formatted file.
- Bloom Table 2 i.e., the seventh information
- the first node can call a file parsing interface to parse a formatted file to generate seventh information.
- This formatted file includes information about L different fourth topics related to the first node.
- the first node can parse the formatted file to generate Bloom Table 2 during application preparation, such as application initialization or node creation. Bloom Table 2 is generated by mapping multiple different available fourth topics related to the first node to corresponding bits according to the formatted file and following certain Bloom mapping rules.
- the first node can normally create the data writer and/or data reader modules.
- S1401 may occur before S1402, or it may occur after S1402, or it may occur simultaneously with S1402.
- S803 The second node sends the first message to the first node.
- the second node sends third information to the first node to determine whether to send an SEDP message to the second node, and to determine the subject information carried in the SEDP message when the first node decides to send an SEDP message to the second node.
- the second node can send the first information and the third information to the first node through the same message; that is, S803 and S1403 shown in Figure 14 can be a single step; in other examples, the second node can send the first information and the third information to the first node through different messages.
- This application embodiment does not limit this, and Figure 14 is only an example of the second node sending the first information and the third information to the first node through different messages.
- the third information can be carried in the SPDP message. Taking the example of the second node sending the first and third information to the first node through the same message, as shown in Figure 15, the second node sends Bloom Table 1 (i.e., the third information) and Compact Bit Sequence 1 (i.e., the first information) to the first node through the SPDP message.
- Bloom Table 1 i.e., the third information
- Compact Bit Sequence 1 i.e., the first information
- the second node can send the third information to the first node through data in the form of submessage (such as DDS submessage) or parameter (such as DDS parameter).
- submessage such as DDS submessage
- parameter such as DDS parameter
- S1404 The first node determines whether the fourth topic related to the first node matches at least one of the above third topics.
- the first node can determine whether its associated fourth topic matches at least one of the aforementioned third topics using a Bloom filter strategy. For instance, the first node can use the same Bloom mapping mechanism to map the topics of the third and seventh information, determining whether there is a topic match between the fourth topic associated with the first node and the third topic of the second node. If so, it is determined that the first node has a fourth topic that matches the second node; otherwise, it is determined that the first node does not have a fourth topic that matches the second node. Furthermore, the first node can also use the same Bloom mapping mechanism to determine which of its fourth topics matches its third topic.
- S804 may occur before S1404, or after S1404, or may occur simultaneously with S1404.
- the seventh information generated by the first node and the third information generated by the first node follow the same topic and bit mapping rules. Based on this, the first node can directly use the same Bloom mapping mechanism to quickly and accurately determine whether the fourth topic related to the first node matches different third topics.
- the first node executes S1405; if the second topic related to the first node does not match any of the M different first topics, and the fourth topic related to the first node does not match any of the at least three third topics, the first node does not send an SEDP message to the second node.
- the first node sends an SEDP message to the second node, the SEDP carrying information about a second topic that matches at least one of the M different first topics and/or information about a fourth topic that matches at least one of the at least one third topic.
- the first node shown in Figure 15 may send an SEDP message to the second node when there is a second topic in compact bit sequence 2 that matches the first topic available in compact bit sequence 1, and/or when, based on Bloom Table 2 and Bloom Table 1, it is determined that there is a third topic in the fourth topic indicated by Bloom Table 2 that matches the third topic indicated by Bloom Table 1.
- the SEDP message carries information about the second topic that matches the first node's first topic and/or information about the fourth topic that matches the first node's third topic. This information carried in the SEDP message is used for mutual discovery and information transfer between the data writer/data reader modules corresponding to the matching topics between the first node and the second node.
- the second node and the first node can match based on the compact bit sequence at the SPDP node. This ensures that the length of the compact bit sequence remains within a certain size, thus not affecting the length of the message in the SPDP stage and reducing the false alarm rate, enabling rapid discovery between communication nodes.
- mapping based on a hybrid sequence can further avoid unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without publish-subscribe relationships, and further shorten the time required for establishing a link between multiple communication nodes providing services for the same or related application tasks/functions, thus enabling rapid link establishment between communication nodes.
- the first node can also record information about the second node (such as node address, node identifier, etc., without limitation) in a first mismatch list.
- the first mismatch list is used to record information about remote nodes that do not match the first node. Remote nodes that do not match the first node refer to remote nodes that do not have a matching topic with the first node.
- the first node when the first node subsequently receives an SPDP message (such as an SPDP keep-alive packet) from the second node, it can determine that the second node does not match the first node based on the information of the second node recorded in the first mismatch list, and thus will not perform the first preset parsing on the SPDP message (such as the SPDP keep-alive packet).
- the first node can avoid performing unnecessary parsing and processing related to node discovery on SPDP messages (such as SPDP keep-alive packets) from mismatched communication nodes. This allows for selective message processing during the SPDP phase, which can reduce the consumption of memory and computing resources and shorten the time required for establishing a link between communication nodes, thus enabling rapid link establishment between them.
- the first node can also send fourth information (such as a remote overlap tag) to the second node to notify the second node that the second topic related to the first node does not match any of the M different first topics related to the second node.
- fourth information such as a remote overlap tag
- the fourth information (such as a remote overlap tag) can represent, in the form of a preset identifier, that the second topic related to the first node does not match any of the M different first topics related to the second node, and that the fourth topic related to the first node does not match any of the at least one third topic.
- the second node can update the second mismatch list it manages and maintains locally based on the fourth information from the first node, such as recording sixth information, which represents that the second topic related to the first node does not match any of the M different first topics related to the second node.
- the second node can record the information of the first node (such as node address, node identifier, etc., without limitation) in the second mismatch list.
- the first and second nodes can selectively send SEDP messages according to their respective mismatch lists. For example, when the first node receives an SPDP message (such as an SPDP keep-alive packet) from the second node, it can choose not to perform the first preset parsing on the SPDP message (such as the SPDP keep-alive packet) based on the information of the second node recorded in the first mismatch list, such as not processing it or performing simple processing (in some embodiments, it can also be directly deleted to save internal memory).
- SPDP message such as an SPDP keep-alive packet
- the second node when the second node receives an SPDP message (such as an SPDP keep-alive packet) from the first node, it can choose not to perform the first preset parsing on the SPDP message (such as the SPDP keep-alive packet) based on the information of the first node recorded in the second mismatch list, such as not processing it or performing simple processing (in some embodiments, it can also be directly deleted to save internal memory).
- this avoids unnecessary consumption of memory and computing resources caused by sending messages to communication nodes without publish-subscribe relationships.
- it can shorten the time required for establishing a link between multiple communication nodes providing services for the same or related application tasks/application functions, thus achieving rapid link establishment between communication nodes.
- Figure 17 illustrates a schematic diagram of a new topic processing procedure provided by an embodiment of the application.
- a new module such as a new data writer module (DataWriter) or a data reader module (DataReader)
- the second node can update the new topic corresponding to the new module into the first information by querying a preset information table or parsing a formatted file, and send the fifth information to other communication nodes in the distributed system (such as the first node, Figure 17 uses the first node as an example).
- the fifth information is used by the first node to determine whether to send a SEDP message to the second node.
- the fifth information includes a first identifier (such as runtime new entity tag) and information used to characterize the topic corresponding to the new module (denoted as the new topic).
- the first identifier is used to indicate that the information carried in the fifth information characterizes the new topic related to the second node.
- the first node can identify that the fifth message carries a new topic based on other carried first identifiers (such as runtime new entity tag). Then, the first node can determine whether the second topic related to the first node matches the new topic in a manner similar to S804, and determine whether the fourth topic related to the first node matches the new topic in a manner similar to S1404.
- the first node can send an SEDP message to the second node.
- the SEDP message carries information about the second or fourth topic matching the new topic. Based on this, it can be ensured that fast link establishment between communication nodes can still be achieved with a low false alarm rate when a module (or topic) is added. If there is no usable topic matching the new topic in the compact bit sequence 2 and no usable topic matching the new topic in the topics indicated by Bloom Table 2, the first node does not send an SEDP message to the second node.
- the first node may also check whether there is information about the second node in the first mismatch list; if so, as shown in FIG17, the first node deletes the information about the second node from the first mismatch list; if not, the first node does not perform any processing.
- the first node can also send a message (such as a related tag) to the second node to notify the second node that the topic related to the first node matches the new topic.
- the second node can update the second mismatch list it manages and maintains locally based on this message.
- the second node can delete the information of the first node from the second mismatch list; if the second mismatch list did not originally include the information of the first node, the second node does not perform any processing.
- the first node may also update the first mismatch list based on the analysis result; for example, if the first mismatch list does not include the information of the second node, the first node may record the information of the second node in the first mismatch list; if the first mismatch list originally includes the information of the second node, the first node does not perform any processing.
- the first node may send a message (such as a related tag) to the second node to notify the second node that the topic related to the first node does not match the newly added topic.
- the second node can update the second mismatch list it manages and maintains locally based on the related tag from the first node.
- the second node can record the information of the first node in the second mismatch list; if the second mismatch list originally includes the information of the first node, the second node does not perform any processing.
- Figure 17 only illustrates the sending of the fifth message from the second node to the first node in the distributed system when a new module (such as a data writer or data reader) is added.
- the second node may also, when a new module is added, first determine whether the topic corresponding to the new module is a new topic; if it is not a new topic, it does not send the fifth message to the first node; if it is a new topic, it sends the fifth message to the first node.
- the second node can determine whether the topic corresponding to the new module is a new topic by checking whether the first topic represented by the first message includes the topic corresponding to the new module. If it includes it, it determines that the topic corresponding to the new module is not a new topic; if it does not include it, it determines that the topic corresponding to the new module is a new topic.
- the first node and the second node may support the same protocol version or different protocol versions; this embodiment does not limit this.
- the communication nodes in this embodiment may also have the ability to determine the version information of other communication nodes. This facilitates version adaptation when the protocol version supported by a communication node is inconsistent with the protocol version supported by the peer, so that both ends can smoothly carry out subsequent communication processes.
- protocol version adaptation between communication nodes during the discovery and chain establishment process please refer to the explanation and description above, which will not be repeated here.
- communication nodes in the distributed system can send each other their small, compact bit sequences during the SPDP (Small Partial Discovery) phase of automatic discovery, so that other communication nodes can quickly and accurately complete topic matching between nodes and selectively send SEDP (Search for Sequences and Delegates) messages based on the matching results.
- SPDP Small Partial Discovery
- SEDP Search for Sequences and Delegates
- any one or more of the following technologies can be combined: 1) Communication nodes can also send each other their Bloom tables during the SPDP phase of automatic discovery, so that other communication nodes can fully consider relevant topics for topic matching between nodes, further reducing the consumption of memory and computing resources while shortening the time required for link establishment between communication nodes, thus achieving rapid link establishment between communication nodes; 2) Communication nodes can record information about unrelated communication nodes so that when they receive SPDP messages from those unrelated communication nodes again, they can perform no processing or simple processing, further reducing the consumption of memory and computing resources while shortening the time required for link establishment between communication nodes.
- Communication nodes can identify software versions and support software version adaptation, so that subsequent communication can proceed smoothly even if the software versions of communication nodes do not match; 3) Communication nodes can send new topics and first identifiers to other nodes, so that other communication nodes can match their related topics with the new topics based on the first identifier, so as to ensure that rapid link establishment between communication nodes can still be achieved with a low false alarm rate when a module (or topic) is added; 4) Communication nodes can parse formatted files in advance to obtain their own related topic information, so as to support normal discovery and link establishment between communication nodes based on the solution provided in Example 1 in some special scenarios such as ROS-like interface scenarios.
- Embodiment 2 also incorporates any one or more of the following technologies: a) Communication nodes can record information about unrelated communication nodes, so that when they subsequently receive SPDP messages from those unrelated communication nodes again, they can perform no processing or only simple processing, further reducing the consumption of memory and computing resources while shortening the time required for establishing links between communication nodes, thus achieving communication efficiency.
- SPDP Simultaneous Spread Node Display
- Embodiment 2 also incorporates any one or more of the following technologies: a) Communication nodes can record information about unrelated communication nodes, so that when they subsequently receive SPDP messages from those unrelated communication nodes again, they can perform no processing or only simple processing, further reducing the consumption of memory and computing resources while shortening the time required for establishing links between communication nodes, thus achieving communication efficiency.
- communication nodes include hardware structures and/or software modules corresponding to the execution of each function.
- this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
- This application embodiment can divide communication nodes (such as first nodes, second nodes, etc.) into functional modules. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module.
- the integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation. It should also be understood that each module in the communication node (such as first nodes, second nodes, etc.) can be implemented in software and/or hardware, without specific limitations. In other words, the communication node (such as first nodes, second nodes, etc.) is presented in the form of functional modules.
- module can refer to application-specific integrated circuits (ASICs), circuits, processors and memories that execute one or more software or firmware programs, integrated logic circuits, and/or other devices that can provide the above functions.
- ASICs application-specific integrated circuits
- the computer program product includes one or more computer instructions.
- the computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
- the computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another.
- the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.
- the computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media.
- the available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disk (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).
- the steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions.
- the software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, compact disc read-only memory (CD-ROM), or any other form of storage medium well known in the art.
- RAM random access memory
- ROM read-only memory
- EPROM erasable programmable read-only memory
- EEPROM electrically erasable programmable read-only memory
- registers hard disks, portable hard disks, compact disc read-only memory (CD-ROM), or any other form of storage medium well known in the art.
- One exemplary embodiment couples a storage medium to a processor, enabling the processor to read information from and write information to the storage medium.
- the storage medium can
- the processor and the storage medium can reside in an application-specific integrated circuit (ASIC). Furthermore, the ASIC can be located within a communication node (such as a first node, a second node, etc.). Of course, the processor and storage medium can also exist as discrete components.
- ASIC application-specific integrated circuit
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computer And Data Communications (AREA)
Abstract
本申请公开了节点间的建链方法、节点及分布式系统,涉及分布式通信技术领域,可以提高通信节点之间建链的效率和可靠性,且可以节省内存、计算等开销。本申请中,分布式系统中的通信节点之间基于小尺寸的紧凑型比特序列进行相关主题匹配,以判断两者之间是否需要建立发布订阅关系,可以在不对SPDP阶段的消息的长度造成影响的前提下,降低误报率,实现通信节点之间的快速发现;另外,基于紧凑型比特序列进行匹配,可以便于通信节点有选择性的进行SEDP消息的发送,可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,且可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
Description
本申请要求于2024年4月29日提交国家知识产权局、申请号为202410537087.X、申请名称为“节点间的建链方法、节点及分布式系统”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本申请涉及分布式通信技术领域,尤其涉及一种节点间的建链方法、节点及分布式系统。
目前,在很多场景下,可以通过多个通信节点之间的相互建链实现多种不同的业务功能。以智能车领域为例,车辆可以通过多个通信节点(如座舱域控制器(cockpit domain controller,CDC)、智能驾驶域控制器(如移动数据中心(mobile data center,MDC))、车控域控制器(vehicle domain controller,VDC)、微控制单元(microcontroller unit,MCU)等的功能节点)之间的相互建链实现车辆启动、路线规划、自动驾驶、自动泊车等功能。
随着软硬件技术的发展以及应用技术的发展,能够提供多种多样业务功能的应用会越来越多,随之而来的智能驾驶相关算法以及所需要的通信节点也越来越多,便会导致智能驾驶系统中通信节点之间的建链过程更加复杂,建链所需的内存开销、计算开销和时间开销等大大增加,会对内存和计算成本、建链效率等造成影响,影响业务功能实现的可靠性和时延,影响用户体验。
本申请提供一种节点间的建链方法、节点及分布式系统,可以提高通信节点之间建链的效率和可靠性,且可以节省内存、计算等开销。
为达到上述目的,本申请采用如下技术方案:
第一方面,提供一种节点间的建链方法,该方法包括:第一节点接收来自第二节点的第一信息,其中第一信息包括M(M为正整数)个比特,M个比特分别表征第二节点相关的M个不同第一主题的可用状态;第一节点判断第一节点相关的第二主题是否与上述不同第一主题相匹配;在第一节点相关的第二主题与M个不同第一主题中的至少一个相匹配时,第一节点向第二节点发送简单端节点发现协议(simple endpoint discovery protocol,SEDP)消息,其中SEDP中携带有与上述M个不同第一主题中的至少一个相匹配的第二主题的信息。
作为一种示例,第一信息可以是紧凑型比特序列。
作为一种示例,第一节点与第二节点是分布式系统中的通信节点,第一节点与第二节点遵循相同的主题与比特位的映射规则生成各自的比特序列。例如,分布式系统可以包括但不限于数据分发服务(data distribution service,DDS)分布式系统。
上述第一方面提供的方案,分布式系统中的通信节点之间基于小尺寸的紧凑型比特序列进行相关主题匹配,以判断两者之间是否需要建立发布订阅关系,可以在不对SPDP阶段的消息的长度造成影响的前提下,降低误报率,实现通信节点之间的快速发现;另外,基于紧凑型比特序列进行匹配,可以便于通信节点有选择性的进行SEDP消息的发送,可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,且可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述第一节点在SPDP阶段接收来自第二节点的第一信息。基于此,可以便于第一节点基于第一信息判断与第二节点之间是否需要建立发布订阅关系,进而在后续的SEDP阶段有选择性的进行SEDP消息的发送,可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,且可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述第一信息携带在SPDP消息中。基于此,可以复用标准SPDP消息实现第一信息的发送,提高该方案实现的兼容性、操作的简单性和便捷性。
当然,本申请不限定第二节点向第一节点发送第一信息的具体方式,例如,第二节点也可以通过单独的一条消息向第一节点发送第一信息。
作为一种可能的实现方式,上述第一节点中保存有第二信息,其中第二信息包括N(N为正整数)个比特,该N个比特分别表征第一节点相关的N个不同第二主题的可用状态;上述第一节点判断第一节点相关的N个第二主题是否与上述不同第一主题相匹配,包括:第一节点通过比较不同第二主题的可用状态是否与不同第一主题的可用状态相同,来判断不同第二主题中是否存在与不同第一主题相匹配的主题。基于此,可以方便、准确、快速地判断出是否需要建立通信节点间的发布订阅关系。
示例性地,第一节点可以通过对第二信息与第二信息进行位比较,比较第二信息中不同第二主题的可用状态是否与第一信息中不同第一主题的可用状态相同,来判断不同第二主题中是否存在与不同第一主题相匹配的主题。若有,则确定第一节点有与第二节点相匹配的主题;若无,则确定第一节点没有与第二节点相匹配的主题。
作为一种可能的实现方式,上述第二信息与第一信息所遵循的主题与比特位的映射规则一致。基于此,可以保证第一节点基于第一信息和第二信息判断两者是否存在相匹配的主题得到的结果的准确性,进而保证后续基于该结果做出建链与否决定的准确性。
作为一种可能的实现方式,上述第一节点应用于机器人操作系统(robot operating system,ROS)场景,上述方法还包括:第一节点调用文件解析接口,解析格式化文件以生成第二信息,其中格式化文件包括第一节点相关的N个不同第二主题的信息。基于此,可以通过提前解析文件生成第二信息,避免在一些类ROS接口场景等特殊场景下,无法在节点发现前获取通信节点相关主题信息的问题,导致无法准确进行发现和建链的问题。
作为一种可能的实现方式,上述方法还包括:第一节点接收来自第二节点的第三信息,其中第三信息包括K(K为正整数)个比特,该K个比特表征与第二节点相关的至少一个第三主题的可用状态;第一节点根据布隆过滤器的策略判断第一节点相关的第四主题是否与上述至少一个第三主题相匹配;在第一节点相关的第四主题与至少一个第三主题中的至少一个相匹配时,第一节点向第二节点发送SEDP消息。基于此,可以通过第一信息和第三信息相结合,进一步提高通信节点判断两者是否存在相匹配的主题得到的结果的准确性,以及进一步降低内存资源以及计算资源的消耗,缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
示例性地,第三信息是布隆表,布隆表中包括的多个比特分别表征第二节点相关的多个未知主题(如未在紧凑型比特序列中查找到对应比特位的第三主题)的可用状态。
示例性地,第一节点与第二节点在生成各自的布隆表时,可以遵循相同的布隆映射机制,以便于各个通信节点可以快速、准确的进行主题的匹配。
作为一种可能的实现方式,上述第一节点应用于ROS场景,上述方法还包括:第一节点调用文件解析接口,解析格式化文件以确定第一节点相关的第四主题,其中格式化文件包括第一节点相关的第四主题的信息。基于此,可以通过提前解析文件生成相关主题信息,避免在一些类ROS接口场景等特殊场景下,无法在节点发现前获取通信节点相关主题信息的问题,导致无法准确进行发现和建链的问题。
示例性地,上述格式化文件包括以下任意一种或多种类型的文件:XML文件、JSON文件、YAML文件。
作为一种可能的实现方式,上述第三信息与第一信息携带在同一消息中或不同消息中。基于此,可以提高信息发送方式的灵活性,提高该方案实现的兼容性、操作的简单性和便捷性。
作为一种可能的实现方式,上述方法还包括:在第一节点相关的第二主题上述M个不同第一主题均不匹配,且第一节点相关的第四主题与上述至少一个第三主题均不匹配时,第一节点在不匹配列表中记录第二节点的标识;在接收到来自第二节点的SPDP消息时,第一节点根据不匹配列表不该SPDP消息进行第一预设解析。基于此,可以避免对来自没有发布订阅关系的通信节点的消息的解析带来的对内存资源以及计算资源不必要的消耗,进一步缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述方法还包括:第一节点向第二节点发送第四信息,其中第四信息表征第一节点相关的第二主题与M个不同第一主题均不匹配。基于此,可以便于对端节点及时获知两个通信节点之间没有发布订阅关系,方便对端设备采用不向第一节点发送SPDP消息等方式来降低内存资源以及计算资源的消耗,进而缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述方法还包括:第一节点接收来自第二节点的第五信息,其中第五信息包括第一标识和用于表征与第二节点相关的新增主题的信息,第一标识用于指示第五信息中携带的信息表征的是与第二节点相关的新增主题;第一节点根据上述第一标识,判断第一节点相关的第二主题和第一节点相关的第四主题是否与新增主题相匹配;在第一节点相关的第二主题与新增主题相匹配或者第一节点相关的第四主题与新增主题相匹配时,第一节点向第二节点发送SEDP消息。基于此,可以保证在有模块(或主题)新增时仍然可以以较低的误报率实现通信节点之间的快速建链。
作为一种可能的实现方式,在第一节点相关的第二主题与新增主题相匹配或者第一节点相关的第四主题与新增主题相匹配时,上述方法还包括:第一节点从维护的不匹配列表中删除第二节点的标识。基于此,可以避免由于没有及时从不匹配列表中删除第二节点的标识,导致的第一节点不对来自具有发布订阅关系的第二节点进行第一预设解析对业务功能的影响。
作为一种可能的实现方式,上述方法还包括:第一节点解析来自第二节点的SPDP消息,识别第二节点支持的第一协议版本;在第一协议版本高于或等于第一节点支持的第二协议版本时,第一节点在向第二节点发送SPDP消息和SEDP消息时基于第二协议版本发送;在第一协议版本低于第一节点支持的第二协议版本时,第一节点在向第二节点发送SPDP消息和SEDP消息时基于第一协议版本发送。基于此,可以支持在通信节点之间软件版本不匹配的情况下依旧可以通过版本适配顺利进行后续的通信过程。
第二方面,提供一种节点间的建链方法,该方法包括:第二节点生成第一信息,其中第一信息包括M(M为正整数)个比特,该M个比特分别表征第二节点相关的M个不同第一主题的可用状态;第二节点向第一节点发送第一信息,第一信息用于第一节点判断是否向第二节点发送SEDP消息,以及用于第一节点在向第二节点发送SEDP消息时确定携带在SEDP消息中的主题信息。
上述第二方面提供的方案,分布式系统中的通信节点之间基于小尺寸的紧凑型比特序列进行相关主题匹配,以判断两者之间是否需要建立发布订阅关系,可以在不对SPDP阶段的消息的长度造成影响的前提下,降低误报率,实现通信节点之间的快速发现;另外,基于紧凑型比特序列进行匹配,可以便于通信节点有选择性的进行SEDP消息的发送,可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,且可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述第二节点在SPDP阶段向第一节点发送上述第一信息。基于此,可以便于第一节点基于第一信息判断与第二节点之间是否需要建立发布订阅关系,进而在后续的SEDP阶段有选择性的进行SEDP消息的发送,可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,且可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述第一信息携带在SPDP消息中。基于此,可以复用标准SPDP消息实现第一信息的发送,提高该方案实现的兼容性、操作的简单性和便捷性。
当然,本申请不限定第二节点向第一节点发送第一信息的具体方式,例如,第二节点也可以通过单独的一条消息向第一节点发送第一信息。
作为一种可能的实现方式,上述第二节点应用于ROS场景,上述第二节点生成第一信息,包括:第二节点调用文件解析接口,解析格式化文件以生成第一信息,其中格式化文件包括第二节点相关的不同第一主题的信息。基于此,可以通过提前解析文件生成第二信息,避免在一些类ROS接口场景等特殊场景下,无法在节点发现前获取通信节点相关主题信息的问题,导致无法准确进行发现和建链的问题。
作为一种可能的实现方式,上述方法还包括:第二节点向第一节点发送第三信息,其中第三信息用于第一节点判断是否向第二节点发送SEDP消息,第三信息包括K(K为正整数)个比特,该K个比特表征与第二节点相关的至少一个第三主题的可用状态。基于此,可以通过第一信息和第三信息相结合,进一步提高第一节点判断两者是否存在相匹配的主题得到的结果的准确性,以及进一步降低内存资源以及计算资源的消耗,缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述第二节点应用于ROS场景,上述方法还包括:第二节点调用文件解析接口,解析格式化文件以确定第二节点相关的至少一个第三主题,其中格式化文件包括第二节点相关的第三主题的信息。基于此,可以通过第一信息和第三信息相结合,进一步提高第一节点判断两者是否存在相匹配的主题得到的结果的准确性,以及进一步降低内存资源以及计算资源的消耗,缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
示例性地,上述格式化文件包括以下任意一种或多种类型的文件:XML文件、JSON文件、YAML文件。
作为一种可能的实现方式,上述第三信息与第一信息携带在同一消息中或不同消息中。基于此,可以提高信息发送方式的灵活性,提高该方案实现的兼容性、操作的简单性和便捷性。
作为一种可能的实现方式,上述方法还包括:第二节点接收来自第一节点的第四信息,其中第四信息表征第一节点相关的第二主题与上述不同第一主题均不匹配;第二节点根据第四信息记录第六信息,第六信息表征第一节点相关的第二主题上述M个不同第一主题均不匹配且第一节点相关的第四主题与上述至少一个第三主题均不匹配。基于此,可以保证第二节点及时获知与第一节点之间没有发布订阅关系,方便对端设备采用不向第一节点发送SPDP消息等方式来降低内存资源以及计算资源的消耗,进而缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
作为一种可能的实现方式,上述方法还包括:第二节点向第一节点发送第五信息,其中第五信息用于第一节点判断是否向第二节点发送SEDP消息,第五信息包括第一标识和用于表征与第二节点相关的新增主题的信息,第一标识用于指示第五信息中携带的信息表征的是与第二节点相关的新增主题。基于此,可以保证在有模块(或主题)新增时仍然可以以较低的误报率实现通信节点之间的快速建链。
作为一种可能的实现方式,上述方法还包括:第二节点在向第一节点发送SPDP消息时携带用于表征第二节点支持的第一协议版本的信息,用于第一节点确定在向第二节点发送SPDP消息和SEDP消息时所使用的协议版本。基于此,可以支持在通信节点之间软件版本不匹配的情况下依旧可以通过版本适配顺利进行后续的通信过程。
第三方面,提供一种通信节点,该通信节点包括:存储器,用于存储计算机程序指令和数据;处理器,用于执行所述计算机程序指令,以支持服务器实现如第一方面或第二方面任一种可能的实现方式所述的方法。
第四方面,提供一种分布式通信系统,该分布式通信系统包括:第一节点和第二节点,其中第一节点用于实现如第一方面任一种可能的实现方式所述的方法,第二节点用于实现如第二方面任一种可能的实现方式所述的方法。
第五方面,提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序指令,该计算机程序指令被处理器执行时实现如第一方面或第二方面任一种可能的实现方式中的方法。
第六方面,提供一种包含指令的计算机程序产品,当该计算机程序产品在计算机上运行时,使得计算机实现如第一方面或第二方面任一种可能的实现方式中的方法。
第七方面,提供一种芯片系统,该芯片系统包括处理电路、存储介质,存储介质中存储有计算机程序指令;所述计算机程序指令被所述处理器执行时,实现如第一方面或第二方面任一种可能的实现方式中的方法。该芯片系统可以由芯片构成,也可以包含芯片和其他分立器件。
图1为一种集中式系统架构示意图;
图2为一种分布式系统架构示意图;
图3为本申请实施例提供的一种DDS的运行逻辑示意图;
图4为本申请实施例提供的一种基于DDS进行通信节点之间的自动发现过程示意图;
图5为本申请实施例提供的一种布隆表规则示意图;
图6为本申请实施例提供的一种智能车系统架构图;
图7为本申请实施例提供的一种通信节点的框架示意图;
图8为本申请实施例提供的一种节点间的建链方法流程图;
图9为本申请实施例提供的一种紧凑型比特序列的生成过程示意图;
图10为本申请实施例提供的一种分布式系统中通信节点之间的发现和建链过程示意图;
图11为本申请实施例提供的一种基于不匹配列表进行通信节点之间的发现和建链过程示意图;
图12为本申请实施例提供的一种针对新增主题处理过程示意图;
图13为本申请实施例提供的一种协议版本适配过程示意图;
图14为本申请实施例提供的另一种节点间的建链方法流程图;
图15为本申请实施例提供的另一种分布式系统中通信节点之间的发现和建链过程示意图;
图16为本申请实施例提供的另一种基于不匹配列表进行通信节点之间的发现和建链过程示意图;
图17为本申请实施例提供的另一种针对新增主题处理过程示意图。
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。其中,在本申请实施例的描述中,除非另有说明,“/”表示或的意思,例如,A/B可以表示A或B;本文中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,在本申请实施例的描述中,“多个”是指两个或多于两个。
以下,术语“第一”、“第二”等仅用于区分不同的描述对象,对被描述对象的位置、顺序、优先级、数量或内容等没有限定作用。例如,被描述对象为“字段”,则“第一字段”和“第二字段”中的“字段”之前的序数词并不限定“字段”之间的位置或顺序,“第一”和“第二”并不限定其修饰的“字段”是否在同一个消息中,也不限制“第一字段”和“第二字段”的先后顺序。再如,被描述对象为“等级”,则“第一等级”和“第二等级”中的“等级”之前的序数词并不限定“等级”之间的优先级。再如,被描述对象的数量并不受序数词的限制,可以是一个或多个,以“第一设备”为例,其中“设备”的数量可以是一个或多个。此外,不同前缀词修饰的对象可以相同或者不同,例如,被描述对象为“设备”,则“第一设备”和“第二设备”可以是相同类型的设备或者不同类型的设备,再如,被描述对象为“信息”,则“第一信息”和“第二信息”可以是相同内容的信息或者不同内容的信息。总之,本申请实施例中对序数词等用于区分描述对象的前缀词的使用不对所描述对象构成限制,对所描述对象的陈述参见权利要求或实施例中上下文的描述,不应因为使用这种前缀词而构成多余的限制。
以及,本申请实施例中,“连接”可以是直接连接或者间接连接;此外,可以指电连接或者通信连接;例如,两个电学元件A和B连接,可以指A与B直接连接,或者可以指A和B之间通过其它电学元件或连接介质间接连接,或者可以指A和B之间通过其它通信设备或通信介质间接连接,只要使得A与B之间可以进行通信即可。
如背景技术所述,目前,在很多场景下常通过多个通信节点之间的相互建链实现多种不同的业务功能。例如,多个通信节点可以是集中式架构中的通信节点或者分布式架构中的通信节点。集中式架构如包括但不限于机器人操作系统(robot operating system,ROS)1、中心化模式的可扩展的基于IP的面向服务的中间件(scalable service-oriented middleware over IP,SOME/IP)等。分布式架构如包括但不限于机器人操作系统ROS2、DDS、去中心化模式的SOME/IP等
以多个通信节点是集中式架构中的通信节点为例,请参考图1,图1示出了一种集中式系统架构示意图。如图1所示,该集中式架构包括管理节点(master)以及多个通信节点(图1以发送端节点1、发送端节点2、接收端节点1和接收端节点2为例),其中管理节点(master)用于存储多个通信节点的节点信息,如地址信息等;多个通信节点之间在相互建链的过程中需要依赖管理节点(master)为其提供对方的节点信息。
示例性地,如图1所示,假设发送端节点1发布(advertise)的主题与接收端节点1订阅(subscribe)的主题匹配(如均为主题(topic)1),则认为两者之间可以配对,进而两者之间可以建链以实现主题1对应的业务功能;在发送端节点1与接收端节点1建链的过程中,发送端节点1需要从管理节点(master)获取接收端节点1的地址信息,以及接收端节点1需要从管理节点(master)获取发送端节点1的地址信息。通过从管理节点(master)获取的地址信息,发送端节点1与接收端节点1可以发现成功并成功建链,以及进行后续的消息通信以实现对应的业务功能。类似地,假设发送端节点2发布(advertise)的主题与接收端节点2订阅(subscribe)的主题匹配(如均为主题(topic)2),则认为两者之间可以配对,进而两者之间可以建链以实现主题2对应的业务功能;在发送端节点2与接收端节点2建链的过程中,发送端节点2需要从管理节点(master)获取接收端节点2的地址信息,以及接收端节点2需要从管理节点(master)获取发送端节点2的地址信息。通过从管理节点(master)获取的地址信息,发送端节点2与接收端节点2可以发现成功并成功建链,以及进行后续的消息通信以实现对应的业务功能。也就是说,在图1所示集中式架构中,管理节点(master)需要存储4个通信节点的节点信息,随着软硬件技术的发展以及应用技术的发展,能够提供多种多样的业务功能的应用会越来越多,随之而来的相关算法也会越来越多,进而所需要的通信节点也会越来越多,因此存储开销方面的压力会更大。并且,多个通信节点之间的建链强依赖于管理节点(master),若管理节点(master)发生故障,则会影响整个集中式架构中所有通信节点的正常工作。
以多个通信节点是分布式架构中的通信节点为例,请参考图2,图2示出了一种分布式系统架构示意图,如图2所示,该分布式架构包括多个通信节点(图2以发送端节点1、发送端节点2、接收端节点1和接收端节点2为例)通过与系统内所有通信节点进行信息交互,以发现能够配对(如建链)的通信节点并存储能够与其配对的通信节点的节点信息。
示例性地,在图2所示的架构中,发送端节点1分别需要向发送端节点2、接收端节点1和接收端节点2发送其自身的节点信息,以及分别接收发送端节点2、接收端节点1和接收端节点2各自的节点信息并存储;类似地,发送端节点2、接收端节点1和接收端节点2也需要进行类似的操作,这里不做赘述。也就是说,在图2所示集中式架构中,每个通信节点需要进行3次节点信息的发送,整个架构共计需要进行12次节点信息的发送,并且每个通信节点需要存储4条节点信息(包括自身的节点信息),整个架构共计需要存储16条节点信息,因此系统的计算资源开销和存储开销也有很大的压力。特别是随着在分布式系统中通信节点很多的情况下,计算资源开销和存储开销方面的压力会更大。
基于集中式架构与分布式架构各自的特征以及集中式架构所存在的问题,目前,在一些场景下常采用分布式架构。作为一种示例,分布式架构可以基于数据分发服务(data distribution service,DDS)支持通信节点之间的建链。其中,DDS是对象管理组织(object management organization,OMG)在高级体系结构(high level architecture,HLA)及通用对象请求代理体系结构(common object request broker architecture,CORBA)等标准的基础上制定的新一代分布式实时通信中间件技术规范。DDS采用发布/订阅体系架构,强调以数据为中心,可以提供丰富的服务质量(quality of service,QoS)策略,能保障数据进行实时、可靠、灵活地分发,因此可满足各种分布式实时通信应用需求。
作为一种示例,请参考图3,图3示出了本申请实施例提供的一种DDS的运行逻辑示意图。如图3所示,分布式架构包括参与者(participant)1和参与者2(即通信节点),当然在实际应用中,分布式架构还可能包括其它多个参与者(即通信节点),不做具体限定,图3仅以参与者1和参与者2作为示例。参与者1和参与者2中部署有至少一个发布者(publisher)和/或至少一个订阅者(subscriber),也就是说,任何参与者可以作为发布者,也可以作为订阅者,不做具体限定。其中,图3仅以参与者1作为发布者(publisher)、参与者2作为订阅者(subscriber)作为示例,在实际应用中,不做具体限定。
如图3所示,发布者(publisher)中包括一个或多个数据写入模块(DataWriter),订阅者(subscriber)中包括一个或多个数据读取模块(DataReader),数据写入模块(DataWriter)和数据读取模块(DataReader)分别对应有主题名称(TopicName)和QoS策略,发布者(publisher)与订阅者(subscriber)可以根据彼此的主题名称(TopicName)和QoS策略是否匹配(如是否一致、是否有交集等)进行自动发现以及配对建链,以基于建立的通信链路进行消息通信进而实现对应的业务功能。在一些实施例中,不同的数据写入模块(DataWriter)/数据读取模块(DataReader)所对应的主题名称(TopicName)/QoS策略可能相同,也可能不同,基于此,能够与一个数据写入模块(DataWriter)配对的数据读取模块(DataReader)可能有多个,能够与一个数据读取模块(DataReader)配对的数据写入模块(DataWriter)可能有多个,这给消息通信带来了极大的灵活性。
作为一种可能的实现方式,基于DDS进行通信节点之间的自动发现可以包括以下两个阶段:
1、简单参与者发现协议(simple participant discovery protocol,SPDP)阶段:主要用于参与者(participant)之间信息的互相传递,以便各个参与者(participant)认识域内其他参与者(participant)。
示例性地,请参考图4,图4示出了本申请实施例提供的一种基于DDS进行通信节点之间的自动发现过程示意图。如图4所示,在SPDP阶段,节点A(即参与者A)在完成创建之后向节点B(即参与者B)发送节点A的节点信息,节点B在完成创建之后向节点A发送节点B的节点信息,基于对方发送的节点信息,节点A可以发现节点B并将其节点信息保存至本地信息库,节点B可以发现节点A并将其节点信息保存至本地信息库,至此,节点A与节点B之间的发现完成。
2、简单端节点发现协议(simple endpoint discovery protocol,SEDP)阶段:主要用于多个参与者(participant)中数据写入模块(DataWriter)/数据读取模块(DataReader)间信息的互相传递,以便各个数据写入模块(DataWriter)/数据读取模块(DataReader)认识域内其它数据写入模块(DataWriter)/数据读取模块(DataReader),如果一个参与者(participant)中有能够与另一个参与者(participant)中节点匹配的数据写入模块(DataWriter)/数据读取模块(DataReader),则两个参与者(participant)建立起发布订阅关系,即配对成功。
如图4所示,在SEDP阶段,节点A在完成数据写入模块1的创建之后向节点B发送数据写入模块1的信息,节点B在完成数据读取模块1的创建之后向节点A发送数据读取模块1的信息,基于对方发送的数据写入模块的信息,节点A可以发现数据读取模块1并将其信息保存至本地信息库,节点B可以发现数据写入模块1并将其信息保存至本地信息库,至此,数据写入模块1与数据读取模块1之间的发现完成。类似地,节点A中的其它数据写入模块/数据读取模块也可以基于类似的过程与节点B中的其它数据写入模块/数据读取模块互相发现。
从图4可以看出,基于DDS进行通信节点之间的自动发现的过程中,每个参与者(participant)都需向其余所有参与者(participant)发送SPDP消息,以及每个参与者(participant)都需要通过SEDP消息针对每个数据写入模块(DataWriter)/数据读取模块(DataReader)向其余所有参与者(participant)发送模块的信息,并且每个参与者(participant)都需要存储接收到的信息,以便掌握整个系统中的发布订阅节点以及各自其中的数据写入模块(DataWriter)/数据读取模块(DataReader),方便从中寻找与自己配对的节点。以系统中参与者(participant)的数量为P、每个参与者(participant)中数据写入模块(DataWriter)/数据读取模块(DataReader)的总数为E为例,在SPDP阶段共计至少需要进行P(P-1)次参与者之间的交互,在SEDP阶段共计至少需要进行2EP(P-1)次参与者之间的交互,也就是说在SPDP阶段和SEDP阶段都进行了“完全图”式的消息交互及全量的消息存储,这就带来极大的计算与存储资源的消耗。
以智能车领域为例,智能车辆(以下简称“车辆”)的驾驶系统常采用分布式架构,如基于DDS的分布式架构,作为一个集环境感知、规划决策、多等级辅助驾驶等功能于一体的综合系统,车辆驾驶系统集中运用了计算机、现代传感、信息融合、通讯、人工智能及自动控制等技术,驾驶系统中的多个通信节点之间通过相互建链可以实现如车辆启动、路线规划、自动驾驶、自动泊车、车道保持辅助,(lane keeping assist,LKA)、自动紧急制动(automatic emergency braking,AEB)、前碰撞预警(front collision warning,FCW)、车道偏离预警(lane departure warning,LDW)、紧急车道保持(emergency lane keeping,ELK)等功能。因此,随之而来的智能驾驶相关算法也会越来越多,进而所需要的通信节点也会越来越多,便会导致通信节点之间的建链过程会更加复杂。且由于建链所需的内存开销、计算开销和时间开销等会大大增加,会对内存成本、建链效率等造成影响,影响业务功能实现的可靠性和时延,影响用户体验。
特别是在未来智能驾驶向L3(如具备条件自动驾驶功能)、L4(如具备高度自动驾驶功能)甚至L5(如具备完全自动驾驶功能)级别演进的趋势下,智能驾驶级别的升级可能会涉及到通信模型的改变,就要求新的通信节点能够快速完成建链,不要影响安全运行;再如用户上车开机启动时,所有的软件冷启动,所有的通信节点都要开始建链,如果建链时间过长影响到冷启动时间,对于用户体验到的就是开机速度慢,因此通信节点之间建链所存在的上述问题会越来越显著。
为了缩短通信节点之间建链所需的时长,降低内存资源以及计算资源的消耗,作为一种可能的实现方式,可以在通信节点的自动发现过程中引入布隆过滤器,其中布隆过滤器的主要原理是通过检索一个元素是否在一个集合中来进行数据过滤,如统一资源定位器(uniform resource locator,URL)去重、垃圾邮件识别、重复元素判断等,以避免对重复元素的处理带来的不必要的内存资源和计算资源的消耗,以及带来的不必要的时延的增加。
在基于布隆过滤器进行分布式系统中通信节点之间的发现和建链时,节点A可以将节点A中所有数据写入模块(DataWriter)和数据读取模块(DataReader)对应的主题以一定规则或算法(如布隆表规则或算法)映射在bit数组(也称布隆表)中发送给节点B。例如,请参考图5,图5示出了本申请实施例提供的一种布隆表规则示意图;如图5所示,可以通过布隆表规则或算法将词条1对应的主题和词条2对应的主题映射至bit数组中,如在主题存在时在对应的一个或多个比特位上置1,在主题不存在时在对应的一个或多个比特位上置0,其中图5以词条1对应的主题映射比特1、4、7,词条2对应的主题映射比特3、4、8作为示例。基于此,节点B可以根据节点A发送的bit数组中状态为1的字段,采用同样的规则或算法逆向计算,确定该字段对应的主题是否存在,进而基于此判断对应的主题是否与本端的主题匹配。
示例性地,以布隆过滤器应用于DDS分布式架构为例,通信节点之间基于布隆表规则或算法的通信过程可能如下所示:
可以理解,基于“Add BF to Participant DATA A message”,节点A可以通过SPDP消息向其它节点(如包括节点B)发送生成的布隆表,其它节点(如包括节点B)在接收到SPDP消息会后,可以从中获取布隆表,然后采用同样的规则或算法逆向计算确定节点A存在的主题,并基于此判断本端与节点A中是否有匹配的主题。例如,在节点B确定本端有主题与节点A的主题匹配时,可以执行“Send Endpoint information(SSEDP message)to the remote Participant”以向节点A发送包含能够匹配的主题的信息的SEDP消息;否则(即节点B本端没有主题与节点A的主题匹配),节点B不向节点A发送SEDP消息。基于此,可以实现有选择性的SEDP消息的发送,缩短通信节点之间建链所需的时长,降低内存资源以及计算资源的消耗。
但是,基于布隆过滤器进行分布式系统中通信节点之间的发现和建链目前存在以下问题:
问题1:主要是在SEDP阶段实现有选择性的SEDP消息的发送,因此在缩短建链所需时长、降低内存资源以及计算资源方面还有可以优化的空间。
问题2:对于大规模拓扑结构的分布式架构,布隆表长度通常较大(如516字节),如误报率为0.1,布隆表长度如480B;特别对于未来智能驾驶向L3、L4甚至L5级别演进时,布隆表长度很可能超过1500B。这会造成SPDP消息长度大大增加,进而造成内存资源以及计算资源的消耗增加等。
问题3:存在误报问题。如,误报率p与布隆表的长度m关系为:m=nlnp/(ln2)2,其中n为主题个数。尤其布隆表的长度m越长,误报率越高。
问题4:该方案仅适用于支持布隆过滤器的通信节点,若两个通信节点能力不匹配,则无法顺利基于布隆过滤器按完成发现和建链。
问题5:该方案无法在通信节点有新增数据写入模块(DataWriter)或数据读取模块(DataReader)时相应的进行布隆表更新。
问题6:该方案要求通信节点在创建数据写入模块(DataWriter)和数据读取模块(DataReader)前就预知所有数据写入模块(DataWriter)和数据读取模块(DataReader)的主题,但是在一些特殊场景下,如类ROS接口场景下,是由ROS接口调用DDS接口进行通信节点的创建及消息的发送。由于ROS接口不对外暴露DDS的发布订阅模型,而是以topic为粒度创建并声明发布节点或订阅节点;具体的,若某一topic的参与者(participant)未创建,则创建该参与者(participant),并且创建其中的数据写入模块(DataWriter)/数据读取模块(DataReader);若某一topic的参与者(participant)已创建,则直接创建其中的数据写入模块(DataWriter)/数据读取模块(DataReader)。这就会导致参与者(participant)仅获取了该一个topic的信息便开始建链工作,因此无法基于布隆过滤器进行分布式系统中通信节点之间的发现和建链。
为了常规的分布式系统中通信节点之间互相发现和建链过程中存在的上述问题,提高通信节点之间建链的效率和可靠性,且可以节省内存、计算等开销,本申请实施例提供一种节点间的建链方法,该方法可以在通信节点发现阶段以及各个通信节点中数据写入模块/数据读取模块的发现阶段均在最大限度地节省内存、计算等开销。示例性地,本申请实施例提供的方案中,一个通信节点(记作第二节点)可以在通信节点发现阶段向分布式系统中其它通信节点(记作第一节点)发送紧凑型比特序列,以通过紧凑型比特序列的不同比特分别表征第二节点对应的主题的可用状态。例如,紧凑型比特序列包括M(M为正整数)个比特,M个比特分别表征所述第二节点相关的M个不同主题的可用状态。基于此,第一节点在接收到该紧凑型比特序列后,与本地的紧凑型比特序列进行比较,判断两者之间是否有主题能够匹配;若有,则进入后续通信节点中数据写入模块/数据读取模块的发现阶段;若无,则不进行后续通信,以及进一步地还可以在后续收到来自第二节点的SPDP消息时不做处理或者简单处理。
其中,本申请实施例中所述通信节点可以理解为能够实现某一类业务任务或者业务功能的子模块的集合,或者能够实现某一具体业务任务或者业务功能的子模块的集合,一个通信节点中可以包括至少一个数据写入模块(DataWriter)和/或至少一个数据读取模块(DataReader)。在一个通信节点中包括多个子模块时,该多个子模块通常可以用于为同一类业务任务或者业务功能提供相同或者相关的支持作用,或者为同一业务任务或者业务功能提供相同或者相关的支持作用。通信节点对应的主题可以用于表征通信节点支持的业务任务或者业务功能。
作为一种示例,本申请实施例中所述主题的方式可以包括但不限于以下任意一个或多个:业务任务名称/业务功能名称、消息类型、发布者与订阅者的关系、逻辑通道、隔离分组等,以方便多个通信节点基于此来决策是否需要建立彼此之间的发布订阅关系。例如,通信节点之间可以根据彼此的主题是否匹配来决策是否建立彼此之间的发布订阅关系,如若通信节点之间的主题匹配则建立发布订阅关系,若通信节点之间的主题不匹配则不建立发布订阅关系。
其中,主题匹配包括但不限于主题相同、主题相关。例如,以通信节点对应的主题是业务任务名称/业务功能名称为例,通信节点之间可以根据彼此的业务任务名称/业务功能名称是否相同来判断彼此的主题是否匹配;以通信节点对应的主题是消息类型为例,通信节点之间可以根据彼此的消息类型是否相同来判断彼此的主题是否匹配,或者通信节点之间可以根据彼此的消息类型是否相关来判断彼此的主题是否匹配,其中消息类型相关如同属一个业务任务/业务功能类别;以通信节点对应的主题是发布者与订阅者的关系列表为例,通信节点之间可以根据彼此的列表中是否包括彼此之间的关系对来判断彼此的主题是否匹配;以通信节点对应的主题是逻辑通道为例,通信节点之间可以根据彼此是否拥有同一个逻辑通道来判断彼此的主题是否匹配;以通信节点对应的主题是隔离分组为例,通信节点之间可以根据彼此是否位于同一个分组中来判断彼此的主题是否匹配。示例性地,本申请实施例所述分布式架构可以指任意应用领域下的分布式系统,如包括但不限于智能驾驶领域、智能机器人领域、物联网领域、智慧医疗领域、智能教育领域、智能城市领域、铁路调度领域等等,本申请实施例不做限定。以及,本申请实施例所述分布式架构可以指任意通过通信节点发现阶段以及各个通信节点中数据写入模块/数据读取模块的发现阶段完成通信节点间建链的分布式架构,如包括但不限于DDS分布式架构、去中心化模式的SOME/IP分布式架构、ROS2分布式架构等,本申请实施例不做限定。
示例性地,以智能驾驶领域的分布式系统为例,请参考图6,图6示出了本申请实施例提供的一种智能车系统架构图。如图6所示,智能车系统可以包括远程信息处理盒(telematics box,T-Box)、分布式网关(如MCU)以及在同一硬件平台上承载的多个操作系统实现的不同功能的多个域控制器,如智驾域控制器、仪表域控制器、座舱域控制器、底盘域控制器、动力域控制器、车身域控制器等(图6以智驾域控制器、座舱域控制器和底盘域控制器等作为示例)。多个域控制器可以在实现车载计算单元的硬件整合和算力共享的同时,实现不同域之间的安全隔离,同时有效降低整车成本。
其中,T-Box和多个域控制器及分布式网关之间依赖以太网进行通信。T-Box内部、域控制器内部或分布式网关内部也存在应用之间的操作系统内的内存通信共享、跨片通信(对于内部有多个芯片的情况)、隔离分区间通信等。
其中,智驾域控制器主要用于提供自动驾驶感知、决策等业务,如图像信息的接收、图像信息的处理和判断、数据的处理和计算、导航与路线规划、对于实时情况的快速判断和决策,智驾域需要处理感知、决策、控制三个层面的算法,对于域控制器的软硬件要求都最高。仪表域控制器主要用于提供从车辆速度、发动机转速、驱动能量等的仪表化或界面化展示等。座舱域控制器主要用于控制车辆的智能座舱中的各种电子信息系统功能,如中控系统、车载信息娱乐系统、抬头显示、座椅系统、仪表系统、后视镜系统、驾驶行为监测系统、导航系统等。底盘域控制器主要用于控制车辆的行驶行为和行驶姿态,其功能包括但不限于制动系统管理、车传动系统管理、行驶系统管理、转向系统管理、车速传感器管理、车身姿态传感器管理、空气悬挂系统管理、安全气囊系统管理等。动力域控制器主要用于控制车辆的动力组成,优化车辆的动力表现,保证车辆的动力安全,如发动机管理、变速箱管理、电池管理、动力分配管理、排放管理、限速管理、节油节电管理等。车身域控制器主要用于控制各种车身功能,包括但不限于对于车前灯、车后灯、内饰灯、车门锁、车窗、天窗、雨刮器、电动后备箱、智能钥匙、空调、天线、网关通信等的控制。
通常,T-Box、域控制器或分布式网关上均可以部署有用于实现多种业务任务或者业务功能的应用,多个节点之间可以基于分布式通信协同进行相同或相关业务任务或者业务功能的实现。其中,T-Box、域控制器和分布式网关等相互之间的协同依赖于相互之间的正确建链,正确建链依赖于彼此的自动发现。
需要说明,图6仅作为一种智能车系统架构示例,本申请实施例不限定智能车系统架构中所包括的具体组成部分,例如图6所示分布式网关还可以与其它域控制器或者T-Box等协同进行相同或相关业务任务或者业务功能的实现。
以及,需要说明,本申请实施例所述车是一个广义的概念,例如,本申请实施例所述车可以是交通工具(如轿车、公共汽车、地铁、高铁、摩托车、飞行车、火车等),工业车辆(如叉车、挂车、牵引车等),工程车辆(如挖掘机、推土机、吊车等),农用设备(如割草机、收割机等),游乐设备,玩具车辆,船、气垫船、潜水艇、飞机、直升机等。本申请实施例对车的具体类型、型态和功能等不做限定。
当然,本申请实施例提供的方案也可以应用于其它运载工具,如水上交通工具、空中交通工具、工业设备、农业设备或娱乐设备等。
作为一种示例,请参考图7,图7以DDS分布式架构中的通信节点为例,示出了本申请实施例提供的一种通信节点的框架示意图。如图7所示,通信节点可以包括接口层、远程过程调用(remote procedure call,RPC)模块、QoS模块、资源管理模块、数据收发模块、SPDP模块、SEDP模块、通道抽象模块。
其中,接口层由上层应用调用,基于DDS通信进行节点创建、消息发送、消息接收、QoS配置等。
RPC模块可以简单理解为用于对接接口层和数据收发模块进行消息的一来一回的收发,比如本端请求远端提供一个服务,如数据计算,远端会根据请求进行数据处理,并把计算好的数据回复给本地,在这一过程中RPC可以用于负责进行数据的包装。
QoS模块可以通过接口配置,依赖资源管理模块缓存管理数据,依赖数据收发模块实现一些QoS的功能,比如reliable QoS时要收发Heartbeat、Acknack等消息。
资源管理模块主要用于管理通道资源、缓存资源等。通道资源如包括但不限于用户数据报协议(user datagram protocol,UDP)通道资源、共享内存资源等;管理缓存资源如用于缓存数据收发模块收发的数据,比如Reliable QoS模式下,发送端要依赖高速缓存(cache)存放已发送的数据包,以便一旦对端告知没有收到该数据,则直接从高速缓存(cache)中取出该数据再次发送。
数据收发模块主要用于负责业务报文和控制报文的收发,数据报文就是用户要收发的数据,控制报文就是自动发现需要传输的SPDP报文、SEDP报文,以及Heartbeat、AckNack、Gap等这类负责管理的报文。例如,数据收发模块可以在收发信息时根据资源管理模块指示的传输通道,调用通道抽象进行信息收发。
SPDP模块主要用于进行SPDP阶段的通信,以便系统中的各个通信节点之间可以相互发现。
SEDP模块主要用于进行SEDP阶段的通信,以便系统中的各个通信节点中数据写入模块/数据读取模块之间可以相互发现。
通道抽象模块主要用于对UDP、TCP、共享内存等各种底层通道进行抽象。
如图7所示,本申请实施例提供的方案可以在自动发现阶段引入紧凑型比特序列(Dense Bitlist)(记作改进点1)。其中,紧凑型比特序列包括多个比特,多个比特分别表征通信节点相关的多个不同主题的可用状态,一个比特表征通信节点相关的一个主题的可用状态。对应地,对端节点在接收到该紧凑型比特序列后,与对端节点本地的紧凑型比特序列进行比较,判断两者之间是否有主题能够匹配以判断两者之间是否需要建立发布订阅关系;若有,则进入后续通信节点中数据写入模块/数据读取模块的发现阶段;若无,则不进行后续通信,以及进一步地还可以在后续收到来自该通信节点的SPDP消息时不做处理或者简单处理。由于紧凑型比特序列所包括的比特数与通信节点相关的主题数相同或者相当(如仅多出了少量的预留比特位),因此可以保证紧凑型比特序列的长度保持在一定的尺寸(如50字节)内,因此不会对SPDP阶段的消息的长度造成影响,且可以降低误报率,实现通信节点之间的快速发现;另外,基于紧凑型比特序列的比较结果进行有选择性的后续的消息发送,一方面可以降低内存资源以及计算资源的消耗,另一方面还可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。也即,基于此,可以解决传统布隆过滤器方案存在的上述问题2和问题3。
在一些实施例中,如图7所示,本申请实施例提供的方案还可以在自动发现阶段引入用于记录不匹配的远端节点的不匹配列表(Useless Remote),如将经过紧凑型比特序列比较后与本端节点没有主题能够匹配的远端节点(即无关的远端节点)的标识记录在该列表中(记作改进点2)。基于此,后续若再次接收到来自该远端节点的SPDP消息时,可以不做处理或者简单处理。如此,可以在SPDP阶段进行有选择性的消息处理,一方面可以降低内存资源以及计算资源的消耗,另一方面还可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。也即,基于此,可以解决传统布隆过滤器方案存在的上述问题1。
在一些实施例中,如图7所示,本申请实施例提供的方案还可以在自动发现阶段引入紧凑型比特序列的基础上引入传统的布隆过滤器,如引入布隆表(Bloom Bitlist),其中布隆表中包括的多个比特分别表征通信节点相关的多个未知主题(如未在紧凑型比特序列中查找到对应比特位的主题)的可用状态(记作改进点3)。对应地,对端节点在接收到该布隆表后,可以采用传统的布隆过滤方法,判断两者之间是否有主题能够匹配以判断两者之间是否需要建立发布订阅关系;若有,则进入后续通信节点中数据写入模块/数据读取模块的发现阶段;若无,则不进行后续通信。基于紧凑型比特序列以及布隆表进行是否建立发布订阅关系的判断,可以在降低内存资源以及计算资源的消耗、缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链的同时,进一步降低误报率。也即,基于此,可以解决传统布隆过滤器方案存在的上述问题3。
在一些实施例中,如图7所示,本申请实施例提供的方案还可以在自动发现阶段引入版本适配机制(记作改进点4)。如,本地节点可以根据来自远端节点的SPDP消息中携带的版本标识(如Version Label)确定远端节点能够支持的DDS协议版本,以便在其版本与本地节点支持的DDS协议版本不一致时进行版本适配,以便两端可以顺利进行后续的通信过程。又如,本地节点可以根据来自远端节点的SPDP消息中是否携带有预设的信息(如是否携带紧凑型比特序列)来确定远端节点能够支持的DDS协议版本,以便在其版本与本地节点支持的DDS协议版本不一致时进行版本适配,以便两端可以顺利进行后续的通信过程。基于此,可以在两个通信节点所支持的DDS协议版本不一致时依旧可以兼容,以顺利进行后续的通信过程。也即,基于此,可以解决传统布隆过滤器方案存在的上述问题4。
在一些实施例中,如图7所示,本申请实施例提供的方案还可以在自动发现阶段引入新增标识(记作改进点5),如本地节点可以在有模块(或主题)新增时向远端节点发送新增模块的主题(或者新增主题)以及新增标识,其中新增标识用于指示远端节点本次新消息的发送涉及新增模块的主题(或者新增主题)。对应地,远端节点在接收到携带新增标识的消息后,会根据其中携带的主题判断两者之间是否需要建立发布订阅关系;若有,则进入后续通信节点中数据写入模块/数据读取模块的发现阶段;若无,则不进行后续通信。基于此,可以保证在有模块(或主题)新增时仍然可以以较低的误报率实现通信节点之间的快速建链。也即,基于此,可以解决传统布隆过滤器方案存在的上述问题5。
在一些实施例中,本申请实施例提供的方案还可以在自动发现阶段引入主题信息文件的提前解析(记作改进点6),如在参与者(participant)的数据写入模块(DataWriter)/数据读取模块(DataReader)还未创建时,通过解析XML文件、JSON文件、YAML文件等包括节点相关主题的格式化文件提前获取节点相关的主题信息,以支持在一些类ROS接口场景等特殊场景下,基于紧凑型比特序列和/或布隆表实现通信节点之间的正常发现和建链。也即,基于此,可以解决传统布隆过滤器方案存在的上述问题6。
需要说明,图7示出了一种通用的通信节点的框架示意图,在本申请实施例中,第一节点和第二节点等通信节点均可以具有图7所示的功能框架。
另外,需要说明,图7所述对自动发现阶段的改进仅作为一种示例,在实际应用中,上述各个改进点之间可以自由组合,即上述改进点1-6中的至少两个可以任意组合以对自动发现阶段进行改进。例如,本申请实施例支持在引入紧凑型比特序列的基础上,引入以下一个或多个改进:叠加发送布隆表、不匹配的远端节点的列表、版本适配机制、新增标识、主题信息文件的提前解析。又如,本申请实施例支持在引入发送布隆表的基础上,引入以下一个或多个改进:不匹配的远端节点的列表、版本适配机制、新增标识、主题信息文件的提前解析。
以下将以DDS分布式架构为例,结合具体实施例1和实施例2,对本申请实施例提供的节点间的建链方法进行具体介绍。其中,以下实施例1主要介绍在引入紧凑型比特序列的基础上,引入以下一个或多个改进:叠加发送布隆表、不匹配的远端节点的列表、版本适配机制、新增标识、主题信息文件的提前解析;以下实施例2主要介绍在引入发送布隆表的基础上,引入以下一个或多个改进:不匹配的远端节点的列表、版本适配机制、新增标识、主题信息文件的提前解析。
在实施例1中,一个通信节点(记作第二节点)可以在自动发现的SPDP阶段向系统内的其它通信节点(记作第一节点)发送其自身(即第二节点)的紧凑型比特序列,其中第二节点的紧凑型比特序列包括多个比特,多个比特分别表征通信节点相关的多个不同主题的可用状态,一个比特表征通信节点相关的一个主题的可用状态。系统内的其它通信节点(记作第一节点)在接收到第二节点的紧凑型比特序列后,与本地的紧凑型比特序列(即第一节点的紧凑型比特序列)进行比较,以判断两者之间是否有主题能够匹配,进而判断是否建立两者之间的发布订阅关系。
作为一种可能,第一节点与第二节点有能够匹配的主题,则第一节点与第二节点进行后续的SEDP阶段,以发现第二节点中与第一节点主题匹配的数据写入模块(DataWriter)和/或数据读取模块(DataReader),完成建链,建立发布订阅关系。
作为另一种可能,第一节点与第二节点没有能够匹配的主题,则第一节点与第二节点不进行后续的SEDP阶段,如第一节点不向第二节点发送SEDP消息。
作为一种示例,请参考图8,图8以第一节点和第二节点之间的发现和建链为例,示出了本申请实施例提供的一种节点间的建链方法流程图。如图8所示,本申请实施例提供的节点间的建链方法可以基于S801-S805实现:
S801:第二节点生成第一信息,第一信息包括M(M为正整数)个比特,M个比特分别表征第二节点相关的M个不同第一主题的可用状态。
作为一种示例,第二节点相关的第一主题与第二节点能够支持的业务任务或者业务功能有关,例如第二节点相关的第一主题可以表征第二节点能够支持的业务任务或者业务功能。关于第一主题表征业务任务或者业务功能的具体方式,本申请实施例不做限定,如第一主题可以通过以下任意一个或多个方式来表征第二节点能够支持的业务任务或者业务功能:业务任务名称/业务功能名称、消息类型、发布者与订阅者的关系、逻辑通道、隔离分组等。另外,本申请实施例也不限定业务任务或者业务功能的具体表征形式,如第一主题可以通过关键词、标识等形式表征第二节点能够支持的业务任务或者业务功能。
作为一种示例,第一信息可以是紧凑型比特序列(Dense Bitlist),紧凑型比特序列包括多个比特,多个比特分别表征第二节点相关的多个不同第一主题的可用状态,一个比特表征第二节点相关的一个第一主题的可用状态。
作为一种示例,第一信息可以是第二节点通过在预设信息表中查询第二节点所承载的应用相关的主题(topic),并根据查询结果遵循一定的映射规则将第二节点相关的多个不同可用第一主题映射至对应的比特生成的,如以单比特(bit)的方式记录在紧凑型比特序列(Dense Bitlist)中。例如,在某一主题能够在预设信息表中查询到时,将其对应的比特位置为第一预设标识;若某一主题在预设信息表中没有查询到时,将其对应的比特位置为第二预设标识或者不在紧凑型比特序列(Dense Bitlist)中记录其对应的比特。其中,第一预设标识如1,第二预设标识如0;或者,第一预设标识如0,第二预设标识如1。
示例性地,在生成紧凑型比特序列(Dense Bitlist)时,分布式系统中的所有通信节点(包括第一节点和第二节点)遵循相同的映射规则,以便于各个通信节点可以快速、准确的进行主题的匹配。
其中,上述预设信息表可以是开发者预先输入至第二节点或者分布式系统的,例如预设信息表可以包括整车部署的应用相关的所有主题的信息(如主题名称(TopicName))。示例性地,预设信息表可以包括但不限于包括整车部署的应用相关的所有主题的信息的XML文件、JSON文件、YAML文件等,不做具体限定。
作为一种示例,假设分布式系统应用类ROS场景,第二节点可以调用文件解析接口,解析格式化文件以生成第一信息。其中,格式化文件包括整车部署的应用相关的所有主题的信息(如主题名称(TopicName)),因此也包括第二节点相关的M个不同第一主题的信息。示例性地,格式化文件可能是开发者预先输入至第二节点或者分布式系统的。格式化文件可以包括但不限于以下任意一种或多种类型的文件:XML文件、JSON文件、YAML文件等。
其中,格式化可能以一个文件对应一个通信节点的形式存储,也可以以一个文件对应多个通信节点(如分布式系统中的所有通信节点)的形式存储,本申请实施例不做限定。对于一个格式化文件对应非所有通信节点的情况,开发者可以提前在描述通信节点的文件中增加用于描述通信节点特征的字符串,这样通信节点在调用文件解析接口时,可以根据通信节点对应的字符串从对应的文件中查找其相关的主题的信息。
示例性地,请参考图9,图9示出了本申请实施例提供的一种紧凑型比特序列的生成过程示意图。如图9所示,第二节点可以在应用做准备工作时,如应用初始化(initialize)或创建节点(createParticipant)时,解析格式化文件生成紧凑型比特序列1(即第一信息),紧凑型比特序列1是根据格式化文件,遵循一定的映射规则将第二节点相关的多个不同可用第一主题映射至对应的比特位生成的。如此,在完成应用初始化(initialize)或创建节点(createParticipant)后,第二节点可以正常进行数据写入模块(DataWriter)和/或数据读取模块(DataReader)的创建。
可以理解,类ROS接口场景下,ROS接口不对外暴露DDS的发布订阅模型,而是以topic为粒度创建并声明发布节点或订阅节点,这一特殊机制可能会导致通信节点可能在仅获取了少量主题的信息时便开始建链工作,也就是说类ROS接口场景下获取的主题信息并不全。但是,分布式系统中各个通信节点相关的主题通常是提前开发者预先写入代码或者配置文件(如预先写入预设信息表或者预先配置在格式化文件中)中的,基于此,本申请实施例通过提前基于预设信息表或者提前解析格式化文件生成第一信息,因此也可以在类ROS接口场景基于图8所示的方案顺利进行通信节点之间的发现和建链。
作为一种示例,请参考图10,图10以第一信息和第二信息是紧凑型比特序列(Dense Bitlist),第二节点通过SPDP消息向第一节点发送第一信息为例,示出了本申请实施例提供的一种分布式系统中通信节点之间的发现和建链过程示意图。如图10所示,第二节点可以通过查表或者解析格式化文件以生成紧凑型比特序列1(即第一信息)。
S802:第一节点生成第二信息,第二信息包括N(N为正整数)个比特,N个比特分别表征第一节点相关的N个不同第二主题的可用状态。
作为一种示例,第一节点相关的第二主题与第一节点能够支持的业务任务或者业务功能有关,例如第一节点相关的第二主题可以表征第一节点能够支持的业务任务或者业务功能,关于第二主题表征业务任务或者业务功能的具体方式,本申请实施例不做限定,如第二主题可以通过以下任意一个或多个方式来表征第一节点能够支持的业务任务或者业务功能:业务任务名称/业务功能名称、消息类型、发布者与订阅者的关系、逻辑通道、隔离分组等。另外,本申请实施例也不限定业务任务或者业务功能的具体表征形式,如第二主题可以通过关键词、标识等形式表征第一节点能够支持的业务任务或者业务功能。
作为一种示例,第二信息可以是紧凑型比特序列(Dense Bitlist),紧凑型比特序列包括多个比特,多个比特分别表征第一节点相关的多个不同第二主题的可用状态,一个比特表征第一节点相关的一个第二主题的可用状态。
作为一种示例,第二信息可以是第一节点通过在预设信息表中查询第一节点所承载的应用相关的主题(topic),并根据查询结果生成的,如以单比特(bit)的方式记录在紧凑型比特序列(Dense Bitlist)中。例如,在某一主题能够在预设信息表中查询到时,将其对应的比特位置为第一预设标识;若某一主题在预设信息表中没有查询到时,将其对应的比特位置为第二预设标识或者不在紧凑型比特序列(Dense Bitlist)中记录其对应的比特。其中,第一预设标识如1,第二预设标识如0;或者,第一预设标识如0,第二预设标识如1。
其中,上述预设信息表可以是开发者预先输入至第一节点或者分布式系统的,例如预设信息表可以包括整车部署的应用相关的所有主题的信息(如主题名称(TopicName))。示例性地,预设信息表可以包括但不限于包括整车部署的应用相关的所有主题的信息的XML文件、JSON文件、YAML文件等,不做具体限定。
作为一种示例,假设分布式系统应用类ROS场景,第一节点可以调用文件解析接口,解析格式化文件以生成第二信息。其中,格式化文件包括整车部署的应用相关的所有主题的信息(如主题名称(TopicName)),因此也包括第一节点相关的N个不同第二主题。示例性地,格式化文件可能是开发者预先输入至第一节点或者分布式系统的。格式化文件可以包括但不限于以下任意一种或多种类型的文件:XML文件、JSON文件、YAML文件等。
示例性地,如图10所示,第一节点可以通过查表或者解析格式化文件以生成紧凑型比特序列2(即第二信息)。
例如,第一节点可以在应用做准备工作时,如应用初始化(initialize)或创建节点(createParticipant)时,解析格式化文件生成紧凑型比特序列2(即第二信息),紧凑型比特序列2是根据格式化文件,遵循一定的映射规则将第一节点相关的多个不同可用第二主题映射至对应的比特位生成的。如此,在完成应用初始化(initialize)或创建节点(createParticipant)后,第一节点可以正常进行数据写入模块(DataWriter)和/或数据读取模块(DataReader)的创建。
需要说明,本申请实施例不限定第二节点执行S801和第一节点执行S802的先后顺序,S801可能发生在S802之前,也可能发生在S802之后,还可能与S802同时发生。
S803:第二节点向第一节点发送第一信息。
其中,第二节点向第一节点发送第一信息用于第一节点判断是否向第二节点发送SEDP消息,以及用于第一节点在确定向第二节点发送SEDP消息时确定携带在SEDP消息中的主题信息。
作为一种可能的实现方式,第二节点可以在SPDP阶段向第一节点发送第一信息。例如,第一信息可以携带在SPDP消息中,如9所示,第二节点通过SPDP消息向第一节点发送紧凑型比特序列1(即第一信息)。当然,第一信息也可以由第二节点单独发送给第一节点,关于第二节点发送第一信息的具体方式,本申请实施例不做具体限定。
需要说明,本申请实施例也不限定承载第一信息的具体数据形式,例如第二节点可以通过submessage(如DDS submessage)或parameter(如DDS parameter)等形式的数据向第一节点发送第一信息。
其中,每种submessage通常代表一个DDS的数据类型,如用户数据、SPDP、SEDP、HeartBeat、AckNack、Gap等数据类型;对于不同种的submessage,DDS分布式系统中的通信节点根据实际情况会有不同的处理规则。例如,使用网络封包分析软件对抓包的submessage进行解析都可以获取其所承载的具体信息,解析结果可能如以下示例1:
示例1:
∨Real-Time Publish-Subscribe Wire Protocal
Magic:RTPS
>Protocol version:2.3
vendorId:xxx.xxx
>guidPrefix:8888f65xxxxxxxxx
>Default port mapping:domainId=0,participantId=0,nature=UNICAST_USERTRAFFIC
>submessageId:INFO_DST(0x0e)
>submessageId:INFO_TS(0x09)
>submessageId:DATA(0x15)
其中,在上述示例1中,INFO_DST表示该消息的目的地是哪里;INFO_TS表示时间戳;DATA是具体数据信息,如SPDP消息,DATA内会存储SPDP的具体信息,如用户的业务报文等。
Parameter通常用于标识本地节点的如域ID、协议版本号、接收地址信息、QoS信息等各类信息。例如,使用网络封包分析软件对抓包的parameter进行解析都可以获取其所承载的具体信息,解析结果可能如以下示例2:
示例2:
∨serializedData
encapsulation kind:PL_CDR_LE(0x0003)
encapsulation options:0x0000
∨serializedData
>PID_DOMAIN_ID
>PID_DOMAIN_TAG
>PID_PROTOCOL_VERSION
>PID_VERSION_ID
>PID_EXPECTS_INLINE_QOS
>PID_BUILTIN_ENDPOINT_SET
>PID_BUILTIN_ENDPOINT_QOS
>PID_DEFAULT_UNICAST_LOCATOR(LOCATOR_KIND_UDPV4,7.183.x.xxx:7411)
>PID_DEFAULT_MULTICAST_LOCATOR(LOCATOR_KIND_UDPV4,23.25.x.xxx:7400)
>PID_METATRAFFIC_UNICAST_LOCATOR(LOCATOR_KIND_UDPV4,7.183.x.xxx:7411)
>PID_METATRAFFIC_MULTICAST_LOCATOR(LOCATOR_KIND_UDPV4,23.25.x.xxx:7400)
>PID_PARTICIPANT_MANUAL_LIVELINESS_COUNT
>PID_PARTICIPANT_GUID
>PID_USER_DATA
>PID_PARTICIPANT_LEASE_DURATION
>PID_SENTINEL
其中,在上述示例2中,serializedData内各种PID代表不同的parameter编号。
S804:第一节点判断第一节点相关的第二主题是否与不同第一主题相匹配。
作为一种示例,第一节点可以通过比较第二信息与第一信息,来判断第一节点相关的第二主题是否与不同第一主题相匹配。
例如,第一节点可以通过对第二信息与第二信息进行位比较,比较第二信息中不同第二主题的可用状态是否与第一信息中不同第一主题的可用状态相同,来判断不同第二主题中是否存在与不同第一主题相匹配的主题。若有,则确定第一节点有与第二节点相匹配的主题;若无,则确定第一节点没有与第二节点相匹配的主题。以及,进一步地,第一节点还可以通过位比较确定第一节点的哪一个第二主题与第一节点的第一主题匹配。
示例性地,以第一信息和第二信息是紧凑型比特序列(Dense Bitlist)为例,如图10所示,第一节点可以对其本地的紧凑型比特序列2和从第二节点接收到的紧凑型比特序列1逐比特进行位比较,判断紧凑型比特序列2中是否有与紧凑型比特序列1中可用的第一主题相匹配的第二主题,以及在有匹配的主题时确定哪一个第二主题与第一节点的第一主题匹配。
可以理解,由于分布式系统中的所有通信节点(包括第一节点和第二节点)在生成各自的紧凑型比特序列(Dense Bitlist)时都遵循相同的映射规则,因此第一节点生成的第二信息与第一节点生成的第一信息所遵循的主题与比特位的映射规则一致,基于此,第一节点可以直接通过对第二信息与第二信息进行位比较,快速、准确地判断第一节点相关的第二主题是否与不同第一主题相匹配。
在执行完S804后,若第一节点相关的第二主题与M个不同第一主题中的至少一个相匹配,第一节点执行S805;若第一节点相关的第二主题与M个不同第一主题均不匹配,第一节点不向第二节点发送SEDP消息。
S805:第一节点向第二节点发送SEDP消息,SEDP中携带有与M个不同第一主题中的至少一个相匹配的第二主题的信息。
示例性地,图10所示第一节点可以在紧凑型比特序列2中有与紧凑型比特序列1中可用的第一主题相匹配的第二主题时,向第二节点发送SEDP消息。其中,SEDP消息中携带有与第一节点的第一主题匹配的第二主题的信息,SEDP消息中携带的上述信息用于进行第一节点与第二节点之间能够匹配的主题对应的数据写入模块(DataWriter)/数据读取模块(DataReader)之间的相互发现和信息传递。
基于图8所提供的实施例,由于紧凑型比特序列所包括的比特数与通信节点相关的主题数相同或相当(如仅多出了少量的预留比特位),因此第二节点与第一节点在SPDP节点基于紧凑型比特序列进行匹配,可以保证紧凑型比特序列的长度保持在一定的尺寸内,因此不会对SPDP阶段的消息的长度造成影响,且可以降低误报率,实现通信节点之间的快速发现;另外,基于紧凑型比特序列进行匹配,第一节点可以有选择性的进行SEDP消息的发送,如在第一节点相关的第二主题与M个不同第一主题均不匹配时,不向第二节点发送SEDP消息,一方面可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,另一方面还可以缩短为相同或相关应用任务/应用功能提供服务的多个通信节点之间建链所需的时长,实现通信节点之间的快速建链。
在一些实施例中,在执行完S804后,若第一节点相关的第二主题与M个不同第一主题均不匹配,如图11所示,第一节点还可以在不匹配列表(Useless Remote)(记作“第一不匹配列表”)中记录第二节点的信息(如节点地址、节点标识等,不做限定),其中第一不匹配列表用于记录与第一节点不匹配的远端节点的信息,与第一节点不匹配的远端节点指与第一节点没有能够匹配的主题的远端节点。基于此,第一节点可以在后续接收到来自第二节点的SPDP消息(如SPDP保活包)时,根据第一不匹配列表中所记录的第二节点的信息确定第二节点与第一节点不匹配,进而不对SPDP消息(如SPDP保活包)进行第一预设解析,第一预设解析如与节点间发现相关的解析处理。也就是说,第一节点可以不对来自不匹配的通信节点的SPDP消息(如SPDP保活包)进行不必要的与节点间发现相关的解析处理,如不做处理或者简单处理,如此,可以在SPDP阶段进行有选择性的消息处理,一方面可以降低内存资源以及计算资源的消耗,另一方面还可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
在一些实施例中,在执行完S804后,若第一节点相关的第二主题与M个不同第一主题均不匹配,如图11所示,第一节点还可以向第二节点发送第四信息(如remote overlap tag)以通知第二节点第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配,如第四信息表征第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配。示例性地,第四信息(如remote overlap tag)可以以预设标识的形式表征第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配。对应地,第二节点可以根据来自第一节点的第四信息更新本地管理和维护的不匹配列表(记作“第二不匹配列表”),如记录第六信息,第六信息表征第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配。示例性地,第二节点可以将第一节点的信息(如节点地址、节点标识等,不做限定)记录在第二不匹配列表中。基于此,后续第一节点和第二节点可以根据各自的不匹配列表有选择性的进行SEDP消息的发送,如第一节点可以在后续接收到来自第二节点的SPDP消息(如SPDP保活包)时,根据第一不匹配列表中所记录的第二节点的信息不对SPDP消息(如SPDP保活包)进行第一预设解析,如不做处理或者简单处理(在一些实施例中,也可以直接删除以节省内部内存);又如第二节点可以在后续接收到来自第一节点的SPDP消息(如SPDP保活包)时,根据第二不匹配列表中所记录的第一节点的信息不对SPDP消息(如SPDP保活包)进行第一预设解析,如不做处理或者简单处理在一些实施例中,也可以直接删除以节省内部内存)。一方面可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,另一方面还可以缩短为相同或相关应用任务/应用功能提供服务的多个通信节点之间建链所需的时长,实现通信节点之间的快速建链。
在一些实施例中,请参考图12,图12示出了本申请实施例提供的一种针对新增主题处理过程示意图。如图12所示,第二节点可以在有新增模块,如有新增数据写入模块(DataWriter)或数据读取模块(DataReader)时将新增模块对应的主题(记作新增主题)通过查询预设信息表或者解析格式化文件更新进第一信息中,并向分布式系统中的其它通信节点(如第一节点,图12以第一节点作为示例)发送第五信息,第五信息用于第一节点判断是否向第二节点发送SEDP消息。其中,第五信息包括第一标识(如runtime new entity tag)和用于表征新增模块对应的主题(记作新增主题)的信息,第一标识用于指示第五信息中携带的信息表征的是与第二节点相关的新增主题。对应地,在接收到来自第二节点的第五信息后,第一节点可以根据其它携带的第一标识(如runtime new entity tag)识别第五信息中携带有新增主题,然后第一节点可以采用与S804类似的方式判断第一节点相关的第二主题是否与第二节点对应的新增主题匹配,如通过比较查找紧凑型比特序列2确定是否有与新增主题匹配的可用主题;若紧凑型比特序列2中有与新增主题匹配的可用主题,第一节点可以向第二节点发送SEDP消息,SEDP中携带有与新增主题相匹配的第二主题的信息,基于此,可以保证在有模块(或主题)新增时仍然可以以较低的误报率实现通信节点之间的快速建链;若紧凑型比特序列2中没有与新增主题匹配的可用主题,第一节点不向第二节点发送SEDP消息。
在一些实施例中,若第一节点通过比较查找紧凑型比特序列2确定紧凑型比特序列2中有与新增主题匹配的可用主题,第一节点还可以查找第一不匹配列表中是否有第二节点的信息;若有,如图12所示,则第一节点将第二节点的信息从第一不匹配列表中删除;若没有,第一节点不做处理。
在一些实施例中,若第一节点通过比较查找紧凑型比特序列2确定紧凑型比特序列2中有与新增主题匹配的可用主题,如图12所示,第一节点还可以向第二节点发送消息(如related tag)以通知第二节点第一节点相关的主题与新增主题匹配。对应地,第二节点可以根据该消息更新本地管理和维护的第二不匹配列表,如若第二不匹配列表中包括第一节点的信息,第二节点可以将第一节点的信息从第二不匹配列表中删除;若第二不匹配列表中原本就不包括第一节点的信息,第二节点不做处理。
在一些实施例中,若第一节点通过比较查找紧凑型比特序列2确定紧凑型比特序列2中没有与新增主题匹配的可用主题,第一节点还可以基于该分析结果更新第一不匹配列表;如,若第一不匹配列表中不包括第二节点的信息,第一节点可以将第二节点的信息记录在第一不匹配列表中;若第一不匹配列表中原本就包括第二节点的信息,第一节点不做处理。
在一些实施例中,若第一节点通过比较查找紧凑型比特序列2确定紧凑型比特序列2中没有与新增主题匹配的可用主题,第一节点可以向第二节点发送消息(如related tag)以通知第二节点第一节点相关的第二主题与新增主题不匹配。对应地,第二节点可以根据来自第一节点的related tag更新本地管理和维护的第二不匹配列表,如若第二不匹配列表中不包括第一节点的信息,第二节点可以将第一节点的信息记录在第二不匹配列表中;若第二不匹配列表中原本就包括第一节点的信息,第二节点不做处理。
需要说明,图12仅以第二节点在有新增模块(如数据写入模块(DataWriter)或数据读取模块(DataReader))时向分布式系统中的第一节点发送第五信息作为示例,在一些实施例中,第二节点也可以在有新增模块时,先判断新增模块对应的主题是否是新的主题;若不是新的主题,不向第一节点发送第五信息;若是新的主题,则向第一节点发送第五信息。例如,第二节点可以通过查找第一信息所表征的第一主题是否包括新增模块对应的主题来判断新增模块对应的主题是否是新的主题,如若包括,则确定新增模块对应的主题不是新增主题,若不包括,则确定新增模块对应的主题是新增主题。
在一些实施例中,各通信节点还可能在标识位于其不匹配列表中的某一通信节点下电(包括但不限于正常下电、异常下电)时,将该下电的通信节点的信息从不匹配列表中删除,以进行状态同步,同时可以最大限度减少不匹配列表中的冗余信息以及减小不匹配列表的尺寸。
在本申请实施例中,第一节点和第二节点可能支持相同的协议版本,也可能支持不同的协议版本,本申请实施例不做限定。当第一节点和第二节点支持不同的协议版本时,为了保证支持不同版本协议的通信节点之间在进行发现与建链过程中的适配依,以实现软件版本兼容,本申请实施例中通信节点之间还可以具备确定其它通信节点版本信息的能力。
作为一种示例,第二节点可以向第一节点发送用于表征第二节点支持的协议版本(记作“第一协议版本”)的信息,如发送第二节点支持的协议版本的标识(Version Label,如PID_PROTOCOL_VERSION),用于第一节点确定在向第二节点发送SPDP消息和SEDP消息时所使用的协议版本。
作为一种示例,第一节点可以根据对第二节点发送给第一节点的消息的解析结果自行识别第二节点支持的协议版本(即第一协议版本)。示例性地,第一节点可以根据对第二节点发送给第一节点的消息中是否携带第一信息(如紧凑型比特序列)来识别第二节点支持的协议版本,如假设第二节点发送给第一节点的消息中携带有第一信息,则识别第二节点支持的协议版本是新的协议版本;假设第二节点发送给第一节点的消息中未携带有第一信息,则识别第二节点支持的协议版本是旧的协议版本。
例如,以第一节点支持第二协议版本、第二节点支持第一协议版本为例,在接收到来自第二节点的消息(如SPDP消息)后,首先,第一节点可以通过解析该消息,根据其中携带的第二节点支持的协议版本的标识识别第二节点支持的第一协议版本,或者根据其中未携带第一信息的解析结果识别第二节点支持的第一协议版本;然后,第一节点可以判断第一节点支持的协议版本(即第二协议版本)是否高于第二节点支持的协议版本(即第一协议版本);若第一协议版本高于或等于第二协议版本,第一节点可以在后续向第二节点发送消息(如SPDP消息或SEDP消息)时基于第二协议版本进行消息发送;若第一协议版本低于第二协议版本时,第一节点可以在后续向第二节点发送消息(如SPDP消息或SEDP消息)时基于第一协议版本进行消息发送。
示例性地,请参考图13,图13以第一节点支持新的协议版本、第二节点支持旧的协议版本为例,示出了本申请实施例提供的一种协议版本适配过程示意图。如图13所示,在接收到来自第二节点的消息(如图13所示SPDP消息)后,第一节点根据SPDP消息中携带的旧的协议版本的标识或者根据SPDP消息中未携带紧凑型比特序列识别出第二节点支持旧的协议版本;基于此,第一节点在后续基于旧的协议版本向第二节点发送消息(如图13所示SPDP消息和/或SEDP消息)。示例性地,如图13所示,第一节点可以记录第二节点支持的旧的协议版本的信息,如为第二节点打上旧的协议版本的标签(Old Version Label),之后,第一节点可以根据该标签(Old Version Label)基于旧的协议版本向第二节点发送消息。
需要说明,本申请实施例所述版本适配机制可以适用于分布式系统的任意场景,如SPDP阶段、模块/主题新增场景等。以模块/主题新增场景为例,如图13所示,假设第一节点接收到了来自第二节点的新增主题和第一标识,第一节点通过查看第二节点对应的标签确定第二节点支持旧的协议版本,在这种情况下,第一节点基于旧的协议版本进行后续与第二节点的通信;又如,假设第一节点由于有新增模块/主题向第二节点发送新增主题和第一标识,第一节点通过查看第二节点对应的标签确定第二节点支持旧的协议版本,在这种情况下,第一节点基于旧的协议版本进行后续与第二节点的通信。
基于此,可以便于通信节点在其支持的协议版本与对端支持的协议版本不一致时进行版本适配,以便两端可以顺利进行后续的通信过程。
需要说明,图13仅以第二节点发起SPDP作为示例,对于第一节点发起SPDP的情况,第一节点先基于其支持的新的协议版本向第二节点发送SPDP消息;对应地,第二节点由于其支持的是旧的协议版本,因此无法成功解析来自第一节点的紧凑型比特序列,因此第二节点通常会默认不做处理。之后,第二节点仍然基于其所支持的旧的协议版本向第一节点发送消息,对应地,第一节点采用与图13类似的处理过程完成与第二节点的协议版本适配,实现软件版本的兼容。
在一些实施例中,为了进一步降低内存资源以及计算资源的消耗,实现通信节点之间的快速建链,第二节点还可以向第一节点发送布隆表(Bloom Bitlist),其中布隆表中包括的多个比特分别表征通信节点相关的多个未知主题(如未在紧凑型比特序列中查找到对应比特位的第四主题)的可用状态。基于此,第一节点可以在判断第一节点相关的第二主题是否与不同第一主题相匹配的基础上,采用传统的布隆过滤方法判断第一节点相关的多个未知主题(如未在紧凑型比特序列中查找到对应比特位的第四主题)与第二节点的第三主题之间是否有主题能够匹配,进而基于结果判断是否建立两者之间的发布订阅关系。
示例性地,请参考图14,图14示出了本申请实施例提供的另一种节点间的建链方法流程图。如图14所示,该方法可以基于如下S801-S802、S1401-S1402、S803、S1403、S1404和S1405实现:
S801:第二节点生成第一信息,第一信息包括M(M为正整数)个比特,M个比特分别表征第二节点相关的M个不同第一主题的可用状态。
S802:第一节点生成第二信息,第二信息包括N(N为正整数)个比特,N个比特分别表征第一节点相关的N个不同第二主题的可用状态。
关于S801-S804可以参考上文中的解释和说明,这里不再重复。
需要说明,本申请实施例不限定第二节点执行S801和第一节点执行S802的先后顺序,S801可能发生在S802之前,也可能发生在S802之后,还可能与S802同时发生。
S1401:第二节点生成第三信息,第三信息包括K(K为正整数)个比特,K个比特表征与第二节点相关的至少一个第三主题的可用状态。
其中,第三主题是与第二节点相关的未知主题,如未在紧凑型比特序列中查找到对应比特位的主题。
作为一种示例,第三信息可以是布隆表(Bloom Bitlist),布隆表包括多个比特,多个比特基于预设的布隆映射机制表征第二节点相关的至少一个第三主题的可用状态。
作为一种示例,第三信息可以是第二节点通过在预设信息表中查询第二节点所承载的应用相关的主题(topic),并根据查询结果生成的。例如,若某一主题在预设信息表中没有查询到,将其可用状态采用预设的布隆映射机制映射至布隆表,如布隆表中的第三预设标识表征其对应的主题可用,第四预设标识表征其对应的主题不可用。其中,第三预设标识如1,第四预设标识如0;或者,第四预设标识如0,第三预设标识如1。
示例性地,请参考图15,图15示出了本申请实施例提供的一种分布式系统中通信节点之间的发现和建链过程示意图。如图15所示,第二节点可以通过查表或者解析格式化文件以生成布隆表1(即第三信息)。
示例性地,在生成布隆表时,分布式系统中的所有通信节点(包括第一节点和第二节点)遵循相同的布隆映射机制,以便于各个通信节点可以快速、准确的进行主题的匹配。
作为一种示例,假设分布式系统应用类ROS场景,第二节点可以调用文件解析接口,解析格式化文件以生成第三信息。其中,格式化文件包括第二节点相关的K个不同第三主题的信息。例如,第二节点可以在应用做准备工作时,如应用初始化(initialize)或创建节点(createParticipant)时,解析格式化文件生成布隆表1,布隆表1是根据格式化文件,遵循一定的布隆映射规则将第二节点相关的多个不同可用第三主题映射至对应的比特位生成的。如此,在完成应用初始化(initialize)或创建节点(createParticipant)后,第二节点可以正常进行数据写入模块(DataWriter)和/或数据读取模块(DataReader)的创建。
S1402:第一节点生成第七信息,第七信息包括L(L为正整数)个比特,L个比特分别表征第一节点相关的至少一个第四主题的可用状态。
其中,第四主题是与第一节点相关的未知主题,如未在紧凑型比特序列中查找到对应比特位的主题。
作为一种示例,第七信息可以是布隆表(Bloom Bitlist),布隆表包括多个比特,多个比特基于预设的布隆映射机制表征第一节点相关的至少一个第四主题的可用状态。
作为一种示例,第七信息可以是第一节点通过在预设信息表中查询第一节点所承载的应用相关的主题(topic),并根据查询结果生成的。例如,若某一主题在预设信息表中没有查询到,将其可用状态采用预设的布隆映射机制映射至布隆表,如布隆表中的第三预设标识表征其对应的主题可用,第四预设标识表征其对应的主题不可用。其中,第三预设标识如1,第四预设标识如0;或者,第四预设标识如0,第三预设标识如1。
如图15所示,第一节点可以通过查表或者解析格式化文件以生成布隆表2(即第七信息)。
作为一种示例,假设分布式系统应用类ROS场景,第一节点可以调用文件解析接口,解析格式化文件以生成第七信息。其中,格式化文件包括第一节点相关的L个不同第四主题的信息。例如,第一节点可以在应用做准备工作时,如应用初始化(initialize)或创建节点(createParticipant)时,解析格式化文件生成布隆表2,布隆表2是根据格式化文件,遵循一定的布隆映射规则将第一节点相关的多个不同可用第四主题映射至对应的比特位生成的。如此,在完成应用初始化(initialize)或创建节点(createParticipant)后,第一节点可以正常进行数据写入模块(DataWriter)和/或数据读取模块(DataReader)的创建。
需要说明,本申请实施例不限定第二节点执行S1401和第一节点执行S1402的先后顺序,S1401可能发生在S1402之前,也可能发生在S1402之后,还可能与S1402同时发生。
S803:第二节点向第一节点发送第一信息。
S1403:第二节点向第一节点发送第三信息。
其中,第二节点向第一节点发送第三信息用于第一节点判断是否向第二节点发送SEDP消息,以及用于第一节点在确定向第二节点发送SEDP消息时确定携带在SEDP消息中的主题信息。
在一些示例中,第二节点可以通过同一消息向第一节点发送第一信息和第三信息;也就是说,图14所示S803和S1403可以是一个步骤;在另一些示例中,第二节点可以通过不同消息向第一节点发送第一信息和第三信息,本申请实施例不做限定,图14仅以第二节点通过不同消息向第一节点发送第一信息和第三信息作为示例。
作为一种示例,第三信息可以携带在SPDP消息中。以第二节点通过同一消息向第一节点发送第一信息和第三信息为例,如图15所示,第二节点通过SPDP消息向第一节点发送布隆表1(即第三信息)和紧凑型比特序列1(即第一信息)。
需要说明,本申请实施例不限定承载第三信息的具体数据形式,例如第二节点可以通过submessage(如DDS submessage)或parameter(如DDS parameter)等形式的数据向第一节点发送第三信息。
S1404:第一节点判断第一节点相关的第四主题是否与上述至少一个第三主题相匹配。
作为一种示例,第一节点可以根据布隆过滤器的策略判断第一节点相关的第四主题是否与上述至少一个第三主题相匹配。例如,第一节点可以采用相同的布隆映射机制进行第三信息和第七信息的主题映射,判断第一节点相关的第四主题与第二节点的第三主题之间是否有主题能够匹配。若有,则确定第一节点有与第二节点相匹配的第四主题;若无,则确定第一节点没有与第二节点相匹配的第四主题。以及,进一步地,第一节点还可以采用相同的布隆映射机制确定第一节点的哪一个第四主题与第一节点的第三主题匹配。
需要说明,本申请实施例不限定第一节点执行S804和S1404的先后顺序,S804可能发生在S1404之前,也可能发生在S1404之后,还可能与S1404同时发生。
可以理解,由于分布式系统中的所有通信节点(包括第一节点和第二节点)在生成各自的布隆表时都遵循相同的布隆映射机制,因此第一节点生成的第七信息与第一节点生成的第三信息所遵循的主题与比特位的映射规则一致,基于此,第一节点可以直接采用相同的布隆映射机制,快速、准确地判断第一节点相关的第四主题是否与不同第三主题相匹配。
在执行完S804和S1404后,若第一节点相关的第二主题与M个不同第一主题中的至少一个相匹配,和/或,第一节点相关的第四主题与至少一个第三主题中的至少一个相匹配,第一节点执行S1405;若第一节点相关的第二主题与M个不同第一主题均不匹配,且第一节点相关的第四主题与至少一个第三主题均不匹配,第一节点不向第二节点发送SEDP消息。
S1405:第一节点向第二节点发送SEDP消息,SEDP中携带有与M个不同第一主题中的至少一个相匹配的第二主题的信息和/或与至少一个第三主题中的至少一个相匹配的第四主题的信息。
示例性地,图15所示第一节点可以在紧凑型比特序列2中有与紧凑型比特序列1中可用的第一主题相匹配的第二主题,和/或,基于布隆表2与布隆表1确定布隆表2所指示的第四主题中有与布隆表1所指示的第三主题相匹配时,向第二节点发送SEDP消息。其中,SEDP消息中携带有与第一节点的第一主题匹配的第二主题的信息和/或与第一节点的第三主题相匹配的第四主题的信息,SEDP消息中携带的上述信息用于进行第一节点与第二节点之间能够匹配的主题对应的数据写入模块(DataWriter)/数据读取模块(DataReader)之间的相互发现和信息传递。
基于图14所提供的实施例,由于紧凑型比特序列所包括的比特数与通信节点相关的主题数相同或者相当,因此第二节点与第一节点在SPDP节点基于紧凑型比特序列进行匹配,可以保证紧凑型比特序列的长度保持在一定的尺寸内,因此不会对SPDP阶段的消息的长度造成影响,且可以降低误报率,实现通信节点之间的快速发现;另外,基于混合序列(即紧凑型比特序列和布隆表)进行匹配,可以进一步避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,以及进一步缩短为相同或相关应用任务/应用功能提供服务的多个通信节点之间建链所需的时长,实现通信节点之间的快速建链。
在一些实施例中,在执行完S1404后,若第一节点相关的第二主题与M个不同第一主题均不匹配,且第一节点相关的第四主题与至少一个第三主题均不匹配,如图16所示,第一节点还可以在第一不匹配列表中记录第二节点的信息(如节点地址、节点标识等,不做限定),其中第一不匹配列表用于记录与第一节点不匹配的远端节点的信息,与第一节点不匹配的远端节点指与第一节点没有能够匹配的主题的远端节点。基于此,第一节点可以在后续接收到来自第二节点的SPDP消息(如SPDP保活包)时,根据第一不匹配列表中所记录的第二节点的信息确定第二节点与第一节点不匹配,进而不对SPDP消息(如SPDP保活包)进行第一预设解析。也就是说,第一节点可以不对来自不匹配的通信节点的SPDP消息(如SPDP保活包)进行不必要的与节点间发现相关的解析处理,如不做处理或者简单处理,如此,可以在SPDP阶段进行有选择性的消息处理,一方面可以降低内存资源以及计算资源的消耗,另一方面还可以缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。
在一些实施例中,在执行完S1404后,若第一节点相关的第二主题与M个不同第一主题均不匹配,且第一节点相关的第四主题与至少一个第三主题均不匹配,如图16所示,第一节点还可以向第二节点发送第四信息(如remote overlap tag)以通知第二节点第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配,如第四信息表征第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配。示例性地,第四信息(如remote overlap tag)可以以预设标识的形式表征第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配,且第一节点相关的第四主题与至少一个第三主题均不匹配。对应地,第二节点可以根据来自第一节点的第四信息更新本地管理和维护的第二不匹配列表,如记录第六信息,第六信息表征第一节点相关的第二主题与第二节点相关的M个不同第一主题均不匹配。示例性地,第二节点可以将第一节点的信息(如节点地址、节点标识等,不做限定)记录在第二不匹配列表中。基于此,后续第一节点和第二节点可以根据各自的不匹配列表有选择性的进行SEDP消息的发送,如第一节点可以在后续接收到来自第二节点的SPDP消息(如SPDP保活包)时,根据第一不匹配列表中所记录的第二节点的信息不对SPDP消息(如SPDP保活包)进行第一预设解析,如不做处理或者简单处理(在一些实施例中,也可以直接删除以节省内部内存);又如第二节点可以在后续接收到来自第一节点的SPDP消息(如SPDP保活包)时,根据第二不匹配列表中所记录的第一节点的信息不对SPDP消息(如SPDP保活包)进行第一预设解析,如不做处理或者简单处理在一些实施例中,也可以直接删除以节省内部内存)。一方面可以避免向没有发布订阅关系的通信节点发送消息带来的不必要的内存资源以及计算资源的消耗,另一方面还可以缩短为相同或相关应用任务/应用功能提供服务的多个通信节点之间建链所需的时长,实现通信节点之间的快速建链。
在一些实施例中,请参考图17,图17示出了申请实施例提供的一种针对新增主题处理过程示意图。如图17所示,第二节点可以在有新增模块,如有新增数据写入模块(DataWriter)或数据读取模块(DataReader)时将新增模块对应新增主题通过查询预设信息表或者解析格式化文件更新进第一信息中,并向分布式系统中的其它通信节点(如第一节点,图17以第一节点作为示例)发送第五信息,第五信息用于第一节点判断是否向第二节点发送SEDP消息。其中,第五信息包括第一标识(如runtime new entity tag)和用于表征新增模块对应的主题(记作新增主题)的信息,第一标识用于指示第五信息中携带的信息表征的是与第二节点相关的新增主题。对应地,在接收到来自第二节点的第五信息后,第一节点可以根据其它携带的第一标识(如runtime new entity tag)识别第五信息中携带有新增主题,然后第一节点可以采用与S804类似的方式判断第一节点相关的第二主题是否与新增主题匹配,以及采用与S1404类似的方式判断第一节点相关的第四主题是否与新增主题匹配;若紧凑型比特序列2中有与新增主题匹配的可用主题或布隆表2所指示的主题中有与新增主题匹配的可用主题,第一节点可以向第二节点发送SEDP消息,SEDP中携带有与新增主题相匹配的第二主题或第四主题的信息,基于此,可以保证在有模块(或主题)新增时仍然可以以较低的误报率实现通信节点之间的快速建链;若紧凑型比特序列2中没有与新增主题匹配的可用主题且布隆表2所指示的主题中没有与新增主题匹配的可用主题,第一节点不向第二节点发送SEDP消息。
在一些实施例中,若第一节点确定紧凑型比特序列2中有与新增主题匹配的可用主题,或者布隆表2所指示的主题中有与新增主题匹配的可用主题,第一节点还可以查找第一不匹配列表中是否有第二节点的信息;若有,如图17所示,则第一节点将第二节点的信息从第一不匹配列表中删除;若没有,第一节点不做处理。
在一些实施例中,若第一节点确定紧凑型比特序列2中有与新增主题匹配的可用主题,或者布隆表2所指示的主题中有与新增主题匹配的可用主题,如图17所示,第一节点还可以向第二节点发送消息(如related tag)以通知第二节点第一节点相关的主题与新增主题匹配。对应地,第二节点可以根据该消息更新本地管理和维护的第二不匹配列表,如若第二不匹配列表中包括第一节点的信息,第二节点可以将第一节点的信息从第二不匹配列表中删除;若第二不匹配列表中原本就不包括第一节点的信息,第二节点不做处理。
在一些实施例中,若第一节点确定紧凑型比特序列2中没有与新增主题匹配的可用主题,且布隆表2所指示的主题中没有与新增主题匹配的可用主题,第一节点还可以基于该分析结果更新第一不匹配列表;如,若第一不匹配列表中不包括第二节点的信息,第一节点可以将第二节点的信息记录在第一不匹配列表中;若第一不匹配列表中原本就包括第二节点的信息,第一节点不做处理。
在一些实施例中,若第一节点确定紧凑型比特序列2中没有与新增主题匹配的可用主题,且布隆表2所指示的主题中没有与新增主题匹配的可用主题,第一节点可以向第二节点发送消息(如related tag)以通知第二节点第一节点相关的主题与新增主题不匹配。对应地,第二节点可以根据来自第一节点的related tag更新本地管理和维护的第二不匹配列表,如若第二不匹配列表中不包括第一节点的信息,第二节点可以将第一节点的信息记录在第二不匹配列表中;若第二不匹配列表中原本就包括第一节点的信息,第二节点不做处理。
需要说明,图17仅以第二节点在有新增模块(如数据写入模块(DataWriter)或数据读取模块(DataReader))时向分布式系统中的第一节点发送第五信息作为示例,在一些实施例中,第二节点也可以在有新增模块时,先判断新增模块对应的主题是否是新的主题;若不是新的主题,不向第一节点发送第五信息;若是新的主题,则向第一节点发送第五信息。例如,第二节点可以通过查找第一信息所表征的第一主题是否包括新增模块对应的主题来判断新增模块对应的主题是否是新的主题,如若包括,则确定新增模块对应的主题不是新增主题,若不包括,则确定新增模块对应的主题是新增主题。
在本申请实施例中,第一节点和第二节点可能支持相同的协议版本,也可能支持不同的协议版本,本申请实施例不做限定。当第一节点和第二节点支持不同的协议版本时,为了保证支持不同版本协议的通信节点之间在进行发现与建链过程中的适配,本申请实施例中通信节点之间还可以具备确定其它通信节点版本信息的能力,便于通信节点在其支持的协议版本与对端支持的协议版本不一致时进行版本适配,以便两端可以顺利进行后续的通信过程。关于通信节点之间在进行发现与建链过程中进行协议版本适配的相关介绍,可以参考上文中关于的解释和说明,这里不再重复。
可以理解,上述实施例1提供的方案中,分布式系统中的通信节点之间可以在自动发现的SPDP阶段互相发送自身的小尺寸的紧凑型比特序列,以便其它通信节点可以快速、准确地完成节点间的主题匹配,并基于匹配结果有选择性的进行SEDP消息的发送,在降低内存资源以及计算资源的消耗的同时缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链。以及进一步地,在通信节点之间进行相互发现和建链的过程中,也可以结合以下任意一个或多个技术实现:1)通信节点之间也可以在自动发现的SPDP阶段互相发送自身的布隆表,以便其它通信节点可以全量考虑相关主题以进行节点间的主题匹配,进一步在降低内存资源以及计算资源的消耗的同时缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链;2)通信节点可以记录不相关通信节点的信息,以便后续再次接收到来自该不相关通信节点的SPDP消息时,可以不做处理或者简单处理,进一步在降低内存资源以及计算资源的消耗的同时缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链;3)通信节点之间可以识别软件版本并支持软件版本的适配,以支持在通信节点之间软件版本不匹配的情况下依旧可以通过版本适配顺利进行后续的通信过程;4)通信节点可以向其它节点发送新增主题和第一标识,以便其它通信节点可以基于第一标识进行其相关的主题与新增主题的匹配,以保证在有模块(或主题)新增时仍然可以以较低的误报率实现通信节点之间的快速建链;5)通信节点可以提前解析格式化文件获取其自身相关的主题信息,以支持在一些类ROS接口场景等特殊场景下,基于实施例1提供的方案实现通信节点之间的正常发现和建链。
在一些实施例中,如实施例2提供的方案中,分布式系统中的通信节点之间可以在自动发现的SPDP阶段互相发送布隆表(不发送紧凑型比特序列),以便其它通信节点可以基于布隆过滤器的策略进行节点间的主题匹配,实现有选择性的进行SEDP消息的发送;并且,实施例2还结合了以下任意一个或多个技术实现:a)通信节点可以记录不相关通信节点的信息,以便后续再次接收到来自该不相关通信节点的SPDP消息时,可以不做处理或者简单处理,进一步在降低内存资源以及计算资源的消耗的同时缩短通信节点之间建链所需的时长,实现通信节点之间的快速建链;b)通信节点之间可以识别软件版本并支持软件版本的适配,以支持在通信节点之间软件版本不匹配的情况下依旧可以通过版本适配顺利进行后续的通信过程;c)通信节点可以向其它节点发送新增主题和第一标识,以便其它通信节点可以基于第一标识进行其相关的主题与新增主题的匹配,以保证在有模块(或主题)新增时仍然可以以较低的误报率实现通信节点之间的快速建链;d)通信节点可以提前解析格式化文件获取其自身的布隆表,以支持在一些类ROS接口场景等特殊场景下,基于布隆表实现通信节点之间的正常发现和建链。
关于上述技术实现a)~d),可以参考上文实施例1中的相关介绍,关于技术通信节点之间在发送布隆表的基础上结合上述技术实现a)~d)中的任意一个或多个的具体实现活成,也可以参考上文实施例1中的相关介绍,这里不再重复。
应理解,本申请实施例的各个方案可以进行合理的组合使用,并且实施例中出现的各个术语的解释或说明可以在各个实施例中互相参考或解释,对此不作限定。
还应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
可以理解的是,通信节点(如第一节点、第二节点等)为了实现上述任一个实施例的功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
本申请实施例可以对通信节点(如第一节点、第二节点等)进行功能模块的划分,例如,可以对应各个功能划分各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。需要说明的是,本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。还应理解,通信节点(如第一节点、第二节点等)中的各个模块可以通过软件和/或硬件形式实现,对此不作具体限定。换言之,通信节点(如第一节点、第二节点等)是以功能模块的形式来呈现。这里的“模块”可以指特定应用集成电路ASIC、电路、执行一个或多个软件或固件程序的处理器和存储器、集成逻辑电路,和/或其它可以提供上述功能的器件。
在一种可选的方式中,当使用软件实现数据传输时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地实现本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其它可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线((digital subscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如软盘、硬盘、磁带)、光介质(例如数字化视频光盘(digital video disk,DVD))、或者半导体介质(例如固态硬盘solid state disk(SSD))等。
结合本申请实施例所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于随机存取存储器(random access memory,RAM)、闪存、只读存储器(read only memory,ROM)、可擦可编程只读存储器(erasable programmable read-only memory,EPROM)、电可擦只读存储器(electrically erasable programmable read-only memory,EEPROM)存储器、寄存器、硬盘、移动硬盘、只读光盘驱动器(compact disc read-only memory,CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性地存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(application specific integrated circuit,ASIC)中。另外,该ASIC可以位于通信节点(如第一节点、第二节点等)中。当然,处理器和存储介质也可以作为分立组件存在。
通过以上的实施方式的描述,所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。
Claims (30)
- 一种节点间的建链方法,其特征在于,所述方法包括:第一节点接收来自第二节点的第一信息,所述第一信息包括M个比特,所述M个比特分别表征所述第二节点相关的M个不同第一主题的可用状态,所述M为正整数;所述第一节点判断所述第一节点相关的第二主题是否与所述不同第一主题相匹配;在所述第一节点相关的第二主题与所述M个不同第一主题中的至少一个相匹配时,所述第一节点向所述第二节点发送简单端节点发现协议SEDP消息,所述SEDP中携带有与所述M个不同第一主题中的至少一个相匹配的第二主题的信息。
- 根据权利要求1所述的方法,其特征在于,所述第一节点在简单参与者发现协议SPDP阶段接收来自所述第二节点的所述第一信息。
- 根据权利要求2所述的方法,其特征在于,所述第一信息携带在SPDP消息中。
- 根据权利要求1-3中任一项所述的方法,其特征在于,所述第一节点中保存有第二信息,所述第二信息包括N个比特,所述N个比特分别表征所述第一节点相关的N个不同第二主题的可用状态,所述N为正整数;所述第一节点判断所述第一节点相关的N个第二主题是否与所述不同第一主题相匹配,包括:所述第一节点通过比较所述不同第二主题的可用状态是否与所述不同第一主题的可用状态相同,来判断所述不同第二主题中是否存在与所述不同第一主题相匹配的主题。
- 根据权利要求4所述的方法,其特征在于,所述第二信息与所述第一信息所遵循的主题与比特位的映射规则一致。
- 根据权利要求5所述的方法,其特征在于,所述第一节点应用于ROS场景,所述方法还包括:所述第一节点调用文件解析接口,解析格式化文件以生成所述第二信息,所述格式化文件包括所述第一节点相关的N个不同第二主题的信息。
- 根据权利要求4-6中任一项所述的方法,其特征在于,所述方法还包括:所述第一节点接收来自所述第二节点的第三信息,所述第三信息包括K个比特,所述K个比特表征与所述第二节点相关的至少一个第三主题的可用状态,所述K为正整数;所述第一节点根据布隆过滤器的策略判断所述第一节点相关的第四主题是否与所述至少一个第三主题相匹配;在所述第一节点相关的第四主题与所述至少一个第三主题中的至少一个相匹配时,所述第一节点向所述第二节点发送SEDP消息。
- 根据权利要求7所述的方法,其特征在于,所述第一节点应用于ROS场景,所述方法还包括:所述第一节点调用文件解析接口,解析格式化文件以确定所述第一节点相关的第四主题,所述格式化文件包括所述第一节点相关的第四主题的信息。
- 根据权利要求6-8中任一项所述的方法,其特征在于,所述格式化文件包括以下任意一种或多种类型的文件:XML文件、JSON文件、YAML文件。
- 根据权利要求8或9所述的方法,其特征在于,所述第三信息与所述第一信息携带在同一消息中或不同消息中。
- 根据权利要求8-10中任一项所述的方法,其特征在于,所述方法还包括:在所述第一节点相关的第二主题与所述M个不同第一主题均不匹配,且所述第一节点相关的第四主题与所述至少一个第三主题均不匹配时,所述第一节点在不匹配列表中记录所述第二节点的标识;在接收到来自所述第二节点的SPDP消息时,所述第一节点根据所述不匹配列表不对所述SPDP消息进行第一预设解析。
- 根据权利要求11所述的方法,其特征在于,所述方法还包括:所述第一节点向所述第二节点发送第四信息,所述第四信息表征所述第一节点相关的第二主题与所述M个不同第一主题均不匹配。
- 根据权利要求11或12所述的方法,其特征在于,所述方法还包括:所述第一节点接收来自所述第二节点的第五信息,所述第五信息包括第一标识和用于表征与所述第二节点相关的新增主题的信息,所述第一标识用于指示所述第五信息中携带的信息表征的是与所述第二节点相关的新增主题;所述第一节点根据所述第一标识,判断所述第一节点相关的第二主题和所述第一节点相关的第四主题是否与所述新增主题相匹配;在所述第一节点相关的第二主题与所述新增主题相匹配或者所述第一节点相关的第四主题与所述新增主题相匹配时,所述第一节点向所述第二节点发送SEDP消息。
- 根据权利要求13所述的方法,其特征在于,所述方法还包括:所述第一节点从维护的不匹配列表中删除所述第二节点的标识。
- 根据权利要求1-14中任一项所述的方法,其特征在于,所述方法还包括:所述第一节点解析来自所述第二节点的SPDP消息,识别所述第二节点支持的第一协议版本;在所述第一协议版本高于或等于所述第一节点支持的第二协议版本时,所述第一节点在向所述第二节点发送SPDP消息和SEDP消息时基于所述第二协议版本发送;在所述第一协议版本低于所述第一节点支持的第二协议版本时,所述第一节点在向所述第二节点发送SPDP消息和SEDP消息时基于所述第一协议版本发送。
- 一种节点间的建链方法,其特征在于,所述方法包括:第二节点生成第一信息,所述第一信息包括M个比特,所述M个比特分别表征所述第二节点相关的M个不同第一主题的可用状态,所述M为正整数;所述第二节点向第一节点发送所述第一信息,所述第一信息用于所述第一节点判断是否向所述第二节点发送SEDP消息,以及用于所述第一节点在向所述第二节点发送SEDP消息时确定携带在所述SEDP消息中的主题信息。
- 根据权利要求16所述的方法,其特征在于,所述第二节点在SPDP阶段向所述第一节点发送所述第一信息。
- 根据权利要求17所述的方法,其特征在于,所述第一信息携带在SPDP消息中。
- 根据权利要求16-18中任一项所述的方法,其特征在于,所述第二节点应用于ROS场景,所述第二节点生成第一信息,包括:所述第二节点调用文件解析接口,解析格式化文件以生成所述第一信息,所述格式化文件包括所述第二节点相关的不同第一主题的信息。
- 根据权利要求18或19所述的方法,其特征在于,所述方法还包括:所述第二节点向所述第一节点发送第三信息,所述第三信息用于所述第一节点判断是否向所述第二节点发送SEDP消息;其中,所述第三信息包括K个比特,所述K个比特表征与所述第二节点相关的至少一个第三主题的可用状态,所述K为正整数。
- 根据权利要求20所述的方法,其特征在于,所述第二节点应用于ROS场景,所述方法还包括:所述第二节点调用文件解析接口,解析格式化文件以确定所述第二节点相关的至少一个第三主题,所述格式化文件包括所述第二节点相关的第三主题的信息。
- 根据权利要求19-21中任一项所述的方法,其特征在于,所述格式化文件包括以下任意一种或多种类型的文件:XML文件、JSON文件、YAML文件。
- 根据权利要求20-22中任一项所述的方法,其特征在于,所述第三信息与所述第一信息携带在同一消息中或不同消息中。
- 根据权利要求20-23中任一项所述的方法,其特征在于,所述方法还包括:所述第二节点接收来自所述第一节点的第四信息,所述第四信息表征所述第一节点相关的第二主题与所述不同第一主题均不匹配;所述第二节点根据所述第四信息记录第六信息,所述第六信息表征所述第一节点相关的第二主题与所述M个不同第一主题均不匹配且所述第一节点相关的第四主题与所述至少一个第三主题均不匹配。
- 根据权利要求16-24中任一项所述的方法,其特征在于,所述方法还包括:所述第二节点向所述第一节点发送第五信息,所述第五信息用于所述第一节点判断是否向所述第二节点发送SEDP消息;其中,所述第五信息包括第一标识和用于表征与所述第二节点相关的新增主题的信息,所述第一标识用于指示所述第五信息中携带的信息表征的是与所述第二节点相关的新增主题。
- 根据权利要求16-25中任一项所述的方法,其特征在于,所述方法还包括:所述第二节点在向所述第一节点发送SPDP消息时携带用于表征所述第二节点支持的第一协议版本的信息,用于所述第一节点确定在向所述第二节点发送SPDP消息和SEDP消息时所使用的协议版本。
- 一种通信节点,其特征在于,所述通信节点包括:存储器,用于存储计算机程序指令和数据;处理器,用于执行所述计算机程序指令,以支持所述处理模块实现如权利要求1-15或16-26中任一项所述的方法。
- 一种分布式通信系统,其特征在于,所述分布式通信系统包括:第一节点,用于实现如权利要求1-15中任一项所述的方法;第二节点,用于实现如权利要求16-26中任一项所述的方法。
- 一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序指令,所述计算机程序指令被处理电路执行时实现如权利要求1-15或16-26中任一项所述的方法。
- 一种包含指令的计算机程序产品,其特征在于,当所述计算机程序产品在计算机上运行时,使得所述计算机执行如权利要求1-15或16-26中任一项所述的方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410537087.X | 2024-04-29 | ||
| CN202410537087.XA CN120915774A (zh) | 2024-04-29 | 2024-04-29 | 节点间的建链方法、节点及分布式系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2025227992A1 true WO2025227992A1 (zh) | 2025-11-06 |
Family
ID=97546716
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2025/084091 Pending WO2025227992A1 (zh) | 2024-04-29 | 2025-03-21 | 节点间的建链方法、节点及分布式系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN120915774A (zh) |
| WO (1) | WO2025227992A1 (zh) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104426728A (zh) * | 2013-08-23 | 2015-03-18 | 汤姆逊许可公司 | 采用中央发现机制的通信设备及相关方法 |
| US20160350424A1 (en) * | 2015-05-25 | 2016-12-01 | International Business Machines Corporation | Publish-Subscribe System with Reduced Data Storage and Transmission Requirements |
| CN109194736A (zh) * | 2018-08-30 | 2019-01-11 | 百度在线网络技术(北京)有限公司 | 消息去重方法、装置、电子设备、介质和无人车 |
| CN113378230A (zh) * | 2021-07-05 | 2021-09-10 | 东南大学 | 一种dds分布式系统的数据访问控制方法 |
| CN115297556A (zh) * | 2022-07-14 | 2022-11-04 | 中国航空无线电电子研究所 | 一种机载网络中实现主题优先级的数据分发方法 |
| CN116545928A (zh) * | 2023-05-31 | 2023-08-04 | 重庆长安汽车股份有限公司 | 通讯组播过滤方法、装置及系统 |
-
2024
- 2024-04-29 CN CN202410537087.XA patent/CN120915774A/zh active Pending
-
2025
- 2025-03-21 WO PCT/CN2025/084091 patent/WO2025227992A1/zh active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104426728A (zh) * | 2013-08-23 | 2015-03-18 | 汤姆逊许可公司 | 采用中央发现机制的通信设备及相关方法 |
| US20160350424A1 (en) * | 2015-05-25 | 2016-12-01 | International Business Machines Corporation | Publish-Subscribe System with Reduced Data Storage and Transmission Requirements |
| CN109194736A (zh) * | 2018-08-30 | 2019-01-11 | 百度在线网络技术(北京)有限公司 | 消息去重方法、装置、电子设备、介质和无人车 |
| CN113378230A (zh) * | 2021-07-05 | 2021-09-10 | 东南大学 | 一种dds分布式系统的数据访问控制方法 |
| CN115297556A (zh) * | 2022-07-14 | 2022-11-04 | 中国航空无线电电子研究所 | 一种机载网络中实现主题优先级的数据分发方法 |
| CN116545928A (zh) * | 2023-05-31 | 2023-08-04 | 重庆长安汽车股份有限公司 | 通讯组播过滤方法、装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN120915774A (zh) | 2025-11-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20240333802A1 (en) | Vehicle signal relay service | |
| JP7028598B2 (ja) | 第1通信ノード及びその動作方法 | |
| US11968060B2 (en) | Data switching device and data switching method for a vehicle, device and method for a vehicle component of a vehicle, and computer program | |
| US20180103121A1 (en) | Operation method of communication node for selective wake-up in vehicle network | |
| CN102752215B (zh) | 一种vdp请求报文的处理方法和边缘交换机 | |
| Kenjić et al. | Connectivity challenges in automotive solutions | |
| CN118450354B (zh) | 基于面向服务架构的ota升级方法、装置、电子设备及介质 | |
| JP7839284B2 (ja) | スリープ/ウェイクアップ方法、システム、および装置 | |
| WO2023205916A1 (zh) | 一种车载诊断方法、装置及系统 | |
| US7350014B2 (en) | Connecting peer endpoints | |
| WO2025227992A1 (zh) | 节点间的建链方法、节点及分布式系统 | |
| CN116233241A (zh) | 一种微服务应用的迁移方法及装置 | |
| CN118784706B (zh) | 通信方法和通信装置 | |
| CN117651057A (zh) | 车辆控制方法、装置、车辆及存储介质 | |
| WO2024026592A1 (zh) | 一种数据存储方法及相关装置 | |
| CN116860265A (zh) | 基于多核异构平台的soa架构部署方法及装置 | |
| CN116489208A (zh) | Soa中间件、控制器及其系统、服务发现及通信方法 | |
| CN116347041A (zh) | 共享整车图像采集设备数据的方法及系统 | |
| US20260030339A1 (en) | Communication method, apparatus, and system, and mobile carrier | |
| CN118555181B (zh) | 一种网络业务处理方法、装置、电子设备及存储介质 | |
| CN120017697B (zh) | 车辆通信控制方法、装置、设备以及计算机可读存储介质 | |
| CN117032174B (zh) | 基于车载网关的控制方法、装置及计算机可读存储介质 | |
| CN116248775B (zh) | Dds网关的交互方法、装置、电子设备及存储介质 | |
| CN119902747B (zh) | 软件组件的代理方法、装置、电子设备及存储介质 | |
| CN116436994B (zh) | Profinet协议报文传输方法、装置、设备及介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 25797168 Country of ref document: EP Kind code of ref document: A1 |