搞过ROS 2、而且系统一复杂就开始排查通信问题的人基本都会碰上一个需要把协议栈往下翻两层的时刻。明明每个节点都起来了ros2 topic list却只显示一半或者新节点启动半天其他模块才慢吞吞发现它再要么一抓包UDP 7400端口上来来往往的组播流量非常热闹却说不清谁在发、谁在收。ROS 2默认的中间件是Fast DDSDDS/RTPS里的“分布式发现”机制决定了这一切。这篇文章就从Fast DDS的视角把PDP、EDP这两个发现协议以及它们背后真正的接收线程、事件线程讲清楚。适合两类人一类是想把“对方怎么找到我”弄明白的ROS 2开发者另一类是已经被发现故障折磨到想放弃、准备按图索骥排查的工程师。1. 先弄清楚PDP和EDP在DDS里的位置1.1 从一次完整的话题通信说起在接触DDS之前我们很容易被ROS 1时代养出来的惯性思维带偏以为发布方和订阅方之间有一个“主节点”或者“名字服务”话题关系是由调度中心撮合的。ROS 1确实有master节点但ROS 2默认架构完全不同——它没有中心节点底层走的是DDSDDS的分布式发现是完全去中心化的。一个发布方和一个订阅方最终能对上话靠的是RTPS协议栈里那套看不见的握手流程。一套完整流程是这样。节点启动时Fast DDS会创建一个RTPS Participant实例这个实例携带一定数量的内置端点builtin endpoints。阶段一叫PDP也就是Participant Discovery Protocol参与者发现协议。它负责把“我这台机器上有一个参与者我长这样”的信息广播出去同时收集网络里其他参与者发来的同类信息。阶段二叫EDPEndpoint Discovery Protocol端点发现协议。它解决的是另一个问题既然我已经知道对面有一个参与者了那它内部有哪些Publisher、哪些Subscriber它们分别挂在哪个话题下QoS策略是什么只有等EDP把这一层也交换完实际数据才能在发布方和订阅方之间流动。很多排查陷阱就藏在两阶段之间的衔接处。PDP做完了只能说明“我看到你了”并不代表话题能通。话题能不能通取决于EDP阶段有没有匹配成功。我见过不少项目组在容器环境里排查数据不通折腾半天发现是组播没开PDP阶段就失败了压根没轮到EDP说话。1.2 PDP和EDP的分工差异用生活化的例子帮记忆。PDP像电梯里的住户表张三搬进来在楼道里喊一声“我住301叫张三这是我的样子”大家各自在脑子里记一笔李四也一样。EDP像是加微信之后交换名片你知道了对面住着一位叫张三的邻居但还不知道张三平时干什么、能帮你什么忙于是双方交换更细的信息“我这边有一路摄像机图像话题”“我这边在订阅摄像机图像”。PDP管的是参与者级别的可见性EDP管的是端点级别的匹配性。这个分工直接决定了协议行为差异。PDP的流量是周期性的、尽力发送的因为参与者在线状态需要持续维持隔几秒就得重新宣告一次EDP的流量是事件驱动的、可靠投递的因为端点信息只会在节点启动、话题创建、QoS变化这些时刻主动产生。理解了这点再看后面的线程模型会顺很多前者天然需要周期事件线程兜底后者则更依赖收包线程上的可靠回调。2. PDP怎么发现“参与者”SPDP组播宣告、租约与内置端点2.1 默认实现SPDP消息里到底装了什么Fast DDS的PDP默认实现是SPDP全称Simple Participant Discovery Protocol简单参与者发现协议。它不是一个抽象理论而是有明确定义报文格式和生产级实现的RTPS机制。在这个协议下每个Participant内部固定维护一组用来交换PDP信息的内置端点在DDS主题层面对应内建主题DCPSParticipant在RTPS传输层则使用预先约定的组播地址和端口进行通告。默认情况下domain ID为0时组播地址是239.255.0.1:7400。domain ID每增加1端口号偏移250所以domain 1对应端口7650domain 2对应7900。这个设计保证了不同domain的网络流量天然隔离避免两个团队在同一个局域网里跑各自的系统时相互干扰。实际抓包时这个端口是最重要的过滤条件。SPDP报文里携带的关键信息包括Participant的GUID全局唯一标识由GUID Prefix和Entity ID组成、RTPS协议版本、所属domain ID、租约时长leaseDuration以及一组单播/组播Locator地址。对端收到后会在本地维护一份ParticipantProxy记录里面保存着这个“邻居”的网络可达地址和身份信息之后EDP的所有通信就需要用到这些地址。2.2 宣告周期与租约两个容易被误调的参数Fast DDS里两个最核心的PDP参数默认值非常朴素discoveryPeriod宣告周期默认1秒leaseDuration租约默认3秒。也就是说正常情况下每个Participant每秒钟会向组播地址广播一次自己的存在对端如果连续3秒没有再收到某个Participant的SPDP就会认为它离开了或网络断了主动把本地对应的ParticipantProxy记录清理掉。这两个参数之间的关系是排查“节点明明活着但别人就是看不到它”这类问题的核心。很多优化心切的开发者会把宣告周期往小调比如一百毫秒以期加快发现速度。但若只调周期、不调租约就会出现一个诡异现象两个节点在同一网段里进程都好好的却偶尔互相“失明”。原因是网络稍有抖动3秒内没收到组播对端就把本地记录清了于是触发一次重新发现。我的建议是除非有明确需求否则不要动默认值如果确实要调leaseDuration至少应该是discoveryPeriod的5倍以上否则就是自己给自己挖坑。配置项在Fast DDS的participant attributes里通常通过XML profiles暴露。一个简化示意如下participant rtps builtin discovery_config discoveryProtocolSIMPLE/discoveryProtocol leaseDurationPT3S/leaseDuration leaseAnnouncement period sec1/sec /period /leaseAnnouncement /discovery_config /builtin /rtps /participant代码里也可以通过RTPSParticipantAttributes::builtin.discovery_config.discoveryPeriod和leaseDuration直接改。但注意跨语言的客户端类型、ROS 2的QoS设置都可能覆盖或绕过部分XML配置改了还得验证真的生效。2.3 租约过期引发的“假离线”和“假在线”租约机制本身是可靠的但人类对它的理解经常出错。默认3秒租约的意思是对端把你的ParticipantProxy保留3秒这3秒内只要收到任何一包SPDP就自动续约。所以一个稳定运行的节点它的邻居侧记录几乎不会超时。反过来如果一个节点异常退出因为SPDP不再继续广播其他节点最多3秒后就会把它从参与者的列表里清掉。在ROS 2层面做一次直观验证打开两个终端分别运行两个节点然后直接关掉其中一个进程另一个机器上执行ros2 node list你会看到消失的滞后时间略小于租约时长。如果这个滞后时间过长就得去复查是不是把leaseDuration调得太大了。另一个反面情况是如果你把组播禁掉了PDP宣告完全发不出去则会出现“自己能看到自己但永远看不到别人”的诡异状态因为Fast DDS默认还保留了环回接口的发现能力。3. PDP之后紧跟着EDP端点信息如何从“谁能收发”变成匹配结果3.1 SEDP的两个内置主题绕不开的四类端点当两个Participant通过PDP互相确认存在之后EDP开始工作。Fast DDS的EDP默认实现是SEDPSimple Endpoint Discovery Protocol简单端点发现协议。与PDP的尽力而为不同SEDP基于可靠通信因为它承载的信息量大、错过一次就要重传绝不可能靠“下次周期再广播”来兜底。具体到实现上每个Participant要维护两组内置主题DCPSPublication和DCPSSubscription。每个主题各有一个Writer和一个Reader所以一共是四个内置端点。发Publisher信息由Publication Writer完成订阅方侧的Publication Reader接收发Subscriber信息则由Subscription Writer完成由发布方侧的Subscription Reader接收。看到这些名字不用害怕它们本质就是一些经过特殊标记的RTPS端点伪装成普通话题走同样的收包分发通道。3.2 一个Publisher和Subscriber的完整“对上眼”过程把完整流程放慢看。假设Participant A上创建了一个Subscriber订阅话题/chatterParticipant B上创建了一个Publisher发布话题/chatter。在PDP完成后A和B已经知道彼此地址。接下来A的Subscription Writer会把一条描述Subscriber的SubscriptionData发给BB的Publication Writer也会把一条描述Publisher的PublicationData发给A。两边各自在对方的Publication Reader和Subscription Reader上收到数据。收到数据后Fast DDS要做的是匹配检查。匹配条件比大多数人想象得严格不只是话题名相同type name也必须一致QoS策略还要互相兼容。如果这三个条件都满足双方就会在各自的端点上相互建立写作/阅读关联于是数据通道正式打通。这个匹配过程对两端是对称的某一边漏收了一条EDP消息就会出现“我从A能看到B的话题但B看不到A的”这种单向可见问题。3.3 QoS不匹配是EDP层最常见的分手原因EDP匹配失败时表面症状和PDP失败完全不同。PDP失败时ros2 node list里根本看不到对方节点EDP失败时节点列表正常但话题列表要么缺失、要么有话题名但数据永远是空的。我排查过一个很典型的场景两台机器通过自研的可视化程序连接程序里自定义了History和Reliability策略订阅方用了Volatile的Durability发布方却要求TransientLocal。两边的topic name完全一致type也一致但QoS就是不兼容。ROS 2控制台刷了一堆INCOMPATIBLE_QOS日志话题出现却始终没有数据。这类问题不是网络问题也不是线程问题就是EDP层的QoS匹配规则卡住了。遇到这种症状第一反应应该是列出两端的QoS对象逐个字段比对而不是去抓包看流量。4. 谁在处理这些发现流量接收线程和事件线程的真实分工4.1 先破除一个误解PDP和EDP没有专属常驻线程很多刚接触Fast DDS源码的人容易默认“PDP一个线程EDP一个线程数据通信又一个线程”。真实实现不是这样。Fast DDS里PDP和EDP的逻辑处理都寄生在几个通用机制上收包IO线程、事件调度线程以及内建端点上的回调。它们是协议不是一堆独立调度的线程。理解这一点特别重要因为它直接影响你看性能瓶颈的方向。收包IO线程负责从UDP或TCP socket上读取到来的RTPS报文。默认配置下一个Participant会按需创建若干个这类线程数量和启用的传输通道有关常见的单播、组播通道各自会有一个接收线程在跑。事件调度线程则是Fast DDS内部用于管理周期任务和超时任务的公共设施SPDP的周期性公告、leaseDuration超时清理这类工作都由它驱动。换句话说网络流量由IO线程吃进去周期维护由事件线程负责PDP和EDP的回调则分别挂在各自的Reader上最终在IO线程的上下文里被调用。4.2 一个UDP包从网卡到PDP/EDP回调的完整链路这条链路值得展开讲。假设某个Participant收到一条SPDP消息顺序是这样的。首先UDP传输层接收线程阻塞在socket上拿到一个数据报交给MessageReceiver::processCDRMsg做RTPS子消息解析。接着解析器根据子消息里的实体ID找到对应Endpoint也就是PDP Reader。然后调用该Reader的回调onNewCacheChangeAdded在这个回调里完成GUID比对、ParticipantProxy创建或更新、租约续期等动作。如果这条消息触发了一个新Participant加入回调还会在此基础上发起进一步的SEDP书籍交换于是又有新的EDP消息进入发送队列。这条链路的精髓在于PDP和EDP的处理不是单独的线程在跑而是实实在在发生在接收IO线程的调用栈里。用gdb或perf抓一个高负载进程的栈排在前面的函数往往就是MessageReceiver::processCDRMsg和它下面挂着的Reader回调。这意味着一次发现包的解析时间如果过长后到的其他RTPS包只能排队等着反过来如果发现包流量极大最先被打爆的就是这几个接收线程。4.3 周期宣告为什么必须由事件线程做SPDP每隔一秒自动发送的动作并不能靠接收线程“收到请求再回复”因为组播环境下没有统一的请求源。它就是单纯按时间节拍往组播地址上喊话。Fast DDS把这些周期动作挂到Participant的事件调度器上由事件线程按时间唤醒、执行发送动作。还有租约过期清理本质上也依赖事件线程的定时检查。这个分工带来的实际影响是当你用top或perf观察发现某个进程CPU异常时先分清CPU时间到底是花在接收线程的processCDRMsg上还是花在事件调度上。前者说明流量压力大比如节点多、发现风暴、或有人恶意组播后者说明周期任务太频繁往往和把discoveryPeriod调得过小有关。方向判断错了后面所有调优都会白费。5. 实际调试发现问题的三个层次从抓包到线程视角5.1 第一层先抓包确认SPDP和EDP流量存在排查发现故障我习惯先不碰代码先抓包。domain 0的默认场景下一条tcpdump命令就能验证SPDP是否在发tcpdump -i eth0 udp port 7400 -nn正常启动一个节点你会看到源地址为组播地址或本机地址的周期UDP包。如果看不到任何SPDP包问题大概率出在网络层而不是Fast DDS配置。最常见的三个原因组播被交换机或防火墙挡了节点跑在容器里而容器网络没开启多播两个节点不在同一VLAN。组播是一个很容易被忽略的先决条件尤其在云主机和K8s环境里默认是不支持组播的SPDP首先就发不出去后面一切免谈。如果SPDP正常但话题始终没数据继续抓EDP流量就得靠优化过滤规则。EDP走的是可靠传输端口通常落在单播端口范围不像SPDP有固定的7400这么友好。一个更实用的验证办法是直接用ROS 2层的工具判断ros2 node list能看到对方说明PDP完成了ros2 topic list有话题但ros2 topic echo没有数据说明EDP匹配出了问题。5.2 第二层PDP“看见了”但EDP匹配不上的经典场景假设你已经确认节点列表里能看到对方话题列表却很安静这时候的排查重点我前面已经提过topic name、type name、QoS三者逐一核对。还有一种很容易被忽略的情况就是参与者的domain ID不一致。如果两个节点分别跑在domain 0和domain 1它们不会互相发现对方但各自的node list里可能都看不到对方这个问题会在PDP层先暴露出来属于第一层就能查出。EDP层最常见的坑反而是“话题出现为空”。比如两个节点都加载了同一个接口定义文件但source code里的package版本不一致生成的type identifier不完全一样Fast DDS在type匹配时给出的结果可能是不匹配。从用户视角看明明消息结构一模一样为什么互相不认识这就是因为RTPS层的type匹配非常严格。遇到这种情况先让两端把topic type打印出来对比别急着怀疑中间件。5.3 第三层线程视角下的发现风暴和CPU尖峰到了最底层就是线程。多机多节点场景下我见过很多“启动瞬间CPU飙满、几十秒后才回落”的报告本质就是发现风暴。N个Participant在PDP阶段互相广播、在EDP阶段互相交换端点信息整体通信量接近N平方量级。在一个有20个节点的系统里一多半节点同时重启瞬间EDP可靠消息挤满收包线程CPU自然就上去了。用perf top或者直接开一个gdb attach之后看线程栈基本都能看到收包线程密集执行MessageReceiver::processCDRMsg。这种情况下修改单个参数意义不大真正的优化手段是下面要讲的Discovery Server模式或者拆分domain、控制同一个domain下的Participant数量。从线程角度看发现问题不是“某个线程坏了”而是“所有发现处理都堆在那几个收包线程上”。所以调优的思路永远是减少流量、分散负载而不是增加线程数。6. 大系统下的发现优化从周期参数到Discovery Server6.1 discoveryPeriod和leaseDuration的取舍逻辑这两个参数在小型实验里几乎感觉不到差别但在大系统里它们决定了发现速度与网络压力的平衡。用一个简单关系来说明discoveryPeriod越短新节点加入后被其他人发现的时间就越短但单位时间内的组播包数量也线性增长leaseDuration越长临时掉线节点在邻居列表里残留的时间就越长容易出现“明明进程挂了列表里还能看到它”的尴尬。我个人的经验是如果节点少于10个默认参数就是最优解不用动。如果节点多且启动频繁可以把discoveryPeriod压到500ms左右同时把leaseDuration设为2秒或3秒保证租约仍然远大于周期。反过来如果网络带宽紧张把周期拉到2秒甚至3秒leaseDuration至少要在5到6秒以上。调参数时不能只改一个必须成对改这个我在前面已经踩过坑。6.2 组播不可用的环境单播模式的价值与代价Fast DDS允许把PDP调整为只使用单播它不再依赖组播地址而是通过已知的单播locator列表互相发现。这种方式在某些云网络里很实用因为云厂商的VPC通常不转发组播。但代价是配置量变大你必须把所有Participant的单播地址和端口都写清楚而且每增加一个节点都要更新配置。除非环境强制要求否则一般不建议自己写死单播列表太脆弱。相对更优雅的方案是后面这招Discovery Server。它可以被理解成一个“会合点”把发现流量从组播泛洪改成单播注册特别适合跨网段、跨VLAN、或者组播已被禁用的容器环境。它改动的是PDP协议的模式而不是把组播简单换成单播列表。6.3 Discovery Server把PDP从广播社交变成单播会合Fast DDS的Discovery Server模式在ROS 2里通过环境变量或XML配置即可使用。每个Participant扮演两种角色声明为CLIENT的节点不再发组播SPDP而是定期向已知的SERVER地址注册并请求其他Client的信息声明为SERVER的节点维护一个参与者目录单独为每个Client转发目录变化。这样本来要发到整个局域网的组播PDP流量变成了每个Client和Server之间的一对一单播流量发现收敛时间也不随节点数平方爆炸。设置方式在ros 2中非常直观export ROS_DISCOVERY_SERVER192.168.1.100:11811XML配置则是在participant的discovery_config里把discoveryProtocol改成CLIENT或SERVER再填上discoveryServersList。需要特别提醒Discovery Server运行后Client之间虽然不需要组播也能互相发现但EDP的端点信息交换仍然会发生在两端之间所以网络层仍然要保证它们能单播互通。另外SERVER是单点生产环境最好再考虑备用SERVER的同步否则SERVER挂掉新的Client就进不了这个分布式系统。6.4 优化之前先想清楚瓶颈在哪优化工具永远只是工具真正重要的还是定位瓶颈。如果问题出现在“新节点加入后别人发现它太慢”优先调短discoveryPeriod如果问题出现在“局域网的CPU尖峰和组播风暴”优先上Discovery Server或拆domain如果问题出现在“掉线节点残留在列表里太久”优先调短leaseDuration。把故障现象和协议阶段对应上就不会像无头苍蝇一样乱试参数。每改一次配置都要重新验证PDP和EDP两个层次的表现最简单的方法仍然是ros2 node list配合ros2 topic echo。结尾最后分享一个我自己的排查习惯。遇到任何“发现类”问题我第一反应不是去改参数而是先抓包确认SPDP到底在不在发、EDP到底有没有交换先判断是卡在PDP还是EDP这一层。绝大多数情况下默认参数是够用的真正害我的反而是一次手滑把discoveryPeriod调到了100毫秒结果局域网里瞬间全是RTPS广播所有节点的CPU都被顶了上去节点之间反而因为发现风暴丢失了消息。那一次教训让我彻底明白Fast DDS的发现机制本质上就是收包线程加事件线程的协同产物调任何参数之前想清楚它会让哪个线程多干活、会让哪段链路变快或变慢比什么都重要。 
长河君 · 2026/10/15 8:41:56 · 阅读 1.2k ROS 2 Fast DDS分布式发现：PDP/EDP协议与线程模型详解
搞过ROS 2、而且系统一复杂就开始排查通信问题的人基本都会碰上一个需要把协议栈往下翻两层的时刻。明明每个节点都起来了ros2 topic list却只显示一半或者新节点启动半天其他模块才慢吞吞发现它再要么一抓包UDP 7400端口上来来往往的组播流量非常热闹却说不清谁在发、谁在收。ROS 2默认的中间件是Fast DDSDDS/RTPS里的“分布式发现”机制决定了这一切。这篇文章就从Fast DDS的视角把PDP、EDP这两个发现协议以及它们背后真正的接收线程、事件线程讲清楚。适合两类人一类是想把“对方怎么找到我”弄明白的ROS 2开发者另一类是已经被发现故障折磨到想放弃、准备按图索骥排查的工程师。1. 先弄清楚PDP和EDP在DDS里的位置1.1 从一次完整的话题通信说起在接触DDS之前我们很容易被ROS 1时代养出来的惯性思维带偏以为发布方和订阅方之间有一个“主节点”或者“名字服务”话题关系是由调度中心撮合的。ROS 1确实有master节点但ROS 2默认架构完全不同——它没有中心节点底层走的是DDSDDS的分布式发现是完全去中心化的。一个发布方和一个订阅方最终能对上话靠的是RTPS协议栈里那套看不见的握手流程。一套完整流程是这样。节点启动时Fast DDS会创建一个RTPS Participant实例这个实例携带一定数量的内置端点builtin endpoints。阶段一叫PDP也就是Participant Discovery Protocol参与者发现协议。它负责把“我这台机器上有一个参与者我长这样”的信息广播出去同时收集网络里其他参与者发来的同类信息。阶段二叫EDPEndpoint Discovery Protocol端点发现协议。它解决的是另一个问题既然我已经知道对面有一个参与者了那它内部有哪些Publisher、哪些Subscriber它们分别挂在哪个话题下QoS策略是什么只有等EDP把这一层也交换完实际数据才能在发布方和订阅方之间流动。很多排查陷阱就藏在两阶段之间的衔接处。PDP做完了只能说明“我看到你了”并不代表话题能通。话题能不能通取决于EDP阶段有没有匹配成功。我见过不少项目组在容器环境里排查数据不通折腾半天发现是组播没开PDP阶段就失败了压根没轮到EDP说话。1.2 PDP和EDP的分工差异用生活化的例子帮记忆。PDP像电梯里的住户表张三搬进来在楼道里喊一声“我住301叫张三这是我的样子”大家各自在脑子里记一笔李四也一样。EDP像是加微信之后交换名片你知道了对面住着一位叫张三的邻居但还不知道张三平时干什么、能帮你什么忙于是双方交换更细的信息“我这边有一路摄像机图像话题”“我这边在订阅摄像机图像”。PDP管的是参与者级别的可见性EDP管的是端点级别的匹配性。这个分工直接决定了协议行为差异。PDP的流量是周期性的、尽力发送的因为参与者在线状态需要持续维持隔几秒就得重新宣告一次EDP的流量是事件驱动的、可靠投递的因为端点信息只会在节点启动、话题创建、QoS变化这些时刻主动产生。理解了这点再看后面的线程模型会顺很多前者天然需要周期事件线程兜底后者则更依赖收包线程上的可靠回调。2. PDP怎么发现“参与者”SPDP组播宣告、租约与内置端点2.1 默认实现SPDP消息里到底装了什么Fast DDS的PDP默认实现是SPDP全称Simple Participant Discovery Protocol简单参与者发现协议。它不是一个抽象理论而是有明确定义报文格式和生产级实现的RTPS机制。在这个协议下每个Participant内部固定维护一组用来交换PDP信息的内置端点在DDS主题层面对应内建主题DCPSParticipant在RTPS传输层则使用预先约定的组播地址和端口进行通告。默认情况下domain ID为0时组播地址是239.255.0.1:7400。domain ID每增加1端口号偏移250所以domain 1对应端口7650domain 2对应7900。这个设计保证了不同domain的网络流量天然隔离避免两个团队在同一个局域网里跑各自的系统时相互干扰。实际抓包时这个端口是最重要的过滤条件。SPDP报文里携带的关键信息包括Participant的GUID全局唯一标识由GUID Prefix和Entity ID组成、RTPS协议版本、所属domain ID、租约时长leaseDuration以及一组单播/组播Locator地址。对端收到后会在本地维护一份ParticipantProxy记录里面保存着这个“邻居”的网络可达地址和身份信息之后EDP的所有通信就需要用到这些地址。2.2 宣告周期与租约两个容易被误调的参数Fast DDS里两个最核心的PDP参数默认值非常朴素discoveryPeriod宣告周期默认1秒leaseDuration租约默认3秒。也就是说正常情况下每个Participant每秒钟会向组播地址广播一次自己的存在对端如果连续3秒没有再收到某个Participant的SPDP就会认为它离开了或网络断了主动把本地对应的ParticipantProxy记录清理掉。这两个参数之间的关系是排查“节点明明活着但别人就是看不到它”这类问题的核心。很多优化心切的开发者会把宣告周期往小调比如一百毫秒以期加快发现速度。但若只调周期、不调租约就会出现一个诡异现象两个节点在同一网段里进程都好好的却偶尔互相“失明”。原因是网络稍有抖动3秒内没收到组播对端就把本地记录清了于是触发一次重新发现。我的建议是除非有明确需求否则不要动默认值如果确实要调leaseDuration至少应该是discoveryPeriod的5倍以上否则就是自己给自己挖坑。配置项在Fast DDS的participant attributes里通常通过XML profiles暴露。一个简化示意如下participant rtps builtin discovery_config discoveryProtocolSIMPLE/discoveryProtocol leaseDurationPT3S/leaseDuration leaseAnnouncement period sec1/sec /period /leaseAnnouncement /discovery_config /builtin /rtps /participant代码里也可以通过RTPSParticipantAttributes::builtin.discovery_config.discoveryPeriod和leaseDuration直接改。但注意跨语言的客户端类型、ROS 2的QoS设置都可能覆盖或绕过部分XML配置改了还得验证真的生效。2.3 租约过期引发的“假离线”和“假在线”租约机制本身是可靠的但人类对它的理解经常出错。默认3秒租约的意思是对端把你的ParticipantProxy保留3秒这3秒内只要收到任何一包SPDP就自动续约。所以一个稳定运行的节点它的邻居侧记录几乎不会超时。反过来如果一个节点异常退出因为SPDP不再继续广播其他节点最多3秒后就会把它从参与者的列表里清掉。在ROS 2层面做一次直观验证打开两个终端分别运行两个节点然后直接关掉其中一个进程另一个机器上执行ros2 node list你会看到消失的滞后时间略小于租约时长。如果这个滞后时间过长就得去复查是不是把leaseDuration调得太大了。另一个反面情况是如果你把组播禁掉了PDP宣告完全发不出去则会出现“自己能看到自己但永远看不到别人”的诡异状态因为Fast DDS默认还保留了环回接口的发现能力。3. PDP之后紧跟着EDP端点信息如何从“谁能收发”变成匹配结果3.1 SEDP的两个内置主题绕不开的四类端点当两个Participant通过PDP互相确认存在之后EDP开始工作。Fast DDS的EDP默认实现是SEDPSimple Endpoint Discovery Protocol简单端点发现协议。与PDP的尽力而为不同SEDP基于可靠通信因为它承载的信息量大、错过一次就要重传绝不可能靠“下次周期再广播”来兜底。具体到实现上每个Participant要维护两组内置主题DCPSPublication和DCPSSubscription。每个主题各有一个Writer和一个Reader所以一共是四个内置端点。发Publisher信息由Publication Writer完成订阅方侧的Publication Reader接收发Subscriber信息则由Subscription Writer完成由发布方侧的Subscription Reader接收。看到这些名字不用害怕它们本质就是一些经过特殊标记的RTPS端点伪装成普通话题走同样的收包分发通道。3.2 一个Publisher和Subscriber的完整“对上眼”过程把完整流程放慢看。假设Participant A上创建了一个Subscriber订阅话题/chatterParticipant B上创建了一个Publisher发布话题/chatter。在PDP完成后A和B已经知道彼此地址。接下来A的Subscription Writer会把一条描述Subscriber的SubscriptionData发给BB的Publication Writer也会把一条描述Publisher的PublicationData发给A。两边各自在对方的Publication Reader和Subscription Reader上收到数据。收到数据后Fast DDS要做的是匹配检查。匹配条件比大多数人想象得严格不只是话题名相同type name也必须一致QoS策略还要互相兼容。如果这三个条件都满足双方就会在各自的端点上相互建立写作/阅读关联于是数据通道正式打通。这个匹配过程对两端是对称的某一边漏收了一条EDP消息就会出现“我从A能看到B的话题但B看不到A的”这种单向可见问题。3.3 QoS不匹配是EDP层最常见的分手原因EDP匹配失败时表面症状和PDP失败完全不同。PDP失败时ros2 node list里根本看不到对方节点EDP失败时节点列表正常但话题列表要么缺失、要么有话题名但数据永远是空的。我排查过一个很典型的场景两台机器通过自研的可视化程序连接程序里自定义了History和Reliability策略订阅方用了Volatile的Durability发布方却要求TransientLocal。两边的topic name完全一致type也一致但QoS就是不兼容。ROS 2控制台刷了一堆INCOMPATIBLE_QOS日志话题出现却始终没有数据。这类问题不是网络问题也不是线程问题就是EDP层的QoS匹配规则卡住了。遇到这种症状第一反应应该是列出两端的QoS对象逐个字段比对而不是去抓包看流量。4. 谁在处理这些发现流量接收线程和事件线程的真实分工4.1 先破除一个误解PDP和EDP没有专属常驻线程很多刚接触Fast DDS源码的人容易默认“PDP一个线程EDP一个线程数据通信又一个线程”。真实实现不是这样。Fast DDS里PDP和EDP的逻辑处理都寄生在几个通用机制上收包IO线程、事件调度线程以及内建端点上的回调。它们是协议不是一堆独立调度的线程。理解这一点特别重要因为它直接影响你看性能瓶颈的方向。收包IO线程负责从UDP或TCP socket上读取到来的RTPS报文。默认配置下一个Participant会按需创建若干个这类线程数量和启用的传输通道有关常见的单播、组播通道各自会有一个接收线程在跑。事件调度线程则是Fast DDS内部用于管理周期任务和超时任务的公共设施SPDP的周期性公告、leaseDuration超时清理这类工作都由它驱动。换句话说网络流量由IO线程吃进去周期维护由事件线程负责PDP和EDP的回调则分别挂在各自的Reader上最终在IO线程的上下文里被调用。4.2 一个UDP包从网卡到PDP/EDP回调的完整链路这条链路值得展开讲。假设某个Participant收到一条SPDP消息顺序是这样的。首先UDP传输层接收线程阻塞在socket上拿到一个数据报交给MessageReceiver::processCDRMsg做RTPS子消息解析。接着解析器根据子消息里的实体ID找到对应Endpoint也就是PDP Reader。然后调用该Reader的回调onNewCacheChangeAdded在这个回调里完成GUID比对、ParticipantProxy创建或更新、租约续期等动作。如果这条消息触发了一个新Participant加入回调还会在此基础上发起进一步的SEDP书籍交换于是又有新的EDP消息进入发送队列。这条链路的精髓在于PDP和EDP的处理不是单独的线程在跑而是实实在在发生在接收IO线程的调用栈里。用gdb或perf抓一个高负载进程的栈排在前面的函数往往就是MessageReceiver::processCDRMsg和它下面挂着的Reader回调。这意味着一次发现包的解析时间如果过长后到的其他RTPS包只能排队等着反过来如果发现包流量极大最先被打爆的就是这几个接收线程。4.3 周期宣告为什么必须由事件线程做SPDP每隔一秒自动发送的动作并不能靠接收线程“收到请求再回复”因为组播环境下没有统一的请求源。它就是单纯按时间节拍往组播地址上喊话。Fast DDS把这些周期动作挂到Participant的事件调度器上由事件线程按时间唤醒、执行发送动作。还有租约过期清理本质上也依赖事件线程的定时检查。这个分工带来的实际影响是当你用top或perf观察发现某个进程CPU异常时先分清CPU时间到底是花在接收线程的processCDRMsg上还是花在事件调度上。前者说明流量压力大比如节点多、发现风暴、或有人恶意组播后者说明周期任务太频繁往往和把discoveryPeriod调得过小有关。方向判断错了后面所有调优都会白费。5. 实际调试发现问题的三个层次从抓包到线程视角5.1 第一层先抓包确认SPDP和EDP流量存在排查发现故障我习惯先不碰代码先抓包。domain 0的默认场景下一条tcpdump命令就能验证SPDP是否在发tcpdump -i eth0 udp port 7400 -nn正常启动一个节点你会看到源地址为组播地址或本机地址的周期UDP包。如果看不到任何SPDP包问题大概率出在网络层而不是Fast DDS配置。最常见的三个原因组播被交换机或防火墙挡了节点跑在容器里而容器网络没开启多播两个节点不在同一VLAN。组播是一个很容易被忽略的先决条件尤其在云主机和K8s环境里默认是不支持组播的SPDP首先就发不出去后面一切免谈。如果SPDP正常但话题始终没数据继续抓EDP流量就得靠优化过滤规则。EDP走的是可靠传输端口通常落在单播端口范围不像SPDP有固定的7400这么友好。一个更实用的验证办法是直接用ROS 2层的工具判断ros2 node list能看到对方说明PDP完成了ros2 topic list有话题但ros2 topic echo没有数据说明EDP匹配出了问题。5.2 第二层PDP“看见了”但EDP匹配不上的经典场景假设你已经确认节点列表里能看到对方话题列表却很安静这时候的排查重点我前面已经提过topic name、type name、QoS三者逐一核对。还有一种很容易被忽略的情况就是参与者的domain ID不一致。如果两个节点分别跑在domain 0和domain 1它们不会互相发现对方但各自的node list里可能都看不到对方这个问题会在PDP层先暴露出来属于第一层就能查出。EDP层最常见的坑反而是“话题出现为空”。比如两个节点都加载了同一个接口定义文件但source code里的package版本不一致生成的type identifier不完全一样Fast DDS在type匹配时给出的结果可能是不匹配。从用户视角看明明消息结构一模一样为什么互相不认识这就是因为RTPS层的type匹配非常严格。遇到这种情况先让两端把topic type打印出来对比别急着怀疑中间件。5.3 第三层线程视角下的发现风暴和CPU尖峰到了最底层就是线程。多机多节点场景下我见过很多“启动瞬间CPU飙满、几十秒后才回落”的报告本质就是发现风暴。N个Participant在PDP阶段互相广播、在EDP阶段互相交换端点信息整体通信量接近N平方量级。在一个有20个节点的系统里一多半节点同时重启瞬间EDP可靠消息挤满收包线程CPU自然就上去了。用perf top或者直接开一个gdb attach之后看线程栈基本都能看到收包线程密集执行MessageReceiver::processCDRMsg。这种情况下修改单个参数意义不大真正的优化手段是下面要讲的Discovery Server模式或者拆分domain、控制同一个domain下的Participant数量。从线程角度看发现问题不是“某个线程坏了”而是“所有发现处理都堆在那几个收包线程上”。所以调优的思路永远是减少流量、分散负载而不是增加线程数。6. 大系统下的发现优化从周期参数到Discovery Server6.1 discoveryPeriod和leaseDuration的取舍逻辑这两个参数在小型实验里几乎感觉不到差别但在大系统里它们决定了发现速度与网络压力的平衡。用一个简单关系来说明discoveryPeriod越短新节点加入后被其他人发现的时间就越短但单位时间内的组播包数量也线性增长leaseDuration越长临时掉线节点在邻居列表里残留的时间就越长容易出现“明明进程挂了列表里还能看到它”的尴尬。我个人的经验是如果节点少于10个默认参数就是最优解不用动。如果节点多且启动频繁可以把discoveryPeriod压到500ms左右同时把leaseDuration设为2秒或3秒保证租约仍然远大于周期。反过来如果网络带宽紧张把周期拉到2秒甚至3秒leaseDuration至少要在5到6秒以上。调参数时不能只改一个必须成对改这个我在前面已经踩过坑。6.2 组播不可用的环境单播模式的价值与代价Fast DDS允许把PDP调整为只使用单播它不再依赖组播地址而是通过已知的单播locator列表互相发现。这种方式在某些云网络里很实用因为云厂商的VPC通常不转发组播。但代价是配置量变大你必须把所有Participant的单播地址和端口都写清楚而且每增加一个节点都要更新配置。除非环境强制要求否则一般不建议自己写死单播列表太脆弱。相对更优雅的方案是后面这招Discovery Server。它可以被理解成一个“会合点”把发现流量从组播泛洪改成单播注册特别适合跨网段、跨VLAN、或者组播已被禁用的容器环境。它改动的是PDP协议的模式而不是把组播简单换成单播列表。6.3 Discovery Server把PDP从广播社交变成单播会合Fast DDS的Discovery Server模式在ROS 2里通过环境变量或XML配置即可使用。每个Participant扮演两种角色声明为CLIENT的节点不再发组播SPDP而是定期向已知的SERVER地址注册并请求其他Client的信息声明为SERVER的节点维护一个参与者目录单独为每个Client转发目录变化。这样本来要发到整个局域网的组播PDP流量变成了每个Client和Server之间的一对一单播流量发现收敛时间也不随节点数平方爆炸。设置方式在ros 2中非常直观export ROS_DISCOVERY_SERVER192.168.1.100:11811XML配置则是在participant的discovery_config里把discoveryProtocol改成CLIENT或SERVER再填上discoveryServersList。需要特别提醒Discovery Server运行后Client之间虽然不需要组播也能互相发现但EDP的端点信息交换仍然会发生在两端之间所以网络层仍然要保证它们能单播互通。另外SERVER是单点生产环境最好再考虑备用SERVER的同步否则SERVER挂掉新的Client就进不了这个分布式系统。6.4 优化之前先想清楚瓶颈在哪优化工具永远只是工具真正重要的还是定位瓶颈。如果问题出现在“新节点加入后别人发现它太慢”优先调短discoveryPeriod如果问题出现在“局域网的CPU尖峰和组播风暴”优先上Discovery Server或拆domain如果问题出现在“掉线节点残留在列表里太久”优先调短leaseDuration。把故障现象和协议阶段对应上就不会像无头苍蝇一样乱试参数。每改一次配置都要重新验证PDP和EDP两个层次的表现最简单的方法仍然是ros2 node list配合ros2 topic echo。结尾最后分享一个我自己的排查习惯。遇到任何“发现类”问题我第一反应不是去改参数而是先抓包确认SPDP到底在不在发、EDP到底有没有交换先判断是卡在PDP还是EDP这一层。绝大多数情况下默认参数是够用的真正害我的反而是一次手滑把discoveryPeriod调到了100毫秒结果局域网里瞬间全是RTPS广播所有节点的CPU都被顶了上去节点之间反而因为发现风暴丢失了消息。那一次教训让我彻底明白Fast DDS的发现机制本质上就是收包线程加事件线程的协同产物调任何参数之前想清楚它会让哪个线程多干活、会让哪段链路变快或变慢比什么都重要。