Передача данных, которая всё ещё может удерживаться приложением.

Прежде чем перейти к деталям в следующих разделах, следующая анимация изображает ход событий.

Теперь кратко определим основные сущности системы iceoryx, которые частично уже использовались в приведённом выше примере.

RouDi

RouDi — это аббревиатура от Routing и Discovery. RouDi отвечает за настройку связи, но фактически не участвует в обмене данными между издателем и подписчиком или клиентом и сервером. RouDi можно рассматривать как оператора коммутатора iceoryx. Одна из его других основных задач — настройка общей памяти, которую приложения используют для обмена данными полезной нагрузки. Иногда называемый демоном, RouDi управляет общей памятью и отвечает за обнаружение служб, то есть позволяет подписчикам/клиентам находить темы, предлагаемые издателями/серверами. Он также отслеживает все приложения, которые инициализировали среду выполнения и, следовательно, могут создавать издателей, подписчиков, серверы или клиенты. Предоставляет приложениям средства для запроса этой информации.

Когда приложение аварийно завершает работу, RouDi очищает все ресурсы. Благодаря нашим преимущественно свободным от блокировок межпроцессным механизмам (только одна последняя блокировка; мы работаем над её устранением), связь на основе iceoryx гораздо более надёжна по сравнению с традиционным механизмом, использующим блокировку.

Чтобы просмотреть доступные параметры командной строки для RouDi, вызовите $ICEORYX_ROOT/build/iox-roudi --help.

Общая память

Для обеспечения связи без копирования между процессами iceoryx использует подход с общей памятью, то есть издатели и подписчики или клиенты и серверы могут обмениваться данными через общую память, что приводит к связи без копирования.

Общая память — это физическая память, которая становится доступной для нескольких процессов посредством сопоставления с областью памяти в их виртуальных адресных пространствах.

Дополнительную информацию можно найти в нашей статье о концепции общей памяти.

Среда выполнения

Каждое приложение, которое хочет использовать iceoryx, должно создать экземпляр своей среды выполнения, которая, по сути, обеспечивает связь с RouDi.

Для этого требуются следующие строки кода:

iox::runtime::PoshRuntime::initRuntime("some_unique_application_name");

Среда выполнения — это объект внутри пользовательского приложения, который отображает общую память в адресное пространство пользовательского приложения.

!!! note Для каждого пользовательского приложения разрешён только один объект среды выполнения.

Создание описаний служб для тем

ServiceDescription в iceoryx представляет тему, в рамках которой издатели и подписчики или клиенты и серверы могут обмениваться данными, и однозначно идентифицируется тремя строковыми идентификаторами.

1. Имя группы
2. Имя экземпляра
3. Тема

Тройка, состоящая из таких строк, называется ServiceDescription. Два ServiceDescription считаются совпадающими, если все эти три строки равны поэлементно, то есть имена групп и экземпляров одинаковы для обоих из них. Это означает, что имя группы и имя экземпляра можно игнорировать при создании различных ServiceDescription. Они потребуются для расширенной функции фильтрации в будущем.

Модель службы iceoryx основана на AUTOSAR и до сих пор используется в API с этими именами (Service, Instance, Event). Так называемый канонический протокол реализован в пространстве имён capro.

В следующей таблице представлен обзор различных терминов и текущего сопоставления:

Сервис связан с экземпляром, как классы связаны с объектами в C++. Сервис описывает абстрактную тему, а экземпляр — это одна конкретизация этой абстракции, подобно тому как объект является конкретизированным классом. События в этом контексте подобны членам класса.

Пример:

class MyRadarService {
   public:
      bool hasObstacleDetected;
      float distanceToObstacle;
};

MyRadarService frontLeftRadarInstance;
std::cout << frontLeftRadarInstance.hasObstacleDetected << std::endl;

В мире iceoryx мы бы, например, подписались на сервис («MyRadarService», «frontLeftRadarInstance», «hasObstacleDetected») и получали бы образец всякий раз, когда обнаруживалось препятствие. Или мы бы подписались на «distanceToObstacle» и получали бы постоянный поток данных, представляющий расстояние до препятствия.

Ограничения

Тип данных передаваемых данных может быть любым классом, структурой или простым старым типом данных, если он удовлетворяет следующим условиям:

• не используется куча;
• структура данных полностью содержится в общей памяти — нет указателей на локальную память процесса, нет ссылок на локальные конструкции процесса, нет динамических распределителей;
• структура данных должна быть перемещаемой и поэтому не должна внутренне использовать указатели/ссылки;
• нет виртуальных функций-членов;
• нельзя полагаться на вызов деструктора.

!!! Примечание Образец может быть выпущен из процесса без права записи в общую память. Поэтому деструктор не вызывается при выпуске образца. Все типы данных должны быть либо тривиально разрушаемыми, либо по крайней мере не должны полагаться на вызов деструктора. Последнее относится к контейнерам iceoryx, таким как cxx::vector, где только внутренний тип должен быть тривиально разрушаем.

!!! Информация Большинство типов STL нельзя использовать, но некоторые из них перереализованы для удовлетворения вышеуказанных условий. Обзор можно найти здесь.

Издатель

Издатель привязан к теме и нуждается в описании сервиса для создания. Если он типизирован, необходимо дополнительно указать тип данных в качестве параметра шаблона. В противном случае издатель знает только о необработанной памяти, и пользователь должен убедиться, что она интерпретируется правильно.

После того как он предложил свою тему, он может публиковать (отправлять) данные определённого типа. Обратите внимание, что по умолчанию существует несколько издателей для одной и той же темы (n:m-коммуникация). Доступен параметр компиляции, чтобы ограничить iceoryx 1:n-связью. При использовании 1:n-связи RouDi проверяет наличие нескольких издателей по одной и той же теме и выдаёт ошибку, если существует более одного издателя для темы.

Подписчик

Симметрично подписчик также соответствует теме и, следовательно, нуждается в описании службы для создания. Как и для издателей, мы различаем типизированных и нетипизированных подписчиков.

Как только подписчик подписывается на какую-либо тему, он получает данные связанного с ней типа. В нетипизированном случае это необработанная память, и пользователь должен позаботиться о том, чтобы она была интерпретирована совместимым образом с фактически отправленными данными.

Когда несколько издателей предложили одну и ту же тему, подписчик получит данные от всех них (но в неопределённом порядке между разными издателями). Обратите внимание, что подписчик не будет получать данные от серверов или клиентов, даже если они используют одну и ту же тему.

Клиент

Подобно издателям и подписчикам, клиенты привязаны к теме и нуждаются в описании службы для создания. Если клиент типизирован, нужно указать типы запроса и ответа в качестве параметров шаблона. В нетипизированном случае клиент знает только о необработанной памяти, и пользователь должен заботиться о её правильной интерпретации.