CHAPTER 3 Quality of Service.doc

CHAPTER 3 Quality of Service 3.1 Introduction The previous examples use default QoS policies for the various entities. This chapter discusses the QoS policies which are implemented in OpenDDS and the details of their usage. See the DDS specification for further information about the policies discussed in this chapter. 前面的例子使用默认QoS策略的各种实体。本章讨论的QoS策略中实现OpenDDS及其用法的详细信息。看到进一步的DDS规范在本章讨论的政策信息。3.2 QoS Policies Each policy defines a structure to specify its data. Each entity supports a subset of the policies and defines a QoS structure that is composed of the supported policy structures. The set of allowable policies for a given entity is constrained by the policy structures nested in its QoS structure. For example, the Publishers QoS structure is defined in the specifications IDL as follows: 每个策略定义了一个指定其数据结构。每个实体支持政策和定义了一个子集的QoS支持政策的结构,是由结构。容许集政策对于一个给定的实体是制约其QoS策略结构嵌套结构。例如,出版商的QoS结构规范的IDL定义如下:module DDS struct PublisherQos PresentationQosPolicy presentation; PartitionQosPolicy partition; GroupDataQosPolicy group_data; EntityFactoryQosPolicy entity_factory; ; ; Setting policies is as simple as obtaining a structure with the default values already set, modifying the individual policy structures as necessary, and then applying the QoS structure to an entity (usually when it is created). We show examples of how to obtain the default QoS policies for various entity types in 3.2.1. 设置策略非常简单,获得结构已经设置默认值,根据需要修改个人政策结构,然后应用QoS结构一个实体(通常创建时)。我们展示的例子如何获得各种实体类型的默认QoS策略在3.2.1之上。 Applications can change the QoS of any entity by calling the set_qos() operation on the entity. If the QoS is changeable, existing associations are removed if they are no longer compatible and new associations are added if they become compatible. The DCPSInfoRepo re-evaluates the QoS compatibility and associations according to the QoS specification. If the compatibility checking fails, the call to set_qos() will return an error. The association re-evaluation may result in removal of existing associations or addition of new associations. 应用程序可以通过调用set_qos改变任何实体的QoS()操作的实体。如果QoS多变,删除现有的关联,如果他们不再兼容,添加新的联系,如果他们成为兼容。的DCPSInfoRepo重新评估的QoS兼容性和协会根据QoS规范。如果兼容性检查失败,调用set_qos()将返回一个错误。协会重新评估可能导致取消现有的协会或添加新的联系 If the user attempts to change a QoS policy that is immutable (not changeable), then set_qos() returns DDS:RETCODE_IMMUTABLE_POLICY. 如果用户试图改变QoS策略,是不变的(不是变化无常),然后set_qos()返回DDS:RETCODE_IMMUTABLE_POLICY。 A subset of the QoS policies are changeable. Some changeable QoS policies, such as USER_DATA, TOPIC_DATA, GROUP_DATA, LIFESPAN, OWNERSHIP_STRENGTH, TIME_BASED_FILTER, ENTITY_FACTORY, WRITER_DATA_LIFECYCLE, and READER_DATA_LIFECYCLE, do not require compatibility and association re-evaluation. The DEADLINE and LATENCY_BUDGET QoS policies require compatibility re-evaluation, but not for association. The PARTITION QoS policy does not require compatibility re-evaluation, but does require association re-evaluation. The DDS specification lists TRANSPORT_PRIORITY as changeable, but the OpenDDS implementation does not support dynamically modifying this policy. 一个子集QoS策略是多变的。一些多变的QoS策略,比如USER_DATA,TOPIC_DATA,GROUP_DATA,寿命,OWNERSHIP_STRENGTH, TIME_BASED_FILTER,ENTITY_FACTORY,WRITER_DATA_LIFECYCLE,READER_DATA_LIFECYCLE,不需要兼容和协会进行重新评估。最后期限和LATENCY_BUDGET QoS策略需要兼容性重新评估,但不是协会。分区QoS策略不需要兼容性重新评估,但确实需要重新评估。DDS规范列表TRANSPORT_PRIORITY多变,但OpenDDS实现不支持动态修改这一政策。3.2.1 Default QoS Policy Values Applications obtain the default QoS policies for an entity by instantiating a QoS structure of the appropriate type for the entity and passing it by reference to the appropriate get_default_entity_qos() operation on the appropriate factory entity. (For example, you would use a domain participant to obtain the default QoS for a publisher or subscriber.) The following examples illustrate how to obtain the default policies for publisher, subscriber, topic, domain participant, data writer, and data reader. 应用程序获得一个实体的默认QoS策略通过实例化一个QoS结构适当类型的实体,并通过引用适当的get_default_entity_qos()操作在适当的实体工厂。(例如,您将使用一个域参与者获得出版商或用户的默认QoS)。下面的示例说明如何获得出版商的默认策略,订阅者,主题,领域的参与者,数据作家,和数据阅读器。 / Get default Publisher QoS from a DomainParticipant: DDS:PublisherQos pub_qos; DDS:ReturnCode_t ret; ret = domain_participant-get_default_publisher_qos(pub_qos); if (DDS:RETCODE_OK != ret) std:cerr Could not get default publisher QoS get_default_subscriber_qos(sub_qos); if (DDS:RETCODE_OK != ret) std:cerr Could not get default subscriber QoS get_default_topic_qos(topic_qos); if (DDS:RETCODE_OK != ret) std:cerr Could not get default topic QoS get_default_participant_qos(dp_qos); if (DDS:RETCODE_OK != ret) std:cerr Could not get default participant QoS get_default_datawriter_qos(dw_qos); if (DDS:RETCODE_OK != ret) std:cerr Could not get default data writer QoS get_default_datareader_qos(dr_qos); if (DDS:RETCODE_OK != ret) std:cerr Could not get default data reader QoS MANUAL_BY_PARTICIPANT_LIVELINESS_QOS AUTOMATIC_LIVELINESS_QOS In addition, the writers offered lease duration must be less than or equal to the readers 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. 此外,作者的提供租赁时间必须小于或等于读者的请求的租赁期限。这两个条件必须满足提供和要求活泼策略设置要考虑兼容和协会成立。3.2.3 RELIABILITY The RELIABILITY policy applies to the topic, data reader, and data writer entities via the reliability member of their respective QoS structures. Below is the IDL related to the reliability QoS policy: 可靠性策略适用于主题,读者数据,通过可靠性数据作家实体成员各自的QoS结构。下面是相关的IDL可靠性QoS策略:enum ReliabilityQosPolicyKind BEST_EFFORT_RELIABILITY_QOS, RELIABLE_RELIABILITY_QOS ; struct ReliabilityQosPolicy ReliabilityQosPolicyKind kind; Duration_t max_blocking_time; ; This policy controls how data readers and writers treat the data samples they process. The “best effort” value (BEST_EFFORT_RELIABILITY_QOS) makes no promises as to the reliability of the samples and could be expected to drop samples under some circumstances. The “reliable” value (RELIABLE_RELIABILITY_QOS) indicates that the service should eventually deliver all values to eligible data readers. 这一政策控制数据读者和作者如何对待他们过程的数据样本。“尽力服务”型值(BEST_EFFORT_RELIABILITY_QOS)没有承诺为样本的可靠性,可以预计样品在某些情况下。“可靠”值(RELIABLE_RELIABILITY_QOS)表明,服务应该最终交付所有值合格数据读者。The max_blocking_time member of this policy is used when the history QoS policy is set to “keep all” and the writer is unable to return because of resource limits (due to transport backpressuresee 3.2.7 for details). When this situation occurs and the writer blocks for more than the specified time, then the write fails with a timeout return code. The default for this policy for data readers and topics is “best effort,” while the default value for data writers is “reliable.” max_blocking_time成员该政策时使用的是历史的QoS策略设置为“所有”,作者是无法返回,因为资源限制(由于运输backpressure-see 3.2.7详情)。当这种情况发生时,作者块超过指定的时间,然后用一个超时返回代码写失败。默认为这一政策数据读者和主题是“最好的努力,”虽然数据作家的默认值是“可靠的”。This 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 reliability kind of data writer must be greater than or equal to the value of data reader. 这一政策被认为是在创建数据作家和读者之间的关联。双方的价值协会必须要创建兼容的一个协会。类型的数据可靠性作家必须大于或等于数据读者的价值。3.2.4 HISTORY 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结构。下面是相关的IDL历史QoS策略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. 这项政策默认为“保持”的深度。3.2.5 DURABILITY 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结构。下面是相关的IDL耐久性QoS策略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 writers 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 3.2.6 DURABILITY_SERVICE 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政策控制样本的删除临时或永久耐用性缓存。这一政策适用于主题和数据通过durability_service作家实体成员各自的QoS结构,提供了一种方法来指定历史和RESOURCE_LIMITS示例缓存。下面是相关的IDL耐久性服务QoS策略: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. 类似于历史和资源限制成员,虽然独立,那些历史和RESOURCE_LIMITS政策。service_cleanup_delay可以设置为所需的值。默认情况下,它被设置为0,这意味着没有清理缓存的样本。3.2.7 RESOURCE_LIMITS The RESOURCE_LIMITS policy determines the amount of resources the service can consume in order