What settings affect DomainParticipant’s liveliness?

Participants are able to know when other participants in the same domain are alive or not. This is called Participant’s Liveliness. DiscoveryConfigQosPolicy has three properties that define this Participant’s Liveliness behavior:

  1. participant_liveliness_assert_period is the period of time at which the participant sends out packets asserting that it is alive (DATA(p) in Wireshark). If you set participant_liveliness_assert_period = 5 seconds, the local participant will declare itself alive at most every 5 seconds.

  1. participant_liveliness_lease_duration is the time period after which remote participants can consider this participant dead. If remote participants don't receive any messages asserting that this participant is alive, they will declare it dead (stale). For example, if the local participant has participant_liveliness_lease_duration to 30 seconds, remote participants will declare this local participant as not alive if within 30 seconds they don't receive any “assert liveliness message”.

  1. max_liveliness_loss_detection_period determines the rate at which the local participant checks if any remote participant has been declared dead/alive. So, the less duration the more frequently this is checked.

participant_liveliness_assert_period and max_liveliness_loss_detection_period are applied locally. But participant_liveliness_lease_duration is a property that by definition must be applied in remote participants. Thus, this information must be exchanged in order to be applied remotely. This exchange is done in the discovery phase.

For example, consider the following configuration for two DomainParticipants (Participant A and Participant B):

  • participant_liveliness_assert_period = 30 seconds

  • participant_liveliness_lease_duration = 100 seconds

  • max_liveliness_loss_detection_period = 5 seconds

     

Figure 1: Different scenarios where B is checking if A is alive every 5 second

 

Let’s focus on Participant A. A is declaring itself alive every 30 seconds and B expects to receive an “alive message” at least every 100 seconds. B checks if A is alive every 5 seconds. If participant A goes away (is dead) and stops sending messages, the following situations (represented in Figure 1) can take place:

  • Last time B checked was at second 95.1 right after it got the last liveliness message from A. Next time B will check will be in second 100.1. This time, B has realized that A is dead 0.1 seconds after lease duration.

  • Last time B checked if A is alive was at second 99.9 right after it got a liveliness message from A. Next time B will check will be in second 104.9. Now, B has realized that A is dead 4.9 seconds after lease duration.

Note that once participant_liveliness_lease_duration expires, B will never take longer than max_liveliness_loss_detection_period to realize A is gone.

 
Keywords: