Introduction

This use case applies if you are trying to connect multiple real-time local networks together, or if you are trying to connect a real-time local network to other network(s) over a wide area network (WAN). This solution supports use cases where each local area network (LAN) site may be a cluster of many Connext applications distributing large amounts of data that should not be sent across the WAN. This solution also supports use cases where sites are geographically distant from each other, and where bandwidth must be conserved. A few examples of this include:

  • Controlling or monitoring a robot over a WAN
  • Monitoring many pieces of equipment from a remote monitoring station
  • Sending real-time radar information between remote sites
  • Monitoring multiple vehicles over a public network
  • Communicating between an UAV and a ground station

Connext is a high-performance, peer-to-peer middleware that can send real-time data within your LAN, or optionally over a WAN. This is enabled in this example using:

  • RTI Routing Service (part of RTI Connext® Professional), which allows you to selectively bridge data between different subsystems. The Routing Service is being used here to send a subset of your local data between local networks on separate DDS domains, or over a wide area network using TCP or UDP transports.
  • Real-Time WAN Transport (part of Connext Anywhere) which enables Connext applications to directly access wide area networks and traverse NAT routers.
  • RTI Cloud Discovery Service (part of Connext Anywhere) that eases the discovery process for Connext applications on networks (LAN or WAN) that lack a wide-area discovery mechanism such as UDP multicast.

If you need to connect separate real-time networks together over a WAN or LAN, this example offers several configuration options to enable communications.

What This Example Does

This example shows two logical subsystems that represent two LAN environments. These LAN environments are logically separated by using different DDS domains: even if you run them on the same network, they will not communicate with each other. Further, if you run them on different LAN networks, they will also be physically separated.

This example offers several approaches to connecting these separated networks using a local or wide-area network (such as the internet) with TCP or UDP transport options.

For simplicity, the applications running in either LAN will be the RTI Shapes Demo, but other applications can be substituted with little or no modification to the configuration scripts included in this example.

Example 1: Bridging with Routing Service over UDP LAN

This example selectively bridges topics between applications running on different DDS domains on a common LAN, using RTI Routing Service.

The Routing Services are configured to pass only specific topics:

  • Circle data in one direction, unfiltered.
  • Square data in the other, with a data filter that passes data only if the Square is in the bottom half of the Shapes Demo application.

Note that while 2 instances of Routing Service were used in this example (each bridging their local domains to a common domain 0), a single instance could have been used to connect domain 5 to domain 6, without using an intermediate domain.

 

Example 2: Bridging with Routing Service over TCP LAN

This example is similar to Example 1, but uses the TCP transport option for the intermediate domain between the two local networks, and does not use a topic data filter:

TCP transports may be a solution for managed local networks that routinely block UDP data traffic between subsections of the network, but allow TCP traffic to pass unhindered. This example requires that each Routing Service (RS) instance be given the IP address of the RS instance it needs to contact, thereby providing a direct TCP link between the 2 RS instances.

 

Example 3: Bridging with Routing Service over TCP WAN

This example is similar to Example 2, but uses the TCP WAN transport between the Routing Service instances to enable communications over a wide-area network such as the internet:

Similar to Example 2, this example requires that each Routing Service instance is given the IP address of the remote RS instance, and to ensure the correct TCP port is open and not blocked by a firewall.

 

Example 4: Bridging with Routing Service over TCP WAN through a TCP relay server

In the previous TCP example, the IP address of each remote machine must be known to establish a connection. But what if those addresses cannot be known or are subject to change? This example uses a third RTI Routing Service, hosted on a web-accessible server with a fixed public IP address. This RS instance is configured as a DDS ‘TCP Relay,’ forwarding DDS traffic between 2 TCP ports. This enables any local RS instance to connect to this TCP relay, without knowing the IP addresses of any other RS instances:

As with other TCP examples, the IP address of the TCP Relay machine must be provided to each Routing Service instance, and the direction of data flow is established by selection of the TCP port on the TCP Relay. This example uses the auto route feature of Routing Service, wherein routes are created for all discovered data topics, excluding the internal RTI topics used for discovery and logging.

 

Example 5: Bridging with Routing Service over WAN with Connext Anywhere using RTI Cloud Discovery Service and Real-Time WAN Transport

This example highlights features in Connext Anywhere (a free trial version of Connext Anywhere is available here. 

  • RTI Cloud Discovery Service, which enables DDS discovery on networks that lack a multicast option, such as the internet, and to traverse common types of NAT routers.
  • RTI Real-Time WAN Transport, a transport option that enables applications to directly use UDP over wide-area networks such as the internet.

Put together, these two capabilities enable isolated UDP LAN networks to selectively extend their reach to multiple remote destinations over UDP WAN.

The use of Cloud Discovery Service requires the applications (in this case, the Routing Service instances) be made aware of the IP address of the Cloud Discovery Service server.

 

Example 6: Directly connecting applications over WAN with Connext Anywhere using RTI Cloud Discovery Service and Real-Time WAN Transport

This example shows how applications may be configured to directly use Real-Time WAN Transport to connect to remote applications over a WAN connection, without using a Routing Service instance.

Similar to the Routing Service example 5 above, this example configures the applications (RTI Shapes Demo) to use the Real-Time WAN Transport option, and provides the setting to locate the Cloud Discovery Service instance to let the remote applications find each other, even when located behind NAT routers.

 

Running the Example

Download the Example

Much of this example is based on RTI Routing Service, using platform- independent XML files for configuration. These files can be downloaded from the RTI Community DDS Use Cases repository in GitHub. This repository includes other subsets - the code for this example is found in the DataSubsetWAN folder. The code can be saved to a location of your choice. We'll refer to this location as EXAMPLE_HOME.

All of the examples use RTI Shapes Demo, a free download from the RTI website and also included in the free trial version of RTI Connext. Portions of this example use Real-Time WAN Transport, or the Cloud Discovery Service, both of which are available in a full license version of Connext.

Download Connext 

If you do not already have Connext installed, download and install it now. You can use a 30-day trial license to try out the product. Your download will include most of the components that are required to run the example, and tools you can use to visualize and debug your distributed system.

Running the Example

Detailed instructions on running the example are included in the README.md file, summarized below. For this example, you must set an environment variable called NDDSHOME. This must point to the RTI Connext 6.1 installation. After setting the environment variables, navigate or change directories into EXAMPLE_HOME\ExampleCode to find the starting scripts and configuration.

This example is presented in 3 sections: Bridging over LAN, Bridging over WAN with TCP, and Bridging over WAN with Real-Time WAN Transport and Cloud Discovery Service.

Bridging over LAN

The first section demonstrates ways of connecting isolated systems over a common LAN network, using RTI Routing Service and UDP or TCP.



Bridging over WAN with TCP

The second section demonstrates how to create a TCP-over-WAN connection to bridge systems with wide physical separation to act as an integrated unit.



Bridging with Connext Anywhere using Real-Time WAN Transport and Cloud Discovery Service

The final section demonstrates how Connext applications can communicate over a WAN (such as the internet) as easily as with a local network.

 

Next Steps

Join the Community

Post questions on the RTI Community Forum.

Contribute to our Case + Code examples on RTI Community GitHub using these instructions.

Explore More with Connext

Check out more of the RTI Connext product suite and learn how Connext products can help you build your distributed systems. If you haven't already, download the free trial.