7. Practical Uses with RTI Applications

7.1. Debugging Discovery Problems

Tip

Start capturing data before running your applications. This will ensure you capture all the discovery packets.

While many object-discovery problems are difficult to diagnose, others are quite obvious once you use the right diagnostic tools. By inspecting all RTPS packets with Wireshark, you may be able to narrow the problem down to one of the following:

• The participants are not discovering each other.

  In this case, you will see periodic sending of DATA packets, but no response from the other host that is not being discovered.

• The participants have discovered each other, but their contained readers/writers are not getting hooked up correctly.

  In this case, you may see HEARTBEAT and ACKNACK packets for the reserved metatraffic data representing the reader and writer from one participant to another, but the other participant is not responding back in accordance to the RTPS protocol.

• The objects have all discovered each other, but the writer is not sending user data.

  In this case, you will see the discovery protocol complete successfully, but not see DATA packets containing user data from the writer. When a participant containing a writer sends metatraffic data to other participants, and those other participants respond with ACKNACK packets to acknowledge those discovery packets, all you can say is that the declaration for that writer was received by all participants in the system. But just because a participant is writing DATA packets does not necessarily mean it is writing your application’s user data. Connext DDS also uses DATA packets to propagate internal object information. When in doubt, check the traffic_nature field in the decoded packet to see how the packet is being used.

  A subscriber reciprocally declares its reader object with another DATA packet to all concerned participants. This happens before the writer application starts publishing user data. Connext DDS uses separate builtin objects to announce and discover readers vs. writers, so it’s important to check the writerEntityId of the DATA packet to confirm that the participants in question have discovered the reader/writer correctly.

  Lastly, it’s important to check whether the topic and type declared in the metatraffic data of the reader matches that in the metatraffic data of the writer. Assuming that neither party is deliberately ignoring certain Entities (Participants, Topics, DataReaders, DataWriters), if all these were acknowledged (with ACKNACK packets), the reader participant should at this point be ready to accept user data from the writer and the writer will send the data to the reader. Exactly when the data will appear on the wire will depend on when the writer writes the next sample, as well as the QoS of both the reader and writer.

• The writer is writing your data, but the reader is not able to access that data when it calls read() or take().

  In this case, you should check your QoS settings. Compare the writer’s QoS against the reader’s. Perhaps the minimum_separation in the TimeBasedFilter QosPolicy of the reader is inadvertently filtering out received issues.

  Once a writer is writing user data to a reader, the initial discovery phase is over. But there can be an “anti-discovery” problem: depending on the Liveliness QosPolicy, Connext DDS may purge a remote entity that it considers to be stale. Regardless of what kind of liveliness setting you use, the main idea is to ensure that your participant and its entities renew their liveliness (automatically or manually) within the declared duration. A classic symptom of communication ceasing due to a liveliness expiration is that a participant stops sending its periodic participant DATA packets. (See the RTI Connext DDS Core Libraries User’s Manual or the Connext DDS API Reference online documentation for information about the Liveliness QosPolicy.)

Tip

Connext DDS can log more detailed information about what it is doing if you use a higher verbosity setting. See the Troubleshooting chapter in the RTI Connext DDS Core Libraries User’s Manual for information on setting verbosity.

7.2. Visualizing Your System

Once your applications are communicating, tuning Connext DDS to maximize performance may require an in-depth understanding of your network. A visual understanding of Connext DDS network usage is very valuable for system tuning.

For example, you may be sending data as fast as Connext DDS will allow and wonder why the reader cannot keep up. Wireshark itself offers many statistical analysis tools under the Statistics menu. As the following figures show, you can see how many RTPS packets are being sent, what portion of total network bandwidth the RTPS packets are taking up, which hosts are talking to others, and how much bandwidth is being used to do so.

In our “sending too fast” example, you may find that the RTPS packets are being dropped at a host with a relatively slow reader. In some extreme cases, even Wireshark may not see all the packets sent, because the network card on the sniffing machine itself dropped them.

Figure 7.1 UDP Conversations

Figure 7.2 I/O Graph

Figure 7.3 Protocol Hierarchy

7.3. Providing Information to RTI Support

If you ever need to contact RTI Support for an issue related to Connext DDS, the captured packets will help RTI Support diagnose the problem faster (especially when accompanied by a Connext DDS log created with a high verbosity setting). See the Troubleshooting chapter in the RTI Connext DDS Core Libraries User’s Manual for more on setting verbosity.