Description of the issue

When running any combination of Vortex DDS products using DDSI protocol on UDP multicast, communication sets up as expected at applications startup, but stops 10 seconds after startup.

• In Vortex Café logs, the following message appears at INFO level :

Duration lease expired for remote Participant XXXXXXXX.XXXXXXXX.XXXXXXXX – remove it

The origin of the issue : Bad multicast support

These  kinds of problems are most often due to multicast communications issues. Multicast packets can flow from one application to the other but not in reverse.

Multicast problems are most often noticed in these situations:

• Using incorrect network interfaces.
• When using multicast in WiFi environments (A lot of WiFi routers don’t support multicast communications correctly).
• Using multicast on Android.

The Simple Participant Discovery Protocol

Each Participant in the domain periodically sends RTPS messages on the network to announce itself to other Participants and assert it’s presence. These messages are sent to a predefined list of locators but in particular to a standard multicast IP address and UDP port. In each of these messages is a lease duration. This indicates how long a Participant should be considered to be alive after this announcement.

In this case, as multicast does not flow correctly from one Participant to the other, the second one eventually considers the first one as dead and stops communicating with it. As most of Vortex products have a default lease duration of around 10 seconds, communication breaks after 10 seconds.

See DDS Interoperability Wire Protocol Specification section 8.5.3 for more details on the Simple Participant Discovery Protocol.

Why did communication take place at the first place if multicast is broken ?

As suggested by the DDS Interoperability Wire Protocol Specification and to minimize start-up delays, all Vortex DDSI implementations send an additional SPDP message on unicast in response to receiving an SPDP message from a previously unknown Participant. As multicast correctly flows from one of the Participants to the other and the unicast response also correctly reaches the first one, both Participants indeed discover each other at the first place.

Fixing the issue

• Make sure that all applications are configured to use the correct network interface. Both VortexOpenSplice and VortexLite implementations indeed receive multicast packets even if not using the correct interface. But the multicast packets they send do not reach the other end.
• Fix the multicast behaviour at transport level.
• Configure the involved vortex products to only use unicast communications.
  • VortexOpenSplice and VortexLite :
    • Disable multicast :

      • <DDSI2Service name="ddsi2">
           <General>
              <AllowMulticast>false</AllowMulticast>
           </General>
        </DDSI2Service>

    • Configure peers :

      • <DDSI2Service name="ddsi2">
           <Discovery>
              <Peers>
                 <Peer Address="10.10.10.10:7400"/>
              </Peers>
           </Discovery>
        </DDSI2Service>

  • VortexCafé :
    • Disable multicast :

      •  ddsi.discovery.udp.allowMulticast=false

    • Configure peers :

      •  ddsi.discovery.udp.peers=10.10.10.10:7400