.. include:: vars.rst .. _section-tutorials: Tutorials ************ .. note:: The commands shown in these examples are for the ``x64Linux3gcc5.4.0`` architecture. For simplicity, all the examples assume that all the applications run on the same host machine and the environment variable ``NDDSHOME`` is set to point to your *RTI Connext DDS* installation. .. note:: Some of the examples require OpenSSL libraries and you must ensure they are present in your library path before starting the applications. Example commands assume the existence of the environment variable ``OPENSSLHOMELIB`` set to the directory that contains the OpenSSL libraries. If you use the OpenSSL libraries distributed by RTI, the libraries directory will have the following locations: - On UNIX-based systems: ````//release/lib - On Windows systems: ````\\\\release\\bin .. _section-example-hw-simple: Example: Using a Builtin UDP Transport ====================================== This example illustrates the basic functionality of |CDS|. It shows how *Connext DDS* applications discover each other through an instance of |CDS|. .. _section-example-udp-transport-setup: Setup ----- The first step is to have two *Connext DDS* applications that can talk to each other. For that, you can use an IDL file of your choice and run *rtiddsgen* to generate the example. For instance, you can create a file named ``CDSHelloWorld.idl`` with the following content: .. code-block:: c struct CDSHelloWorld { long count; }; Generate the publisher and subscriber examples by running the following command (you can replace ``C++03`` with any other supported language of your choice): .. code-block:: bash $NDDHSOME/bin/rtiddsgen -language C++03 -example x64Linux3gcc5.4.0 \ -ppDisable CDSHelloWorld.idl Modify ``CDSHelloWorld_publisher.cxx`` to increase the ``count`` field each time the sample is written. For instance, you can add the following line in the main writing loop: .. code-block:: c++ sample.count(count); To compile the generated code, run: .. code-block:: bash make -f makefile_CDSHelloWorld_x64Linux3gcc5.4.0 You should have two executables, ``CDSHelloWorld_publisher`` and ``CDSHelloWorld_subscriber.`` Now you can run the examples to make sure everything is fine. You need to run the examples from the directory that contains the generated ``USER_QOS_PROFILES.xml``. From one terminal run: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_publisher Writing CDSHelloWorld, count 0 Writing CDSHelloWorld, count 1 ... From a different terminal, run: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber CDSHelloWorld subscriber sleeping for 4 sec... [count: 3] CDSHelloWorld subscriber sleeping for 4 sec... [count: 4] ... You should see that the subscriber application receives the samples generated by the publisher application. This occurs because by default, |DPs| enable multicast. That is, participant announcements are automatically sent to a multicast destination. Disable Multicast ----------------- Stop the applications and disable multicast. For that, you can specify an empty list of initial peers by setting the environment as follows: .. code-block:: xml export NDDS_DISCOVERY_PEERS= Now if you run the publisher and subscriber applications again, notice that the subscriber does not receive any samples: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber CDSHelloWorld subscriber sleeping for 4 sec... CDSHelloWorld subscriber sleeping for 4 sec... CDSHelloWorld subscriber sleeping for 4 sec... ... You can stop the applications now. |CDS_Heading| in Action ----------------------- To make the applications communicate, we need to run |CDS|. From a terminal, run the following command: .. code-block:: bash $NDDSHOME/bin/rticlouddiscoveryservice This command will run |CDS| with the builtin configuration that listens on port 7400 over the UDP transport. Re-run the publisher and subscriber applications, but this time set the initial peers to talk to |CDS| (see :numref:`section-domain-list-rtps-peer-descriptor`). For that, you can set the environment from the application terminal as follows: .. code-block:: bash export NDDS_DISCOVERY_PEERS=rtps@localhost:7400 Now run the applications and verify that the subscriber receives samples. You can also stop |CDS| and see how the applications **continue communicating**. In addition, you can start more publishers and subscribers, then see how they all discover each other and communicate. Example: Using a Custom Listening Port ====================================== This example extends :ref:`section-example-hw-simple` to run |CDS| on a custom listening port over UDP. For that, you can run |CDS| as follows: .. code-block:: bash $NDDSHOME/bin/rticlouddiscoveryservice -transport where ```` represents the port number you want to use. This example will use ``10000``. .. code-block:: bash $NDDSHOME/bin/rticlouddiscoveryservice -transport 10000 To see which exact address |CDS| is using to listen for participant announcements, run the service with ``-verbosity 4`` and look for the line: .. code-block:: bash ... [CDS DETECTOR] listening for announcements on: udpv4://172.17.0.2:10000 ... Set the initial peers accordingly to indicate where |CDS| is listening: .. code-block:: bash export NDDS_DISCOVERY_PEERS=rtps@udpv4://172.17.0.2:10000 Example: Using RTI TCP Transport ================================ This example extends :ref:`section-example-hw-simple` to use the RTI TCP transport for both discovery and user data. The example shows how to run |CDS| using the preregistered instance of RTI TCP transport. .. note:: To run this example, you need RTI TCP Transport, which is included with |CONNEXT|. .. _section-example-tcp-setup: Setup ----- The first step of this example is to configure the publisher and subscriber applications so they communicate over the RTI TCP transport in LAN mode. For that, you can include the following XML code within the ```` tag of the file ``USER_QOS_PROFILES.xml`` generated by *rtiddsgen*. .. code-block:: xml dds.transport.load_plugins dds.transport.tcp.tcp1 dds.transport.tcp.tcp1.library nddstransporttcp dds.transport.tcp.tcp1.create_function NDDS_Transport_TCPv4_create dds.transport.tcp.tcp1.server_bind_port $(BIND_PORT) dds.transport.tcp.tcp1.parent.classid NDDS_TRANSPORT_CLASSID_TCPV4_LAN The server bind port property value is obtained from the environment variable ``$(BIND_PORT)``. This is a convenience for this example so you can reuse the same file to specify a different port for the publisher and subscriber applications, which is required when running on the same host machine. Now you can run the applications. You need to run from the directory that contains the generated ``USER_QOS_PROFILES.xml`` you just modified. From the terminal, run the Publisher application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0 export BIND_PORT=7401 export NDDS_DISCOVERY_PEERS=tcpv4_lan://localhost:7402 ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_publisher Then run the Subscriber application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0 export BIND_PORT=7402 export NDDS_DISCOVERY_PEERS=tcpv4_lan://localhost:7401 ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber You should see the subscriber receive samples. This is possible since in the initial peers list, you indicated how the applications can reach each other. |CDS_Heading| in Action ----------------------- Now you will use |CDS| to provide the discovery for the applications. From a terminal, run the following: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0 $NDDSHOME/bin/rticlouddiscoveryservice -transport tcpv4_lan:7400 This will run |CDS| with the builtin configuration and override the transport selection to use RTI TCP with bind port ``7400``. Re-run the publisher and subscriber application, but this time set the initial peers to talk to |CDS| (see :numref:`section-domain-list-rtps-peer-descriptor`). For that, you can set the environment from the application terminal as follows: For the Publisher application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0 export BIND_PORT=7401 export NDDS_DISCOVERY_PEERS=rtps@tcpv4_lan://localhost:7400 For the Subscriber application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0 export BIND_PORT=7402 export NDDS_DISCOVERY_PEERS=rtps@tcpv4_lan://localhost:7400 Now run the applications and verify that the subscriber receives samples. You can also stop |CDS| and see how the applications **continue communicating**. Configuration for TCP transport in WAN Mode using a public address ------------------------------------------------------------------ In this example, we have seen how to configure the TCP transport on the publisher and subscriber applications and |CDS| to operate in LAN mode. However, there can be situations where |CDS| or the publisher and subscriber applications are located across LANs or firewalls. In such a use case, it would be typical to have |CDS| expose a public IP address which can be used for asymmetric discovery by the publisher or subscriber application. To apply this example in that context, you would need to make the following changes: USER_QOS_PROFILES.xml ^^^^^^^^^^^^^^^^^^^^^ Change the **classid** for the TCP transport used by the publisher and subscriber applications as follows: .. code-block:: xml dds.transport.tcp.tcp1.parent.classid NDDS_TRANSPORT_CLASSID_TCPV4_WAN |CDS_Heading| ^^^^^^^^^^^^^ Create a configuration file for |CDS| and select the TCP transport for the WAN alias and set the public address. This public address will be used by the publisher and the subscriber applications in their discovery peers. .. literalinclude:: static/rti_cds_example_tcp_wan.xml :language: xml You can download the configuration file from here: :download:`rti_cds_example_tcp_wan.xml ` You can read more about the **public_address** property of the RTI TCP transport in :link_tcpv4_properties:`RTI TCP Transport configuration <>`. An important thing to note here is the format of the specified address. It follows the ``[ip:port]`` format, where the IP is the public address of the router that provides access to the WAN. The port is the router port that is used to reach the private ``server_bind_port`` inside the LAN from the outside. In this example, the private ``server_bind_port`` is ``9000`` and the external port is ``4589``. You should change these values as per your network configuration. To use this configuration, from the terminal, run: .. code-block:: bash $NDDSHOME/bin/rticlouddiscoveryservice \ -cfgFile /rti_cds_example_tcp_wan.xml -cfgName ExampleTCPWAN NDDS_DISCOVERY_PEERS ^^^^^^^^^^^^^^^^^^^^ Run the publisher and subscriber applications exactly the way you did in :ref:`section-example-tcp-setup`, but with one modification. .. code-block:: bash export NDDS_DISCOVERY_PEERS=rtps@tcpv4_wan://35.6.9.10:4589 You will see that until |CDS| is started, the publisher and subscriber applications won’t discover each other. Once |CDS| starts, these applications will complete discovery and start communicating with each other. Example: Using RTI TCP Transport with RTI TLS Support ===================================================== This example extends :ref:`section-example-hw-simple` to enable TLS for secure communication. The example shows how to run |CDS| using the preregistered transport instance of the RTI TCP transport with TLS enabled. .. note:: To run this example, you need the RTI TCP Transport, which is shipped with RTI Connext DDS. Additionally, you will need to install the optional packages :link_tls_support_install:`RTI TLS support and OpenSSL <>`. Setup ----- The first step in this example is to configure the publisher and subscriber applications to communicate over the RTI TCP transport in LAN mode with TLS enabled. For that, you can include the following XML code within the ```` tag of the file ``USER_QOS_PROFILES.xml`` generated by *rtiddsgen*. .. code-block:: xml dds.transport.load_plugins dds.transport.tcp.tcp1 dds.transport.tcp.tcp1.library nddstransporttcp dds.transport.tcp.tcp1.create_function NDDS_Transport_TCPv4_create dds.transport.tcp.tcp1.server_bind_port $(BIND_PORT) dds.transport.tcp.tcp1.parent.classid NDDS_TRANSPORT_CLASSID_TLSV4_LAN dds.transport.tcp.tcp1.tls.verify.ca_file cacert.pem dds.transport.tcp.tcp1.tls.identity.certificate_chain_file peer1.pem The server bind port property value is obtained from the environment variable ``$(BIND_PORT)``. This is a convenience for this example so you can reuse the same file to specify different ports for the publisher and subscriber applications, which is required when running on the same host machine. You must also provide certificate files. You can obtain example certificates from the following links: - :download:`Certificate authority ` - :download:`Certificate chain ` Now you can run the applications. You need to run from the directory that contains the generated ``USER_QOS_PROFILES.xml`` that you just modified and the certificates. Because TLS is enabled, you must ensure that the *RTI TLS Support* and OpenSSL libraries are present in your library path before starting the applications. See the :ref:`beginning of this section ` for a note on how to locate the OpenSSL libraries. From the terminal, run the Publisher application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export BIND_PORT=7401 export NDDS_DISCOVERY_PEERS=tlsv4_lan://localhost:7402 ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_publisher Then run the Subscriber application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export BIND_PORT=7402 export NDDS_DISCOVERY_PEERS=tlsv4_lan://localhost:7401 ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber You should see the subscriber receives samples. This is possible since in the initial peers list, you indicated how the applications can reach each other. |CDS_Heading| in Action ----------------------- Now you will use |CDS| to provide the discovery for the applications. In this case, you need to configure the transport with an instance of the RTI TCP transport with TLS enabled. The configuration required for this example is shown below: .. literalinclude:: static/rti_cds_example_tls.xml :language: xml You can download the configuration file from here: :download:`rti_cds_example_tls.xml ` From a terminal, run: .. code-block:: bash export LD_LIBRARY_PATH=$OPENSSLHOMELIB $NDDSHOME/bin/rticlouddiscoveryservice \ -cfgFile /rti_cds_example_tls.xml -cfgName ExampleTls This command will run |CDS| with the custom configuration for this example, located under the directory ``.`` Re-run the publisher and subscriber applications, but this time set the initial peers to talk to |CDS| (see :numref:`section-domain-list-rtps-peer-descriptor`). For that, you can set the environment from the application terminal as follows: For the Publisher application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export BIND_PORT=7401 export NDDS_DISCOVERY_PEERS=rtps@tlsv4_lan://localhost:7400 For the Subscriber application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export BIND_PORT=7402 export NDDS_DISCOVERY_PEERS=rtps@tlsv4_lan://localhost:7400 Now run the applications and verify that the subscriber receives samples. You can also stop |CDS| and see how the applications **continue communicating**. Example: Using RTI Secure WAN Transport ======================================= This example extends the example in :numref:`section-example-hw-simple` to use *RTI Secure WAN Transport* for communication. The example shows how to run |CDS| with a user-registered transport instance of *RTI Secure WAN Transport*. .. note:: To run this example, you will need :link_secure_wan_install:`RTI Secure Wan Transport <>` and its dependencies. Because DTLS is enabled, you must ensure that OpenSSL libraries are present in your library path before starting the applications. See the :ref:`beginning of this section ` for a note on how to locate the OpenSSL libraries. The provided example uses the WAN transport with security disabled. The WAN transport relies on a rendezvous server based on the STUN protocol in order to locate peers and establish communication. You can run the WAN server as follows: .. code-block:: bash ${NDDSHOME}/bin/rtiwanserver -address
-port Where ``
`` and ```` define where the WAN server listens and how the publisher and subscriber applications can reach it. In this example, the values for the address and port are ``127.0.0.1`` and 3478, respectively. You will need the WAN server to be running for all the applications to communicate. Setup ----- The first step in this example is to configure the publisher and subscriber applications to communicate over the *RTI Secure WAN Transport*. For that, you can include the following XML code within the ```` tag of the file ``USER_QOS_PROFILES.xml`` generated by *rtiddsgen*. .. code-block:: xml dds.transport.load_plugins dds.transport.wan_plugin.wan dds.transport.wan_plugin.wan.library nddstransportwan dds.transport.wan_plugin.wan.create_function NDDS_Transport_WAN_create dds.transport.wan_plugin.wan.server 127.0.0.1 dds.transport.wan_plugin.wan.transport_instance_id $(WAN_ID) The WAN ID property value is obtained from the environment variable ``$(WAN_ID)``. This is a convenience for this example so you can specify a different ID for the publisher and subscriber without having to modify the file. Now you can run the applications. You need to run from the directory that contains the generated ``USER_QOS_PROFILES.xml`` that you just modified. For the Publisher application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export WAN_ID=2 export NDDS_DISCOVERY_PEERS=wan://::3:127.0.0.1 ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_publisher For the Subscriber application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export WAN_ID=3 export NDDS_DISCOVERY_PEERS=wan://::2:127.0.0.1 ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber You should see the subscriber receive samples. This is possible since in the initial peers list, you indicated how the applications can reach each other. |CDS_Heading| in Action ----------------------- Now you will use |CDS| to provide discovery for the applications. In this case, you need to configure the transport with a user-registered instance of the *RTI Secure WAN Transport*. The configuration required for this example is shown below: .. literalinclude:: static/rti_cds_example_wan.xml :language: xml You can download the configuration file from here: :download:`rti_cds_example_wan.xml ` From a terminal, run the following command: .. code-block:: bash $NDDSHOME/bin/rticlouddiscoveryservice \ -cfgFile /rti_cds_example_wan.xml -cfgName ExampleWan This command will run |CDS| with the custom configuration for this example, located under the directory ````. Re-run the publisher and subscriber application, but this time set the initial peers to talk to |CDS| (see :numref:`section-domain-list-rtps-peer-descriptor`). For that, you can set the environment in the application terminal as follows: For the Publisher application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export WAN_ID=2 export NDDS_DISCOVERY_PEERS=rtps@wan://::1:127.0.0.1:7400 For the Subscriber application: .. code-block:: bash export LD_LIBRARY_PATH=$NDDSHOME/lib/x64Linux3gcc5.4.0:$OPENSSLHOMELIB export WAN_ID=3 export NDDS_DISCOVERY_PEERS=rtps@wan://::1:127.0.0.1:7400 Now run the applications and verify that the subscriber receives samples. You can also stop |CDS| and see how the applications **continue communicating**. Example: Discovering Connext DDS Micro applications with |CDS_Heading| ====================================================================== This example illustrates how a |CONNEXT_MICRO| publisher application discovers a subscriber application via an instance of |CDS|. To reiterate, we are assuming that we are on a network that doesn’t support multicast. Installing |CONNEXT_MICRO_Heading| ---------------------------------- Before we move to how |CDS| is configured, you first need to have |CONNEXT_MICRO| installed. This example assumes that you have |CONNEXT_MICRO| version 3.0.0 or higher installed. This includes the |RTIDDSGEN| code generator. |RTIDDSGEN| can be used to generate example applications for publishing and subscribing to data. Earlier versions of |RTIDDSGEN| shipped with |CONNEXT_MICRO| didn’t support this functionality of generating examples. Please follow the step by step instructions in the |CONNEXT_MICRO| :link_micro_build_source_code:`documentation <>` to build the source code before moving on to the next steps. Setup ----- Just like |CONNEXT_PRO|, you will need an IDL file to feed into |RTIDDSGEN| to create an example publisher and subscriber application. You can use the same IDL as used in :numref:`section-example-udp-transport-setup`, ``CDSHelloWorld.idl``: .. code-block:: c struct CDSHelloWorld { long count; }; Generate the publisher and subscriber applications by running the following command (you can also use C++): .. code-block:: bash $RTIMEHOME/rtiddsgen/scripts/rtiddsgen -micro -language C -example \ CDSHelloWorld.idl Modify the ``CDSHelloWorld_publisher.c`` file to increase the ``count`` variable with each written sample. For instance, you could add the following line to the main writing loop: .. code-block:: c sample->count = i; The next step is to compile the applications. .. note:: |RTIDDSGEN| creates a README.txt file which contains instructions on how to compile for most standard platforms. For example: .. code-block:: bash $RTIMEHOME/resource/scripts/rtime-make --config Release --build --name \ x64Linux3gcc5.4.0 --target Linux --source-dir . \ -G "Unix Makefiles" --delete This will generate two executables, ``CDSHelloWorld_publisher`` and ``CDSHelloWorld_subscriber``, under the ``objs/`` folder. Run the examples to make sure everything is as expected. From the top-level directory of the project, run the following commands in two different terminals. Terminal 1: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_publisher Written sample 1 Matched a subscriber Written sample 2 Written sample 3 Written sample 4 Written sample 5 Terminal 2: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber Running for 24 hours, press Ctrl-C to exit Matched a publisher Valid sample received Valid sample received Valid sample received Valid sample received You should see that the subscriber application receives the samples generated by the publisher application. This happens because the |CONNEXT_MICRO| application you created adds the loopback address as a default peer and runs on domain ID 0. Understanding the |CONNEXT_MICRO_Heading| Peer Descriptor --------------------------------------------------------- |CONNEXT_MICRO| follows a different naming convention than |CONNEXT_PRO| when it comes to its peer descriptor string. The peer descriptor format is: .. code-block:: bash [participant_index@][interface://]address You can read more about this in the :link_micro_peer_desc_string:`documentation <>`. But the important point to note here is that |CONNEXT_MICRO| doesn’t allow you to directly specify a port number in the peer descriptor. So you need to be aware of which port number is selected based on the combination of participant index and domain ID. As you will see in more detail below, it is essential for the purpose of avoiding port conflicts. For the use case of |CDS| working with |CONNEXT_MICRO|, we have two configuration options: #. *Configure by Port* - You can compute the port number that the combination of peer descriptor and domain ID will refer to, based on the RTPS well-known ports specification. This idea is useful when one of the |CONNEXT_MICRO| publishers or subscribers is running on the same machine as |CDS|. #. *Configure by Domain ID* - You can configure |CDS| to run on a particular domain ID and by default it will assume the participant index 0. This idea is useful when |CDS| is running on a separate machine than the publisher or the subscriber application. .. _cds_micro_configure_by_port: Configure by Port ----------------- Setup ^^^^^ This example assumes that |CDS| runs on the same machine as either the publisher or subscriber application or both. If you want to test a |CDS| instance running on a different machine, you can still use this example by just changing the IP address part in the peer descriptor or you can check out the simpler method of :ref:`cds_micro_configure_by_domain_id`. Changing the default initial peer ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We are going to change the initial peer for the publisher and the subscriber applications so they won’t be able to discover each other. To demonstrate this example on the same machine, we will have the publisher and subscriber applications contact a specific participant index that doesn’t correspond to either of them. This will allow |CDS| to come into the picture. To do that, run the publisher and subscriber applications as follows, using the ``-peer`` and ``-domain`` command-line arguments. CDSHelloWorld_publisher: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_publisher -peer [5]@_udp://127.0.0.1 \ -domain 0 CDSHelloWorld_subscriber: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber -peer [5]@_udp://127.0.0.1 \ -domain 0 At this point you should notice that the publisher and subscriber applications cannot discover each other. |CDS_Heading| in Action ^^^^^^^^^^^^^^^^^^^^^^^ To make the applications communicate, we need a special configuration for |CDS|. We need a configuration where |CDS| listens on the ports referred to by the combination of peer descriptor and domain ID for the publisher and the subscriber applications. The configuration from file :download:`rti_cds_example_micro.xml ` required for this example is shown below: .. literalinclude:: static/rti_cds_example_micro.xml :language: xml :start-after: :end-before: Here ``7420`` is the port number corresponding to participant index 5 on domain 0 when the RTPS well-known port mapping is kept to its default setting. You can read more about the defaults in the :link_rtps_well_known_ports_c_api:`API documentation <>`. This allows |CDS| to discover both the publisher and subscriber applications and relay their announcements to each other. .. note:: Assuming there are no other |CONNEXT_MICRO| or |CONNEXT_PRO| applications running on the system, if we start the publisher first, it will take the participant index 0 and the subscriber will take the participant index 1 on domain 0. If you have more applications running on your system on the same domain, you will have to increase the participant index in the peer descriptor to be a higher number (than 5 which was used) to avoid port conflicts with other running DDS applications. At the same time you will have to change the port number |CDS| binds to, based on the corresponding combination of participant index and domain ID. From the terminal, you can run the following command to use the above configuration: .. code-block:: bash $NDDSHOME/bin/rticlouddiscoveryservice -cfgFile /rti_cds_example_micro.xml \ -cfgName ExampleMicroByPort Once |CDS| starts, you should see the publisher and subscriber applications sending data to each other. You can stop |CDS| and still see the applications continue to communicate. .. _cds_micro_configure_by_domain_id: Configure by Domain ID ---------------------- Setup ^^^^^ This method assumes that |CDS| runs on a separate machine. This is because if |CDS| runs on the same machine as your publisher or subscriber application, you may end up with port conflicts depending on which application (the publisher, subscriber or |CDS|) is started first. |CDS| when working in this configuration tries to bind to the port corresponding to participant index 0. To see |CDS| in action on the same machine as your |CONNEXT_MICRO| publisher, subscriber or both, please refer to the :ref:`cds_micro_configure_by_port` section. Changing the default initial peer ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We are going to change the initial peer for the publisher and the subscriber application such that they won’t be able to discover each other. To do that we will be running the publisher and subscriber applications as follows using the ``-peer`` and ``-domain`` command-line arguments. In the example commands below, note that ``10.10.10.10`` is a hypothetical address for the machine running |CDS|. You may want to replace that with the IP address of your machine that is running |CDS|. CDSHelloWorld_publisher: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_publisher -peer _udp://10.10.10.10 \ -domain 0 CDSHelloWorld_subscriber: .. code-block:: bash ./objs/x64Linux3gcc5.4.0/CDSHelloWorld_subscriber -peer _udp://10.10.10.10 \ -domain 0 At this point you should notice that the publisher and subscriber applications cannot discover each other. |CDS_Heading| in Action ^^^^^^^^^^^^^^^^^^^^^^^ To make the applications communicate, we need a special configuration for |CDS|. We need a configuration where |CDS| listens on a port computed from the RTPS well-known port mapping for a given domain ID. Note that the participant index cannot be configured and defaults to 0. The configuration from file :download:`rti_cds_example_micro.xml ` required for this example is shown below: .. literalinclude:: static/rti_cds_example_micro.xml :language: xml :start-after: :end-before: From the terminal, run the following command: .. code-block:: bash $NDDSHOME/bin/rticlouddiscoveryservice -cfgFile /rti_cds_example_micro.xml \ -cfgName ExampleMicroByDomainID Once |CDS| starts you should see the publisher and subscriber applications sending data to each other. As before, you can stop |CDS| and still see the applications continue to communicate.