4.7. INTRA Transport

The builtin intra participant transport (INTRA) is a transport that bypasses RTPS and reduces the number of data-copies from three to one for data published by a DataWriter to a DataReader within the same participant. When a sample is published, it is copied directly to the data reader’s cache (if there is space). This transport is used for communication between DataReaders and DataWriters created within the same participant by default.

Please refer to Threading Model for important details regarding application constraints when using this transport.

4.7.1. Registering the INTRA Transport

The builtin INTRA transport is a RTI Connext Micro component that is automatically registered when the DomainParticipantFactory_get_instance() method is called. By default, data published by a DataWriter is sent to all DataReaders within the same participant using the INTRA transport.

In order to prevent the INTRA transport from being used it is necessary to remove it as a transport and a user-data transport prior to creating the participant. The following code shows how to only use the builtin UDP transport for user-data.

struct DDS_DomainParticipantQos dp_qos =
                            DDS_DomainParticipantQos_INITIALIZER;

REDA_StringSeq_set_maximum(&dp_qos.transports.enabled_transports,1);
REDA_StringSeq_set_length(&dp_qos.transports.enabled_transports,1);
*REDA_StringSeq_get_reference(&dp_qos.transports.enabled_transports,0) =
                                    REDA_String_dup(NETIO_DEFAULT_UDP_NAME);

/* Use only unicast for user-data traffic. */
REDA_StringSeq_set_maximum(&dp_qos.user_traffic.enabled_transports,1);
REDA_StringSeq_set_length(&dp_qos.user_traffic.enabled_transports,1);
*REDA_StringSeq_get_reference(&dp_qos.user_traffic.enabled_transports,0) =
                                    REDA_String_dup("_udp://");

Note that the INTRA transport is never used for discovery traffic internally. It is not possible to disable matching of DataReaders and DataWriters within the same participant.

4.7.2. Configuring QoS policies

Most configurations of the Reliability and Durability QoS policies will function as intended over the INTRA transport. However, because the INTRA transport bypasses RTPS reliability and DDS durability queues, your application may lose data when using certain settings, as described below.

4.7.2.1. Reliability

If a DataWriter configured with RELIABLE Reliability and KEEP_ALL History matches with any DataReader via the INTRA transport, the DataWriter will eventually run out of resources in its cache. This occurs because the DataReader has no path to send sample acknowledgements (ACKNACKS) to the DataWriter over INTRA. Once the DataWriter’s queue fills up, it will stop sending data. Therefore, this configuration should not be used when communicating via the INTRA transport.

All other configurations of Reliability and History are supported, including a RELIABLE DataWriter with KEEP_LAST History.

4.7.2.2. Durability

The TRANSIENT_LOCAL Durability setting directs a DataWriter to keep samples in its queue for late-joining DataReaders, but it has no path to deliver them when communicating via INTRA. Late-joining TRANSIENT_LOCAL DataReaders will not receive historical data as intended.

Note

TRANSIENT_LOCAL Durability does not prevent DataWriters and DataReaders from communicating over INTRA after both are created; only the historical samples in the DataWriter’s queue will fail to be delivered.

However, if you create all DataReaders before creating any DataWriters, TRANSIENT_LOCAL Durability is not required because the DataReaders will start receiving data immediately from any matched DataWriters without missing any samples.

4.7.3. Threading Model

The INTRA transport does not create any threads. Instead, a DataReader receives data over the INTRA transport in the context of the DataWriter’s send thread.

This model has two important limitations:

  • Because a DataReader’s on_data_available() listener is called in the context of the DataWriter’s send thread, a DataReader may potentially process data at a different priority than intended (the DataWriter’s). While it is generally not recommended to process data in a DataReader’s on_data_available() listener, it is particularly important to not do so when using the INTRA transport. Instead, use a DDS WaitSet or a similar construct to wake up a separate thread to process data.

  • Because a DataReader’s on_data_available() listener is called in the context of the DataWriter’s send thread, any method called in the on_data_available() listener is done in the context of the DataWriter’s stack. Calling a DataWriter write() in the callback could result in an infinite call stack. Thus, it is recommended not to call in this listener any Connext Micro APIs that write data.