Fast DDS容器与宿主机通信问题解析：共享内存权限限制

在分布式系统开发中，Fast DDS作为高性能的DDS中间件实现，其容器化部署常会遇到通信问题。本文深入分析一个典型场景：当HelloWorld示例在Docker容器中运行发布者，而在宿主机运行订阅者时，出现的共享内存通信障碍。

问题现象

开发者在Docker容器内使用--net host和--ipc host参数运行发布者，同时在宿主机运行订阅者。虽然能观察到端点匹配（Discovery阶段正常），但实际数据传输失败。这种现象在使用Fast DDS 2.14.0版本、Ubuntu 20.04系统时出现，涉及默认的UDPv4和SHM传输组合。

根本原因

问题核心在于共享内存(SHM)传输的权限限制。当发布者在特权容器中运行时，创建的共享内存段具有特定的权限属性。而宿主机上的订阅者进程由于缺乏足够的权限（非特权用户运行），无法访问这些内存段。值得注意的是，发现阶段仍能正常工作，因为该过程通过UDP网络传输实现，不受共享内存权限影响。

解决方案

方案一：提升订阅者权限

通过配置sudoers文件，为订阅者执行文件赋予提升的权限。这种方法虽然直接，但需要注意安全风险，建议仅用于开发测试环境。

方案二：禁用共享内存传输

在Fast DDS配置中显式禁用SHM传输，强制使用纯网络传输。虽然会牺牲部分性能（共享内存的零拷贝优势），但能确保通信可靠性。配置示例如下：

<participant profile_name="no_shm_participant">
    <rtps>
        <useBuiltinTransports>true</useBuiltinTransports>
        <builtinTransportsMask>UDPv4</builtinTransportsMask>
    </rtps>
</participant>

深度技术建议

1. 容器用户映射：考虑在Docker运行时使用--user参数指定用户ID，保持容器内外用户一致性
2. 共享内存调优：如需保留SHM传输，可设置共享内存段的权限掩码（如0666）
3. 混合传输策略：配置多传输组合，优先尝试SHM，失败时自动降级到UDP
4. 监控工具：使用ipcs -m命令监控共享内存段状态，辅助排查权限问题

总结

Fast DDS在容器化环境中的通信问题往往涉及传输层权限和隔离机制。理解不同传输方式（SHM/UDP）的特性差异，合理配置权限和传输策略，是保证分布式系统可靠通信的关键。对于性能敏感场景，建议在开发早期就建立与生产环境一致的用户权限体系。