Skip to content

Scenario3.md

Latest commit

 

History

History
120 lines (73 loc) · 6.76 KB

Scenario3.md

File metadata and controls

120 lines (73 loc) · 6.76 KB
Raw

Scenario 3: Relayed Communication Using RTI Routing Service

This scenario demonstrates WAN communication when both DomainParticipants are behind NATs (symmetric or cone NATs) and cannot reach each other directly. A cloud-based Passive RTI Routing Service acts as a relay to route communication between the Active RTI Routing Services.

The Active RTI Routing Services initiate discovery towards the public cloud instance. The cloud-based Passive RTI Routing Service relays communication between both NAT-protected Active Routing Services.

This scenario does not require the OR's and the Arm Controller's NATs to be cone NATs, making it the most flexible deployment option. However, the communication between local networks is not direct over the WAN, and is instead bridged by the cloud-based RTI Routing Service instance.

In this scenario, only Domain 1 is secured. Operating room applications from Module 01 run in non-secured mode locally on Domain 0, while WAN communication uses authentication and encryption on Domain 1. In a production deployment, you may choose to secure the local traffic as well or just the remote traffic as demonstrated here.

Make sure the shared setup in the root Quick Start section is complete and that Module 01 is already working before you try this scenario.

Module-specific notes:

  • If you plan to use secure mode, make sure the security artifacts from the root README have been generated.

Scenario 3 diagram

Setup and Installation

Complete the shared setup in the root Quick Start section. This scenario then adds the WAN transport, cloud instance, security, and network configuration below.

1. Install RTI Real-Time WAN Transport

The RTI Real-Time WAN Transport is available as an add-on product. Follow the RTI Real-Time WAN Transport Installation Guide to install the transport plugin on both machines.

2. Setup Cloud Instance

On your publicly reachable cloud instance, install the RTI Connext host and the RTI Real-Time WAN Transport packages.

  1. To install Connext host, follow the installation guide and install only the host bundle (there is no need to install a target bundle).
  2. RTI Real-Time WAN Transport is available as an add-on product. Follow the RTI Real-Time WAN Transport Installation Guide to install the transport plugin.

3. Security (optional)

The shared trusted security artifacts are covered in the root Quick Start. Complete that setup before running this scenario, then distribute the generated artifacts to whichever machines are used to run the demo applications.

You should generate the security artifacts once and then distribute to whichever machines are used to run the demo applications. This ensures the certificates can be correctly verified across machines during DomainParticipant authentication.

4. Network Configuration

On the Active sides and on your cloud instance, set the following environment variables before running the scenario. NDDSHOME must already be set from your Connext installation (see Module 01 Setup).

Variable Value Default
PUBLIC_ADDRESS Publicly accessible IP address of the cloud instance. (required)
PUBLIC_PORT Publicly accessible/forwarded port of the cloud instance. 10777
INTERNAL_PORT Internal/forwarded port of the cloud instance. This may be the same as PUBLIC_PORT. 10777

PUBLIC_PORT and INTERNAL_PORT default to 10777 in the XML configuration and only need to be set if you are forwarding a different port. PUBLIC_ADDRESS has no default and must be set, or the service will fail to start.

# Linux / macOS
export PUBLIC_ADDRESS=<cloud instance public IP>
export PUBLIC_PORT=10777       # only needed if not using the default
export INTERNAL_PORT=10777     # only needed if not using the default

# Windows Command Prompt
set PUBLIC_ADDRESS=<cloud instance public IP>
set PUBLIC_PORT=10777
set INTERNAL_PORT=10777

You will need to add a security rule on your cloud instance to allow incoming/outgoing traffic on PUBLIC_PORT for the UDP protocol. For example:

Configuration cloud instance

Run the Scenario

Important: Run the commands below from the repository root. launch.py lives at the project root and is the single runtime entrypoint for this project.

Note: This scenario will not work if different certificate sets are used on each side.

1. Launch Active Side Applications

From one machine, start the teleop Arm Controller:

# From the repository root
python3 launch.py 01-operating-room ArmController

2. Launch Passive Side Applications

From the other machine, start the Operating Room applications:

# From the repository root
python3 launch.py 01-operating-room Orchestrator PatientSensor Arm PatientMonitor

Observe: You should see no communication between applications since the RTI Routing Service infrastructure has not been started yet.

3. Launch Cloud Routing Service

In a terminal on your cloud instance, run the Passive RTI Routing Service:

# From the repository root
python3 launch.py 03-remote-teleoperation RsCloud [-s]

4. Launch Active Routing Services

Open a new terminal on both Active sides and run the following in each:

# From the repository root
python3 launch.py 03-remote-teleoperation RsActive [-s]

5. Observe Communication

Observe the operating room applications to verify that all Module 01: Digital Operating Room functionality works across the WAN.

Observe: Once discovery completes, you should see data flow between the Operating Room applications and the Arm Controller. The cloud-based RTI Routing Service acts as a relay, facilitating communication between both NAT-protected sides. RTI Routing Service provides scalability by bridging between the local networks over the WAN and avoids managing a separate WAN connection for each set of remote applications that communicate.

6. Kill the applications

Press Ctrl-C in each terminal to terminate the running applications.