A method for accurately tracking specified RTPS messages in DDS communication
By defining the packet resolution structure and configuration interface in the DDS communication network, the precise tracking of RTPS packets is achieved, and the difficulty of identifying and analyzing messages in the DDS communication network is solved, greatly improving the problem location and resolution efficiency.
Patent Information
- Application Number
- CN202311382335.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-10-24
- Publication Date
- 2025-03-21
- Estimated Expiration
- 2043-10-24
AI Technical Summary
In the DDS communication network, due to the communication link formed by a large number of RTPS participants, the message interaction is complicated. If a message is lost or handled abnormally, it is difficult to identify and analyze, and the prior art is difficult to achieve accurate tracking of specified RTPS messages.
By defining a specific message resolution structure and configuration interface, users can specify the RTPS message attributes that need to be tracked. The PUB and SUB sides respectively add headers during serialization and analysis, identify the tracking status, and record process location information to achieve accurate tracking of specified RTPS messages.
It realizes accurate tracking of RTPS messages, simplifies the problem location and resolution process, improves analysis efficiency, reduces dependence on the environment, and makes up for the shortcomings of the tracking capabilities of designated messages in the existing technology.
Smart Images

Figure CN117478767B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to DDS communication technology, and in particular to a method for accurately tracking a specified RTPS message in DDS communication. Background Art
[0002] In the DDS communication network implemented by the RTPS protocol stack, there are a large number of RTPS participants, and each pair of participants may form an RTPS communication link. Therefore, there will be a large number of message interactions in the entire DDS communication network, including RTPS protocol messages and RTPS data messages. In actual application scenarios, if a message is lost or processed abnormally, identifying this message in the entire network is like looking for a needle in a haystack. Even if the required message can be identified from a large number of messages, and then the abnormality is analyzed based on the message, the difficulty of abnormal analysis is greatly increased due to the lack of processing procedures. Summary of the invention
[0003] In order to solve the deficiencies in the prior art, the object of the present invention is to provide a method for accurately tracking a specified RTPS message in DDS communication.
[0004] To achieve the purpose of the present invention, the technical solution adopted by the present invention is:
[0005] A method for accurately tracking a specified RTPS message in DDS communication, comprising the steps of:
[0006] (1) Define a specific message parsing structure and provide a configuration interface for users to specify the attributes of specific RTPS messages that need to be tracked;
[0007] (2) The PUB receives the user's data sending request and serializes the user data; adds a header to the serialization structure to indicate whether the message needs to be tracked; the user calls the RTPS data sending interface and searches the user data for the attribute value of the RTPS message configured by the user; then, obtains the header of the serialized data, identifies the tracking status bit, and records the current process position in the process position information recording point; then, the RTPS protocol stack sends the user data to the network and writes the user data to the writer's history_cache;
[0008] (3) The SUB receives the RTPS message from the network, receives and parses the user data, and obtains the sub-message of the message; parses the sub-message, obtains the serialized header part, sets the current tracking state, and records the current process position in the process position information recording point; the RTPS protocol stack saves the sample data in the reader's sample space; for the sample data that can be notified to the user, the sample data is taken out from the reader's sample space and placed in the reader's history cache history_cache;
[0009] (4) Return the message processing result to the PUB end. After receiving the processing result from the SUB end, the PUB end searches for the relevant data from the writer's history_cache and deletes the data from the writer's history_cache. At the same time, the tracking status of the serialization header is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point.
[0010] (5) The user obtains the data in the reader's history cache history_cache through the SUB end. The SUB end deserializes the data. During the deserialization process, the current tracking status is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point, and then the deserialized data is passed to the user.
[0011] Furthermore, in step (1), a specific message parsing structure is defined, including specific character information in the message that needs to be tracked, the length of the specific character information that needs to be tracked, the starting position of the specific character that needs to be tracked in the data, the current tracked process location information recording point, and a status flag indicating whether to perform tracking.
[0012] Furthermore, in step (1), the user sets the attributes of the RTPS message to be tracked through the provided configuration interface before sending the message, and the RTPS protocol stores the character information and length configured by the user in the cache.
[0013] Furthermore, in step (2), when the user calls the RTPS data sending interface, the attribute value of the RTPS message configured by the user is searched in the user data. If the user-specified configuration is not found in the user's data information, the normal sending process is followed; if the user-specified configuration is found in the user's data information, the header of the serialized data is obtained, the tracking status bit is identified, and the current process position is recorded in the process position information recording point.
[0014] Furthermore, in step (2), during the data serialization process, the added header is skipped first, the data is serialized, and written into the serialization buffer.
[0015] Furthermore, in step (2), the RTPS protocol stack sends the user data to the network and determines the current tracking state. If the current tracking state is set, the current process position is recorded in the process position information recording point.
[0016] Furthermore, in step (2), the RTPS protocol stack writes the user data into the writer's history_cache and determines the current tracking state. If the current tracking state is set, the current process position is recorded into the process position information recording point.
[0017] Furthermore, in step (3), the serialized header part is obtained. If the tracking status of the header part is not set, normal receiving processing is performed; if the tracking status of the header part is set, the current tracking status is set, and the current process position is recorded in the process position information recording point.
[0018] Furthermore, in step (3), the RTPS protocol stack takes the sample data from the reader's sample space and puts it into the reader's history cache history_cache, and determines the current tracking state. If the current tracking state is set, the current process position is recorded in the process position information recording point.
[0019] The beneficial effect of the present invention is that, compared with the prior art, the present invention adds accurate tracking of specified RTPS messages in the RTPS protocol stack, providing strong support for developers to locate and solve problems.
[0020] The method of the present invention records the overall processing flow of the RTPS message from receiving a user request, to sending it out at the PUB end, to receiving it at the SUB end, and then to delivering it to the user. The method can clearly, conveniently and accurately record the entire flow process of the RTPS message, and provide developers with a set of efficient methods for locating problems, which greatly shortens the time for solving problems by viewing messages or reading processes, as well as the dependence on the environment, effectively improves the accuracy of problem locating and the speed of solving problems, and fills the gap in the RTPS protocol for accurately tracking specified messages. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Figure 1 This is the RTPS message processing flow chart;
[0022] Figure 2 It is a flow chart of the method for accurately tracking a specified RTPS message in DDS communication according to the present invention. DETAILED DESCRIPTION
[0023] 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.
[0024] In DDS communication, RTPS messages are divided into two categories: protocol messages and data messages. Protocol messages are messages that complete RTPS notification and link creation, and data messages are messages for data interaction between users after link creation. Regardless of whether it is a protocol message or a data message, the RTPS protocol handles them in a similar way.
[0025] like Figure 1 As shown, the RTPS message processing flow is as follows (taking data messages as an example):
[0026] (1) The PUB receives the user's data sending request and serializes the user data. It sends the serialized user data in pieces or as a whole according to the user's configuration. While sending, it stores the serialized user data in the writer's history cache history_cache.
[0027] (2) The SUB receives the RTPS message from the network, receives and parses the user data, and obtains the sub-message of the message; parses the sub-message to obtain data fragments, and saves the data fragments according to the situation; combines the saved data fragments into samples, and saves the sample data in the reader's sample space; for the sample data that can be notified to the user, the sample data is taken out from the reader's sample space and put into the reader's history cache history_cache;
[0028] Parsing user data includes parsing the RTPS message header to obtain the RTPS message payload; parsing the RTPS message payload, and analyzing the sub-message type corresponding to this message according to the RTPS sub-message structure definition. The sub-message type includes multiple sub-message types such as heartbeat sub-message, data sub-message, acknack sub-message, and dst sub-message.
[0029] For data sub-messages, there are two types: fragmented sub-messages and unfragmented sub-messages. For fragmented sub-messages, RTPS stores the fragments in the fragment space corresponding to the relevant entity, and merges the fragments while storing them to determine whether to generate samples. For unfragmented sub-messages, samples are directly generated. For the generated samples, they are placed in the sample space of the relevant entity, that is, the sample space of the reader.
[0030] For sample data that can be notified to the user, the sample data is taken out from the reader's sample space and put into the reader's history cache history_cache.
[0031] (3) Then the message processing result is returned to the PUB side. After receiving the processing result from the SUB side, the PUB side deletes the data from the writer's history_cache;
[0032] (4) The user obtains the data in the reader's history cache history_cache through the SUB-side RTPS interface or listener. The SUB-side deserializes the data and passes it to the user.
[0033] The method for accurately tracking specified RTPS messages in DDS communication described in the present invention implements tracking of specified RTPS messages by adding a specific message tracking method to the above process, thereby providing strong technical support for locating and solving problems.
[0034] like Figure 2 As shown, the method for accurately tracking a specified RTPS message in DDS communication according to the present invention comprises the steps of:
[0035] (1) Define a specific message parsing structure and provide a configuration interface for users to specify the attributes of specific RTPS messages that need to be tracked;
[0036] Define a specific message parsing structure, including: the specific character information in the message that needs to be tracked, the length of the specific character information that needs to be tracked, the starting position of the specific character that needs to be tracked in the data, the current process location information recording point tracked, and the mark bit of whether the process is tracked.
[0037] Provide users with a configuration interface to specify the attributes of specific RTPS messages that need to be tracked; users use the provided configuration interface to set the attributes of the RTPS messages that need to be tracked before sending messages, and the RTPS protocol stores the character information and length configured by the user in the cache.
[0038] (2) The PUB receives the user's data sending request and serializes the user data; adds a header to the serialization structure to indicate whether this message needs to be tracked; the user calls the RTPS data sending interface and searches for the attribute value of the RTPS message configured by the user in the user's data information; then, obtains the header of the serialized data, identifies the tracking status bit, and records the current process position in the process position information recording point; then, the RTPS protocol stack sends the user data to the network and writes the user data to the writer's history_cache (whc);
[0039] When the user calls the RTPS data sending interface, the attribute value of the RTPS message configured by the user (that is, the specific character information that needs to be included in the message) is searched in the user's data information; if the user-specified configuration is not found in the user's data information, the normal sending process is followed; if the user-specified configuration is found in the user's data information, the header of the serialized data is obtained, the tracking status bit is identified, and the current process position is recorded in the process position information recording point.
[0040] During the data serialization process, the added header is skipped first, the data is serialized, and written into the serialization buffer.
[0041] The RTPS protocol stack sends user data to the network, and sends it in segments or as a whole according to the user's configuration. During this process, the current tracking status is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point.
[0042] While sending, the RTPS protocol stack writes the user data to the writer's history_cache and also determines the current tracking state. If the current tracking state is set, the current process position is recorded in the process position information recording point.
[0043] At this point, the user data sending operation has been completed.
[0044] (3) The SUB receives the RTPS message from the network, receives and parses the user data, and obtains the sub-message of the message; parses the sub-message, obtains the serialized header part, sets the current tracking state, and records the current process position in the process position information recording point; the RTPS protocol stack sample data is saved in the reader's sample space; for the sample data that can be notified to the user, the sample data is taken out from the reader's sample space and put into the reader's history cache history_cache (rhc);
[0045] When SUB receives an RTPS data packet on the network, the RTPS protocol stack parses and strips off the RTPS header of the packet, and parses the sub-message type of the RTPS packet according to the RTPS sub-message structure definition. When the sub-message type is the data type data, the sub-message header of the RTPS packet is stripped, and the serialized header part is obtained in the data payload of the sub-message of the RTPS packet. If the tracking status of the header part is not set, normal receiving processing is performed; if the tracking status of the header part is set, the current tracking status is set, and the current process position is recorded in the process position information recording point.
[0046] If it is a fragmented message, the RTPS protocol stack stores the fragmented message in the fragment space. During this process, the current tracking state is determined. If the current tracking state is set, the current process position is recorded in the process position information recording point. If the complete sample data is received, the RTPS protocol stack stores the sample in the sample space. During this process, the current tracking state is determined. If the current tracking state is set, the current process position is recorded in the process position information recording point.
[0047] If the received sample data meets the conditions for passing to the user, the RTPS protocol stack removes the sample data from the sample space and writes it to the reader's history_cache. During this process, the current tracking status is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point.
[0048] If the upper limit is reached in the history_cache of the reader, the sample data is deleted and the current tracking status is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point.
[0049] (4) Then the message processing result is returned to the PUB side. After receiving the processing result from the SUB side, the PUB side searches for the relevant data from the writer's history_cache and deletes the data from the writer's history_cache. At the same time, the tracking status of the serialization header is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point.
[0050] (5) The user obtains the data in the reader's history cache history_cache through the SUB-side RTPS interface or listener. The SUB-side deserializes the data. During the serialization process, the current tracking status is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point, and then the data is passed to the user.
[0051] So far, the entire user data processing flow has been basically covered. If you need to record other details, you can also determine whether you need to record the location information based on the tracking status of the header part in the serialized data.
[0052] 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 accurately tracking a specified RTPS message in DDS communication, characterized in that: Includes steps: (1) Define a specific message parsing structure and provide a configuration interface for users to specify the attributes of specific RTPS messages that need to be tracked; Define a specific message parsing structure, including the specific character information in the message that needs to be tracked, the length of the specific character information that needs to be tracked, the starting position of the specific character in the data that needs to be tracked, the recording point of the current process location information tracked, and the status flag of whether to track; The user sets the attributes of the RTPS message to be tracked through the provided configuration interface before sending the message. The RTPS protocol stores the character information and length configured by the user in the cache. (2) The PUB receives the user's data sending request and serializes the user data; a header is added to the serialization structure to indicate whether this message needs to be tracked; the user calls the RTPS data sending interface and searches the user data for the attribute value of the RTPS message configured by the user; Then, the header of the serialized data is obtained, the tracking status bit is identified, and the current process position is recorded in the process position information recording point; then, the RTPS protocol stack sends the user data to the network and writes the user data to the writer's history_cache; (3) The SUB receives the RTPS message from the network, receives and parses the user data, and obtains the sub-message of the message; Parse the sub-message, obtain the serialized header part, set the current tracking state, and record the current process position in the process position information recording point; the RTPS protocol stack saves the sample data in the reader's sample space; for the sample data that can be notified to the user, take the sample data from the reader's sample space and put it into the reader's history cache history_cache; (4) Return the message processing result to the PUB side. After receiving the processing result from the SUB side, the PUB side searches for the relevant data from the writer's history_cache and deletes the data from the writer's history_cache. At the same time, it determines the tracking status of the serialization header. If the current tracking status is set, the current process position is recorded in the process position information recording point. (5) The user obtains the data in the reader's history cache history_cache through the SUB end. The SUB end deserializes the data. During the deserialization process, the current tracking status is determined. If the current tracking status is set, the current process position is recorded in the process position information recording point, and then the deserialized data is passed to the user.
2. The method for accurately tracking a specified RTPS message in DDS communication according to claim 1, characterized in that: In step (2), when the user calls the RTPS data sending interface, the attribute value of the RTPS message configured by the user is searched in the user data. If the user-specified configuration is not found in the user's data information, the normal sending process is followed; If the user-specified configuration is found in the user's data information, the header of the serialized data is obtained, the tracking status bit is identified, and the current process position is recorded in the process position information recording point.
3. The method for accurately tracking a specified RTPS message in DDS communication according to claim 1, characterized in that: In step (2), during the data serialization process, the added header is skipped first, the data is serialized, and written into the serialization buffer.
4. The method for accurately tracking a specified RTPS message in DDS communication according to claim 1, characterized in that: In step (2), the RTPS protocol stack sends the user data to the network and determines the current tracking state. If the current tracking state is set, the current process position is recorded in the process position information recording point.
5. The method for accurately tracking a specified RTPS message in DDS communication according to claim 1, characterized in that: In step (2), the RTPS protocol stack writes the user data into the writer's history_cache and determines the current tracking state. If the current tracking state is set, the current process position is recorded in the process position information recording point.
6. The method for accurately tracking a specified RTPS message in DDS communication according to claim 1, characterized in that: In step (3), the serialized header part is obtained. If the tracking status of the header part is not set, normal receiving processing is performed; if the tracking status of the header part is set, the current tracking status is set and the current process position is recorded in the process position information recording point.
7. The method for accurately tracking a specified RTPS message in DDS communication according to claim 1, characterized in that: In step (3), the RTPS protocol stack takes the sample data from the reader's sample space and puts it into the reader's history cache history_cache. At the same time, it determines the current tracking status. If the current tracking status is set, the current process position is recorded in the process position information recording point.
Citation Information
Patent Citations
Message server based on XMPP and signaling tracking method thereof
CN104468333A
DDS message processing method and device, vehicle and storage medium
CN116132514A