DDS 问题排查

DDS（Data Distribution Service）协议栈在构建高性能、实时、分布式系统（如自动驾驶、工业控制、航空航天、金融交易等）中扮演着核心角色。然而，其复杂性和对网络、配置的高度依赖，使得在实际使用中难免会遇到各种问题。以下是一些常见问题及其排查方向的系统性总结：

一、通信问题（数据收不到/发不出）

1. 基础网络连通性问题

   • 排查方向
     • 物理连接：网线、网卡、交换机端口状态。
     • IP配置：参与者IP地址、子网掩码、网关是否正确？是否在同一子网？有无IP冲突？
     • 防火墙/安全组：检查操作系统防火墙（iptables, Windows Firewall）和云环境安全组规则，必须放行DDS使用的端口（尤其是用户数据端口和发现端口）和协议（TCP/UDP，特别是组播UDP）。确认是否阻止了组播流量（常见问题源）。
     • 路由：跨子网通信时，路由表是否正确配置？组播路由是否启用并配置正确（mrouted, pimd）？
     • VLAN：参与者是否在预期的VLAN内？VLAN间路由/中继配置是否正确？
     • MTU：网络路径MTU是否一致？是否存在需要分片但设置了DF位导致丢包的情况？检查netstat -s中的分片统计。

2. DDS发现失败

   • 问题：参与者彼此找不到对方（无法匹配DomainParticipant，DataWriter/DataReader）。
   • 排查方向：
     • Domain ID：所有需要通信的参与者Domain ID是否一致？检查代码、XML配置、环境变量。
     • 发现协议配置：
       • 单播/组播发现：使用的是单播发现(SimpleDiscovery)还是组播发现(MulticastDiscovery)？默认通常是组播。
       • 组播地址/端口：检查DDS实现默认的或用户配置的组播地址(239.255.0.1常见)和端口是否被防火墙/网络设备阻止？参与者配置是否一致？
       • 单播地址列表：如果使用单播发现(InitialPeers)，列表是否正确且可达？是否包含了所有需要发现的参与者的单播地址和发现端口？
       • 发现端口：参与者监听的发现端口是否一致且未被占用？检查配置（通常是7400, 7401等）。
     • 发现流量限制：网络设备是否限制了组播或特定端口的流量速率？
     • 实现差异：不同DDS实现（RTI Connext, Eclipse CycloneDDS, OpenDDS, CoreDX）的默认发现配置可能不同，混合使用时需特别注意兼容性配置。
     • 日志：启用DDS实现的详细日志（尤其是Discovery类别），查看参与者启动、发送/接收发现消息（SPDP, SEDP）的记录。这是最直接的排查手段。

3. QoS策略不兼容

   • 问题：DataWriter和DataReader的QoS策略不匹配导致无法建立连接（即使发现了彼此）。
   • 排查方向：
     • RELIABILITY：Writer是BEST_EFFORT而Reader要求RELIABLE？或者反之？这是最常见的不匹配。
     • DURABILITY：Reader要求TRANSIENT_LOCAL/TRANSIENT/PERSISTENT，但Writer是VOLA