Why does DDS produce ICMP Destination Unreachable messages?

1 post / 0 new
Howard's picture
Last seen: 1 day 3 hours ago
Joined: 11/29/2012
Posts: 177
Why does DDS produce ICMP Destination Unreachable messages?

Just answered this for a support customer who asked "why does RTI Connext send many ICMP Destination Unreachable UDP packets?


DDS may send packets to UDP ports on other hosts that do not have applications attached (which will cause the Destination Unreachable ICMP response) in the following situations:

1) Use of "Initial Peers" list, DDS will send a Participant Liveliness discovery packet periodically (by default 30 seconds) to each host in the initial peers list.  For each host, it will send 5 packets to 5 different UDP port numbers (by default).  If there are no DDS participants listening on those sockets, then the Destination Unreachable will happen.


then every 30 seconds, DDS will send 5 UDP packets to and 5 UDP packets to, each to a different UDP port.

The 5 packet is controlled by the syntax


for example

[email protected]

by default, if an address in the NDDS_DISCOVERY_PEERS list does not have the "<x>@" prefix, <x> is default to be 4.

How DDS uses this <x> value is to determine how many possible DDS participants are on the host "w.x.y.z" to try to contact.  The value "x" is the maximum participant ID....participant ID's start at 0.

So  [email protected], tells DDS to contact the first participant on only.  Where as [email protected], tells DDS to contact the first and second participant.

So by default [email protected], says to contact the first five participants.  DDS does this by sending an unicast, UDP packet to a socket for each participant.  If the participant exists, it will get the packet and answer back.  If it does not, the IP layer will respond with an ICMP Destination Unreachable packet.

2) When existing applications/participants die unexpectedly.  For a period of time (default 100 seconds), after an application dies without notifying other applications, the remaining applications all think that the original application is still alive.  If that is the case, any data sent to the dead application may result in an ICMP Destination Unreachable packet since there is no longer an application listening to the socket at the original address/port.  Eventually, when the dead application is timed out, existing applications will stop sending data to the dead application, and ICMP messages due to this should stop...however, it could be that the existing applications are still sending Participant Liveliness discovery messages in hopes that the dead application is restarted (this would be the case described above).