OpenDDS的Qos策略

1、前言

OpenDDS（Open Source Data Distribution Service）是一个功能强大的开源数据传输系统，广泛应用于分布式应用程序中。其中的 QoS（Quality of Service）策略在实现高效、可靠的数据通信方面起着关键作用。本文将深入探讨 OpenDDS 的 QoS 策略，包括其作用、常用策略类型以及如何配置和定制 QoS 策略。

2、QoS策略

在配置 OpenDDS 的 QoS 策略时，需要根据具体应用场景和需求选择合适的策略类型和参数。可以通过 XML 配置文件或代码中直接设置 QoS 策略，对各种数据发布器（DataWriter）和数据订阅器（DataReader）进行个性化的配置。

2.1、LIVELINESS

判断参与者是否存活。

心跳发送周期(Liveliness Lease Duration) : 指定数据发布者发送心跳信号的时间间隔。数据订阅者(DataReader)通过接收心跳信号来判断数据发布者是否仍然活跃。如果在指定的时间间隔内没有收到心跳信号，订阅者将认为数据发布者已经失活。
心跳超时时间(Liveliness Lease Duration): 指定数据订阅者等待心跳信号的超时时间，如果在超时时间内没有收到心跳信号，订阅者将认为数据发布者已经失活，并采取相应的措施，如清除相关数据。

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

2.2、RELIABILITY

为DataWriter设置RELIABILITY属性，可以使数据实现“可靠”的传输，当出现通信错误导致数据采样没有被接收到时，DataWriter会持续重传，直到所有数据被正确接收。

enum ReliabilityQosPolicyKind {BEST_EFFORT_RELIABILITY_QOS, //可靠送达 (传输层如果不可靠，应用层实现，比较消耗资源，容易堵塞)RELIABLE_RELIABILITY_QOS //尽力送达
};
struct ReliabilityQosPolicy {ReliabilityQosPolicyKind kind;Duration_t max_blocking_time;
};

2.3、HISTORY

可以选择仅保存最新sample,或最近的N个sample,或全部sample
设置HISTORY属性可以让DataWriter保存并发送旧的采样数据，新的DDS节点如果订阅了相关的Topic，它不仅能够接收到数据的当前值，也能收到一部分历史值，从而了解数据近期的变化趋势

enum HistoryQosPolicyKind {KEEP_LAST_HISTORY_QOS, // 保留最近一部分数据   新数据来临时丢掉最老的数据KEEP_ALL_HISTORY_QOS  // 全部保留  到达资源限制字段后将不再接收
};
struct HistoryQosPolicy {HistoryQosPolicyKind kind;long depth;  //保存数量  默认：1
};

2.4、DURABILITY

VOLATILE: 数据仅提供给现有的订阅者，后加入的Subscriber无法获得数据，这是DDS的默认行为
TRANSIENT_LOCAL: Publisher在本地保存数据，后加入的Subscriber能够获得数据TRANSIENT: GDS (Global Data Space) 保存数据，后加入的Subscriber能够获得数据PERSISTENT: GDS永久保存数据，后加入的Subscriber能够获得数据，即使整个系统发生了重启。

比如: 一个dds系统，里面有多个Subscriber，我们有些节点先启动，有些后启动，启动慢的节点可能错够一些数据。可以配置durabity进行解决。

enum DurabilityQosPolicyKind {VOLATILE_DURABILITY_QOS, // Least DurabilityTRANSIENT_LOCAL_DURABILITY_QOS,TRANSIENT_DURABILITY_QOS,PERSISTENT_DURABILITY_QOS // Greatest Durability
struct DurabilityQosPolicy {DurabilityQosPolicyKind kind;
};

2.5、DURABILITY_SERVICE

持久性缓冲区

struct DurabilityServiceQosPolicy {Duration_t service_cleanup_delay;HistoryQosPolicyKind history_kind;long history_depth;long max_samples;long max_instances;long max_samples_per_instance;
};

2.6 、RESOURCE_LIMITS

用于限制DDS可以分配的系统内存。
max_samples成员指定单个数据写程序或数据读取器可以跨其所有实例管理的最大样本数。 max_instances成员指定数据写入程序或数据读取器可以管理的最大实例数。 max_samples_per_instance成员指定可以在单个数据写程序或数据读取器中为单个实例管理的最大样本数。 所有这些成员的值默认为无限制（DDS :: LENGTH_UNLIMITED）。

struct ResourceLimitsQosPolicy {long max_samples;long max_instances;
long max_samples_per_instance;
};

2.7、PARTITION

允许在同一Domain下创建逻辑分区，处于同一分区内的DataWriter和DataReader才可以建立通信

struct PartitionQosPolicy {StringSeq name;
};

2.8、DEADLINE

如果希望某个Topic能够周期更新，可以设置DEADLINE属性。在数据的发布方设置DEADLINE，这意味着应用程序必须以小于DEADLINE的周期去更新Topic，而在数据的订阅方设置DEADLINE，这意味着数据的发布方必须以小于DEADLINE的周期去发布Topic。

struct DeadlineQosPolicy {Duration_t period;
};

2.9、LIFESPAN

通过设置LIFESPAN，可以使DataWriter写入的每个数据样本都有一个关联的“到期时间”，超过该时间后，该数据样本不再传送给任何应用程序，并且这些数据将从DataReader缓存中清除。
比如:类似雷达等数据是随着时间快速变化的，如果出现故境一直是旧的数据，我们可以设置LIFESPAN来设置数据有效时间.

struct LifespanQosPolicy {Duration_t duration;  // 有效时间，默认为永久
}

2.10、USER_DATA

允许应用程序将一个字节序列与DomainParticipant、DataReader或DataWiter进行关联，该字节序列通过内建Topic进行分发，常用于分发安全凭证，应用程序可通过此凭证验证数据的有效性。

struct UserDataQosPolicy {sequence<octet> value;
};

2.11、TOPIC_DATA

允许应用程序将一个字节序列与Topic相关联，该字节序列通过内建Topic进行分发常用于为Topic添加附加信息

struct TopicDataQosPolicy {sequence<octet> value;
};

2.12、GROUP_DATA

允许应用程序将一个字节序列与Publisher或Subscriber相关联，该字节序列通过内建Topic进行分发。
可以携带用户定义的信息，在服务发现的过程中就可以交换一些用户数据，从而做一些想做的事，比如安全凭证啥的。

struct GroupDataQosPolicy {sequence<octet> value;
};

2.13、TRANSPORT_PRIORITY

控制传输数据的优先级，由一个整数表示，值越大优先级越高

struct TransportPriorityQosPolicy {long value;
};

2.14、LATENCY_BUDGET

用于控制数据传输的延迟。
它定义了数据从发送端到接收端的最大允许延迟时间。当数据的延迟超过设定的延迟预算时，DDS可以采取一些策略，如丢弃数据或调整传输优先级，以确保数据传输的实时性。

struct LatencyBudgetQosPolicy {Duration_t duration;
};

2.15、ENTITY_FACTORY

指定充当工厂的实体是否自动启用它创建的实例。

struct EntityFactoryQosPolicy {
Boolean autoenable_created_entities;
};

2.16、PRESENTATION

Coherent Access：在一组DDS data sample的更新都到达接收端后，应用程序才能够访问这一组data sample,适用于不同数据实例之间存在关联关系的场景
比如:坐标数据，x,y,z都获取到才能访问这组数据.

enum PresentationQosPolicyAccessScopeKind {INSTANCE_PRESENTATION_QOS, // （默认值）表示实例独立发生更改。TOPIC_PRESENTATION_QOS, // 接受的更改仅限于同一数据读取器或数据写入器中的所有实例。GROUP_PRESENTATION_QOS // 接受的更改仅限于同一发布者或订阅者中的所有实例。
};
struct PresentationQosPolicy {PresentationQosPolicyAccessScopeKind access_scope;boolean coherent_access;boolean ordered_access;
}

2.17、DESTINATION_ORDER

控制给定实例中的样本可供数据读取器使用的顺序。 如果指定了历史深度1（缺省值），则实例将反映所有数据写入程序写入该实例的最新值。

enum DestinationOrderQosPolicyKind {BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS, // 实例中的样本按数据读取器接收它们的顺序排序BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS // 实例中的样本是根据数据写入程序提供的时间戳排序的
};
struct DestinationOrderQosPolicy {DestinationOrderQosPolicyKind kind;
};

2.18、WRITER_DATA_LIFECYCLE

该策略控制由数据写入程序管理的数据实例的生命周期。
当autodispose_unregistered_instances设置为true（缺省值）时，数据写入器在删除时时会释放实例。

struct WriterDataLifecycleQosPolicy {boolean autodispose_unregistered_instances;
};

2.19、READER_DATA_LIFECYCLE

策略控制数据读取器管理的数据实例的生命周期.
当autodispose_unregistered_instances设置为true（缺省值）时，数据读取器在删除时时会释放实例。

struct ReaderDataLifecycleQosPolicy {
Duration_t autopurge_nowriter_samples_delay; Duration_t autopurge_disposed_samples_delay;
};

2.20、TIME_BASED_FILTER

按照指定频率经过数据过滤。
设置该参数意味着在指定时间周期内只期望收到一个data sample,过多的data sample将被DataReader丢弃
该参数有助于优化网络负载及节点的计算资源。
比如：默认情况发送方能发送得很快（1秒100个），接受方只要求1秒5个，就可以设置这个参数控制发送速度，减小本地系统资源。

struct TimeBasedFilterQosPolicy { 
Duration_t minimum_separation; 
}; 

2.21、OWNERSHIP

当系统中存在针对同一个数据实例的多人DataWriter时，可以通过设置每DataWrter的"强度"来控制DataWiter的写入权限(“强度”最高的DataWiter拥有写入权限)。
比如: 有两套传感器(冗余)只使用一个，一个发生故障(高强度)，切换到另一个传感器(次强度)。

enum OwnershipQosPolicyKind { 
SHARED_OWNERSHIP_QOS,  // 共享
EXCLUSIVE_OWNERSHIP_QOS  // 独占
}; 
struct OwnershipQosPolicy { 
OwnershipQosPolicyKind kind; 
}; 

2.22、OWNERSHIP_STRENGTH

当OWNERSHIP类型设置为EXCLUSIVE时，OWNERSHIP_STRENGTH策略与OWNERSHIP策略一起使用。

struct OwnershipStrengthQosPolicy { 
long value;  // 独占的强度
};