DDS interconnection and intercommunication method and system under container cluster isolation network

Abstract

The invention relates to a DDS interconnection and intercommunication method and system under a container cluster isolation network, and the method comprises the steps: deploying and starting a routing agent and a DDS application container agent; monitoring local DDS service discovery data through the DDS application container agent; receiving DDS service discovery data reported by all DDS application container agents through a routing agent, constructing an index based on the DDS service discovery data, performing data analysis in the index, and automatically establishing a communication link between the DDS application container agents; and executing interconnection and intercommunication based on the communication link. According to the method, the routing agent and the DDS application container agent are deployed, and the automatic index is built in the routing agent, so that interconnection and intercommunication of the DDS application container under the isolated network can be supported without configuring an intercommunication relationship in advance.

Description

Technical Field

[0001] This disclosure relates to the field of container cluster network communication technology, and in particular to a method and system for DDS interconnection in an isolated container cluster network. Background Technology

[0002] Containerization technology is widely used in distributed application deployment. Kubernetes, as a container orchestration platform, combined with the Calico CNI plugin, can achieve powerful container network isolation capabilities. DDS data distribution service has become a core technology for distributed simulation due to its high real-time performance and high reliability.

[0003] In related technologies, container networks between different projects or different tasks within the same project are strictly isolated in a Kubernetes Calico environment. This prevents cross-project DDS applications from achieving dynamic discovery and interoperability, and also limits flexible networking between different applications within the same project. To address these issues, existing solutions for automatic discovery and dynamic interconnection include Docker native networking and Host mode networking. The Docker native networking solution uses Docker's own bridged network to network DDS applications, connecting all relevant DDS containers to the same Docker bridged network and enabling inter-container communication through Docker's built-in network forwarding function. The Host mode networking solution configures the network mode of DDS application containers to Host mode, allowing containers to directly share the host machine's network namespace. This is equivalent to all DDS applications running directly on the host machine's network without requiring additional network configuration for communication.

[0004] However, the above technical solutions have the following drawbacks: the Docker native networking solution only supports container networking within a single host machine. All DDS containers within the same host machine are on the same bridged network, resulting in no isolation between DDS applications in different projects and tasks, which can easily lead to data interference and security risks. In the Host mode networking solution, all DDS applications share the host machine network. DDS messages from different projects, different DDS Domain communication domains, and different Topic names will interfere with each other, leading to service discovery mismatches, data transmission errors, and even the loss of critical messages, making it impossible to achieve network isolation between projects. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this disclosure provides a method and system for DDS interconnection and interoperability under a container cluster isolated network.

[0006] According to a first aspect of the present disclosure, a method for DDS interconnection in a container cluster isolated network is provided. Deploy and start the routing agent and the DDS application container agent; Listen for local DDS service discovery data through the DDS application container proxy; The routing agent receives DDS service discovery data reported by all DDS application container agents, builds an index based on the DDS service discovery data, performs data analysis in the index, and automatically establishes communication links between DDS application container agents. Interconnection is performed based on communication links.

[0007] According to a second aspect of the present disclosure, a DDS interconnection system under a container cluster isolated network is provided, comprising: The initialization module is used to deploy and start the routing agent and the DDS application container agent; The listening module is used to listen for local DDS service discovery data through the DDS application container proxy. The routing module is used to receive DDS service discovery data reported by all DDS application container agents through the routing agent, build an index based on the DDS service discovery data, perform data analysis in the index, and automatically establish communication links between DDS application container agents. Interoperability module, used to perform interconnection based on communication links.

[0008] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the method for DDS interconnection in a container cluster isolated network provided in the first aspect of the present disclosure.

[0009] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, having stored thereon computer program instructions that, when executed by a processor, implement the steps of the DDS interconnection method under a container cluster isolated network provided in the first aspect of the present disclosure.

[0010] According to a fifth aspect of the present disclosure, a vehicle is provided that stores a set of instructions, which are executed by the vehicle to implement the method for DDS interconnection under a container cluster isolated network provided in the first aspect of the present disclosure.

[0011] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: by deploying routing agents and DDS application container agents, DDS application containers can be interconnected in isolated networks without prior configuration of interoperability relationships. The deployment efficiency is high and it can be quickly and dynamically adapted, which can meet the flexible networking requirements of multiple projects and multiple simulation tasks.

[0012] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0014] Figure 1 This is a flowchart illustrating a DDS interconnection method under a container cluster isolated network according to an exemplary embodiment.

[0015] Figure 2 This is a block diagram illustrating an interconnection proxy scenario according to an exemplary embodiment.

[0016] Figure 3 This is a block diagram illustrating a DDS interconnection system under a container cluster isolated network according to an exemplary embodiment.

[0017] Figure 4 This is a block diagram of an electronic device according to an exemplary embodiment.

[0018] Figure 5 This is a block diagram of a vehicle according to an exemplary embodiment. Detailed Implementation

[0019] The exemplary embodiments will now be described in detail with reference to the accompanying drawings.

[0020] It should be noted that the relevant embodiments and accompanying drawings are only for describing and illustrating exemplary embodiments provided by this disclosure, and not all embodiments of this disclosure, nor should this disclosure be understood to be limited to the relevant exemplary embodiments.

[0021] It should be noted that the terms "first," "second," etc., used in this disclosure are only used to distinguish different steps, devices, or modules. These terms do not represent any specific technical meaning, nor do they indicate any order or interdependence between them.

[0022] It should be noted that the terms “a,” “a plurality of,” and “at least one” used in this disclosure are illustrative rather than restrictive. Unless otherwise expressly indicated in the context, they should be understood as “one or more.”

[0023] It should be noted that the term "and / or" used in this disclosure is used to describe the relationship between related objects, and generally indicates that there are at least three relationships. For example, A and / or B can at least indicate: the existence of A alone, the existence of both A and B, and the existence of B alone.

[0024] It should be noted that the various steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Unless otherwise specified, the scope of this disclosure is not limited by the order in which the steps are described in the relevant embodiments.

[0025] It should be noted that all actions involving the acquisition of signals, information, or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with authorization from the owner of the relevant device.

[0026] Technical Terminology Explanation DDS (Data Distribution Service): A data distribution service, a data-centric publish-subscribe communication framework, is a data communication middleware that provides low latency, high reliability, and scalability for core distributed real-time systems.

[0027] K8s (Kubernetes): An open-source container orchestration platform used to automate the deployment, scaling, and management of containerized applications.

[0028] Calico (Calico Network Plugin): A container network plugin based on the BGP protocol that provides network connectivity, network isolation, and other functions for Kubernetes clusters, and supports fine-grained network policy control.

[0029] Pod: The smallest unit of deployment and management in the Kubernetes platform.

[0030] DDS Domain: The core logical isolation unit in the DDS protocol, defining an independent communication namespace. DDS applications within the same domain can discover and communicate with each other, while applications in different domains are isolated by default.

[0031] Topic Name: DDS Topic. Defines the logical channel for data interaction between DDS applications. Only applications that have subscribed to the same topic can receive the corresponding data.

[0032] Exemplary methods Figure 1 This is a flowchart illustrating a DDS interconnection method under a container cluster isolated network according to an exemplary embodiment, such as... Figure 1 As shown, it includes the following steps.

[0033] In step S110, the routing agent and the DDS application container agent are deployed and started, specifically including: Each project often contains different tasks, and business requirements can be communicated within a project or between tasks in different projects. For example, container A1 and container A2 under project A communicate within the project, while container A1 under project A and container B2 under project B communicate across projects.

[0034] Establish independent Router Agents within the project or between different project tasks. The Router Agents are deployed in the project's dedicated Kubernetes namespace. The Router Agents are authorized to access across namespaces through the network security policy Calico. The Router Agents are deployed on a container orchestration platform for data forwarding and link management. Establish a corresponding DDS application container agent Client Agent for each DDS application container within the project or between different project tasks, and deploy the Client Agent and DDS application container in the same Pod container group to share the namespace; When the DDS application container starts, the corresponding DDS application container agent, the Client Agent, also starts. The Client Agent specifies the Router address of its routing agent. The Router address includes the IP address and port number. This address is a fixed configuration and can be exposed through a Kubernetes Service to ensure that the Router address remains unchanged. The above description uses the Kubernetes platform as an example of a container orchestration platform to more clearly and specifically illustrate this solution. However, the Kubernetes platform should not be used as a limitation on the scope of protection and application scenarios of this case.

[0035] The number of routing agents is determined based on the network scale. In general scenarios and embodiments of the present invention, one self-developed routing agent is set up. Preferably, for ultra-large-scale clusters such as distributed simulation and industrial control systems, such as 1000+ DDS nodes, multiple routers can be deployed to form a cluster, and the task application is assigned to the corresponding routing agent through a consistent hashing algorithm.

[0036] Consistent hashing can achieve uniform distribution. Specifically, it creates a virtual hash ring. Each routing agent calculates its own identifier's position on the ring using a hash function. Assuming there are N routing agents, they are distributed in N different positions on the ring. Preferably, virtual node technology is used to distribute the positions evenly. When a Client Agent needs to allocate a Router, it uses the same hash function to calculate the Client's identifier's position on the ring and searches for the first Router node clockwise for the corresponding allocation.

[0037] In step S120, the DDS application container proxy listens for local DDS service discovery data, specifically including: It is important to note that the DDS application container agent can listen to two types of data: DDS service discovery data and application data. DDS service discovery data is transmitted through DDS service discovery data packets, while application data is transmitted through Topic application data packets. DDS service discovery data contains the communication requirements of DDS application containers and is used for forwarding link construction, enabling business data interoperability after network formation.

[0038] Steps S120 to S130 focus on describing the link construction; Multi-threaded monitoring is used to listen to DDS service discovery data in all local DDS Domain communication domains, and to listen to DDS service discovery data in all domains from 0 to 233. Extract key information, including DDS Domain, Topic name, source IP address, destination IP address, and port, from the DDS service discovery data, and report the original DDS service discovery data and key information together to the routing agent.

[0039] In step S130, DDS service discovery data reported by all DDS application container proxies is received through the routing proxy. An index is built based on the DDS service discovery data, and data analysis is performed in the index to automatically establish communication links between DDS application container proxies. Specifically, this includes: The Router Agent receives data reported by all Clients and builds a global data index based on the received DDS service discovery data and key information. The DDS Domain communication domain, Topic name, source IP address, destination IP address, and port are used as the index dimensions for the global data index.

[0040] In the global data index, for the current DDS application container agent, retrieve all other DDS application container agents with the same DDS Domain communication domain and Topic name as the Client group, and establish communication links for the Client group.

[0041] In this embodiment of the invention, the global data index can be replaced by distributed shared storage, such as the Etcd real-time read / write data index; The global data index is a local global index, while the Etcd real-time read and write data indexing method involves the client directly writing the reported key information into Etcd, and the router querying the target client address from Etcd and forwarding the data. This method is suitable for large-scale cluster scenarios. Therefore, in this embodiment of the invention, if multiple routers are currently deployed to form a cluster, the Etcd real-time read and write data indexing method is automatically enabled, and multiple routers share the index data without the need for a synchronization mechanism, thereby improving the index access efficiency.

[0042] In this embodiment of the invention, establishing a communication link refers to establishing a virtual interaction relationship between DDS application container agents. That is, at this time, the current required node can be identified based on the index result, and communication can be achieved after the subsequent steps automatically form a network.

[0043] In step S140, interconnection is performed based on the communication link, specifically including: Interconnection and interoperability are achieved among client groups based on clearly defined virtual relationships; The routing proxy can also obtain DDS service discovery data and application data.

[0044] When the routing agent receives a DDS service discovery data packet, it forwards the DDS service discovery data packet to the client group. When the DDS application container agent receives the DDS service discovery data, it performs network formation through local UDP multicast to ensure that the local DDS application can receive the corresponding data, thereby realizing dynamic discovery of cross-container DDS. The DDS dynamic service discovery mechanism searches for communication brokers that need to be established in multicast data. It can forward the information to all clients in the same domain and then determine the needs through TOPIC subscription, thereby realizing networking with the client group.

[0045] Business data exchange is carried out after data is networked through service discovery. When the routing agent receives a Topic application data packet, it forwards the Topic application data packet to the Client group. When the DDS application container agent receives the DDS application data, it communicates business data through any of the TCP, UDP, or QUIC communication protocols. The QUIC communication protocol features connectionless and multiplexing characteristics, which can reduce forwarding latency and improve network adaptability. However, QUIC is a non-DDS standard transmission protocol, so transmission is achieved through protocol conversion proxies or bridging mechanisms when using QUIC.

[0046] After the DDS container completes dynamic discovery, it can communicate directly through the native protocol. The DDS application container agent ClientAgent only participates in the initial stage of service discovery and application data forwarding, and does not affect the efficiency of subsequent communication.

[0047] During subsequent interconnection, the routing agent and DDS application container agent can still receive both DDS service discovery data and application data. When the key information displayed by the communication requirements changes, the link will be automatically updated and the network will be re-established to ensure normal interconnection of application data.

[0048] The above technical solutions of the embodiments of the present invention will be illustrated with reference to the following accompanying drawings.

[0049] Figure 2 This is a block diagram illustrating an interconnection proxy scenario according to an exemplary embodiment, such as... Figure 2 As shown, this illustrates a DDS interconnection architecture based on dynamic router discovery within an isolated container cluster network. Figure 2 Deploy a Router Agent, assign a DDS Application Container Agent Client Agent to each DDS application container, and deploy the corresponding Client.

[0050] The Router Agent, as the core forwarding component, is deployed in an independent Pod. It has functions such as retrieval, automatic link network establishment, and data-directed forwarding, and supports access from multiple project clients. The Router Agent has a built-in automatic link establishment function, which automatically groups clients based on DDS Domain and Topic. That is, it automatically matches senders and receivers with the same service, forms links for clients in the same group to form a network, and requires no manual intervention. The Client Agent is a lightweight component that integrates functions such as data listening, local service discovery data reporting, remote service data discovery and reception, and local playback. It can be started with one click along with the DDS application container without complex configuration.

[0051] Examples of application scenarios applicable to the embodiments of the present invention are as follows: 1. Industrial simulation testing platform Large manufacturing enterprises build industrial simulation and testing platforms based on Kubernetes (K8s). Multiple R&D teams simultaneously conduct simulation tests on different products, such as autonomous driving simulation for automobiles and collaborative robot simulation. Each team's simulation task corresponds to an independent project, and it is necessary to maintain isolation between projects to avoid interference with simulation data. Each simulation task deploys an independent router. Team members launch the DDS simulation application on the same client. After specifying the router address, the system can automatically discover target nodes across teams and nodes, enabling simulation data interoperability.

[0052] 2. Multi-tenant cloud-native service platform The cloud service provides cloud-native DDS services to multiple tenants, each with an independent Kubernetes namespace. Tenant isolation is achieved through Calico. DDS applications within a tenant require flexible networking, potentially involving cross-node deployment. Some tenants may need to communicate with designated DDS nodes based on business collaboration, requiring both tenant isolation and support for large-scale deployment. Each tenant deploys an independent router, and inter-tenant communication only requires authorizing access permissions between routers. This enables dynamic discovery and communication of DDS applications across tenants and nodes, ensuring tenant isolation while enhancing collaboration flexibility and supporting large-scale tenant and node access.

[0053] 3. Single-node multi-project testing environment The R&D team built a multi-project DDS test environment on a single Docker environment server. Each project corresponds to an independent Docker container, ensuring isolation between projects to avoid interference with test data. Simultaneously, some test cases needed to achieve interoperability testing between DDS applications across projects, without requiring complex configuration. A lightweight router was deployed in each project. The DDS test application started with the client and specified the router address, enabling cross-project interoperability and dynamic discovery. This solved the problems of insufficient isolation in native Docker networking and severe interference in Host mode.

[0054] The above scenarios share common characteristics such as large scale, high dynamism, and unpredictability. For example, the composition of an industrial simulation test platform changes dynamically during simulation, such as with new algorithms or models. Multi-tenant cloud-native service platforms are large in scale, and the number and topology of DDS application containers change dynamically over time, with tenants potentially establishing temporary communication management at any time.

[0055] In summary, to address the existing problems, this invention proposes a DDS interconnection method under isolated container cluster networks. By deploying routing proxies and DDS application container proxies, and with built-in automatic indexing within the routing proxies, other DDS application container proxies with the same DDSDomain communication domain and Topic name are treated as a group of clients to be established. The method establishes the transmission link before transmitting application data, enabling interconnection of DDS application containers under isolated networks without prior configuration of interconnection relationships. It uses the QUIC communication protocol to improve data forwarding efficiency across network environments. The method offers high deployment efficiency and rapid dynamic adaptation, meeting the flexible networking needs of multiple projects and simulation tasks.

[0056] Exemplary System Figure 3 This is a block diagram of a DDS interconnection system under a container cluster isolated network, according to an exemplary embodiment. (Refer to...) Figure 3 The system 300 includes an initialization module 310, a monitoring module 320, a routing module 330, and an interconnection module 340.

[0057] Initialization module 310 is used to deploy and start the routing agent and the DDS application container agent, specifically for: Establish independent Router Agents within a project or between different project tasks, authorize the Router Agents to access across namespaces through network security policies, and deploy the Router Agents on a container orchestration platform; Establish a corresponding DDS application container agent Client Agent for each DDS application container within the project or between different project tasks, and deploy the Client Agent and DDS application container in the same Pod container group to share the namespace; When the DDS application container starts, the corresponding DDS application container agent Client Agent is started, and the Client Agent specifies the Router address of the routing agent to which it belongs.

[0058] Listening module 320 is used to listen for local DDS service discovery data through the DDS application container proxy, specifically for: The system employs multi-threaded monitoring of DDS service discovery data across all local DDS Domain communication domains. Key information, including the DDS Domain communication domain, Topic name, source IP address, destination IP address, and port, is extracted from the DDS service discovery data. The original DDS service discovery data and the key information are then jointly reported to the routing agent.

[0059] Routing module 330 is used to receive DDS service discovery data reported by all DDS application container proxies through the routing proxy, build an index based on the DDS service discovery data, perform data analysis in the index, and automatically establish communication links between DDS application container proxies. Specifically, it is used for: A global data index is established based on the received DDS service discovery data and key information; The DDS Domain communication domain, Topic name, source IP address, destination IP address, and port are used as the index dimensions for the global data index.

[0060] In the global data index, for the current DDS application container agent, retrieve all other DDS application container agents with the same DDS Domain communication domain and Topic name as the Client group, and establish communication links for the Client group.

[0061] Interoperability module 340 is used to perform interconnection and interoperability based on communication links, specifically for: When the routing agent receives the DDS service discovery data packet, it forwards the DDS service discovery data packet to the client group. When the DDS application container agent receives the DDS service discovery data, it performs network formation through local UDP multicast. When the routing agent receives a Topic application data packet, it forwards the Topic application data packet to the Client group. When the DDS application container agent receives the DDS application data, it communicates business data through any of the TCP, UDP, or QUIC communication protocols.

[0062] In summary, to address the existing problems, this invention presents a DDS interoperability system under an isolated container cluster network. By deploying routing proxies and DDS application container proxies, and with built-in automatic indexing within the routing proxies, other DDS application container proxies with the same DDSDomain communication domain and Topic name are treated as a group of clients to be established. The system first establishes the transmission link before transmitting application data, enabling DDS application containers to interconnect under isolated networks without the need for pre-configuration of interoperability relationships. It uses the QUIC communication protocol to improve data forwarding efficiency across network environments. With high deployment efficiency and rapid dynamic adaptation, it can meet the flexible networking needs of multiple projects and simulation tasks.

[0063] The above-described exemplary system is a system implementation corresponding to the exemplary method. The specific operation of each module can be understood based on the specific description of each step in the exemplary method, and will not be repeated here.

[0064] Exemplary electronic devices Figure 4 This is a block diagram illustrating an electronic device 400 according to an exemplary embodiment. The electronic device 400 may be a vehicle controller, an in-vehicle terminal, an in-vehicle computer, or other types of electronic devices.

[0065] Reference Figure 4 The electronic device 400 may include at least one processor 410 and a memory 420. The processor 410 can execute instructions stored in the memory 420. The processor 410 is communicatively connected to the memory 420 via a data bus. In addition to the memory 420, the processor 410 can also be communicatively connected to an input device 430, an output device 440, and a communication device 450 via the data bus.

[0066] Processor 410 can be any conventional processor, such as a commercially available CPU. Processors may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems-on-chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0067] The memory 420 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0068] In this embodiment of the present disclosure, the memory 420 stores executable instructions, and the processor 410 can read the executable instructions from the memory 420 and execute the instructions to implement all or part of the steps of the DDS interconnection method under the container cluster isolation network described in any of the exemplary embodiments above.

[0069] Exemplary computer-readable storage media In addition to the methods and systems described above, exemplary embodiments of this disclosure may also be computer program products or computer-readable storage media storing such computer program products. The computer product includes computer program instructions that can be executed by a processor to implement all or part of the steps described in any of the container cluster isolated network DDS interconnection methods in the exemplary embodiments described above.

[0070] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages, and scripting languages ​​(e.g., Python). The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0071] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: static random access memory (SRAM) having one or more electrically connected wires; electrically erasable programmable read-only memory (EEPROM); erasable programmable read-only memory (EPROM); programmable read-only memory (PROM); read-only memory (ROM); magnetic storage; flash memory; magnetic disk or optical disk; or any suitable combination thereof.

[0072] Exemplary vehicle Figure 5 This is a block diagram illustrating a vehicle 500 according to an exemplary embodiment. The vehicle 500 may be a gasoline vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicles.

[0073] Reference Figure 5 The vehicle 500 may include multiple subsystems, such as a drive system 510, a control system 520, a sensing system 530, a communication system 540, an information display system 550, and a computing processing system 560. The vehicle 500 may also include more or fewer subsystems, and each subsystem may include multiple components, which will not be described in detail here.

[0074] The drive system 510 includes components that provide power to the vehicle 500. These include, for example, an engine, an energy source, and a transmission.

[0075] The control system 520 includes components that provide control for the vehicle 500. These include, for example, vehicle control, cockpit equipment control, and driver assistance control.

[0076] The perception system 530 includes components that provide the vehicle 500 with perception of its surroundings. Examples include a vehicle positioning system, laser sensors, voice sensors, ultrasonic sensors, and camera equipment.

[0077] The communication system 540 includes components that provide communication connectivity for the vehicle 500. These may include, for example, mobile communication networks (e.g., 3G, 4G, 5G networks), WiFi, Bluetooth, and vehicle-to-everything (V2X) connectivity.

[0078] The information display system 550 includes components that provide various information displays for the vehicle 500. These include, for example, vehicle information displays, navigation information displays, and entertainment information displays.

[0079] The computing processing system 560 includes components that provide data computing and processing capabilities for the vehicle 500. The computing processing system 560 may include at least one processor 561 and a memory 562. The processor 561 can execute instructions stored in the memory 562.

[0080] Processor 561 can be any conventional processor, such as a commercially available CPU. Processors may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems-on-chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0081] The memory 562 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0082] In this embodiment of the disclosure, a set of instructions is stored in the memory 562, and the processor 561 can execute the set of instructions to implement all or part of the steps of the DDS interconnection method under the container cluster isolation network described in any of the exemplary embodiments above.

[0083] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of this disclosure. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0084] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for DDS interconnection and interoperability under a container cluster isolated network, characterized in that, The method specifically includes: Deploy and start the routing agent and the DDS application container agent; The DDS application container agent listens for local DDS service discovery data. The routing proxy receives DDS service discovery data reported by all DDS application container proxies, builds an index based on the DDS service discovery data, performs data analysis in the index, and automatically establishes communication links between DDS application container proxies. Interconnection is performed based on the communication link.

2. The method according to claim 1, characterized in that, The deployment and startup of the routing agent and the DDS application container agent specifically include: Establish independent Router Agents within the project or between different project tasks, authorize the Router Agents to access across namespaces through network security policies, and deploy the Router Agents on a container orchestration platform; Establish a corresponding DDS application container agent Client Agent for each DDS application container within the project or between different project tasks, and deploy the Client Agent and the DDS application container in the same Pod container group and share the namespace. When the DDS application container starts, the corresponding DDS application container agent Client Agent is started, and the Client Agent specifies the Router address of the routing agent to which it belongs.

3. The method according to claim 1, characterized in that, The specific steps of listening to local DDS service discovery data through the DDS application container proxy include: The system employs multi-threaded monitoring of DDS service discovery data across all local DDS Domain communication domains. Key information, including the DDS Domain communication domain, Topic name, source IP address, destination IP address, and port, is extracted from the DDS service discovery data. The original DDS service discovery data and the key information are then jointly reported to the routing agent.

4. The method according to claim 3, characterized in that, The step of receiving DDS service discovery data reported by all DDS application container proxies through the routing proxy and building an index based on the DDS service discovery data specifically includes: A global data index is established based on the received DDS service discovery data and the key information; The DDS Domain communication domain, the Topic name, the source IP address, the destination IP address, and the port are used as the index dimensions of the global data index.

5. The method according to claim 4, characterized in that, The step of performing data analysis in the index and automatically establishing communication links between DDS application container agents specifically includes: In the global data index, for the current DDS application container agent, all other DDS application container agents with the same DDS Domain communication domain and Topic name are retrieved and treated as a Client group, and a communication link is established for the Client group.

6. The method according to claim 5, characterized in that, The interconnection and interoperability based on the communication link specifically includes: When the routing agent receives the DDS service discovery data packet, it forwards the DDS service discovery data packet to the Client group. When the DDS application container agent receives the DDS service discovery data, it performs networking through local UDP multicast. When the routing agent receives a Topic application data packet, it forwards the Topic application data packet to the Client group. When the DDS application container agent receives the DDS application data, it performs business data communication through any one of the TCP, UDP, or QUIC communication protocols.

7. A DDS interconnection system under a container cluster isolated network, used in the DDS interconnection method under a container cluster isolated network as described in any one of claims 1 to 6, characterized in that, The system specifically includes: The initialization module is used to deploy and start the routing agent and the DDS application container agent; The listening module is used to listen for local DDS service discovery data through the DDS application container proxy. The routing module is used to receive DDS service discovery data reported by all DDS application container agents through the routing agent, build an index based on the DDS service discovery data, perform data analysis in the index, and automatically establish communication links between DDS application container agents. Interconnection module, used to perform interconnection based on the communication link.

8. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the DDS interconnection method under a container cluster isolated network as described in any one of claims 1-6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the steps of the DDS interconnection method under a container cluster isolated network as described in any of claims 1-6.

10. A vehicle, characterized in that, A set of instructions is stored, which is executed by the vehicle to implement the DDS interconnection method under a container cluster isolated network as described in any one of claims 1-6.

Images