Return to DDS Quality of Service
The LIVELINESS policy controls the mechanism and parameters used by the Service 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 QoS policy.
This policy has several settings to support both data-objects that are updated periodically as well as those that are changed sporadically. It also allows customizing for different application requirements in terms of the kinds of failures that will be detected by the liveliness mechanism.
The AUTOMATIC liveliness setting is most appropriate for applications that only need to detect failures at the processlevel, but not application-logic failures within a process. The Service takes responsibility for renewing the leases at the required rates and thus, as long as the local process where a DomainParticipant
is running and the link connecting it to remote participants remains connected, the entities within the DomainParticipant
will be considered alive. This requires the lowest overhead.
The MANUAL settings (MANUAL_BY_PARTICIPANT, MANUAL_BY_TOPIC), require the application on the publishing
side to periodically assert the liveliness before the lease expires to indicate the corresponding Entity is still alive. The action can be explicit by calling the assert_liveliness
operations, or implicit by writing some data.
The two possible manual settings control the granularity at which the application must assert liveliness.
DomainParticipant
are also alive.The value offered is considered compatible with the value requested if and only if the following conditions are met:
offered kind >= requested kind
evaluates to TRUE
. For the purposes of this inequality, the values of LIVELINESS kind are considered ordered such that: AUTOMATIC < MANUAL_BY_PARTICIPANT < MANUAL_BY_TOPIC
. offered lease_duration ⇐ requested lease_duration
evaluates to TRUE
.
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 LivelinessChangedStatus is updated at least once during each lease_duration and the related Listeners and WaitSets are notified within a lease_duration
from the time the LIVELINESS changed.
Source: DDS 1.4 Spec