RTI Connext DDS Micro
Version 2.4.10
|
<<cert>> Determines the mechanism and parameters used by the application to determine whether a DDS_Entity is alive. More...
#include <dds_c_infrastructure.h>
Data Fields | |
DDS_LivelinessQosPolicyKind | kind |
The kind of liveliness desired. | |
struct DDS_Duration_t | lease_duration |
The duration within which a DDS_Entity must be asserted, or else it is assumed to be not alive. |
<<cert>> Determines the mechanism and parameters used by the application to determine whether a DDS_Entity is alive.
<<< Version 2.2.2: Supports MANUAL_BY_TOPIC only >>> Liveliness must be asserted at least once every lease_duration
otherwise RTI Connext Micro will assume the corresponding DDS_Entity or is no longer alive. The liveliness status of a DDS_Entity is used to maintain instance ownership in combination with the setting of the OWNERSHIP policy. The application is also informed via DDS_Listener when an DDS_Entity is no longer alive. A DDS_DataReader requests that liveliness of writers is maintained by the requested means and loss of liveliness is detected with delay not to exceed the lease_duration
. A DDS_DataWriter commits to signalling its liveliness using the stated means at intervals not to exceed the lease_duration
. Listeners are used to notify a DDS_DataReader of loss of liveliness and DDS_DataWriter 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 DDS_DataWriter first loses liveliness).
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. RTI Connext DDS Micro supports the manual setting DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS. It requires the application on the publishing side to periodically assert the liveliness before the lease expires to indicate the corresponding DDS_Entity is still alive. The action can be explicit by calling the DDS_DataWriter_assert_liveliness operation or implicit by writing some data. The two possible manual settings control the granularity at which the application must assert liveliness. The setting DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS requires that at least one instance within the DDS_DataWriter is asserted. 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.
The value offered is considered compatible with the value requested if and only if the following conditions are met:
lease_duration
<= requested lease_duration
evaluates to DDS_BOOLEAN_TRUE. DDS_LivelinessQosPolicyKind DDS_LivelinessQosPolicy::kind |
The kind of liveliness desired.
[default] DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS
struct DDS_Duration_t DDS_LivelinessQosPolicy::lease_duration |
The duration within which a DDS_Entity must be asserted, or else it is assumed to be not alive.
[default] DDS_DURATION_INFINITE [range] [0,1 year] or DDS_DURATION_INFINITE