How will DDS messages choose the link?

[guoyanzhang920817]

I have the following scenario: I am using an ARM processor with two network interfaces. One interface, eth1, has been modified to connect in a MAC-to-MAC manner to an MCU on the same circuit board, and the network works normally. The other interface, eth0, faces outward and may sometimes not be connected to a network cable. If I use the following configuration, will messages reliably go through eth0 when I plug in the network cable?

1<?xml version="1.0" encoding="utf-8"?>
 2<CycloneDDS
 3  xmlns="https://cdds.io/config"
 4  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 5  xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd"
 6>
 7  <Domain Id="any">
 8    <General>
 9      <Interfaces>
10        <NetworkInterface autodetermine="true" priority="default"
11        multicast="default" />
12      </Interfaces>
13      <AllowMulticast>default</AllowMulticast>
14      <MaxMessageSize>65500B</MaxMessageSize>
15    </General>
16    <Tracing>
17      <Verbosity>config</Verbosity>
18      <OutputFile>
19        ${HOME}/dds/log/cdds.log.${CYCLONEDDS_PID}
20      </OutputFile>
21    </Tracing>
22  </Domain>
23</CycloneDDS>

[guoyanzhang920817]

@eboasson Please help take a look at this problem, thank you.

[guoyanzhang920817]

I am currently using the following cyclonedds.xml in my environment. Will there be any issues if eth0 is not connected to a network cable?

<?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="0">
        <General>
            <Interfaces>
                <!--NetworkInterface name="eth0" priority="default" multicast="true" /-->
                <NetworkInterface autodetermine="true" priority="default" multicast="default" />
            </Interfaces>
            <AllowMulticast>spdp</AllowMulticast>
            <MaxMessageSize>65500B</MaxMessageSize>
            <DontRoute>true</DontRoute>
        </General>
        <Discovery>
            <EnableTopicDiscoveryEndpoints>true</EnableTopicDiscoveryEndpoints>
        </Discovery>
        <Internal>
            <Watermarks>
                <WhcHigh>500kB</WhcHigh>
            </Watermarks>
        </Internal>
    </Domain>
</CycloneDDS>

[eboasson]

Hi @guoyanzhang920817, Cyclone (still) the network interfaces that were selected at start-up, it doesn't monitor for interfaces that get added or removed. You can tell it to use eth0, but then eth0 must be available when it starts (if you tell it to use a network interface that isn't available, it refuses to start). It then continues to try to use it, even if the cable gets disconnected.

What it definitely won't do yet is use eth0 if available, and eth1 otherwise. It would be really nice if it could do that ... It is not even very hard to make it work¹ but that work hasn't been done.

Footnotes

1. Monitoring the set of network interfaces is not so difficult, the protocol supports communication address changes, etc. ↩

[guoyanzhang920817]

hi @eboasson ,
“It then continues to try to use it, even if the cable gets disconnected.” I understand this sentence to mean that if the device running the DDS program is connected to an external PC through eth0 when starting up, I looked at the cyclonedds log and it selected eth0. However, in my actual test here, after disconnecting the external PC, the device running the DDS program became abnormal. What's going on? So now I add the network card eth0 to a Linux bridge (bridge), and then DDS selects bridge communication. What are the risks of adopting such a plan?

When my device starts without connecting to an external PC, it chooses eth1 communication. After the device starts, I connect to the PC through eth0, and the PC cannot receive messages unless the DDS process is restarted. Of course, adding eth0 to the Linux bridge as I mentioned above is also a solution.