Real-Time LAN Over WAN

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.

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.

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.

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.

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.

This example highlights features of RTI Cloud Discovery Service and RTI Real-Time WAN Transport.

• 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.

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.

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 a free trial of Connext. 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.