RTI Connext DDS Micro C++ API  2.4.14.2
 All Classes Files Functions Variables Typedefs Enumerations Enumerator Macros Groups
DDS_LivelinessQosPolicy Struct Reference

<<cert>> Determines the mechanism and parameters used by the application to determine whether a DDSEntity is alive. More...

List of all members.

Public Attributes

DDS_LivelinessQosPolicyKind kind
 The kind of liveliness desired.
struct DDS_Duration_t lease_duration
 The duration within which a DDSEntity must be asserted, or else it is assumed to be not alive.

Detailed Description

<<cert>> Determines the mechanism and parameters used by the application to determine whether a DDSEntity is alive.

Liveliness must be asserted at least once every lease_duration otherwise RTI Connext Micro will assume the corresponding DDSEntity or is no longer alive.

The liveliness status of a DDSEntity is used to maintain instance ownership in combination with the setting of the OWNERSHIP policy. The application is also informed via DDSListener when an DDSEntity is no longer alive.

A DDSDataWriter commits to signalling its liveliness using the stated means at intervals not to exceed the lease_duration. That is, a failure by the DDSDataWriter to assert liveliness within its offered lease_duration will result in a DDS_LIVELINESS_LOST_STATUS event.

A DDSDataReader will match a DDSDataWriter if the DDSDataReader's requested lease_duration is equal to or larger than the lease_duration offered by the DDSDataWriter and the offered kind is equal to or better than the requested kind. In addition, a DDSDataReader uses its own lease_duration as the check period to check if a DDSDataWriter was active or not. This means that a DDSDataWriter may be inactive for up to, but not including, twice the DDSDataReader's lease_duration before being detected as inactive by the DDSDataReader. It does not matter when the DDSDataWriter was active, or how many times the DDSDataWriter was active within the last DDSDataReader's lease_duration to be considered inactive.

For example: If a DDSDataReader must detect that a DDSDataWriter was inactive within at most 100ms, both the DDSDataWriter and DDSDataReader must specify a lease_duration of 50ms.

Listeners are used to notify a DDSDataReader of loss of liveliness and DDSDataWriter of violations to the liveliness contract. The on_liveliness_lost() callback is only called once, after the first time the lease_duration is exceeded (when the DDSDataWriter first loses liveliness).

This QoS policy can be used during system integration to ensure that applications have been coded to meet design specifications. It can also be used during run time to detect when systems are performing outside of design specifications. Receiving applications can take appropriate actions in response to disconnected DataWriters.

Entity:
DDSTopic, DDSDataReader, DDSDataWriter
Status:
DDS_LIVELINESS_LOST_STATUS, DDS_LivelinessLostStatus;
DDS_LIVELINESS_CHANGED_STATUS, DDS_LivelinessChangedStatus;
DDS_REQUESTED_INCOMPATIBLE_QOS_STATUS, DDS_OFFERED_INCOMPATIBLE_QOS_STATUS
Properties:
RxO = YES
Changeable = NO

Usage

This policy controls the mechanism and parameters used by RTI Connext Micro to ensure that particular entities on the network are still alive. The liveliness can also affect the ownership of a particular instance, as determined by the OWNERSHIP policy.

This policy has several settings to support both data types that are updated periodically as well as those that are changed sporadically. It also allows customisation for different application requirements in terms of the kinds of failures that will be detected by the liveliness mechanism.

The DDS_AUTOMATIC_LIVELINESS_QOS liveliness setting is most appropriate for applications that only need to detect failures at the process-level, but not application-logic failures within a process. RTI Connext Micro takes responsibility for renewing the leases at the required rates and thus, as long as the local process where a DDSDomainParticipant is running and the link connecting it to remote participants remains connected, the entities within the DDSDomainParticipant will be considered alive. This requires the lowest overhead.

The manual settings (DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS, DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS) require the application on the publishing side to periodically assert the liveliness before the lease expires to indicate the corresponding DDSEntity is still alive. The action can be explicit by calling the DDSDataWriter::assert_liveliness operation or implicit by writing some data.

The two possible manual settings control the granularity at which the application must assert liveliness.

Changes in LIVELINESS must be detected by the Service with a time-granularity greater or equal to the lease_duration. This ensures that the value of the DDS_LivelinessChangedStatus is updated at least once during each lease_duration and the related Listeners are notified within a lease_duration from the time the LIVELINESS changed.

Compatibility

The value offered is considered compatible with the value requested if and only if the following conditions are met:


Member Data Documentation

DDS_LivelinessQosPolicyKind DDS_LivelinessQosPolicy::kind

The kind of liveliness desired.

[default] DDS_AUTOMATIC_LIVELINESS_QOS

struct DDS_Duration_t DDS_LivelinessQosPolicy::lease_duration

The duration within which a DDSEntity must be asserted, or else it is assumed to be not alive.

[default] DDS_DURATION_INFINITE

[range] [0,1 year] or DDS_DURATION_INFINITE


RTI Connext DDS Micro C++ API 2.4.14.2 Copyright © Tue May 28 2024 Real-Time Innovations, Inc