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

---

前言

在第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
DurabilityQosPolicyKind取值

• VOLATILE_DURABILITY_QOS：忽略已发布的消息，DataReader只接收加入后的消息
• TRANSIENT_LOCAL_DURABILITY_QOS：当一个新的DataReader加入时，该主题已发布的消息将同步到该新加入的DataReader的历史列表。这样的话，DataReader可以查看到该主题已经发布过哪些消息。
• TRANSIENT_DURABILITY_QOS：与TRANSIENT_LOCAL_DURABILITY_QOS类似，增加了可以将已发布的消息写入数据库等持久化功能。
• PERSISTENT_DURABILITY_QOS：所有消息都进行保存（磁盘等存储介质）
  网上找到的比较好的解释：
  Volatile（默认级别）：数据不需要持久存储，当发布者或者订阅者离线时，数据将丢失
  Transient Local：数据需要在本地磁盘上持久存储，以便在发布者或者订阅者重新连接到系统时，可以重新发送数据
  Transient（最高级别）：数据需要在分布式系统的持久存储中进行持久存储，以便在整个系统重启时，可以重新发送数据。这种策略需要提供数据存储机制，如数据库或者文件系统等。

注意：

• 如果想在DataReader中接收过去的样本，除了设置此QosPolicy外，还需要将reliabilityqosppolicy设置为RELIABLE_RELIABILITY_QOS

DurabilityServiceQosPolicy：持久性服务策略（V2.14.1暂不支持）

作用：当 DurabilityQosPolicy策略配置为TRANSIENT_DURABILITY_QOS or PERSISTENT_DURABILITY_QOS可持久性存储时，DurabilityServiceQosPolicy策略用于配置持久缓存中消息的删除。
可应用的实体： Topic，DataWriter

//DurabilityServiceQosPolicy成员
struct DurabilityServiceQosPolicy {
  Duration_t service_cleanup_delay; //超过该时间间隔，检测到数据instance失活或者没有DataWriter对数据instance进行写入，则清除缓存的历史数据，默认是0
  HistoryQosPolicyKind history_kind;//历史数据保存策略：KEEP_LAST_HISTORY_QOS保存最新或者KEEP_ALL_HISTORY_QOS全保存，默认为KEEP_LAST_HISTORY_QOS
  int32_t history_depth; //保存的消息个数
  int32_t max_samples;  //相关联的ResourceLimitsQosPolicy样本的最大数量
  int32_t max_instances;//相关联的ResourceLimitsQosPolicy实例的最大数量
  int32_t max_samples_per_instance; //每个实例最大样本数
};

EntityFactoryQosPolicy

作用：指定充当工厂的实体是否自动启用它创建的实例。默认使能。
可应用的实体： This QoS Policy concerns to DomainParticipantFactory (as factory for DomainParticipant), DomainParticipant (as factory for Publisher, Subscriber and Topic), Publisher (as factory for DataWriter) and Subscriber (as factory for DataReader).

GroupDataQosPolicy

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

HistoryQosPolicy

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

• KEEP_LAST_HISTORY_QOS：服务将只尝试保留实例的最新值，并丢弃较旧的值。要保留和交付的样本的最大数量由HistoryQosPolicy的另一个成员depth定义，它需要与ResourceLimitsQosPolicy设置保持一致。如果达到深度定义的极限，系统将丢弃最旧的样本，为新的样本腾出空间。
• KEEP_ALL_HISTORY_QOS：全部保留 到达资源限制字段后将不再接收
  注意该策略的参数比如depth需要与ResourceLimitsQosPolicy策略设置的服务资源参数想匹配，如depth的大小不能超过ResourceLimitsQosPolicy设置的对应的最大深度。

LatencyBudgetQosPolicy（V2.14.1暂不支持）

作用：这个策略设置了数据从DataWriter端发布到更新到DataReader端History列表的最大可接受延时，可以使DataWriter写入的每个数据样本都有一个关联的“到期时间”，超过该时间后，该数据样本不再传送给任何应用程序，并且这些数据将从DataReader缓存中及其他可持久性缓存中清除。这个策略对于一些快速变化的数据，如IMU或者雷达这种高频变化的数据，应用必须使用最新的数据，那么可以设置这个策略保证系统丢弃旧的数据。
可应用的实体：Topic，DataWriter，DataReader

LifespanQosPolicy

作用：由DataWriter写入的每个数据样本都有一个关联的过期时间，超过该过期时间，数据将从DataWriter和DataReader历史记录以及瞬态和持久信息缓存中删除。相当于数据发布后，超过设置时间没有被读取，则删除掉。用于控制数据传输的延迟。它定义了数据从发送端到接收端的最大允许延迟时间。当数据的延迟超过设定的延迟预算时，DDS可以采取一些策略，如丢弃数据或调整传输优先级，以确保数据传输的实时性。默认为0。
可应用的实体：Topic，DataWriter，DataReader

LivelinessQosPolicy

作用：心跳机制，用于判断网络中的实体是否还在线。对于发布者来说，该策略指定发布者发送心跳信号的时间间隔，订阅者通过接收心跳信号来判断发布者是否存活。如果在指定的时间间隔内没有收到心跳信号，订阅者将认为发布者已经掉线。对于订阅者来说，该策略指定订阅者等待心跳信号的超时时间，如果在超时时间内没有收到心跳信号，订阅者将认为发布者已经失活，并采取相应的措施，如清除相关数据。超时策略由LivelinessQosPolicyKind类型成员指定。
可应用的实体：Topic，DataWriter，DataReader
LivelinessQosPolicyKind取值：

• AUTOMATIC_LIVELINESS_QOS：只要参与者运行的本地进程和将其连接到远程参与者的链接存在，远程参与者中的实体就会被认为是活动的。适用于只需要检测远程应用程序是否仍在运行的应用程序。表示服务如果在lease_duration时间周期内没有任何网络流量，则自动的发出表示参与者存活的信息。
• 手动模式：MANUAL_BY_PARTICIPANT_LIVELINESS_QOS和MANUAL_BY_TOPIC_LIVELINESS_QOS表示实体要在指定的心跳间隔内写入数据样本或者发送确认在线的消息，心跳间隔时间由lease_duration字段指定。发布端在心跳间隔内发送数据也被认为是在线的，无需发送专门的心跳包。如果在指定的心跳间隔内无数据要发布，则需要手动调用调用assert_liveliness()操作来发送心跳包。

//LivelinessQosPolicy成员
struct LivelinessQosPolicy{
  LivelinessQosPolicyKind kind; //超时策略，默认为AUTOMATIC_LIVELINESS_QOS
  Duration_t lease_duration;//心跳等待间隔
  Duration_t announcement_period; //DataWriter端发心跳间隔
};

OwnershipQosPolicy

作用：此QoS策略指定是否允许多个datawriter更新相同的数据实例（多发布端同时下发某个数据），如果允许，则应如何仲裁这些修改。由OwnershipQosPolicyKind类型成员指定策略，默认为SHARED_OWNERSHIP_QOS。
可应用的实体：Topic，DataWriter，DataReader
OwnershipQosPolicyKind：

• SHARED_OWNERSHIP_QOS：允许多个datareader更新相同的数据实例，并且所有更新都可供现有的datareader使用。
• EXCLUSIVE_OWNERSHIP_QOS：每个实例只能由一个DataWriter更新。可根据OwnershipStrengthQosPolicy策略设置每个DataWriter的强度值（应该是优先级的概念），当出现竞争时，允许强度值高的DataWriter写。如果两个DataWriter具有相同的强度值，GUID值较低的DataWriter将是主题的所有者。

OwnershipStrengthQosPolicy

作用：此QoS策略指定用于在试图修改同一数据实例的多个datawriter之间进行仲裁的强度值。
可应用的实体：DataWriter

PartitionQosPolicy

作用：策略允许在一个域中创建逻辑分区。仅当数据读者和数据写者的分区字符串匹配时，才允许在二者间建立关联关系。有点像在域里面又创建了个小域，只有在小域里面的DataReader和DataWriter才能通讯。
可应用的实体：Publisher，Subscriber

PresentationQosPolicy（V2.14.1暂不支持）

作用：在一组DDS data sample的更新都到达接收端后，应用程序才能够访问这一组data sample,适用于不同数据实例之间存在关联关系的场景。比如:坐标数据，x,y,z都获取到才能访问这组数据。由PresentationQosPolicyAccessScopeKind类型成员指定类型。
可应用的实体：Publisher，Subscriber

ReaderDataLifecycleQosPolicy（V2.14.1暂不支持）

作用：DataReader会对接收到的消息创建缓存进行保存和管理，为避免因应用程序没读走等原因导致长时间不释放资源，通过这个QoS策略可以设置对消息的管理周期，以便强制释放资源。
可应用的实体：DataReader

ReliabilityQosPolicy：服务可靠性策略

作用：此QoS策略表示服务提供和请求的可靠性级别。服务可靠性策略由ReliabilityQosPolicyKind类型成员配置。对于DataReader，默认为BEST_EFFORT_RELIABILITY_QOS，对于DataWriter，默认为RELIABLE_RELIABILITY_QOS
可应用的实体：Topic，DataWriter，DataReader

//ReliabilityQosPolicy成员
struct ReliabilityQosPolicy{
  ReliabilityQosPolicyKind kind; //传输策略，BEST_EFFORT_RELIABILITY_QOS：尽最大能力传输，不重发，类似UDP的效果；RELIABLE_RELIABILITY_QOS：可靠传输，有应答，类似TCP的效果
  Duration_t max_blocking_time;//写端最大阻塞间隔
};

ResourceLimitsQosPolicy：

作用：配置DDS服务的一些参数，比如sample、instance的最大数量。
可应用的实体：Topic，DataWriter，DataReader

TimeBasedFilterQosPolicy：（V2.14.1暂不支持）

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

TopicDataQosPolicy：

作用：允许应用程序将附加信息附加到已创建的Topic上，以便当远程应用程序发现该Topic时，它可以访问并使用该数据。
可应用的实体：Topic

TransportPriorityQosPolicy：（V2.14.1暂不支持）

作用：控制传输数据的优先级，由一个整数表示，值越大优先级越高。
可应用的实体：Topic，DataWriter

UserDataQosPolicy：

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

WriterDataLifecycleQosPolicy：（V2.14.1暂不支持）

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

1.1.1.2.2 eProsima扩展QoS策略

Fast DDS自定义的QoS策略有15种。

DataSharingQosPolicy

作用：配置数据共享传递功能。
可应用的实体： DataReader，DataWriter

DisablePositiveACKsQosPolicy

作用：该策略通过省去DataReader端回复ack信号给DataWriter端的动作，来降低网络传输的数据量，避免网络阻塞。在对传输质量要求不高或者带宽有限的情况下，可以使用该策略。
可应用的实体： DataReader，DataWriter

//DisablePositiveACKsQosPolicy成员
struct DisablePositiveACKsQosPolicy{
  bool enabled; //是否使能该策略
  Duration_t duration;//写端在这个时间内为读端保留数据的时间
};

FlowControllersQos

作用：写端流量控制。主要的控制策略是限定DataWriter在设置的周期内，写入到网络的数据量不能超过某个阈值。比如1s内，不能超过300KByte。
可应用的实体： DomainParticipant

ParticipantResourceLimitsQos

作用：设置DomainParticipant 所使用到的资源大小。
可应用的实体： DomainParticipant
这个策略包含了众多服务参数的配置，很多参数的意义都看不太懂。

//ParticipantResourceLimitsQos成员
struct ParticipantResourceLimitsQos{
  RemoteLocatorsAllocationAttributes locators; //跟远端发现相关的配置，看不太懂
  //ResourceLimitedContainerConfig 类型主要是用来配置容器的大小
  ResourceLimitedContainerConfig participants;//participants的最大数量
  ResourceLimitedContainerConfig readers; //readers的最大数量
  ResourceLimitedContainerConfig writers; //writers的最大数量
  SendBuffersAllocationAttributes send_buffers; //发送缓冲区参数配置
  VariableLengthDataLimits data_limits; //应该是UserData、GroupData这些策略的数据长度限制
  ContentFilterProperty::AllocationConfiguration content_filter;
};

PropertyPolicyQos

作用：这个附加的QoS策略(PropertyPolicyQos)存储了名称/值对，这些名称/值对可用于配置某些不能使用标准QoS策略直接配置的DDS设置。

PublishModeQosPolicy

作用：设置DataWriter如何发送数据。
可应用的实体： DataWriter
主要是两种模式：

• SYNCHRONOUS_PUBLISH_MODE：同步模式，数据在调用写操作的用户线程的上下文中发送。应该是会阻塞用户程序的线程。
• ASYNCHRONOUS_PUBLISH_MODE：内部线程负责异步发送数据。写操作在数据实际发送之前返回。
  默认为同步模式。

ReaderResourceLimitsQos

作用：此QoS策略根据将与DataReader匹配的数据写入器的最大数量来声明匹配的数据写入器资源有限集合的限制。
可应用的实体： DataReader

RTPSEndpointQos

作用：此QoS策略配置RTPS端点的各个方面，例如定位器列表、标识符和历史内存策略。
可应用的实体： DataWriter， DataReader

RTPSReliableReaderQos

作用：配置RTPS Reader可靠传输。主要是配置一些延时时间阈值。
可应用的实体： DataReader

RTPSReliableWriterQos

作用：配置RTPS Writer可靠传输。主要是配置一些延时时间阈值。
可应用的实体： DataWriter

ThreadSettings

作用：DDS内部会自动创建线程来完成一些任务，这个QoS主要用来配置线程的，比如优先级，栈大小。

TransportConfigQos

作用：配置传输层参数。
可应用的实体： DomainParticipant
成员：

• user_transports：此数据成员定义要与内置数据一起使用或代替内置数据使用的传输列表
• use_builtin_transports：控制是启用还是禁用内置传输层。如果设置为false，则禁用默认的UDPv4实现。
• send_socket_buffer_size：默认情况下，Fast DDS使用系统默认大小创建套接字缓冲区。此数据成员允许更改用于发送数据的发送套接字缓冲区大小。
• listen_socket_buffer_size：监听套接字缓冲区大小也是用系统默认大小创建的，但是可以使用这个数据成员来更改它。
• builtin_transports_reception_threads()：DDS与这个QoS相关的内建线程的参数

WireProtocolConfigQos

作用：有线传输协议配置。
可应用的实体： DomainParticipant
比较复杂，，看不太懂。

WriterResourceLimitsQos

作用：此QoS策略根据将与DataWriter匹配的datareader的最大数量来声明匹配的datareader的资源限制集合的限制。
可应用的实体： DomainParticipant

1.1.1.2.3 XTypes 扩展QoS策略

1.1.1.2 Status

每个实体都与一组状态对象相关联，这些状态对象的值表示该实体的通信状态。状态值的变化是由于与每个实体相关的通信事件而发生的，例如，当新数据到达时，发现一个新的参与者，或者丢失一个远程端点。当状态改变时，会触发相应的回调函数。
同时Conditions and Wait-sets机制为应用程序提供了一种机制，可以同时等待多个实体的状态更改后，再去执行某些动作。
Fast DDS列出了15种状态及其对应的回调函数。

InconsistentTopicStatus

每次发现不一致的远端Topic(即与当前Topic名称相同但特征不同的Topic)时，该状态都会改变。

DataOnReaders

绑定在Subscriber的DataReader上有新消息到达时，触发状态改变，进而回调Subscriber的on_data_on_reader回调。

DataAvailable

DataReader上有新消息到达时，触发状态改变，进而回调DataReader的on_data_available回调。

LivelinessChangedStatus

每次匹配的DataWriter的活跃状态发生变化时，此状态都会发生变化。这可能是因为处于非活动状态的DataWriter变得活动了，也可能是因为相反的原因。

RequestedDeadlineMissedStatus

每次在DataReaderQos上配置的截止时间内没有接收到数据时，该状态都会改变。

RequestedIncompatibleQosStatus

每次DataReader找到与Topic匹配且具有公共分区的DataReader，但其QoS配置与DataReader上定义的QoS配置不兼容时，此状态都会更改。

SampleLostStatus

数据丢失时，会触发状态改变及回调

SampleRejectedStatus

每次传入的数据样本被DataReader拒绝时，此状态都会更改。

SampleRejectedStatusKind

当数据样本被拒绝发送或接受时，会触发回调。

SubscriptionMatchedStatus

每当DataReader找到与主题匹配且具有公共分区和兼容QoS的DataWriter，或者不再与以前认为匹配的DataWriter匹配时，此状态都会更改。

LivelinessLostStatus

DataWriter未在设置的超时时间内发送数据或者心跳，会触发状态改变及回调。

OfferedDeadlineMissedStatus

DataWriter端没有在设置周期时间发布数据，会触发状态改变及回调。

OfferedIncompatibleQosStatus

每次DataWriter发现与Topic匹配且具有公共分区的DataReader，但其QoS配置与DataWriter上定义的配置不兼容时，此状态都会更改。

PublicationMatchedStatus

每当DataWriter发现与Topic匹配且具有公共分区和兼容QoS的DataReader，或者不再与以前认为匹配的DataReader匹配时，此状态都会发生变化。

1.1.2 Domain

一个域表示一个单独的通信平面。它在共享公共通信基础设施的实体之间创建了逻辑分离。从概念上讲，它可以看作是一个虚拟网络，连接在同一域中运行的所有应用程序，并将它们与在不同域中运行的应用程序隔离开来。通过这种方式，几个独立的分布式应用程序可以共存于同一个物理网络中，而不会相互干扰，甚至不会相互察觉。

1.1.2.1 DomainParticipant

DomainParticipant是应用程序到域的入口点。每个DomainParticipant从创建时就链接到单个域，并包含与该域相关的所有实体。它还充当发布者、订阅者和主题的创建工厂。DomainParticipant的行为可以通过DomainParticipantQos类上指定的QoS值进行修改。QoS值可以在创建DomainParticipant时设置，也可以稍后使用DomainParticipant::set_qos()成员函数修改。作为一个实体，DomainParticipant接受DomainParticipantListener，该listener将收到DomainParticipant实例状态变化的通知。

• DomainParticipantQos类
  用于设置DomainParticipant，该类内部包含了适用于DomainParticipant实体的所有QoS策略类：

QosPolicy class	Accessor/Mutator
UserDataQosPolicy	user_data()
EntityFactoryQosPolicy	entity_factory()
ParticipantResourceLimitsQos	allocation()
PropertyPolicyQos	properties()
WireProtocolConfigQos	wire_protocol()
TransportConfigQos	transport() and setup_transports()
FlowControllersQos	flow_controllers()
ThreadSettings	builtin_controllers_sender_thread()
ThreadSettings	timed_events_thread()
ThreadSettings	discovery_server_thread()
ThreadSettings	security_log_thread()

• DomainParticipantListener类
  抽象类，定义响应DomainParticipant的状态变化时将被触发的回调函数接口。
  DomainParticipantListener继承了TopicListener, PublisherListener和SubscriberListener。除了父类定义的回调接口，还支持以下新增回调：
  on_participant_discovery()：在同一域中发现了一个新的DomainParticipant，以前已知的DomainParticipant已被删除，或者某些DomainParticipant已更改其QoS，会触发该回调。该方法提供了一个带有附加布尔输出参数的重载，因此该回调可以通过使用ignore_participant()告诉中间件是否必须忽略新发现的参与者。当需要忽略发现回调中的参与者时，应该使用此重载，因为在侦听器中调用ignore_participant()可能会死锁。如果两个回调都实现了，则带有should_be_ignored布尔标志的发现回调优先。只有在第一次回调中没有忽略发现的DomainParticipant (should_be_ignored参数返回false)时，才会执行第二个发现回调。
  on_subscriber_discovery()：在同一域中发现了新的订阅者，以前已知的订阅者已被删除，或者某些订阅者已更改其QoS，会触发回调。
  on_publisher_discovery()：在同一域中发现了新的Publisher，以前已知的Publisher已被删除，或者某些Publisher已更改其QoS，会触发回调。
  on_type_discovery()：在同一域中发现新的数据类型
  on_type_dependencies_reply()：类型查找客户端收到了对getTypeDependencies()请求的重播。此回调可用于使用getTypes()请求检索新类型，并使用检索到的类型对象创建新的动态类型。on_type_information_received()：从一个新发现的DomainParticipant接收到一个新的TypeInformation。onParticipantAuthentication():通知远程DomainParticipant的认证过程的结果(失败或成功)。

• DomainParticipantFactory类
  工厂类，用于创建DomainParticipant实例。可通过DomainParticipantFactoryQos修改一些配置参数。

• DomainParticipant创建
  通过DomainParticipantFactory的 create_participant() 创建，通过 delete_participant()销毁。
  创建时，必须传入DomainId和QoS参数。可选参数： DomainParticipantListener，StatusMask：使能/失能对应的状态，可不响应某些状态变化，也就不调用对应的回调函数，默认是全使能。

注意指定DomainId时，根据DDSI-RTPS V2.2标准(第9.6.1.1节)，默认端口是根据DomainId计算的，因此，建议使用低于200的DomainId(超过DomainId 233的默认端口分配将始终失败)。

参考文档：https://fast-dds.docs.eprosima.com/en/v2.14.1/fastdds/dds_layer/dds_layer.html 章节3.1 3.2