Какой должна быть структура связи DDS?

Question

У меня есть 2 выхода проекта C++, где у меня есть отправитель и получатель. Они связаны с соединением сокета UDP и строят через CmakeFile.txt

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

Теперь я хочу изменить UDP с контекстом DDS idl

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 и т. Д.), То я бы порекомендовал контролировать файл [s] IDL, но не сгенерированный код. [Есть также несколько аргументов для управления сгенерированным кодом, но я думаю, что он почти всегда приносит больше вреда, чем пользы.] Поэтому, специально для вашего проекта, я ожидаю найти один или несколько файлов IDL (или XML) в DDSCom/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 поддерживает вызов "запись", а другие объекты предоставляют различные точки конфигурации, влияющие на поведение и структуру связи.

Точно так же потребитель данных создает соответствующие объекты DDS, которые позволяют ему "читать" данные (например, DDS::DomainParticipant, DDS::Subscriber, DDS::Topic и DDS::DataReader). DataReader поддерживает множество различных вариантов операции чтения для обеспечения доступа к доступным данным.

Каждый из объектов DDS действует как фабрика для других объектов, и каждый из них может быть настроен с различными параметрами политики качества обслуживания (QoS). Эти параметры QoS предоставляют DDS очень богатый набор параметров конфигурации, которые влияют на связь. Сущность "Тема" определяет логическую группу данных, идентифицируемых по имени, и дополнительно определяет "тип" данных, содержащихся в коллекции.

В небольшом проекте вам может оказаться проще создавать объекты DDS на месте, где это необходимо в приложении (например, прямо в подпрограмме main()). В качестве альтернативы для более крупных систем часто выгодно инкапсулировать объекты DDS в компоненте, который можно повторно использовать в различных приложениях.