Fastdds_ContentFilteredTopicExample_代码剖析2_qos

        在上一章节中,我们观看了FastDDS提供的ContentFilteredTopicExample案例中发布者初始化的一个大致流程,在本章中我们将详细观察在初始化的过程中,qos做了什么。本章将引用hzy博主的部分图片与原文,已与博主取得授权,博客地址如下:https://zhuanlan.zhihu.com/p/695277440

        在进入代码观看之前,我们需要简单介绍一下qos的概念。QoS(Quality of Service)即服务质量规范,在官方的介绍中,对Qos作出了以下的定义:

“数据还可以通过灵活的服务质量 (QoS) 规范进行共享,包括可靠性、系统运行状况(活跃性)甚至安全性。在真实的系统中,并非所有其他端点都需要本地存储中的所有数据。 DDS 很聪明,只发送它需要的内容。如果消息并不总是到达预期目的地,中间件会在需要时实现可靠性。当系统发生变化时,中间件会动态地确定将哪些数据发送到哪里,并智能地将变化通知参与者。如果总数据量很大,DDS会智能过滤并仅发送每个端点真正需要的数据。当需要快速更新时,DDS 会发送多播消息来同时更新许多远程应用程序。随着数据格式的发展,DDS 会跟踪系统各个部分使用的版本并自动进行转换。对于安全关键型应用程序,DDS 控制访问、强制执行数据流路径并动态加密数据。当您在非常动态、要求严格且不可预测的环境中以极高的速度同时指定所有这些内容时,DDS 的真正威力就会显现出来。”

        这段话非常好的体现了Qos的特点,在同一时间当一个大系统里面存在多种数据需要传输并且对不同数据的传输“需求”不同的场景,这时候正是Qos发挥其威力的时候。Qos其实就是DDS配置相当于socket里面的set_option。根据不同的使用场景,qos为域参与者、发布者、订阅者、数据读者、数据写者、主题提供了多种选择,以满足其对通信需求配置(可靠性,持久化,传输优先级,延迟预算,截止时间)和数据呈现(所有权,基于时间过滤等),资源需求配置(历史数据,资源限制)以及自动发现配置(分区,实体工厂等)四方面的要求。更加详细的内容可以参考我所贴出的博客

        我们引用hzy博主的一张图片,展现一下qos与各模块之间的关系:

        

        各个模块都有对应的qos配置,以保障服务需求的实现。

        回到代码层面

        我们今天主要看的就是初始化中这三行代码中的前两行代码,第三行将在下章讲解:

    DomainParticipantQos pqos;
    pqos.name("Participant_pub");
    // Create DomainParticipant in domain 0
    participant_ = DomainParticipantFactory::get_instance()->create_participant(0, pqos);

        先粗略的讲解一下他做了什么,这里就是先设置了一个域参与者的qos然后在工厂创建域参与者时对其进行了配置。

        我们先看一下DomainParticipantQos在构造pqos的时候发生了什么。代码如下:

    FASTDDS_EXPORTED_API DomainParticipantQos()
    {
#ifdef FASTDDS_STATISTICS
        /*
         * In the case of Statistics, the following properties are set with an empty value. This is because if these
         * properties are set and empty during the enabling of the DomainParticipant, they are fill with the default
         * mechanism
         */
        properties_.properties().emplace_back(parameter_policy_physical_data_host, "");
        properties_.properties().emplace_back(parameter_policy_physical_data_user, "");
        properties_.properties().emplace_back(parameter_policy_physical_data_process, "");
#endif // ifdef FASTDDS_STATISTICS
    }

        在构造函数之前,他加了一个宏定义,该宏定义的作用为控制该函数在编译和链接过程中的导出和导入属性,这种机制主要用于跨平台库的开发,特别是在需要生成动态链接库(DLL)的情况下。通过这些宏定义,可以确保构造函数在不同的平台和编译环境下正确地导出或导入。

        在之后当定义了FASTDDS_STATISTICS时,向properties_属性中添加三个属性,分别表示主机、用户和进程的物理数据。每个属性都由一个键值对(名称和值)组成,这里值被设置为空字符串。因为如果这些属性在DomainParticipant启用时为空,系统会自动为它们填充默认值。这样做的目的是确保即使属性在初始化时为空,系统仍然能够提供合理的默认值。需要说明的是这些parameter_policy_physical_data_host之类的是不能修改的字符串.

const char* const parameter_policy_physical_data_host = "fastdds.physical_data.host";

        我们来看一下properties_是什么,他的定义如下:

PropertyPolicyQos properties_;
using PropertyPolicyQos = fastrtps::rtps::PropertyPolicy;

        我们可以看到他其实是rtps的PropertyPolicy。PropertyPolicy类提供了一种管理属性的机制,允许动态设置和获取属性。通过向properties_属性集合中添加特定的属性,可以为系统配置特定的行为或选项。在代码中,通过调用properties_.properties().emplace_back() 方法向属性集合中添加新的属性空。

        PropertyPolicy 支持默认构造,移动构造,复制构造。构造函数代码如下:

    FASTDDS_EXPORTED_API PropertyPolicy()
    {
    }

    FASTDDS_EXPORTED_API PropertyPolicy(
            const PropertyPolicy& property_policy)
        : properties_(property_policy.properties_)
        , binary_properties_(property_policy.binary_properties_)
    {
    }

    FASTDDS_EXPORTED_API PropertyPolicy(
            PropertyPolicy&& property_policy)
        : properties_(std::move(property_policy.properties_))
        , binary_properties_(std::move(property_policy.binary_properties_))
    {
    }

    FASTDDS_EXPORTED_API PropertyPolicy& operator =(
            const PropertyPolicy& property_policy)
    {
        properties_ = property_policy.properties_;
        binary_properties_ = property_policy.binary_properties_;
        return *this;
    }

        那么很明显这里走的是默认构造什么都不做。

        然后他又获取了一个内部的properties_ 代码如下:

    //!Set properties
    FASTDDS_EXPORTED_API PropertySeq& properties()
    {
        return properties_;
    }

        这个properties_则是property的一个vector容器。

PropertySeq properties_;

        绕了半天终于可以见到property了。

        在property中,会走以下构造函数:

    Property(
            const std::string& name,
            const std::string& value,
            bool propagate = false)
        : name_(name)
        , value_(value)
        , propagate_(propagate)
    {
    }

property类的主要作用是表示一个属性键值对。每个property对象包含以下成员:

  • name: 属性的名称。
  • value_: 属性的值。
  • propagate_: 一个布尔值,指示属性是否需要传播(在某些情况下可能有用,例如分布式系统中的配置传播)。

之后他对pqos设置了一个名字后将其传入到了工厂之类。

梳理:在本章节中,我们观察了在ContentFilteredTopicExample案例构造的发布者中,域参与者qos初始化是怎么进行的,在域参与者qos中,他将三个属性添加到属性列表perproties_中,分别表示主机、用户和进程的物理数据。他将他们的值设置为空表示在构造域参与者时进行默认的行为。我们同时也观察了property是什么,那么property和qos的关系是什么?

PropertyQoS 的关系

  1. 属性(Property)作为 QoS 配置的一部分

    • property 类用于存储具体的属性键值对,这些属性可以包括各种配置参数,例如主机信息、用户信息、进程信息等。
    • 这些属性在 QoS 策略中用于细化和定制 QoS 参数的行为。例如,可以通过属性设置来控制特定的 QoS 特性。
  2. PropertyPolicy 类包含属性集合

    • PropertyPolicy 类用于管理一组属性(property 对象)。这些属性可以用于配置不同的 QoS 策略。
    • PropertyPolicy 类通常会嵌入在 QoS 策略类中,用于提供额外的配置选项。
  3. QoS 策略类

    • DDS 中有多种 QoS 策略类,例如DomainParticipantQosDataRea、DataReaderQos、DataWriterQos 等。
    • 这些策略类通常会包含一个或多个PropertyPolicy对象,以提供更灵活和详细的配置选项。

在下一章中我们将看到初始化的qos是怎么在工厂中被使用创建域参与者的。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值