DDS QoS

最新推荐文章于 2024-04-29 17:40:43 发布

_ace_313_

最新推荐文章于 2024-04-29 17:40:43 发布

阅读量4k

点赞数 9

分类专栏： DDS

本文链接：https://blog.csdn.net/anxuecheng0313/article/details/115398488

版权

DDS 专栏收录该内容

9 篇文章 9 订阅

订阅专栏

1.USER_DATA

USER_DATA策略通过各自的QoS结构的user_data成员应用于域参与者、数据读取器和数据写入器实体。以下是与用户数据QoS策略相关的IDL：

   struct UserDataQosPolicy {
       sequence<octet> value;
   };
默认情况下，未设置值成员。可以将其设置为可用于将信息附加到创建的实体的任何八位位组序列。 USER_DATA策略的值在相应的内置主题数据中可用。远程应用程序可以通过内置主题获取信息，并将其用于自己的目的。例如，应用程序可以通过USER_DATA策略附加安全凭证，远程应用程序可以使用该凭证来认证源。
此QoS的目的是允许应用程序将附加信息附加到创建的Entity对象上，这样，当远程应用程序发现它们的存在时，它可以访问该信息并将其用于自己的目的。此QoS的一种可能用途是附加安全凭证或远程应用程序可以用来验证源身份的某些其他信息。与ignore_participant，ignore_publication，ignore_subscription和ignore_topic等操作结合使用，这些QoS可以帮助应用程序定义和实施其自己的安全策略。此QoS的使用不仅限于安全性，还提供了一种简单而灵活的扩展机制。

2.TOPIC_DATA

TOPIC_DATA策略通过TopicQoS结构的topic_data成员应用于主题实体。以下是与主题数据QoS策略相关的IDL：
   struct TopicDataQosPolicy {
       sequence<octet> value;
   };
默认情况下，未设置该值。可以设置为将附加信息附加到创建的主题。数据写入器，数据读取器和主题内置主题数据中提供了TOPIC_DATA策略的值。远程应用程序可以通过内置主题获取信息，并以应用程序定义的方式使用它。
此QoS的目的是允许应用程序将附加信息附加到已创建的主题，以便当远程应用程序发现其存在时，可以检查该信息并以应用程序定义的方式使用它。结合DataReader和DataWriter上的侦听器以及通过诸如ignore_topic之类的操作，这些QoS可以帮助应用程序扩展提供的QoS。

3.GROUP_DATA

GROUP_DATA策略通过它们各自的QoS结构的group_data成员应用于发布者和订阅者实体。以下是与组数据QoS策略相关的IDL：
   struct GroupDataQosPolicy {
       sequence<octet> value;
   };
默认情况下，未设置值成员。可以设置为将附加信息附加到创建的实体。 GROUP_DATA策略的值通过内置主题传播。数据写入器内置主题数据包含来自发布者的GROUP_DATA，而数据读取器内置主题数据包含来自订阅者的GROUP_DATA。 GROUP_DATA策略可用于实现与PARTITION策略类似的匹配机制，但可以基于应用程序定义的策略进行决策。
此QoS的目的是允许应用程序将附加信息附加到创建的发布者或订阅者。 GROUP_DATA的值可用于DataReader和DataWriter实体上的应用程序，并通过内置主题传播。
应用程序可以通过与DataReaderListener和DataWriterListener组合使用此QoS来实现与PARTITION QoS相似的匹配策略，但可以基于应用程序定义的策略进行决策。

4. DURABILITY

持久性策略控制数据写入者在将样本发送给已知订户之后是否应保留样本。此策略通过其各自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;
   };
默认情况下，种类为VOLATILE_DURABILITY_QOS。
   持久性为VOLATILE_DURABILITY_QOS意味着将样本发送给所有已知订户后将其丢弃。副作用是，订户无法恢复在连接之前发送的样本。
   持久性TRANSIENT_LOCAL_DURABILITY_QOS意味着与数据写入器关联/连接的数据读取器将被发送数据写入器历史记录中的所有样本。
   持久性TRANSIENT_DURABILITY_QOS意味着采样在数据写入器中寿命更长，并且只要过程仍然存在就可以持续。样本将保留在内存中，但不会永久保存。订阅了同一域中同一主题和分区的数据读取器将被发送属于同一主题/分区的所有缓存样本。
   持久性PERSISTENT_DURABILITY_QOS提供与瞬态持久性基本相同的功能，不同之处在于持久性保留了缓存的样本并将在过程破坏后继续存在。
如果指定了临时或持久性持久性，则DURABILITY_SERVICE QoS策略为持久性缓存指定其他调整参数。
在创建数据写入者和数据读取者之间的关联时会考虑持久性策略。关联双方的值必须兼容才能创建关联。数据写入器的持久性种类值必须大于或等于数据读取器的相应值。持久性种类值的排序如下：
   PERSISTENT_DURABILITY_QOS > TRANSIENT_DURABILITY_QOS > TRANSIENT_LOCAL_DURABILITY_QOS > VOLATILE_DURABILITY_QOS
由发布/订阅范例提供的DataReader和DataWriter之间的解耦使应用程序即使在网络上当前没有读取器的情况下也可以写入数据。此外，在已写入某些数据之后加入网络的DataReader可能对访问数据的最新值以及某些历史记录感兴趣。此QoS策略控制该服务是否实际将数据提供给后来加入的读者。请注意，尽管相关，但这并不严格控制服务将在内部维护哪些数据。也就是说，如果DURABILITY QoS策略设置为VOLATILE，则服务可能会选择出于其自身目的（例如，流控制）维护某些数据，不会使这些数据可供后来加入的读者使用。
对于每个主题，内置的虚拟“持久性服务” DataReader和DataWriter的QoS是根据相应主题的主题QoS配置的。换句话说，“as-if”就是服务首先执行find_topic访问主题，然后使用主题的QoS来配置虚拟的内置实体。该模型的结果是，可以通过在主题上设置适当的QoS来配置所服务的瞬态或持久性。
对于给定的主题，通常的请求/提供的语义适用于编写该主题的系统中的任何DataWriter与该主题的内置瞬态/持久DataReader之间的匹配；对于主题的内置瞬态/持久性DataWriter和该主题的任何DataReader，也是如此。结果，与主题指定的QoS不兼容的DataWriter不会将其数据发送到瞬态/持久性服务，而与主题指定的QoS不兼容的DataReader不会获取数据从中。
本地DataReader / DataWriter实体与相应的虚拟“内置瞬态/持久性实体”之间的不兼容会导致REQUESTED_INCOMPATIBLE_QOS / OFFERED_INCOMPATIBLE_QOS状态发生更改，并且相应的Listener调用和/或Condition和WaitSet对象的信号通知将与非虚拟实体一样。
service_cleanup_delay的设置控制TRANSIENT或PERSISTENT服务何时能够删除有关数据实例的所有信息。在满足以下条件之前，将一直保留有关数据实例的信息：
   1.实例已被明确处置（instance_state = NOT_ALIVE_DISPOSED），并且
   2.当处于NOT_ALIVE_DISPOSED状态时，系统检测到不再有“实时” DataWriter实体在写入该实例，也就是说，所有现有的写入者要么注销该实例（调用注销），要么失去其活跃性，并且
   3.自从服务检测到满足前两个条件的那一刻起，经过了更长的时间间隔service_cleanup_delay。
service_cleanup_delay的实用程序在以下情况下很明显：应用程序处理实例，并且在有机会完成与该处理有关的其他任务之前崩溃。重新启动后，应用程序可能会要求初始数据恢复其状态，而service_cleanup_delay引入的延迟将允许重新启动的应用程序接收有关已处置实例的信息并完成中断的任务。

5. DURABILITY_SERVICE

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设置为所需值。默认情况下，它设置为零，这意味着从不清除缓存的样本。
此策略用于配置“持久性服务”使用的虚拟DataReader和DataWriter使用的HISTORY QoS和RESOURCE_LIMITS QoS。 “持久性服务”是负责实现持久性类型“瞬态”和“持久性”的一项

6. PRESENTATION

表示QoS策略控制如何将发布者对实例所做的更改呈现给数据读取器。它会影响这些更改的相对顺序和顺序的范围。此外，此策略引入了一致性变更集的概念。以下是演示QoS的IDL：

   enum PresentationQosPolicyAccessScopeKind {
       INSTANCE_PRESENTATION_QOS,
       TOPIC_PRESENTATION_QOS,
       GROUP_PRESENTATION_QOS
   };
   struct PresentationQosPolicy {
       PresentationQosPolicyAccessScopeKind access_scope;
       boolean coherent_access;
       boolean ordered_access;
   };
这些更改的范围（access_scope）指定了应用程序可以感知的级别：
   –INSTANCE_PRESENTATION_QOS（默认值）表示实例的更改是独立发生的。实例访问本质上是对一致性访问和有序访问的no-op。将这些值设置为true在订阅应用程序中没有明显的影响。
   –TOPIC_PRESENTATION_QOS表示接受的更改仅限于同一数据读取器或数据写入器中的所有实例。
   –GROUP_PRESENTATION_QOS表示接受的更改仅限于同一发布服务器或订阅服务器内的所有实例。

一致的变更（一致的存取）允许一个实例的一个或多个变更作为单一变更提供给相关的资料阅读器。如果数据读取器没有接收到发布者所做的全部一致更改，则所有更改都不可用。一致变化的语义本质上与许多关系数据库提供的事务中的语义相似。默认情况下，consistent_access为false。
也可以按发布者发送的顺序（按顺序访问）向关联的数据读取器提供更改。这在本质上类似于目的地的顺序QoS策略，但是有序的访问允许数据独立于实例排序进行排序。默认情况下，有序访问为false。
此策略控制提供给订阅服务器的示例的顺序和范围，但是订阅服务器应用程序必须在读取示例时使用正确的逻辑来保证请求的行为。有关详细信息。
这种QoS策略控制对数据实例的更改可以相互依赖的程度，以及服务可以传播和维护的依赖类型。
coherent_access的设置控制服务是否通过begin_coherent_change和end_coherent_change操作来保存发布应用程序所做的更改分组。
ordered_access的设置控制服务是否保留更改顺序。
粒度由access_scope的设置控制。

如果设置了coherent_access，则access_scope控制coherent changes的最大范围。其行为如下：
如果access_scope设置为INSTANCE，那么使用begin_coherent_change和end_coherent_change对订阅者访问数据的方式没有影响，因为作用域仅限于每个实例，对单独实例的更改被视为独立的，因此不能通过一致性更改进行分组。
如果access_scope设置为TOPIC，则一致性更改（由其在begin_coherent_change和end_coherent_change的调用中的范围指示）将独立地提供给每个远程数据读取器。也就是说，对每个单独DataWriter中实例所做的更改将与对同一DataWriter中实例的其他更改一致，但不会与对属于不同DataWriter的实例所做的更改分组。
如果access_scope设置为GROUP，则通过连接到common Publisher的DataWriter对实例所做的一致更改作为一个单元提供给远程订阅者。
如果设置了有序访问，则访问范围控制服务将为其保留顺序的最大范围。
如果access_scope设置为INSTANCE（最低级别），则相对于对任何其他实例的更改，对每个实例的更改都被视为无序的。这意味着对两个实例所做的更改（创建、删除、修改）不一定按发生的顺序来查看。即使是同一个应用程序线程使用同一个DataWriter进行更改，也是如此。
如果access_scope设置为TOPIC，则单个DataWriter所做的更改（创建、删除、修改）将以相同的顺序提供给订阅服务器。通过不同的DataWriter实体对实例所做的更改不一定按发生的顺序显示。即使更改是由单个应用程序线程使用附加到同一发布服务器的DataWriter对象进行的，也是如此。
最后，如果access_scope设置为GROUP，则通过附加到同一Publisher对象的DataWriter实体对实例所做的更改将以发生的相同顺序提供给订阅服务器。
当且仅当满足以下条件时，所提供的值才被视为与请求值兼容：
   1 不等式“provided access_scope>=required access_scope”的计算结果为“TRUE”。出于该不等式的目的，PRESENTATION access_scope的值被认为是有序的，因此INSTANCE<TOPIC<GROUP。
   2 请求的一致性访问为FALSE，否则提供的和请求的一致性访问都为TRUE。
   3 请求的有序访问为FALSE，否则提供的和请求的有序访问都为TRUE。

7.DEADLINE

DEADLINE QoS策略允许应用程序检测在指定的时间内未写入或读取数据的时间。此策略通过各自QoS结构的截止日期成员适用于主题、数据写入者和数据读取者实体。以下是与期限QoS策略相关的IDL。
   struct DeadlineQosPolicy {
       Duration_t period;
   };
期间成员的默认值是无穷大，不需要任何行为。当此策略设置为有限值时，数据写入器将监视应用程序对数据所做的更改，并通过设置相应的状态条件并触发on_offered_deadline_missed（）侦听器回调来指示无法遵守该策略。数据读取器在该期限到期之前检测到数据未更改，将设置相应的状态条件，并触发on_requested_deadline_missed（）侦听器回调。
在创建数据写入者和数据读取者之间的关联时会考虑此策略。关联双方的值必须兼容才能创建关联。数据读取器的截止期限必须大于或等于数据写入器的相应值。
启用关联的实体后，此策略的值可能会更改。在制定数据读取器或数据写入器的策略的情况下，仅当更改与读取器或写入器所参与的所有关联的远程端保持一致时，更改才能成功应用。如果更改主题的策略，它将仅影响在进行更改后创建的数据读取器和写入器。主题策略值更改不会影响任何现有的读者或作家，以及它们之间的任何现有关联。
对于希望某个主题定期更新每个实例的情况，此策略很有用。在发布方面，此设置建立了应用程序必须满足的合同。在订阅方面，该设置为希望提供数据值的远程发布者建立了最低要求。
当服务“匹配” DataWriter和DataReader时，它会检查设置是否兼容（即，提供的截止期限<=请求的截止期限）如果不兼容，（通过侦听器或条件机制）通知两个实体 QoS设置和通信将不兼容。
假设读取器和写入器端具有兼容设置，则本服务将监视此合同的履行，并通过适当的侦听器或条件将任何违规情况通知应用程序。
当且仅当不等式“提供的截止期限<=请求的截止期限”评估为“ TRUE”时，才认为提供的值与请求的值兼容。
DEADLINE策略的设置必须与TIME_BASED_FILTER的设置一致。为了使这两个策略一致，设置必须为“截止期限> = minimum_separation”。

8. LATENCY_BUDGET

延迟预算策略通过其各自的QoS策略结构的延迟预算成员应用于主题、数据读取器和数据写入器实体。下面是与LatencyBudget QoS策略相关的IDL：
   struct LatencyBudgetQosPolicy {
       Duration_t duration;
   };
duration的默认值为零，表示应该将延迟最小化。此策略被视为对传输层的提示，以指示发送样本的紧迫性。OpenDDS使用该值绑定一个延迟间隔，用于报告将样本从发布传输到订阅时的不可接受延迟。此策略目前仅用于监视目的。使用传输优先级策略修改样本的发送。数据写入器策略值仅用于兼容性比较，如果保留为默认值零，则将匹配来自数据读取器的所有请求持续时间值。
添加了一个附加的侦听器扩展，以允许报告超过策略持续时间设置的延迟。OpenDDS::DCPS::DataReaderListener接口有一个附加操作，用于通知收到的样本的传输延迟测量值大于latency_budget策略持续时间。该方法的IDL为：
   struct BudgetExceededStatus {
       long total_count;
       long total_count_change;
       DDS::InstanceHandle_t last_instance_handle;
   };
   void on_budget_exceeded(
       in DDS::DataReader reader,
       in BudgetExceededStatus status);
要使用扩展侦听器回调，需要从扩展接口派生侦听器实现，如以下代码片段所示：
   class DataReaderListenerImpl
        : public virtual
          OpenDDS::DCPS::LocalObject<OpenDDS::DCPS::DataReaderListener>
然后必须为on_budget_exceeded()操作提供非空实现。请注意，您还需要为以下扩展操作提供空实现：
   on_subscription_disconnected()
   on_subscription_reconnected()
   on_subscription_lost()
   on_connection_deleted()
OpenDDS还通过数据读取器的扩展接口提供了摘要延迟统计信息。此扩展接口位于OpenDDS::DCPS模块中，IDL定义为：

   struct LatencyStatistics {
       GUID_t publication;
       unsigned long n;
       double maximum;
       double minimum;
       double mean;
       double variance;
   };
   typedef sequence<LatencyStatistics> LatencyStatisticsSeq;
   local interface DataReaderEx : DDS::DataReader {
          /// Obtain a sequence of statistics summaries.
          void get_latency_stats( inout LatencyStatisticsSeq stats);
          /// Clear any intermediate statistical values.
          void reset_latency_stats();
          /// Statistics gathering enable state.
          attribute boolean statistics_enabled;
   };
此策略为应用程序提供了一种向中间件指示数据通信的“紧迫性”的方法。通过具有非零的持续时间，服务可以优化其内部操作。
这项政策被认为是一个暗示。对于服务应该如何利用这个提示，没有指定的机制。
当且仅当不等式“offered duration<=requested duration”的计算结果为“TRUE”时，才认为提供的值与请求的值兼容

9.OWNERSHIP

OWNERSHIP策略控制着一个以上的Data Writer是否能够为同一数据对象实例编写样本。所有权可以是独占或共享。以下是与所有权QoS策略相关的IDL：
   enum OwnershipQosPolicyKind {
       SHARED_OWNERSHIP_QOS,
       EXCLUSIVE_OWNERSHIP_QOS
   };
   struct OwnershipQosPolicy {
       OwnershipQosPolicyKind kind;
   };
如果将kind成员设置为SHARED_OWNERSHIP_QOS，则允许多个Data Writer更新同一数据对象实例。如果将kind成员设置为EXCLUSIVE_OWNERSHIP_QOS，则只允许一个Data Writer更新给定的数据对象实例（即，Data Writer被视为该实例的所有者），并且关联的Data Reader将仅看到由该Data Writer编写的示例。  实例的所有者由OWNERSHIP_STRENGTH策略的值确定；具有最高强度值的数据写入器被视为数据对象实例的所有者。其他因素也可能影响所有权，例如，具有最高强度的数据写入器是否“有效”（如LIVELINESS策略所定义）并且没有违反其提供的发布截止日期限制（如DEADLINE策略所定义）。
   此策略控制服务是否允许多个DataWriter对象更新数据对象的同一实例（由Topic +键标识）。
通过该类型的设置可以选择两种所有权：共享和专有。
SHARED kind
此设置表明服务不会对每个实例强制执行唯一所有权。在这种情况下，多个编写者可以更新同一数据对象实例。主题的订阅者将能够访问所有DataWriter对象的修改，但要遵守可能过滤特定样本的其他QoS的设置（例如TIME_BASED_FILTER或HISTORY QoS策略）。在任何情况下，都不会基于导致修改的DataWriter的身份对修改进行“过滤”。
EXCLUSIVE kind
此设置表明一个数据对象的每个实例只能由一个DataWriter修改。换句话说，在任何时间点，单个DataWriter都会“拥有”每个实例，并且是唯一一个其修改对DataReader对象可见的实例。通过选择具有强度26最高值的DataWriter来确定所有者，强度26既是LIVELINESS QoS策略定义的“活动”，又在数据实例方面未违反其DEADLINE约定
因此，所有权可能会发生变化，因为（a）系统中的数据编写器具有更高的修改实例的强度值，（b）拥有该实例的数据编写器的强度值发生变化，（c）拥有该实例的数据编写器的活跃度发生变化，以及（d）关于实例的截止日期，该截止日期被拥有该实例的数据编写器错过。
系统的行为就像确定是由每个DataReader独立进行的。每个DataReader可能会在不同时间检测所有权的更改。不需要在特定的时间点上该Topic的所有DataReader对象都具有谁拥有每个实例的一致图片。也不要求DataWriter对象知道它们是否拥有特定实例。没有错误或通知给DataWriter，它修改了它当前不拥有的实例。
选择这些要求是为了（a）保持发布者和订阅者的分离，以及（b）允许有效地实施该策略。
具有相同强度的多个DataWriter对象可能修改同一个实例。如果发生这种情况，服务将选择其中一个DataWriter对象作为“所有者”。它没有指定如何选择所有者。但是，要求用于选择所有者的策略是，所有DataReader对象将对作为所有者的特定DataWriter做出相同的选择。还要求所有者保持不变，直到强度、活跃度发生变化，所有者在实例上截止日期，具有更高强度的新数据编写器修改实例，或服务认为具有相同强度的另一个数据编写器修改实例。
专有所有权是基于实例的。即，订户可以接收由强度较低的DataWriter写入的值，只要它们影响其值尚未由强度较高的DataWriter设置的实例即可。
提供的OWNERSHIP类型的值必须与请求的值完全匹配，否则将被视为不兼容。

10.OWNERSHIP_STRENGTH

当OWNERSHIP类型设置为EXCLUSIVE时，OWNERSHIP_STRENGTH策略与OWNERSHIP策略结合使用。以下是与所有权强度QoS策略相关的IDL：
   struct OwnershipStrengthQosPolicy {
       long value;
   };
值成员用于确定哪个Data Writer是数据对象实例的所有者。默认值为零。
此QoS策略应与OWNERSHIP策略一起使用。它仅适用于将OWNERSHIP种类设置为EXCLUSIVE的情况。
OWNERSHIP_STRENGTH的值用于确定数据实例的所有权（由密钥标识）。仲裁由DataReader执行。

11. LIVELINESS

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;
   };
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
此外，作者提供的租约期限必须小于或等于读者请求的租约期限。必须同时满足这两个条件，才能将所提供和请求的活动策略设置视为兼容并建立关联。
此策略控制服务使用的机制和参数，以确保网络上的特定实体仍然“处于活动状态”。活泼性还可能影响特定实例的所有权，如OWNERSHIP QoS策略所确定。
此策略具有多种设置，以支持定期更新的数据对象和偶尔更改的数据对象。它还可以根据活动机制检测到的故障种类，针对不同的应用程序需求进行定制。
AUTOMATIC liveliness设置最适合只需要在流程级别检测故障，而无需检测流程中的应用程序逻辑故障的应用程序。该服务负责按要求的费率续订租约，因此，只要运行DomainParticipant的本地进程以及将其连接到远程参与者的链接保持连接状态，DomainParticipant中的实体都将处于活动状态。这需要最低的开销。
MANUAL设置（MANUAL_BY_PARTICIPANT，MANUAL_BY_TOPIC）要求发布方的应用程序在租约到期之前定期断言活动性，以指示相应的实体仍然有效。该操作可以通过调用assert_liveliness操作来显式，也可以通过写入一些数据来隐式。
两种可能的手动设置控制应用程序必须断言生动性的粒度。
   •设置MANUAL_BY_PARTICIPANT仅要求声明发布者中的一个实体是活动的，才能推断出同一DomainParticipant中的所有其他实体对象也是活动的。
   •设置MANUAL_BY_TOPIC要求在DataWriter中至少声明一个实例。
当且仅当满足以下条件时，才认为提供的值与请求的值兼容：

1）不等式“提供的种类> =请求的种类”计算为“ TRUE”。出于这种不平等的目的，LIVELINESS类型的值被认为是有序的：
   AUTOMATIC < MANUAL_BY_PARTICIPANT < MANUAL_BY_TOPIC.
2）不等式“提供的lease_duration <=请求的lease_duration”的值为TRUE。
服务必须以大于或等于lease_duration的时间粒度来检测LIVELINESS的更改。这样可以确保在每个lease_duration期间至少将LivelinessChangedStatus的值更新一次，并在LIVELINESS更改之时在lease_duration内通知相关的侦听器和WaitSet。

12. TIME_BASED_FILTER

TIME_BASED_FILTER QoS策略控制数据读取器可能对数据实例的值更改感兴趣的频率。这是基于时间的过滤器QoS的IDL：
   struct TimeBasedFilterQosPolicy {
       Duration_t minimum_separation;
   };
可以在数据读取器上指定一个间隔（minimum_separation）。此间隔定义实例值更改之间的最小延迟；这允许数据读取器在不影响相关数据写入器状态的情况下限制更改。默认情况下，minimum_separation为零，表示没有数据被过滤。此QoS策略不节省带宽，因为实例值更改仍被发送到订户进程。它仅影响通过数据读取器提供哪些样本。
通过此策略，DataReader可以指示它不一定要查看在“主题”下发布的每个实例的所有值。相反，它希望每个minimum_separation周期最多看到一个更改。
TIME_BASED_FILTER分别应用于每个实例，也就是说，约束条件是DataReader不想在每个minimum_separation周期内看到每个实例的多个样本。
此设置允许DataReader进一步将自身与DataWriter对象解耦。它可用于保护在异构网络上运行的应用程序，在异构网络中，某些节点能够比其他节点消耗数据的速度快得多。它还适应以下事实：对于快速变化的数据，不同的订户可能有不同的要求，即需要多长时间通知他们最新的值。
TIME_BASED_FILTER的设置（即，选择大于零的minimum_separation）与“历史记录”和“可靠性QoS”的所有设置兼容。 TIME_BASED_FILTER指定DataReader感兴趣的样本。历史和可靠性QoS会影响中间件相对于已确定为DataReader感兴趣的样本的行为，也就是说，它们在应用TIME_BASED_FILTER之后才应用。
如果可靠性QoS类型为RELIABLE，然后处于稳定状态（定义为DataWriter与minimum_separation相比，DataWriter长时间不写新样本的情况），系统应保证将最后一个样本交付给DataReader 。
TIME_BASED_FILTER minimum_separation的设置必须与DEADLINE周期一致。为了使这两个QoS策略保持一致，它们必须验证“ period> = minimum_separation”。通过set_qos操作创建实体时，尝试以不一致的方式设置这些策略将导致操作失败。

13. PARTITION

PARTITION QoS策略允许在域内创建逻辑分区。如果它们具有匹配的分区字符串，则仅允许数据读取器和数据写入器关联。此策略通过发布者和订阅者实体各自QoS结构的分区成员来应用。以下是与分区QoS策略相关的IDL。
   struct PartitionQosPolicy {
       StringSeq name;
   };
名称成员默认为空字符串序列。默认分区名称是一个空字符串，使实体参与默认分区。分区名称可以包含POSIX fnmatch函数定义的通配符。数据读取器和数据写入器关联的建立取决于发布和预订端上匹配的分区字符串。未能匹配分区不会被视为失败，并且不会触发任何回调或设置任何状态值。该政策的价值可以随时更改。对此政策的更改可能会导致删除或添加关联。
这项政策允许在域引起的“物理”分区中引入逻辑分区概念。
为了使DataReader看到DataWriter对实例所做的更改，不仅主题必须匹配，而且它们还必须共享一个公共分区。列表中定义此QoS策略的每个字符串都定义一个分区名称。分区名称可能包含通配符。共享公共分区意味着分区名称之一匹配。未能匹配分区不被视为“不兼容” QoS，并且不会触发任何侦听器或条件。
此政策是可变的。更改此策略可能会修改现有DataReader和DataWriter实体的“匹配”。它可能会建立以前不存在的新“匹配”，或者破坏现有的匹配。
PARTITION名称可以是正则表达式，并且可以包含POSIX fnmatch API（1003.2-1992 B.6节）所定义的通配符。发布者或订阅者都可以在分区名称中包含正则表达式，但不会同时考虑两个都包含通配符的名称。这意味着尽管可以在发布者和订户端都使用正则表达式，但是该服务将不会尝试匹配两个正则表达式（在发布者和订阅者之间）。
域彼此完全隔离；应用程序或服务本身无法通过流量、元流量或任何其他方式查看其不属于的域中的实体。其次，一个实体只能属于一个域，而一个实体可以位于多个分区中。最后，就DDS服务而言，每个唯一的数据实例都由元组（domainId，Topic，键）标识。因此，不同域中的两个Entity对象不能引用相同的数据实例。另一方面，可以在一个或多个分区上使相同的数据实例可用（发布）或请求（订阅）。

14. RELIABILITY

可靠性策略通过其各自QoS结构的可靠性成员而适用于主题、数据读取器和数据写入器实体。以下是与可靠性QoS策略相关的IDL：
   enum ReliabilityQosPolicyKind {
       BEST_EFFORT_RELIABILITY_QOS,
       RELIABLE_RELIABILITY_QOS
   };
   struct ReliabilityQosPolicy {
       ReliabilityQosPolicyKind kind;
       Duration_t max_blocking_time;
   };
此策略控制数据读取器和写入器如何处理他们处理的数据样本。 “尽力而为”值（BEST_EFFORT_RELIABILITY_QOS）对样本的可靠性没有任何保证，在某些情况下可能会丢弃样本。 “可靠”值（RELIABLE_RELIABILITY_QOS）表示该服务最终应将所有值传递给合格的数据读取器。
当历史QoS策略设置为“全部保留”并且写入器由于资源限制而无法继续时，将使用此策略的max_blocking_time成员。如果发生这种情况，并且写入器阻塞的时间超过了指定的时间，则写入将失败，并返回超时返回代码。数据读取器和主题的此策略的默认值为“尽力而为”，而数据写入器的默认值为“可靠”。
在创建数据写入者和数据读取者之间的关联时会考虑此策略。关联双方的值必须兼容才能创建关联。数据写入器的可靠性类型必须大于或等于数据读取器的值。
此策略指示DataReader请求或DataWriter提供的可靠性级别。这些级别是有序的，BEST_EFFORT低于RELIABLE。提供级别的DataWriter隐式提供下面的所有级别。
此策略的设置取决于RESOURCE_LIMITS策略的设置。如果将RELIABILITY类型设置为RELIABLE，则如果修改将导致数据丢失或导致超出RESOURCE_LIMITS中指定的限制之一，则可能会阻止对DataWriter的写操作。在这些情况下，RELIABILITY max_blocking_time配置写操作可能阻塞的最大持续时间。
如果将RELIABILITY类型设置为RELIABLE，则由于通讯错误而无法接收到以前的数据样本，则无法使源自单个DataWriter的数据样本对DataReader可用。换句话说，该服务将修复错误并根据需要重新传输数据样本，以便在DataReader对其进行访问之前重建DataWriter历史记录的正确快照。
如果将RELIABILITY类型设置为BEST_EFFORT，则该服务将不会重新传输丢失的数据样本。但是，对于源自任何一个DataWriter的数据样本，服务将确保以与源自DataWriter的顺序相同的顺序将它们存储在DataReader历史记录中。换句话说，DataReader可能会丢失一些数据样本，但它永远不会看到数据对象的值从较新的值更改为order值。
当且仅当不等式“提供的种类> =请求的种类”评估为“ TRUE”时，才认为提供的值与请求的值兼容。出于这种不等式的目的，将RELIABILITY类型的值视为有序的，使得BEST_EFFORT <RELIABLE 。

15. TRANSPORT_PRIORITY

TRANSPORT_PRIORITY策略通过其各自的QoS策略结构的transport_priority成员应用于主题和数据写入者实体。以下是与TransportPriority QoS策略相关的IDL：
   struct TransportPriorityQosPolicy {
       long value;
   };
transport_priority的默认值成员为零。该策略被认为是对传输层的提示，用于指示以什么优先级发送消息。较高的值表示较高的优先级。 OpenDDS将优先级值直接映射到线程和DiffServ代码点值。默认优先级为零将不会修改消息中的线程或代码点。
OpenDDS将尝试设置发送传输以及任何关联的接收传输的线程优先级。传输优先级值从零（默认值）到最大线程优先级线性映射而不进行缩放。如果最低线程优先级不同于零，那么它将映射到传输优先级值零。如果系统上的优先级值是相反的（较高的数字值表示较低的优先级），则OpenDDS会将其映射到从零开始的递增优先级值。低于系统上最小（最低）线程优先级的优先级值将映射到该最低优先级。大于系统上最大（最高）线程优先级的优先级值将映射到该最高优先级。在大多数系统上，只有在将进程调度程序设置为允许这些操作时才能设置线程优先级。设置进程调度程序通常是一项特权操作，并且需要系统特权才能执行。在基于POSIX的系统上，系统调用sched_get_priority_min()和sched_get_priority_max()用于确定线程优先级的系统范围。
如果传输实现支持，OpenDDS将尝试在套接字上设置DiffServ代码点，该代码点用于为数据写入器发送数据。如果网络硬件接受代码点值，则更高的代码点值将导致更高优先级样本的更好（更快）传输。默认值零将映射到零的（默认）代码点。然后将从1到63的优先级值映射到相应的代码点值，并将更高的优先级值映射到最高代码点值（63）。
创建数据写入器后，OpenDDS当前不支持对transport_priority策略值的修改。可以通过创建新的数据写入器来解决此问题，因为需要不同的优先级值。
此QoS的目的是允许应用程序利用能够发送具有不同优先级的消息的传输机制。
该政策被认为是提示。该策略取决于基础传输对它们发送的消息设置优先级的能力。可以选择32位有符号整数范围内的任何值。较高的值表示较高的优先级。
但是，对此政策的任何进一步解释都特定于服务的特定运输和特定实施。例如，允许一种特定的传输将一系列优先级值视为等同。预期在传输配置期间，应用程序将提供DataWriter上设置的TRANSPORT_PRIORITY的值与对每个传输有意义的值之间的映射。然后，在传播由DataWriter写入的数据时，基础结构将使用此映射。

16. LIFESPAN

LIFESPAN QoS策略允许应用程序指定样本何时过期。过期的样本将不会交付给订户。此策略通过其各自QoS结构的 lifespan成员适用于主题和数据编写者实体。以下是与寿命QoS策略相关的IDL。
   struct LifespanQosPolicy {
       Duration_t duration;
   }
持续时间成员的默认值是无限的，这意味着样本永不过期。当使用除VOLATILE以外的DURABILITY类型时，OpenDDS当前支持发布者端的过期样本检测。当前的OpenDDS实现可能在将样本放入缓存后过期后，无法从数据写入器和数据读取器缓存中删除它们。该政策的值可以随时更改。对此策略的更改仅影响更改后写入的数据。
此QoS的目的是避免将“陈旧的”数据传递给应用程序。
DataWriter编写的每个数据样本都有一个关联的“过期时间”，超过该时间不应将数据传递给任何应用程序。一旦样本过期，数据将从DataReader缓存以及瞬态和持久信息缓存中删除。
每个样本的“到期时间”是通过将LIFESPAN QoS指定的持续时间添加到源时间戳中来计算的。每次服务调用DataWriter写操作时，源时间戳都会由Service自动计算，或者由应用程序通过write_w_timestamp操作提供。
此QoS依赖于其时钟充分同步的发送方和接收方应用程序。如果不是这种情况，并且服务可以检测到它，则允许DataReader在计算“过期时间”时使用接收时间戳，而不是源时间戳。

17. DESTINATION_ORDER

DESTINATION_ORDER QoS策略控制将给定实例中的样本提供给数据读取器的顺序。如果指定的历史深度为1（默认值），则该实例将反映所有数据编写者写入该实例的最新值。这是终点顺序Qos的IDL：
   enum DestinationOrderQosPolicyKind {
       BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS,
       BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS
   };
   struct DestinationOrderQosPolicy {
       DestinationOrderQosPolicyKind kind;
   };
BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS值（默认值）指示实例中的样本按照数据读取器接收样本的顺序进行排序。请注意，不一定按相同数据写入器发送的顺序接收样本。要强制执行这种类型的排序，应使用BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS值。
BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS值指示实例内的样本是根据数据写入器提供的时间戳进行排序的。应该注意的是，如果多个数据写入器写入同一实例，则应注意确保时钟同步，以防止在数据读取器上进行不正确的排序。
此策略控制每个订阅者如何解析由在不同节点上运行的多个DataWriter对象（可能与不同的Publisher对象相关联）写入的数据实例的最终值。
设置BY_RECEPTION_TIMESTAMP表示，假设OWNERSHIP策略允许它，则实例的最新接收值应该是保留其值的值。这是默认值。
设置BY_SOURCE_TIMESTAMP表示，假设OWNERSHIP策略允许，则应使用放置在源上的时间戳。在并发相同强度的DataWriter对象更新同一实例的情况下，这是唯一的设置，可确保所有订阅者最终获得该实例的最终值相同。设置源时间戳记的机制取决于中间件。
当且仅当不等式“提供的种类> =请求的种类”评估为“ TRUE”时，才认为提供的值与请求的值兼容。出于这种不平等的目的，将DESTINATION_ORDER类型的值视为有序的，使得BY_RECEPTION_TIMESTAMP <BY_SOURCE_TIMESTAMP 。

18. HISTORY

历史记录策略确定特定实例在数据写入器和数据读取器中如何保存样本。对于数据编写者，这些值将一直保留到发布者检索到它们并将它们成功发送给所有连接的订户为止。对于数据读取器，这些值将保留到应用程序“获取”为止。此策略通过各自的QoS结构的历史记录成员适用于主题、数据读取器和数据写入器实体。以下是与历史QoS策略相关的IDL：
   enum HistoryQosPolicyKind {
       KEEP_LAST_HISTORY_QOS,
       KEEP_ALL_HISTORY_QOS
   };
   struct HistoryQosPolicy {
       HistoryQosPolicyKind kind;
       long depth;
   };
“全部保留”值（KEEP_ALL_HISTORY_QOS）指定应保留该实例的所有可能样本。当指定“全部保留”并且未读样本的数量等于max_samples_per_instance的“资源限制”字段时，则拒绝任何传入的样本。
“保留最后一个”值（KEEP_LAST_HISTORY_QOS）指定仅保留最后一个深度值。当数据写入器包含给定实例的深度样本时，该实例的新样本写入将排队等待交付，而最旧的未发送样本将被丢弃。当数据读取器包含给定实例的深度样本时，该实例的所有传入样本都会保留，最旧的样本将被丢弃。此策略默认为深度为1的“保留最后”。
   1）当实例的值在最终与它的某些现有DataReader实体通信之前发生更改时，此策略控制Service的行为。
   2）如果将种类设置为KEEP_LAST，则服务将仅尝试保留实例的最新值并丢弃较旧的值。在这种情况下，深度值可调节服务将维持和提供的最大值数（包括最新值）。深度的默认值（也是最常用的设置）是1，表示仅应传递最新的值。
   3）如果将种类设置为KEEP_ALL，则服务将尝试维护实例的所有值并将其传递给现有订户。服务可用于保留此历史记录的资源受RESOURCE_LIMITS QoS的设置限制。如果达到限制，则服务的行为将取决于可靠性QoS。如果可靠性类型为BEST_EFFORT，则旧值将被丢弃。如果可靠性是可靠的，则服务将阻止DataWriter，直到它可以将必要的旧值传递给所有订户。
历史记录深度的设置必须与RESOURCE_LIMITS max_samples_per_instance相一致。为了使这两个QoS保持一致，它们必须验证 depth<= max_samples_per_instance。

19. RESOURCE_LIMITS

RESOURCE_LIMITS策略确定服务可以消耗以满足要求的QoS的资源量。此策略通过各自的QoS结构的resource_limits成员适用于主题、数据读取器和数据写入器实体。以下是与资源限制QoS策略相关的IDL。
   struct ResourceLimitsQosPolicy {
       long max_samples;
       long max_instances;
       long max_samples_per_instance;
   };
max_samples成员指定单个数据写入器或数据读取器可以在其所有实例中管理的最大样本数。 max_instances成员指定数据写入器或数据读取器可以管理的最大实例数。 max_samples_per_instance成员指定可以在单个数据写入器或数据读取器中为单个实例管理的最大样本数。所有这些成员的值默认为无限制（DDS ::LENGTH_UNLIMITED）。
数据写入器使用资源来使写入数据写入器的样本排队，但由于传输产生的backpressure，这些样本尚未发送给所有数据读取器。数据读取器使用资源来对已接收但尚未从数据读取器读取/获取的样本进行排队。
此策略控制服务可以使用的资源，以满足应用程序和其他QoS设置施加的要求。
如果DataWriter对象传递样本的速度比DataReader对象最终获取的速度快，则中间件最终将遇到某些QoS施加的资源限制。请注意，当只有一个DataReader不能跟上其对应的DataWriter时，可能会发生这种情况。在这种情况下，行为取决于“可靠性QoS”的设置。如果可靠性为BEST_EFFORT，则允许服务删除样本。如果可靠性是可靠的，则服务将阻止DataWriter或在DataReader 处丢弃样本，以免丢失现有样本。
常量LENGTH_UNLIMITED可用于指示不存在特定限制。例如，将max_samples_per_instance设置为LENGH_UNLIMITED将导致中间件不强制执行此特定限制。
RESOURCE_LIMITS max_samples的设置必须与max_samples_per_instance相一致。为了使这两个值一致，它们必须验证“ max_samples> = max_samples_per_instance”。
RESOURCE LIMITS max_samples per_instance的设置必须与HISTORY深度一致。为了使这两个QoS保持一致，它们必须验证“ depth <= max_samples per_instance”。
通过set_qos操作创建实体时，尝试将此策略设置为不一致的值将导致操作失败。

20. ENTITY_FACTORY

ENTITY FACTORY策略控制在创建实体时是否自动启用它们。以下是与实体工厂QoS策略相关的IDL：
   struct EntityFactoryQosPolicy {
       boolean autoenable_created_entities;
   };
该策略可以应用于充当其他实体工厂的实体，并控制在创建时是否自动启用由这些工厂创建的实体。此策略可以应用于域参与者工厂（作为域参与者的工厂），域参与者（作为发布者、订阅者和主题的工厂），发布者（作为写入器的工厂）或订阅者（作为数据读取器的工厂）。 autoenable_created_entities成员的默认值为true，表示在创建实体时会自动启用它们。希望在创建实体后的某个时间显式启用实体的应用程序应将此策略的autoenable_created_entities成员的值设置为false，并将该策略应用于适当的工厂实体。然后，应用程序必须通过调用实体的enable()操作来手动启用实体。
该政策的值可以随时更改。对此策略的更改仅影响更改后创建的实体。此策略控制实体作为其他实体的工厂的行为。此策略仅涉及DomainParticipant（作为Publisher、Subscriber和Topic的工厂），Publisher（作为DataWriter的工厂）和Subscriber（作为DataReader的工厂）。此政策是可变的。策略的更改仅影响更改后创建的实体。而不是先前创建的实体。
将autoenable_created_entities设置为TRUE表示，每次创建新实体时，工厂create_ <entity>操作将自动调用启用操作。因此，由create_ <entity>返回的实体将已启用。设置为FALSE表示该实体将不会自动启用。应用程序将需要通过启用操作显式启用它。
autoenable_created_entities的默认设置= TRUE表示，默认情况下，无需在新创建的实体上显式调用enable。

21. WRITER_DATA_LIFECYCLE

WRITER DATA LIFECYCLE QoS策略控制由数据写入器管理的数据实例的生命周期。下面是Writer数据生命周期QoS策略的IDL：
   struct WriterDataLifecycleQosPolicy {
       boolean autodispose_unregistered_instances;
   };
当autodispose_unregistered_instances设置为true（默认值）时，数据写入器在取消注册实例时将其处置。在某些情况下，可能希望防止在未注册实例时处置该实例。例如，此策略可以允许EXCLUSIVE数据写入器从容地推迟到下一个数据写入器，而不会影响实例状态。删除数据写入器会在删除之前隐式注销其所有实例。
就其管理的数据实例的生命周期而言，此策略控制DataWriter的行为，也就是说，该数据实例已使用注册操作明确地注册到了DataWriter中或直接写入数据隐式。当DataWriter通过注销操作注销实例时，autodispose_unregistered_instances标志控制行为：
   •设置“ autodispose_unregistered_instances = TRUE”会使DataWriter每次取消注册实例时都对其进行处置。该行为与在调用取消注册操作之前在实例上显式调用处置操作之一相同。
   •设置“ autodispose_unregistered_instances = FALSE”将不会导致注销后自动处理。在注销实例之前，应用程序仍可以调用处理操作之一，并达到相同的效果。
请注意，删除DataWriter会自动注销其管理的所有数据实例。因此，autodispose_unregistered_instances标志的设置将确定在直接通过Publisher::delete_datawriter操作删除DataWriter时，还是由于在发布者或包含DataWriter的DomainParticipant上调用delete_contained_entities而间接删除DataWriter时，是否最终处置了实例。

22. READER_DATA_LIFECYCLE

READER DATA LIFECYCLE QoS策略控制由数据读取器管理的数据实例的生命周期。这是读取器数据生命周期QoS策略的IDL：
   struct ReaderDataLifecycleQosPolicy {
       Duration_t autopurge_nowriter_samples_delay;
       Duration_t autopurge_disposed_samples_delay;
   };
通常，数据读取器将为所有实例维护数据，直到该实例不再有关联的数据写入器，该实例已被处置或该数据已由用户获取为止。在某些情况下，可能希望限制这些资源的回收。例如，此策略可以允许后期加入的数据编写器在故障转移情况下延长实例的生命周期。
一旦实例转换为NOT_ALIVE_NO_WRITERS状态，autopurge_nowriter_samples_delay控制数据读取器在回收资源之前等待多长时间。默认情况下，autopurge_nowriter_samples_delay是无限的。
一旦实例转换为NOT_ALIVE_DISPOSED状态，autopurge_disposed_samples_delay控制数据读取器在回收资源之前等待多长时间。默认情况下，autopurge_disposed_samples_delay是无限的。
该策略根据其管理的数据实例的生命周期来控制DataReader的行为，即该数据实例已接收并且DataReader为其维护一些内部资源的数据实例。
根据其他QoS策略（例如“历史记录”和“资源限制”）施加的约束，DataReader在内部维护应用程序尚未获取的样本。即使已经“采集”了所有样本，DataReader也会维护有关数据实例的身份，view_state和instance_state的信息。这是在以后的样本到达时正确计算状态所必需的。
在正常情况下，DataReader只能回收没有写程序且已“获取”所有样本的实例的所有资源。DataReader对该实例获取的最后一个样本的instance_state的NOT_ALIVE_NO_WRITERS或NOT_ALIVE_DISPOSED取决于关于最后拥有实例所有权的作者是否将其处置。关于状态图，请参见图2.11，该状态图描述了instance_state可能的转换。在没有READER_DATA_LIFECYCLE QoS的情况下，如果应用程序“忘记”“采集”这些样本，则此行为可能会导致问题。 “未使用”样本将阻止DataReader回收资源，并且它们将无限期保留在DataReader中。
autopurge_nowriter_samples_delay定义了当实例的状态变为NOT_ALIVE_NO_WRITERS后，DataReader会维持有关该实例的信息的最大持续时间。经过这段时间后，DataReader将清除有关实例的所有内部信息，所有未获取的样本也将丢失。
autopurge_disposed_samples_delay定义当实例的状态变为NOT_ALIVE_DISPOSED时，DataReader为其维护样本的最大持续时间。经过这段时间后，DataReader将清除该实例的所有样本。

_ace_313_

关注

9
点赞
踩
32

收藏

觉得还不错? 一键收藏
0
评论
DDS QoS

1.USER_DATA USER_DATA策略通过各自的QoS结构的user_data成员应用于域参与者、数据读取器和数据写入器实体。以下是与用户数据QoS策略相关的IDL： struct UserDataQosPolicy { sequence<octet> value; }; 默认情况下，未设置值成员。可以将其设置为可用于将信息附加到创建的实体的任何八位位组序列。 USER_DATA策略的值在相应的内置主题数据中可用。 ...
复制链接

扫一扫