eProsima Fast DDS公开了两个不同的API,以在不同级别与通信服务交互。主要API是数据分发服务(DDS)数据中心发布订阅(DCPS)平台独立模型(PIM)API,简称DDS DCPS PIM,由Fast DDS遵循的数据分发服务1.4版规范定义。本节旨在解释Fast DDS下此API的主要特性和使用模式,并对其分为五个模块进行深入解释:
-
Core: 它定义了由其他模块细化的抽象类和接口。它还提供了服务质量(QoS)定义,以及支持中间件的基于通知的交互。
-
Domain: 它包含充当服务入口点的DomainParticipant类,以及许多类的工厂。DomainParticipant还充当构成服务的其他对象的容器。
-
Publisher: 它描述了发布端使用的类,包括Publisher和DataWriter类,以及PublisherListener和DataWriterListener接口。
-
Subscriber: 它描述了订阅端使用的类,包括Subscriber和DataReader类,以及SubscriberListener和DataReaderListener接口。
-
Topic: 它描述了用于定义通信主题和数据类型的类,包括Topic和TopicDescription类,以及TypeSupport和TopicListener接口。
1、Core
此模块定义其他模块将使用的基础结构类和类型。它包含实体类、QoS策略和状态的定义。
- Entity: 实体是具有状态的DDS通信对象,可以使用策略进行配置。
- Policy: 控制实体行为的每个配置对象。
- Status: 与实体关联的每个对象,其值表示该实体的通信状态。
1.1 Entity
Entity(实体)指代各个实体对象,如DomainParticipant、Publisher、Subscriber、DataWriter、DataReader等。Entity的作用是对DDS中的概念进行抽象,允许用户创建和管理这些对象并在它们之间进行通信和交互。
Fast DDS的Entity采用面向对象编程的思想,在实现过程中与对象的属性和行为相对应。对象的属性(Attribute)描述了对象所具有的状态信息,包括实体名称、实体ID、实体类型、传输模式、QoS参数等。对象的行为(Behavior)定义了对象可以执行的操作,包括创建、销毁、启动、停止、发布、订阅、发现等。
1.1.1 Entity的类型
-
DomainParticipant: 此实体是服务的入口点,充当发布服务器、订阅服务器和主题的工厂。有关详细信息,请参阅DomainParticipant。
-
Publisher: 它充当一个工厂,可以创建任意数量的DataWriter。有关详细信息,请参阅Publisher。
-
Subscriber: 它充当一个工厂,可以创建任意数量的DataReader。有关详细信息,请参阅订阅服务器。
-
Topic: 此实体位于发布实体和订阅实体之间,充当通道。有关详细信息,请参阅主题。
-
DataWriter: 是负责数据分发的对象。有关详细信息,请参阅DataWriter。
-
DataReader: 用于访问接收数据的对象。有关详细信息,请参阅DataReader。
下图显示了所有DDS实体之间的层次结构:
1.1.2 通用实体特征
所有实体类型都具有实体概念所共有的一些特征。
1.1.2.1 Entity标识符
每个实体都由一个唯一的ID标识,该ID在DDS实体与其对应的RTPS实体(如果存在)之间共享。该ID存储在Entity基类上声明的Instance Handle对象上,可以使用getter函数get_Instance_Handle()访问该对象。
1.1.2.2 QoS策略
可以使用一组配置策略来配置每个实体的行为。对于每个实体类型,都有一个对应的服务质量(QoS)类,该类对影响所述实体类型的所有策略进行分组。用户可以创建这些QoS类的实例,根据自己的需要修改包含的策略,并在创建过程中或稍后使用每个实体公开的set_QoS()函数来配置实体(DomainParticipant::set_qos(),Publisher::set_qos(),Subscriber::set.qos(),Topic::set.qos(),DataWriter::set_qos(),DataReader::set.qos())。QoS类及其包含的策略在每个实体类型的文档中进行了解释。
有关可用策略及其说明的列表如下所示:
QoS枚举 | 作用 |
---|---|
DurabilityQosPolicyKind | 决定数据在发布者(Publisher)断开连接后是否仍然可以被Consumer接收。 |
DeadlineQosPolicyKind | 定义了数据生产者(DataWriter)在多长时间内必须将数据发送给消费者(DataReader)。 |
LatencyBudgetQosPolicyKind | 定义了数据从生产到消费所需的最大延迟。 |
LivelinessQosPolicyKind | 定义了数据生产者的活动状态。 |
ReliabilityQosPolicyKind | 决定数据传输的可靠性,是否使用重传机制。 |
HistoryQosPolicyKind | 可以控制以前已经发布的数据如何进行管理和存储,以及何时将它们删除。 |
ResourceLimitsQosPolicyKind | 定义了数据生产者和数据消费者之间交换数据时可以利用的最大资源。 |
OwnershipQosPolicyKind | 允许DDS使用一组规则来确定哪个实体具有对数据的所有权。 |
OwnershipStrengthQosPolicyKind | 定义了拥有权之间相互竞争的实体之间的关系。 |
WriterDataLifecycleQosPolicyKind | 管理当数据生产者(DataWriter)结束时如何处理由该生产者写入的数据。 |
ReaderDataLifecycleQosPolicyKind | 管理当数据消费者(DataReader)结束时如何处理由该消费者读取的数据。 |
1.1.2.3 Listener监听器
侦听器包含一些函数,实体使用这些函数来响应事件。因此,侦听器充当异步通知系统,允许实体向应用程序通知实体中的状态更改。因此,侦听器就像一个异步通知系统,允许实体向应用程序通知实体中的状态更改。
所有实体类型都定义一个抽象侦听器接口,该接口包含实体将触发的回调函数,以将状态更改传递给应用程序。用户可以实现自己的侦听器,从这些接口继承并实现应用程序所需的回调。然后,他们可以在创建过程中或稍后使用每个实体公开的set_listener()函数将这些侦听器链接到每个实体(DomainParticipant::set_listenr(), Publisher::set_litener(), Subscriber::set-listener((), Topic::set-liistener()), DataWriter::set _listener。每个实体类型的侦听器接口及其回调在每个实体类型文档中进行了解释。当事件发生时,它由具有非空侦听器的最低级别实体处理,并且在其StatusTask中启用了相应的回调。高级侦听器继承自低级侦听器,如下图所示:
注意:
on_data_on_readers()回调在on_data_available()之前拦截消息。这意味着如果启用了DomainParticipantListener,用户应该考虑默认情况下侦听器使用StatusMask::all()。由于保留了回调实体层次结构,在这种情况下将调用on_data_on_readers()。如果应用程序希望改用on_data_available(),则应禁用Statusask的相应位。
重要:
-
在创建实体时使用StatusMask::none()仅禁用DDS标准回调:
on_sample_rejected()
on_liveliness_changed()
on_requested_deadline_missed()
on_requested_incompatible_qos()
on_data_available()
on_subscription_matched()
on_sample_lost()
on_offered_incompatible_qos()
on_offered_deadline_missed()
on_liveliness_lost()
on_publication_matched()
on_inconsistent_topic()
on_data_on_readers() -
始终启用特定于Fast DDS的任何回调:
on_participant_discovery()
on_ParticipantAuthentication()
on_subscriber_discovery()
on_publisher_discovery()
on_type_discovery()
on_type_dependencies_reply()
on_type_information_received()
on_unacknowledged_sample_removed()
警告
-
只创建一个线程来侦听每个实现的侦听器,因此建议保持侦听器函数的简单性,将此类信息的处理留给适当的类。
-
不要在侦听器成员函数的范围内创建或删除任何实体,因为这可能会导致未定义的行为。相反,建议使用Listener类作为信息通道,并使用上层Entity类来封装此类行为。
1.1.2.4 Status
每个实体都与一组状态对象相关联,这些状态对象的值表示该实体的通信状态。这些状态值的更改会触发调用相应的Listener回调以异步通知应用程序。有关所有状态对象的列表及其内容的描述,请参见状态。在那里,您还可以找到哪个状态适用于哪个实体类型。
1.1.2.5 StatusCondition
每个实体都有一个StatusCondition,每当其启用状态更改时,都会通知它。StatusCondition提供实体和等待集之间的链接。有关详细信息,请参阅“条件和等待集”一节。
1.1.2.6 启用实体
所有实体都可以创建为已启用或未启用。默认情况下,工厂被配置为创建已启用的实体,但可以对已启用的工厂使用EntityFactoryQosPolicy进行更改。禁用的工厂创建禁用的实体,而不管其QoS如何。禁用实体的操作仅限于以下操作:
- Set/Get 实体的QoS策略
- Set/Get 实体监听器
- Create/Delete 子实体
- 得到实体的状态,即使他们没有改变
- 查找操作
在这种状态下调用的其他函数都会返回NOT_ENABLED.
转载自:https://www.cnblogs.com/zhangzl419/p/17158631.html
部分内容不完整,后期持续补充更新,所有内容均来自fastdds官方文档:https://fast-dds.docs.eprosima.com/en/latest/
标签:set,QoS,DDS,fastdds,实体,学习,侦听器,DataWriter From: https://www.cnblogs.com/xingyuchen/p/17324212.html