Routing Service Constrained WAN Example

The purpose of this demonstration is to show how the Routing Service can be used to constrain the amount of information sent over a network (usually a WAN). Different QoS and configuration and filters are applied to the Routing Service without any changes to the original publisher.

There are two primary demos, one for localhost only demonstrations that publishes and subscribes from two different shapes demo applications. And the second that utilizes an AWS hosted instance of the shapes demo


  1. Install the RTI Routing Service and shapes demo (both are included with RTI DDS Connext Pro)
  2. Set the NDDSHOME environmental variable based on your environment, see the core libraries user manual for instructions
  3. For the localhost based demo, download these four XML files from github in the conf/ directory, and place them in their own directory
    1. 0ms.xml
    2. 300ms.xml
    3. 1000ms.xml
    4. localhost.xml
  4. For the AWS hosted demo, download the XML configuration file from the same github location conf/ directory
    1. local.tcp.transport.xml
    2. server.tcp.transport.xml (Not required and for reference, this is the server side Routing Service configuration)
    3. simple_shapes_demo.xml (Not required and for reference, this is the server side web integration service configuration)
  5. For the localhost content filter propagation demo, your shapes demo application will need to be configured to use the localhost interface so wireshark can capture the packets
    1. This guide explains how to disable shared memory
    2. And this optional guide explains how to configure colorizing rules in wireshark, this can also be used for the IO graph portion of wireshark we will use later.

Localhost Demo:

  1. Start one copy of the shapes demo on domain 0
    • Publish one square, circle, and triangle shape using different colors (all using the default QoS settings)
  2. Start a second copy of the shapes demo on domain 1
    • To change domains, select "Controls→Configuration" then click the "stop" button. Change the domain number, and click "start"
    • Subscribe to squares, circles, and triangles (all using the default QoS settings)
    • At this point you should not see any samples on the subscribing side because the Routing Service is not running
  3. Start the Routing Service via the RTI Launcher
    • Select the "Services" tab, then click the "Routing Service" icon
    • Specify your "Working Directory" to be the directory where the localhost .xml configuration files are located
    • Specify the "Custom" configuration file to be localhost.xml
    • On the "Configuration" line specify "example - from CUSTOM"

  4. You should now see shapes show up on the shapes demo application subscribing on domain 1
    • Note that Routing Service is not configured to route from domain 1 to domain 0, so if you have problems double check your domain IDs.


  5. Start the routing service remote shell to dynamically reconfigure the Routing Service
    • From the command line run rtirssh -domainId 0 -timeout 3
    • If the executable cannot be found you may have to set your PATH variable to the bin/ folder of your connext dds install location
  6. Update the square route to include a time based filter. 
    • Run this command within the rtirssh shell:update example Route::Session::Square <path to xml>/300ms.xml
    • Notice how the square is now only received on domain 1 every 300ms. This is a filter acting on the routing service's input.
    • This could be useful for telematic applications that may not need every single sample at the upstream analysis or logging system. And under degraded WAN network conditions this time filter can be dynamically applied to individual routes


    • You can revert to no time based filter by using the "0ms.xml" file with the above command
    • If you want to increase the time between samples you can use the "1000ms.xml" file
    • Lets leave the "300ms.xml" time filter on for now, so we can compare it to batching QoS in the next step
  7. Enabling batching by first disabling the triangle's route, and then enabling the TriangleBatch route
    • Launch Admin Console from the "Tools" tab in the Launcher
    • Select the routing service instance in the "Physical View" in the bottom left pane
    • Right click on the "Triangle" route and disable it, then right click on the "TriangleBatch" route and enable it

      ac triangle

    • Notice how the triangle is now updating in batches of 6 samples (compared to the other shapes that are updating one sample at a time)

      demo 3
  8. Combine batching and time filters together. 
    • Run this command within the rtirssh shell:update example Route::Session::TriangleBatch <path to xml>/300ms.xml
    • Notice how the triangle is still batching 6 samples up at a time, but it is also time filtering one sample every 300ms.
    • If you instead apply the 1000ms.xml filter, you'll notice batches of 2 samples at a time normally. This is because the time filter is applied on the input before batching is applied. And then batching is applied with a <max_flush_delay> of 2 seconds.
      This configuration of batching can be useful to send periodic data at a defined rate, regardless of the number of samples that have been collected

  9. Combine multiple topics into a single topic. 
    • Within admin console, disable the TriangleBatch route, and enable the TriangleToCircle route (similar to step #7)
    • Notice how the triangle is now remapped to circles. This would allow applications with similar datatypes to combine multiple topics into a single topic. This can limit discovery traffic and improve discovery time.

      Triangles shown on the subscriber are disposed instances
    • You can also rewrite the squares to circles enabling the SquareToCircle route (disable the Square route first)
    • Note that you won't be able to directly apply the time based filters to these routes without modifying the xml files, since the SquareToCircle and TriangleToCircle are <topic_route>'s not <auto_topic_route>'s
  10. Content filter propagation
    • Restart Routing Service so the default Square/Circle/Triangle routes are enabled
    • On the shapesdemo on domain 0 delete the triangle and circle publications, so only the square publication is left
    • On the shapesdemo on domain 1 delete all subscriptions, and subscribe to a square using a content filter (place it across the bottom half of the area)
    • Using wireshark, capture on localhost, go to statistics->IO graph and add these filters for data samples on domain 0 and domain 1:
      • Domain 0 wireshark IO graph filter: rtps.domain_id==0 && (( == 0x02) || ( == 0x03))
      • Domain 1 wireshark IO graph filter: rtps.domain_id==1 && (( == 0x02) || ( == 0x03))
    • Notice how square samples are sent on domain 1 only when the shape is within the filter (purple bars), but that filter is not propagated over to the original publisher on domain 0 for writer side filtering (teal bars)

      wireshark io graph 1

    • Delete the square publisher and subscriber, and setup the same demo using circles or triangles. (publisher on domain 0, subscriber with a filter on domain 1)


    • Notice how the circle or triangle content filter is propagated through the routing service over to the original publisher due to the <filter_propagation> being enabled within that route. 
      When the shape is outside of the subscriber's filter, no samples are published on either domain. You can dynamically move the filter around to show the power of this filter propagation 

      wireshark io graph 2

WAN Demo over TCP

To build on the localhost routing service demo above, a second copy of routing service is setup on an AWS instance to send DDS samples over the WAN network using TCP.
To visualize the DDS samples on the AWS instance, the web integration service is configured to display the shapes via a web browser.

Network Diagram of the Demonstration


WAN Over TCP Process

  1. Start one copy of the shapes demo on domain 0
    • Publish one square, circle, and triangle using different colors (the default QoS settings should be fine)
    • I don't recommend setting the shapes to move very quickly, because once we add a time based filter it can become harder to visually see each shape's path. You can easily slow down all shapes with "Controls→Slow Down"
  2. Start the routing service 
    • Via the Launcher GUI: Specify your "Working Directory" and "Custom" configuration file of local.tcp.transport.xml from above
    • On the Configuration line select "example - from CUSTOM"

    • You can verify your local instance of routing service is operating correctly by launching admin console
      Select the "example" routing service in the "Physical View"
      The "Routing Entities" tab and "Statistics" tab should now be selected, and on the right side you can view the number of samples/second passing through each route

      admin stats
      Each topic is publishing a different number of samples a second by default due to time filtering being applied automatically
  3. Launch in a browser
    • Notice how each routing service instance is adapting samples between different domain IDs
    • Each routing service is also adapting between TCP and UDP/Shared memory
    • You should see the shapes on your browser that is connected to the web integration service URL. By default time based filters are applied to the Squares (300ms.xml), and Triangles (1000ms.xml), no filter is applied to the Circles.
    • These time based filters are applied on the input side of the local routing service, so fewer samples are sent over the WAN link.

  4. If you want to dynamically apply different time filters to the local routing service instance on topics you can use the rtirssh shell:
    • Disable Triangle time filters: update example Route::Session::Triangle <path to xml>/0ms.xml
    • Apply a 300ms Triangle time filter: update example Route::Session::Triangle <path to xml>/300ms.xml
    • Apply a 1000ms Triangle time filter: update example Route::Session::Triangle <path to xml>/1000ms.xml
  5. Use Admin Console 6.0.1+ subscribe to the command_request and command_reply topics to monitor the commands sent to the routing service (Use the built-in AdminConsole::DataVisualization QoS)
    • By viewing the sample log you can see commands and responses sourced from the rtirssh or Admin Console's routing service view

      command request
  6. Enable content filtering of the data at the local routing service 
    • Using Admin Console disable the "Circle" route and enable the "CircleFilter" route (like you did during the localhost portion of the demo above)


    • A content filter is now applied on the input side of the local routing service instance, that is based on the X value of the shape.
      Samples are filtered prior to the TCP/WAN link saving WAN bandwidth


    • You can visualize this content filter by capturing rtps traffic in wireshark on your interface connected to your WAN, and viewing the I/O graph.
      Data samples are only sent over the WAN link when the content filter is matched. (You may want to only enable one route at a time for a cleaner graph)


  7. Combine multiple topics into a single topic
    • Using Admin Console select the routing service instance like you did above, and disable the "Square" and "Triangle" routes
    • Then enable the "SquareToCircle" and "TriangleToCircle" routes
    • These routes that transform the topic name are applied on the local instance of routing service, and would help to reduce the amount of bandwidth and time used for discovery.


Demo Notes

  1. The rtirssh tool is a demonstration of the routing service administration interface. Customers can develop their own implementation to control their routing service instances
  2. Disposed shapes sometime remain on the web integration service if routing service is exited. You can re-enable these routes and delete them from the original publisher to clear these instances.


Browse the files in GitHub