【FastDDS】FastCDR和ProtoBuf在FastDDS中的应用

在 FastDDS 中，FastCDR 和 Protocol Buffers（ProtoBuf） 是两种不同的数据序列化技术，它们的应用关系体现在“默认支持”与“扩展兼容”的层面，核心是为 FastDDS 提供数据编码/解码能力，但适用场景和集成方式有显著差异。

1. 核心定位：FastCDR 是“原生标配”，ProtoBuf 是“扩展选项”

• FastCDR 是 FastDDS 的原生序列化工具，与 FastDDS 深度绑定，是 FastDDS 实现 DDS 标准（Data Distribution Service）的核心依赖。
  DDS 标准要求使用 CDR（Common Data Representation） 作为默认数据格式（尤其是 XCDRv1 和 XCDRv2 版本），而 FastCDR 正是 CDR 标准的高效 C++ 实现，负责将用户定义的消息类型（通过 IDL 定义）序列化为符合 CDR 规范的二进制流，确保 DDS 节点间的跨平台、跨语言通信兼容性。

• ProtoBuf 是 Google 定义的独立序列化格式，并非 DDS 标准的一部分。在 FastDDS 中，ProtoBuf 需通过扩展机制集成，用于将 ProtoBuf 定义的消息类型适配到 FastDDS 的通信框架中，满足用户在已有 ProtoBuf 生态下使用 FastDDS 的需求。

2. 集成方式：原生支持 vs 扩展适配

• FastCDR 与 FastDDS 的集成：
  FastDDS 对 FastCDR 的支持是“无缝原生”的。用户通过 IDL 文件 定义消息类型（如 HelloWorld.idl），然后使用 FastDDS 提供的代码生成工具（fastddsgen）自动生成基于 FastCDR 的序列化/反序列化代码。这些代码会被 FastDDS 的发布者（Publisher）和订阅者（Subscriber）直接调用，完成消息在网络中的传输。
  例如，用户定义的 HelloWorld 消息会被 fastddsgen 转换为包含 serialize 和 deserialize 方法的 C++ 类，这些方法内部通过 FastCDR 的 Cdr 类实现数据编码/解码。

• ProtoBuf 与 FastDDS 的集成：
  FastDDS 本身不直接支持 ProtoBuf，需通过 自定义类型支持（TypeSupport） 实现适配。具体步骤包括：

  1. 用户通过 .proto 文件定义消息类型（如 message Hello { string text = 1; }）。
  2. 使用 protoc 生成 ProtoBuf 的 C++ 类（包含原生序列化方法）。
  3. 手动实现 FastDDS 的 TypeSupport 接口，将 ProtoBuf 的序列化结果（二进制流）适配为 FastDDS 可处理的格式（通常是封装为 CDR 流或直接传递）。
     这种集成本质上是“将 ProtoBuf 作为数据载体”，通过 FastDDS 的传输能力发送，而非替代 CDR 标准。

3. 应用场景：标准兼容 vs 生态复用

• FastCDR 的典型场景：
  当用户遵循 DDS 标准开发时，FastCDR 是默认选择。例如：

  • ROS 2 中使用 FastDDS 作为中间件时，消息的序列化完全依赖 FastCDR（遵循 CDR 标准）。
  • 工业控制、自动驾驶等依赖 DDS 标准的实时系统，需通过 FastCDR 确保不同厂商设备间的通信兼容性。

• ProtoBuf 的典型场景：
  当用户已有基于 ProtoBuf 的系统，希望复用现有消息定义并利用 FastDDS 的通信能力（如实时性、可靠性）时，会选择集成 ProtoBuf。例如：

  • 微服务架构中，部分模块使用 ProtoBuf 定义接口，需通过 FastDDS 与机器人等实时设备通信。
  • 需在 DDS 网络中传输历史遗留的 ProtoBuf 消息，避免重新定义 IDL 类型。

4. 技术关系：互补而非替代

FastCDR 和 ProtoBuf 在 FastDDS 中并非对立关系，而是针对不同需求的互补选项：

• FastCDR 确保 FastDDS 符合 DDS 标准，提供极致的实时性能和跨平台兼容性，是 FastDDS 的“官方标配”。
• ProtoBuf 作为扩展选项，允许用户在特定场景下复用现有 ProtoBuf 生态，代价是需要额外的适配代码，且可能损失部分 DDS 标准的兼容性（如复杂类型的自动发现）。

总结

在 FastDDS 中，FastCDR 是实现 DDS 标准的核心序列化工具，与 FastDDS 深度绑定，适用于所有遵循 DDS 规范的场景；ProtoBuf 是可选的扩展兼容方案，用于复用现有 ProtoBuf 消息类型，需通过自定义适配集成，不替代 CDR 标准。两者的选择取决于是否需要遵循 DDS 规范或复用已有 ProtoBuf 生态。