DDS（Data Distribution Service）数据分发服务-05 Fast DDS框架-1

文章目录

前言
一、Fast DDS框架
- 1.1 DDS Layer

前言

在第4篇文章的时候，展示了如何编译、安装还有运行demo。通过demo程序，基本上能了解如何调用接口实现发布订阅。本文主要讲解Fast DDS的设计框架，有助于更进一步理解及使用API。

一、Fast DDS框架

在这里插入图片描述
Fast DDS整体上可分为四层：

Application layer：应用程，调用Fast DDS API在分布式系统中实现通信的用户应用程序
Fast DDS layer：DDS协议层，实现DSCP框架、QoS策略等
RTPS layer：RTPS协议层，实现与DDS应用程序互操作的实时发布-订阅(RTPS)协议，作为传输层的抽象层
Transport Layer：传输层协议，不可靠传输协议(UDP)、可靠传输协议(TCP)或共享内存传输协议(SHM)

1.1 DDS Layer

DDS协议层就是按照DDS的协议规范（目前最新1.4版本），实现了DCPS模型下的通讯框架、定义了通讯实体及提供给用户使用的PIM（平台无关）API。可从下面5个模块来深入了解DDS：

Core：DDS层核心模块，定义了抽象基类和接口、QoS定义、消息响应模型
Domain：包含DomainParticipant类(充当服务的入口点)，以及许多类的创建工厂
Publisher：定义了发布端的类，包括Publisher和DataWriter实体类，以及PublisherListener和DataWriteListener接口类
Subscriber：定义订阅端的类，包括Subscriber和DataReader实体类，以及SubscriberListener和DataReadListener接口类
Topic：定义用于通讯的主题的类，包括Topic和TopicDescription，以及TypeSupport、TopicListerner

1.1.1 Core

Core模块定义了其他模块将使用的基础结构类和类型。它包含实体类、QoS策略和状态的定义。

实体（Entity）：实体是DDS通信对象，具有Status，可以配置policy
策略（Policy）：实体的具体行为及配置
状态（Status）：实体的通信状态

1.1.1.1 Entity

在这里插入图片描述
DDS 实体继承图，Entity作为抽象基类，派生出其他通讯实体类，以此定义了DDS通讯框架中的所有实体对象。

所有实体类型都具备以下共有属性：

Entity 标识符：定义了一个全局唯一标识符
QoS 策略：每个实体的行为都可以通过一组配置策略进行配置。对于每种实体类型，都有一个相应的服务质量(QoS)类，该类将影响该实体类型的所有策略分组。
监听器（Listener）：监听器类定义了一堆回调函数接口，用于实体在响应消息时调用，比如实体状态回调，实体接受到消息的回调等。监听器继承结构：

每个实体，都有对应的监听器类，比如DataWriteer对应DataWriterListener，用户可以继承这些监听器类复写其中的接口，来实现自定义的回调。定义好监听器类之后，可以调用实体的set_listener()接口，将两者进行关联。
要注意的是在DDS内部也是通过为每个监听器创建线程来实现监听，因此要求回调函数尽可能简单。
状态：每个实体都与一组状态对象相关联，这些状态对象的值表示该实体的通信状态。对这些状态值的更改将触发调用适当的Listener回调，以异步地通知应用程序。

1.1.1.2 Policy

服务质量(QoS)用于指定服务的行为，允许用户定义每个实体的行为方式。为了增加系统的灵活性，QoS被分解为多个QoS策略，每个QoS策略可以独立配置。但是，可能会出现几个策略冲突的情况。这些冲突通过QoS设置器函数返回的ReturnCodes通知给用户。每个Qos策略都有一个在qosppolicyid_t枚举器中定义的唯一ID。此ID在某些Status实例中用于标识该Status所引用的特定Qos Policy。有些QoS策略是不可变的，这意味着只能在实体创建时或调用enable操作之前指定。每个DDS实体都有一组特定的QoS策略，这些策略可以是标准QoS策略、XTypes扩展策略和eProsima扩展策略的混合。

1.1.1.2.1 标准QoS策略

Fast DDS里面的标准QoS策略有22种。

序号	policy	是否支持（V2.14.1）	重要等级
1	DeadlineQosPolicy	是	高
2	DestinationOrderQosPolicy	否	\
3	DurabilityQosPolicy	是	高
4	DurabilityServiceQosPolicy	否	\
5	EntityFactoryQosPolicy	是	中
6	GroupDataQosPolicy	是	低
7	HistoryQosPolicy	是	高
8	LatencyBudgetQosPolicy	否	\
9	LifespanQosPolicy	是	高
10	LivelinessQosPolicy	是	高
11	OwnershipQosPolicy	是	中
12	OwnershipStrengthQosPolicy	是	中
13	PartitionQosPolicy	是	低
14	PresentationQosPolicy	否	\
15	ReaderDataLifecycleQosPolicy	否	\
16	ReliabilityQosPolicy	是	高
17	ResourceLimitsQosPolicy	是	高
18	TimeBasedFilterQosPolicy	否	\
19	TopicDataQosPolicy	是	低
20	TransportPriorityQosPolicy	否	\
21	UserDataQosPolicy	是	低
22	WriterDataLifecycleQosPolicy	否	\

重要等级是个人理解来定义，非官方定义，可能不准确。

DeadlineQosPolicy

作用：当主题数据在设定的阈值内没有更新时，将产生告警。这个策略对于需要定期更新数据的情况，非常有用。对于发布端来说，这个QoS定义了应用程序需在设置的阈值内更新主题数据并发布，对于订阅端来说，这个QoS定义了应用程序需在设置的阈值时间内接受到新的主题数据。
可应用的实体： Topic，DataReader，DataWriter
注意：

DataReaders提供的deadline period(配置)必须小于或等于DataReader中请求的deadline period(配置)
DeadlineQosPolicy必须与TimeBasedFilterQosPolicy设置一致，这意味着截止时间必须大于或等于最小间隔。

DestinationOrderQosPolicy（V2.14.1暂不支持）

作用：当多个DataWriter对同一个Topic发送相同key消息的时候，此QoS策略用于确定这些消息的排序方式。取值范围由DestinationOrderQosPolicyKind确定，默认是BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS类型。
可应用的实体： Topic，DataReader，DataWriter
注意：
DestinationOrderQosPolicyKind类型取值：

BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS：数据按DataReader的接收时间排序的，这个选项可能会导致每个DataReader因接收顺序不一致导致数据不一致。
BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS：数据是根据发送消息时的DataWriter时间戳排序，可以保证多终端数据的一致性。
当DataReaders和datarewriters的DestinationOrderQosPolicy具有不同的类型值时，为了保持它们之间的兼容性，datarereader的类型必须大于或等于DataReader的类型：BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS < BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS

DurabilityQosPolicy：持久性策略

作用：DataWriter可以在没有DataReader的时候，往主题上发布数据。DurabilityQoSPolicy定义了在DataReader连接之前，系统将如何处理存在于Topic上的那些以发布的数据样本。策略取值由DurabilityQosPolicyKind确定。DataReader默认为VOLATILE_DURABILITY_QOS，DataWriter默认为TRANSIENT_LOCAL_DURABILITY_QOS。
可应用的实体： Topic，DataReader，DataWriter
DurabilityQosPolic