Data communication method, apparatus, terminal and storage medium based on DDS

Abstract

This application provides a DDS-based data communication method, apparatus, terminal, and storage medium, belonging to the field of communication technology. The method includes: acquiring a Topic message published by a first application on a first terminal; determining the transmission protocol supported by a second application on a second terminal, wherein the second application is an application that subscribes to the Topic message; and, if the transmission protocol supported by the second application includes the QUIC transmission protocol, sending the Topic message to the second application based on the QUIC transmission protocol through a first DDS middleware of the first terminal and a second DDS middleware of the second terminal. This application can improve the data transmission performance based on DDS.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a data communication method, apparatus, terminal and storage medium based on DDS. Background Technology

[0002] Data Distribution Service (DDS) is a middleware protocol and Application Programming Interface (API) standard. A DDS-based communication architecture includes a first application (publisher), a second application (subscriber), and DDS middleware. The DDS middleware stores the data published by the first application in the second application's global data space. The second application accesses this global data space to retrieve the data published by the first application, thus enabling easier communication and data sharing between the two applications.

[0003] In related technologies, DDS middleware uses User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or Scalable TCP (STCP) transport protocols to store data published by the first application in the global data space of the second application. However, because UDP does not require a response from the other end—as long as the message is sent—its data reliability is poor. TCP requires a three-way handshake to establish a connection and a four-way handshake to close the connection, and it also uses timeout retransmission and acknowledgment mechanisms to ensure data integrity; therefore, TCP has low data transmission efficiency. STCP also requires a three-way handshake to establish a connection and a four-way handshake to close the connection; therefore, STCP also has low data transmission efficiency. In summary, the data transmission performance of DDS-based technologies in related technologies is poor. Summary of the Invention

[0004] This application provides a DDS-based data communication method, apparatus, terminal, and storage medium, which can improve the data transmission performance based on DDS.

[0005] On the one hand, a data communication method based on Data Distribution Service (DDS) is provided, the method comprising:

[0006] Retrieve Topic messages published by the first application on the first terminal;

[0007] Determine the transport protocol supported by the second application of the second terminal, wherein the second application is an application that subscribes to Topic messages;

[0008] If the second application supports the QUIC transport protocol, the Topic message is sent to the second application based on the QUIC transport protocol via the DDS middleware of the first terminal and the second DDS middleware of the second terminal.

[0009] On the other hand, a data communication device based on a data distribution service (DDS) is provided, the device comprising:

[0010] The first acquisition module is used to acquire Topic messages published by the first application of the first terminal.

[0011] The first determining module is used to determine the transmission protocol supported by the second application of the second terminal, wherein the second application is an application that subscribes to the Topic messages;

[0012] The first communication module is configured to send the Topic message to the second application via the first middleware of the first terminal and the second DDS middleware of the second terminal, based on the QUIC transmission protocol, when the transmission protocol supported by the second application includes the QUIC transmission protocol.

[0013] On the other hand, a terminal is provided, the terminal including a processor and a memory, the memory storing at least one piece of program code, the at least one piece of program code being loaded and executed by the processor to implement the data communication method based on Data Distribution Service (DDS) described above.

[0014] On the other hand, a computer-readable storage medium is provided, wherein at least one piece of program code is stored in the storage medium, the at least one piece of program code being loaded and executed by a processor to implement the data communication method based on Data Distribution Service (DDS) described above.

[0015] In this embodiment, since the QUIC transport protocol has the characteristics of low latency (reducing the number of handshakes to establish a connection), high reliability (ensuring no packet loss) and high security (the QUIC generation protocol has embedded TLS1.3 and comes with encrypted transmission), when the second application supports the transport protocol including the QUIC transport protocol, the QUIC transport protocol is preferred for data transmission, which can improve data transmission performance. Attached Figure Description

[0016] Figure 1 A schematic diagram illustrating an implementation environment of a DDS-based data communication method according to an exemplary embodiment of this application is shown.

[0017] Figure 2 A flowchart illustrating a DDS-based data communication method of an exemplary embodiment of this application is shown;

[0018] Figure 3 A schematic diagram of the structure of a DDS middleware according to an exemplary embodiment of this application is shown;

[0019] Figure 4 A schematic diagram of the architecture of a DDS-based data communication method according to an exemplary embodiment of this application is shown;

[0020] Figure 5 A flowchart illustrating a DDS-based data communication method of an exemplary embodiment of this application is shown;

[0021] Figure 6 It shows Figure 5 The illustrated embodiment shows a schematic diagram of the architecture of the DDS-based data communication method.

[0022] Figure 7 A schematic diagram of the architecture of a DDS-based data communication method according to an exemplary embodiment of this application is shown;

[0023] Figure 8 A flowchart illustrating a DDS-based data communication method of an exemplary embodiment of this application is shown;

[0024] Figure 9 A flowchart illustrating a DDS-based data communication method of an exemplary embodiment of this application is shown;

[0025] Figure 10 A flowchart illustrating a DDS-based data communication method of an exemplary embodiment of this application is shown;

[0026] Figure 11 A flowchart illustrating a DDS-based data communication method of an exemplary embodiment of this application is shown;

[0027] Figure 12 A flowchart illustrating a DDS-based data communication method of an exemplary embodiment of this application is shown;

[0028] Figure 13 A block diagram of a DDS-based data communication apparatus according to an exemplary embodiment of this application is shown;

[0029] Figure 14 A block diagram of a terminal according to an exemplary embodiment of this application is shown. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0031] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0032] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the Topic messages published by the first application involved in this application were obtained with full authorization.

[0033] Please refer to Figure 1 This illustration shows a schematic diagram of an implementation environment for a DDS-based data communication method according to an exemplary embodiment of this application. See also... Figure 1 The implementation environment includes: a first terminal 101 and a second terminal 102, and the first terminal 101 and the second terminal 102 communicate with each other based on DDS.

[0034] In some embodiments, the first terminal 101 includes a first application and a first DDS middleware, and the second terminal 102 includes a second application and a second DDS middleware. The first application is a publisher, that is, the first application publishes Topic messages; while the second application is a subscriber, that is, the second application subscribes to Topic messages; the first DDS middleware and the second DDS middleware communicate with each other to enable the first application and the second application to share Topic messages.

[0035] In some embodiments, the publisher and subscriber may be on the same terminal, that is, the first terminal 101 and the second terminal 102 can be the same terminal; however, in more common cases, the publisher and subscriber are not on the same terminal, that is, the first terminal 101 and the second terminal 102 can be different terminals; in this embodiment, the example of the first terminal 101 and the second terminal 102 being different terminals is used for illustration. Furthermore, the first terminal 101 can be an IoT device, an in-vehicle terminal, a mobile phone, or a tablet computer, etc.; the second terminal 102 can also be an IoT device, an in-vehicle terminal, a mobile phone, or a tablet computer, etc.

[0036] Please refer to Figure 2The diagram illustrates a flowchart of a DDS-based data communication method according to an exemplary embodiment of this application. (Reference) Figure 2 The method includes:

[0037] Step 201: Obtain the Topic message published by the first application of the first terminal.

[0038] The first application is the publisher, meaning it publishes Topic messages, while other applications subscribe to these Topic messages; for example, the second application subscribes to these Topic messages. In some embodiments, the first terminal is an in-vehicle terminal, and the first application is an application corresponding to the vehicle's sensors.

[0039] Step 202: Determine the transport protocol supported by the second application of the second terminal, where the second application is the application that subscribes to the Topic messages.

[0040] Prior to this step, the second application subscribes to Topic messages, meaning the second application is a subscriber; the second application supports at least one of the following transport protocols: UDP, TCP, STCP, and QUIC.

[0041] Step 203: If the second application supports the QUIC transport protocol, then based on the QUIC transport protocol, send a Topic message to the second application through the first DDS middleware of the first terminal and the second DDS middleware of the second terminal.

[0042] QUIC is a low-latency internet transport layer protocol based on UDP. Compared to TCP, UDP is more lightweight but has less error checking, resulting in higher efficiency but lower reliability for data transmission. QUIC effectively addresses the various needs of today's transport and application layers. For example, it can handle more connections while offering higher security and lower latency. Furthermore, QUIC incorporates features from TCP, TLS, and HTTP / 2, but it ultimately uses UDP for data transmission.

[0043] In some embodiments, a primary goal of the QUIC transport protocol is to reduce connection latency. For example, when two communicating parties establish a connection for the first time using the QUIC transport protocol, a reliable and secure connection can be established with only 1 RTT (Round-Trip Time), which is much faster than the 1-3 RTTs required by the TCP transport protocol + TLS transport protocol. Furthermore, the sending end caches encrypted authentication information locally, so when the two communicating parties establish a connection again, they can use the stored authentication information to achieve a connection establishment latency of 0-RTT.

[0044] In some embodiments, the QUIC transport protocol also reuses the multiplexing functionality of the HTTP / 2 transport protocol. However, because the QUIC transport protocol is based on the UDP transport protocol, it avoids the head-of-line blocking problem of the HTTP / 2 transport protocol. Since the QUIC transport protocol is based on the UDP transport protocol and runs in the user domain rather than the system kernel, it can be updated and deployed quickly, thus effectively solving the difficulties of deploying and updating the TCP transport protocol.

[0045] In some embodiments, in a distributed system, DDS middleware is a software layer situated between the operating system and the application. It enables the various components of the distributed system to communicate and share data more easily, allowing software developers to focus on the specific purpose of the application rather than the mechanism for transferring information between the application and the operating system, thus simplifying application development. Two applications communicating via DDS can be either publishers or subscribers; and the DDS middleware stores the data to be transmitted into the application's global data space on demand. The application accesses the global data space via an API to retrieve the data without needing to know how the data is transmitted. See also... Figure 3 The DDS middleware consists of two parts: the middleware and the platform. The middleware is responsible for providing application layer API interfaces and quality of service (QoS) management, while the platform, as the base part, is mainly responsible for transmission services between various heterogeneous platforms, that is, data transmission based on transmission protocols.

[0046] For example, see Figure 4Application 1 (publisher 1) publishes Topic Message 1 and Topic Message 2, meaning the DDS middleware corresponding to Application 1 publishes Topic Message 1 and Topic Message 2 to the global data space. Application A (subscriber A) and Application B (subscriber B) subscribe to Topic Message 1 and Topic Message 2, meaning the DDS middleware corresponding to Application A retrieves Topic Message 1 and Topic Message 2 from the global data space. Application 2 (publisher 2) also publishes Topic Message 2, meaning the DDS middleware corresponding to Application 2 publishes Topic Message 2 to the global data space. Application 3 (publisher 3) publishes Topic Message 3, meaning the DDS middleware corresponding to Application 3 publishes Topic Message 3 to the global data space; Application B (subscriber B) subscribes to Topic Message 2 and Topic Message 3, meaning the DDS middleware corresponding to Application B retrieves Topic Message 2 and Topic Message 3 from the global data space. Application B is both a subscriber and a publisher. Application B (publisher B) publishes Topic message 4, that is, the DDS middleware corresponding to application B publishes Topic message 4 to the global data space. Application 1 is both a subscriber and a publisher. Application 1 (subscriber 1) subscribes to Topic message 4, that is, the DDS middleware corresponding to application 1 retrieves Topic message 4 from the global data space.

[0047] In this embodiment, since the QUIC transport protocol has the characteristics of low latency (reducing the number of handshakes to establish a connection), high reliability (ensuring no packet loss) and high security (the QUIC generation protocol has embedded TLS1.3 and comes with encrypted transmission), when the second application supports the transport protocol including the QUIC transport protocol, the QUIC transport protocol is preferred for data transmission, which can improve data transmission performance.

[0048] Please refer to Figure 5 This document illustrates a flowchart of a DDS-based data communication method according to an exemplary embodiment of this application. The method can be executed by a first terminal or by a first DDS middleware included in the first terminal; in this embodiment, the execution entity is described as the first DDS middleware in the first terminal. (Reference) Figure 5 The method includes:

[0049] Step 501: The first DDS middleware obtains the Topic message created by the first application. The Topic message is used for the second application to subscribe to.

[0050] Data transmission based on DDS is topic-based, and the two applications exchange topic messages using a data-centric publish-subscribe (DCPS) model. The first application is the publisher, creating topic messages for the second application (subscriber) to subscribe to. For example, see [reference needed]. Figure 6 The first application, acting as the data sender (Publisher), calls the API write interface (DataWriter) to write the Topic message.

[0051] In some embodiments, the first DDS middleware obtains the Topic message created by the first application and broadcasts the Topic message for the second application to subscribe to; if the second application subscribes to the Topic message, the second DDS middleware (the DDS middleware in the second terminal where the second application is located) sends a subscription registration message to the first DDS middleware, the subscription registration message carrying the main registered Topic message and the transport protocol supported by the second application, and then executes step 302.

[0052] In some embodiments, a transport protocol negotiation field is added to the subscription registration message, and the transport protocol supported by the second application is marked in the transport protocol negotiation field so that the first DDS middleware can obtain the transport protocol supported by the second application; and the transport protocol supported by the second application is marked by the second DDS middleware in the transport protocol negotiation field of the subscription registration message.

[0053] For example, please refer to Figure 7 Application 1 (the publisher) creates a Topic message, and the first DDS middleware 1 on the first terminal where Application 1 resides broadcasts the Topic message for second applications to subscribe to. When Application 2 and Application 3 subscribe to the Topic message, the second DDS middleware 1 on the second terminal where Application 2 resides sends a subscription registration message to the first DDS middleware 1. This subscription registration message carries the transport protocol supported by Application 2, such as TCP. Similarly, the second DDS middleware 2 on the second terminal where Application 3 resides sends a subscription registration message to the first DDS middleware 1. This subscription registration message carries the transport protocol supported by Application 3, such as TCP+QUIC.

[0054] In some embodiments, the transmission protocol supported by the second application can be set and changed based on at least one of the version of the second DDS middleware and the access network type; for example, if the version of the second DDS middleware 1 on the second terminal where application 2 is located is version 1 and the access network is a 5G network, then the transmission protocol supported by application 2 is TCP; while the version of the second DDS middleware 2 on the second terminal where application 3 is located is version 2 and the access network is a Wi-Fi (WiFi) network, then the transmission protocol supported by application 3 is TCP+QUIC.

[0055] Step 502: The first DDS middleware obtains the subscription registration message of the second application. The subscription registration message carries the Topic message and the transport protocol supported by the second application.

[0056] The first DDS middleware receives the subscription registration message of the second application sent by the second DDS middleware, obtains the Topic message it has subscribed to and the transport protocol it supports from the subscription registration message of the second application, and then executes step 503.

[0057] For example, continue to refer to Figure 7 The first DDS middleware 1 obtains the Topic messages subscribed to by application 2 and the supported transport protocol TCP, and obtains the Topic messages subscribed to by application 3 and the supported transport protocol TCP+QUIC.

[0058] In some embodiments, the first DDS middleware corresponding to the first application obtains the transport protocols supported by the second application, but the first DDS middleware does not synchronize the transport protocols supported by the second application to the first application. That is, the first application is unaware of the transport protocols supported by the second application, thereby saving transport resources.

[0059] Step 503: If the Topic message carried in the subscription registration message is the same as the Topic message created by the first application, the first DDS middleware determines the Topic message subscribed by the second application and stores the program identifier of the second application and the transport protocol supported by the second application in the correspondence.

[0060] The first DDS middleware determines whether the Topic message carried in the subscription registration message of the second application is the same as the Topic message created by the first application. If the Topic message carried in the subscription registration message of the second application is the same as the Topic message created by the first application, the first DDS middleware determines that the second application subscribes to the Topic message. Only then does the first DDS middleware store the program identifier of the second application and the transport protocol supported by the second application into the correspondence.

[0061] In addition, when the first middleware determines that the second application has subscribed to Topic messages, the first DDS middleware also associates and stores the program identifier of the first application and the program identifier of the second application, so as to find the second application that has subscribed to Topic messages based on the program identifier of the first application.

[0062] In some embodiments, if the first DDS middleware determines that the Topic message carried in the subscription registration message of the second application is different from the Topic message created by the first application, the first DDS middleware discards the subscription registration message.

[0063] In this embodiment of the application, after receiving the subscription registration message of the second application, the first DDS middleware verifies the Topic message created by the first application and the Topic message carried by the subscription registration message of the second application. Only after confirming that the second application has subscribed to the Topic message will subsequent recording operations be performed, thereby improving the reliability of data transmission.

[0064] In some embodiments, steps 501-503 are subscription processes that only need to be executed once. When the first application publishes a Topic message subsequently, step 304 can be executed directly.

[0065] Step 504: The first DDS middleware obtains the Topic message published by the first application.

[0066] The first application publishes a Topic message, and the first DDS middleware retrieves the Topic message published by the first application. In this step, the Topic message published by the first application is an update of the Topic message created in step 301. For example, continue to refer to... Figure 7 When an application publishes a Topic message update, it calls the first DDS middleware to publish the Topic message.

[0067] Step 505: The first DDS middleware determines the program identifier of the second application based on the program identifier of the first application.

[0068] In step 503, the first DDS middleware associates and stores the program identifier of the first application and the program identifier of the second application; therefore, in this step, the first DDS middleware obtains the program identifier of the second application associated with the program identifier of the first application based on the program identifier of the first application.

[0069] For example, continue to refer to Figure 7 The first DDS middleware determines that the applications subscribing to the Topic messages of application 1 are application 2 and application 3.

[0070] Step 506: The first DDS middleware obtains the transmission protocols supported by the second application from the correspondence between the program identifier and the transmission protocol based on the program identifier of the second application.

[0071] The transport protocol supported by the second application in the correspondence is the one stored in the Topic message subscription of the second application. For example, see [link to relevant documentation]. Figure 7 The first DDS middleware determines that the transport protocol supported by application 2 is TCP, and the transport protocol supported by application 3 is TCP+QUIC.

[0072] Step 507: If the second application supports the QUIC transport protocol, the first DDS middleware sends Topic messages to the second application based on the QUIC transport protocol, through the first DDS middleware and the second DDS middleware.

[0073] If the second application supports the QUIC transport protocol, the first DDS middleware will preferentially use the QUIC transport protocol to send Topic messages to the second application, thereby improving data transmission performance. If the second application does not support the QUIC transport protocol, the first DDS middleware will send Topic messages to the second application based on other transport protocols supported by the second application, through the first DDS middleware and the second DDS middleware.

[0074] For example, if application 2 supports the TCP transport protocol, then the first DDS middleware sends Topic messages to the second application based on the TCP transport protocol, through the first DDS middleware and the second DDS middleware; if application 3 supports the TCP+QUIC transport protocol, then the first DDS middleware sends Topic messages to the second application based on the QUIC transport protocol, through the first DDS middleware and the second DDS middleware.

[0075] In this embodiment of the application, during the Topic message subscription stage, a transport protocol negotiation field is added to the subscription registration message. The second DDS middleware marks the transport protocol supported by the second application in the transport protocol negotiation field, thereby notifying the first DDS middleware of the transport protocol supported by the second application. As a result, the QUIC transport protocol can be preferentially selected for data transmission based on the transport protocol supported by the second application, so as to improve data transmission performance.

[0076] Please refer to Figure 8This document illustrates a flowchart of a DDS-based data communication method according to an exemplary embodiment of this application. The method can be executed by a first terminal or by a first DDS middleware included in the first terminal; in this embodiment, the execution entity is described as the first DDS middleware in the first terminal. (Reference) Figure 8 The method includes:

[0077] Step 801: The first DDS middleware obtains the Topic message published by the first application.

[0078] In some embodiments, this step is the same as step 504, and will not be described again here.

[0079] Step 802: The first DDS middleware determines the transport protocol supported by the second application of the second terminal, where the second application is an application that subscribes to Topic messages.

[0080] In some embodiments, this step can be implemented through steps 506-506, which will not be described in detail here.

[0081] Step 803: If the second application supports the QUIC transport protocol, the first DDS middleware sends the Topic message to the second DDS middleware based on the QUIC transport protocol.

[0082] The first application stores the Topic messages in its local global data space. Then, the first DDS middleware sends the Topic messages in its local global data space to the second DDS middleware based on the QUIC transport protocol.

[0083] Step 804: The first DDS middleware stores the Topic message in the global data space of the second application through the second DDS middleware, and the second application reads the Topic message from the global data space.

[0084] The second DDS middleware receives Topic messages sent by the first DDS middleware and stores them in the global data space of the second application. The second application then reads the Topic messages from its global data space. For example, if a message event is generated in the global data space of the second application, the second application reads and processes the message event.

[0085] For example, continue to refer to Figure 6The second application acts as the data receiver (Subscriber), and the first DDS middleware publishes the Topic messages published by the first application to the global data space. The process of the first DDS middleware publishing the Topic messages published by the first application to the global data space is as follows: The first DDS middleware first updates the Topic messages published by the first application in its global data space. Then, based on the subscriber of the Topic messages (the second application), it transmits the Topic messages to the corresponding second DDS middleware, which updates the Topic messages in its global data space. Message events are generated in the second application's global data space, and the second application reads and processes these message events through a DataReader.

[0086] In this embodiment of the application, the Topic message based on the QUIC transmission protocol is stored in the global data space of the second application through the first DDS middleware and the second DDS middleware, so that the second application can read the Topic from the local global data space, thereby optimizing DDS transmission based on the QUIC transmission protocol and improving data transmission performance.

[0087] Please refer to Figure 9 This document illustrates a flowchart of a DDS-based data communication method according to an exemplary embodiment of this application. The method can be executed by a first terminal or by a first DDS middleware included in the first terminal; in this embodiment, the execution entity is described as the first DDS middleware in the first terminal. (Reference) Figure 9 The method includes:

[0088] Step 901: The first DDS middleware obtains the Topic message published by the first application.

[0089] In some embodiments, this step is the same as step 304, and will not be described again here.

[0090] Step 902: The first DDS middleware determines the transport protocol supported by the second application of the second terminal, where the second application is an application that subscribes to Topic messages.

[0091] In some embodiments, this step can be implemented through steps 305-306, which will not be described in detail here.

[0092] Step 903: When the second application supports the QUIC transmission protocol, and the first DDS middleware communicates with the second DDS middleware for the first time, the first DDS middleware establishes a QUIC connection between the first DDS middleware and the second DDS middleware based on the terminal identifier ID of the first terminal and the ID of the second terminal.

[0093] QUIC enables rapid handshakes and integrates the handshake and key negotiation exchange processes, achieving a connection establishment speed of 1-RTT on the first visit, significantly improving handshake efficiency. This is extremely useful for scenarios with frequent short connections or high latency requirements. Furthermore, the first and second DDS middleware establish QUIC connections based on the IDs of the first and second terminals. These terminals can be IoT devices or in-vehicle terminals. IoT and autonomous driving scenarios are inherently weak network environments where network IPs can change at any time, while QUIC connections are defined by connection IDs. Therefore, when the underlying four-tuple changes, TCP must re-handshake to establish a connection, while QUIC allows the connection to remain open, avoiding the need for a second handshake and reducing handshake time. Thus, transmitting Topic messages based on the QUIC transport protocol enables connection migration.

[0094] Step 904: The first DDS middleware, based on the QUIC connection, sends Topic messages to the second application through the first DDS middleware and the second DDS middleware.

[0095] The first DDS middleware, based on a QUIC connection, sends Topic messages to the second DDS middleware. The second DDS middleware stores the Topic messages in the global data space of the second application, which then reads the Topic messages from the global data space.

[0096] In this embodiment, the first DDS middleware and the second DDS middleware establish a QUIC connection based on the IDs of the first terminal and the second terminal. The first terminal and the second terminal can be IoT devices or vehicle terminals. IoT or autonomous driving scenarios are inherently weak network environments, and network IPs can change at any time. The QUIC connection, however, is defined by the connection ID. Therefore, when the underlying four-tuple changes, TCP must re-handshake to establish a connection, while QUIC allows the connection to remain established, thus avoiding the need for a second handshake and reducing handshake time. Therefore, transmitting Topic messages based on the QUIC transport protocol can achieve connection migration.

[0097] Please refer to Figure 10This document illustrates a flowchart of a DDS-based data communication method according to an exemplary embodiment of this application. The method can be executed by a first terminal or by a first DDS middleware included in the first terminal; in this embodiment, the execution entity is described as the first DDS middleware in the first terminal. (Reference) Figure 10 The method includes:

[0098] Step 1001: The first DDS middleware receives the Topic message published by the first application.

[0099] In some embodiments, this step is the same as step 504, and will not be described again here.

[0100] Step 1002: The first DDS middleware determines the transport protocol supported by the second application of the second terminal, where the second application is an application that subscribes to Topic messages.

[0101] In some embodiments, this step can be implemented through steps 505-506, which will not be described in detail here.

[0102] Step 1003: When the second application supports the QUIC transport protocol, and the first DDS middleware communicates with the second DDS middleware for the first time, the first DDS middleware sends an RTT request message to the second DDS middleware based on the ID of the second terminal. The RTT request message carries the ID of the first terminal and is used to query the handshake public key.

[0103] The RTT request message is used not only to request the establishment of a QUIC connection, but also to query the handshake public key, thus QUIC integrates the handshake and key negotiation and exchange processes. The second DDS middleware receives the RTT request message, obtains the handshake public key, and sends an RTT response message to the first DDS middleware based on the first terminal's ID. The RTT response message carries the handshake public key.

[0104] Step 1004: Upon receiving the RTT response message sent by the second DDS middleware, the first DDS middleware establishes a QUIC connection between the first DDS middleware and the second DDS middleware. The RTT response message carries the handshake public key.

[0105] After the first DDS middleware receives the RTT response message, it completes the 1-RTT handshake process, and at this time, a QUIC connection is established between the first DDS middleware and the second DDS middleware.

[0106] Step 1005: The first DDS middleware determines the session key based on the handshake public key.

[0107] The first DDS middleware determines the session key based on the handshake public key using any key algorithm; for example, the first DDS middleware determines the session key based on the handshake public key using the DH algorithm.

[0108] In some embodiments, the first DDS middleware stores a handshake key so that it can directly obtain the handshake key in subsequent non-first communications between the first DDS middleware and the second DDS middleware, thereby achieving a 0-RTT connection establishment speed for repeat customers.

[0109] Step 1006: The first DDS middleware encrypts the Topic message based on the session key.

[0110] The first DDS middleware, based on the QUIC transport protocol, encapsulates Topic messages to obtain packets. The packets include the target ID (the ID of the second terminal) and the Topic message. Based on the session key, the Topic message in the packets is encrypted.

[0111] In this embodiment, most fields in the message header of QUIC are encrypted, except for a few fields such as the destination ID. At the same time, TLS 1.3 is directly embedded in QUIC, and the handshake information and warnings generated during the encryption process are directly encapsulated and transmitted through QUIC, which can improve data security.

[0112] Step 1007: The first DDS middleware, based on the QUIC connection, sends encrypted Topic messages to the second application through the first DDS middleware and the second DDS middleware.

[0113] In some embodiments, this step is similar to step 904, and will not be described again here.

[0114] In this embodiment of the application, during the connection establishment process between the first DDS middleware and the second DDS middleware, a handshake public key is negotiated, and the Topic message is encrypted based on the session key obtained from the handshake public key, which can improve the security of data transmission.

[0115] Please refer to Figure 11 This document illustrates a flowchart of a DDS-based data communication method according to an exemplary embodiment of this application. The method can be executed by a first terminal or by a first DDS middleware included in the first terminal; in this embodiment, the execution entity is described as the first DDS middleware in the first terminal. (Reference) Figure 11 The method includes:

[0116] Step 1101: The first DDS middleware obtains the Topic message published by the first application of the first terminal.

[0117] In some embodiments, this step is the same as step 504, and will not be described again here.

[0118] Step 1102: The first DDS middleware determines the transport protocol supported by the second application of the second terminal, where the second application is an application that subscribes to Topic messages.

[0119] In some embodiments, this step can be implemented through steps 505-506, which will not be described in detail here.

[0120] Step 1103: If the second application supports the QUIC transport protocol, and the first DDS middleware and the second DDS middleware are not communicating for the first time, the first DDS middleware obtains the cached handshake public key.

[0121] The handshake public key is cached during the initial communication between the first DDS middleware and the second DDS middleware. In this step, the first DDS middleware directly obtains the cached handshake public key to proceed with subsequent steps, thereby achieving 0-RTT connection establishment for repeat customers and greatly improving handshake efficiency.

[0122] Step 1104: The first DDS middleware encrypts the Topic message based on the session key.

[0123] In some embodiments, this step is the same as step 806, and will not be described again here.

[0124] Step 1105: The first DDS middleware, based on the QUIC connection, sends encrypted Topic messages to the second application through the first DDS middleware and the second DDS middleware.

[0125] In some embodiments, this step is the same as step 1007, and will not be described again here.

[0126] In this embodiment, when the first DDS middleware communicates with the second DDS middleware for the first time, the connection is established through 1-RTT and the handshake public key is cached. When the first DDS middleware communicates with the second DDS middleware for the second time, the cached handshake public key is directly obtained, and subsequent encryption and data transmission processes can be performed. This truly achieves a 0-RTT connection establishment speed for repeat customers, thereby improving handshake efficiency and data transmission efficiency.

[0127] Please refer to Figure 12 This document illustrates a flowchart of a DDS-based data communication method according to an exemplary embodiment of this application. The method can be executed by a first terminal or by a first DDS middleware included in the first terminal; in this embodiment, the execution entity is described as the first DDS middleware in the first terminal. (Reference) Figure 12The method includes:

[0128] Step 1201: The first DDS middleware obtains the Topic message published by the first application of the first terminal.

[0129] In some embodiments, this step is the same as step 504, and will not be described again here.

[0130] Step 1202: The first DDS middleware determines the transport protocol supported by the second application of the second terminal, where the second application is an application that subscribes to Topic messages.

[0131] In some embodiments, this step can be implemented through steps 505-506, which will not be described in detail here.

[0132] Step 1203: If the second application supports the QUIC transport protocol, the first DDS middleware sends Topic messages to the second application based on the QUIC transport protocol, through the first DDS middleware of the first terminal and the second DDS middleware of the second terminal.

[0133] In some embodiments, this step can be implemented through step 507; or, this step can be implemented through steps 803-804; or, this step can be implemented through steps 703-704; or, this step can be implemented through steps 1003-1007; or, this step can be implemented through steps 1103-1105, which will not be described in detail here.

[0134] Step 1204: In the event that the transmission of Topic messages based on the QUIC transport protocol fails, the first DDS middleware determines other transport protocols included in the transport protocols supported by the second application. The other transport protocols are transport protocols other than the QUIC transport protocol.

[0135] Other transport protocols can be at least one of TCP, UDP, and STCP transport protocols. In some embodiments, when other transport protocols include multiple transport protocols, in this step, the first DDS middleware randomly selects one transport protocol from the multiple transport protocols; or, the first DDS middleware selects a transport protocol from the multiple transport protocols that matches the type of the Topic message published by the first application. For example, if the Topic message published by the first application is of low importance, the first DDS middleware selects the UDP transport protocol from the multiple transport protocols. As another example, if the Topic message published by the first application is of high importance, the first DDS middleware selects the TCP transport protocol from the multiple transport protocols.

[0136] In this embodiment, the first DDS middleware selects other transmission protocols from multiple transmission protocols supported by the second application based on the type of Topic message published by the first application. This allows it to select other transmission protocols that meet the actual scenario, thereby improving data transmission performance to some extent.

[0137] Step 1205: The first DDS middleware sends Topic messages to the second application through the first DDS middleware and the second DDS middleware, based on other transport protocols.

[0138] The first DDS middleware sends Topic messages to the second DDS middleware based on other transport protocols. The second DDS middleware stores the Topic messages in the global data space of the second application, and the second application reads the Topic messages from the global data space.

[0139] For example, if application 3 supports the TCP+QUIC transport protocol, then if the first DDS middleware fails to send the Topic message published by the first application to the second application based on the QUIC transport protocol, the first DDS middleware will send the Topic message published by the first application to the second application based on the TCP transport protocol.

[0140] In this embodiment, when the second application supports the QUIC transport protocol, the first DDS middleware prioritizes sending the Topic message published by the first application to the second application based on the QUIC transport protocol. If sending the Topic message based on the QUIC transport protocol fails, it will then try to send the Topic message published by the first application to the second application based on other transport protocols, which can improve the success rate of data transmission.

[0141] Please refer to Figure 13 The diagram illustrates a block diagram of a DDS-based data communication apparatus according to an exemplary embodiment of this application, the apparatus comprising:

[0142] The first acquisition module 1301 is used to acquire Topic messages published by the first application of the first terminal;

[0143] The first determining module 1302 is used to determine the transmission protocol supported by the second application of the second terminal, wherein the second application is an application that subscribes to Topic messages;

[0144] The first communication module 1303 is used to send Topic messages to the second application via the first DDS middleware of the first terminal and the second DDS middleware of the second terminal, based on the QUIC transmission protocol, when the transmission protocol supported by the second application includes the QUIC transmission protocol.

[0145] In some embodiments, the first determining module 1302 is configured to determine the program identifier of the second application based on the program identifier of the first application; and to obtain the transmission protocol supported by the second application from the correspondence between program identifiers and transmission protocols based on the program identifier of the second application.

[0146] In some embodiments, the communication device further includes:

[0147] The second acquisition module is used to acquire Topic messages created by the first application. These Topic messages are used for the second application to subscribe to.

[0148] The third acquisition module is used to acquire the subscription registration message of the second application. The subscription registration message carries the Topic message and the transmission protocol supported by the second application.

[0149] The storage module is used to determine the Topic message subscribed to by the second application when the Topic message carried in the subscription registration message is the same as the Topic message created by the first application, and to store the program identifier of the second application and the transport protocol supported by the second application in the correspondence relationship.

[0150] In some embodiments, the communication device further includes:

[0151] The second determining module is used to determine other transmission protocols included in the transmission protocols supported by the second application when the transmission of Topic messages based on the QUIC transmission protocol fails. The other transmission protocols are transmission protocols other than the QUIC transmission protocol.

[0152] The second communication module is used to send Topic messages to the second application through the first DDS middleware and the second DDS middleware based on other transmission protocols.

[0153] In some embodiments, other transport protocols include at least one of TCP, UDP, and STCP transport protocols.

[0154] In some embodiments, the first communication module 1303 is used to send a Topic message to a second DDS middleware through a first DDS middleware based on the QUIC transmission protocol; and to store the Topic message in the global data space of a second application through the second DDS middleware, so that the second application can read the Topic message from the global data space.

[0155] In some embodiments, the first communication module 1303 is configured to establish a QUIC connection between the first DDS middleware and the second DDS middleware based on the terminal identifier ID of the first terminal and the ID of the second terminal when the first DDS middleware communicates with the second DDS middleware for the first time; and send Topic messages to the second application through the first DDS middleware and the second DDS middleware based on the QUIC connection.

[0156] In some embodiments, the first communication module 1303 is configured to send an RTT request message to the second DDS middleware based on the ID of the second terminal. The RTT request message carries the ID of the first terminal and is used to query the handshake public key. Upon receiving an RTT response message sent by the second DDS middleware, a QUIC connection is established between the first DDS middleware and the second DDS middleware. The RTT response message carries the handshake public key.

[0157] The communication module is also used to determine the session key based on the handshake public key; to encrypt the Topic message based on the session key; and to send the encrypted Topic message to the second application through the first DDS middleware and the second DDS middleware based on the QUIC connection.

[0158] In some embodiments, the first communication module 1303 is configured to: obtain a cached handshake public key when the first DDS middleware and the second DDS middleware are not communicating for the first time; encrypt the Topic message based on the session key; and send the encrypted Topic message to the second application through the first DDS middleware and the second DDS middleware based on the QUIC connection.

[0159] In this embodiment, since the QUIC transport protocol has the characteristics of low latency (reducing the number of handshakes to establish a connection), high reliability (ensuring no packet loss) and high security (the QUIC generation protocol has embedded TLS1.3 and comes with encrypted transmission), when the second application supports the transport protocol including the QUIC transport protocol, the QUIC transport protocol is preferred for data transmission, which can improve data transmission performance.

[0160] It should be noted that the DDS-based data communication device provided in the above embodiments is only illustrated by the division of the above functional modules when performing DDS-based data communication. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the user terminal can be divided into different functional modules to complete all or part of the functions described above. In addition, the DDS-based data communication device and the DDS-based data communication method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0161] Please refer to Figure 14 The diagram illustrates a block diagram of a terminal 1400 according to an exemplary embodiment of this application. The terminal 1400 in this application may include one or more components such as a processor 1410, a memory 1420, and a display screen 1430.

[0162] Processor 1410 may include one or more processing cores. Processor 1410 connects to various parts within terminal 1400 using various interfaces and lines, and performs various functions and processes data of terminal 1400 by running or executing instructions, programs, code sets, or instruction sets stored in memory 1420, and by calling data stored in memory 1420. Optionally, processor 1410 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 1410 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural-network Processing Unit (NPU), and modem. Specifically, the CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required to be displayed on display screen 1430; the NPU is used to implement Artificial Intelligence (AI) functions; and the modem is used to handle wireless communication. It is understandable that the aforementioned modem may not be integrated into the processor 1410, but may be implemented as a separate chip.

[0163] The memory 1420 may include random access memory (RAM) or read-only memory. Optionally, the memory 1420 may include a non-transitory computer-readable storage medium. The memory 1420 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1420 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described below, etc.; the data storage area may store data created based on the use of the terminal 1400 (such as audio data, phone book, etc.).

[0164] Display screen 1430 is a display component used to display a user interface. Optionally, the display screen 1430 is a touch-enabled display screen, through which users can use their fingers, styluses, or any suitable object to perform touch operations on the display screen 1430. Display screen 1430 is typically located on the front panel of terminal 1400. Display screen 1430 can be designed as a full-screen, curved screen, irregularly shaped screen, dual-sided screen, or foldable screen. Display screen 1430 can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen, etc., which are not limited in this embodiment.

[0165] In addition, those skilled in the art will understand that the structure of the terminal 1400 shown in the above figures does not constitute a limitation on the terminal 1400. The terminal 1400 may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the terminal 1400 may also include audio acquisition devices, speakers, radio frequency circuits, input units, sensors, audio circuits, a Wireless Fidelity (Wi-Fi) module, a power supply, a Bluetooth module, and other components, which will not be described in detail here.

[0166] This application also provides a computer-readable medium storing at least one piece of program code, which is loaded and executed by a processor to implement the DDS-based data communication method shown in the above embodiments.

[0167] This application also provides a computer program product, which includes at least one piece of program code, which is loaded and executed by a processor to implement the DDS-based data communication method shown in the above embodiments.

[0168] In some embodiments, the computer program product involved in the present application can be deployed and executed on a user terminal, or on multiple user terminals located in one location, or on multiple user terminals distributed in multiple locations and interconnected through a communication network. Multiple user terminals distributed in multiple locations and interconnected through a communication network can form a blockchain system.

[0169] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0170] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A data communication method based on a data distribution service (DDS), characterized by, The method comprises: acquiring a topic message published by a first application of a first terminal; determining a transmission protocol supported by a second application of a second terminal, the second application being an application subscribing to the topic message, the transmission protocol supported by the second application being set based on a version of second DDS middleware of the second terminal and an access network form; in a case where the transmission protocol supported by the second application includes a QUIC transmission protocol, sending the topic message to the second application through the first DDS middleware of the first terminal and the second DDS middleware of the second terminal based on the QUIC transmission protocol, the transmission protocol supported by the second application being carried in a subscription registration message, and a transmission protocol negotiation field being added in the subscription registration message, the transmission protocol negotiation field marking the transmission protocol supported by the second application; in a case where the sending of the topic message based on the QUIC transmission protocol fails, determining other transmission protocols included in the transmission protocol supported by the second application, the other transmission protocols being transmission protocols other than the QUIC transmission protocol; in a case where there are multiple other transmission protocols, selecting an other transmission protocol matching a type of the topic message from the multiple other transmission protocols; sending the topic message to the second application through the first DDS middleware and the second DDS middleware based on the other transmission protocol; the sending of the topic message to the second application through the first DDS middleware of the first terminal and the second DDS middleware of the second terminal based on the QUIC transmission protocol comprises: in a case where the first DDS middleware and the second DDS middleware communicate for the first time, sending an RTT request message to the second DDS middleware based on an ID of the second terminal, the RTT request message carrying an ID of the first terminal, and the RTT request message being used not only to request the establishment of a QUIC connection but also to inquire a handshake public key; in a case where an RTT response message sent by the second DDS middleware is received, establishing the QUIC connection between the first DDS middleware and the second DDS middleware, the RTT response message carrying a handshake public key, the handshake public key being cached when the first DDS middleware and the second DDS middleware communicate for the first time, and the handshake public key cached by the first DDS middleware being used to directly acquire the handshake public key in a case where the first DDS middleware and the second DDS middleware communicate for the second time; determining a session key based on the handshake public key, encrypting the topic message based on the session key, and sending the encrypted topic message to the second application through the first DDS middleware and the second DDS middleware based on the QUIC connection.

2. The method of claim 1, wherein, The determining the transmission protocol supported by the second application of the second terminal comprises: determining the program identity of the second application based on the program identity of the first application; obtaining the transmission protocol supported by the second application from the correspondence between the program identity and the transmission protocol based on the program identity of the second application.

3. The method of claim 2, wherein, The method further comprises: obtaining a Topic message created by the first application, the Topic message being used for the second application to subscribe; obtaining a subscription registration message of the second application, the subscription registration message carrying the Topic message and the transmission protocol supported by the second application; in the case where the Topic message carried in the subscription registration message is the same as the Topic message created by the first application, determining that the second application subscribes to the Topic message, and storing the program identity of the second application and the transmission protocol supported by the second application in the correspondence.

4. The method of claim 1, wherein, The other transmission protocols comprise at least one of a TCP transmission protocol, a UDP transmission protocol and a STCP transmission protocol.

5. The method of claim 1, wherein, The sending the Topic message to the second application based on the QUIC transmission protocol through the first DDS middleware of the first terminal and the second DDS middleware of the second terminal comprises: sending the Topic message to the second DDS middleware through the first DDS middleware based on the QUIC transmission protocol; storing the Topic message into a global data space of the second application through the second DDS middleware, and reading the Topic message from the global data space by the second application.

6. The method according to claim 1 or 5, characterized in that, The sending the Topic message to the second application based on the QUIC transmission protocol through the first DDS middleware of the first terminal and the second DDS middleware of the second terminal comprises: in the case where the first DDS middleware and the second DDS middleware are not communicated for the first time, obtaining a cached handshake public key, the handshake public key being cached when the first DDS middleware and the second DDS middleware are communicated for the first time; encrypting the Topic message based on the session key; sending the encrypted Topic message to the second application through the first DDS middleware and the second DDS middleware based on the QUIC connection.

7. A data communication apparatus based on a Data Distribution Service (DDS), characterized by The apparatus comprises: a first obtaining module configured to obtain a Topic message published by a first application of a first terminal; a first determining module configured to determine a transmission protocol supported by a second application of a second terminal, the second application being an application that subscribes to the Topic message. The first communication module is configured to, in the case that the second application program supports the QUIC transmission protocol, send the Topic message to the second application program based on the QUIC transmission protocol through the first DDS middleware of the first terminal and the second DDS middleware of the second terminal, wherein the transmission protocol supported by the second application program is carried in a subscription registration message, and a transmission protocol negotiation field is added in the subscription registration message, and the transmission protocol negotiation field marks the transmission protocol supported by the second application program. The second determination module is configured to, in the case that the Topic message fails to be transmitted based on the QUIC transmission protocol, determine other transmission protocols included in the transmission protocols supported by the second application program, wherein the other transmission protocols are transmission protocols other than the QUIC transmission protocol. The data communication device is configured to, in the case that there are multiple other transmission protocols, select an other transmission protocol matching the type of the Topic message from the multiple other transmission protocols. The second communication module is configured to send the Topic message to the second application program based on the other transmission protocol through the first DDS middleware and the second DDS middleware. The first communication module is configured to, in the case that the first DDS middleware and the second DDS middleware communicate for the first time, send an RTT request message to the second DDS middleware based on the ID of the second terminal, wherein the RTT request message carries the ID of the first terminal, and the RTT request message is used not only to request to establish a QUIC connection, but also to inquire a handshake public key; in the case that an RTT response message sent by the second DDS middleware is received, the QUIC connection is established between the first DDS middleware and the second DDS middleware, wherein the RTT response message carries the handshake public key, the handshake public key is cached when the first DDS middleware and the second DDS middleware communicate for the first time, and the handshake public key cached by the first DDS middleware is used to directly obtain the handshake public key in the case that the first DDS middleware and the second DDS middleware communicate for the second time. The data communication device is configured to determine a session key based on the handshake public key, encrypt the Topic message based on the session key, and send the encrypted Topic message to the second application program through the first DDS middleware and the second DDS middleware based on the QUIC connection.

8. A terminal, characterized by comprising: The terminal comprises a processor and a memory, and the memory stores at least one program code, which is loaded and executed by the processor to implement the DDS-based data communication method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The storage medium stores at least one program code, and the at least one program code is loaded and executed by the processor to implement the data communication method based on the data distribution service (DDS) according to any one of claims 1 to 6.

10. A computer program product, characterised in that, The computer program product includes at least one program code, and the at least one program code is loaded and executed by the processor to implement the data communication method based on the data distribution service (DDS) according to any one of claims 1 to 6.

Images