7. Discovery

Prerequisites	Publish/Subscribe Repository cloned from GitHub here
Time to complete	30 minutes
Concepts covered in this module	Discovery Domains DomainParticipants

Before we talk about discovery, we should talk about the DomainParticipant entity that you create when you create your DDS application. If you walk through all of the code we have used so far, you will see that creating a DomainParticipant is nearly the first step our applications take, and a DomainParticipant is used to create all the Publishers, Subscribers (and ultimately the DataWriters and DataReaders) your application uses. When you create a DomainParticipant, it starts the discovery process.

Definition

Discovery is the process in which DomainParticipants find out about other DomainParticipants and exchange information about their DataWriters and DataReaders. When a DomainParticipant learns about the DataWriters and DataReaders belonging to another DomainParticipant, it analyzes whether they have matching Topics, datatypes, and compatible QoS with its own DataReaders and DataWriters. If a DataWriter and DataReader are determined to be compatible, they communicate. By default, discovery starts as soon as you create a DomainParticipant in your application.

Discovery is an ongoing process—whenever DataWriters and DataReaders are created, modified, or deleted, their DomainParticipant sends that information to the other DomainParticipants in the system. In addition, DomainParticipants maintain their liveliness in the system using periodic discovery announcements.

Figure 7.1 Simplified discovery diagram. All DomainParticipants in your system will send discovery information at startup (by default), and they will all determine whether they have DataWriters and DataReaders that match. Any time you create a new DataWriter or DataReader in your application, its DomainParticipant will announce the existence of the new DataWriter or DataReader to all the DomainParticipants it has discovered.

Tip

Notice that creating a DomainParticipant means creating discovery traffic over the network. This is one reason we recommend you create as few DomainParticipants as possible, according to your system design. Often there is only one DomainParticipant per application with multiple DataReaders and DataWriters underneath it, but that may depend on the number of domains you need.

7.1. Domains

When you create a DomainParticipant, you pass it a positive integer value that represents the DDS domain it should communicate in. A DDS domain is a logical DDS network. If you create DomainParticipants in different domains, they will not communicate with each other.

Tip

Using multiple domains is not a way to secure your DDS system, but it is a way to keep DDS applications that should not communicate from interfering with each other or from using unnecessary resources storing information about DataWriters or DataReaders they will never communicate with. For information on securing a DDS system, see the RTI Security Plugins Getting Started Guide.

There are many reasons for creating multiple DDS domains. For example:

• You need to run a production system and a test system on the same network, and you do not want them to communicate with each other.

• You have multiple developers running tests, and you don’t want them to collide with each other

• You have different subsystems in your overall system, and they don’t need to communicate with each other.

• You are using Security Plugins, and you want to support both a secure domain and a non-secure domain in your system.

Sometimes, you may have an application that needs to interact in multiple DDS domains. It does that by creating a DomainParticipant for each domain it wants to communicate in.

Figure 7.2 DomainParticipants in different domains do not send announcements to each other.

7.2. Initial Peers

The initial peers define where a DomainParticipant sends its first announcements. These peers are a list of addresses (in string format) that a DomainParticipant should attempt to contact. Connext can support transports other than UDP, so these strings use a format called a “locator” that allows you to specify which transport as well as the address. The details on how to format locator strings can be found in Discovered RTPS Locators and Changes with IP Mobility, in the RTI Connext DDS Core Libraries User’s Manual. Most of the time you will be specifying locators that look like normal host names and IP addresses.

By default, a DomainParticipant sends its announcements to:

• A multicast IP address with a port associated with the domain the participant is communicating in.

• Loopback IP address with ports associated with the domain the participant is communicating in.

• A shared memory locator with an ID associated with the domain the participant is communicating in.

If you need to change the initial peers your DomainParticipants contact, you can do that a few different ways, but the easiest way is in the XML configuration file:

<qos_library>
    <qos_profile name="DefaultProfile">
        <domain_participant_qos>
            <discovery>
                <initial_peers>
                    <!-- Add an element for each machine you want to communicate with -->
                    <element>IP address of machine to contact</element>
                </initial_peers>
            </discovery>
        </domain_participant_qos>
    </qos_profile>
</qos_library>

7.3. Hands-On 1: Troubleshooting Discovery

Discovery may not work for a number of reasons. The most common reasons for discovery not working (or appearing not to work) are:

• A firewall is blocking some or all DDS traffic.

• There is a router in your network that is not allowing multicast traffic through.

• Discovery is working, but your Topic names are misconfigured.

• Discovery is working, but your QoS profiles are misconfigured.

To troubleshoot whether there is DDS communication going between applications, we will use the rtiddsping utility. This is a simple utility that sends ping messages over DDS from a DataWriter to a DataReader, and can help determine whether an issue is with discovery or with misconfiguration. This is more interesting when run on multiple machines, but you can do this hands-on on a single machine to understand how to do this simple troubleshooting step.

1. In one terminal, run rtiddsping:

   LinuxmacOSWindows

   $ <NDDSHOME>/bin/rtiddsping
   

2. In a second terminal, run rtiddsping with the -subscriber parameter:

   LinuxmacOSWindows

   $ <NDDSHOME>/bin/rtiddsping -subscriber
   

   After you start both applications, you should see output similar to the following in the rtiddsping publishing application:

   RTI Connext DDS Ping built with DDS version: ...
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Sending data... value: 0000000
   Found 1 additional ping subscriber(s).
   Current subscriber tally is: 1
   Sending data... value: 0000001
   Sending data... value: 0000002
   Sending data... value: 0000003
   Sending data... value: 0000004
   Sending data... value: 0000005
   Sending data... value: 0000006
   

   You should see output similar to the following in the rtiddsping subscribing application:

   RTI Connext DDS Ping built with DDS version: 6.1.0 (Core: 1.9a.00, C:
   1.9a.00, C++: 1.9a.00)
   Copyright 2012 Real-Time Innovations, Inc.
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   rtiddsping is listening for data, press CTRL+C to stop it.
   Found 1 additional ping publishers(s).
   Current publisher tally is: 1
   Found 1 additional alive ping publishers(s).
   Current alive publisher tally is: 1
   rtiddsping, issue received: 0000001
   Detected Missed Sample(s) current: 1 cumulative: 1 (50.0)%
   rtiddsping, issue received: 0000002
   rtiddsping, issue received: 0000003
   rtiddsping, issue received: 0000004
   rtiddsping, issue received: 0000005
   rtiddsping, issue received: 0000006
   

   If you do not see “issue received” messages in the subscribing rtiddsping application, there is likely an issue with a firewall or with your network. Now, try running rtiddsping with the option -peer. Specify the IP address of the machine where you are running the other rtiddsping application. This will help you determine whether there is an issue with multicast (perhaps due to a router between your machines). If communication occurs when you specify a peer, it is likely that there is no multicast available between your machines. This means that you may need to specify initial peers when running your applications.

For further troubleshooting steps, see this HOWTO article on the RTI community site: HOWTO Do Basic Debugging for System-Level DDS.

7.4. Hands-On 2: Start Applications in Different Domains

All of the applications we have built so far can take a parameter to start in a different domain than the default. Go back to any one of the previous examples, and start one of the applications with -d 1. Notice that it doesn’t communicate with applications that are not in the same domain.

For example:

1. Start two applications.

   In the 6_content_filters/csharp/ directory, type the following:

   $ dotnet run -p MonitoringCtrlApplication -- --domain-id 1
   
   $ dotnet run -p TemperingApplication -- --domain-id 0
   

   Notice that the two applications do not communicate, because they are in different domains.
   
   

2. Open Admin Console and see that there are two domains in your system: domain 0 and domain 1. You can see that the ChocolateLotState and ChocolateTemperature Topics exist in both domains.

   

   Click on domain 0.

   You can see which DataWriters and DataReaders are communicating within domain 0. For example, you can see there are no DataReaders and one DataWriter of the ChocolateTemperature Topic:

   

7.5. Next Steps

Congratulations! You have learned the basics of discovery, domains, and initial peers. You have also learned about one of the utilities that can help you troubleshoot discovery issues. For more details on discovery, see Discovery, in the RTI Connext Core Libraries User’s Manual