A method for implementing a multicast transmission mechanism of a data distribution service protocol based on a Client-Server discovery model

Abstract

The present invention relates to a multicast transmission mechanism for a data distribution service protocol based on the Client-Server discovery model, including: creating reader agent data and writer agent data in the Client-Server discovery model; Server participant nodes: receiving discovery messages sent by publisher clients, extracting writer agent data, grouping writers with the associated topic as the key, and storing them in the server database; receiving discovery messages sent by subscriber clients, and extracting reader agent data; dynamically allocating unified multicast resources for newly discovered topics according to the reader agent data, and storing the allocation result and the topic in the form of key-value pairs in the server database; the server completes the matching between clients and forwards the discovery message to relevant clients; Client participant nodes: receiving and processing the discovery messages sent by the server participant nodes. Compared with the prior art, the present invention solves the problem of unicast sending queuing in data distribution services and can achieve real-time data sending in a one-to-many scenario.

Description

Technical Field

[0001] The present invention relates to the field of communication electronic computer technology, and in particular to a data distribution service protocol multicast transmission mechanism based on a Client-Server discovery model. Background Art

[0002] Data Distribution Service (DDS) is a service-oriented communication middleware technology that distributes data with data as the center and has high scalability and flexibility. DDS also has a rich quality of service (QoS) strategy, which can provide users with a variety of data transmission mechanisms. DDS provides an API for service-oriented remote procedure calls and communications. Application developers can flexibly define data formats according to their needs and provide efficient data transmission by publishing and subscribing to topics.

[0003] Time-Sensitive Networking (TSN) is a set of Ethernet extension protocols developed by the IEEE 802.1TSN working group, which was formerly the AVB working group. The TSN protocol family includes four sub-protocols: clock synchronization, reliability, low latency, and resource management. The purpose is to achieve real-time, reliable transmission of time-sensitive data streams based on standard Ethernet. It has broad application prospects in the fields of industrial Internet and Internet of Vehicles.

[0004] As a communication middleware, DDS works between the application layer software and the operating system. Although it has rich QoS, these QoS cannot control the transmission behavior of the data link layer. It happens that TSN mainly works at the data link layer. The integration of DDS-TSN can provide reliable and real-time data transmission for DDS. At present, the adaptation between the two is becoming a hot topic in the industry.

[0005] At present, the DDS protocol uses unicast communication in the process of user data transmission, which means that when there are multiple DataReaders in the network subscribing to the same topic, the data writer DataWriter needs to send a unicast message to each data reader DataReader. The process of sending messages in sequence will bring additional waiting delays to the messages sent later, which may have a serious impact on time-sensitive tasks. Moreover, affected by the task scheduling of the operating system, the waiting delay is uncertain, which will have a catastrophic impact on the deterministic scheduling of time-sensitive networks, especially the scheduling of the most commonly used time-aware shaper, resulting in the inability to guarantee the real-time performance of DDS data transmission.

[0006] Repeatedly sending unicast messages with the same data consumes the CPU resources and bandwidth resources of the sender, reducing the transmission efficiency of DDS. Moreover, adopting this unicast transmission mechanism will increase the number of messages in the network, consuming the bandwidth resources in the entire network.

[0007] Currently, in the DDS protocol, to transmit data through multicast, DDS users must manually allocate multicast resources for topics, and need to communicate and confirm with developers who do not use this topic in advance, which brings inconvenience to the development work and easily leads to conflicts in the use of multicast resources. That is, the current DDS protocol cannot achieve automated multicast transmission. Summary of the Invention

[0008] The purpose of the present invention is to overcome the defects of the above-mentioned existing technologies and provide a multicast transmission mechanism for the data distribution service protocol based on the Client-Server discovery model. By allocating different multicast resources for different topics, the publisher can transmit data to all subscribers by sending only a single multicast message, solving the queuing problem caused by the default use of unicast sending in the data distribution service, and enabling real-time data sending in a one-to-many scenario, improving the sending efficiency.

[0009] The purpose of the present invention can be achieved through the following technical solutions:

[0010] The present invention provides a multicast transmission mechanism for the data distribution service protocol based on the Client-Server discovery model, including:

[0011] In the Client-Server discovery model, create reader proxy data storing reader attributes and information, and writer proxy data storing writer attributes and information;

[0012] Server participant node: Receive the discovery message sent by the publisher client, extract the writer proxy data from it, group the writers with the associated topic as the key, and store them in the database of the server; Receive the discovery message sent by the subscriber client, and extract the reader proxy data from it; Among them, the server dynamically allocates unified multicast resources for newly discovered topics according to the reader proxy data, and stores the allocation result and the topic in the form of a key-value pair in the database of the server; The server completes the matching between clients and forwards the discovery message to relevant clients;

[0013] Client participant node: Receive and process the discovery message sent by the server participant node.

[0014] Preferably, the reader agent data includes a globally unique identifier for uniquely identifying each data distribution service entity, the topics subscribed by the reader, and a locator for the reader to receive messages; the globally unique identifier includes a globally unique identifier prefix for identifying the participant to which the entity belongs and an entity identifier for identifying different entities under the same participant; wherein, the same entity identifier is assigned to all readers subscribing to the same topic;

[0015] The multicast resources include a multicast address, a listening port, and a reader entity identifier.

[0016] Preferably, the server dynamically allocates unified multicast resources for newly discovered topics according to the reader agent data, specifically:

[0017] Modify the unicast address, listening port, and reader entity identifier in the locator of the reader's original discovery message to the unified multicast address, listening port, and reader entity identifier for the topic;

[0018] After serializing the modified reader agent data, repackage it as a discovery message and send it to the participant entity where the reader itself is located.

[0019] Preferably, the process of allocating the multicast resources specifically includes:

[0020] The allocation expression of the multicast address is specifically:

[0021] MulticastAddress=BaseAddress+counter

[0022] Wherein, BaseAddress is the base address, which has been used by the discovery protocol; counter is a counter; when a new topic is discovered, the counter will automatically increment by 1;

[0023] The listening port follows the regulations for user multicast data streams in the RTPS protocol, and the allocation expression is:

[0024] Port=PB+DG*DomainId+d2

[0025] Wherein, PB is the port base; DG is the domain gain; DomainId is the domain id where the reader is located; d2 is 1; after this port allocation, all client participants in the same domain open the same listening port to listen to the multicast data stream;

[0026] The entity identifier consists of a four-byte array; among them, the highest byte corresponds to characterizing and distinguishing readers / writers and with or without key values, and by default it is of the type without key values; the three bytes other than the highest byte serve as the id counter, which is initialized to 0x7f, and after a new topic is discovered, the id counter is automatically incremented by 1.

[0027] Preferably, in the server, the process of feeding back the reader proxy data containing multicast resources to the participant entity where the reader itself is located is specifically as follows:

[0028] Add a reader first feedback flag bit and set it to true, and add the global unique identifier of the reader to the subscriber send waiting queue in the database;

[0029] The entity in the server participant responsible for sending EDP messages about subscribers traverses the global unique identifiers of the readers in this queue, looks up the modified reader proxy data corresponding to the global unique identifier from the discovery database in the server, encapsulates this data into an EDP discovery message after serialization, and sends this new discovery message to the participant entity where the reader itself is located according to the filtering rules of the sending entity, and sets the first feedback flag bit to false after successful sending.

[0030] Preferably, in the server participant node, the matching process of readers and writers under a newly discovered topic is specifically as follows:

[0031] Traverse all the discovered readers under the same topic, add a reader-related status flag bit and set it to false, and add the global unique identifier of the reader to the database subscriber to-be-sent queue;

[0032] Traverse all the discovered writers under the same topic, add a writer-related status flag bit and set it to false, and add the discovery message of the writer to the database publisher to-be-sent queue;

[0033] Preferably, for a writer or reader waiting for forwarding, the specific process of the server forwarding the discovery message to the client is as follows:

[0034] Forward the discovery message of the reader: The entity in the server participant responsible for sending EDP messages about subscribers traverses the global unique identifiers of the readers in the database subscriber to-be-sent queue, looks up the modified reader proxy data corresponding to the global unique identifier from the discovery database, encapsulates this data into an EDP discovery message after serialization, and sends this new discovery message to the client participant where the writer with the writer-related status flag bit being false is located according to the filtering rules of the sending entity, and sets this flag bit to true after successful sending;

[0035] Forward the discover message of the writer: The entity in the server participant responsible for sending the EDP message of the publisher traverses the discover message of the writer in the database publisher's pending send queue, and sends the discover message to the client participant where the reader with the relevant status flag set to false is located according to the filtering rule. After successful sending, the flag is set to true.

[0036] Preferably, a receiver repository is set up in the client participant node, and the receiver repository uses the constructed socket to receive multicast messages from the matching writer.

[0037] Preferably, the client participant will receive the discover message sent by the server participant node and perform corresponding processing, specifically:

[0038] 1) Receive the writer discovery message sent by the server, and complete the matching of the local reader with the writer; receive the modified reader discovery message sent back by the server, and extract the multicast address, listening port, and reader entity identifier allocated by the server for this topic from it;

[0039] 2) Create a socket of the User Datagram Protocol type, open the specified listening port, and add the socket to the multicast group specified by the multicast address to receive multicast messages sent to this multicast address;

[0040] 3) Create a receiver repository and put the newly created socket into this receiver resource;

[0041] 4) Search for the corresponding reader in the local participant entity according to the feedback topic, and put the reader and the feedback reader entity identifier into the newly created receiver repository;

[0042] 5) When the socket in the receiver repository receives a multicast message containing user data, the message receiver will take out the specified reader entity identifier in the message, search for the reader corresponding to this reader entity identifier in this receiver repository, and pass the data to this reader to complete the data reception work.

[0043] Preferably, the client participant node also includes sending multicast messages, specifically:

[0044] Receive the reader discovery message sent by the server, complete the matching of the local writer with the reader, and store the reader locator of the reader in the writer;

[0045] When the writer sends user data, it traverses all the reader locators that have completed matching with itself, and then merges the locators with the same multicast address and listening port, so that only one multicast message is sent to the same multicast address to transmit data, and the multicast message contains the reader entity identifier assigned by the server for this topic.

[0046] Compared with the prior art, the present invention has the following beneficial effects:

[0047] 1) The multicast transmission mechanism based on the Client-Server discovery model constructed by the present invention utilizes the created reader proxy data to allocate different multicast resources for different topics, and the publisher can deliver data to all subscribers by sending only a single multicast message.

[0048] 2) When the existing DDS sends multiple unicast messages, only the sending moment of the first message is controllable, and the sending moments of the subsequent unicast messages are affected by the operating system task scheduling and are not accurately predictable. When the sending moment of the DDS message is uncontrollable, the time-aware shaper cannot be used to ensure the real-time and deterministic data transmission. The multicast transmission mechanism based on the Client-Server discovery model constructed by the present invention creates conditions for the integration of TSN and DDS. Especially when using the time-aware shaper of TSN to schedule the DDS data stream, the publisher can deliver data to all subscribers by sending only a single multicast message, ensuring the real-time and deterministic data transmission.

[0049] 3) The reader proxy data of the present invention includes a globally unique identifier for uniquely identifying each data distribution service entity, the topic subscribed by the reader, and the locator for the reader to receive messages. The writers are grouped with the associated topic as the key, and the reader locators and reader entity identifiers for multicast are automatically allocated during the discovery phase, facilitating the subsequent matching work between readers and writers and realizing multicast transmission.

[0050] 4) The present invention gives a specific calculation method for the reallocation of the multicast address, listening port, and entity identifier. Among them, through the reallocation of the listening port, all participants in the same domain will open the same listening port to listen to the multicast data stream, logically separating the readers in different domains; the id counter in the entity identifier is initialized to 0x7f, avoiding the conflict between the entity identifier reallocated by the server and the entity identifier allocated in the original client.

[0051] 5) The multicast resource allocation process in the present invention is automatically completed by the DDS middleware, which is transparent to users and does not require manual configuration by users, realizing the decoupling of the upper-layer application and the DDS middleware. Using the present invention can reduce the workload of developers and avoid the errors that may be caused by manual configuration.

[0052] 6) In the client participant node of the present invention, a receiver repository is set up, and multicast communication with the matching writer is achieved by using the constructed User Datagram Protocol (UDP) type socket. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 Schematic diagram of the Simple Participant Discovery Protocol (SPDP) provided for the embodiment;

[0054] Figure 2 Schematic diagram of the Simple Endpoint Discovery Protocol (SEDP) provided for the embodiment;

[0055] Figure 3 Schematic diagram of the Client-Server discovery model provided for the embodiment;

[0056] Figure 4 Schematic diagram of ReaderProxyData and WriterProxyData provided for the embodiment;

[0057] Figure 5 Flowchart of the Reader discovery process for the Server Participant node provided for the embodiment;

[0058] Figure 6 Flowchart of the Writer discovery process for the Server Participant node provided for the embodiment;

[0059] Figure 7 Flowchart of the EDPServerSUBReader process in the Server Participant node provided for the embodiment;

[0060] Figure 8 Flowchart of the EDPServerSUBWriter process in the Server Participant node provided for the embodiment;

[0061] Figure 9 Flowchart of the matching process for newly discovered Readers and Writers in the Server Participant node provided for the embodiment;

[0062] Figure 10 Flowchart of the process for handling the send queue in the Server Participant node provided for the embodiment;

[0063] Figure 11 Flowchart of the process for handling Reader EDP messages in the Client Participant node provided for the embodiment;

[0064] Figure 12 Schematic diagram of processing feedback messages in the original Client Participant node provided for the embodiment.

[0065] Figure 13 Schematic diagram of ReceiverResource provided for the embodiment;

[0066] Figure 14 Flowchart of storing entityId and corresponding RTPSReader into ReceiverResource provided for the embodiment;

[0067] Figure 15 Schematic diagram of multicast transmission provided for the embodiment. Detailed implementation manners

[0068] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0069] Embodiment

[0070] First, the English terms involved in this embodiment are described in detail in Table 1 below.

[0071] Table 1. Introduction to the concepts and uses of relevant English terms

[0072]

[0073]

[0074]

[0075] The DDS discovery phase consists of two phases: participant discovery and endpoint discovery. As Figure 1 , 2 shown, they respectively follow the Simple Participant Discovery Protocol (SPDP) and the Simple Endpoint Discovery Protocol (SEDP). Both discovery phases send and receive discovery information through built-in endpoints.

[0076] As Figure 1As shown, in the SPDP phase, the endpoint SPDPbuiltinParticipantWriter of a participant sends information related to this participant to the endpoints SPDPbuiltinParticipantReader of other participants. After receiving the discovery message, the latter will create a ParticipantProxy for the newly discovered Participant for subsequent discovery processes. The entityId and Topic of the built-in endpoints used in the SPDP protocol are both predefined in the protocol. The SPDP phase adopts a distributed multicast transmission method, that is, each participant node sends discovery messages to all other participant nodes via multicast packets, and will also receive discovery messages from all other participant nodes. Using a unified multicast address and port number, when initializing the SPDPbuiltinParticipantReader, it will be added to this multicast group, and a Socket will be created based on this port to listen for SPDP discovery messages.

[0077] The SEDP phase is used to discover user-defined entities. Six built-in endpoints participate under each participant node and provide three built-in Topics: DCPSTopic, DCPSSubscription, and DCPSPublication, which are used to discover Topics, Readers, and Writers respectively, where Topic discovery is an optional item. Figure 2 Shows the communication process among four SEDP endpoints around DCPSSubscription and DCPSPublication. Among them, SEDPbuiltinPublicationWriter and SEDPbuiltinPublicationReade are used to discover user-defined Writers, and SEDPbuiltinSubscriptionWriter and SEDPbuiltinSubscriptionReader are used to discover user-defined Readers. The SEDP phase adopts the same distributed model as SPDP. When the above four built-in endpoints interact with messages, they will use the predefined entityId and the unified multicast address and port.

[0078] The underlying transmission of the DDS protocol generally supports three transmission methods: TCP, UDP, and shared memory (SHM). Since TCP is a connection-oriented transmission method and does not support the multicast mechanism, the multicast transmission mechanism proposed in the embodiments of this application needs to use the UDP-based method for transmission.

[0079] The Client-Server discovery model used in the embodiments of this application is as Figure 3As shown, its participant nodes are divided into Server Participant nodes and Client Participant nodes. The discovery process of the Client-Server model is also divided into two phases: PDP and EDP. Different from the distributed discovery model used in the simple discovery protocol, the PDP and EDP entities of the Client Participant node only send discovery messages to the PDP and EDP entities under the Server Participant node via unicast, and Client nodes no longer send and receive discovery messages from each other. To achieve the directional sending of discovery messages from the Client to the Server and to determine whether the received information comes from the correct Server Participant node, it is necessary to specify the Locator information of the Server Participant node when creating the Client Particiapnt. The Locator contains IP address and port information, and at the same time, its guidPrefix also needs to be specified. The guidPrefix uniquely identifies the RTPS Participant.

[0080] A DiscoveryDatabase database is created in the Server Participant node to record all discovery messages from the Client. The Server will match the newly discovered Writer or Reader based on the information in the database and send the discovery messages of the other Client to the Client Participant node that matches successfully.

[0081] In the fully distributed discovery model, each Participant node in the domain needs to go through two discovery phases: SPDP and SEDP, and each Participant node needs to store the information of other nodes, regardless of whether other nodes are related to this node or not. When the number of Participant nodes in the domain increases, it will occupy a large amount of hardware resources.

[0082] Compared with the distributed discovery model, each Client Participant node under the Client-Server discovery model will only receive the discovery messages related to itself forwarded by the Server. Only the information of other Client Participant nodes related to itself is recorded in all Client Participants. This will effectively reduce the local memory occupation of the Client and is conducive to deploying DDS on resource-constrained devices.

[0083] In the Client-Server mode, only the messages in the discovery phase between Client nodes need to be processed and relayed by the Server node. Once the Client nodes match successfully with each other, the data transmission between user-defined entities still goes directly from end to end without passing through the Server node, which has no impact on the transmission performance of user data.

[0084] As the underlying transport protocol of DDS, the RTPS transport protocol uses RTPSReader and RTPSWriter for data transmission and reception, hereinafter simply referred to as Reader and Writer.

[0085] After the matching of Client nodes is completed in the ordinary Client-Server discovery model, the Client nodes still use the unicast mechanism to send messages. Under the unicast mechanism, the Writer sends messages to each already-matched ReaderLocator (including the destination address and port) in the form of a queue in turn. Queuing will inevitably cause delays, affecting real-time performance and transmission efficiency. The embodiment of the present application improves on the ordinary Client-Server discovery model and realizes a multicast transmission mechanism by automatically allocating ReaderLocator and Reader entityId for multicast in the discovery phase to solve the above problems.

[0086] The implementation process of the multicast transmission mechanism proposed by the present invention includes two parts. The first part is the processing process in the ServerParticipant node, and the second part is the processing process in the Client Participant node.

[0087] The improvement of the present invention on the ordinary Client-Server discovery model is mainly carried out around ReaderProxyData. As Figure 4 shown, ReaderProxyData records various information of the Reader itself, including Guid (including guidprefix, used to identify the Participant where the Reader is located, and entityId used to identify the Reader entity in the Participant), Topic (the topic subscribed by this Reader), and Locator (the IP address and port number used by this Reader to receive messages, which can be divided into unicast Locator and multicast Locator according to the type of IP address), etc.

[0088] When the Client Participant node and the Server Participant node are initialized, the initialization processes of the PDP and EDP phases are carried out in sequence, and the built-in entities for the Client-Server discovery protocol as shown in Figure 3 are created in the Participant.

[0089] Next, the two parts of the multicast transmission mechanism in this embodiment are received in detail respectively.

[0090] 1. The processing process of the first part, the Server Participant node

[0091] The processing work of the Server Participant node is mainly completed in three entities: EDPServerSUBReader, EDPServerSUBWriter, and DiscoveryDataBase.

[0092] The EDPServerSUBReader entity is responsible for receiving the ReaderProxyData sent by the EDPClientSUBWriter in the Client Participant node and allocating a new multicast Locator and entityId for it; the EDPServerSUBWriter entity is mainly responsible for sending the processed ReaderProxydata; DiscoeryDataBase is mainly responsible for storing the collected discovery information and the allocated multicast information to complete the matching of Readers and Writers under the same Topic.

[0093] The discovery processing flow of the Server Participant node for the Reader is as shown in Figure 5As shown in the figure. After the ClientParticipant node enters the EDP discovery phase, its subordinate EDPClientSUBWriter endpoint will send a change message to the EDPServerSUBReader endpoint in the ServerParticipant node. The ReaderProxyData of the Reader in the Client Participant is encapsulated in this Change message, and the ReaderProxyData can be extracted by deserializing this message. Then, the EDPServerSUBReader will reallocate the multicast Locator and entityId, replace the corresponding items in the original ReaderProxyData, and store the newly allocated multicast Locator, the entityId of the Reader, and the Topic name in the form of key-value pairs in the DiscoveryDataBase. In addition to writing the reallocated multicast information into the ReaderProxyData and storing it under the corresponding ParticipantProxyData, the guid of the newly discovered Reader will also be stored in readers_by_topic for subsequent matching management.

[0094] The modified ReaderProxyData is serialized in the EDPServerSUBWriter entity and encapsulated into a change. When sending, it passes through the filtering policy in the set filter and is only sent to the ClientParticipant where the Reader is located to trigger the processing work of the Client node.

[0095] The discovery processing flow of the Server Participant node for the Writer is as Figure 6 shown.

[0096] The Server Participant node mainly relies on three entities to handle the work related to Writer discovery: EDPServerPUBReader, EDPServerPUBWriter, and DiscoveryDataBase.

[0097] After the Client Participant node enters the EDP discovery phase, its subordinate EDPClientPUBWriter endpoint will send a change message to the EDPServerPUBReader endpoint in the Server Participant node.

[0098] The EDPServerPUBReader is responsible for receiving the WriterProxyData sent by the EDPClientSUBWriter in the ClientParticipant node. The EDPServerPUBWriter entity is mainly responsible for sending EDP messages containing WriterProxyData.

[0099] After receiving the message, the EDPServerPUBReader deserializes it, extracts the WriterProxyData from it, and stores the EDP message and the relevant information of the writer in the DiscoveryDataBase.

[0100] The DiscoveryDataBase stores the information of all discovered Readers and Writers, and matches the Readers and Writers according to the Topic.

[0101] The discovery message of the successfully matched Writer is passed to the EDPServerPUBWriter. When sending, it passes through the filtering policy in the set filter and is only sent to the Client Participant where the Reader is located.

[0102] The ReaderProxyData of the successfully matched Reader is serialized in the EDPServerSUBWriter entity and encapsulated into a change. When sending, it passes through the filtering policy in the set filter and is only sent to the ClientParticipant where the Writer is located.

[0103] Next, the processing process of each entity in the Server Participant will be elaborated in detail.

[0104] As Figure 7 shown, the processing process of the EDPServerSUBReader endpoint after receiving the change message is as follows:

[0105] Deserialize the change message to obtain the ReaderProxyData;

[0106] Obtain the Topic information from the ReaderProxyData;

[0107] Judge whether multicast resources have been allocated for this Topic;

[0108] If multicast resources have been allocated, directly search for its multicast Locator and Reader entityId in the DiscoveryDataBase;

[0109] If no multicast resources have been allocated yet, allocate a new multicast Locator for this Topic;

[0110] Furthermore, in this application, the multicast Locator is allocated on a Topic basis. The Locator in the ReaderProxyData sent by the EDPClientSUBReader defaults to a unicast Locator;

[0111] Furthermore, the method for allocating the multicast address is as follows:

[0112] MulticastAddress = BaseAddress + counter

[0113] where BaseAddress = 239.255.0.1, this address has been used by the discovery protocol, the counter is initialized to 0, and when a new Topic is discovered, the counter will automatically increment by 1. The range 239.255.0.0 to 239.255.255.255 is the multicast address segment defined by the IETF for local management.

[0114] The listening port number follows the regulations for user multicast data streams in the RTPS protocol, and the calculation method is as follows:

[0115] Port = PB + DG * DomainId + d2

[0116] where PB (Port Base Number) is 7400, DG (Domain Gain) is 250, DomainId is the domain id where the Reader is located, and d2 is 1. After this port allocation, all participants in the same domain will open the same listening port to listen for multicast data streams, logically separating Readers in different domains.

[0117] Allocate a new Reader entityId for this Topic;

[0118] To identify the destination Reader of the RTPS message, the Writer needs to specify the entityId of the destination Reader in the header when assembling the RTPS packet. Therefore, in addition to allocating the multicast Locator, it is also necessary to allocate the same entityId to all Readers subscribing to the same Topic. The calculation method for allocating the entityId is as follows. The entityId consists of a four-byte array. Among them:

[0119] entityId[3] = octet("0x04")

[0120] entityId[2] = octet(idcounter)

[0121] entityId[1] = octet(idcounter >> 8)

[0122] entityId[0] = octet(idcounter >> 16)

[0123] Among them, entityId[3] is used to represent and distinguish Reader / Writer, as well as with_key and no_key, and the default is the no_key type. When the original Client allocates entityId, it starts increasing from 0x00 by default. To avoid conflicts between the entityId reallocated by the Server side and the entityId allocated by the original Client, the idcounter counter is initialized to 0x7f. When a new Topic is discovered, idcounter is automatically incremented by 1;

[0124] Delete the original unicast Locator from ReaderProxyData and add the newly allocated multicast Locator;

[0125] Modify the Key value in ReaderProxyData with the new Reader GUID value;

[0126] Furthermore, ReaderProxyData is stored under the corresponding ParticipanProxyData in DiscoveryDataBase. Add the modified ReaderProxyData to the corresponding Participant in DiscoveryDataBase;

[0127] Add an identification bit first_feedback_flags_by_guid to it, which is used to indicate whether this ReaderProxyData is fed back to the Client side for the first time subsequently, and set this flag to true here;

[0128] Add the GUID of this Reader to the edp_sub_to_send send queue in DiscoveryDataBase;

[0129] Immediately call the processing thread of the Server, and feedback the modified ReaderProxyData to the Client Participant where the Reader is located through the EDPServerSUBWriter. The specific process of sending by the EDPServerSUBWriter is as Figure 8 shown;

[0130] Traverse the GUIDs in edp_sub_to_send, and search for the corresponding ReaderProxyData of this GUID in the DiscoveryDataBase;

[0131] After serializing the ReaderProxyData, obtain change, and store this change in the DiscoveryDataBase;

[0132] After passing through the filter of the EDPServerSUBWriter, this change can be fed back to the Client Participant where the Reader is located;

[0133] Set the flag bit first_feedback_flags_by_guid to false;

[0134] Next, elaborate on the specific processing process in the DiscoveryDataBase. Whenever the Server discovers a new Reader or Writer, it will call the matching algorithm to match the Writers or Readers under the same Topic, and put the discovery messages of the successful matches into the sending queue, waiting to be forwarded to the Participant where the successful match is located.

[0135] As Figure 9 shown, the process of matching Readers and Writers in the DiscoveryDataBase is processed as follows:

[0136] When the newly discovered one is a Writer:

[0137] Traverse all the already discovered Readers under the same Topic, add the Reader.relevant_status[Writer] flag bit and set it to false, and add the GUID of the Reader to edp_sub_to_send; add the Writer.relevant_status[Reader] flag bit and set it to false, and add the EDP message of the Writer to edp_pub_to_send;

[0138] When the newly discovered entity is a Reader:

[0139] Traverse all the already discovered Writers under the same Topic, add the Writer.relevant_status[Reader] flag and set it to false, add the Writer's EDP message to edp_pub_to_send; add the Reader.relevant_status[Writer] flag and set it to false, add the Reader's GUID to edp_sub_to_send;

[0140] After the matching is completed, as Figure 10 shown, the Server will process the data in the DiscoveryDataBase sending queue:

[0141] Traverse the Reader's GUIDs in edp_sub_to_send;

[0142] Find the corresponding change of the GUID from the DiscoveryDataBase;

[0143] EDPServerSUBWriter sends the change to the Writer with the Writer.relevant_status[Reader] flag set to false according to the filter, and sets the flag to true after the sending is successful;

[0144] Traverse the Writer's changes in edp_pub_to_send;

[0145] EDPServerPUBWriter sends the change to the Reader with the Reader.relevant_status[Writer] flag set to false according to the filter, and sets the flag to true after the sending is successful;

[0146] 2. Processing process of the second part, the Client Participant node

[0147] Figure 11 The following shows the processing process of the Client Participant node after receiving the EDP message sent from the Server.

[0148] When the EDPClientSUBReader receives an EDP message, if the change_guid.prefix of the change in the message is equal to the guid.prefix of this Participant, it indicates that the EDP message is the one feedback from the Server, and the processing is as follows: Figure 12 as shown;

[0149] Deserialize the change in the EDP message and extract the modified ReaderProxyData;

[0150] Obtain the modified multicast Locator and Reader entityId from the ReaderProxyData;

[0151] Create a ReceiverResource according to the modified multicast Locator;

[0152] Find the corresponding original Reader according to the Topic in the ReaderProxyData;

[0153] Combine the modified Reader entityId and the original Reader and store them in the ReceiverResource;

[0154] Furthermore, the purpose of creating a ReceiverResource is to create a Socket for multicast communication with the matching Writer, including opening a listening port and joining the multicast group;

[0155] Furthermore, as shown in Figure 14 the process of pairing the Reader entityId (modified) and the original RTPSreader under the same Topic and passing them into the ReceiverResource is as follows:

[0156] First, traverse the ReceiverResource list, which stores the ReceiverResource corresponding to each Locator;

[0157] If the current Locator matches the ReceiverResource, store the corresponding Reader and entityId in the associated_readers of the ReceiverResource in the form of key-value pairs;

[0158] When the EDPClientSUBReader receives an EDP message, if the change_guid.prefix in the change of the message is not equal to the guid.prefix of this Participant, it indicates that the EDP message is forwarded by the Server for matching with the local Writer. The processing is as follows:

[0159] Deserialize the change in the EDP message and extract the ReaderProxyData therein;

[0160] Query the Writers in the local Participant that can match it, and add the multicast locator in the ReaderProxyData to the matched_remote_locators of the Writer;

[0161] Through the above two parts of the processing in the discovery phase, the Writer can transmit data to multiple Readers that match it through multicast. The process of the specific multicast transmission mechanism is as Figure 15 shown:

[0162] Because multicast transmission is used, only one identical multicast locator needs to be reserved at the Reader or Writer side. Therefore, after receiving multiple multicast locators, the locatorSelector entity needs to merge the multicast locators with the same multicast address and listening port, so as to send only one multicast message to the same multicast address for data transmission, and the RTPSMessage contains the RTPSReader entityId assigned by the Server for this Topic.

[0163] Through the above multicast transmission mechanism, the Writer of the Client Participant node can send user data to multiple Readers associated under the same Topic through multicast at the same time.

[0164] In view of the characteristic of low bandwidth consumption of the Client-Server discovery model, the present invention proposes a multicast transmission mechanism, which effectively solves the delay problem caused by queue sending, improves the real-time performance of DDS transmission, can effectively reduce the network load, and at the same time creates conditions for the integration of DDS and TSN.

[0165] As described above, it is only the specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of various equivalent modifications or substitutions, and these modifications or substitutions should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for implementing a multicast transmission mechanism of a data distribution service protocol based on a Client-Server discovery model, characterized in that: include: In the Client-Server discovery model, create reader proxy data storing reader attributes and information, and writer proxy data storing writer attributes and information; Server participant node: receives the discovery message sent by the publisher client, extracts the writer proxy data from it, groups the writers with the associated topic as the key, and stores it in the server's database; receives the discovery message sent by the subscriber client, extracts the reader proxy data from it; wherein the server dynamically allocates a unified multicast resource for the newly discovered topic based on the reader proxy data, and the allocation includes modifying the unicast address, listening port and reader entity identifier in the locator of the reader's original discovery message to a multicast address, listening port and reader entity identifier that are unified with the topic, and storing the allocation result and the topic in the form of a key-value pair in the server's database; the server completes the matching between clients and forwards the discovery message to the relevant client; Client participant node: receives and processes the discovery message sent by the server participant node; In the server participant node, the matching process of readers and writers under the newly discovered topic is specifically as follows: Traverse all discovered readers under the same topic, add the reader-related status flag and set it to false, and add the reader's globally unique identifier to the database subscriber's waiting queue; Traverse all discovered writers under the same topic, add the writer-related status flag and set it to false, and add the writer's discovery message to the database publisher's waiting queue; For writers or readers waiting to be forwarded, the specific process of the server forwarding the discovery message to the client is as follows: Forward the reader's discovery message: The entity in the server participant responsible for sending the EDP message about the subscriber traverses the globally unique identifier of the reader in the database subscriber's waiting queue, searches the discovery database for the modified reader proxy data corresponding to the globally unique identifier, encapsulates the data into an EDP discovery message after sequencing, and sends the new discovery message to the client participant where the writer's related status flag is false according to the filtering rules of the sending entity, and sets the flag to true after the sending is successful; Forwarding the discovery message of the writer: The entity in the server participant responsible for sending the EDP message about the publisher traverses the discovery message of the writer in the database publisher's waiting queue, and sends the discovery message to the client participant where the reader's related status flag is false according to the filtering rules, and sets the flag to true after the sending is successful.

2. The method according to claim 1, characterized in that The reader proxy data includes a globally unique identifier for uniquely identifying each data distribution service entity, a topic subscribed by the reader, and a locator for the reader to receive messages; the globally unique identifier includes a globally unique identifier prefix for identifying the participant to which the entity belongs, and an entity identifier for identifying different entities under the same participant; wherein the same entity identifier is assigned to all readers who subscribe to the same topic; The multicast resource includes a multicast address, a listening port, and a reader entity identifier.

3. The method according to claim 2, characterized in that The server dynamically allocates unified multicast resources for the newly discovered topic based on the reader proxy data, specifically: Modify the unicast address, listening port and reader entity identifier in the locator in the original discovery message of the reader to the multicast address, listening port and reader entity identifier that are unified with the topic; The modified reader proxy data is serialized and repackaged into a discovery message, which is sent to the participant entity where the reader itself is located.

4. The method according to claim 3, characterized in that The multicast resource allocation process specifically includes: The allocation expression of the multicast address is specifically: MulticastAddress = BaseAddress + counter Among them, BaseAddress is the base address, which has been used by the discovery protocol; counter is a counter; when a new topic is discovered, the counter will automatically increase by 1; The listening port follows the provisions of the RTPS protocol for user multicast data streams, and the allocation expression is: Port = PB + DG * DomainId + d2 Among them, PB is the port cardinality; DG is the domain gain; DomainId is the domain id of the reader; d2 is 1; after this port allocation, all client participants in the same domain open the same listening port to listen to the multicast data stream; The entity identifier is composed of a four-byte array; the highest byte is used to characterize and distinguish readers / writers and those with key values ​​and those without key values, and the default is the type without key values; the three bytes other than the highest byte are used as an id counter, initialized to 0x7f, and the id counter automatically increases by 1 when a new topic is discovered.

5. The method according to claim 3, characterized in that: In the server, the process of feeding back the reader proxy data containing the multicast resource to the participant entity where the reader itself is located is specifically as follows: Add the reader's first feedback flag and set it to true, and add the reader's globally unique identifier to the database's subscriber sending waiting queue; The entity in the server participant that is responsible for sending the subscriber entity discovery protocol EDP message traverses the globally unique identifier of the reader in the queue, searches the server's discovery database for the modified reader proxy data corresponding to the globally unique identifier, encapsulates the data into an EDP discovery message after sequencing, and sends the new discovery message to the participant entity where the reader itself is located according to the filtering rules of the sending entity, and sets the first feedback flag to false after successful sending.

6. The method according to claim 2, characterized in that The client participant node is provided with a receiver resource library, and the receiver resource library receives multicast messages by using the constructed socket and the matching writer.

7. The method according to claim 6, characterized in that The client participant will receive the discovery message sent by the server participant node and make corresponding processing, specifically: 1) Receive the writer discovery message sent by the server and complete the matching work between the local reader and the writer; receive the modified reader discovery message sent back by the server and extract the multicast address, listening port and reader entity identifier assigned by the server for the topic; 2) Create a user datagram protocol type socket, open the specified listening port, and add the socket to the multicast group specified by the multicast address to receive multicast messages sent to the multicast address; 3) Create a receiving resource library and put the newly created socket into the receiver resource; 4) Find the corresponding reader in the local participant entity according to the topic fed back, and put the reader and the fed back reader entity identifier into the newly created receiver resource library; 5) When the socket in the receiver resource library receives a multicast message containing user data, the message receiver will take out the reader entity identifier specified in the message, search for the reader corresponding to the reader entity identifier in the receiver resource library, pass the data to the reader, and complete the data reception.

8. The method according to claim 7, characterized in that The client participant node also includes sending a multicast message, specifically: Receive the reader discovery message sent by the server, complete the matching work between the local writer and the reader, and store the reader locator of the reader in the writer; When sending user data, the writer will traverse all reader locators that have matched itself, and then merge the locators with the same multicast address and listening port, so that only one multicast message will be sent to the same multicast address to transmit data, and the multicast message will contain the reader entity identifier assigned by the server to the topic.

Images