Fast-DDS源码阅读笔记(二)-DDS层

eProsima Fast DDS 提供了两种不同的API，以在不同层面上与通信服务进行交互。 主要的API是数据分发服务（DDS）数据中心化发布/订阅（DCPS）平台无关模型（PIM）API，或者简称为DDS DCPS PIM，它是由DDS 1.4规范定义的，Fast DDS 遵循该规范，由Core，Domain，Publisher，Subscriber，Topic五个核心概念构成

Core

Core中定义了其他模块使用的基础类和类型，包括Entity类，Qos策略，与Status

Entity

所有DDS实体的抽象基类，实体的层次结构如下

通用Entity特性

下面的特征是所有的Entity都所有的

特征	描述
Entity Identifier	ID标识，get_instance_handle()获取
Qos Policy	服务质量策略
Listener	包含Entity在响应事件时调用的函数，充当异步通知系统
Status	代表着Entity的通信状态
Status Condition	Entity与等待集之间的桥梁

Listener继承关系

Policy

Qos指定服务的行为，使得用户能定义Entity的行为。Qos被分解成多个独立的Qos策略增加系统的灵活性。多个策略冲突时，可以通过函数返回的ReturnCodes通知用户。

每个Qos Policy都有一个唯一的ID(QosPolicyId_t类型)，标识具体的Qos Policy。每个DDS Entity都有一套特定的Qos策略，主要是标准Qos，XTypes与Eprosima三种策略。

Policy和匹配规则详见参考资料

Status

每个Entity与一组Status相关联，Status值代表着Entity的通信状态，变化由Entity相关的通信事件引起（比如新数据到达，发现新的Paticipant与EndPoint下线）。Status分解成不同的Status对象，并且与通信的不同方面有关，维持了Status之间的独立性。
SatusD的变化触发Listener的相应事件回调，对于给定的Status对象，Listener定义了一个接口（example：fooStatus的状态对象与on_foo数据回调）Status会在相应的回调触发之后被重置。
条件和等待集为应用层提供了另一种机制，使得可以等待多个Entity的变化。并且能够在外部线程中处理回调。

Conditions与Wait-Sets

Conditions与Wait-sets一起使用，给应用层提供了接收通信状态变化的能力，具体的方式如下

graph TD; A[Start] --> B[wait]; B --> C[Get Satus Change]; C --> D{Use done?}; D -- Yes --> E[detach_condition]; E --> F[End]; D -- No --> B;

GuardCondition

通过调用set_trigger_value()触发条件

StatusCondition

通信状态发生变化即触发

ReadCondition

存在一个Sample与ReadCondition匹配时触发

Domain

Domain是一个独立的通信平面，在共享同一基础设施的实体间创建逻辑分离，每个Domain都有一个DomainID，应用层如果需要添加到域中，需要创建一个感兴趣的DomainDomainParticipant实例，DomainParticipant由DomainParticipantFactory创建。

DomainParticipant

应用层与Domain的入口点，创建时便与单个Domain关联并包含的Entities，并充当Puber，Suber与Topic的工厂，可以通过指定Qos来修改DomainParticipant的行为

每个DomainParticipant接受一个DomainParticipantListener并且Listener在Entity状态发生变化的时候收到通知

DomainParticipantListener

抽象基类，定义了DomainParticipant 状态发生变化时的行为，默认下情况下所有的行为都是空,用户可以继承并且实现这个类

DomainParticipantFactory

单列，主要用于创建DomainParticipant

Partitions

分区是在Domain的物理隔离之后引入的逻辑隔离概念，代表着域和主题之上的另一个隔离层，相比Domain的隔离方式，更加轻量，并且可修改可在endpoint的生命周期中动态的更改。相比于Endpoint与domain之间的一一对应关系，一个endpoint可以从属多个分区

Publisher

DataWriter

DataWriter从属于Publisher，绑定到单独的Topic上

DataWriterListener

抽象类，定义状态变化时应该触发的回调。
on_publication_matched() 发现DataReader 匹配Topic与Partition时触发
on_offered_deadline_missed() 在无法在超时时间内发送数据时触发
on_offered_incompatible_qos()顾名思义
on_liveliness_lost() Reader因为DataWriter不遵守DataWriterQos认为Writer掉线时触发。
on_unacknowledged_sample_removed() 未被ACK的样本被移除

Subscriber

Subscriber 扮演容器的角色，一个Subscriber可以包含多个DataReader，并且这些DataReader的 SubscriberQos一致

SubscriberListener

同PublisherListener

DataReader

归属于特定的Subscriber，绑定到单独的Topic上。

DataReaderListener

类似于DataWriterListener

SampleInfo

当sample被DataReader取出,SampleInfo同样返回，其中包含着例如Sample是否可用的信息。

Topic

Topic,Keys and instance

instance可以理解为Topic下面的再进行逻辑划分，根据不同的key获得不同的sample
instance的优势有不需要重新创建DataWriter，DataReader,以及与此相关的服务发现带来的开销。instance的生命周期如下