DDS message capturing method and system

Abstract

The invention discloses a DDS (Direct Digital Synthesizer) message capturing method and system. The method comprises the following steps: respectively creating an independent sandbox environment for each user; after each user defines and registers a callback function through an API (Application Program Interface) in the created sandbox environment, distributing a priority for the self-defined callback function; wherein the step of defining the callback function comprises the step of defining input content required by the callback function; capturing messages from a preset network interface according to the distributed priority sequence and a preset message filtering rule, analyzing the captured message information, and extracting required data from the analyzed message information according to the input content required by the defined callback function; and transmitting the extracted data to each callback function defined by the user through a callback mechanism. According to the invention, the problem that the current DDS message capture data output lacks real-time performance and does not support multi-user capture can be solved.

Description

Technical Field

[0001] The invention belongs to the technical field of communications, and in particular relates to a DDS message capture method and system. Background Art

[0002] As an efficient distributed communication middleware, DDS plays a key role in real-time systems, especially in aerospace, military and industrial automation. However, most tools (such as Wireshark) only provide user-oriented interfaces, usually saving the parsed data locally before outputting it, or passing the parsed results in JSON array format. Although this method is suitable for static analysis, it lacks real-time performance and is difficult to meet the strict requirements of distributed real-time systems for low latency.

[0003] The development of multi-user support functions in the current DDS environment is mostly focused on simulation systems, and has not been fully explored in message capture systems. However, different developers may have different usage requirements for captured messages. For example, some developers need to capture message data for display, while others need to store or further analyze it. Summary of the invention

[0004] The purpose of the present invention is to overcome the deficiencies in the prior art and provide a DDS message capture method and system to solve the problem that the current DDS message capture data output lacks real-time performance and does not support multi-user capture.

[0005] In order to solve the above technical problems, the present invention is implemented by adopting the following technical solutions:

[0006] In a first aspect, the present invention provides a message capture method and system, comprising:

[0007] S1: Create an independent sandbox environment for each user;

[0008] S2: After each user defines and registers a callback function through an API interface in the sandbox environment created in step S1, a priority is assigned to the custom callback function; wherein defining the callback function includes defining the input content required for the callback function;

[0009] S3: according to the priority order assigned in step S2 and the preset message filtering rules, capture messages from the preset network interface, parse the captured message information, and extract required data from the parsed message information according to the input content required by the callback function defined in step S2;

[0010] S4: The data extracted in step S3 is transmitted to the callback function defined in step S2 of each user through the callback mechanism.

[0011] In the aforementioned message capture method, step S2 further includes setting a network interface and filtering rules using an API interface provided by the PCAP library;

[0012] Step S2 also includes defining a static function pointer in an underlying library provided by Wireshark for data packet capture and analysis, and binding the defined static function pointer to a corresponding callback function;

[0013] The static function pointer is used to store the address of the user-defined callback function;

[0014] Defining the callback function in step S2 also includes defining the data processing logic of the callback function.

[0015] In the aforementioned message capture method, the message information captured by parsing in step S3 includes:

[0016] Use the pre-processed Wireshark to parse the captured messages layer by layer according to the link layer, network layer, transport layer and application layer according to the pre-processed RTPS2 protocol specification;

[0017] The preprocessing of Wireshark includes cutting out functional codes irrelevant to parsing in the Wireshark source code, wherein the functional codes irrelevant to parsing include functional codes related to data storage and data display;

[0018] The preprocessing of the RTPS2 protocol specification includes: checking whether the RTPS2 protocol specification supports the fields and message types in the captured message according to the preset filtering rules; and adding parsing logic in the RTPS2 protocol specification for unsupported fields and message types.

[0019] In the above-mentioned message capture method, step S4 comprises:

[0020] S41: Call the callback function using the defined static function pointer;

[0021] S42: Processing the data extracted in step S3 according to the data processing logic of the callback function in step S41;

[0022] S43: Transmit the output result of the data processing in step S42 to the callback function defined in step S2 of each user.

[0023] The aforementioned DDS message capture method further includes:

[0024] S5: After the data transmission in step S4 is completed, the sandbox environment created in step S1 is destroyed to release system resources.

[0025] In a second aspect, the present invention provides a DDS message capture system, which is used in the DDS message capture method described in the first aspect, and the DDS message capture system includes a sandbox management module, a user-defined callback module, a capture and analysis module, and a data transmission module;

[0026] The sandbox management module is used to: create an independent sandbox environment for each user;

[0027] The user-defined callback module is used for: each user to customize the registration of callback functions through the API interface in the sandbox environment created by the sandbox management module and assign a priority to the customized callback function; wherein, defining the callback function includes defining the input content required for the callback function;

[0028] The capture and analysis module is used to: capture messages from a preset network interface according to the priority order assigned by the user-defined callback module and the preset message filtering rules, analyze the captured message information, and extract required data from the analyzed message information according to the input content required by the callback function defined by the user-defined callback module;

[0029] The data transfer module is used to transmit the data extracted by the capture and analysis module to the callback function defined by each user in the user-defined callback module through a callback mechanism.

[0030] The aforementioned DDS message capture system, the sandbox management module includes a virtualization unit and an environment management unit;

[0031] The virtualization unit is used to: create an independent sandbox environment for each user, isolate access paths between users, and match system resources allocated by the environment management unit to the corresponding sandbox environment;

[0032] The environment management unit is used to: manage the sandbox environment created by the virtualization unit;

[0033] Managing the sandbox environment includes initializing, allocating and destroying the sandbox environment created by the virtualization unit according to user usage;

[0034] Among them, allocation processing refers to adjusting the allocation of system resources required by the sandbox environment according to user usage.

[0035] The aforementioned DDS message capture system, the user-defined callback module includes a registration callback function unit, a callback queue management unit and a task scheduling unit;

[0036] The callback function registration unit is used to: customize and register the callback function through the API interface, and assign a priority to the customized callback function; wherein, defining the callback function includes defining the input content required for the callback function;

[0037] The callback queue management unit is used to: sort the registered callback functions according to the assigned priorities;

[0038] The task scheduling unit is used to allocate system resources required by the callback function in each sandbox environment according to the priority order.

[0039] The aforementioned DDS message capture system, the capture and analysis module includes a message capture unit and a message analysis unit;

[0040] The message capture unit is used to: capture the target DDS message from the preset network interface through the PCAP library according to the assigned priority order and the preset message filtering rules;

[0041] The message parsing unit is used to parse the captured message layer by layer according to the link layer, network layer, transport layer and application layer in the underlying library provided by Wireshark for data packet capture and analysis, and extract the required data from the parsed message information according to the input content required by the callback function.

[0042] The aforementioned DDS message capture system, the data transmission module includes a data receiving unit and a log recording and monitoring unit;

[0043] The data receiving unit is used to: transmit the extracted data to each user-defined callback function through a callback mechanism and then receive the transmitted data;

[0044] The logging and monitoring unit is used to implement logging and monitoring operations on the data transmission process through a logging library and a monitoring tool.

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

[0046] The present invention provides a DDS message capture method and system, which creates an independent sandbox environment for each user and allows the user to customize and register a callback function, so that each user can independently capture messages and return parsed message information through a callback mechanism, thereby solving the problem that the current DDS message capture data output lacks real-time performance and does not support multi-user capture.

[0047] The present invention provides a DDS message capture method and system, which takes multi-user customized callback and layer-by-layer in-depth analysis as the core, realizes user data isolation through a sandbox environment, and effectively guarantees data security and task independence. At the same time, the DDS message is analyzed layer by layer, the user-defined callback function is called in real time, and the analysis result is directly passed to the developer interface to meet the personalized processing and analysis needs of different users.

[0048] The present invention directly provides a developer interface to transmit the parsing result to the callback function in real time, avoiding the delay of intermediate storage and better meeting the real-time requirements;

[0049] The present invention introduces a sandbox environment and provides each user with an independent custom callback function, which not only ensures the isolation and security of user data, but also provides developers with a flexible and efficient interface to meet the needs of diverse application scenarios.

[0050] The present invention adopts a method of directly capturing and parsing packets from a network interface without entering the DDS system for subscription. It is a non-invasive message capture method. The message capture method of the present invention is separated from the publish-subscribe architecture of DDS, and directly obtains DDS messages from the bottom layer, avoiding changes to the existing system. Therefore, the message capture method of the present invention is suitable for deployed distributed real-time systems, can quickly access and monitor data traffic, and save development and maintenance costs.

[0051] The present invention defines a static function pointer in the pre-processed Wireshark underlying library to store the user-defined callback function address. The user can encapsulate his own processing logic (such as storage and display) into the customized callback function. In order to implement the callback of the user-defined callback function, the DDS message capture method of the present invention provides the user with an API interface for registration. The user registers the customized callback function into the system by calling the API interface and binds the defined static function pointer. During message parsing, each time after the DDS message parsing is completed, the registered callback function is automatically called according to the required input content of each callback function, and the parsing result is passed to the user. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a flowchart of a DDS message capture method according to Embodiment 1 of the present invention;

[0053] Figure 2 It is a structural schematic diagram of a DDS message capture system according to Embodiment 2 of the present invention;

[0054] Figure 3 It is a schematic diagram of a visualization interface of message parsing results of a DDS message capture system according to Embodiment 2 of the present invention. DETAILED DESCRIPTION

[0055] The technical solution of the present invention is described in detail below through the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present application and the specific features in the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations on the technical solution of the present application. In the absence of conflict, the embodiments of the present application and the technical features in the embodiments can be combined with each other.

[0056] The term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0057] Embodiment 1:

[0058] Figure 1 This is a flow chart of a DDS message capture method in the first embodiment of the present invention. This flow chart only shows the logical sequence of the method described in this embodiment. In other possible embodiments of the present invention, different methods may be used without conflict. Figure 1 The steps shown or described are accomplished in the order shown.

[0059] A DDS message capture method of this embodiment, such as Figure 1 As shown, including:

[0060] S1: Create an independent sandbox environment for each user;

[0061] The Sandbox Environment is an isolated testing environment that allows developers to test new code or software features without affecting the stability of the main system. This environment is like a sandbox, where all operations can be reset at any time, facilitating multiple experiments and tests.

[0062] S2: After each user defines and registers a callback function through an API interface in the sandbox environment created in step S1, a priority is assigned to the custom callback function; wherein defining the callback function includes defining the input content required for the callback function;

[0063] S3: according to the priority order assigned in step S2 and the preset message filtering rules, capture messages from the preset network interface, parse the captured message information, and extract required data from the parsed message information according to the input content required by the callback function defined in step S2;

[0064] S4: The data extracted in step S3 is transmitted to the callback function defined in step S2 of each user through the callback mechanism;

[0065] After step S4 is completed, it also includes:

[0066] S5: After the data transmission in step S4 is completed, the sandbox environment created in step S1 is destroyed to release system resources.

[0067] In specific implementation,

[0068] Step S2 also includes setting the network interface and filtering rules using the API interface provided by the PCAP library;

[0069] In this embodiment, the network interface is a network card, which is a physical connection device between a computer and a network. The network card is responsible for converting the computer's digital signal into an analog signal required for network transmission (or vice versa) and processing the underlying details in network communication;

[0070] Filter rules are conditions or criteria used to determine which messages should be captured. These rules are usually based on certain features of the message, such as source address, destination address, port number, protocol type, etc. By applying filter rules, you can capture only the messages of interest and ignore other irrelevant messages, thus saving storage space and processing time.

[0071] Step S2 also includes defining a static function pointer in an underlying library provided by Wireshark for data packet capture and analysis, and binding the defined static function pointer to a corresponding callback function;

[0072] The static function pointer is used to store the address of the user-defined callback function;

[0073] In this embodiment, a static function pointer wsRTPS2Callback is defined, whose type is RTPS2Callback and is used to reference a user-defined callback function.

[0074] Defining the callback function in step S2 also includes defining the data processing logic of the callback function. The data processing logic of the callback function includes recording, analyzing or forwarding.

[0075] After capturing the target DDS message, you need to parse the captured data to identify the DDS message. This involves inspecting the contents of the target DDS message to find specific fields or patterns related to the input content required by the callback function.

[0076] In step S3, packets are captured from a preset network interface. In this embodiment, packets are captured from a designated network card, which means that packets are captured only from network traffic received by the network card.

[0077] The message information parsed and captured in step S3 includes:

[0078] Use the pre-processed Wireshark to parse the captured messages layer by layer according to the link layer, network layer, transport layer and application layer according to the pre-processed RTPS2 protocol specification;

[0079] The preprocessing of Wireshark includes cutting out functional codes irrelevant to parsing in the Wireshark source code, wherein the functional codes irrelevant to parsing include functional codes related to data storage and data display;

[0080] The preprocessing of the RTPS2 protocol specification includes: checking whether the RTPS2 protocol specification supports the fields and message types in the captured message according to the preset filtering rules; and adding parsing logic in the RTPS2 protocol specification for unsupported fields and message types.

[0081] In the parsing logic of the standard RTPS2 protocol specification, the default encapsulation format of serialized_data is ENCAPSULATION_CDR_LE (little-endian serialization encapsulation), but in actual scenarios, different manufacturers may use other encapsulation formats, such as CDR (Common Data Representation) + JSON hybrid encapsulation, which RTPS2 does not natively support.

[0082] Therefore, in order to better adapt to the application requirements of identifying other encapsulation formats other than the default encapsulation format in actual scenarios, the present invention expands the parsing logic of the RTPS2 protocol specification. Taking the identification of the mixed encapsulation of CDR (Common Data Representation) + JSON as an example, the identification of the RTPS2 protocol specification parsing logic preprocessed by the present invention consists of two parts: the first part is used to identify the basic encapsulation type of CDR, and the second part is the extension identification, indicating the starting position of the nested JSON data. When the CDR+JSON identification is detected, segmented parsing is adopted. The first segment parses the CDR data and extracts the main field of the serialized data; the second segment enters the JSON data segment according to the offset extracted by the CDR to parse the nested JSON data.

[0083] In this embodiment, the captured message is parsed at the link layer to extract the MAC address, frame type and other link layer header information. The MAC address includes a source MAC address and a destination MAC address. The source MAC address represents the physical address of the sending device and is used to identify the source of the data. The MAC address is fixed in the network device (such as a network card) and is globally unique. The destination MAC address represents the physical address of the receiving device and is used to identify the destination of the data. During data transmission, the data link layer will forward the frame to the correct receiving device based on the destination MAC address. The frame type indicates the type or length of the data in the frame. For Ethernet frames, the EtherType field is typically used to indicate the type of upper layer protocol (such as IPv4, IPv6, ARP, etc.). In addition, the link layer header information may also include other control fields, such as:

[0084] Preamble: Used to synchronize the receiving adapter and detect the start of the data stream.

[0085] Start of Frame Delimiter (SFD): marks the beginning of a MAC frame.

[0086] Cyclic Redundancy Check (CRC): Used to detect whether errors are introduced into the frame and ensure data integrity.

[0087] It should be noted that different data link layer protocols may have different header information formats and contents.

[0088] MAC address and frame type are important components of the link layer header information. Together with other control fields, they ensure the correct transmission and processing of data in the data link layer.

[0089] For example, for Ethernet links, extract the source MAC address, destination MAC address, and Ethernet type field; after the link layer parsing is completed, enter the network layer to extract the IP header information, including the source IP address, destination IP address, TTL (time to live), protocol type and other fields. After the network layer, enter the transport layer, extract the detailed information of the UDP message header, parse the source port, destination port, length and checksum fields; extract the serialized data in the RTPS message by parsing the nested fields in the RTPS protocol, such as data encapsulation (encapsulation), metadata fields (metadata), etc. At this point, the deep parsing is completed, and the data is transferred to the data transfer module through the callback function, such as Figure 3 The figure shows the message parsing result of passing it into the user-defined callback function.

[0090] RTPS (Real-time Publish-Subscribe Protocol) is a protocol based on the publish / subscribe model for real-time data distribution. It is a standard protocol defined by the OMG (Object Management Group) organization to support data distribution and communication in distributed real-time systems.

[0091] RTPS messages are the structure and content used in the RTPS protocol to transfer data between publishers and subscribers, while serialized data is the part of these data contents that has been converted into a specific format for network transmission or storage.

[0092] In traditional distributed real-time systems, the subscription mechanism of DDS relies on the data publisher in the application. Subscribers need to explicitly define the message topic and QoS (quality of service) policy in the DDS system and obtain the message data through interaction with the publisher. This approach requires adjustment or expansion of the publishing logic of the existing DDS system, intrusion into the implementation of the existing system, resulting in high maintenance costs, and occupies a large amount of network resources in high-frequency data transmission scenarios. In particular, when the QoS protocol needs to be maintained between the publisher and the subscriber, the problem of network resource occupation is particularly prominent.

[0093] The present invention adopts a method of directly capturing and parsing packets from a network interface, without entering the DDS system for subscription. It is a non-invasive message capture method. The message capture method of the present invention is separated from the publish-subscribe architecture of DDS, directly obtains DDS messages from the bottom layer, avoids changes to the existing system, and does not rely on the publish-subscribe logic of the DDS system itself. This dependence refers to the traditional way of subscribing, which requires the publisher to change the configuration and code, and has a dependency on the DDS system. The message capture method of the present invention does not need to adjust the existing DDS system and can be used in any DDS system environment. Therefore, it is suitable for deployed distributed real-time systems, can quickly access and monitor data traffic, and save development and maintenance costs.

[0094] In this embodiment, the message parsing ideas are as follows:

[0095] First, the core architecture of Wireshark was studied, focusing on its protocol parsing module (Epan). By combing the source code structure of Wireshark, we focused on packet-rtps.c (RTPS protocol parsing related), epan_dissect.c (managing the creation and release of parsing context), and wtap.h (managing timestamps and metadata).

[0096] In order to meet the high-efficiency requirements of parsing, the Wireshark source code was trimmed, and functional modules such as message capture, data storage, and UI were removed. Only the relevant logic of parsing was retained, and the compilation options were modified, and the underlying library of Wireshark was re-customized to focus on parsing tasks. On this basis, in order to meet the needs of deep parsing of the RTPS2 protocol in the captured messages, the serialized data in RTPS2 is supported, and detailed parsing is performed for specific message types (such as CDR and JSON format payload data). By decoding the CDR data structure, the key fields are extracted, and structured parsing of JSON format messages is implemented.

[0097] In order to introduce the callback mechanism, a static function pointer is defined in packet-rtps2.c to reference the user-defined callback function. The specific parsing process is as follows: initialize the parsing context of the message in epan_dissect_new, pass the captured message to the parsing engine through epan_dissect_run and wtap_pseudo_header, and after the parsing is completed, combine CDR and JSON data to expand the parsing capability, and further extract and format the parsing results. After that, pass the parsing results to the user-defined callback function through the callback mechanism, and finally release the resources and memory of the parsing context through epan_dissect_free.

[0098] Step S4 includes: S41: calling the callback function using the defined static function pointer;

[0099] S42: Processing the data extracted in step S3 according to the data processing logic of the callback function in step S41;

[0100] S43: Transmit the output result of the data processing in step S42 to the callback function defined in step S2 of each user.

[0101] Embodiment 2:

[0102] Based on the same inventive concept as in Example 1, Figure 2 As shown, this embodiment introduces a DDS message capture system, which is used to implement the DDS message capture method described in Example 1. The DDS message capture system includes a sandbox management module, a user-defined callback module, a capture and analysis module, and a data transmission module;

[0103] The sandbox management module is used to: create an independent sandbox environment for each user;

[0104] The user-defined callback module is used for: each user to customize the registration of callback functions through the API interface in the sandbox environment created by the sandbox management module and assign a priority to the customized callback function; wherein, defining the callback function includes defining the input content required for the callback function;

[0105] The capture and analysis module is used to: capture messages from a preset network interface according to the priority order assigned by the user-defined callback module and the preset message filtering rules, analyze the captured message information, and extract required data from the analyzed message information according to the required content of the callback function defined by the user-defined callback module;

[0106] The data transfer module is used to transmit the data extracted by the capture and analysis module to the callback function defined by each user in the user-defined callback module through a callback mechanism.

[0107] When this embodiment is implemented,

[0108] The sandbox management module includes a virtualization unit and an environment management unit;

[0109] The virtualization unit is used to: create an independent sandbox environment for each user, isolate access paths between users, and match system resources allocated by the environment management unit to the corresponding sandbox environment;

[0110] In this embodiment, Microsoft Hyper-V is used to create a sandbox environment under Windows, and Docker container technology or KVM is used to create it under Linux. Hyper-V is a native virtualization solution for Windows operating system. Through Hyper-V, each user can be provided with an independent virtual machine instance or an isolated container environment; in a lightweight isolation scenario, Docker provides an efficient container virtualization method, and implements resource isolation and management through Docker's namespace and control group (cgroup); KVM, as a native virtualization solution for Linux, can provide each user with a complete virtualization instance to ensure data isolation and independence of resource allocation.

[0111] The environment management unit is used to: manage the sandbox environment created by the virtualization unit;

[0112] Managing the sandbox environment includes initializing, allocating and destroying the sandbox environment created by the virtualization unit according to user usage;

[0113] Among them, allocation processing refers to adjusting the allocation of system resources required by the sandbox environment according to user usage.

[0114] The environment management module is used to reasonably allocate and recycle system resources, manage the resource allocation ratio of each user's sandbox environment, and improve the resource utilization of the system.

[0115] In this embodiment, the environment management module provides API function interfaces such as env_init(), env_allocate(), and env_destroy().

[0116] The env_init() interface is typically used to initialize an environment or context so that subsequent operations or computations can proceed in a known and expected state.

[0117] The env_allocate() interface is used to allocate resources in a certain environment or context. These resources can be memory, file handles, network connections, database connections, threads, or any other limited system resources. The env_allocate() interface provides a standardized way to allocate and manage resources, ensuring efficient use and correct management of system resources.

[0118] The env_destroy() interface is used to destroy or clean up the environment or resources created or initialized by a previous interface (such as env_allocate()). In programming and software development, the correct release of resources and cleanup of the environment are crucial to avoid problems such as memory leaks, file handle leaks, and resource contention. The env_destroy() interface provides a standardized way to destroy and clean up the environment or resources created previously, ensuring system stability and efficient use of resources.

[0119] The user-defined callback module includes a registration callback function unit, a callback queue management unit and a task scheduling unit;

[0120] The callback function registration unit is used to: customize and register the callback function through the API interface, and assign a priority to the customized callback function; wherein, defining the callback function includes defining the input content required for the callback function;

[0121] The registration callback function unit enables the system to call the corresponding callback function according to user needs.

[0122] In this embodiment, the registration callback function unit provides API interfaces such as register_callback(), unregister_callback(), and set_callback_priority().

[0123] The register_callback() interface is used to register a callback function in programming so that the function can be automatically called when a specific event or condition occurs.

[0124] The unregister_callback() interface is often used to remove previously registered callback functions in programming. In event-driven programming or callback mechanisms, a callback function is registered at a certain moment to be executed when a specific event occurs. However, in some cases, this callback needs to be canceled, such as when the object is destroyed or the event is no longer needed to be processed. The unregister_callback() interface is an important tool for managing callbacks and events, which allows the program to safely remove old callbacks when it is no longer necessary to process a specific event, thereby avoiding potential errors and waste of resources.

[0125] The set_callback_priority() interface is usually used to set the priority of callback functions. In an event-driven system or framework, callback functions are used to respond to specific events, and the execution order of callback functions may affect the behavior and performance of the system. Therefore, it is particularly important to provide the function of setting callback priority.

[0126] The set_callback_priority() interface provides a flexible way to manage the execution order of callback functions, which helps to build more complex and efficient event processing systems.

[0127] The callback queue management unit is used to sort the registered callback functions according to the assigned priorities so as to give priority to processing high priority tasks when resources are limited.

[0128] In this embodiment, the priority levels are divided into 1-5 levels. Users can set the priority of each callback function by themselves. The larger the number, the higher the priority. The higher the priority callback function, the earlier it is processed. When the system load is high and resources are limited, the real-time and integrity of high-priority task data are guaranteed.

[0129] The task scheduling unit is used to allocate system resources required by the callback function in each sandbox environment according to the priority order.

[0130] The task scheduling unit is used to allocate the required system resources for each callback function of the same user within a single sandbox environment. The environment management unit of the sandbox management module and the task scheduling unit of the user-defined callback module are combined to realize efficient dynamic allocation of system resources. When the execution task of the highest priority callback function cannot obtain sufficient system resources, the task scheduling unit of the user-defined callback module sends a resource increment request to the environment management unit of the sandbox management module. The environment management unit increases the resource allocation to the sandbox environment for the execution of the highest priority callback function in the sandbox environment. When the execution is completed, the system resources are returned, the system resources are increased, or the sandbox environment is destroyed according to the execution of the next priority callback function in the sandbox environment.

[0131] The capture and analysis module includes a message capture unit and a message analysis unit;

[0132] The message capture unit is used to: capture the target DDS message from the preset network interface through the PCAP library according to the assigned priority order and the preset message filtering rules;

[0133] The PCAP library is a powerful tool for capturing data packets at the link layer. DDS is a middleware protocol for real-time data distribution, but DDS messages usually run at the application layer. This means that using the PCAP (Packet Capture) library to capture qualified DDS (Data Distribution Service) messages from a specified network interface requires cross-layer identification of DDS message-specific application layer features from the link layer to capture the target DDS message. This includes the following steps:

[0134] Install the PCAP library, determine the characteristics of DDS messages, and write a PCAP capture program;

[0135] The specific description is as follows:

[0136] Installing the PCAP library involves making sure the appropriate PCAP library and header files are installed in your development environment. On Linux, you can use the equivalent library from libpcap or WinPcap (Windows platform).

[0137] Determine the characteristics of DDS messages including: DDS messages are usually identified by a specific topic, type, or QoS (Quality of Service) setting. Understand the topic name, data structure, and QoS settings used by a specific DDS application. However, these application layer characteristics cannot be seen directly when crawling at the link layer. Therefore, it is necessary to analyze the link layer IP address, port number, specific data pattern, or application layer protocol identifier (if DDS uses a custom transport protocol).

[0138] Writing a PCAP capture program involves using the API provided by the PCAP library to open the network interface, set filters, capture packets, and process the captured data. Filters can be set based on IP addresses, port numbers, or other features.

[0139] The message parsing unit is used to parse the captured message layer by layer according to the link layer, network layer, transport layer and application layer in the underlying library for data packet capture and analysis provided by Wireshark, and extract the required data from the parsed message information according to the input content required by the callback function. After parsing layer by layer, the parsed message information includes serialized data, timestamp, source and destination, etc.

[0140] In actual use, the DDS message capture system of the present invention can be equipped with a human-computer interaction interface to facilitate viewing the message capture result interface, such as Figure 3As shown in the diagram of the visual interface of the message parsing results of the DDS message capture system, the message parsing list on the left side of the figure shows the core field information parsed based on the callback function registered by the user, including the capture time, message name, unique identifier, etc. The parsing results can be dynamically adjusted according to user needs to meet the personalized needs of different scenarios; the detailed field display module on the right side shows the protocol field information parsed after the callback function extension, and supports further decoding of undefined fields or user-specific fields of the RTPS protocol; the original message data at the bottom is used to compare and verify the accuracy of the callback parsing results.

[0141] The data transfer module includes a data receiving unit and a log recording and monitoring unit;

[0142] The data receiving unit is used to transmit the extracted data to each user-defined callback function through a callback mechanism and then receive the transmitted data;

[0143] The logging and monitoring unit is used to implement logging and monitoring operations on the data transmission process through a logging library and a monitoring tool.

[0144] In this embodiment, the system is logged and monitored based on the log library Logback and the monitoring tool Zabbix. Logback is a high-performance logging framework based on Java, and Zabbix is ​​an open source enterprise-level monitoring tool that is used to monitor infrastructure such as servers, network devices, and cloud services, and provides functions such as data collection, alarms, and visual analysis.

[0145] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0146] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0147] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0148] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0149] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A DDS message capture method, characterized in that: include: S1: Create an independent sandbox environment for each user; S2: After each user defines and registers a callback function through an API interface in the sandbox environment created in step S1, a priority is assigned to the custom callback function; wherein defining the callback function includes defining the input content required for the callback function; S3: According to the priority order assigned in step S2 and the preset message filtering rules, capture messages from the preset network interface, parse the captured message information, and extract required data from the parsed message information according to the input content required by the callback function defined in step S2; S4: The data extracted in step S3 is transmitted to the callback function defined in step S2 of each user through the callback mechanism.

2. The DDS message capture method according to claim 1, characterized in that: Step S2 also includes setting the network interface and filtering rules using the API interface provided by the PCAP library; Step S2 also includes defining a static function pointer in an underlying library provided by Wireshark for data packet capture and analysis, and binding the defined static function pointer to a corresponding callback function; The static function pointer is used to store the address of the user-defined callback function; Defining the callback function in step S2 also includes defining the data processing logic of the callback function.

3. The DDS message capture method according to claim 1, characterized in that: The message information parsed and captured in step S3 includes: Use the pre-processed Wireshark to parse the captured messages layer by layer according to the link layer, network layer, transport layer and application layer according to the pre-processed RTPS2 protocol specification; The preprocessing of Wireshark includes cutting out functional codes irrelevant to parsing in the Wireshark source code, wherein the functional codes irrelevant to parsing include functional codes related to data storage and data display; The preprocessing of the RTPS2 protocol specification includes: checking whether the RTPS2 protocol specification supports the fields and message types in the captured message according to the preset filtering rules; and adding parsing logic in the RTPS2 protocol specification for unsupported fields and message types.

4. The DDS message capture method according to claim 3, characterized in that: Step S4 includes: S41: calling the callback function using the defined static function pointer; S42: Processing the data extracted in step S3 according to the data processing logic of the callback function in step S41; S43: Transmit the output result of the data processing in step S42 to the callback function defined in step S2 of each user.

5. The DDS message capture method according to claim 1, characterized in that: Also includes: S5: After the data transmission in step S4 is completed, the sandbox environment created in step S1 is destroyed to release system resources.

6. A DDS message capture system, characterized in that: Used to implement the DDS message capture method according to any one of claims 1 to 5, the DDS message capture system includes a sandbox management module, a user-defined callback module, a capture and parsing module, and a data transmission module; The sandbox management module is used to: create an independent sandbox environment for each user; The user-defined callback module is used for: each user to customize the registration of callback functions through the API interface in the sandbox environment created by the sandbox management module and assign a priority to the customized callback function; wherein, defining the callback function includes defining the input content required for the callback function; The capture and analysis module is used to: capture messages from a preset network interface according to the priority order assigned by the user-defined callback module and the preset message filtering rules, analyze the captured message information, and extract required data from the analyzed message information according to the input content required by the callback function defined by the user-defined callback module; The data transfer module is used to transmit the data extracted by the capture and analysis module to the callback function defined by each user in the user-defined callback module through a callback mechanism.

7. The DDS message capture system according to claim 6, characterized in that: The sandbox management module includes a virtualization unit and an environment management unit; The virtualization unit is used to: create an independent sandbox environment for each user, isolate access paths between users, and match system resources allocated by the environment management unit to the corresponding sandbox environment; The environment management unit is used to: manage the sandbox environment created by the virtualization unit; Managing the sandbox environment includes initializing, allocating and destroying the sandbox environment created by the virtualization unit according to user usage; Among them, allocation processing refers to adjusting the allocation of system resources required by the sandbox environment according to user usage.

8. The DDS message capture system according to claim 6, characterized in that: The user-defined callback module includes a registration callback function unit, a callback queue management unit and a task scheduling unit; The callback function registration unit is used to: customize and register the callback function through the API interface, and assign a priority to the customized callback function; wherein, defining the callback function includes defining the input content required for the callback function; The callback queue management unit is used to: sort the registered callback functions according to the assigned priorities; The task scheduling unit is used to allocate system resources required by the callback function in each sandbox environment according to the priority order.

9. The DDS message capture system according to claim 6, characterized in that: The capture and analysis module includes a message capture unit and a message analysis unit; The message capture unit is used to: capture the target DDS message from the preset network interface through the PCAP library according to the assigned priority order and the preset message filtering rules; The message parsing unit is used to parse the captured message layer by layer according to the link layer, network layer, transport layer and application layer in the underlying library provided by Wireshark for data packet capture and analysis, and extract the required data from the parsed message information according to the input content required by the callback function.

10. The DDS message capture system according to claim 6, characterized in that: The data transfer module includes a data receiving unit and a log recording and monitoring unit; The data receiving unit is used to: transmit the extracted data to each user-defined callback function through a callback mechanism and then receive the transmitted data; The logging and monitoring unit is used to implement logging and monitoring operations on the data transmission process through a logging library and a monitoring tool.

Images