Индивидуальное решение для обмена сообщениями для IoT-устройств

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

В одной из IoT-систем, разработанных командой КЕДР Solutions, нам нужно было обеспечить соединение клиентского устройства с базой данных и периферийными модулями. Наши разработчики искали гибкое решение, отвечающее всем требованиям проекта.

Итогом поисков стало создание кастомной технологии, повышающей эффективность клиент-серверного взаимодействия. Наша команда интегрировала несколько компонентов, объединив их в библиотеку обмена сообщениями. Далее мы подробно расскажем о структуре и возможностях нашего индивидуального решения.

В одном из наших IoT-проектов мы создали API на стороне сервера устройства для его взаимодействия с периферийным оборудованием. В ходе разработки проекта мы столкнулись с некоторыми общими проблемами, которые попытались решить, используя стандартные сетевые технологии.

Так, мы использовали HTTP для взаимодействия с веб-панелью IoT-системы. Для установления связи между сервером и клиентским устройством – зарядной станцией – мы попытались использовать протокол MQTT. Этот упрощенный сетевой стандарт широко используется для связи клиент-сервер в системах с низкой пропускной способностью.

Однако для нашего проекта такой вариант оказался неподходящим, так как не мог гарантировать эффективную передачу данных и стабильную связь с зарядными устройствами (некоторые из них работали в сетях 2G, которые отличаются плохой пропускной способностью и неустойчивостью соединения).

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

Созданная нами библиотека имеет много общего с аналогичными протоколами обмена сообщениями IoT. Это легковесное решение, предназначенное для интеллектуальных сетей, требующих быстрого и эффективного обмена данными. Библиотека использует модель связи, аналогичную механизму обмена сообщениями MQTT, и имеет простую реализацию, такую как библиотеки POrtable COmponents C++ (POCO).

Несмотря на схожесть с другими протоколами, наше решение для обмена сообщениями IoT имеет ряд преимуществ, способных оптимизировать взаимодействие компонентов внутри системы.

• Документация. Инженеры КЕДР Solutions подготовили четкую и емкую документацию, которая поможет разработать, внедрить и поддерживать ваш проект на основе нашей библиотеки.
• Гибкость. Мы создали кроссплатформенное решение с широкими возможностями настройки, которое можно использовать для обмена сообщениями в различных средах.
• Минимальные накладные расходы. Наша разработка имеет легкую архитектуру, работает по протоколу TCP, при этом накладные расходы ниже по сравнению с MQTT и HTTP.
• Масштабируемость. Решение позволяет создавать сети с количеством узлов, ограниченным только возможностями вашего сервера.
• Безопасность. В библиотеке есть система защиты от вредоносных программ, которая фильтрует входящие сообщения.
• Простая реализация. Библиотека удобна для разработчиков, так как ее можно легко настроить и интегрировать в текущий C++ код.
• Простое развертывание. Библиотеку можно внедрить, имея только локальный или облачный сервер. Мы предоставляем полный набор компонентов, инструментов и инструкций.
• Нетребовательность к ресурсам. Решение обеспечивает эффективную передачу данных и стабильную связь даже в 2G сетях.

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

Создание подобных решений осуществляется инженерами КЕДР Solutions в рамках предоставления услуг по разработке системного и прикладного программного обеспечения. Мы создаем сетевые приложения и протоколы, обеспечивающие бесперебойную связь между компонентами IoT и встроенными системами.

Наша разработка – это набор компонентов, предназначенных для интеграции промежуточного ПО, ориентированного на обработку сообщений (message-oriented middleware или MOM). MOM – это программное обеспечение, поддерживающее обмен данными в распределенной среде. Ориентированная на сообщения инфраструктура библиотеки упрощает реализацию диспетчера, маршрутизатора и других компонентов, связанных с доставкой данных.

Библиотеку можно использовать для разработки приложений с клиент-серверной и одноранговой (P2P) архитектурами. Решение предоставляет интерфейсы для создания, отправки, получения и хранения коммуникационных данных. Оно предназначено для эффективной передачи двоичных файлов. Для генерации различных типов сообщений и их доставки используется несколько классов.

Библиотека работает с сеансами и не поддерживает протоколы без установления соединения, такие как UDP и IP. На данный момент она совместима только с сетевым протоколом TCP.

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

Созданная нами библиотека использует шаблон "издатель/подписчик", который немного отличается от модели, применяемой в аналогичных технологиях обмена сообщениями. Например, MQTT использует брокера, который служит посредником между узлами сети. В нашей модели связи клиенты могут напрямую взаимодействовать с сервером.

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

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

Мы создали гибкое и настраиваемое решение, которое позволяет реализовывать собственную логику, используя компоненты библиотеки.

Библиотека содержит взаимосвязанные компоненты, или классы, используемые для реализации функционала системы обмена данными. К базовым классам относятся Session, Transport, SessionManager и Message.

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

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

Пользователь может расширять и настраивать список сохраняемых параметров с помощью встроенного механизма класса Properties – гетерогенного контейнера для хранения данных.

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

Механизм может быть полезен для отправки подтверждений или уведомлений. Он помогает реализовать протокол дистанционного вызова процедур (Remote Procedure Call или RPC) и запросы с использованием системы обмена сообщениями (например, запрос к сетевому узлу на предоставление доступа к базе данных).

Обычно сеансы появляются в системе при установке соединения с удаленным клиентом (на стороне сервера) и при подключении к серверу (на стороне клиента). В обоих случаях сокетное соединение устанавливается независимо от применяемого протокола – будь то TCP или WebSocket.

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

Transport предоставляет пользователю библиотеки высокоуровневый интерфейс, который позволяет обмениваться сообщениями без обращения ко всем низкоуровневым деталям, характерным для используемого протокола. Например, мы используем библиотеку Asio, которая предоставляет контекст ввода/вывода и набор объектов для работы с TCP. Класс Transport реализует механизм обмена сообщениями на основе этого протокола, скрывая от пользователя подпрограмму стека TCP/IP.

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

При этом класс Transport позволяет работать с очередью в многопоточной среде, не беспокоясь о безопасности данных или гонках API. Интерфейс очереди исключает риск гонок с использованием необязательных типов. Также исключаются все возможные методы, которые могут привести к таким ситуациям, например, расчеты размера очереди.

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

Разработанная нами библиотека содержит компонент SessionManager, который управляет сеансами и предоставляет интерфейс для их создания. Для удобства использования компонента можно прописать в сетевой подсистеме обратный вызов на одно из возможных событий – соединение принято или установлено.

Класс Acceptor или ConnectionListener – это низкоуровневый компонент библиотеки. Он отвечает за получение событий подключения и уведомление SessionManager о необходимости создания сеанса.

В случае успешного подключения экземпляр запроса Transport будет передан в SessionManager. Последний создаст новую сессию и соединит ее с указанным классом Transport.

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

Класс MessageFactory – это специальный компонент, который формирует сообщения из необработанных данных. Создание сообщений вне MessageFactory недопустимо и приведет к системным ошибкам. Чтобы сформировать сообщение, вы должны знать его тип и сеанс, выступающий в качестве контекста.

Тип сообщения определяет его структуру. В системе может быть зарегистрировано любое количество типов сообщений. Главное, чтобы они были уникальными. Сам тип сообщения представляет собой обычный числовой идентификатор. Его базовый вид определяется MessageType.

Как только сообщение создано, оно помещается в канал сообщений или очередь. Dispatcher – это библиотечный компонент, который регистрирует обработчики для разных типов сообщений. Таким образом, обработчик 1 вызывается для обработки MessageType 1 и т. д.

Чтобы создать ответ, мы должны предоставить MessageFactory определенный MessageType и Session.

Одного числового идентификатора недостаточно для описания структуры сообщения. Наша библиотека включает в себя класс Field, который является базовым типом поля сообщения, и класс FieldDescriptor. Последний предоставляет интерфейс для получения дополнительной информации о поле, например, его имени, и помогает создать нужный тип поля.

Оба компонента принадлежат абстрактным классам и не могут напрямую служить указанным выше целям. Для хранения данных можно использовать производные классы – DataField и DataFieldDescriptor соответственно. Этот метод называется затиранием типов. Он используется для хранения любых данных, включая встроенные типы языка C++ и пользовательские типы (UDT).

FiledDescriptors объединяются в дескриптор сообщений, который передается MessageFactory в качестве прототипа. Этот прототип станет основой для мгновенного сообщения определенного типа.

Схематично это можно показать следующим образом:

Итак, каждое сообщение имеет дескриптор, содержащий информацию о типе сообщения (также называемом числовым идентификатором) и его полях. Эти поля не сохраняются в самом дескрипторе сообщения, но используются дескрипторы полей – они создают актуальное поле нужного типа с нужным именем.

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

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