DDS QoS - HISTORY

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

18. HISTORY

OpenDDS Developer's Guide（OpenDDS Version 3.14）

The HISTORY policy determines how samples are held in the data writer and data reader for a particular instance. For data writers these values are held until the publisher retrieves them and successfully sends them to all connected subscribers. For data readers these values are held until “taken” by the application. This policy applies to the topic, data reader, and data writer entities via the history member of their respective QoS structures. Below is the IDL related to the history QoS policy:

历史记录策略确定特定实例在数据写入器和数据读取器中如何保存样本。 对于数据编写者，这些值将一直保留到发布者检索到它们并将它们成功发送给所有连接的订户为止。 对于数据读取器，这些值将保留到应用程序“获取”为止。 此策略通过各自的QoS结构的历史记录成员适用于主题、数据读取器和数据写入器实体。 以下是与历史QoS策略相关的IDL：

enum HistoryQosPolicyKind {

KEEP_LAST_HISTORY_QOS,

KEEP_ALL_HISTORY_QOS

};

struct HistoryQosPolicy {

HistoryQosPolicyKind kind;

long depth;

};

The “keep all” value ( KEEP_ALL_HISTORY_QOS ) specifies that all possible samples for that instance should be kept. When “keep all” is specified and the number of unread samples is equal to the “resource limits” field of max_samples_per_instance then any incoming samples are rejected.

“全部保留”值（KEEP_ALL_HISTORY_QOS）指定应保留该实例的所有可能样本。 当指定“全部保留”并且未读样本的数量等于max_samples_per_instance的“资源限制”字段时，则拒绝任何传入的样本。

The “keep last” value ( KEEP_LAST_HISTORY_QOS ) specifies that only the last depth values should be kept. When a data writer contains depth samples of a given instance, a write of new samples for that instance are queued for delivery and the oldest unsent samples are discarded. When a data reader contains depth samples of a given instance, any incoming samples for that instance are kept and the oldest samples are discarded.

“保留最后一个”值（KEEP_LAST_HISTORY_QOS）指定仅保留最后一个深度值。 当数据写入器包含给定实例的深度样本时，该实例的新样本写入将排队等待交付，而最旧的未发送样本将被丢弃。 当数据读取器包含给定实例的深度样本时，该实例的所有传入样本都会保留，最旧的样本将被丢弃。

This policy defaults to a “keep last” with a depth of one.

此策略默认为深度为1的“保留最后”。

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

1) This policy controls the behavior of the Service when the value of an instance changes before it is finally communicated to some of its existing DataReader entities.

1）当实例的值在最终与它的某些现有DataReader实体通信之前发生更改时，此策略控制Service的行为。

2) If the kind is set to KEEP_LAST, then the Service will only attempt to keep the latest values of the instance and discard the older ones. In this case, the value of depth regulates the maximum number of values (up to and including the most current one) the Service will maintain and deliver. The default (and most common setting) for depth is one, indicating that only the most recent value should be delivered.

2）如果将种类设置为KEEP_LAST，则服务将仅尝试保留实例的最新值并丢弃较旧的值。 在这种情况下，深度值可调节服务将维持和提供的最大值数（包括最新值）。 深度的默认值（也是最常用的设置）是1，表示仅应传递最新的值。

3) If the kind is set to KEEP_ALL, then the Service will attempt to maintain and deliver all the values of the instance to existing subscribers. The resources that the Service can use to keep this history are limited by the settings of the RESOURCE_LIMITS QoS. If the limit is reached, then the behavior of the Service will depend on the RELIABILITY QoS. If the reliability kind is BEST_EFFORT, then the old values will be discarded. If reliability is RELIABLE, then the Service will block the DataWriter until it can deliver the necessary old values to all subscribers.

3）如果将种类设置为KEEP_ALL，则服务将尝试维护实例的所有值并将其传递给现有订户。 服务可用于保留此历史记录的资源受RESOURCE_LIMITS QoS的设置限制。 如果达到限制，则服务的行为将取决于可靠性QoS。 如果可靠性类型为BEST_EFFORT，则旧值将被丢弃。 如果可靠性是可靠的，则服务将阻止DataWriter，直到它可以将必要的旧值传递给所有订户。

The setting of HISTORY depth must be consistent with the RESOURCE_LIMITS max_samples_per_instance . For these two QoS to be consistent, they must verify that depth <= max_samples_per_instance .

历史记录深度的设置必须与RESOURCE_LIMITS max_samples_per_instance相一致。 为了使这两个QoS保持一致，它们必须验证 depth<= max_samples_per_instance。

用ChatGPT

《OpenDDS Developer's Guide》:

这段文字的中文翻译以及解释如下：
3.2.4 历史记录（HISTORY）
历史记录策略决定了数据写入者和数据读取者如何为某个特定实例保留样本。对于数据写入者，这些值将被保留，直到发布者取得这些值并成功地将它们发送给所有连接的订阅者。对于数据读取者，这些值将被保留，直到应用程序“取得”这些值。这一策略通过各自的服务质量（QoS）结构中的历史记录成员来适用于主题、数据读取者和数据写入者实体。以下是与历史记录服务质量策略相关的接口定义语言（IDL）：

enum HistoryQosPolicyKind {
    KEEP_LAST_HISTORY_QOS,
    KEEP_ALL_HISTORY_QOS
};

struct HistoryQosPolicy {
    HistoryQosPolicyKind kind;
    long depth;
};

“keep all”（保留全部历史记录_QOS）值指定应该保留该实例的所有可能样本。当指定了“keep all”并且未读样本数量等于“资源限制”字段中的max_samples_per_instance时，则任何新到的样本都将被拒绝。
“keep last”（保留最后历史记录_QOS）值指定应该只保留最后的depth数量的值。当数据写入者含有一个给定实例的depth样本时，对该实例的新样本写入操作将被排队等待传递，并且最老的未发送样本将被丢弃。当数据读取者含有一个给定实例的depth样本时，任何针对该实例的新到样本都将被保留，并且最老的样本将被丢弃。
该策略默认为一个“保留最后”的策略，并且深度为1。
解释说明：
- "历史记录策略"是控制数据在OpenDDS系统中如何被保存和传输的规则。
- 数据写入者（Data Writer）和数据读取者（Data Reader）会根据这个策略来决定保留多少历史数据样本。
- “保留全部”（KEEP_ALL_HISTORY_QOS）策略意味着所有可能的数据样本都会被保存，直到达到资源限制为止。
- “保留最后”（KEEP_LAST_HISTORY_QOS）策略意味着只保留最新的一定数量（depth指定的数量）的数据样本，新到的样本会替换掉旧的样本。
- 此策略对于信息交换的实时性和资源使用有显著影响，适合于不同的应用场景。

《Data Distribution Service (DDS)》Version 1.4 ：

这段内容来自《Data Distribution Service (DDS)》版本 1.4的官方文档，主要描述了HISTORY（历史）服务质量（Quality of Service，QoS）策略。这个策略控制当实例的值变化了，但是还没跟所有现存DataReader实体最终通信前，服务的行为。
1. 当设定为KEEP_LAST（保持最后）时，服务将只尝试保持该实例的最新值并丢弃更旧的值。在这种情况下，depth（深度）的值决定了服务将维护和传递的最大的值数量（包含并限于最新的一个值）。depth的默认（也是最常见的设置）值是1，表示只有最近的一个值应当被传递。
2. 当设定为KEEP_ALL（保持全部）时，服务将尝试维护并传递实例的所有值给现存的订阅者。服务用于保持这个历史记录的资源受RESOURCE_LIMITS（资源限制）QoS设置的限制。如果到达了限制，服务的行为将取决于RELIABILITY（可靠性）QoS。如果可靠性的类型是BEST_EFFORT（尽力而为），那么旧的值将会被丢弃。如果可靠性是RELIABLE（可靠），那么服务将阻塞DataWriter直到它能够将必要的旧值传递给所有的订阅者。
3. HISTORY（历史）深度的设置必须与RESOURCE_LIMITS（资源限制）中的max_samples_per_instance（每个实例的最大样本数）相一致。为了这两个QoS保持一致，它们必须满足depth（深度）小于等于max_samples_per_instance。
这段文本的中文翻译和解释如下：
1.此策略控制服务在实例的值发送给现有DataReader实体之前发生变化时的行为。
2.如果类型设置为KEEP_LAST（保持最新），服务只会尝试保留实例的最新值，并丢弃较旧的值。在这种情况下，depth（深度）的值决定了服务将维护并传递的最大值数量（包括最新的一个）。depth的默认设置（也是最常见的设置）为1，这意味着只有最新的值会被传递。
3.如果类型设置为KEEP_ALL（保持全部），服务将尝试保持并传递所有实例的值至现有的订阅者。服务用于保存这些历史数据的资源受到RESOURCE_LIMITS（资源限制）QoS设置的约束。如果达到了限制，服务的行为会取决于RELIABILITY（可靠性）QoS的设置。如果可靠性类型是BEST_EFFORT（尽力而为），则会丢弃旧的值。如果可靠性是RELIABLE（可靠），服务会阻塞DataWriter，直到它能够将必要的旧值都送达给所有的订阅者。HISTORY的depth设置必须与RESOURCE_LIMITS中的max_samples_per_instance值相一致。为了保证两个QoS设置的一致性，它们必须满足depth小于或等于max_samples_per_instance。