FastDDS服务发现之PDP和EDP的创建

已于 2025-04-16 16:23:20 修改
阅读量2k 收藏 14
点赞数 2
分类专栏： Fast DDS 文章标签： 中间件 去中心化 linux c++ 1024程序员节 FastDDS
于 2023-09-20 09:26:35 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010378559/article/details/133064758
版权

目录

Fast DDS提供了可以跨DomainParticipants主动发现和匹配DataWriters和DataReaders来共享数据的机制。本文简要介绍Fast DDS中不同的服务发现机制，重点分析Simple Discovery的对象创建

内置协议

BuiltinProtocols类是内置协议的主要处理器。BuiltinProtocols包括以下主要数据：

//协议属性字段
BuiltinAttributes m_att;
//服务发现的PDP对象
PDP* mp_PDP;
//WriterLiveness 对象，用于心跳保活
WLP* mp_WLP;
//!Pointer to the TypeLookupManager
fastdds::dds::builtin::TypeLookupManager* tlm_;
//!Locator list for metatraffic
LocatorList_t m_metatrafficMulticastLocatorList;
//!Locator List for metatraffic unicast
LocatorList_t m_metatrafficUnicastLocatorList;
//! Initial peers
LocatorList_t m_initialPeersList;
//! Known discovery and backup server container
std::list<eprosima::fastdds::rtps::RemoteServerAttributes> m_DiscoveryServers;

BuiltinAttributes类用于配置BuiltinProtocols所需要的内容，主要有以下字段：

DiscoverySettings discovery_config;

//是否使用保活协议（WriterLiveliness protocol）
bool use_WriterLivelinessProtocol = true;

//! TypeLookup Service settings
TypeLookupSettings typelookup_config;

//单播地址，这个默认是7410，0.0.0.0,它的作用是什么？
LocatorList_t metatrafficUnicastLocatorList;

//组播地址，默认为7400，239.255.0.1
LocatorList_t metatrafficMulticastLocatorList;

//! The collection of external locators to use for communication on metatraffic topics.
fastdds::rtps::ExternalLocators metatraffic_external_unicast_locators;

//! Initial peers.
LocatorList_t initialPeersList;

//! Memory policy for builtin readers
MemoryManagementPolicy_t readerHistoryMemoryPolicy =
MemoryManagementPolicy_t::PREALLOCATED_WITH_REALLOC_MEMORY_MODE;

//! Maximum payload size for builtin readers
uint32_t readerPayloadSize = BUILTIN_DATA_MAX_SIZE;

//! Memory policy for builtin writers
MemoryManagementPolicy_t writerHistoryMemoryPolicy =
MemoryManagementPolicy_t::PREALLOCATED_WITH_REALLOC_MEMORY_MODE;

//! Maximum payload size for builtin writers
uint32_t writerPayloadSize = BUILTIN_DATA_MAX_SIZE;

//! Mutation tries if the port is being used.
uint32_t mutation_tries = 100u;

BuiltinAttributes对象在什么地方被初始化？

这些内置协议包括：

  1. 参与者发现协议（Participant Discovery Protocol）：该协议让参与者（即DDS应用）可以发现网络中的其他参与者。
  2. 发布者/订阅者发现协议（Publisher/Subscriber Discovery Protocol）：这允许参与者发现网络中其他参与者的发布者和订阅者。
  3. 读写器发现协议（Reader/Writer Discovery Protocol）：这使参与者可以发现网络中其他参与者的数据读写器。
  4. WLP保活协议（心跳，WriterLiveliness），主要由类WLP来实现

这些内置协议在Fast DDS中是自动启动并运行的，而BuiltinProtocols类就是用来管理和处理这些内置协议的。总的来说，BuiltinProtocols类的主要作用是管理和处理Fast DDS的内置协议，这些协议使得DDS应用可以在网络中发现和与其他应用交互。

发现机制

Simple Discovery

优点

  1. 简单易用，只要在同一网络中的节点启动Fast DDS应用，他就能自动发现彼此并建立连接
  2. 自动化，无需手动配置每个节点的网络地址，减轻了配置和维护的工作量
  3. 实时性，可以快速探测和连接节点，适合实时性要求高的系统

缺点

  1. 缺乏灵活性，不支持定制化的发现策略，可能不适合某些特殊需求
  2. 可扩展性问题：在大型复杂的系统中，需要所有节点之间进行广播，当节点数量非常多时可能会导致网络拥塞，所以缺乏可扩展性
  3. 安全性问题：Simple Discovery并未考虑到安全性问题，可能会导致节点攻击

适用场景

Static Discovery

Static Discovery使用SPDP（即上面的Simple Participant Discovery Protocol)作为PDP阶段，但跳过了SEDP，所有参与的节点在启动前必须已知。这些信息定义在XML文件中，即EDP阶段通过静态配置来代替SEDP协议。这在处理有限带宽和已知的DataWrites和DataReaders方面非常有用。如果所有的DataWriters和DataReaders，它们的Topics，data types都是事先已知的，EDP阶段可以用对端的静态配置替换。因此也只有在对端配置的部分才可以通信。

优点

  1. 安全。与Simple Discovery相比，Static Discovery可以更好的控制哪些节点可以连接到系统，从而提高系统的安全性
  2. 可扩展。不依赖于节点之间的广播，所以有较好的扩展性
  3. 灵活性。可以控制哪些节点应该连接在一起，使用更加灵活

缺点

  1. 需要手动配置每个节点的网络地址，增加了配置和维护的工作量；且如果拓扑结构发生变化，也需要手动修改
  2. 启动阶段，因为在系统启动阶段需要保证配置完成，否则可能导致启动失败或部分功能无法使用，导致启动较慢

适用场景

Discovery Server

这种发现机制使用中心化的策略，基于client-server模式。这种服务模式中，一个或多个DomainParticipants作为server，所有的其他节点作为client，向server注册信息，并从server获取其他节点的信息。
Discovery Server DomainParticipants可以是clients或者servers。分为四种模式：SERVER，CLIENT，BACKUP，SUPPER CLIENT。它们之间的区别主要是节点发现过程中的角色和职责上：

  1. SERVER：SERVER是Discovery Server模式中的中心节点，它负责管理和存储所有节点（包括CLIENT，BACKUP，SUPER CLIENT）的元数据信息。当一个CLIENT节点需要发现其他节点信息时，它会像SERVER请求所需的元数据信息。具体来说，一个SERVER会发布clients和servers的信息，同时一个server可能会连接到另一个serser上来接收它的clients信息。
  2. CLIENT：CLIENT是需要与其他节点进行交互的节点。在Discovery Server模式中，CLIENT节点会连接到一个或多个SERVER，将自己的元数据信息注册到SERVER，并从SERVER获取它需要的，其他节点的元数据信息，以便与其他节点建立连接和进行通信。Clients需要预先知道它要连接的Servers。
  3. BAKCUP：备份是一种特殊的SERVER，它会将发现的信息写入持久化的数据库，用于Server发生故障时提供备份和恢复服务。BACKUP节点会定期从SERVER同步所有节点的元数据信息。如果主SERVER发生故障，CLIENT节点可以从BACKUP节点获取所需要的元数据信息，以便于继续与其他节点通信。
  4. SUPER CLIENT：特殊的CLIENT，可以直接与SERVER进行通信，而不需要通过BACKUP节点。这使得SUPER CLIENT可以在SERVER发生故障时直接从BACKUP节点获取元数据信息，而不需要等待BACKUP节点的同步。这可以提供系统的响应速度和可靠性。

优点

  1. 可扩展：对于大型系统，在Simple Discovery中每个节点都要互相通信，节点数量很大的情况下会造成大量通信从而导致网络拥塞，而在Discovery Server中节点之间的通信减少，大大减少了网络流量和节点处理负载
  2. 效率：点对点发现模式中，节点发现过程的时间通常会随着节点数量的增加而增加，而在Discovery Server模式中，由于所有的元素据都在服务器上，因此节点发现过程的时间基本上上固定的，不会随着节点的增加而增加。
  3. 灵活：Discovery Server提供一种更灵活的方式来管理拓扑结构，例如，节点可以部署到不同的网络子网中，只要可以访问到服务器即可，服务器可以根据需要来控制哪些客户端

缺点

  1. 服务器单点故障：如果发生故障，会导致所有节点无法发现和通信。虽然可以通过备份服务器来提高系统的可靠性，但会增加系统的复杂性和成本。
  2. 依赖服务器：所有节点都依赖服务器进行发现和通信，如果性能不足或者网络连接不稳定，整个系统的性能和稳定性都会受到影响
  3. 配置复杂：相比点到点的发现，需要配置服务器地址，端口，以及节点的角色和权限等信息。

适用场景

适用于大型和复杂的分布式系统

Manual Discovery

这种机制只与RTPS层兼容。没有PDP阶段，因此也就没有EDP阶段，所有匹配只能通过RTPS层的addReaderLocator, addReaderProxy, addWriterProxy方法

发现阶段

服务发现的创建和发现都是在BuiltinProtocols类中处理。所有的服务发现都可以分为两个阶段：

  1. Participant Discovery Phase(PDP)：这个阶段DomainParticipant通过周期性的广播消息获取互相的存在。
  2. Endpoint Discovery Phase (EDP)：这个阶段DataReader和DataWriter进行发现和匹配，对于两个要匹配的端点而言，topic和data type必须要一致，部分Qos要兼容。一旦Puiblisher和Subscriber匹配上之后，就可以接收和发送用户数据了。

数据结构

ParticipantProxyData

服务发现的对端的信息都存储在ParticipantProxyData中。这个实例在发现过程中被创建，然后填充发现后的信息后，加入到PDP的参与者列表（ResourceLimitedVector<ParticipantProxyData*> participant_proxies_）中。当前participant的信息构造的ParticipantProxyData对象作为participant_proxies_的第一个成员。

其他较重要的数据类型：

BuiltinAttributes m_discovery;  // 主要用于服务发现配置数据
std::unique_ptr<fastdds::rtps::PDPEndpoints> builtin_endpoints_;
EDP* mp_EDP;   // PDP 中指定要使用的EDP对象
ResourceLimitedVector<ParticipantProxyData*> participant_proxies_;  // 注册的RTPSParticipants对象，第一个元素为本地创建的RTPSParticipants，PDP阶段发现的RTPSParticipants都会添加到这个数据中
ResourceLimitedVector<ParticipantProxyData*> participant_proxies_pool_;//!Pool of participant proxy data objects ready for reuse
size_t reader_proxies_number_;//!Number of reader proxy data objects created
 ResourceLimitedVector<ReaderProxyData*> reader_proxies_pool_;//!Pool of reader proxy data objects ready for reuse
size_t writer_proxies_number_;//!Number of writer proxy data objects created
ResourceLimitedVector<WriterProxyData*> writer_proxies_pool_;//!Pool of writer proxy data objects ready for reuse
 std::atomic_bool m_hasChangedLocalPDP;//!Variable to indicate if any parameter has changed.
ReaderListener* mp_listener;//!Listener for the SPDP messages.
ProxyPool<ReaderProxyData> temp_reader_proxies_;//! ProxyPool for temporary reader proxies
ProxyPool<WriterProxyData> temp_writer_proxies_;//! ProxyPool for temporary writer proxies

Simple发现开发视图

类图

在这里插入图片描述

对象创建时序图

在这里插入图片描述

创建PDP对象

服务发现对象的创建在构造DomainParticipant时开始，具体来说在构造RTPSParticipantImpl时通过创建BuiltinProtocols对象并初始化时开始。
在BuiltinProtocols::initBuiltinProtocols中构造一个PDPSimple对象，同时创建多个ParticipantProxyData，WriterProxyData和ReaderProxyData对象，其中，ParticipantProxyData用于存放PDP发现找到的participant的数据，WriterProxyData和ReaderProxyData用于存放EDP阶段需要发送给其他participant的writer和reader信息。

bool BuiltinProtocols::initBuiltinProtocols(
        RTPSParticipantImpl* p_part,
        BuiltinAttributes& attributes)
{
    mp_participantImpl = p_part;
    m_att = attributes;
    m_metatrafficUnicastLocatorList = m_att.metatrafficUnicastLocatorList;
    m_metatrafficMulticastLocatorList = m_att.metatrafficMulticastLocatorList;
    m_initialPeersList = m_att.initialPeersList;
    ...
    // PDP
    switch (m_att.discovery_config.discoveryProtocol)
    {
        case DiscoveryProtocol_t::NONE:
            EPROSIMA_LOG_WARNING(RTPS_PDP, "No participant discovery protocol specified");
            return true;

        case DiscoveryProtocol_t::SIMPLE:
            mp_PDP = new PDPSimple(this, allocation);
            break;
		...
}

PDP对象初始化

这部分在PDPSimple::init中实现，可以分为两部分，一部分是创建PDP的其他相关对象，在PDP::initPDP中实现，另一部分创建EDPSimple对象

bool PDPSimple::init(
        RTPSParticipantImpl* part)
{
    // 第一部分: 初始化PDP
    // The DATA(p) must be processed after EDP endpoint creation
    if (!PDP::initPDP(part))
    ...
    //第二部分：构造EDPSimple对象
    if (m_discovery.discovery_config.use_STATIC_EndpointDiscoveryProtocol)
    {
        mp_EDP = new EDPStatic(this, mp_RTPSParticipant);
        if (!mp_EDP->initEDP(m_discovery))
        ...
    }
    else if (m_discovery.discovery_config.use_SIMPLE_EndpointDiscoveryProtocol)
    {
        mp_EDP = new EDPSimple(this, mp_RTPSParticipant);
        if (!mp_EDP->initEDP(m_discovery))
        ...

initPDP

PDP相关对象如PDP endpoints，当前Participant的ParticipantProxyData等对象的创建，在PDP::initPDP中实现，具体又可以分为三部分：对象创建，METATRAFFIC更新，ParticipantProxyData的创建。

bool PDP::initPDP(
        RTPSParticipantImpl* part)
{
    mp_RTPSParticipant = part;
    m_discovery = mp_RTPSParticipant->getAttributes().builtin;
    initial_announcements_ = m_discovery.discovery_config.initial_announcements;
    //CREATE ENDPOINTS
    if (!createPDPEndpoints())
    {
        return false;
    }
    //UPDATE METATRAFFIC.
    update_builtin_locators();

    mp_mutex->lock();
    ParticipantProxyData* pdata = add_participant_proxy_data(mp_RTPSParticipant->getGuid(), false, nullptr);
    mp_mutex->unlock();

    if (pdata == nullptr)
    {
        return false;
    }
    initializeParticipantProxyData(pdata);

    return true;
}
  1. 对象创建，在PDPSimple::createPDPEndpoints中实现：
bool PDPSimple::createPDPEndpoints()
{
    fastdds::rtps::SimplePDPEndpoints* endpoints = nullptr;
    ...
    {
        endpoints = new fastdds::rtps::SimplePDPEndpoints();
        endpoints->reader.listener_.reset(new PDPListener(this));
    }
    builtin_endpoints_.reset(endpoints);

    bool ret_val = create_dcps_participant_endpoints();
    ...
}

这段代码又可以细分为三点：

  • 创建PDP Endpoints。具体为
    • 创建SimplePDPEndpoints对象，包含两个成员：BuiltinReader<fastrtps::rtps::StatelessReader>和BuiltinWriter<fastrtps::rtps::StatelessWriter>，用于收发SPDP的数据
    • 创建PDPListener对象，交给BuiltinWriter<fastrtps::rtps::StatelessWriter>用于监听其他Participant的PDP报文，PDPListener监听到数据后交给BuiltinWriter<fastrtps::rtps::StatelessWriter>处理
    • 在PDPSimple::create_dcps_participant_endpoints中创建PDP的StatelessReader和StatelessWriter，和其对应的ReaderHistory和WriterHistory，reader_entity_id/writer_entity_id，topic name(“DCPSParticipant”)，申请payload内存，设置相关Qos，PDP发送地址(默认239.255.0.1:7400)等。
  1. 更新meta traffic, locator为本地IP:7412
void PDPSimple::update_builtin_locators()
{
    auto endpoints = static_cast<fastdds::rtps::SimplePDPEndpoints*>(builtin_endpoints_.get());
    mp_builtin->updateMetatrafficLocators(endpoints->reader.reader_->getAttributes().unicastLocatorList);
}
  1. 创建一个当前Participant的ParticipantProxyData对象并添加到participant_proxies_中，这个ParticipantProxyData是保存当前participant的信息发送给其他participant。

创建EDP对象

《TODO：EDP对象创建时序图》

EDP对象的创建也是在PDPSimple::init中实现，完成上述PDP::initPDP后开始创建EDP对象。

EDP初始化

EDP初始化的代码在EDPSimple::initEDP中完成，EDPSimple::initEDP中主要操作为调用EDPSimple::createSEDPEndpoints创建SEDP Endpoints。

bool EDPSimple::createSEDPEndpoints()
{
    ...
    publications_listener_ = new EDPSimplePUBListener(this);  // pub listener
    subscriptions_listener_ = new EDPSimpleSUBListener(this);  // sub listener

    if (m_discovery.discovery_config.m_simpleEDP.use_PublicationWriterANDSubscriptionReader)
    {
        if (!EDPUtils::create_edp_writer(mp_RTPSParticipant, "DCPSPublications", c_EntityId_SEDPPubWriter,
                writer_history_att, watt, publications_listener_, pub_writer_payload_pool_, publications_writer_))
    
        if (!EDPUtils::create_edp_reader(mp_RTPSParticipant, "DCPSSubscriptions", c_EntityId_SEDPSubReader,
                reader_history_att, ratt, subscriptions_listener_, sub_reader_payload_pool_, subscriptions_reader_))
    }

    if (m_discovery.discovery_config.m_simpleEDP.use_PublicationReaderANDSubscriptionWriter)
    {
        if (!EDPUtils::create_edp_reader(mp_RTPSParticipant, "DCPSPublications", c_EntityId_SEDPPubReader,
                reader_history_att, ratt, publications_listener_, pub_reader_payload_pool_, publications_reader_))
                
        if (!EDPUtils::create_edp_writer(mp_RTPSParticipant, "DCPSSubscriptions", c_EntityId_SEDPSubWriter,
                writer_history_att, watt, subscriptions_listener_, sub_writer_payload_pool_, subscriptions_writer_))
    }
}

这段代码主要创建了两对EDP的writer/reader，以及对应的listener和WriterHistory/ReaderHistory

  1. 第一对，PublicationWriter和SubscriptionReader

  • PublicationWriter: topic name为DCPSPublications，listener为EDPSimplePUBListener，entity ID为c_EntityId_SEDPPubWriter。这个RTPSWriter用于在创建了DataWriter之后发送这个DataWriter的EDP的报文
    在发送EDP报文时，会指定EDP endpoint为publications_writer_，这段代码的实现在EDPSimple::processLocalWriterProxyData中。同时，接受端的reader entity ID为c_EntityId_SEDPPubReader（这一步在收到PDP消息后更新EDP对象时指定，具体参考这篇博客）。

  • SubscriptionReader：topic name为DCPSSubscriptions，listener为EDPSimpleSUBListener，entity ID为c_EntityId_SEDPSubReader。用于接收对端是DataReader时发送的EDP报文

  1. 第二对，PublicationReader和SubscriptionWriter
  • PublicationReader：topic name为DCPSPublications，listener为EDPSimplePUBListener，entity ID为c_EntityId_SEDPPubReader。用于接收对端是DataWriter时发送的EDP报文。
  • SubscriptionWriter：topic name为DCPSSubscriptions，listener为EDPSimpleSUBListener，entity ID为c_EntityId_SEDPSubWriter。这个RTPSWriter用于在创建了DataReader之后发送这个DataReader的EDP报文。
FastDDS（8）Discovery自动发现
pony12的专栏
12-25 1807
Fast DDS作为一种数据分发服务（DDS）实现，提供了发现机制，允许跨域参与者自动查找和匹配DataWriter和DataReader，以便他们可以开始共享数据。对于所有机制，此发现分两个阶段执行。Participant Discovery Phase参与者发现阶段（PDP）和Endpoint Discovery Phase端点发现阶段（EDP）。 四种发现机制，Simple Discovery简单发现、Static Discovery静态发现、Discovery Server发现服务器、Manual
Fast-DDS 服务发现简要概述
KingOfMyHeart的博客
09-12 2099
阅读本文章需要对DDS基础概念有一些了解，一些内容来自Fast-DDS官方文档，一些是工作中踩过的坑。
服务发现详解
最新发布
qq_33089547的博客
03-07 528
在（一种高性能的DDS middleware）中，和是两种不同的服务发现机制，用于节点之间的发现和通信。它们的主要区别在于节点之间如何发现彼此以及如何建立通信关系。
DDS协议--[第六章][Discovery]
qq_41816308的博客
07-22 967
对于要匹配的两个端点，它们的主题和数据类型必须一致。如果要使用不支持多播的计算机（或者由于某些其他原因需要使用单播），或者如果要在没有网络连接的单台计算机上运行（在这种情况下，您的操作系统可能具有禁用您的网络堆栈），有一种简单的方法来控制发现过程 - 您甚至不必重新编译。当使用部分可靠通信的情况下（配置keep_last_N），DataWriter的发送队列会进行数据的覆盖，当队列中的历史数据将要被覆盖，而DataReader还未对此消息进行确认时，DataWriter也会发送GAP消息。
【FastDDS源码剖析】PDP/PDPListener/PDPSimple
桃花朵朵的博客
05-25 338
我们用三篇文章来介绍FastDDS的Simple Discovery机制。发现分为两个阶段，一是Participant Discovery Phase (PDP)，同一个DomainID下的DomainParticipants 相互发现，二是Endpoint Discovery Phase (EDP)，DomainParticipants之间交换DataWriters 和 DataReaders的信息，从而使DataWriters 和 DataReaders相互匹配。
ros2通信核心之DDS简介
elais_h的博客
03-01 1241
DDS（Data Distribution Service，数据分发服务）是一种用于实时系统的通信中间件，它为分布式应用程序提供可靠、高效的数据传输。ROS 2 使用 DDS 作为其底层通信机制，因此理解 DDS 的基本概念对于 ROS 2 编程至关重要。
【ROS2】高级:使用 Fast DDS 发现服务器作为发现协议 [社区贡献]
cxyhjl的博客
07-15 2779
目标：本教程将展示如何使用 Fast DDS Discovery Server 发现协议启动 ROS 2 节点。教程级别：高级时间：20 分钟目录背景快速 DDS 发现服务器 v2先决条件运行此教程设置发现服务器启动监听节点启动对话节点展示发现服务器执行可视化工具rqt_graph高级用例服务器冗余备份服务器发现分区ROS 2 内省守护进程的相关工具没有虚拟光...
fastdds服务发现
setary0301的博客
04-16 1561
域名参与者互相发现，每个DomainParticipant定期发送公告消息，指定DomainParticipator正在侦听传入元数据和用户数据流量的单播地址（IP和端口），当两个给定的DomainParticipants存在于同一DDS域中时，它们将匹配。
Fast DDS入门八、Fast DDS的发现机制
咸鱼爱幻想的博客
03-08 4879
SIMPLE发现协议是默认发现协议，它解决了在各种DDS实体之间建立端到端连接的问题。Fast DDS实现了SIMPLE发现协议，以提供与RTPS标准的兼容性。该规范将SIMPLE发现协议分成两个独立的协议：简单参与者发现协议（SPDP）：指定域参与者如何在网络中发现彼此；它宣布并检测同一域中DomainParticipant的存在。简单端点发现协议（SEDP）：定义所发现的域参与者为交换信息而采用的协议，以便发现每个域参与者中包含的DDS实体，即DataWriter和DataReader。
ROS2学习笔记26--使用快速DDS查找服务作为查找协议（社区贡献）
qq_45701501的博客
08-01 1739
概要：这篇内容主要介绍使用快速DDS查找服务作为查找协议（社区贡献） 环境：ubuntu20.04,ros2-foxy,vscode 最后如果没有陈述实操过程中碰到问题的话，则表示该章节都可被本人正常复现 4.2使用快速DDS查找服务作为查找协议（社区贡献）（原文：https://docs.ros.org/en/foxy/Tutorials/Discovery-Server/Discovery-Server.html） >>教程>>使用快速DDS查找服务作为查找协议（社区贡献） 你正
CycloneDDS（5）发现Discovery
pony12的专栏
12-31 2047
CycloneDDS的发现机制，包括Topic Discovery和Type Discovery
快速DDS：最完善的DDS-已证明：大量成功案例
01-30
eProsima快速DDS eprosima Fast DDS （以前称为Fast RTPS）是OMG（对象管理组）的DDS（数据分发服务）标准的C ++实现。 eProsima Fast DDS实现了RTPS（实时发布订阅）协议，该协议通过对象管理组（OMG）联盟定义和维护的不可靠传输（例如UDP）提供发布者与订阅者的通信。 RTPS还是为数据分发服务（DDS）标准定义的有线互操作性协议。 eProsima Fast DDS公开了一个API，可以直接访问RTPS协议，从而使用户可以完全访问协议内部。 该库的一些主要功能是： 用于实时应用程序的可配置的最大努力和可靠的发布-订阅通信策略。 即插即用的连接性，以便网络的任何其他成员自动发现任何新的应用程序。 模块化和可扩展性允许网络中复杂而简单的设备不断增长。 可配置的网络行为和可互换的传输层：为每个部署选择最佳协议和系统输入/输出通道组合。 两个API层：一个高级的发布者-订阅者层（专注于可用性（DDS））和一个较低的Writer-Reader层，该层提供对RTPS协议内部工作的更好访问。 eProsima Fas
【FastDDS源码剖析】EDP/EDPListener/EDPSimple
桃花朵朵的博客
06-10 321
前一篇文章介绍了PDP(Participant Discovery Phase )，Participant发现之后需要EDP。EDP的代码看起来比较绕，我们分一下几个方面介绍EDP。一是要做什么，二是为了达到这个目的需要发送什么，三是具体如何实现的。
服务发现全流程解析-APOLLO7.0
lobmo的博客
06-11 1450
本文主要用于讲述apollo框架中cyber通信服务发现的过程，详细代码走读解析。
FastDDS的服务器记录-译-
zhangrelay的专栏
06-26 1149
discourse.ros.org/t/fastdds-without-discovery-server/26117/9有疑问如下：我一直在以多种方式与 FastDDS（在 ROS2 Humble 上）作斗争——但最大的问题是发现。对于我的机器人，我有一个用于驱动程序的启动文件，第二个用于定位，第三个用于导航——它们都在机器人计算机上运行。如果我按顺序启动它们，一切正常 - 但然后说我必须重新启动导航才能更改配置 - 大约 75% 的时间，它无法连接某些主题（尤其是 tf 似乎是一个问题），然后我必须重新启
OpenDDS通讯中rtps_discovery对等发现的基本配置和说明
pony12的专栏
04-18 3097
有对DDS技术了解、学习、开发和培训需求的，请加入QQ群：707895641（DDS专业技术辅导）。 *************************************************************************************************** OpenDDS的对等发现模式中，可以采用组播或单播方式进行发现和基于主题的Dat...
Fast DDS（1）
pony12的专栏
12-13 795
eProsima Fast DDS是DDS（数据分发服务）规范的C++实现，DDS是由对象管理组（OMG）定义的协议。eProsima Fast DDS库提供应用程序编程接口（API）和通信协议，用于部署以数据为中心的发布者-用户（DCPS）模型，目的是在实时系统之间建立高效可靠的信息分发。eProsima Fast DDS在资源处理方面具有可预测性、可扩展性、灵活性和高效性。https://fast-dds.docs.eprosima.com/en/latest/
Fast DDS 介绍
Captain--Jack
04-12 2319
前面已经简要介绍过DDS协议规范了，接下来我们来看一个它的C++实现----Fast DDS。eProsima Fast-DDS是eprosima对于DDS的C++实现，这是一个免费开源软件，遵循Apache License 2.0。eProsima Fast DDS在性能，功能和对最新版本RTPS标准（RTPS 2.2）的遵守方面均处于领先地位。它最为被大家知道的可能是因为被ROS2设定为默认的消息中间件。Fast DDS由以下几部分组成：1.DDS API接口实现；
机器人开发--Fast DDS
天道酬勤
06-20 2829
数据分发服务DDS，Fast DDS是实现该协议厂商之一。
fast dds使用示例
06-05
Fast DDS 是一个用于实时通信的开源框架，能够支持高效的可靠传输和低延迟的通信，被广泛应用于工业控制、机器人、通信等领域。以下是 Fast DDS 使用示例： 1. 工业自动化控制：Fast DDS 可以用于生产线上的机器人协作，通过实时传输控制信号、传感器数据等信息，实现多机器人的协作操作。 2. 智能交通领域：Fast DDS 可以用于交通信号灯的智能化控制，通过实时传输交通流量、车辆位置等信息，使交通信号灯的控制更加智能化。 3. 医疗领域：Fast DDS 可以应用于医院的远程诊疗系统，通过实时传输病人的医疗数据、医生的指导等信息，使医疗服务更加高效。 4. 物联网领域：Fast DDS 可以用于智能家居场景中，通过实时传输温度、湿度等信息，实现家电的智能化控制，提高生活质量。 综上所述，Fast DDS 可以应用于许多领域，通过实时传输数据，实现多方协同操作，提高效率和精度。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值