Built-in QoS Profiles


RTI Connext DDS provides Quality of Service (QoS) that controls the behavior of the different DDS entities, and allows you to configure the middleware to enable features such as monitoring. To make this process easier, RTI includes a set of built-in QoS profiles that provide useful functionality, such as enabling monitoring or configuring DataWriters and DataReaders to be strictly reliable.

(Available in version 5.1.0 and higher)

The full list of built-in profiles, as of version 6.0.0, is here:

  • In library "BuiltinQosLib":
    • Baseline
    • Baseline.5.0.0
    • Baseline.5.1.0
    • Baseline 5.2.0
    • Baseline 5.3.0
    • Baseline 6.0.0
    • Generic.Common
    • Generic.Monitoring.Common
    • Generic.ConnextMicroCompatibility
    • Generic.ConnextMicroCompatibility.2.4.9
    • Generic.ConnextMicroCompatibility.2.4.3
    • Generic.OtherDDSVendorCompatibility
    • Generic.510TransportCompatibility
    • Generic.Security
  • In library "BuiltinQosLibExp":
    • Generic.StrictReliable
    • Generic.KeepLastReliable
    • Generic.BestEffort
    • Generic.StrictReliable.HighThroughput
    • Generic.StrictReliable.LowLatency
    • Generic.Participant.LargeData
    • Generic.Participant.LargeData.Monitoring
    • Generic.StrictReliable.LargeData
    • Generic.KeepLastReliable.LargeData
    • Generic.StrictReliable.LargeData.FastFlow
    • Generic.StrictReliable.LargeData.MediumFlow
    • Generic.StrictReliable.LargeData.SlowFlow
    • Generic.KeepLastReliable.LargeData.FastFlow
    • Generic.KeepLastReliable.LargeData.MediumFlow
    • Generic.KeepLastReliable.LargeData.SlowFlow
    • Generic.KeepLastReliable.TransientLocal
    • Generic.KeepLastReliable.Transient
    • Generic.KeepLastReliable.Persistent
    • Generic.AutoTuning
    • Generic.MinimalMemoryFootprint
    • Pattern.PeriodicData
    • Pattern.Streaming
    • Pattern.ReliableStreaming
    • Pattern.Event
    • Pattern.AlarmEvent
    • Pattern.Status
    • Pattern.AlarmStatus
    • Pattern.LastValueCache

Example Description

This example shows how to use built-in profiles in both the XML QoS file and in the source code. In the XML, the default QoS profiles described in the file inherit from two different built-in profiles.

1. The overall default profile inherits from the "BuiltinQoSLibExp::Patter.ReliableStreaming" profile: 

<qos_profile name="profiles_Profile" base_name="BuiltinQosLibExp::Pattern.ReliableStreaming" is_default_qos="true"> 

2. The DomainParticipant's QoS overrides this so that the DomainParticipant can inherit directly from a profile that enables monitoring. This allows the DomainParticipant to take its specific behavior from a different profile than the DataWriter and DataReader, since the DomainParticipant's QoS is independent of the reader- and writer-specific streaming reliability QoS:

<participant_qos base_name="BuiltinQosLib::Generic.Monitoring.Common">

In this example, the DomainParticipant is configured to enable monitoring out of the box.

Note that this will require that you link against RTI's dynamic libraries so the monitoring library can be loaded correctly. See the readme within each directory for more details on linking dynamically.

The DataWriter and DataReader are configured with a QoS profile to enable streaming reliable data.

Download Example

Browse Example





I am wondering where could I find detailed description for each of the above built-in profiles and what they are supposed to replace in 5.0.0. Also I would like possibly an example of how to use the profiles for very large data cases. Thanks.


Hello Robert,

There is documentation of all of the built-in profiles shipped with 5.1.0 in our API documentation here.  This includes both the constant and the string representation of all of the profiles.  In 5.0.0 and before you could create your own XML QoS configurations, and there were examples QoS profiles shipped in the ndds.5.0.0/examples/QoS directory, but there were no pre-built QoS profiles that you could access by name.  For large data, there are several configurations you can try, depending on how reliable your data must be, and how quickly it must be received.  Sending large data is a tradeoff between how quickly the data should arrive on the receiver vs. how much bandwidth to use, so there are three tuning options available.

Edit: I forgot to note that you can download the XML file that contains all of the QoS of all of the built-in profiles here

Thank you,