1. Project Overview¶
DDS Router is a cross-platform non-graphical application developed by eProsima and powered by Fast DDS that allows users to create a communication bridge that connects two DDS networks that otherwise would be isolated. The main use case of the DDS Router is to communicate two DDS networks that are physically or virtually separated and belong to different LANs, allowing the entities of each network to publish and subscribe to local and remote topics indistinctly.
DDS Router is an application that internally runs Participants, which are an abstraction of DDS DomainParticipants. Each one of these Participants is an communication interface, a “door” to a specific DDS network configuration. These Participants allow the application to connect to different DDS networks at the same time. Every time one of these Participants receives a message from the DDS network to which they are connected, they will forward the data and the source of this message through the other Participants. The DDS Router configuration and the topics in which it operates depends on the initial DDS Router configuration.
The following schema represents a DDS Router local use case. This scenario presents different DDS networks that are isolated one to each other due to the Transport Protocol (UDP, TCP, etc.), the Discovery Protocol (Simple, Discovery Server, etc.) or the DDS Domain Id used by each DDS entity. Configuring the DDS Router to have 4 different Participants, each of them configured for one isolated DDS network, will create internally 4 Participants. All the data that arrives to one of the Participants will be forwarded through the others, allowing all the machines to connect to each other independently of their different configurations. This data transmission will be accomplished without copying the data, as all participants will share the pointer to the allocated data, successfully achieving a zero-copy communication mechanism.
1.1. WAN Communication¶
Achieving a WAN communication of two networks that work in different LANs requires a running DDS Router application on each LAN. The DDS Router deployed will communicate with each network using DDS over WAN, and it will reroute every message received in LAN to the remote DDS Router. Once the remote Router receives data, it will transmit it to the local networks to which it is connected. This way, both DDS networks will behave as if they belonged to the same LAN.
Another important feature is that WAN communications are not limited to a single pair of DDS Router. The WAN communication may be performed using the eProsima Discovery Server discovery mechanism (dynamic discovery over non-multicast networks). Thus, any DDS Router connected to the same Discovery Servers will work as a standard DDS node, publishing and subscribing on the shared DDS topics. This create an unlimited and highly scalable decentralized and distributed DDS network.
1.2. Usage Description¶
The DDS Router is a terminal (non-graphical) application that creates the DDS bridge as long as it is running. The configuration in YAML format is very intuitive and human-readable. The whole application has been thought to be user-friendly, following a user-oriented design.
RUN: In order to run a DDS Router application, just a YAML configuration file is required with the specific configurations (see section DDS Router Configuration to check how to configure a DDS Router and see section Application Arguments to check the application supported arguments).
INTERACT: Once the DDS Router application is running, the topics involved in this communication can be changed in runtime by just changing the YAML configuration file (see section Reload Topics for more details about re-configuring a running DDS Router).
STOP: To stop the DDS Router just send a ^C signal to the process, and it will gracefully close the whole application (see section Close Application for more details on how to close the application).
1.3. Common Use Cases¶
The different cases where the DDS Router could be applied are very varied, and would increase as new Participant Kinds will be added in future releases. These are most common use cases so far:
Communicating two different DDS Domain Ids
Communicating ROS 2 Discovery Server executions