DDS通信结构应该是什么？
what should be the DDS communication structure?
我有 2 个退出的 C++ 项目，其中有发送方和接收方。它们通过 UDP 套接字连接连接并通过 CmakeFile.txt
构建
Root
|→ Sender
| |→ src
| |→ include
| |→ Cmakefile.txt
|→ Receiver
| |→ src
| |→ include
| |→ Cmakefile.txt
|→ Cmakefile.txt
现在我想用 DDS context 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
我的结构应该是什么？
项目结构（源文件）：
您提供的项目结构似乎是合理的。一般来说，我建议你的源代码的结构更多地取决于应用程序的体系结构和逻辑结构，而不是通信机制的选择。
但是，将 DDS 集成到项目中时有一些特定的注意事项。特别是，如果您使用 IDL（或 XML）为应用程序定义 DDS 数据类型，那么将这些文件放在 'common' 区域通常是有意义的。 DDS IDL 编译器将从这些类型定义文件生成代码，生成的代码可以编译成一个库，或者简单地编译到每个应用程序中。
此外，如果您使用的是版本控制系统（git、svn 等），那么我建议控制 IDL 文件，而不是生成的代码。 [也有一些控制生成代码的论据，但我认为它几乎总是弊大于利。]因此，特别是对于您的项目，我希望找到一个或多个 IDL（或 XML） DDSCom/src、DDSCom/include 或 DDSCom/idl 下的文件。作为构建过程的一部分，可以创建 CMake 规则以从 IDL 生成特定类型的源代码。这保证了生成的代码与数据类型以及 DDS 实现的升级保持同步。
无论使用何种 DDS 实现，这种方法都应该适用；例如，CoreDX DDS、OpenSplice 或 RTI。
源代码结构：
关于内部代码结构（不是'directory'结构），有很多方法可以构建使用DDS进行通信的应用程序。 DDS API 允许同步和异步通信模式。
通常，数据生产者会创建多个 DDS 实体以促进写入数据的能力（例如，DDS::DomainParticipant、DDS::Publisher、DDS::Topic 和 DDS::DataWriter). DataWriter 实体支持 'write' 调用，其他实体提供各种配置点来影响通信行为和结构。
同样，数据消费者创建相应的 DDS 实体，使其能够 'read' 数据（例如，DDS::DomainParticipant、DDS::Subscriber、DDS::Topic 和DDS::DataReader）。 DataReader 支持 'read' 操作的许多不同变体以提供对可用数据的访问。
每个 DDS 实体都充当其他实体的工厂，并且每个实体都可以配置各种服务质量 (QoS) 策略设置。这些 QoS 设置为 DDS 提供了一组非常丰富的影响通信的配置选项。 'Topic' 实体定义了由名称标识的数据的逻辑分组，并进一步指定了 "type"
集合中包含的数据。
在小项目中，您可能会发现在应用程序需要的地方（例如，就在 main() 例程中）创建 DDS 实体更容易。或者，对于较大的系统，将 DDS 实体封装在一个可以在不同应用程序之间重复使用的组件中通常是有益的。
我有 2 个退出的 C++ 项目，其中有发送方和接收方。它们通过 UDP 套接字连接连接并通过 CmakeFile.txt
构建Root
|→ Sender
| |→ src
| |→ include
| |→ Cmakefile.txt
|→ Receiver
| |→ src
| |→ include
| |→ Cmakefile.txt
|→ Cmakefile.txt
现在我想用 DDS context 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
我的结构应该是什么？
项目结构（源文件）：
您提供的项目结构似乎是合理的。一般来说，我建议你的源代码的结构更多地取决于应用程序的体系结构和逻辑结构，而不是通信机制的选择。
但是，将 DDS 集成到项目中时有一些特定的注意事项。特别是，如果您使用 IDL（或 XML）为应用程序定义 DDS 数据类型，那么将这些文件放在 'common' 区域通常是有意义的。 DDS IDL 编译器将从这些类型定义文件生成代码，生成的代码可以编译成一个库，或者简单地编译到每个应用程序中。
此外，如果您使用的是版本控制系统（git、svn 等），那么我建议控制 IDL 文件，而不是生成的代码。 [也有一些控制生成代码的论据，但我认为它几乎总是弊大于利。]因此，特别是对于您的项目，我希望找到一个或多个 IDL（或 XML） DDSCom/src、DDSCom/include 或 DDSCom/idl 下的文件。作为构建过程的一部分，可以创建 CMake 规则以从 IDL 生成特定类型的源代码。这保证了生成的代码与数据类型以及 DDS 实现的升级保持同步。
无论使用何种 DDS 实现，这种方法都应该适用；例如，CoreDX DDS、OpenSplice 或 RTI。
源代码结构：
关于内部代码结构（不是'directory'结构），有很多方法可以构建使用DDS进行通信的应用程序。 DDS API 允许同步和异步通信模式。
通常，数据生产者会创建多个 DDS 实体以促进写入数据的能力（例如，DDS::DomainParticipant、DDS::Publisher、DDS::Topic 和 DDS::DataWriter). DataWriter 实体支持 'write' 调用，其他实体提供各种配置点来影响通信行为和结构。
同样，数据消费者创建相应的 DDS 实体，使其能够 'read' 数据（例如，DDS::DomainParticipant、DDS::Subscriber、DDS::Topic 和DDS::DataReader）。 DataReader 支持 'read' 操作的许多不同变体以提供对可用数据的访问。
每个 DDS 实体都充当其他实体的工厂，并且每个实体都可以配置各种服务质量 (QoS) 策略设置。这些 QoS 设置为 DDS 提供了一组非常丰富的影响通信的配置选项。 'Topic' 实体定义了由名称标识的数据的逻辑分组，并进一步指定了 "type" 集合中包含的数据。
在小项目中，您可能会发现在应用程序需要的地方（例如，就在 main() 例程中）创建 DDS 实体更容易。或者，对于较大的系统，将 DDS 实体封装在一个可以在不同应用程序之间重复使用的组件中通常是有益的。