DDS 通信结构应该是什么？

Question

我有 2 个现有的 c++ 项目，其中有发送方和接收方。它们通过 UDP 套接字连接连接并通过 CmakeFile.txt 构建

Root
    |→ Sender
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Receiver
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Cmakefile.txt    

现在我想用 DDS 上下文 idl 更改 UDP

Root
    |→ Sender
    |   |→ src
    |   |   |→ Publisher.cpp
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Receiver
    |   |→ src
    |   |   |→ Subscriber.cpp
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Cmakefile.txt


Root
    |→ Sender
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Receiver
    |   |→ src
    |   |→ include
    |   |→ Cmakefile.txt
    |→ DDSCom
    |   |→ src
    |   |   |→ Publisher.cpp
    |   |   |→ Subscriber.cpp
    |   |→ include
    |   |→ Cmakefile.txt
    |→ Cmakefile.txt

我的结构应该是什么？

Answer 1

项目结构（源文件）：

您提出的项目结构似乎是合理的。一般来说，我建议您的源代码结构更多地取决于应用程序的体系结构和逻辑结构，而不是通信机制的选择。

但是，将 DDS 集成到项目中时有一些特定的注意事项。特别是，如果您使用 IDL（或 XML）为应用程序定义 DDS 数据类型，那么将这些文件定位在“公共”区域中通常是有意义的。 DDS IDL 编译器将从这些类型定义文件生成代码，生成的代码可以编译到库中，也可以简单地编译到每个应用程序中。

另外，如果您使用的是版本控制系统（git、svn 等），那么我建议控制 IDL 文件，而不是控制生成的代码。 [也有一些论据来控制生成的代码，但我认为它几乎总是弊大于利。]因此，特别是对于您的项目，我希望在 DDSCom/ 下找到一个或多个 IDL（或 XML）文件src 、 DDSCom/include 或 DDSCom/idl，随您的喜好。作为构建过程的一部分，可以创建 CMake 规则以从 IDL 生成类型特定的源代码。这保证了生成的代码与数据类型以及 DDS 实现的升级保持同步。

无论使用何种 DDS 实现，都应适用此方法；例如，CoreDX DDS、OpenSplice 或 RTI。

源代码结构：

关于内部代码结构（不是“目录”结构），有很多方法可以构建使用 DDS 进行通信的应用程序。 DDS API 允许同步和异步通信模式。

通常，数据生产者会创建多个 DDS 实体以促进写入数据的能力（例如，DDS::DomainParticipant、DDS::Publisher、DDS::Topic 和 DDS::DataWriter）。 DataWriter实体支持'write'调用，其他实体提供各种配置点来影响通信行为和结构。

同样，数据消费者创建相应的 DDS 实体，使其能够“读取”数据（例如，DDS::DomainParticipant、DDS::Subscriber、DDS::Topic 和 DDS::DataReader）。 DataReader 支持“读取”操作的许多不同变体，以提供对可用数据的访问。

每个 DDS 实体都充当其他实体的工厂，每个实体都可以配置各种服务质量 (QoS) 策略设置。这些 QoS 设置为 DDS 提供了一组非常丰富的影响通信的配置选项。 “主题”实体定义了由名称标识的数据的逻辑分组，并进一步指定了“类型” 集合中包含的数据。

在一个小型项目中，您可能会发现在应用程序需要的位置（例如，就在 main() 例程中）创建 DDS 实体更容易。或者，对于较大的系统，将 DDS 实体封装在可以在不同应用程序之间重用的组件中通常是有益的。