Товары в корзине: 0 шт Оформить заказ
Стр. 1 

61 страница

Купить ГОСТ Р 58603-2019 — бумажный документ с голограммой и синими печатями. подробнее

Цена на этот документ пока неизвестна. Нажмите кнопку "Купить" и сделайте заказ, и мы пришлем вам цену.

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

Определяет требования к разработке Клиента MQTT и реализации Сервера MQTT.

Обязательные нормативные положения стандарта, составляющие требования к реализации протокола MQTT, отмечены специальными обозначениями, сформированными по шаблону [MQTT-x.x.x-y] (см. Раздел 3), и размещенными сразу после соответствующего нормативного положения. Полный перечень обязательных нормативных положений справочно представлен в приложении Б.

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

Критерии оценки соответствия реализации Клиента MQTT или Сервера MQTT требованиям настоящего стандарта, приведенные в разделе 9 стандарта.

 Скачать PDF

Содержит требования ISO/IEC 20922:2016

Оглавление

1 Область применения

2 Термины и определения

3 Обозначения и сокращения

     3.1 Обозначения

     3.2 Сокращения

4 Представление данных

     4.1 Бит

     4.2 Целочисленные значения данных

     4.3 Закодированные строки UTF-8

5 Формат управляющего пакета MQTT

     5.1 Структура управляющего пакета МQТТ

     5.2 Фиксированный заголовок

     5.3 Переменный заголовок

     5.4 Полезная нагрузка

6 Управляющие пакеты МQТТ

     6.1 CONNECT - Клиент запрашивает подключение к Серверу

     6.2 CONNACK - Подтверждение запроса на подключение

     6.3 PUBLISH - Публикация сообщения

     6.4 PUBACK - Подтверждение публикации

     6.5 PUBREC - Подтверждение получения пакета PUBLISH с QoS 2

     6.6 PUBREL - Выпуск пакета PUBLISH с QoS 2

     6.7 PUBCOMP - Публикация завершена

     6.8 SUBSCRIBE - Подписка на темы

     6.9 SUBACK - Подтверждение подписки

     6.10 UNSUBSCRIBE - Отменить подписку на темы

     6.11 UNSUBACK - Подтверждение отмены подписки

     6.12 PINGREQ - Запрос PING

     6.13 PINGRESP - Ответ PING

     6.14 Уведомление об отключении

7 Описание работы протоколов

     7.1 Сохранение состояния

     7.2 Сетевые подключения

     7.3 Уровни качества обслуживания и потоки протоколов

     7.4 Повторная доставка сообщений

     7.5 Получение сообщения

     7.6 Порядок отправки сообщений

     7.7 Названия тем и фильтры тем

     7.8 Обработка ошибок

8 Использование WebSocket в качестве протокола передачи данных

     8.1 Примечания IANA

9 Совместимость

     9.1 Цели совместимости

Приложение А (рекомендуемое) Безопасность

Приложение Б (справочное) Обязательные нормативные положения

Приложение В (справочное) Предисловие к оригинальному изданию

Приложение Г (справочное) Извещение правообладателя оригинального издания

Приложение Д (справочное) Сведения об изменениях, внесенных в текст национального стандарта по отношению к исходному стандарту

Библиография

 
Дата введения01.01.2021
Добавлен в базу01.02.2020
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

16.10.2019УтвержденФедеральное агентство по техническому регулированию и метрологии1005-ст
РазработанООО ИАВЦ
РазработанАО ВНИИС
ИзданСтандартинформ2019 г.

Information technology. Internet of things. Message Queuing Telemetry Transport (MQTT) v3.1.1

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТ Р 58603— 2019

(ИСО/МЭК

20922:2016)

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

(ISO/IEC 20922:2016, MOD)

Издание официальное

Москва

Стандартинформ

2019

Предисловие

1    ПОДГОТОВЛЕН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 022 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 16 октября 2019 г. № 1005-ст

4    Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 20922:2016 «Информационные технологии. Протокол организации очередей доставки телеметрических сообщений MQTT. v3.1.1»(ISO/IEC 20922:2016 «Information technology — Message Queuing Telemetry Transport (MQTT) v3.1.1». MOD) путем изменения его структуры для приведения в соответствие с правилами, установленными в ГОСТ 1.5 (подразделы 4.2 и 4.3). Сравнение структуры настоящего стандарта со структурой указанного международного стандарта приведено в дополнительном приложении Д

5    ВВЕДЕН ВПЕРВЫЕ

6    Некоторые положения международного стандарта, указанного в пункте 4. могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© ISO, 2016 — Все права сохраняются ©Стандартинформ, оформление. 2019

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

и

5.2.2 Флаги

Остальные биты [3-0] байта 1 в фиксированном заголовке содержат флаги, специфичные для какого типа управляющего пакета MQTT. как приведено в таблице 6. Если в таблице 6 бит флага отмечен, как «Зарезервировано», то он зарезервирован для будущего использования и ДОЛЖЕН быть установлен в значение, указанное в данной таблице [MQTT-5.2.2-1]. Если полученный пакет содержит неверные флаги, получатель ДОЛЖЕН прервать сетевое соединение [MQTT-5.2.2-2]. Более подробная информация об обработке ошибок приведена в подразделе 7.8.

Таблица 6 — Биты флагов

Управляющий пакет

Фиксированные флаги заголовков

Бит 3

Бит 2

Бит 1

Бит 0

CONNECT

Зарезервировано

0

0

0

0

CONNACK

Зарезервировано

0

0

0

0

PUBLISH

Используется в MQTT 3.1.1

DUP1

QoS2

QoS2

RETAIN3

PUBACK

Зарезервировано

0

0

0

0

PUBREC

Зарезервировано

0

0

0

0

PUBREL

Зарезервировано

0

0

1

0

PUBCOMP

Зарезервировано

0

0

0

0

SUBSCRIBE

Зарезервировано

0

0

1

0

SUBACK

Зарезервировано

0

0

0

0

UNSUBSCRIBE

Зарезервировано

0

0

1

0

UNSUBACK

Зарезервировано

0

0

0

0

PINGREQ

Зарезервировано

0

0

0

0

PINGRESP

Зарезервировано

0

0

0

0

DISCONNECT

Зарезервировано

0

0

0

0

DUP1 = Повторная доставка управляющего пакета PUBLISH

QoS2 = Качество услуги передачи PUBLISH

RETAIN3 = Флаг сохранения пакета PUBLISH

В пункте 6.3.1 приведено описание DUP. QoS и RETAIN в составе управляющего пакета PUBLISH.

5.2.3 Остаток байтов

Позиция: начинается с байта 2.

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

Число оставшихся в данном пакете байтов кодируется с использованием схемы кодирования с переменной длиной, которая использует один байт для значений до 127. Более крупные величины обрабатываются следующим образом. Наименее значимые семь бит каждого байта кодируют данные, а самый старший бит используется для указания, что в представлении присутствуют следующие байты. Таким образом, каждый байт кодирует 128 значений и «бит продолжения». Максимальное количество байтов в поле «Остаток байтов» равно четырем.

Пример—Десятичное число 64 кодируется как один байт, десятичное значение 64, шестнадцатеричное 0x40. Десятичное число 321 (* 65 ♦ 2428) кодируепкя как два байта, наименее значимые указываются первыми. Первый байт равен 65 * 128 = 193. Обратите внимание, что верхний бит установлен для указания хотя бы одного следующего байта. Второй байт равен 2.

Примечание — Кодирование остатка байтов позволяет приложениям отправлять управляющие пакеты размером до 268435455 (256 МБ). Представление этого числа в закодированном виде OxFF. OxFF, OxFF, 0x7F.

В таблице 7 приведены значения остатка байтов, представленные в порядке возрастания числа байтов.

Таблица 7 — Размер поля остатка байтов

Цифры

От

До

1

0(0x00)

127 (0x7F)

2

128 (0x80. 0x01)

16 383 (OxFF, 0x7F)

3

16 384(0x80. 0x80, 0x01)

2 097 151 (OxFF. OxFF. 0x7F)

4

2 097 152 (0x80. 0x80, 0x80. 0x01)

268 435 455 (OxFF. OxFF. OxFF, 0x7F)

Примечания

1    Алгоритм кодирования неотрицательного целого (X) в схему кодирования с переменной длиной выглядит следующим образом

-    ввод

-    encodedByte = X MOO 128

-    X = XDIV 128

-    // если для кодирования данных доступно больше данных, установите верхний бит этого байта

-    если (X > 0)

-    encodedByte = encodedByte ИЛИ 128

-    endif

-    output' encodedByte

-    когда (X > 0)

если MOO является оператором modulo (% in С), DIV является целым делением (/ in С), a OR — поразрядным или (| в С).

2    Алгоритм декодирования поля «Остаток байтов» выглядит следующим образом

-    множитель = 1

-    значение = 0

-    ввод

-    encodedByte = «следующий байт из потока»

-    значение ♦ = (encodedByte AND 127) * множитель

-    множитель * = 128

-    если (множитель> 128 * 128 * 128)

-    выводит ошибку (недопустимая Остаток байтов)

-    когда ((encodedByte AND 128)' = 0)

-    где AND — бит-бит и оператор (& в С),

Когда этот алгоритм завершается, величина содержит значение «Оставшейся длины»

5.3 Переменный заголовок

Некоторые типы управляющих пакетов MQTT содержат компонент переменного заголовка. Он находится между фиксированным заголовком и полезной нагрузкой. Содержимое переменного заголовка зависит от типа управляющего пакета. Поле «Идентификатор пакета» переменного заголовка является общим для нескольких типов пакетов.

5.3.1 Идентификатор пакета

В таблице 8 приведены байты идентификатора пакета.

Таблица 8 — Байты идентификатора пакета

Бит

7

6

5

4

3 | 2

1

0

Байт 1

Идентификатор пакета MSB

Байт 2

Идентификатор пакета LSB

Компонент переменного заголовка для многих типов управляющих пакетов включает в себя поле идентификатора пакета из 2 байтов. Такими управляющими пакетами являются PUBLISH (где QoS > 0). PUBACK. PUBREC, PUBREL. PUBCOMP. SUBSCRIBE. SUBACK. UNSUBSCRIBE. UNSUBACK.

Управляющие пакеты SUBSCRIBE. UNSUBSCRIBE и PUBLISH (в случаях, когда QoS > 0) ДОЛЖНЫ содержать ненулевой 16-разрядный идентификатор пакета (MQTT-5.3.1-1). Каждый раз. когда Клиент отправляет новый пакет одного из этих типов, он ДОЛЖЕН назначить ему неиспользуемый в настоящее

время идентификатор пакета (MQTT-5.3.1-2). Если Клиент повторно отправляет конкретный управляющий пакет, он ДОЛЖЕН использовать тот же идентификатор пакета в последующих повторных отправках этого пакета. Идентификатор пакета становится доступным для повторного использования после того, как Клиент обработал соответствующий пакет подтверждения. В случае QoS 1 PUBLISH — это соответствующий PUBACK; в случае QoS 2 — это PUBCOMP. Для SUBSCRIBE или UNSUBSCRIBE — это соответствующий SUBACK или UNSUBACK [MQTT-5.3.1-3J. Те же условия применяются к Серверу, когда он отправляет PUBLISH с QoS > 0 [MQTT-5.3.1-4],

Пакет PUBLISH НЕ ДОЛЖЕН содержать идентификатор пакета, если его значение QoS установлено на 0 [MQTT-5.3.1-5],

Пакеты PUBACK. PUBREC или PUBREL ДОЛЖНЫ содержать тот же идентификатор пакета, что и первоначально отправленный пакет PUBLISH [MQTT-5.3.1-6], Аналогично SUBACK и UNSUBACK ДОЛЖНЫ содержать идентификатор пакета, который использовался в соответствующем пакете SUBSCRIBE и UNSUBSCIBE. соответственно [MQTT-5.3.1-7].

Управляющие пакеты, требующие идентификатор пакета, приведены в таблице 9.

Таблица 9 — Управляющие пакеты, содержащие идентификатор пакета

Управляющий пакет

Попе идентификатора пакета

CONNECT

НЕТ

CONNACK

НЕТ

PUBLISH

ДА (если QoS > 0)

PUBACK

ДА

PUBREC

ДА

PUBREL

ДА

PUBCOMP

ДА

SUBSCRIBE

ДА

SUBACK

ДА

UNSUBSCRIBE

ДА

UNSUBACK

ДА

PINGREQ

НЕТ

PINGRESP

НЕТ

DISCONNECT

НЕТ

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

Пример — Клиент может отправить пакет PUBLISH с идентификатором пакета 0x1234, а затем получить другой пакет PUBLISH с идентификатором пакета 0x1234 со своего Сервера, прежде чем он получит PUBACK по отправленному PUBLISH.

Клиент    Сервер

Идентификатор пакета PUBLISH = 0x1234---

*--Идентификатор пакета PUBLISH = 0x1234

Идентификатор пакета PUBACK = 0x1234 — -* *— Идентификатор пакета PUBACK = 0x1234


5.4 Полезная нагрузка

Некоторые управляющие пакеты MQTT содержат полезную нагрузку в качестве конечной части пакета, как описано в главе 6. В случае пакета PUBLISH — это сообщение приложения. В таблице 10 приведены управляющие пакеты, в которые необходимо включать полезную нагрузку.

Таблица 10 — Управляющие пакеты, содержащие полезную нагрузку

Управляющий пакет

Полезная нагрузка

CONNECT

Обязательно

CONNACK

Нет

PUBLISH

Опционально

PUBACK

Нет

PUBREC

Нет

PUBREL

Нет

PUBCOMP

Нет

SUBSCRIBE

Обязательно

SUBACK

Обязательно

UNSUBSCRIBE

Обязательно

UNSUBACK

Нет

PINGREQ

Нет

PINGRESP

Нет

DISCONNECT

Нет

6 Управляющие пакеты MQTT

6.1    CONNECT — Клиент запрашивает подключение к Серверу

После того, как Клиент установил сетевое соединение с Сервером, первым пакетом, отправленным Клиентом на Сервер. ДОЛЖЕН быть пакет CONNECT (СОЕДИНЕНИЕ) (MQTT-6.1.0-11-

Клиент может отправить пакет CONNECT через сетевое подключение только один раз. Сервер ДОЛЖЕН обработать второй пакет CONNECT, отправленный Клиентом, как нарушение протокола, и прервать соединение с Клиентом [MQTT-6.1.0-2). Информация об обработке приведена в подразделе 7.8.

Полезная нагрузка содержит одно или несколько закодированных полей. Они определяют уникальный идентификатор Клиента для Клиента, тему «последней воли», сообщение «последней воли», имя пользователя и пароль. Все поля, кроме идентификатора Клиента, являются необязательными и их наличие определяется на основе флагов в переменном заголовке.

6.1.1    Фиксированный заголовок

В таблице 11 приведен фиксированный заголовок пакета CONNECT.

Таблица 11 — Фиксированный заголовок пакета CONNECT

Бит

7

6

5

4

3

2

1

0

Байт 1

Тип управляющего пакета MQTT (1)

Зарезервировано

0

0

0

1

0

0

0

0

Байт 2...

Остаток байтов

Поле «Остаток байтов»

Остаток байтов — это длина переменного заголовка (10 байт) плюс длина полезной нагрузки. Суммарное количество байт в остатке кодируется способом, описанным в подпункте 5.2.3.

6.1.2 Переменный заголовок

Переменный заголовок для пакета CONNECT состоит из четырех полей в следующем порядке: имя протокола, уровень протокола, флаги подключения и интервала поддержки активного соединения.

6.1.2.1 Имя протокола

В таблице 12 приведены байты имени протокола.

Таблица 12 —Байты имени протокола

Имя протокола

Описание

7

6

5

4

3

2

1

0

Байт 1

Длина MSB (0)

0

0

0

0

0

0

0

0

Байт 2

Длина LSB (4)

0

0

0

0

0

1

0

0

Байт 3

«М»

0

1

0

0

1

1

0

1

Байт 4

«О»

0

1

0

1

0

0

0

1

Байт 5

«Т»

0

1

0

1

0

1

0

0

Байт 6

«Т»

0

1

0

1

0

1

0

0

Имя протокола — это кодированная строка UTF-8. которая представляет собой имя протокола «МОТТ», записанное заглавными буквами, как показано. Строка, ее смещение и длина не меняются в последующих изданиях спецификации MQTT.

Если имя протокола неверно. Сервер МОЖЕТ прервать соединение с Клиентом, или МОЖЕТ продолжить обработку пакета CONNECT в соответствии с некоторыми другими спецификациями. В последнем случае Сервер НЕ ДОЛЖЕН продолжать обрабатывать пакет CONNECT в соответствии с настоящей спецификацией [MQTT-6.1.2-1).

Пример — Инспекторы пакетов, например, брандмауэры, могут использовать Имя протокола для идентификации трафика MQTT.

6.1.2.2 Уровень протокола

В таблице 13 приведен байт уровня протокола.

Таблица 13 — Байт уровня протокола

Уровень протокола

Описание

7

6

5

4

3

2

1

0

Байт 7

Уровень(4)

0

0

0

0

0

1

0

0

8-битная величина без знака, представляющая уровень версии протокола, используемый Клиентом. Значение поля «Уровень протокола» для версии 3.1.1 протокола 4 (0x04). Сервер ДОЛЖЕН ответить на пакет CONNECT передачей пакета CONNACK с кодом 0x01 (неподдерживаемая версия протокола), а затем прервать соединение с Клиентом, если уровень протокола не поддерживается Сервером (MQTT-6.1.2-2).

6.1.2.3 Флаги соединения

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

Таблица 14 — Байты флагов соединения

Бит

7

6

5

4

3

2

1

0

Флаг

имени

пользователя

Флаг

пароля

Флаг сохранения «последней воли»

QoS

«последней

воли»

Флаг

«последней

воли»

Флаг

очистки

Сеанса

Зарезер

вировано

Байт 8

X

X

X

X

X

X

X

X

Сервер ДОЛЖЕН проверить, что зарезервированный флаг в пакете управления CONNECT установлен на ноль и прервать соединение с Клиентом, если значение отлично от нуля [MQTT-6.1.2-3].

6.1.2.4 Флаг очистки Сеанса

Позиция: бит 1 байта флага соединения.

Значение этого бита определяет способ обработки состояния Сеанса.

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

Если для флага очистки Сеанса установлено значение «0». Сервер ДОЛЖЕН возобновить обмен данными с Клиентом на основе состояния текущего сеанса (как определено идентификатором Клиента). Если нет Сеанса, связанного с идентификатором Клиента. Сервер ДОЛЖЕН создать новый сеанс. Клиент и Сервер ДОЛЖНЫ сохранять информацию о состоянии текущего Сеанса после прекращения соединения между Клиентом и Сервером (MQTT-6.1.2-4]. После завершения Сеанса, по которому параметр «Очистить сеанс» установлен на 0. Сервер ДОЛЖЕН сохранить дополнительные сообщения с уровнем качества обслуживания 1 и 2. соответствующие любым подпискам, которые существовали у Клиента во время завершения Сеанса [MQTT-6.1.2- 5]. Он МОЖЕТ также хранить сообщения с уровнем качества обслуживания 0. соответствующие тем же критериям.

Если для флага очистки Сеанса установлено значение «1». Клиент и Сервер ДОЛЖНЫ завершить любой предыдущий Сеанс между Клиентом и Сервером и запустить новый. Этот Сеанс длится до тех пор. пока существует сетевое подключение. Данные состояния, связанные с этим Сеансом. НЕ ДОЛЖНЫ повторно использоваться в любом последующем сеансе [MQTT-6.1.2-6].

Состояние сеанса у Клиента состоит из:

-    сообщений с уровнем качества обслуживания 1 и 2, которые были отправлены на Сервер, но не были полностью подтверждены;

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

Состояние Сеанса на Сервере состоит из:

-    признака существования Сеанса, даже если остальная часть состояния Сеанса пуста:

-    подписок Клиента.

-    QoS 1 и QoS 2. которые были отправлены Клиенту, но не были полностью подтверждены.

-    QoS 1 и QoS 2. ожидающие передачи Клиенту;

-    сообщения QoS 2, полученные от Клиента, но не полностью подтвержденные;

-    опционально сообщения QoS 0. ожидающие передачи Клиенту.

Сохраненные сообщения не являются частью состояния Сеанса на Сервере, они НЕ ДОЛЖНЫ удаляться, когда Сеанс заканчивается (MQTT-6.1.2.7J.

Более подробная информация и ограничения сохраненного состояния приведены в подразделе 4.1.

Если для параметра «Очистить сеанс» установлено значение 1. Клиент и Сервер не должны обрабатывать удаление состояния атомарно.

Примечания

1    Чтобы обеспечить надлежащее состояние в случае сбоя связи, Клиент должен повторить попытки подключения, установив параметр «Очистить сеанс» на 1. пока соединение не будет успешно выполнено.

2    Как правило. Клиент всегда будет подключаться с использованием параметра «Очистить Сеанс», установленного на 0 или на 1. и не будет переключаться с одного значения на другое Выбор будет зависеть от приложения Клиент, использующий «Очистить Сеанс», установленный на 1, не получит старые сообщения приложения и должен заново подписываться на любые темы, которые его интересуют, при каждом подключении Клиент, использующий «Очистить Сеанс», установленный на 0. получит все сообщения QoS 1 или QoS 2. которые были опубликованы, пока он был отключен Следовательно, чтобы гарантировать получение сообщений после отключения, используйте QoS 1 или QoS 2 с параметром «Счистить Сеанс», установленным на 0

3    При подключении Клиента с параметром «Очистить сеанс*, установленным на 0, он запрашивает, чтобы Сервер сохранил состояние сеанса MQTT после его отключения Клиенты должны подключаться только с параметром «Очистить Сеанс*, установленным на 0, если они планируют повторно подключиться к Серверу в какой-то более поздний момент времени Когда Клиент решил, что он больше не использует Сеанс, он должен выполнить окончательное соединение с параметром «Очистить Сеанс», установленным на 1. а затем отключиться

6.1.2.5    Флаг «последней воли»

Позиция: 2 бита флагов подключения.

Установка флага «последней воли» на 1 означает, что, если запрос о соединении принят, сообщение «последней воли» ДОЛЖНО храниться на Сервере и быть связано с сетевым подключением. Сообщение о «последней воле» ДОЛЖНО быть опубликовано, когда Сетевое подключение будет закрыто, если сообщение не было удалено Сервером при получении пакета DISCONNECT [MQTT-6.1.2-8],

Ситуации, в которых публикуется сообщение о дальнейших действиях, включают, но не ограничиваются:

-    ошибкой ввода-вывода или сетевым сбоем, обнаруженными Сервером;

-    Клиент не может выполнить соединение в течение времени активного соединения;

-    Клиент закрывает сетевое соединение без предварительной отправки пакета DISCONNECT;

-    Сервер закрывает сетевое подключение из-за ошибки протокола.

Если флаг «последней воли» установлен на 1, поля уровня качества обслуживания сообщения «последней воли» и сохранение сообщения «последней воли» во флагах соединения будут использоваться Сервером, а поля темы «последней воли» и сообщения «последней воли» ДОЛЖНЫ присутствовать в полезной нагрузке [MQTT-6.1.2-9).

Сообщение о «последней воле» ДОЛЖНО быть удалено из сохраненного состояния Сеанса на Сервере после публикации, или когда Сервер получил от Клиента пакет DISCONNECT [MQTT-6.1.2-10].

Если флаг дальнейших действий установлен на 0. значения полей QoS и будущее сохранение должны быть установлены на ноль, а поля будущей темы и сообщение о дальнейших действиях НЕ ДОЛЖНЫ присутствовать в полезной нагрузке [MQTT-6.1.2-11].

Если флаг дальнейших действий установлен на 0. сообщение «последней воли» НЕ ДОЛЖНО публиковаться при завершении данного сетевого подключения [MQTT-6.1.2-12].

Серверу СЛЕДУЕТ немедленно публиковать сообщения «последней воли». В случае отключения или сбоя Сервера, он МОЖЕТ отложить публикацию сообщений «последней воли» до последующего перезапуска. Если это произойдет, может наблюдаться задержка между временем, когда произошел сбой Сервера, и временем публикации сообщений «последней воле».

6.1.2.6    Уровень качества обслуживания (QoS) «последней воли»

Позиция: биты 4 и 3 флагов соединения.

Эти два бита определяют уровень качества обслуживания QoS, который будет использоваться при публикации сообщений «последней воли».

Если флаг «последней воли» установлен на 0, то значение QoS «последней воли» ДОЛЖНО быть установлено на 0 (0x00) (MQTT-6.1.2-13].

Если флаг «последней воли» установлен на 1. значение QoS «последней воли» может быть 0 (0x00), 1 (0x01) или 2 (0x02). Значение НЕ ДОЛЖНО быть установлено на 3 (0x03) [MQTT-6.1.2-14].

6.1.2.7    Флаг сохранения «последней воли»

Позиция: бит 5 флагов соединения.

Этот бит указывает, следует ли сохранять сообщение «последней воли», когда оно опубликовано.

Если флаг «последней воли» установлен на 0. то флаг будущего сохранения ДОЛЖЕН быть установлен на 0 [MQTT-6.1.2-15].

Флаг «последней воли» установлен на 1 в следующих случаях:

-    если для будущего сохранения установлено значение 0. Сервер ДОЛЖЕН публиковать сообщение о дальнейших действиях как не сохраненное сообщение (MQTT-6.1.2-16];

-    если для будущего сохранения установлено значение 1, Сервер ДОЛЖЕН публиковать сообщение о дальнейших действиях как сохраненное сообщение (MQTT-6.1.2-17).

6.1.2.8    Флаг имени пользователя

Позиция: бит 7 флагов соединения.

Если параметр флага имени пользователя установлен на 0. имя пользователя НЕ ДОЛЖНО присутствовать в полезной нагрузке [МОТТ-6.1.2-18].

Если параметр флага имени пользователя установлен на 1, имя пользователя ДОЛЖНО присутствовать в полезной нагрузке [МОТТ-6.1.2-19].

6.1.2.9    Флаг пароля

Позиция: бит 6 байтов флагов соединения.

Если флаг пароля установлен на 0. пароль НЕ ДОЛЖЕН присутствовать в полезной нагрузке (MQTT-6.1.2-20].

Если флаг пароля установлен на 1. пароль ДОЛЖЕН присутствовать в полезной нагрузке [MQTT-6.1.2-21).

Если параметр флага имени пользователя установлен на 0. флаг пароля ДОЛЖЕН быть установлен на 0 [MQTT-6.1.2-22].

6.1.2.10 Интервал поддержки активного соединения В таблице 15 приведены байты активного соединения.

Таблица 15 — Байты активного соединения

Бит

7

6 | 5

4

3 2

1 1 0

Байт 9

Активное соединение MSB

Байт 10

Активное соединение LSB

Активное соединение — это временной интервал, измеряемый 8 секундах и представляемый в виде 16-битного слова, что является максимально допустимым временным промежутком между моментом. в который Клиент заканчивает передачу одного управляющего пакета и моментом, в который он начинает отправлять следующий. Клиент несет ответственность за то. чтобы промежуток между отправляемыми управляющими пакетами не превышал значение активного соединения. В случае отсутствия необходимости в отправке каких-либо других управляющих пакетов Клиент ДОЛЖЕН отправить пакет PINGREQ [MQTT-6.1.2-23).

Клиент может отправить PINGREQ в любое время, независимо от значения активного соединения. и использовать PINGRESP для определения того, что сеть и Сервер работают.

Если значение активного соединения не равно нулю, и Сервер не получает управляющий пакет от Клиента в течение полутора интервалов периода активного соединения, он ДОЛЖЕН отключить сетевое соединение с Клиентом, как если бы произошел сбой сети [MQTT -3.1.2-24).

Если Клиент не получает пакет PINGRESP в течение разумного промежутка времени после отправки PINGREQ. ему СЛЕДУЕТ прервать сетевое подключение к Серверу.

Значение активного соединения, равное нулю (0). приводит к отключению механизма отслеживания активного соединения. Это означает, что в этом случае Сервер не обязан отключать Клиента по причине отсутствия действий.

Обратите внимание, что Серверу разрешено отключать Клиента, которого он определяет, как неактивного или не реагирующего, в любое время, независимо от значения активного соединения, предоставленного этим Клиентом.

Примечание — Фактическое значение активного соединения является специфичным для приложения, обычно оно составляет несколько минут Максимальное значение составляет 18 часов 12 минут и 15 секунд

Пример — Переменный заголовок приведен в таблице 16.

Таблица 16 — Пример переменного заголовка

Описание

*

6

5

4

3

2

-

0

Имя протокола

Байт 1

Длина MSB (0)

0

0

0

0

0

0

0

0

Байт 2

Длина LSB (4)

0

0

0

0

0

1

0

0

Байт 3

«М»

0

1

0

0

1

1

0

1

Байт 4

«Q*

0

1

0

1

0

0

0

1

Байт 5

«Т»

0

1

0

1

0

1

0

0

Байт 6

«Т»

0

1

0

1

0

1

0

0

Уровень протокола

Байт 7

Уровень(4)

0

0

0

0

0

1

0

0

Окончание таблицы 16

Описание

7

6

5

4

3

2

1

0

Флаги соединения

Байт 8

Флаг с именем пользователя (1) Флаг пароля (1)

Будущее сохранение (0) Будущее QoS (01)

Флаг дальнейших действий (1) Счистить сеанс (1) Зарезервировано(0)

1

1

0

0

1

1

1

0

Активное соединение

Байт 9

Активное соединение MSB (0)

0

0

0

0

0

0

0

0

Байт 10

Активное соединение LSB (10)

0

0

0

0

1

0

1

0

6.1.3 Полезная нагрузка

Полезная нагрузка пакета CONNECT содержит одно или несколько полей с префиксом длины, наличие которых определяется флагами в переменном заголовке. Эти поля, если они есть, ДОЛЖНЫ появляться в порядке: идентификатор Клиента, тема «последней воли», сообщение «последней воли», имя пользователя, пароль (MQTT-6.1.3-1).

6.1.3.1    Идентификатор Клиента

Идентификатор Клиента (Clientld) позволяет Серверу идентифицировать Клиента. Каждый Клиент. подключающийся к Серверу, имеет уникальный Идентификатор Клиента (Clientld). Идентификатор Клиента ДОЛЖЕН использоваться Клиентами и Серверами для определения их состояния в отношении этого сеанса MQTT между Клиентом и Сервером (MQTT-6.1.3-21.

Идентификатор Клиента (Clientld) ДОЛЖЕН присутствовать и ДОЛЖЕН быть первым полем в полезной нагрузке пакета CONNECT (MQTT-6.1.3-3).

Clientld ДОЛЖЕН быть кодированной строкой UTF-8, как определено в разделе 4.5.3 [MQTT-6.1.3-4].

Сервер ДОЛЖЕН обрабатывать идентификаторы Клиентов, длина которых попадает в диапазон 1—23 кодированных байтов UTF-8. и которые состоят только из символов «0123456789abcdefghijklmno pqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ» (MQTT-6.1.3-5].

Сервер МОЖЕТ обрабатывать идентификаторы Клиентов, которые содержат более 23 закодированных байтов. Сервер МОЖЕТ разрешить Clientld. содержащие символы, не включенные в список, указанный выше.

Сервер МОЖЕТ позволить Клиенту предоставить Clientld, длина которого равна нулю, однако, если он делает это. Сервер ДОЛЖЕН рассматривать это как особый случай и назначить уникальный Clientld для этого Клиента. Он ДОЛЖЕН обрабатывать пакет CONNECT, как если бы Клиент предоставил уникальный Clientld (MQTT-6.1.3-6].

Если Клиент отправляет Clientld с нулевым байтом, Клиент ДОЛЖЕН также установить флаг очистки Сеанса на 1 (MQTT-6.1.3-7].

Если Клиент отправляет Clientld с нулевым байтом, с установленным значением флага очистки Сеанса равным 0. Сервер ДОЛЖЕН отвечать на управляющий пакет CONNECT отправкой пакета CONNACK с кодом возврата 0x02 (отклонение идентификатора), а затем прервать сетевое соединение (MQTT-6.1.3-8].

Если Сервер отклоняет Clientld. он ДОЛЖЕН отвечать на пакет CONNECT отправкой CONNACK с кодом возврата 0x02 (идентификатор отклонен), а затем прервать сетевое соединение [MQTT-6.1.3-9].

Примечание — Реализация Клиента может обеспечить удобный метод для генерации случайного Clientld Использование такого метода не рекомендуется, если для параметра «Очистить сеанс» установлено значение 0

6.1.3.2    Тема «последней воли»

Если флаг «последней воли» установлен на 1. тема «последней воли» будет следующим полем в полезной нагрузке. Тема «последней воли» ДОЛЖНА быть кодированной строкой UTF-8. как определено в Разделе 4.5.3 (MQTT-6.1.3-10].

6.1.3.3    Сообщение «последней воли»

Если флаг «последней воли» установлен на 1. то это будет следующее поле в полезной нагрузке. Сообщение «последней воли» определяет сообщение приложения, которое должно быть опубликовано в теме, указанной в поле Тема «последней воли», как описано в подпункте 6.1.2.5. Это поле состоит из двух байт, определяющих размер сообщения, за которым следует полезная нагрузка для будущего сообщения. выраженная в виде последовательности из нуля или более байтов. Поле размера сообщения определяет количество байтов в следующих ниже данных и не включает в себя 2 байта, занятых самим полем.

Когда сообщение «последней воли» публикуется в теме «последней воли», его полезная нагрузка состоит из данных сообщения, и не включает поле размера сообщения.

6.1.3.4    Имя пользователя

Если флаг имени пользователя установлен на 1, является следующим в полезной нагрузке. Имя пользователя ДОЛЖНО быть кодированной строкой UTF-8. как определено в пункте 4.5.3 (MQTT-6.1.3-11]. Оно может использоваться Сервером для аутентификации и авторизации.

6.1.3.5    Пароль

Если флаг пароля установлен на 1. поле, определяющее пароль пользователя, является следующим в полезной нагрузке. Поле «Пароль» содержит от 0 до 65535 байтов двоичных данных с двухбайтовым префиксом, указывающим количество байтов, занятых двоичными данными (оно не включает два байта, занятых самим префиксом). Байты пароля приведены в таблице 17.

Таблица 17 — Байты пароля

Бит

7 6 5 4 3 2 1 0

Байт 1

Размер данных MSB

Байт 2

Размер данных LSB

Байт 3...

Данные, если длина > 0

6.1.4 Ответ

Важным моментом является то. что Сервер МОЖЕТ поддерживать несколько протоколов (включая более ранние версии этого протокола) на одном и том же TCP-порту или другой конечной точке сети. Если Сервер определяет, что протокол является MQTT 3.1.1, он проверяет попытку подключения следующим образом:

а)    Если Сервер не получает пакет CONNECT в течение разумного промежутка времени после установления сетевого подключения. Серверу СЛЕДУЕТ закрыть соединение.

б)    Сервер ДОЛЖЕН подтвердить, что пакет CONNECT соответствует описанию, данному в подразделе 6.1 и закрыть сетевое соединение, не отправляя CONNACK, если он не соответствует (MQTT-6.1.4-1).

в)    Сервер МОЖЕТ проверить, чтобы содержимое пакета CONNECT соответствовало любым дополнительным ограничениям и МОЖЕТ выполнять проверки подлинности и авторизации. Если какая-либо из этих проверок не была пройдена. Серверу СЛЕДУЕТ отправить соответствующий пакет CONNACK с ненулевым кодом возврата, как описано в подразделе 6 2. и закрыть сетевое соединение.

Если проверка прошла успешно. Сервер выполняет следующие шаги:

а)    Если идентификатор Клиента представляет Клиента, уже подключенного к Серверу. Сервер ДОЛЖЕН прервать соединение с существующим Клиентом |MQTT-6.1.4-2].

б)    Сервер ДОЛЖЕН выполнить очистку Сеанса согласно процедуре, описанной в подпункте 6.1.2.4 (MQTT-6.1.4-3).

в)    Сервер ДОЛЖЕН подтвердить пакет CONNECT с помощью пакета CONNACK, содержащего нулевой код возврата [MQTT-6.1.4-4].

г)    Запустить доставку сообщений и продолжить мониторинг.

Клиентам разрешено отправлять дополнительные управляющие пакеты сразу после отправки пакета CONNECT; Клиентам не нужно дожидаться поступления пакета CONNACK с Сервера. Если Сервер отклоняет CONNECT, он НЕ ДОЛЖЕН обрабатывать любые данные, отправленные Клиентом после пакета CONNECT [MQTT-6.1.4-5).

Содержание

1    Область применения.................................................................1

2    Термины и определения..............................................................1

3    Обозначения и сокращения............................................................3

3.1    Обозначения....................................................................3

3.2    Сокращения ....................................................................3

4    Представление данных...............................................................3

4.1    Бит............................................................................3

4.2    Целочисленные значения данных...................................................3

4.3    Закодированные строки UTF-8......................................................3

5    Формат управляющего пакета MQTT....................................................4

5.1    Структура управляющего пакета MQTT...............................................4

5.2    Фиксированный заголовок.........................................................5

5.3    Переменный заголовок ...........................................................7

5.4    Полезная нагрузка................................................................9

6    Управляющие пакеты MQTT...........................................................9

6.1    CONNECT — Клиент запрашивает подключение к Серверу .............................9

6.2    CONNACK — Подтверждение запроса на подключение................................16

6.3    PUBLISH — Публикация сообщения................................................17

6.4    PUBACK — Подтверждение публикации ............................................20

6.5    PUBREC — Подтверждение получения пакета PUBLISH с QoS 2........................21

6.6    PUBREL — Выпуск пакета PUBLISH с QoS 2.........................................21

6.7    PUBCOMP — Публикация завершена ..............................................22

6.8    SUBSCRIBE — Подписка на темы .................................................23

6.9    SUBACK — Подтверждение подписки ..............................................25

6.10    UNSUBSCRIBE — Отменить подписку на темы......................................27

6.11    UNSUBACK — Подтверждение отмены подлиски................................... 28

6.12    PINGREQ —Запрос PING.......................................................29

6.13PINGRESP —Ответ PING.......................................................29

6.14 DISCONNECT — Уведомление об отключении......................................30

7    Описание работы протоколов.........................................................30

7.1    Сохранение состояния...........................................................30

7.2    Сетевые подключения...........................................................31

7.3    Уровни качества обслуживания и потоки протоколов..................................31

7.4    Повторная доставка сообщений...................................................34

7.5    Получение сообщения...........................................................34

7.6    Порядок отправки сообщений.....................................................34

7.7    Названия тем и фильтры тем .....................................................35

7.8    Обработка ошибок..............................................................37

8    Использование WebSocket в качестве протокола передачи данных .........................37

8.1    Примечания IANA...............................................................37

9    Совместимость ....................................................................38

9.1    Цели совместимости ............................................................38

Приложение А (рекомендуемое) Безопасность............................................39

Примечание — Клиенты обычно ожидают пакет CONNACK Однако, если Клиент использует возможность отправлять управляющие пакеты, прежде чем он получит CONNACK. это может упростить программную реализацию Клиента, поскольку Клиенту не требуется отслеживать состояние соединения Клиент соглашается с тем, что любые данные, отправленные им до получения пакета CONNACK с Сервера, не будут обрабатываться, если Сервер отклонит соединение

6.2 CONNACK — Подтверждение запроса на подключение

Пакет CONNACK — это пакет, отправленный Сервером в ответ на пакет CONNECT, полученный от Клиента. Первый пакет, отправленный с Сервера Клиенту, ДОЛЖЕН быть пакетом CONNACK (MQTT-6.2.0-11.

Если Клиент не получает пакет CONNACK с Сервера в течение разумного промежутка времени. Клиенту СЛЕДУЕТ прервать сетевое соединение. «Разумный» промежуток времени зависит от типа приложения и инфраструктуры связи.

6.2.1 Фиксированный заголовок

Формат фиксированного заголовка приведен в таблице 18.

Таблица 18 — Фиксированный заголовок пакета CONNACK

Бит

7 | 6

5 | 4

3

2

1

0

Байт 1

Тип управляющего пакета MQTT (2)

Зарезервировано

0

0

1

0

0

0

0 0

Байт 2

Остаток байтов (2)

0

0

0

0

0

0

1

0

Поле «Остаток байтов»

Данное поле определяет размер переменного заголовка. Для пакета CONNACK она имеет значение 2.

6.2.2 Переменный заголовок

Формат переменного заголовка приведен в таблице 19.

Таблица 19 — Переменный заголовок пакета CONNACK

Описание

7 1 6

5

4

3 | 2 | 1

0

Флаги подтверждения соединения

Зарезервировано

SP1

Байт 1

0

0

0

0

0

0

0

X

Код возврата соединения

Байт 2

X

X

X

X

X

X

X

X

6.2.2.1    Флаги подтверждения соединения

Байт 1 — это «Флаги подтверждения соединения». Биты 7-1 зарезервированы и ДОЛЖНЫ быть установлены на 0.

Бит 0 (SP1) — это флаг текущего сеанса.

6.2.2.2    Флаг текущего сеанса

Позиция: бит 0 флагов подтверждения соединения.

Если Сервер принимает соединение с флагом очистки Сеанса, установленным на 1. Сервер ДОЛЖЕН установить флаг текущего Сеанса на 0 в пакете CONNACK в дополнение к установке нулевого кода возврата в пакете CONNACK [MQTT-6.2.2-1).

Если Сервер принимает соединение с флагом очистки Сеанса установленным на 0. значение, устанавливаемое для флага текущего Сеанса, зависит от того, сохранил ли Сервер состояние Сеанса для предоставленного идентификатора Клиента. Если Сервер сохранил состояние сеанса, он ДОЛЖЕН установить флаг текущего Сеанса на 1 в пакете CONNACK (MQTT-6.2.2-2]. Если Сервер не сохранил состояние сеанса, он ДОЛЖЕН установить флаг текущего Сеанса на 0 в пакете CONNACK. Это выполняется дополнительно к установке нулевого кода возврата в пакете CONNACK [MQTT-6.2.2-3].

Приложение Б (справочное) Обязательные нормативные положения .........................42

Приложение В (справочное) Предисловие к оригинальному изданию .........................52

Приложение Г (справочное) Извещение правообладателя оригинального издания ..............53

Приложение Д (справочное) Сведения об изменениях, внесенных в текст национального стандарта

по отношению к исходному стандарту.......................................54

Библиография.......................................................................55

Введение

MQTT — клиент-серверный протокол передачи сообщений, основанный на модели «издатель — подписчик». Он является легким, открытым, простым, и спроектирован таким образом, чтобы его легко можно было реализовать. Данные характеристики делают его идеальным для использования во многих ситуациях, в том числе в ограниченных средах, например, для организации связи в среде межмашинного взаимодействия (М2М) и Интернета вещей (1оТ), где требуется небольшой размер кода и/или пропускная способность сети является приоритетом.

Протокол выполняется с использованием протоколов из набора TCP/IP или через другие сетевые протоколы, которые обеспечивают упорядоченные двунаправленные соединения без потерь. Его функции включают:

а)    использование шаблона проектирования «издатель — подписчик», который обеспечивает распределение сообщений по принципу «один ко многим»;

б)    доставка сообщений, не зависящая от содержимого информационного наполнения:

в)    три уровня качества услуги (QoS) передачи данных:

-    «Не более одного раза», когда сообщения доставляются в соответствии с оптимальными затратами операционной среды. Может произойти потеря сообщений. Данный уровень может использоваться, например, для передачи данных датчика температуры окружающей среды, где потеря отдельного измерения не имеет значения, поскольку вскоре после этого будет опубликовано следующее измерение;

-    «Не реже одного раза», в этом случае гарантируется доставка сообщений, но возможны дубликаты:

-    «Ровно один раз», в этом случае гарантируется доставка сообщений ровно один раз. Данный уровень может использоваться, например, в биллинговых системах, где дублирующиеся или потерянные сообщения могут приводить к применению неправильных сборов;

г)    малый объем служебного трафика и протокольные обмены сводятся к минимуму для снижения сетевого трафика:

д)    механизм уведомления заинтересованных сторон в случае аварийного разрыва связи.

ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1

Information technology Internet of things.

Message Queuing Telemetry Transport (MQTT) v3 1 1

Дата введения — 2021—01—01

1    Область применения

Настоящий стандарт определяет требования к разработке Клиента MQTT и реализации Сервера MQTT.

Обязательные нормативные положения настоящего стандарта, составляющие требования к реализации протокола MQTT. отмечены специальными обозначениями, сформированными по шаблону [MQTT-x.x.x-y] (см. раздел 3). и размещенными сразу после соответствующего нормативного положения. Полный перечень обязательных нормативных положений справочно представлен в приложении Б.

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

Критерии оценки соответствия реализации Клиента MQTT или Сервера MQTT требованиям настоящего стандарта, приведеные в разделе 9 настоящего стандарта.

2    Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

2.1 Ключевые слова «ДОЛЖЕН». «НЕ ДОЛЖЕН». «ТРЕБУЕТСЯ». «БУДЕТ», «НЕ БУДЕТ». «СЛЕДУЕТ». «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ». «МОЖЕТ» и «ОПЦИОНАЛЬНО» в настоящей Спецификации интерпретируются, как описано в IETF RFC (рабочем предложении инженерной рабочей группы Интернета) 2119 (1), следующим образом:

2.1.1    ДОЛЖЕН (MUST), а также термины «требуется» (REQUIRED) и «нужно» (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

2.1.2    НЕ ДОЛЖЕН (MUST NOT) или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

2.1.3    СЛЕДУЕТ (SHOULD), а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от выполнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.

2.1.4    НЕ СЛЕДУЕТ (SHOULD NOT) и глагол не рекомендуется (NOT RECOMMENDED) используются применительно к особенностям или функциям, которые допустимы и могут быть полезными, но могут вызывать проблемы. При реализации таких опций следует учитывать возможность возникновения проблем и принимать взвешенное решение.

Издание официальное

2.1.5 МОЖЕТ (MAY), а также прилагательное необязательный (OPTIONAL) обозначают элементы, реализация которых является необязательной. Одни разработчики могут включать такие опции в свою продукцию для расширения возможностей, а другие — опускать в целях упрощения. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспечиваться за счет некоторого ущерба функциональности). Включающие опцию реализации должны быть готовы (естественно, без использования такой опции) к взаимодействию с реализациями, которые такую опцию не поддерживают.

2.2    сетевое соединение (network connection): Структура, предоставляемая базовым транспортным протоколом, который используется MQTT.

-    подключает Клиента к Серверу:

-    предоставляет средства для отправки упорядоченного потока байтов в двух направлениях без потерь.

Примечание — Примеры приведены в подразделе 7.2.

2.3    сообщение приложения (application message): Данные, передаваемые протоколом MQTT по сети для приложения. При передаче сообщений с использованием протокола MQTT обеспечивается соответствующий уровень качества услуг передачи данных и указывается название темы.

2.4    клиент (client): Программа или устройство, использующее MQTT. Клиент всегда устанавливает сетевое подключение к Серверу. Клиент может:

-    опубликовать сообщения приложений, в которых могут быть заинтересованы другие Клиенты;

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

-    отменить подписку, чтобы удалить запрос на сообщения приложений;

-    отключиться от Сервера.

2.5    сервер (server): Программа или устройство, которое выступает в качестве посредника между Клиентами, которые публикуют сообщения приложений, и Клиентами, которые выполнили Подписки. Сервер может:

-    принимать сетевые подключения от Клиентов:

-    принимать сообщения приложений, публикуемые Клиентами;

-    обрабатывать запросы на подписку и отмену подписки от Клиентов;

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

2.6    подписка (subscription): Подписка включает фильтр по темам и максимальный уровень качества услуг передачи данных. Подписка связана с одним Сеансом. Сеанс может включать несколько Подписок. Каждая Подписка в рамках Сеанса имеет различные фильтры по темам.

2.7    название темы (topic name): Метка, прикрепленная к сообщению приложения, сопоставляемая с Подписками, известными Серверу. Сервер отправляет копию сообщения приложения каждому Клиенту, имеющему соответствующую Подписку.

2.8    фильтр по темам (topic filter): Выражение, содержащееся в подписке, определяющее интерес к сообщениям одной или нескольких тем. Фильтр темы может содержать подстановочные знаки.

2.9    сеанс (session): Межсетевое взаимодействие между Клиентом и Сервером с сохранением состояния. Некоторые Сеансы продолжаются только во время сетевого соединения, другие могут охватывать несколько последовательных сетевых соединений между Клиентом и Сервером.

2.10    управляющий пакет MQTT (MQTT control packet): Пакет информации, который отправляется через Сетевое подключение. Спецификация MQTT определяет четырнадцать различных типов управляющих пакетов, один из которых (пакет PUBLISH /ОПУБЛИКОВАТЬ/) используется для передачи сообщений приложений.

2.11    последняя воля (will): Механизм протокола MQTT, включающий специальное сообщение приложения и набор характеризующих его параметров, предназначенный для обработки ситуаций аварийного разрыва соединения между Клиентом и Сервером, которые могут возникать при:

-    ошибках ввода/вывода и отказов сети, обнаруженных Сервером,

-    превышениях времени ожидания Клиентом;

-    ошибках соблюдения протокола.

3    Обозначения и сокращения

3.1    Обозначения

3.1.1    [MQTT-x.x.x-y]: Обозначает положения настоящего стандарта, обязательные сточки зрения требований к протоколу MQTT, где х.х.х — номер раздела, у — порядковый номер положения в рамках раздела. Обозначение размещается непосредственно после первого появления соответствующего положения в тексте настоящего стандарта.

3.1.2    U+XXXX: Обозначает номер символа в кодировке UTF-8. где X — символ числа в 16-м исчислении (от 0 до F).

3.2    Сокращения

MQTT Клиент-серверный протокол передачи сообщений, основанный на модели «издатель — подписчик»

UTF-8    Формат преобразования Юникода, 8-бит

ASCII    7-битный кодированный набор символов

QoS    Качество предоставляемых услуг

TCP/IP Набор сетевых протоколов передачи данных

UDP    Протокол пользовательских датаграмм

TLS    Протокол защиты транспортного уровня

IANA    Администрация адресного пространства Интернет

SSL    Уровень защищенных сокетов

4    Представление данных

4.1    Бит

Биты в байте обозначены с 7 по 0. Бит номер 7 является самым значимым битом, наименее значащему биту присваивается номер 0.

4.2    Целочисленные значения данных

Целочисленные значения данных составляют 16 бит в обратном порядке байтов: старший байт предшествует младшему байту.

Это означает, что 16-битное слово представлено в сети как наиболее значащий байт (MSB), за которым следует наименее значащий байт (LSB).

4.3    Закодированные строки UTF-8

Текстовые поля в управляющих пакетах, описанных ниже, кодируются как строки UTF-8. UTF-8 (2) — эффективный метод кодирования символов Unicode (5), который оптимизирует кодовую таблицу ASCII для поддержки обмена текстовыми сообщениями.

Канщой из этих строк предшествует префикс длиной в два байта, который определяет количество байтов в самой кодированной строке UTF-8, как приведено в таблице 1. Следовательно, существует ограничение на размер строки, которая может быть передана в одном из этих кодированных компонентов UTF-8; невозможно передать строку размером более 65535 байт.

Если не указано иное, все кодированные строки UTF-8 могут иметь любую длину в диапазоне от 0 до 65535 байт.

Таблица 1 — Структура кодированных строк UTF-8

Бит

7 6 5 | 4 3 | 2 1 0

Байт 1

Длина строки MSB

Байт 2

Длина строки LSB

Байт 3...

Данные закодированного символа UTF-8, если длина > 0

Символьные данные в кодированной строке UTF-8 ДОЛЖНЫ быть правильно сформированы, как определено спецификацией Unicode (5) и подтверждено в RFC 3629 (2]. В частности, эти данные НЕ ДОЛЖНЫ включать кодовые точки между U+D800 и U+DFFF. Если Сервер или Клиент получает управляющий пакет, содержащий неправильно сформированный UTF-8. он ДОЛЖЕН прервать сетевое подключение [MQTT-4.5.3-1).

Закодированная строка UTF-8 НЕ ДОЛЖНА включать кодировку нулевого символа U+0000. Если получатель (Сервер или Клиент) получает управляющий пакет, содержащий U+0000, он ДОЛЖЕН прервать сетевое соединение (MQTT-4.5.3-2).

В данные НЕ СЛЕДУЕТ включать кодовые пункты Unicode [5], перечисленные ниже. Если получатель (Сервер или Клиент) получает управляющий пакет, содержащий любой из них, он МОЖЕТ прервать сетевое соединение:

-    управляющие символы U+0001 ..U+001F;

-    управляющие символы U+007F..U+009F;

-    кодовые точки, которые согласно спецификации Unicode (5) не являются символами (например. U+0FFFF).

Кодированная UTF-8 последовательность OxEF ОхВВ OxBF всегда должна интерпретироваться как U+FEFF («НЕРАЗРЫВНЫЙ ПРОБЕЛ С НУЛЕВОЙ ШИРИНОЙ»), где бы она ни появлялась в строке, и НЕ ДОЛЖНА быть пропущена или удалена получателем пакета (MQTT-1.5.3-3).

Пример — Строка А, которая представлена ЗАГЛАВНОЙ ЛАТИНСКОЙ БУКВОЙ А. за которой следует кодовая точка U*2A6D4 (представляющей ИДЕОГРАФИЧЕСКОЕ РАСШИРЕНИЕ CJK символ В), кодируется следующим образом, приведенным в таблице 2.

Таблица 2 — Пример строки 8 кодировке UTF-8

Бит

_I_1_!_1_!_1_1_1_2_1_£_1_1_

0

Байт 1

Длина строки MSB (0x00)

0

0

0

0

0

0

0

0

Байт 2

Длина строки LSB (0x05)

0

0

0

0

0

1

0

1

Байт 3

А(0x41)

0

1

0

0

0

0

0

1

Байт 4

(0xF0)

1

1

1

1

0

0

0

0

Байт 5

(ОхАА)

1

0

1

0

1

0

1

0

Байт 6

(0x9В)

1

0

0

1

1

0

1

1

Байт 7

(0x94)

1

0

0

1

0

1

0

0

5 Формат управляющего пакета MQTT

5.1 Структура управляющего пакета MQTT

Протокол MQTT работает, обмениваясь серией управляющих пакетов MQTT определенным образом. В данном разделе описывается формат таких пакетов.

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

Таблица 3 — Структура управляющего пакета MQTT

Части управляющего пакета MQTT

1

Фиксированный заголовок, присутствующий во всех пакетах управления MQTT

2

Переменный заголовок, присутствующий в некоторых пакетах управления MQTT

3

Полезная нагрузка, присутствующая в некоторых пакетах управления MQTT

5.2 Фиксированный заголовок

Каждый управляющий пакет MQTT содержит фиксированный заголовок. В таблице 4 приведен фиксированный формат заголовка.

Таблица 4 — Фиксированный формат заголовка

Бит

7 6 5 | 4

3 2 10

Байт 1

Тип управляющего пакета MQTT

Флаги, определенные для каждого типа управляющего пакета MQTT

Байт 2...

Остаток байтов

5.2.1 Тип управляющего пакета MQTT Позиция: байт 1. биты 7-4.

Знамения, представленные в виде 4-разрядной величины без знака, приведены в таблице 5.

Таблица 5 — Типы управляющих пакетов

Название

Значение

Направление потока

Описание

Зарезервировано

0

Запрещено

Зарезервировано

CONNECT

1

Клиент — Сервер

Запрос Клиента на подключение к Серверу

CONNACK

2

Сервер — Клиент

Подтверждение подключения

PUBLISH

3

Клиент — Сервер или Сервер — Клиент

Опубликовать сообщение

PUBACK

4

Клиент — Сервер или Сервер — Клиент

Подтверждение публикации

PUBREC

5

Клиент — Сервер или Сервер — Клиент

Получение публикации (часть1 механизма гарантированной поставки)

PUBREL

6

Клиент — Сервер или Сервер — Клиент

Сообщение для публикации отправлено (часть 2 механизма гарантированной поставки

PUBCOMP

7

Клиент — Сервер или Сервер — Клиент

Публикация сообщения окончена (часть 3 механизма гарантированной поставки)

SUBSCRIBE

8

Клиент — Сервер

Запрос подписки от Клиента

SUBACK

9

Сервер — Клиент

Подтверждение подписки

UNSUBSCRIBE

10

Клиент — Сервер

Запрос об отказе от подписки

UNSUBACK

11

Сервер — Клиент

Подтверждение отказа от подписки

PINGREQ

12

Клиент — Сервер

Запрос PING

PINGRESP

13

Сервер — Клиент

Ответ PING

DISCONNECT

14

Клиент — Сервер

Сообщение об отключении Клиента

Зарезервировано

15

Запрещено

Зарезервировано