Виды взаимодействия в Интернете вещей

Интернет вещей представляет собой вычислительную сеть, имеющую

- основные узлы – интернет-вещи,

- серверы управления интернет-вещами,

- пользовательские узлы – мобильные и персональные вычислительные устройства.

Таким образом, можно выделить 3 основных вида взаимодействий в Интернете вещей:

1. взаимодействие между интернет-вещами,

2. взаимодействие между пользователями и интернет-вещами,

3. взаимодействие между удалённым сервером и интернет-вещами.

Взаимодействие между удалённым сервером и интернет-вещами

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

- минимизация трафика,

- максимальное исключение ошибок передачи данных и трансляции команд,

- поддержка функции делегирования задачи другой вычислительной единице.

Протоколом сетевого уровня для существующих в настоящий момент интернет-вещей является IP, над которым возможно применение протоколов транспортного уровня со специальными модификациями. В разных источниках рассматривается также вопрос о замене протокола IP с целью улучшить алгоритм маршрутизации для обеспечения мобильности интернет-вещей (например, протоколы Locator/ID Separation Protocol (LISP) и Six/One).

Протокол LISP создан компанией Cisco для разделения на две части функциональности, связанной с IP-адресами. Идентификаторы хостов и локаторы маршрутизации разделяются, и предусматривается установка туннельных маршрутизаторов, добавление LISP-заголовков в пакеты по мере их движения по сети.

Протокол Six/One, созданный компанией Ericsson, является альтернативой LISP и дополнением к протоколу IPv6.При таком подходе хосты получают постоянные IP-адреса, которые меняются лишь в старших битах, в зависимости от того, к какому провайдеру подключен хост в данный момент. Эти старшие биты подставляются автоматически, как только пакеты идут через нового провайдера.

На прикладном уровне существует ряд протоколов, разработанных специально для “умных вещей”. Наиболее известный и популярный среди них - протокол MQTT, разработанный компанией IBM.

Протокол MQTT

MQTT (MQ Telemetry Transport) – это протокол, поддерживаемый микроброкером Lotus Expeditor. MQTT представляет собой основанный на TCP/IP протокол обмена сообщениями publish/subscribe (издатель-подписчик), предназначенный для использования в сетях, требующих минимальных накладных расходов. Микроброкер - это маленький брокер сообщений (менее 2 МБ Java-кода), спроектированный для развёртывания на небольших специализированных устройствах, часто удалённых от корпоративного информационного центра.

Для публикации сообщений при помощи MQ Telemetry Transport требуется соединение c микроброкером Lotus Expeditor или другим сервером обмена сообщениями, поддерживающим протокол MQTT, например, WebSphere Message Broker. Для создания подключения к брокеру необходимо выполнить несколько шагов. Создаётся объект свойств MQTT, который затем передаётся фабрике создания клиента. Этот объект свойств предоставляет конфигурацию созданному экземпляру клиента. Одно из этих свойств - булев флаг (Boolean flag), указывающий, является ли клиентское приложение "клиентом без сохранения сеанса". Если значение флага - true, при каждом подключении клиент не будет знать о предыдущем соединении с брокером (например, о любых ранее сделанных подписках или об ожидающих доставки сообщениях). Если значение флага - false, состояние клиента при различных подключениях к брокеру остаётся прежним; например, клиентскому приложению не потребуется повторная подписка при каждом последующем переподключении. Кроме того, в этом случае клиент и брокер пытаются возобновить любой выполняющийся в данный момент обмен сообщениями (в зависимости от определённого для сообщений качества сервиса), прерванный при разрыве соединения. Для использования "клиента с сохранением сеанса" необходимо обеспечить реализацию интерфейса MqttPersistence. Включение реализации этого интерфейса обозначает для фабрики создания клиента, что клиентскому приложению требуется персистентная (надёжная) доставка сообщений. После настройки свойств мы получаем экземпляр MQTT-клиента из фабрики MQTT-клиента. Для создания экземпляра MQTT-клиента требуется несколько параметров, в том числе уникальный идентификатор клиента (client ID), IP-адрес и порт брокера, а также дополнительный объект MqttProperties, описанный ранее.

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

После успешного подключения MQTT можно публиковать сообщения. Приложения выполняют публикацию через объект MQTT-клиента. Сигнатура метода для публикации сообщения - int publish(String, MqttPayload, byte, Boolean). Ниже подробно рассматриваются эти четыре параметра:

· String. Тип параметра темы - строковой (string), и эта строка используется брокером для сопоставления публикации и интересов подписчиков (указываемых при помощи описанного ранее синтаксиса подписки на темы).

· MqttPayload. Второй параметр - это объект MqttPayload. Объект MqttPayload содержит и данные приложения, и любые заголовки протокола для этой публикации. Предусмотрен сдвиг (offset), чтобы приложения могли определить, где в MqttPayload начинаются данные. Это обеспечивает доступ к нижележащему байтовому массиву без создания дополнительных копий после записи данных в сети. Кроме того, обеспечивается доступ для прямого манипулирования полезными данными после создания объекта и до передачи.

· Byte. Третий параметр, byte, - это качество сервиса (Quality of Service, QoS) для этой публикации. У QoS три допустимых значения: 0, 1 или 2:

QoS, равное 0, означает, что публикатор и брокер пытаются выполнить однократную доставку сообщения, но не предпринимают шаги, кроме предусмотренных TCP/IP, чтобы убедиться в том, что сообщение доставлено. Этот уровень иногда называют "выстрелил и забыл", так как сообщение отправляется адресату без проверки получения.

При QoS, равном 1, доставка сообщения брокеру проверяется; однако его разрешается доставлять более одного раза.

Значение QoS, равное 2, приказывает MQTT доставлять сообщения один и только один раз.

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

 

Подписчики могут указать максимальное значение QoS для доставки сообщений на основе темы, поэтому сообщение, опубликованное с уровнем QoS 2, может быть и не доставлено подписчикам. Подписчик может запросить пониженный уровень QoS для получаемых им сообщений. Хотя может показаться странным, что публикатор не полностью управляет качеством сервиса своих сообщений, в результате увеличивается гибкость для потребителей сообщений. Когда опубликованное сообщение отправляется подписчику, брокер доставляет публикацию либо с максимальным значением QoS, указанным подписчиком во время процесса подписки, либо со значением QoS опубликованного сообщения, если оно ниже. Например, сообщение, опубликованное с QoS = 2 для подписчика, указавшего QoS = 1 для данной темы, доставляется с QoS = 1. Сообщение с QoS = 0, опубликованное для того же подписчика по этой же теме, отправляется подписчику с QoS = 0.

· Boolean. Четвёртый параметр, булев флаг (Boolean flag), определяет, является ли эта публикация задержанной. Задержанная публикация удерживается в брокере как последнее полученное сообщение по данной теме. Задержанные публикации позволяют следующим подписчикам получать самые последние сообщения по какой-либо теме, как только они на неё подпишутся, даже если подключение произойдёт после того, как сообщение будет опубликовано. Эта возможность очень полезна для наполнения данными отображающего информацию приложения сразу после его запуска и последующего обновления этой информации при её изменении. Если значение этого флага - false, сообщение получат только подписчики, в данный момент подписанные на эту тему.

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