DDS QoS - DURABILITY，DURABILITY_SERVICE

109702008

已于 2024-03-08 21:25:50 修改

阅读量1.6k

点赞数 1

分类专栏： DDS 文章标签：网络

于 2020-06-30 09:59:34 首次发布

本文链接：https://blog.csdn.net/eidolon_foot/article/details/107003185

版权

DDS 专栏收录该内容

22 篇文章

订阅专栏

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

4. DURABILITY

OpenDDS:

The DURABILITY policy controls whether data writers should maintain samples after they have been sent to known subscribers. This policy applies to the topic, data reader, and data writer entities via the durability member of their respective QoS structures. Below is the IDL related to the durability QoS policy:

持久性策略控制数据写入者在将样本发送给已知订户之后是否应保留样本。此策略通过其各自QoS结构的durability成员而适用于主题，数据读取器和数据写入器实体。以下是与持久性QoS策略相关的IDL：

enum DurabilityQosPolicyKind {

VOLATILE_DURABILITY_QOS, // Least Durability

TRANSIENT_LOCAL_DURABILITY_QOS,

TRANSIENT_DURABILITY_QOS,

PERSISTENT_DURABILITY_QOS // Greatest Durability

};

struct DurabilityQosPolicy {

DurabilityQosPolicyKind kind;

};

By default the kind is VOLATILE_DURABILITY_QOS .

默认情况下，种类为VOLATILE_DURABILITY_QOS。

A durability kind of VOLATILE_DURABILITY_QOS means samples are discarded after being sent to all known subscribers. As a side effect, subscribers cannot recover samples sent before they connect.

持久性为VOLATILE_DURABILITY_QOS意味着将样本发送给所有已知订户后将其丢弃。副作用是，订户无法恢复在连接之前发送的样本。

A durability kind of TRANSIENT_LOCAL_DURABILITY_QOS means that data readers that are associated/connected with a data writer will be sent all of the samples in the data writer’s history.

持久性TRANSIENT_LOCAL_DURABILITY_QOS意味着与数据写入器关联/连接的数据读取器将被发送数据写入器历史记录中的所有样本。

A durability kind of TRANSIENT_DURABILITY_QOS means that samples outlive a data writer and last as long as the process is alive. The samples are kept in memory, but are not persisted to permanent storage. A data reader subscribed to the same topic and partition within the same domain will be sent all of the cached samples that belong to the same topic/partition.

持久性TRANSIENT_DURABILITY_QOS意味着采样在数据写入器中寿命更长，并且只要过程仍然存在就可以持续。样本将保留在内存中，但不会永久保存。订阅了同一域中同一主题和分区的数据读取器将被发送属于同一主题/分区的所有缓存样本。

A durability kind of PERSISTENT_DURABILITY_QOS provides basically the same functionality as transient durability except the cached samples are persisted and will survive process destruction.

持久性PERSISTENT_DURABILITY_QOS提供与瞬态持久性基本相同的功能，不同之处在于持久性保留了缓存的样本并将在过程破坏后继续存在。

When transient or persistent durability is specified, the DURABILITY_SERVICE QoS policy specifies additional tuning parameters for the durability cache.

如果指定了临时或持久性持久性，则DURABILITY_SERVICE QoS策略为持久性缓存指定其他调整参数。

The durability policy is considered during the creation 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 created. The durability kind value of the data writer must be greater than or equal to the corresponding value of the data reader. The durability kind values are ordered as follows:

在创建数据写入者和数据读取者之间的关联时会考虑持久性策略。关联双方的值必须兼容才能创建关联。数据写入器的持久性种类值必须大于或等于数据读取器的相应值。持久性种类值的排序如下：

PERSISTENT_DURABILITY_QOS > TRANSIENT_DURABILITY_QOS > TRANSIENT_LOCAL_DURABILITY_QOS > VOLATILE_DURABILITY_QOS

formal/2015-04-10:

The decoupling between DataReader and DataWriter offered by the Publish/Subscribe paradigm allows an application to write data even if there are no current readers on the network. Moreover, a DataReader that joins the network after some data has been written could potentially be interested in accessing the most current values of the data as well as potentially some history. This QoS policy controls whether the Service will actually make data available to late-joining readers. Note that although related, this does not strictly control what data the Service will maintain internally. That is, the Service may choose to maintain some data for its own purposes (e.g., flow control) and yet not make it available to late-joining readers if the DURABILITY QoS policy is set to VOLATILE.

由发布/订阅范例提供的DataReader和DataWriter之间的解耦使应用程序即使在网络上当前没有读取器的情况下也可以写入数据。此外，在已写入某些数据之后加入网络的DataReader可能对访问数据的最新值以及某些历史记录感兴趣。此QoS策略控制该服务是否实际将数据提供给后来加入的读者。请注意，尽管相关，但这并不严格控制服务将在内部维护哪些数据。也就是说，如果DURABILITY QoS策略设置为VOLATILE，则服务可能会选择出于其自身目的（例如，流控制）维护某些数据，不会使这些数据可供后来加入的读者使用。

The value offered is considered compatible with the value requested if and only if the inequality “offered kind >= requested kind” evaluates to ‘TRUE.’ For the purposes of this inequality, the values of DURABILITY kind are considered ordered such that VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT.

当且仅当不等式“提供的种类> =请求的种类”评估为“ TRUE”时，才认为提供的值与请求的值兼容。出于这种不等式的目的，将DURABILITY类型的值视为有序的，使得VOLATILE <TRANSIENT_LOCAL <TRANSIENT <PERSISTENT。

For the purpose of implementing the DURABILITY QoS kind TRANSIENT or PERSISTENT, the service behaves “as if” for each Topic that has TRANSIENT or PERSISTENT DURABILITY kind there was a corresponding “built-in” DataReader and DataWriter configured to have the same DURABILITY kind. In other words, it is “as if” somewhere in the system (possibly on a remote node) there was a “built-in durability DataReader” that subscribed to that Topic and a “built-in durability DataWriter” that published that Topic as needed for the new subscribers that join the system.

为了实现持久性QoS类型的暂时性或持久性，服务的行为“好像”对于每个具有暂时性或持久性类型的主题，都有相应的“内置”DataReader和DataWriter配置为具有相同的持久性类型。换句话说，它“好像”在系统的某个地方（可能在远程节点上），有一个“内置的持久性数据读取器”订阅了该主题，而“内置持久性数据编写器”根据需要为加入系统的新订户发布了该主题。

For each Topic, the built-in fictitious “persistence service” DataReader and DataWriter has its QoS configured from the Topic QoS of the corresponding Topic. In other words, it is “as-if” the service first did find_topic to access the Topic, and then used the QoS from the Topic to configure the fictitious built-in entities.

对于每个主题，内置的虚拟“持久性服务” DataReader和DataWriter的QoS是根据相应主题的主题QoS配置的。换句话说，“as-if”就是服务首先执行find_topic访问主题，然后使用主题的QoS来配置虚拟的内置实体。

A consequence of this model is that the transient or persistence serviced can be configured by means of setting the proper QoS on the Topic.

该模型的结果是，可以通过在主题上设置适当的QoS来配置所服务的瞬态或持久性。

For a given Topic, the usual request/offered semantics apply to the matching between any DataWriter in the system that writes the Topic and the built-in transient/persistent DataReader for that Topic; similarly for the built-in transient/persistent DataWriter for a Topic and any DataReader for the Topic. As a consequence, a DataWriter that has an incompatible QoS with respect to what the Topic specified will not send its data to the transient/persistent service, and a DataReader that has an incompatible QoS with respect to the specified in the Topic will not get data from it.

对于给定的主题，通常的请求/提供的语义适用于编写该主题的系统中的任何DataWriter与该主题的内置瞬态/持久DataReader之间的匹配；对于主题的内置瞬态/持久性DataWriter和该主题的任何DataReader，也是如此。结果，与主题指定的QoS不兼容的DataWriter不会将其数据发送到瞬态/持久性服务，而与主题指定的QoS不兼容的DataReader不会获取数据从中。

Incompatibilities between local DataReader/ DataWriter entities and the corresponding fictitious “built-in transient/persistent entities” cause the REQUESTED_INCOMPATIBLE_QOS/OFFERED_INCOMPATIBLE_QOS status to change and the corresponding Listener invocations and/or signaling of Condition and WaitSet objects as they would with non-fictitious entities.

本地DataReader / DataWriter实体与相应的虚拟“内置瞬态/持久性实体”之间的不兼容会导致REQUESTED_INCOMPATIBLE_QOS / OFFERED_INCOMPATIBLE_QOS状态发生更改，并且相应的Listener调用和/或Condition和WaitSet对象的信号通知将与非虚拟实体一样。

The setting of the service_cleanup_delay controls when the TRANSIENT or PERSISTENT service is able to remove all information regarding a data-instances. Information on a data-instances is maintained until the following conditions are met:

service_cleanup_delay的设置控制TRANSIENT或PERSISTENT服务何时能够删除有关数据实例的所有信息。在满足以下条件之前，将一直保留有关数据实例的信息：

1. the instance has been explicitly disposed ( instance_state = NOT_ALIVE_DISPOSED), and

1.实例已被明确处置（instance_state = NOT_ALIVE_DISPOSED），并且

2. while in the NOT_ALIVE_DISPOSED state the system detects that there are no more “live” DataWriter entities writing the instance, that is, all existing writers either unregister the instance (call unregister) or lose their liveliness, and

2.当处于NOT_ALIVE_DISPOSED状态时，系统检测到不再有“实时” DataWriter实体在写入该实例，也就是说，所有现有的写入者要么注销该实例（调用注销），要么失去其活跃性，并且

3. a time interval longer that service_cleanup_delay has elapsed since the moment the service detected that the previous two conditions were met.

3.自从服务检测到满足前两个条件的那一刻起，经过了更长的时间间隔service_cleanup_delay。

The utility of the service_cleanup_delay is apparent in the situation where an application disposes an instance and it crashes before it has a chance to complete additional tasks related to the disposition. Upon re-start the application may ask for initial data to regain its state and the delay introduced by the service_cleanup_delay will allow the restarted application to receive the information on the disposed instance and complete the interrupted tasks.

service_cleanup_delay的实用程序在以下情况下很明显：应用程序处理实例，并且在有机会完成与该处理有关的其他任务之前崩溃。重新启动后，应用程序可能会要求初始数据恢复其状态，而service_cleanup_delay引入的延迟将允许重新启动的应用程序接收有关已处置实例的信息并完成中断的任务。

5. DURABILITY_SERVICE

OpenDDS:

The DURABILITY_SERVICE policy controls deletion of samples in TRANSIENT or PERSISTENT durability cache. This policy applies to the topic and data writer entities via the durability_service member of their respective QoS structures and provides a way to specify HISTORY and RESOURCE_LIMITS for the sample cache. Below is the IDL related to the durability service QoS policy:

DURABILITY_SERVICE策略控制在TRANSIENT或PERSISTENT持久性缓存中删除样本。此策略通过其各自QoS结构的durability_service成员适用于主题和数据写入者实体，并提供了一种为样本缓存指定HISTORY和RESOURCE_LIMITS的方式。以下是与持久性服务QoS策略相关的IDL：

struct DurabilityServiceQosPolicy {

Duration_t service_cleanup_delay;

HistoryQosPolicyKind history_kind;

long history_depth;

long max_samples;

long max_instances;

long max_samples_per_instance;

};

The history and resource limits members are analogous to, although independent of, those found in the HISTORY and RESOURCE_LIMITS policies. The service_cleanup_delay can be set to a desired value. By default, it is set to zero, which means never clean up cached samples.

虽然历史记录和资源限制成员与HISTORY和RESOURCE_LIMITS策略中的成员相似，但彼此独立。可以将service_cleanup_delay设置为所需值。默认情况下，它设置为零，这意味着从不清除缓存的样本。

formal/2015-04-10:

This policy is used to configure the HISTORY QoS and the RESOURCE_LIMITS QoS used by the fictitious DataReader and DataWriter used by the “persistence service.” The “persistence service” is the one responsible for implementing the DURABILITY kinds TRANSIENT and PERSISTENCE (see 2.2.3.4).

此策略用于配置“持久性服务”使用的虚拟DataReader和DataWriter使用的HISTORY QoS和RESOURCE_LIMITS QoS。 “持久性服务”是负责实现持久性类型“瞬态”和“持久性”的一项（请参见4）。

用ChatGPT翻译

《OpenDDS Developer's Guide》

3.2.5 持久性（DURABILITY）
持久性策略控制数据写入者是否应在已发送给已知订阅者的样本（数据）后保留这些样本。这个策略适用于主题、数据读取器和数据写入器实体，通过它们各自的QoS结构中的持久性成员来实施。以下是与持久性QoS策略相关的IDL：

enum DurabilityQosPolicyKind {
    VOLATILE_DURABILITY_QOS,              // 最小的持久性
    TRANSIENT_LOCAL_DURABILITY_QOS,       //
    TRANSIENT_DURABILITY_QOS,             //
    PERSISTENT_DURABILITY_QOS             // 最大的持久性
};

struct DurabilityQosPolicy {
    DurabilityQosPolicyKind kind;
};

默认情况下，类型（kind）为`VOLATILE_DURABILITY_QOS`。
VOLATILE_DURABILITY_QOS表示样本在发送给所有已知的订阅者后将被丢弃。因此，订阅者无法恢复在它们连接之前发送的样本。
TRANSIENT_LOCAL_DURABILITY_QOS表示与数据写入者关联/连接的数据读取器将会被发送数据写入者历史中的所有样本。
TRANSIENT_DURABILITY_QOS表示样本比数据写入者有更长的生命周期，并且会一直持续到进程存活为止。样本虽保存在内存中，但并未持久化到永久存储中。订阅了同一主题和分区的数据读取器会在同一域中收到所有属于同一主题/分区的缓存样本。
PERSISTENT_DURABILITY_QOS提供了与瞬态持久性（transient durability）基本相同的功能，但它会持久化缓存样本，并且这些样本会在进程销毁后继续存在。
当指定瞬态或持久性持久性时，`DURABILITY_SERVICE` QoS策略指定了持久性缓存的额外调整参数。
在数据写入者和数据读取者之间建立关联时，会考虑持久性策略。为了建立关系，双方的值必须兼容。数据写入者的持久性种类值必须大于或等于数据读取者对应的值。持久性种类值的顺序如下：
PERSISTENT_DURABILITY_QOS > TRANSIENT_DURABILITY_QOS > TRANSIENT_LOCAL_DURABILITY_QOS > VOLATILE_DURABILITY_QOS
3.2.6 持久性服务（DURABILITY_SERVICE）
持久性服务策略控制`TRANSIENT`或`PERSISTENT`持久性缓存中的样本删除。这个策略适用于主题和数据写入器实体，通过它们各自的QoS结构中的`durability_service`成员来实施，并提供了一种指定样本缓存的`HISTORY`和`RESOURCE_LIMITS`的方法。以下是与持久性服务QoS策略相关的IDL：

struct DurabilityServiceQosPolicy {
    Duration_t service_cleanup_delay;            // 服务清理延迟
    HistoryQosPolicyKind history_kind;           // 历史种类
    long history_depth;                          // 历史深度
    long max_samples;                            // 最大样本数
    long max_instances;                          // 最大实例数
    long max_samples_per_instance;               // 每个实例的最大样本数
};

历史和资源限制成员类似于但独立于在`HISTORY`和`RESOURCE_LIMITS`策略中发现的那些。`service_cleanup_delay`可以设置为期望值。默认情况下，它被设置为零，意味着永远不清理缓存的样本。

《Data Distribution Service (DDS)》Version 1.4 ：

3.2.3.4 可靠性
发布/订阅范式(DataReader和DataWriter分离)使得应用程序能够在没有读者的情况下写入数据。此外，如果在一些数据写入后加入网络的DataReader可能对获取数据的最新值以及可能的一些历史记录感兴趣。此QoS策略控制着服务是否会让后来加入的读者获得数据。注意，尽管相关，这并不严格控制服务将内部维护什么数据。也就是说，服务可能会选择维护一些数据用于自身目的（例如流量控制），但如果将DURABILITY QoS策略设置为VOLATILE，则不会使其适用于后来加入的读者。
提供的值与请求的值兼容当且仅当不等式“提供的类型 >= 请求的类型”评估为“TRUE”。为此不等式之目的，DURABILITY种类的值被认为是有顺序的，使得VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT。
为了实现DURABILITY QoS种类为TRANSIENT或PERSISTENT的目的，服务“好像”对于每个拥有TRANSIENT或PERSISTENT DURABILITY种类的主题，都有一个相应的“内置”DataReader和DataWriter配置为拥有相同的DURABILITY种类。换句话说，就好像系统中的某个地方（可能是远程节点）有一个“内置的可靠性DataReader”，它订阅了该主题，并且有一个“内置的可靠性DataWriter”，它根据需要为新加入系统的订阅者发布该主题。
对每个主题而言，内置的虚构“持久性服务”DataReader和DataWriter的QoS是根据相应主题的主题QoS配置的。换句话说，就好像服务首先执行了find_topic以访问主题，然后使用主题的QoS来配置虚构的内置实体。
这个模型的一个后果是，通过设置主题上适当的QoS，可以配置瞬变或持久性服务。
对于给定主题，任何在系统中写该主题的DataWriter与内置的瞬变/持久DataReader之间的匹配，以及对于该主题的内置瞬变/持久DataWriter和任何DataReader之间的匹配，都适用常规的请求/提供的语义。因此，与主题指定的QoS不兼容的DataWriter将不会将其数据发送给瞬变/持久服务，同样，与主题中指定的QoS不兼容的DataReader将不会从中获取数据。
本地DataReader/DataWriter实体与相应的虚构“内置瞬变/持久实体”之间的不兼容性将导致REQUESTED_INCOMPATIBLE_QOS/OFFERED_INCOMPATIBLE_QOS状态发生变化，以及相应的监听器调用和/或条件和WaitSet对象的信号，就像它们与非虚构实体一样。
service_cleanup_delay的设置控制着瞬变或持久服务何时可以移除有关数据实例的所有信息。在一下条件达成后，将维护有关数据实例的信息：
1.实例已明确处置（instance_state = NOT_ALIVE_DISPOSED），并且
2.在NOT_ALIVE_DISPOSED状态下，系统检测到没有更多“活动的”DataWriter实体正在写入实例，即所有现有的写入者要么取消注册实例（调用unregister）要么失去了活力，并且
3.自服务检测到上述两个条件已满足以来，已经过去了比service_cleanup_delay更长的时间间隔。
service_cleanup_delay的用处在于，当应用程序处置了一个实例并且在它有机会完成与处置相关的额外任务之前崩溃的情况下，重新启动后的应用程序可能会要求初步数据以恢复其状态，并且由service_cleanup_delay引入的延迟将允许重新启动的应用程序接收有关处置实例的信息并完成中断的任务。
2.2.3.5 可靠性服务
此策略用于配置由“持久性服务”所使用的虚构DataReader和DataWriter的HISTORY QoS和RESOURCE_LIMITS QoS。"持久性服务"负责实现DURABILITY种类TRANSIENT和PERSISTENCE（见2.2.3.4）。