Version 0.1.0 · RTI License · C++

RTI Connext DDS

RTI Connext DDS connects a Holoscan application to a DDS databus. Publish and subscribe to strongly typed data with the DDS publish/subscribe model, so independent Holoscan applications and non-Holoscan systems can exchange data without point-to-point connections maintained by each application.

Experimental prototype

This module is an engineering prototype for Holoscan SDK (HSDK) 5.0.0 EA2, not a packaged production module. It is built, tested, and run in Docker.

Connext handles discovery, so compatible publishers and subscribers find each other without an application-level broker. Each data flow carries its own quality-of-service policy for reliability, history, and durability, and types are defined in OMG IDL, so producers and consumers can evolve independently.

At a glance

Repository	`rticonnextdds-holoscan-module`
Version	0.1.0
C++ namespace	`rti::holoscan::dds`
Holoscan SDK	5.0.0 EA2
RTI Connext DDS	7.7.0
CUDA	13
Platforms	x86_64, aarch64. IGX Orin is not supported, because it does not provide CUDA 13.
Languages	C++. Python bindings are not included.
License	RTI License, in the repository. A Connext runtime license is separate.
Maintainer	RTI Real-Time Innovations

This module is maintained by RTI. For the Connext SDK, a runtime license, or support, contact RTI at holoscan@rti.com.

Operators

Operator	What it does
`PublisherOp<DdsType, Adapter>`	Takes a Holoscan payload, converts it to a generated DDS type, and writes it with a Connext `DataWriter`
`SubscriberOp<DdsType, Adapter>`	Reads a generated DDS type with a Connext `DataReader`, converts it to a Holoscan payload, and emits it into the graph

Both operators own the Connext participant, topic, reader or writer, quality of service, and lifecycle. The subscriber wakes the scheduler through a notification source rather than polling. Your application supplies the data type and the conversion at the Holoscan and DDS boundary.

Endpoint parameters

Each operator takes an EndpointConfig:

Parameter	Default	What it sets
`domain_id`	`0`	DDS domain. Only applications on the same domain discover each other.
`topic_name`	none	Topic to publish or subscribe to. Always set it.
`qos_file`	`HoloscanConnextQos.xml`	XML file the quality-of-service profile is loaded from
`qos_profile`	`HoloscanConnext::ReliableKeepAll`	Profile within the XML library
`max_samples_per_activation`	`32`	Largest number of samples a subscriber emits per compute
`wait_for_reader`	`true`	Make a publisher wait for a matched reader at startup
`reader_match_timeout`	`10 s`	How long a publisher waits for that match
`acknowledgment_timeout`	`5 s`	How long a publisher waits for acknowledgment at shutdown

A writer and a reader exchange data only when the domain, topic name, type definitions, and requested and offered quality of service are all compatible, and a network path allows discovery. Matching C++ type names in the source is not enough on its own; both ends must generate compatible type metadata from compatible IDL.

Sample applications

Application	What it shows
`connext_shapes_holoviz`	Generates a shape locally, publishes it, subscribes to the `Square`, `Circle`, and `Triangle` topics, and displays local and received samples with Holoviz
`shapes_demo_flatbuffers`	Separate publisher and subscriber applications that exchange a typed FlatBuffers payload over DDS rather than an in-process connection

Both use the DDS type from the standard RTI Shapes Demo, so they interoperate with it.

Use it in an application

A generated Connext class is not a Holoscan graph payload, so an adapter maps between the two:

Holoscan payload <-> adapter <-> generated DDS type

The adapter names the Holoscan type and converts it:

struct TelemetryAdapter {
  using holoscan_type = std::uint32_t;

  static Telemetry to_dds(holoscan_type index) {
    Telemetry sample;
    sample.sensor_id = 7;
    sample.sample_index = index;
    return sample;
  }
};

When holoscan_type is holoscan::Tensor, the adapter also declares a tensor_input_spec() with the dtype, rank, memory kind, and bounds for the graph compiler. Point the operator at a domain and topic:

const rti::holoscan::dds::EndpointConfig config{
    .domain_id = 42,
    .topic_name = "RobotState",
};

Adding your own data model means generating a C++ type from your IDL, choosing a Holoscan payload the operators in that graph accept, and writing the adapter between them. The module does not generate that mapping. An IDL change usually means updating the generated type, the adapter, any companion schema, and the tests together.

Build and run

Everything builds and runs in Docker, so the host needs neither Connext nor Holoscan installed. The container does need a rti_license.dat, bind-mounted read-only at run time and kept out of the image and out of source control. Request an activation key from the RTI Connext license page.

The container profile shares the host IPC and process namespaces so Connext can use its shared-memory transport between containers and with applications on the host. Private IPC prevents that path, so use a deployment-specific transport configuration when you need stronger isolation.

Source and setup instructions are in the RTI repository.

All modules