A method for optimizing RTPS protocol resource usage in DDS communication

Abstract

The invention discloses a method for optimizing the use of RTPS protocol resources in DDS communication. When a PUB end / SUB end receives a data(p) message from a peer end, a builtin-proxy entity is created locally, and a builtin-proxy entity state table is created at the same time. For example, when the SUB end receives and processes the notification information of all writers from the PUB end, the SUB end sends an acknack message to the PUB end. At this time, the SUB end has completed the interaction of link building, and the memory occupied by the builtin-proxy publication writer entity can be released. At the same time, after the PUB end receives the acknack message from the SUB end, the SUB end has received and processed all the writer information of the PUB end. At this time, the PUB end has completed the interaction of link building, and the space occupied by the builtin-proxy publication reader entity can be released. The invention reduces the occupied memory space by releasing the memory space of the builtin-proxy entity, and the space saved in different scenarios is different.

Description

Technical Field

[0001] The present invention relates to DDS communication technology, and in particular to a method for optimizing the use of RTPS protocol resources in DDS communication. Background Art

[0002] During the DDS communication process, each pair of two ends that need to communicate will store the information of the other end on the local end to facilitate the maintenance of the RTPS protocol communication link with the other end. This information includes information for discovering the other end, information for establishing a link with the other end, and information for data exchange with the other end. Due to the large amount of information, the local end needs to open up a large memory space to store the information of the other end for normal communication.

[0003] When DDS communication runs through the RTPS protocol on some resource-constrained devices, it will pose a great challenge to the resource management of the device because its information occupies too many resources, which directly leads to a reduction in the number of peers that can communicate with the device, thereby affecting the design of the system's communication model or causing business abnormalities due to the system's inability to communicate with the specified peer.

[0004] In order to establish and maintain the links at both ends of DDS communication, the RTPS protocol not only establishes the endpoint entity of DDS communication on the local end, but also stores some information of the endpoint entity on the local end, such as the address, port number information, topic information, and qos information used to establish the connection; seq information, message fragmentation, and related information used for data communication. This information will be stored in two types of entities: builtin-proxy (built-in proxy) entity and user-proxy (user proxy) entity.

[0005] The builtin-proxy entity is defined in the RTPS protocol and is used to complete the link creation at each end of the DDS communication. After the DDS communication link is created, this type of entity will no longer play its role if there is no new access request from the other end. However, due to the uncertainty of the new access request from the other end, this type of entity will still be stored on the local end and occupy the memory space of the local end; the user-proxy entity is the entity that implements the data communication of the RTPS protocol after the DDS communication link is established, that is, the entity that actually performs data interaction. This type of entity maintains the timing and integrity of the data throughout the data interaction process. Summary of the invention

[0006] To solve the deficiencies in the prior art, the present invention aims to provide a method for optimizing the use of RTPS protocol resources in DDS communication.

[0007] To achieve the purpose of the present invention, the technical solution adopted by the present invention is:

[0008] A method for optimizing RTPS protocol resource usage in DDS communication, comprising the steps of:

[0009] (1) When the PUB / SUB end receives the data(p) message from the other end, it creates a builtin-proxy entity locally and creates a builtin-proxy entity status table at the same time, recording the status of the created builtin-proxy entity as alive and the status of the uncreated builtin-proxy entity as clear;

[0010] (2) In the data(w) notification phase, when the SUB side receives the notification information of all writers on the PUB side and completes the processing, the SUB side sends an acknack message to the PUB side. At this time, the builtin-proxy publication writer on the SUB side has completed the interaction of establishing the chain and can release the memory occupied by the builtin-proxy publication writer entity;

[0011] At the same time, after the PUB receives the acknack message from the SUB, the SUB has received and processed all the writer information from the PUB. At this time, the builtin-proxy publication reader on the PUB has completed the interaction of establishing the link, and the memory occupied by the builtin-proxy publication reader entity can be released;

[0012] (3) In the data(r) notification phase, when the PUB receives the notification information of all readers on the SUB side and completes the processing, the PUB side sends an ack message to the SUB side. At this time, the builtin-proxy subscription writer on the PUB side has completed the interaction of establishing the chain and can release the memory occupied by the builtin-proxy subscription writer entity;

[0013] At the same time, after the SUB side receives the ack message from the PUB side, the PUB side has received and processed all the reader information from the SUB side. At this time, the builtin-proxy subscription reader on the SUB side has completed the interaction of establishing the link, and the memory occupied by the builtin-proxy subscription reader entity can be released.

[0014] Furthermore, in step (2), the data(w) notification phase includes the following specific steps:

[0015] When the PUB notifies the SUB of the number of its own writers, it matches each of its own writers with the message seq in the whc of the builtin entity one by one. The seq in the whc is consistent with the seq in the heartbeat. The correspondence table between writers and seq is recorded. The status of each record in the table is nack. The SUB replies with acknack information to the PUB, which includes the writer information that needs to be transmitted by the PUB.

[0016] The PUB receives the acknack message from the SUB, parses the bitmapBase and numbits, calculates the seq that has not been confirmed by the SUB, obtains nack-seq, queries the writer and seq correspondence table, and sets the status of the record whose seq is not in nack-seq to ack; at the same time, according to the acknack message from the SUB, the PUB notifies the SUB of the writer information it needs.

[0017] Furthermore, in step (2), the SUB end releases the entity memory space specifically including: the SUB end releases the memory occupied by its builtin-proxy publication writer entity, searches the builtin-proxy entity state table, and sets the state of the builtin-proxy publication writer entity to a clear state.

[0018] Furthermore, in step (2), the PUB end releases the entity memory space specifically including: the PUB end releases the memory occupied by the builtin-proxy publication reader entity, searches the builtin-proxy entity state table, and sets the state of the builtin-proxy publication reader entity to a clear state.

[0019] Furthermore, after the builtin-proxy entity memory space is released, the builtin-proxy entity state table is checked. When the states of all entities except the builtin-proxy participant detector entity are clear, the builtin-proxy participant detector entity memory is released, its state is set to clear, and the builtin-proxy entity state table is recovered.

[0020] Furthermore, after the builtin-proxy entity memory is released, if a subsequent participant in the established chain creates a new user entity, upon receiving a heartbeat message from the other end, the corresponding builtin-proxy entity is recreated based on the writer entity ID in the heartbeat message, and the notification of the newly created user entity is completed with it.

[0021] The beneficial effect of the present invention is that, compared with the prior art, the present invention reduces the occupied memory space by releasing the memory space of the builtin-proxy entity, and the space saved is different in different scenarios. Because the space occupied by the participant itself at the opposite end is fixed, which is about 2-3 times the space of each builtin-proxy entity, each time a participant at the opposite end is connected, the participant itself can reduce more than 75% of the memory space. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a schematic diagram of RTPS establishing a link;

[0023] Figure 2 It is a flowchart of the writer notification process;

[0024] Figure 3 It is a flow chart of the method for optimizing the use of RTPS protocol resources in DDS communication described in the present invention. DETAILED DESCRIPTION

[0025] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the protection scope of this application.

[0026] The builtin-proxy type entity mainly exists in the process of establishing a link between the two ends of the DDS communication. The process of establishing a link by RTPS is as follows: Figure 1 As shown, it includes five parts, namely:

[0027] 1. data(p) notification phase: notify other participants in the domain that they are online;

[0028] 2. Data (w) notification phase: notify the peer participant of its own writer entity data;

[0029] 3. Data (r) notification phase: notify the peer participant of its own reader entity data;

[0030] 4. Data (m) notification phase: notify the peer participant of their own pmd data;

[0031] 5. Confirmation phase: confirm that the user entities at both ends have established a connection and can communicate data.

[0032] The builtin-proxy entity plays a role in stages 2 - 4. The RTPS protocol requires that the builtin entity be carried in the data(p) message to be notified to the peer end. After receiving the data(p) message, the peer end creates a corresponding builtin-proxy entity on its own according to the information in the message, and stores the address, port, QoS, topic and other information of the DDS communication peer end.

[0033] The builtin-proxy entity, according to specific functions, includes combinations of the following multiple entities: builtin-proxy participant detector, builtin-proxy publication detector, builtin-proxy publication announcer, builtin-proxy subscription detector, builtin-proxy subscription announcer, builtin-proxy participant secure reader, builtin-proxy participant secure writer, builtin-proxy secure participant volatile message reader, builtin-proxy secure participant volatile message writer, builtin-proxy participant stateless message reader, builtin-proxy participant stateless message writer, builtin-proxy secure participant message reader, builtin-proxy secure participant message writer, builtin-proxy secure publication reader, builtin-proxy secure publication writer, builtin-proxy particpiant message data reader, builtin-proxy participant message data writer, builtin-proxy participant state detector, builtin-proxy partcipant state announcer, etc.

[0034] Each of these entities will occupy a certain amount of memory space. When memory resources are scarce, when the number of DDS communication peers increases, it will put a lot of pressure on the memory. After the DDS communication link is established, these entities usually have no effect on the protocol or communication before the next DDS communication link is established. Therefore, the present invention will optimize the use of such entities according to the RTPS protocol interaction process.

[0035] When the local end receives the data(p) message, it will create a builtin-proxy entity. Then, in the data(w) notification phase, the PUB end will send a heartbeat message to the other end to notify the local writer capability and inform the SUB end of the local writer configuration. After the SUB end queries its own storage information, if it finds that there is no writer information notified, it will reply with an acknack message to the PUB end, requesting the PUB end to notify the writer information. The PUB end then notifies the SUB end of the writer information through the data(w) message, and confirms with the SUB end again through the heartbeat message. After receiving the information, the SUB end replies with acknack and saves the writer information of the PUB end. After that, the builtin-proxy publicationreader entity of the PUB end and the builtin-proxy publication writer entity of the SUB end have completed their mission in the process of establishing the link this time, and the space they occupy can be released, but the release time of their memory space needs to be accurately determined, otherwise the transmission of writer information will be lost, and ultimately the two ends cannot carry out normal data communication.

[0036] The writer notification process is as follows: Figure 2 , including the steps of:

[0037] P1: The PUB side notifies the SUB side of the number of its own writers;

[0038] S2: SUB sends a reply to PUB, which contains the writer information that needs to be transmitted by PUB.

[0039] P3: The PUB side notifies the SUB side of the writer information required by the SUB side;

[0040] S4: The SUB side continues to reply acknack to the PUB side according to the received message;

[0041] P5: The PUB end retransmits the writer information that the SUB end has not received to the SUB end;

[0042] S7: After multiple ping-pongs, the SUB receives all the writer information from the PUB and replies with acknack;

[0043] P7: After receiving confirmation of all writer information from SUB, PUB stops sending writer messages.

[0044] The present invention operates the builtin-proxy entity under the condition of ensuring the integrity of the RTPS protocol to achieve reasonable and effective management and utilization of resources, and also explains supplementary solutions to the problems derived from this invention.

[0045] like Figure 3 As shown, the method for optimizing the use of RTPS protocol resources in DDS communication according to the present invention is based on the above-mentioned interaction process and includes the steps of:

[0046] (1) When the PUB / SUB end receives the data(p) message from the other end, it creates each builtin-proxy entity locally and creates a builtin-proxy entity status table. According to the status of the builtin-proxy entities that have been created, the status of each created entity is recorded as alive, and the status of the uncreated builtin-proxy entity is clear;

[0047] For example, when the PUB receives a data(p) message from the SUB, it creates each builtin-proxy entity locally and creates a builtin-proxy entity status table. According to the status of the builtin-proxy entities that have been created, the status of each created entity is recorded as alive, and the status of the builtin-proxy entities that have not been created is clear.

[0048] When the SUB end receives the data(p) message from the PUB end, it creates each builtin-proxy entity locally and creates a builtin-proxy entity status table. According to the status of the builtin-proxy entities that have been created, the status of each created entity is recorded as alive, and the status of the builtin-proxy entities that have not been created is clear.

[0049] (2) In the data(w) notification phase, when the SUB side receives the notification information of all writers on the PUB side and completes the processing, the SUB side will send an acknack message to the PUB side. At this time, the builtin-proxy publication writer on the SUB side has completed the interaction of establishing a chain, and the memory occupied by the builtin-proxy publication writer entity can be released. After the PUB side receives the acknack message from the SUB side, it means that the SUB side has received and processed all the writer information on the PUB side, and the PUB side no longer needs to notify the SUB side of the writer information. At this time, the builtin-proxy publication reader on the PUB side has completed the interaction of establishing a chain, and the memory occupied by the builtin-proxy publication reader entity can be released.

[0050] (2.1) When the PUB end notifies the SUB end of the number of its own writers, it matches each of its own writers with the message seq in the whc of the builtin entity one by one. The seq in the whc is consistent with the seq in the heartbeat. Then, a correspondence table between writers and seq is recorded. The status of each record in the table is nack.

[0051] (2.2) SUB sends an acknack message to PUB, which contains the writer information that needs to be transmitted by PUB.

[0052] (2.3) The PUB receives the acknack message from the SUB, parses the bitmapBase and numbits, calculates the seq that has not been confirmed by the SUB, obtains nack-seq, queries the writer-seq correspondence table, and sets the status of the record whose seq is not in nack-seq to ack; at the same time, according to the acknack message from the SUB, the SUB is notified of the writer information it needs;

[0053] (2.4) The SUB side continues to reply acknack to the PUB side according to the received message;

[0054] (2.5) The PUB receives the acknack message from the SUB, and follows the same process as step (2.3) to set the newly confirmed seq to the ack state;

[0055] (2.6) After multiple ping-pongs, the SUB receives all the writer information from the PUB and replies with acknack. The SUB then determines that it has received all the writer information notified by the PUB and successfully stored it in the memory space. The SUB has achieved the matching work with the writer on the PUB, that is, it has completed the current PUB writer discovery task. The SUB releases the memory occupied by its builtin-proxy publication writer entity, searches the builtin-proxy entity status table, and sets the status of the builtin-proxy publication writer entity to clear.

[0056] (2.7) The PUB receives the acknack message from the SUB, and continues the process of step (2.3), setting the newly confirmed seq to the ack state, and at the same time determines that all seqs are in the ack state. At this time, the PUB has completed its writer notification task. Then, the correspondence table between writer and seq is cleared, the PUB releases the memory occupied by the builtin-proxy publicationreader entity, searches the builtin-proxy entity state table, and sets the state of the builtin-proxy publicationreader entity to the clear state.

[0057] (3) In the data(r) notification phase, the reader notification process on the SUB side is similar to the writer notification process on the PUB side. When the PUB side receives the notification information of all readers on the SUB side and completes the processing, the PUB side will send an ack message to the SUB side. At this time, the builtin-proxy subscription writer on the PUB side has completed the interaction of establishing a link, and the memory occupied by the builtin-proxy subscription writer entity can be released. At the same time, after the SUB side receives the ack message from the PUB side, it means that the PUB side has received and processed all the reader information on the SUB side. The SUB side no longer needs to notify the PUB side of the reader information. At this time, the builtin-proxy subscription reader on the SUB side has completed the interaction of establishing a link, and the memory occupied by the builtin-proxy subscription reader entity can be released.

[0058] The processing of other builtin-proxy is similar to the above two processes, where announcer is analogous to the processing of writer and detector is analogous to the processing of reader.

[0059] When the builtin-proxy entity memory space is released, check the builtin-proxy entity status table. When the states of all entities except the builtin-proxy participant detector entity are clear, release the builtin-proxy participant detector entity memory, set its state to clear, and recycle the builtin-proxy entity state table.

[0060] After the memory of the builtin-proxy entity is released, if a subsequent participant in the established link newly creates a user entity, since there is no corresponding builtin-proxy entity locally, the new user entity cannot be notified. In this scenario, when a heartbeat message is received from the other end, the corresponding builtin-proxy entity is recreated according to the writer entity ID in the heartbeat message, and the notification of the newly created user entity is completed with it. The solution of the present invention has no impact on the scenario of newly added participants.

[0061] The beneficial effect of the present invention is that, compared with the prior art, the present invention saves different amounts of space in different scenarios by releasing the memory space of the builtin-proxy entity. Because the space occupied by the participant itself at the opposite end is fixed, which is about 2-3 times the space of each builtin-proxy entity, in the case of the most basic builtin-proxypublication writer, builtin-proxy publication reader, builtin-proxysubscription writer, builtin-proxy subscription reader, builtin-proxyparticpiant message datareader, builtin-proxy participant message datawriter, and builtin-proxy participant detector, each time a participant at the opposite end is connected, the participant itself can reduce more than 75% of the memory space.

[0062] The applicant of the present invention has made a detailed explanation and description of the implementation examples of the present invention in conjunction with the drawings in the specification. However, those skilled in the art should understand that the above implementation examples are only preferred implementation schemes of the present invention, and the detailed description is only to help readers better understand the spirit of the present invention, but not to limit the scope of protection of the present invention. On the contrary, any improvements or modifications based on the inventive spirit of the present invention should fall within the scope of protection of the present invention.

Claims

1. A method for optimizing RTPS protocol resource usage in DDS communication, characterized in that: Includes steps: (1) When the PUB / SUB end receives the data(p) message from the other end, it creates a built-in-proxy entity locally and creates a built-in-proxy entity status table, recording the status of the created built-in-proxy entity as alive and the status of the uncreated built-in-proxy entity as clear; (2) In the data(w) notification phase, when the SUB side receives the notification information of all writers on the PUB side and completes the processing, the SUB side sends an acknack message to the PUB side. At this time, the builtin-proxy publication writer on the SUB side has completed the interaction of establishing the chain and can release the memory occupied by the builtin-proxy Publication writer entity; At the same time, after the PUB receives the acknack message from the SUB, the SUB has received and processed all the writer information from the PUB. At this time, the builtin-proxy publication reader on the PUB has completed the interaction of establishing the link, and the memory occupied by the builtin-proxy publication reader entity can be released; The data(w) notification phase includes the following specific steps: when the PUB notifies the SUB of the number of its own writers, it matches each of its own writers with the message seq in the whc of the builtin entity one by one, the seq in the whc is consistent with the seq in the heartbeat, and records the correspondence table between writers and seq. The status of each record in the table is nack; the SUB replies with acknack information to the PUB, which includes the writer information that the PUB needs to transmit; The PUB receives the acknack message from the SUB, parses the bitmapBase and numbits, calculates the seq that has not been confirmed by the SUB, obtains nack-seq, queries the writer-seq correspondence table, and sets the status of the record whose seq is not in nack-seq to ack; at the same time, according to the acknack message from the SUB, the PUB notifies the SUB of the writer information it needs; The SUB end releases the entity memory space specifically including: the SUB end releases the memory occupied by its builtin-proxy publication writer entity, searches the builtin-proxy entity state table, and sets the state of the builtin-proxy publication writer entity to the clear state; The PUB end releases the entity memory space specifically including: the PUB end releases the memory occupied by the builtin-proxy publication reader entity, searches the builtin-proxy entity state table, and sets the state of the builtin-proxy publication reader entity to the clear state; (3) In the data(r) notification phase, when the PUB receives the notification information of all readers on the SUB side and completes the processing, the PUB side sends an ack message to the SUB side. At this time, the builtin-proxy subscription writer on the PUB side has completed the interaction of establishing the chain and can release the memory occupied by the builtin-proxy subscription writer entity; At the same time, after the SUB side receives the ack message from the PUB side, the PUB side has received and processed all the reader information of the SUB side. At this time, the builtin-proxy subscription reader on the SUB side has completed the interaction of establishing the link, and the memory occupied by the builtin-proxy subscription reader entity can be released; When the builtin-proxy entity memory space is released, check the builtin-proxy entity state table. When the states of all entities except the builtin-proxy participant detector entity are clear, release the builtin-proxy participant detector entity memory, set its state to clear, and recycle the builtin-proxy entity state table.

2. The method for optimizing RTPS protocol resource usage in DDS communication according to claim 1, characterized in that: After releasing the builtin-proxy entity memory, if a subsequent participant in the established chain creates a new user entity, when receiving the heartbeat message from the other end, it will recreate the corresponding builtin-proxy entity based on the writer entity ID in the heartbeat message and complete the notification of the newly created user entity.

Images