Open topic with navigation

7.5.19 PROPERTY QosPolicy (DDS Extension)

The PROPERTY QosPolicy stores name/value (string) pairs that can be used to configure certain parameters of Connext DDS that are not exposed through formal QoS policies.

It can also be used to store and propagate application-specific name/value pairs that can be retrieved by user code during discovery. This is similar to the USER_DATA QosPolicy, except this policy uses (name, value) pairs, and you can select whether or not a particular pair should be propagated (included in the built-in topic). By default, properties are not propagated during discovery.

It includes the member in Table 7.63 DDS_PropertyQosPolicy.

Table 7.63 DDS_PropertyQosPolicy

Type

Field Name

Description

DDS_PropertySeq

value

A sequence of: (name, value) pairs and booleans that indicate whether the pair should be propagated (included in the entity’s built-in topic upon discovery).

The Property QoS stores name/value pairs for an Entity. Both the name and value are strings. Certain configurable parameters for Entities that do not have a formal DDS QoS definition may be configured via this QoS by using a predefined name and the desired setting in string form.

You can find a complete list of predefined properties in the Property Reference Guide.

You can manipulate the sequence of properties (name, value pairs) with the standard methods available for sequences. You can also use the helper class, DDSPropertyQosPolicyHelper, which provides another way to work with a PropertyQosPolicy object.

The PropertyQosPolicy may be used to configure:

In addition, you can add your own name/value pairs to the Property QoS of an Entity. Start them with a prefix other than dds., com.rti., or rti., so that they do not fail validation. (See 7.5.19.1 Property Validation.) You may also use this QosPolicy to direct Connext DDS to propagate these name/value pairs with the discovery information for the Entity. Applications that discover the Entity can then access the user-specific name/value pairs in the discovery information of the remote Entity. This allows you to add meta-information about an Entity for application-specific use, for example, authentication/authorization certificates (which can also be done using the User or Group Data QoS).

Reasons for using the PropertyQosPolicy include:

The PropertyQosPolicyHelper operations are described in Table 7.64 PropertyQoSPolicyHelper Operations. For more information, see the API Reference HTML documentation.

Table 7.64 PropertyQoSPolicyHelper Operations

Operation

Description

get_number_of_properties

Gets the number of properties in the input policy.

assert_property

Asserts the property identified by name in the input policy. (Either adds it, or replaces an existing one.)

add_property

Adds a new property to the input policy.

assert_pointer_property

Asserts the property identified by name in the input policy.
Used when the property to store is a pointer.

add_pointer_property

Adds a new property to the input policy.
Used when the property to store is a pointer.

lookup_property

Searches for a property in the input policy given its name.

remove_property

Removes a property from the input policy.

get_properties

Retrieves a list of properties whose names match the input prefix.

7.5.19.1 Property Validation

All the properties that Connext DDS provides (which begin with dds., com.rti., or rti.) are validated when the entity or the plugin is created. This validation is done to avoid using an unknown or incorrect property name (for example, due to a typo). Without this validation, Connext DDS ignores the unknown property name, and you might not know why the property's configuration isn't being applied.

By default, at the creation of an entity or a plugin, if you specify an incorrect property name, Connext DDS logs an exception similar to the following:

You can configure the behavior of this validation by setting a property at the DomainParticipant level. The DomainParticipant's DataWriters and DataReaders use the participant's setting. Or you can set the property at the plugin level.

In general, it is recommended that you use dds.participant.property_validation_action to control the validation of the properties for both the Connext DDS core libraries and any plugins you might use. However, there are cases where you might want to configure different behaviors for the core libraries and the plugins. For example, if you are running a customized version of the plugins that supports a new, experimental property, you will need to disable the DomainParticipant validation via dds.participant.property_validation_action, but still keep the plugin validation (for example, dds.transport.TCPv4.tcp1.property_validation_action). Here's an example of disabling the DomainParticipant level validation and enabling a plugin level validation:

<domain_participant_qos>
    <property>
        <value>
            <element>
                <name>dds.participant.property_validation_action</name>
                <value>VALIDATION_ACTION_SKIP</value>
            </element>
            <element>
                <name>dds.transport.TCPv4.tcp1.property_validation_action</name>
                <value>VALIDATION_ACTION_EXCEPTION</value>
            </element>
        </value>
    </property>
</domain_participant_qos>

Note that the validation is sequential: first the property is validated when the DomainParticipant is created, then it is validated when the plugin is created. For example, consider that the DomainParticipant sets the property dds.participant.property_validation_action to VALIDATION_ACTION_EXCEPTION, but the plugin is configured to skip the unknown property. In this case, DomainParticipant creation will fail, and the plugin will never get created. As described above, if you are customizing the plugin, set the validation to VALIDATION_ACTION_SKIP at the DomainParticipant level, then set the plugin property validation to VALIDATION_ACTION_EXCEPTION. By doing that, the properties will be validated just at the plugin level.

You can find a complete list of the Connext DDS predefined properties in the Property Reference Guide.

7.5.19.2 Properties

This QosPolicy can be changed at any time.

There is no requirement that the publishing and subscribing sides use compatible values.

7.5.19.3 Related QosPolicies

7.5.19.4 Applicable Entities

7.5.19.5 System Resource Considerations

The 9.5.4 DOMAIN_PARTICIPANT_RESOURCE_LIMITS QosPolicy (DDS Extension) contains several fields for configuring the resources associated with the properties stored in this QosPolicy.

© 2021 RTI

Open topic with navigation