Deploying DDS Over WAN

In this section we are going to discuss how we can deploy Cyclone DDS over WAN. We can think of many interesting use cases in which we would like our DDS applications to be able to communicate with each other across the wider network. Although many of the commercial DDS implementations include extensive documentation on how to configure the DDS library through a .xml configuration file in order for applications to be able to communicate over the wider network, the Cyclone DDS documentation is still lacking the explanation required for us to implement such a scenario. Furthermore, some features are still not implemented in Cyclone DDS since there is no official release of this library. As a result, performing the across-network discovery, which is the main issue in our case, can prove quite difficult without utilizing some sort of common networking method.

In order to make sure that both remote nodes, which we wanted to connect, could discover each other it was decided to create a VPN network using just a simple online service. This VPN service focuses on IoT lightweight networking solutions. By connecting both nodes (in this case 2 Raspberry Pis with different internet connections) to this VPN network we could move to configuring our discovery protocol. The discovery can be done in a similar manner to the way we choose our DDS network interface, namely through the same cyclonedds.xml file. First, we find the IPv6 addresses provided by our VPN network to each individual node and we add them in our configuration by adding the following block.

<Discovery>
    <Peers>
        <Peer address="[IPV6-address of local machine]"/>
        <Peer address="[IPV6-address of remote machine]"/>
    </Peers>
    <ParticipantIndex>auto</ParticipantIndex>
</Discovery>

We add both IPv6 address to make sure that our configuration file can actually link our local machine to the remote. We can also add the IPv4 addresses, but Cyclone DDS does not allow IPv4 and IPv6 address mixing. Finally, we disable multicast since it is not supported by the VPN service and add all these blocks to our final configuration file.

<?xml version="1.0" encoding="UTF-8" ?>
<CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">
    <Domain id="any">
        <General>
            <NetworkInterfaceAddress>auto</NetworkInterfaceAddress>
            <AllowMulticast>false</AllowMulticast>
            <MaxMessageSize>65500B</MaxMessageSize>
        <FragmentSize>4000B</FragmentSize>
        <Transport>udp6</Transport>
        </General>
    <Discovery>
        <Peers>
            <Peer address="[IPV6-address]"/>
            <Peer address="[IPV6-address]"/>
        </Peers>
        <ParticipantIndex>auto</ParticipantIndex>
    </Discovery>
        <Internal>
            <Watermarks>
                <WhcHigh>500kB</WhcHigh>
            </Watermarks>
        </Internal>
        <Tracing>
            <Verbosity>severe</Verbosity>
            <OutputFile>stdout</OutputFile>
        </Tracing>
    </Domain>
</CycloneDDS>

An important conclusion that was drawn from the WAN experiment was that we need to add softer QoS constraints into our application in order for the communication to function properly. For example, poc3 of the Matrix Board Communication demonstrator does not function consistently well, mainly due to the fact that the communication is extremely fast and expects that the samples require deletion after a few milliseconds. In the WAN case, those milliseconds are not enough for the receiving node to actually read the message. In all other demonstrators where the communication is much slower this issue was not noticed. In conclusion, adding such functionality requires the developer to re-think his DDS timing constraints and add more relaxed QoS standards.