A highly available DDS protocol conversion gateway

Abstract

The present invention discloses a highly available DDS protocol conversion gateway, belonging to the field of computer technology. The method of the present invention includes: the protocol conversion gateway generates its own unique identifier; according to the redundancy deployment requirement, the gateway simultaneously publishes and subscribes to arbitration topic messages with node identifiers; the master node is elected according to the node identifier in the arbitration topic message and the gateway's own identifier; the master node converts DDS protocol messages into other non-DDS protocol messages and sends them out, and non-master nodes do not send out non-DDS protocol messages. The present invention can ensure that the protocol conversion gateway is redundantly deployed in a hot standby manner, implement master node arbitration based on the DDS protocol, and finally select whether to publish non-DDS protocol messages according to whether the replica is the master node, effectively improving the reliability of the protocol conversion gateway.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and particularly to a highly available DDS protocol conversion gateway. Background Art

[0002] The DDS (Data Distribution Service) protocol is a data-centric message middleware, which has characteristics such as low latency, high reliability, and scalability, and is widely used in real-time distributed systems in fields such as autonomous driving. DDS provides a rich set of Quality of Service (QoS) policies, including QoS policies related to improving the reliability of DDS applications through redundancy.

[0003] The DDS redundancy policy is for publishers and subscribers of QoS topics. When multiple replicas publish the same instance, DDS message subscribers will receive all message instances. The DDS message instances carry weight information, and subscribers will sort the same instances. The one with the highest weight is the owner of the instance, that is, the primary node, and the rest are backup nodes. Subscribers only select the instances of the primary node for processing. When the DDS topic contains a key definition, each key corresponds to a message instance. When there is no key definition, all messages are considered as one instance. The related QoS policy configuration items are Ownership, Ownership_strength, Liveliness, and Deadline.

[0004] Ownership defines whether DDS publishers and subscribers adopt an exclusive strategy to process DDS message instances. When using the exclusive strategy, DDS message subscribers will receive and process all messages. Ownership needs to be enabled and configured the same on both the message publisher and subscriber, and cannot be modified after being enabled. It is not enabled by default in DDS. Owhership_strength defines the weight of the DDS message publisher. The weight is a 4-byte integer, which is only enabled on the publisher and can be modified after being enabled. The default value is 0. When multiple publishers use the same weight, the arbitration of the primary and secondary nodes will be random.

[0005] Liveliness defines the way and lifecycle of the liveliness declaration of a DDS message publisher. There are three ways to declare liveliness: automatic, semi-automatic, and manual. It is required that the type of the publisher's liveliness declaration is not greater than that of the subscriber's liveliness declaration, and the order of the type sizes is: automatic < semi-automatic < manual; the configuration of the publisher's liveliness declaration cycle is not greater than that of the subscriber's liveliness declaration cycle, and the default is the automatic mode. When using the automatic mode, the message publisher will publish liveliness declaration messages within the declared cycle, and the message subscriber will judge the liveliness of the publisher according to the configuration of the liveliness declaration cycle. When no liveliness declaration of the publisher is received within the liveliness declaration cycle and exceeds the Deadline cycle agreement, the data publisher is considered to have failed.

[0006] Deadline defines how often each DDS instance must be updated. It is required that the Deadline cycle configuration of the data subscriber is not less than that of the data publisher. It can be modified after being enabled, and the default cycle is infinite.

[0007] In a redundant deployment scenario, the QoS policies of the DDS message publisher and subscriber are configured as exclusive policies, and the liveliness declaration and message update cycle are less than the fault tolerance time. When a message instance exceeds the agreements of Deadline and Liveliness, the DDS message subscriber will consider the message instance to have failed. If the failed message instance is the master node, a master-slave switch will occur, and the node with the largest current weight will be selected as the new master node.

[0008] The DDS protocol conversion gateway is used to convert DDS protocol messages into other non-DDS protocol messages to achieve interoperability between DDS-based application systems and other non-DDS protocol-based application systems. In this application scenario, according to whether the message receiver uses the DDS protocol, it can be divided into two cases: one is from DDS protocol to DDS protocol and from non-DDS protocol to DDS protocol, and the other is from DDS protocol to non-DDS protocol. The DDS protocol conversion gateway is located at the protocol boundary, and both of the above cases exist simultaneously. In a redundant deployment scenario, the DDS protocol conversion gateway can directly utilize the QoS policy of DDS to receive DDS messages and filter redundant messages. Since the arbitration of multiple replicas occurs at the receiving end, after each DDS protocol conversion gateway converts the DDS message into a non-DDS protocol message and sends it to the receiving end of the non-DDS protocol application system, the receiving end of the non-DDS protocol application system will not be able to filter the received redundant messages, resulting in anomalies in the application system. Summary of the Invention

[0009] Technical problems to be solved by the present invention: Aiming at the above problems of the prior art, a highly available DDS protocol conversion gateway is provided. The present invention can ensure that the protocol conversion gateway is redundantly deployed in a hot standby manner, implement master node arbitration based on the DDS protocol, and finally select whether to publish non-DDS protocol messages according to whether the replica is the master node, effectively improving the reliability of the protocol conversion gateway.

[0010] In order to achieve the above object and solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0011] A highly available DDS protocol conversion gateway, including the following steps:

[0012] Step 1: When the protocol conversion gateway starts up, generate its own unique identifier, record the gateway startup timestamp, and execute Step 2 for the conversion from the DDS protocol to the non-DDS protocol;

[0013] For the conversion from the non-DDS protocol to the DDS protocol, execute Step 5;

[0014] Step 2: All replicas publish arbitration topic messages with their own node identifiers.

[0015] 2.1 Read the current system time, subtract the gateway startup timestamp to obtain the total number of seconds the gateway has been running continuously;

[0016] 2.2 Set the QoS policy of the arbitration topic, set Ownership to the exclusive policy, set Deadline and Liveliness according to user needs, and set the arbitration topic message weight Owhership_strength equal to the total number of seconds the gateway has been running continuously;

[0017] 2.3 Publish the arbitration topic message, and the message content is the gateway unique identifier;

[0018] When the user needs to specify the master node, set the arbitration topic message weight Owhership_strength of the specified replica to the maximum value, i.e., 0x7fffffff;

[0019] Step 3: All replicas simultaneously subscribe to the arbitration topic messages, and judge whether they are the master node according to the node identifier in the arbitration topic message and the gateway's own identifier;

[0020] 3.1 All replicas subscribe to the arbitration topic messages, and by default, the initial state of all replicas is the master node;

[0021] 3.2 All replicas continuously read the gateway unique identifier in the message, compare the gateway unique identifier in the message with their own identifier, if they are the same, it is considered that they are the master node, otherwise they are the standby node;

[0022] Step 4: The master node converts the DDS protocol message into other non-DDS protocol messages and sends them out, while the non-master nodes do not send out non-DDS protocol messages.

[0023] If the replica is the master node, it converts the DDS protocol messages received from the DDS protocol application system into non-DDS protocol messages and sends them to the non-DDS protocol application system.

[0024] If the replica is a standby node, it does not send out messages.

[0025] Step 5: All replicas receive the non-DDS protocol messages, convert them into DDS protocol messages and send them out. Messages of the same type use the same DDS protocol topic.

[0026] When the gateway receives non-DDS protocol application messages, it converts the messages into DDS protocol messages, and the QoS policy settings of the DDS protocol message topic are the same as those of the arbitration topic; the DDS protocol messages of all replicas are directly published, and messages of the same type use the same DDS protocol topic.

[0027] Furthermore, Step 1 includes:

[0028] 1.1 When the gateway starts up, it calculates and generates a UUID based on information such as the current time, counter, and hardware identifier, and records the gateway startup timestamp at the same time.

[0029] 1.2 Convert the UUID into a fixed-length character array as the unique identifier of the gateway.

[0030] Compared with the prior art, the present invention has the following advantages: The present invention constructs an arbitration message topic for the problem that the DDS protocol QoS policy does not support redundant deployment of DDS protocol conversion gateways; when the gateway starts up, it records the gateway startup timestamp, generates a gateway identifier, and ensures the uniqueness of the identifier in the system; sets the QoS policy of the arbitration topic, calculates the continuous running time of the gateway according to the current time of the system and the gateway startup timestamp, and calculates the arbitration message weight according to the running time; publishes the arbitration topic message, and the message content is the unique identifier of the gateway; the gateway subscribes to the arbitration topic message and determines the master node according to the identifier in the message and its own identifier; the master node converts the DDS protocol application system messages into non-DDS protocol messages and sends them out, while the standby nodes do not send out messages. The present invention introduces an arbitration topic based on the DDS protocol QoS mechanism, has the ability of redundant deployment while realizing the mutual conversion of DDS protocol messages and non-DDS protocol messages, and does not require the non-DDS protocol application system to modify the message processing method. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is the basic flowchart of the method of the embodiment of the present invention;

[0032] Figure 2Schematic diagram of the conversion application of the DDS protocol to a non-DDS protocol in an embodiment of the present invention;

[0033] Figure 3 Schematic diagram of the conversion application of a non-DDS protocol to the DDS protocol in an embodiment of the present invention;

[0034] Figure 4 Example of the arbitration process of the master node in an embodiment of the present invention. Detailed implementation manners

[0035] In order to make the objectives, technical solutions and advantages of the present invention clearer, the following will take a DDS protocol application system as an example, and further describe in detail a highly available DDS protocol conversion gateway of the present invention in conjunction with the accompanying drawings and embodiments.

[0036] As Figure 1 shown, a highly available DDS protocol conversion gateway in this embodiment includes:

[0037] 1) When the protocol conversion gateway starts up, it loads the QoS configurations of the arbitration topic and the message topic;

[0038] 2) Generates its own unique identifier and records the gateway startup timestamp;

[0039] 3) All replicas publish and subscribe to arbitration topic messages with the node's own identifier;

[0040] 4) Judges whether itself is the master node according to the node identifier in the arbitration topic message and the gateway's own identifier;

[0041] 5) When a DDS protocol message is received, the master replica converts the DDS protocol message into other non-DDS protocol messages and sends them out, and other replicas do not send out non-DDS protocol messages.

[0042] 6) When a non-DDS protocol message is received, all replicas convert the non-DDS protocol message into a DDS protocol message and publish it.

[0043] The QoS configuration includes: the Ownership is set to the exclusive strategy, the message update period Deadline and the liveliness declaration period Liveliness are set according to user needs, and the arbitration topic message weight Owhership_strength is equal to the total number of seconds that the gateway runs continuously, and the calculation method is the current timestamp minus the gateway startup timestamp.

[0044] See Figure 4, The DDS protocol conversion gateway simultaneously publishes and subscribes to arbitration topic messages. The arbitration topic messages contain the identifiers of the published nodes. The node identifier is a Universally Unique Identifier (UUID). The UUID was proposed by the International Organization for Standardization (ISO) and has mature implementations in various operating systems. The UUID is a 128-bit value calculated based on data such as the current time, counter, and network card address, and is regarded as a unique identifier in all spaces and times. When an arbitration topic message is published, due to the QoS configuration policy, only the message with the highest weight will be received by each replica. The weight calculation method is the current system time minus the gateway startup time, and then converted to the total number of seconds. The weight value is equal to the total number of seconds. When it is necessary to manually specify the primary replica, the weight of the replica is modified to the maximum value that can be represented by a 4-byte integer, that is, 0x7fffffff. Subsequently, each replica compares the identifier in the received arbitration message with its own identifier. If they are the same, it is considered that the replica is the primary node, and the protocol conversion gateway converts the received DDS protocol message into a non-DDS protocol message and sends it out. Otherwise, it is considered that the replica is a standby node, and the protocol conversion gateway does not send out non-DDS protocol messages.

[0045] The above is only the implementation mode of the redundant deployment of the protocol conversion gateway of the present invention. The protection scope of the present invention is not limited to the above embodiments. All technical solutions falling within the idea of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art in this technical field, several improvements and refinements made without departing from the principle of the present invention should also be regarded as within the protection scope of the present invention.

Claims

1. A highly available DDS protocol conversion gateway, characterized in that, it includes the following steps: Step 1: When the protocol conversion gateway starts, it generates its own unique identifier, records the gateway startup timestamp, and for the conversion from DDS protocol to non-DDS protocol, execute Step 2; For the conversion from non-DDS protocol to DDS protocol, execute Step 5; Step 2: All replicas publish arbitration topic messages with their own node identifiers 2.1 Read the current system time, subtract the gateway startup timestamp to obtain the total number of seconds the gateway has been running continuously; 2.2 Set the QoS policy of the arbitration topic, set Ownership to the exclusive policy, and set Deadline and Liveliness according to user needs. The arbitration topic message weight Owhership_strength is equal to the total number of seconds the gateway has been running continuously; 2.3 Publish the arbitration topic message, and the message content is the gateway unique identifier; When the user needs to specify the master node, set the arbitration topic message weight of the specified replica to the maximum value; Step 3: All replicas simultaneously subscribe to the arbitration topic message, and judge whether they are the master node according to the node identifier in the arbitration topic message and the gateway's own identifier; 3.1 All replicas subscribe to the arbitration topic message, and by default, the initial state of all replicas is the master node; 3.2 All replicas continuously read the gateway unique identifier in the message, compare the gateway unique identifier in the message with their own identifier. If they are the same, it is considered that they are the master node, otherwise they are the standby node; Step 4: The master node converts the DDS protocol message into other non-DDS protocol messages and sends them out, and the non-master node does not send non-DDS protocol messages If the replica is the master node, it converts the DDS protocol message received from the DDS protocol application system into a non-DDS protocol message and sends it to the non-DDS protocol application system; If the replica is the standby node, it does not send messages; Step 5: All replicas receive non-DDS protocol messages and convert them into DDS protocol messages and send them out. Messages of the same type use the same DDS protocol topic When the gateway receives a non-DDS protocol application message, it converts the message into a DDS protocol message, and the QoS policy setting of the DDS protocol message topic is the same as that of the arbitration topic; the DDS protocol messages of all replicas are directly published, and messages of the same type use the same DDS protocol topic.

2. A highly available DDS protocol conversion gateway according to claim 1, characterized in that, the said Step 1 includes: 1.1 When the gateway starts, it calculates and generates a UUID based on information such as the current time, counter, and hardware identifier, and at the same time records the gateway startup timestamp; 1.2 Convert the UUID into a fixed-length character array as the gateway unique identifier.

Images