DDS QoS - LIVELINESS

https://download.csdn.net/download/eidolon_foot/12568768

11. LIVELINESS

OpenDDS Developer's Guide（OpenDDS Version 3.14）

The LIVELINESS policy applies to the topic, data reader, and data writer entities via the liveliness member of their respective QoS structures. Setting this policy on a topic means it is in effect for all data readers and data writers on that topic. Below is the IDL related to the liveliness QoS policy:

LIVELINESS策略通过其各自QoS结构的liveliness成员而应用于主题、数据读取器和数据写入器实体。 在主题上设置此策略意味着该策略对于该主题上的所有数据读取器和数据写入器均有效。 以下是与实时QoS策略相关的IDL：

enum LivelinessQosPolicyKind {

AUTOMATIC_LIVELINESS_QOS,

MANUAL_BY_PARTICIPANT_LIVELINESS_QOS,

MANUAL_BY_TOPIC_LIVELINESS_QOS

};

struct LivelinessQosPolicy {

LivelinessQosPolicyKind kind;

Duration_t lease_duration;

};

The LIVELINESS policy controls when and how the service determines whether participants are alive, meaning they are still reachable and active. The kind member setting indicates whether liveliness is asserted automatically by the service or manually by the specified entity. A setting of AUTOMATIC_LIVELINESS_QOS means that the service will send a liveliness indication if the participant has not sent any network traffic for the lease_duration. The MANUAL_BY_PARTICIPANT_LIVELINESS_QOS or MANUAL_BY_TOPIC_LIVELINESS_QOS setting means the specified entity (data writer for the “by topic” setting or domain participant for the “by participant” setting) must either write a sample or manually assert its liveliness within a specified heartbeat interval. The desired heartbeat interval is specified by the lease_duration member. The default lease duration is a pre-defined infinite value, which disables any liveliness testing.

LIVELINESS策略控制服务何时以及如何确定参与者是否还活着，这意味着他们仍然可以访问并且处于活动状态。 kind成员设置指示是由服务自动断言还是由指定实体手动断言活泼性。 设置为AUTOMATIC_LIVELINESS_QOS意味着，如果参与者没有为lease_duration发送任何网络流量，则该服务将发送活动指示。 MANUAL_BY_PARTICIPANT_LIVELINESS_QOS或MANUAL_BY_TOPIC_LIVELINESS_QOS设置意味着指定的实体（“按主题”设置的数据编写者或“按参与者”设置的域参与者）必须编写样本或在指定的心跳间隔内手动声明其活动性。 所需的心跳间隔由lease_duration成员指定。 默认的租约期限是一个预定义的无限值，它会禁用任何生动性测试。

To manually assert liveliness without publishing a sample, the application must call the assert_liveliness() operation on the data writer (for the “by topic” setting) or on the domain participant (for the “by participant” setting) within the specified heartbeat interval.

若要在不发布示例的情况下手动声明活动级别，则应用程序必须在指定的心跳间隔内对数据编写器（针对“按主题”设置）或域参与者（针对“按参与者”设置）调用assert_liveliness（）操作 。

Data writers specify ( offer ) their own liveliness criteria and data readers specify ( request ) the desired liveliness of their writers. Writers that are not heard from within the lease duration (either by writing a sample or by asserting liveliness) cause a change in the LIVELINESS_CHANGED_STATUS communication status and notification to the application (e.g., by calling the data reader listener’s on_liveliness_changed() callback operation or by signaling any related wait sets).

数据编写者指定（提供）自己的活动性标准，数据编写者指定（请求）其编写者所需的活动性。 在租用期限内未听到的写入者（通过编写示例或通过声明生动性）导致LIVELINESS_CHANGED_STATUS通信状态发生变化并通知应用程序（例如，通过调用数据读取器侦听器的on_liveliness_changed（）回调操作或通过 用信号通知任何相关的等待集）。

This policy is considered during the establishment of associations between data writers and data readers. The value of both sides of the association must be compatible in order for an association to be established. Compatibility is determined by comparing the data reader’s requested liveliness with the data writer’s offered liveliness. Both the kind of liveliness

(automatic, manual by topic, manual by participant) and the value of the lease duration are considered in determining compatibility. The writer’s offered kind of liveliness must be greater than or equal to the reader’s requested kind of liveliness. The liveliness kind values are ordered as follows:

在数据写入者和数据读取者之间建立关联时会考虑此策略。 关联双方的值必须兼容才能建立关联。 兼容性是通过将数据读取器要求的实时性与数据写入器提供的实时性进行比较来确定的。 确定兼容性时，要考虑活泼的类型（自动，按主题手动，按参与者手动）和租用期限的值。 作者提供的生动性必须大于或等于读者要求的生动性。 活度种类值的排序如下：

MANUAL_BY_TOPIC_LIVELINESS_QOS > MANUAL_BY_PARTICIPANT_LIVELINESS_QOS > AUTOMATIC_LIVELINESS_QOS

In addition, the writer’s offered lease duration must be less than or equal to the reader’s requested lease duration. Both of these conditions must be met for the offered and requested liveliness policy settings to be considered compatible and the association

established.

此外，作者提供的租约期限必须小于或等于读者请求的租约期限。 必须同时满足这两个条件，才能将所提供和请求的活动策略设置视为兼容并建立关联。

Data Distribution Service Version 1.4（ formal/2015-04-10）

This 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.

此策略控制服务使用的机制和参数，以确保网络上的特定实体仍然“处于活动状态”。 活泼性还可能影响特定实例的所有权，如OWNERSHIP QoS策略所确定。

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 process- level , 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.

AUTOMATIC liveliness设置最适合只需要在流程级别检测故障，而无需检测流程中的应用程序逻辑故障的应用程序。 该服务负责按要求的费率续订租约，因此，只要运行DomainParticipant的本地进程以及将其连接到远程参与者的链接保持连接状态，DomainParticipant中的实体都将处于活动状态。 这需要最低的开销。

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.

MANUAL设置（MANUAL_BY_PARTICIPANT，MANUAL_BY_TOPIC）要求发布方的应用程序在租约到期之前定期断言活动性，以指示相应的实体仍然有效。 该操作可以通过调用assert_liveliness操作来显式，也可以通过写入一些数据来隐式。

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

两种可能的手动设置控制应用程序必须断言生动性的粒度。

• The setting MANUAL_BY_PARTICIPANT requires only that one Entity within the publisher is asserted to be alive to deduce all other Entity objects within the same DomainParticipant are also alive.

•设置MANUAL_BY_PARTICIPANT仅要求声明发布者中的一个实体是活动的，才能推断出同一DomainParticipant中的所有其他实体对象也是活动的。

• The setting MANUAL_BY_TOPIC requires that at least one instance within the DataWriter is asserted.

•设置MANUAL_BY_TOPIC要求在DataWriter中至少声明一个实例。

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

当且仅当满足以下条件时，才认为提供的值与请求的值兼容：

1) the inequality “offered kind >= requested kind ” evaluates to ‘TRUE’. For the purposes of this inequality, the values of LIVELINESS kind are considered ordered such that:

1）不等式“提供的种类> =请求的种类”计算为“ TRUE”。 出于这种不平等的目的，LIVELINESS类型的值被认为是有序的：

AUTOMATIC < MANUAL_BY_PARTICIPANT < MANUAL_BY_TOPIC.

2) the inequality “offered lease_duration <= requested lease_duration ” evaluates to TRUE.

2）不等式“提供的lease_duration <=请求的lease_duration”的值为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.

服务必须以大于或等于lease_duration的时间粒度来检测LIVELINESS的更改。 这样可以确保在每个lease_duration期间至少将LivelinessChangedStatus的值更新一次，并在LIVELINESS更改之时在lease_duration内通知相关的侦听器和WaitSet。

用ChatGPT

《OpenDDS Developer's Guide》:

这段文本是描述DDS（数据分发服务）标准中的“生存期(Liveliness)”质量服务(QoS)策略。以下是这段文本的中文翻译及解释：
3.2.2 生存期(Liveliness)
生存期(Liveliness)策略通过主题、数据读取器和数据写入器实体的QoS结构中的liveliness成员应用。在主题上设置此策略意味着它对该主题的所有数据读取器和数据写入器生效。以下是与生存期(Liveliness) QoS策略相关的IDL定义：

enum LivelinessQosPolicyKind {
  AUTOMATIC_LIVELINESS_QOS,
  MANUAL_BY_PARTICIPANT_LIVELINESS_QOS,
  MANUAL_BY_TOPIC_LIVELINESS_QOS
};
struct LivelinessQosPolicy {
  LivelinessQosPolicyKind kind;
  Duration_t lease_duration;
};

生存期(Liveliness)策略控制服务何时以及如何确定参与者是否存活，即它们是否仍然可达并且处于活动状态。kind成员设置指示生存性是由服务自动断言还是由指定实体手动断言。如果设置为AUTOMATIC_LIVELINESS_QOS，意味着如果参与者在lease_duration租约期未发送任何网络流量，则服务将发送生存性指示。MANUAL_BY_PARTICIPANT_LIVELINESS_QOS或MANUAL_BY_TOPIC_LIVELINESS_QOS设置意味着指定的实体（对于“按主题”设置的是数据写入器，对于“按参与者”设置的是域参与者）必须在指定的心跳间隔内写入样本或手动断言其生存性。所需的心跳间隔由lease_duration成员指定。默认的租约期限是一个预定义的无限值，它禁用了任何生存期测试。
为了不发布样本而手动断言生存性，应用程序必须在指定的心跳间隔内对数据写入器（对于“按主题”设置）或域参与者（对于“按参与者”设置）调用assert_liveliness()操作。数据写入器指定（提供）它们自己的生存性标准，数据读取器指定（请求）其写入器的期望生存性。在租约期内没有听到来自写入器的消息（要么通过写入样本或断言生存性），将引起LIVELINESS_CHANGED_STATUS通信状态的变化，并通知应用程序（例如，通过调用数据读取器侦听器的on_liveliness_changed()回调操作或通过发出任何相关的等待集合信号）。
在建立数据写入器和数据读取器之间的关联时，会考虑此策略。两边的值必须兼容才能建立关系。兼容性通过比较数据读取器请求的生存性与数据写入器提供的生存性来确定。生存性的种类（自动，手动按主题，手动按参与者）和租约期限的值都会被考虑以确定兼容性。写入器提供的生存性种类必须大于或等于读取器请求的生存性种类。生存性种类值的顺序如下：
MANUAL_BY_TOPIC_LIVELINESS_QOS >
MANUAL_BY_PARTICIPANT_LIVELINESS_QOS >
AUTOMATIC_LIVELINESS_QOS
此外，写入器提供的租约期限必须小于或等于读取器请求的租约期限。这两个条件都必须满足，提供和请求的生存性政策设置才被认为是兼容的，关联才能被建立。

《Data Distribution Service (DDS)》Version 1.4 ：

该段落是关于数据分发服务（DDS）标准中的“LIVELINESS（生存性）”服务质量（QoS）策略。生存性策略用于控制和参数化由服务使用的机制以确保网络上的特定实体仍然“存活”。生存性也可能影响通过所有权QoS策略所确定的某个实例的所有权。以下是中文翻译并加上了一些解释：生存性策略控制服务用来确保网络上特定实体仍然“存活”的机制和参数。生存性也会根据所有权QoS策略影响特定实例的所有权。该策略有多种设置，以支持周期性更新的数据对象以及偶发性变化的数据对象。它还允许根据不同应用程序对失败检测机制的需求来进行定制。当应用程序只需要检测到进程级别的故障（而不需要检测进程内应用逻辑的故障）时，自动（AUTOMATIC）生存性设置是最合适的。服务负责以适当的频率更新租约，因此只要运行DomainParticipant的本地进程和它与远程参与者连接的链接保持连接，DomainParticipant内的实体将被认为是存活的。这要求最低的开销。手动（MANUAL）设置（按参与者手动MANUAL_BY_PARTICIPANT，按主题手动MANUAL_BY_TOPIC）要求发布端的应用程序在租约到期之前定期声明实体的生存性。这种操作可以通过调用assert_liveliness操作显式进行，或者通过写入一些数据隐式进行。这两个可能的手动设置控制应用程序必须声明生存性的粒度：
- 按参与者手动（MANUAL_BY_PARTICIPANT）设置仅要求声明发布者内一个实体的生存性，以推断同一DomainParticipant中的所有其他Entity对象也是活跃的。
- 按主题手动（MANUAL_BY_TOPIC）设置要求至少在DataWriter的一个实例中声明生存性。当且仅当满足以下条件时，所提供的值与所请求的值被认为是兼容的：
1. 表达式“所提供的种类 >= 所请求的种类”评估为“真”。为了这种不等式的目的，生存性种类的值被认为是有序的，其顺序为：
   自动（AUTOMATIC） < 按参与者手动（MANUAL_BY_PARTICIPANT） < 按主题手动（MANUAL_BY_TOPIC）。
2. 表达式“提供的租约持续时间 <= 请求的租约持续时间”评估为真。服务必须至少用与租约持续时间相等或更大的时间粒度来检测生存性的变化。这确保了LivelinessChangedStatus的值至少在每个租约持续时间内更新一次，并且相关的监听器和WaitSets在生存性变化后的一个租约持续时间内得到通知。[27]这里所说的“进程”是指操作系统进程，也就是提供了一些线程执行上下文的地址空间。