ГОСТ Р 58603-2019 (ИСО/МЭК 20922:2016) Информационные технологии (ИТ). Интернет вещей. Протокол организации очередей доставки телеметрических сообщений MQTT. Версия 3.1.1
Приложение Б
(справочное)
Обязательные нормативные положения
Данное приложение предоставляется только в качестве справочного материала и является ненормативным. В таблице Б.1 приведен перечень заявлений о совместимости, содержащихся в основной части настоящего стандарта. Окончательный список требований к соответствию приведен в разделе 9.
Таблица Б.1 - Перечень нормативных положений о совместимости
Номер нормативного положения | Нормативное положение |
[MQTT-4.5.3-1] | Символьные данные в кодированной строке UTF-8 ДОЛЖНЫ быть правильно сформированными UTF-8, как определено спецификацией Unicode [5] и пересчитаны в RFC 3629 [2]. В частности, эти данные НЕ ДОЛЖНЫ включать кодировки кодовых точек между U+D800 и U+DFFF. Если Сервер или Клиент получает управляющий пакет, содержащий неправильно сформированный UTF-8, он ДОЛЖЕН прервать сетевое подключение |
[MQTT-4.5.3-2] | Закодированная строка UTF-8 НЕ ДОЛЖНА включать кодировку нулевого символа U+0000. Если получатель (Сервер или Клиент) получает управляющий пакет, содержащий U+0000, он ДОЛЖЕН прервать сетевое соединение |
[MQTT-4.5.3-3] | Кодированная последовательность UTF-8 0xEF 0хВВ 0xBF всегда должна интерпретироваться как означающая U+FEFF ("Нулевая ширина без пробела"), где бы она ни появлялась в строке, и НЕ ДОЛЖНА быть пропущена или отключена получателем пакетов |
[MQTT-5.2.2-1] | Если бит флага отмечен как "Зарезервировано" в таблице 5.2 - Биты флагов, он зарезервирован для будущего использования и ДОЛЖЕН быть установлен в значение, указанное в этой таблице |
[MQTT-5.2.2-2] | Если получены недопустимые флаги, получатель ДОЛЖЕН прервать сетевое соединение |
[MQTT-5.3.1-1] | SUBSCRIBE, UNSUBSCRIBE и PUBLISH (в случаях, когда QoS >0) управляющие пакеты ДОЛЖНЫ содержать ненулевой 16-разрядный идентификатор пакета |
[MQTT-5.3.1-2] | Каждый раз, когда Клиент отправляет новый пакет одного из этих типов, он ДОЛЖЕН назначить ему неиспользуемый в настоящее время пакетный идентификатор |
[MQTT-5.3.1-3] | Если Клиент повторно отправляет конкретный управляющий пакет, он ДОЛЖЕН использовать тот же идентификатор пакета в последующих повторных отправках этого пакета. Идентификатор пакета становится доступным для повторного использования после того, как Клиент обработал соответствующий пакет подтверждения. В случае QoS 1 PUBLISH это соответствующий PUBACK; в случае QoS 2 это PUBCOMP. Для SUBSCRIBE или UNSUBSCRIBE - это соответствующий SUBACK или UNSUBACK |
[MQTT-5.3.1-4] | Те же условия применяются к Серверу, когда он отправляет ОПУБЛИКОВАТЬ /PUBLISH/ с QoS >0 |
[MQTT-5.3.1-5] | Пакет PUBLISH НЕ ДОЛЖЕН содержать идентификатор пакета, если его значение QoS установлено на 0 |
[MQTT-5.3.1-6] | Пакет PUBACK, PUBREC или PUBREL ДОЛЖЕН содержать тот же идентификатор пакета, что и первоначально отправленный пакет PUBLISH |
[MQTT-5.3.1-7] | Аналогично SUBACK и UNSUBACK ДОЛЖНЫ содержать идентификатор пакета, который использовался в соответствующем пакете SUBSCRIBE и UNSUBSCRIBE, соответственно |
[MQTT-6.1.0-1] | После того как Клиент установил сетевое соединение с Сервером, первым пакетом, отправленным Клиентом на Сервер, ДОЛЖЕН быть пакет CONNECT |
[MQTT-6.1.0-2] | Сервер ДОЛЖЕН обработать второй пакет CONNECT, отправленный Клиентом, как нарушение протокола, и отключить Клиента |
[MQTT-6.1.2-1] | Если Имя протокола неверно, Сервер МОЖЕТ отключить Клиента, или МОЖЕТ продолжить обработку пакета CONNECT в соответствии с некоторыми другими спецификациями. В последнем случае Сервер НЕ ДОЛЖЕН продолжать обрабатывать пакет CONNECT в соответствии с настоящей спецификацией |
[MQTT-6.1.2-2] | Сервер ДОЛЖЕН реагировать на пакет CONNECT передачей кода CONNACK 0x01 (неприемлемый уровень протокола), а затем отключает Клиента, если уровень протокола не поддерживается Сервером |
[MQTT-6.1.2-3] | Сервер ДОЛЖЕН подтвердить, что зарезервированный флаг в пакете управления CONNECT установлен на ноль и прервать соединение с Клиентом, если значение не равно нулю |
[MQTT-6.1.2-4] | Если для параметра "Очистить сеанс" установлено значение "0", Сервер ДОЛЖЕН возобновить обмен данными с Клиентом на основе состояния с текущего сеанса (как определено идентификатором Клиента). Если сеанс не связан с идентификатором Клиента, Сервер ДОЛЖЕН создать новый сеанс. Клиент и Сервер ДОЛЖНЫ сохранять сеанс после разъединения Клиента и Сервера |
[MQTT-6.1.2-5] | После отключения Сеанса, по которому параметром "Очистить сеанс" установлен на 0, Сервер ДОЛЖЕН сохранить дополнительные сообщения QoS 1 и QoS 2, соответствующие любым подпискам, которые существовали у Клиента во время отключения в составе состояния Сеанса |
[MQTT-6.1.2-6] | Если для параметра "Очистить сеанс" установлено значение 1, Клиент и Сервер ДОЛЖНЫ отменить предыдущий Сеанс и запустить новый. Этот Сеанс длится до тех пор, пока существует сетевое подключение. Данные состояния, связанные с этим Сеансом, НЕ ДОЛЖНЫ повторно использоваться в любой последующей сессии |
[MQTT-6.1.2.7] | Сохраненные сообщения не являются частью состояния Сеанса на Сервере, они НЕ ДОЛЖНЫ удаляться, когда Сеанс заканчивается |
[MQTT-6.1.2-8] | Если флаг дальнейших действий установлен на 1, это означает, что, если запрос о соединении принят, Сообщение о дальнейших действиях ДОЛЖНО храниться на Сервере и связано с сетевым подключением. Сообщение о дальнейших действиях ДОЛЖНО быть опубликовано, когда Сетевое подключение будет закрыто, если сообщение не было удалено Сервером при получении пакета DISCONNECT |
[MQTT-6.1.2-9] | Если флаг дальнейших действий установлен на 1, поля будущего QoS и будущего сохранения в флагах CONNECT будут использоваться Сервером, а поля будущей темы и сообщение о дальнейших действиях ДОЛЖНЫ присутствовать в полезной нагрузке |
[MQTT-6.1.2-10] | Сообщение о дальнейших действиях ДОЛЖНО быть удалено из сохраненного состояния Сеанса на Сервере после его публикации, или, когда Сервер получил от Клиента пакет DISCONNECT |
[MQTT-6.1.2-11] | Если флаг дальнейших действий установлен на 0, значения полей QoS и будущего сохранения должны быть установлены равными нулю, а поля будущая тема и сообщение о дальнейших действиях НЕ ДОЛЖНЫ присутствовать в полезной нагрузке |
[MQTT-6.1.2-12] | Если флаг дальнейших действий установлен на 0, сообщение о дальнейших действиях НЕ ДОЛЖНО публиковаться при завершении этого сетевого подключения |
[MQTT-6.1.2-13] | Если флаг дальнейших действий установлен на 0, то будущий QoS ДОЛЖНО быть установлено на 0 (0x00) |
[MQTT-6.1.2-14] | Если флаг дальнейших действий установлен на 1, значение будущего QoS может быть 0 (0x00), 1 (0x01) или 2 (0x02). Значение НЕ ДОЛЖНО быть установлено на 3 (0x03) |
[MQTT-6.1.2-15] | Если флаг дальнейших действий установлен на 0, то флаг будущего сохранения ДОЛЖЕН быть установлен на 0 |
[MQTT-6.1.2-16] | Если для будущего сохранения установлено значение 0, Сервер ДОЛЖЕН публиковать сообщение о дальнейших действиях как не сохраненное сообщение |
[MQTT-6.1.2-17] | Если для будущего сохранения установлено значение 1, Сервер ДОЛЖЕН публиковать сообщение о дальнейших действиях как сохраненное сообщение |
[MQTT-6.1.2-18] | Если параметр флага с именем пользователя установлен на 0, имя пользователя НЕ ДОЛЖНО присутствовать в полезной нагрузке |
[MQTT-6.1.2-19] | Если параметр флага с именем пользователя установлен на 1, имя пользователя ДОЛЖНО присутствовать в полезной нагрузке |
[MQTT-6.1.2-20] | Если флаг пароля установлен на 0, пароль НЕ ДОЛЖЕН присутствовать в полезной нагрузке |
[MQTT-6.1.2-21] | Если флаг пароля установлен на 1, пароль ДОЛЖЕН присутствовать в полезной нагрузке |
[MQTT-6.1.2-22] | Если параметр флага с именем пользователя установлен на 0, флаг пароля ДОЛЖЕН быть установлен на 0 |
[MQTT-6.1.2-23] | Клиент несет ответственность за то, чтобы промежуток между отправляемыми управляющими пакетами не превышал значение активного соединения. В случае отсутствия отправки каких-либо других управляющих пакетов Клиент ДОЛЖЕН отправить пакет PINGREQ |
[MQTT-6.1.2-24] | Если значение активного соединения не равно нулю, и Сервер не получает контрольный пакет от Клиента в течение полутора интервалов периода активного соединения, он ДОЛЖЕН прервать сетевое подключение с Клиентом, как если бы произошел сбой сети |
[MQTT-6.1.3-1] | Полезная нагрузка пакета CONNECT содержит одно или несколько полей с префиксом длины, наличие которых определяется флагами в заголовке переменной. Эти поля, если они есть, ДОЛЖНЫ появляться в порядке: идентификатора Клиента, будущая тема, сообщение о дальнейших действиях, Имя пользователя, пароль |
[MQTT-6.1.3-2] | Каждый Клиент, подключающийся к Серверу, имеет уникальный Clientld. Идентификатор Клиента ДОЛЖЕН использоваться Клиентами и Серверами для определения их состояния в отношении этого сеанса MQTT между Клиентом и Сервером |
[MQTT-6.1.3-3] | Идентификатор Клиента (Clientld) ДОЛЖЕН присутствовать и ДОЛЖЕН быть первым полем в полезной нагрузке пакета CONNECT |
[MQTT-6.1.3-4] | Clientld ДОЛЖЕН быть кодированной строкой UTF-8, как определено в пункте 4.5.3 [MQTT-6.1.3-4]. |
[MQTT-6.1.3-6] | Сервер МОЖЕТ позволить Клиенту предоставить Clientld, длина которого равна нулю, однако, если он делает это, Сервер ДОЛЖЕН рассматривать это как особый случай и назначить уникальный Clientld для этого Клиента. Он ДОЛЖЕН обрабатывать пакет CONNECT, как если бы Клиент предоставил уникальный Clientld |
[MQTT-6.1.3-7] | Если Клиент отправляет Clientld с нулевым байтом, Клиент ДОЛЖЕН также установить "Очистить сеанс" на 1 |
[MQTT-6.1.3-8] | Если Клиент отправляет Clientld с нулевым байтом, с установленным значением "Очистить сеанс" равным 0, Сервер ДОЛЖЕН отвечать на пакет CONNECT кодом возврата CONNACK 0x02 (отклонение идентификатора), а затем прервать сетевое соединение |
[MQTT-6.1.3-9] | Если Сервер отклоняет Clientld, он ДОЛЖЕН отвечать на пакет CONNECT кодом возврата CONNACK 0x02 (идентификатор отклонен), а затем прервать сетевое соединение |
[MQTT-6.1.3-10] | Если флаг дальнейших действий установлен на 1, будущая тема будет следующим полем в полезной нагрузке. Будущая тема ДОЛЖНА быть кодированной строкой UTF-8, как определено в пункте 4.5.3 |
[MQTT-6.1.3-11] | Имя пользователя ДОЛЖНО быть кодированной строкой UTF-8, как определено в пункте 4.5.3 |
[MQTT-6.1.4-1] | Сервер ДОЛЖЕН подтвердить, что пакет CONNECT соответствует Разделу 6.1, и прервать сетевое соединение, не отправляя CONNACK, если он не соответствует |
[MQTT-6.1.4-2] | Если Clientld представляет Клиента, уже подключенного к Серверу, Сервер ДОЛЖЕН отключить существующего Клиента |
[MQTT-6.1.4-3] | Сервер ДОЛЖЕН выполнить обработку "Очистить сеанс", описанного в подпункте 6.1.2.4 |
[MQTT-6.1.4-4] | Сервер ДОЛЖЕН подтвердить пакет CONNECT с помощью пакета CONNACK, содержащего нулевой код возврата |
[MQTT-6.1.4-5] | Если Сервер отклоняет CONNECT, он НЕ ДОЛЖЕН обрабатывать любые данные, отправленные Клиентом после пакета CONNECT |
[MQTT-6.2.0-1] | Первый пакет, отправленный с Сервера Клиенту, ДОЛЖЕН быть пакетом CONNACK |
[MQTT-6.2.2-1] | Если Сервер принимает соединение с установкой параметра "Очистить сеанс" на 1, Сервер ДОЛЖЕН установить текущий сеанс на 0 в пакете CONNACK в дополнение к установке нулевого кода возврата в пакете CONNACK |
[MQTT-6.2.2-2] | Если Сервер принимает соединение с установкой параметра "Очистить сеанс" на 0, значение, установленное для текущего сеанса, зависит от того, сохранил ли Сервер состояние сеанса для предоставленного идентификатора Клиента. |
[MQTT-6.2.2-3] | Если Сервер не сохранил состояние Сеанса, он ДОЛЖЕН установить текущий сеанс на 0 в пакете CONNACK. Это дополнительно к установке нулевого кода возврата в пакете CONNACK |
[MQTT-6.2.2-4] | Если Сервер отправляет пакет CONNACK, содержащий ненулевой код возврата, он ДОЛЖЕН установить текущий сеанс на 0 |
[MQTT-6.2.2-5] | Если Сервер отправляет пакет CONNACK, содержащий ненулевой код возврата, он ДОЛЖЕН затем прервать сетевое соединение |
[MQTT-6.2.2-6] | Если ни один из кодов возврата, перечисленных в таблице 6.1 - Значения кода возврата соединения, не считается применимым, тогда Сервер ДОЛЖЕН закрыть сетевое соединение, не отправляя пакет CONNACK |
[MQTT-6.3.1-1] | Флаг DUP ДОЛЖЕН быть установлен на 1 Клиентом или Сервером, когда он пытается повторно отправить пакет PUBLISH |
[MQTT-6.3.1-2] | Флаг DUP ДОЛЖЕН быть установлен на 0 для всех сообщений QoS 0 |
[MQTT-6.3.1-3] | Значение флага DUP из входящего пакета PUBLISH не распространяется, когда пакет PUBLISH отправляется подписчикам Сервером. Флаг DUP в исходящем пакете PUBLISH устанавливается независимо от входящего пакета PUBLISH, его значение ДОЛЖНО быть определено только исходя из того, является ли исходящий пакет PUBLISH повторной передачей |
[MQTT-6.3.1-4] | Пакет PUBLISH НЕ ДОЛЖЕН иметь оба бита QoS, установленные на 1. Если Сервер или Клиент получает пакет PUBLISH, у которого оба бита QoS установлены на 1, он ДОЛЖЕН прервать сетевое подключение |
[MQTT-6.3.1-5] | Если флаг RETAIN установлен на 1, в пакете PUBLISH, отправленном Клиентом на Сервер, Сервер ДОЛЖЕН хранить сообщение приложения и его QoS, чтобы он мог доставляться будущим подписчикам, подписки которых соответствуют их названию темы |
[MQTT-6.3.1-6] | Когда установлена новая подписка, последнее сообщение с сохранением, если оно есть, по каждому имени соответствующего типа ДОЛЖНО быть отправлено подписчику |
[MQTT-6.3.1-7] | Если Сервер получает сообщение QoS 0 с флагом RETAIN, установленным на 1, он ДОЛЖЕН отменить любое сообщение, ранее сохраненное для этой темы. СЛЕДУЕТ сохранить новое сообщение QoS 0 в качестве нового сохраненного сообщения для этой темы, но МОЖНО отказаться от него в любое время - если это произойдет, для этого раздела не будет сохраненного сообщения |
[MQTT-6.3.1-8] | При отправке пакета PUBLISH Клиенту Сервер ДОЛЖЕН установить флаг RETAIN на 1, если сообщение отправлено в результате новой подписки, сделанной Клиентом |
[MQTT-6.3.1-9] | Он ДОЛЖЕН установить флаг RETAIN на 0, когда пакет PUBLISH отправляется Клиенту, поскольку он соответствует установленной подписке, независимо от того, как был установлен флаг в полученном сообщении |
[MQTT-6.3.1-10] | Пакет PUBLISH с флагом RETAIN, установленным на 1, и полезная нагрузка, содержащая нулевые байты, будет обрабатываться как обычно Сервером и отправляться Клиентам с подпиской, соответствующей названию темы. Кроме того, любое существующее сохраненное сообщение с тем же именем темы ДОЛЖНО быть удалено, и любые будущие подписчики для темы не получат сохраненное сообщение |
[MQTT-6.3.1-11] | Сохраненное сообщение с нулевым байтом НЕ ДОЛЖНО храниться как сохраненное сообщение на Сервере |
[MQTT-6.3.1-12] | Если флаг RETAIN равен 0, в пакете PUBLISH, отправленном Клиентом на Сервер, Сервер НЕ ДОЛЖЕН хранить это сообщение и НЕ ДОЛЖЕН удалять или заменять существующее сохраненное сообщение |
[MQTT-6.3.2-1] | Название темы ДОЛЖНО присутствовать в качестве первого поля в заголовке пакета PUBLISH. Он ДОЛЖЕН быть кодированной кодировкой UTF-8 |
[MQTT-6.3.2-2] | Название темы в пакете PUBLISH НЕ ДОЛЖНО содержать подстановочных знаков |
[MQTT-6.3.2-3] | Название темы в пакете PUBLISH, отправленное Сервером Клиенту-подписчику, должно соответствовать фильтру темы подписки в соответствии с процессом сопоставления, определенным в Разделе 4.7 |
[MQTT-6.3.4-1] | Получатель пакета PUBLISH ДОЛЖЕН отвечать в соответствии с таблицей 6.4 - Ожидаемый ответ пакета PUBLISH, как определено QoS в пакете PUBLISH |
[MQTT-6.3.5-1] | Сервер ДОЛЖЕН доставлять сообщение Клиенту в соответствии с максимальным QoS всех соответствующих подписок |
[MQTT-6.3.5-2] | Если реализация Сервера не разрешает Клиенту выполнять пакет PUBLISH; он не может сообщить об этом Клиенту. Он ДОЛЖЕН сделать положительное подтверждение в соответствии с обычными правилами QoS или прервать сетевое соединение |
[MQTT-6.6.1-1] | Биты 3, 2, 1 и 0 фиксированного заголовка в пакете управления PUBREL зарезервированы и ДОЛЖНЫ быть установлены на 0, 0, 1 и 0 соответственно. Сервер ДОЛЖЕН считать любое другое значение искаженным, и прервать сетевое соединение |
[MQTT-6.8.1-1] | Биты 3, 2, 1 и 0 фиксированного заголовка управляющего пакета SUBSCRIBE зарезервированы и ДОЛЖНЫ быть установлены на 0, 0, 1 и 0 соответственно. Сервер ДОЛЖЕН считать любое другое значение искаженным и прервать сетевое соединение |
[MQTT-6.8.3-1] | Фильтры тем в полезной нагрузке пакета SUBSCRIBE ДОЛЖНЫ быть закодированными UTF-8 строками, как определено в Разделе 4.5.3 |
[MQTT-6.8.3-2] | Если он предпочитает не поддерживать фильтры тем, которые содержат подстановочные знаки, он ДОЛЖЕН отклонить любой запрос на подписку, фильтр которого их содержит |
[MQTT-6.8.3-3] | Полезная нагрузка пакета SUBSCRIBE ДОЛЖНА содержать по меньшей мере один фильтр тем/пару QoS. Пакет SUBSCRIBE без полезной нагрузки является нарушением протокола |
[MQTT-6.8.3-4] | Сервер ДОЛЖЕН считать пакет SUBSCRIBE искаженным и прервать сетевое соединение, если любой из зарезервированных битов в полезной нагрузке отличен от нуля, или QoS не равно 0, 1 или 2 |
[MQTT-6.8.4-1] | Когда Сервер получает пакет SUBSCRIBE от Клиента, Сервер ДОЛЖЕН отвечать с пакетом SUBACK |
[MQTT-6.8.4-2] | Пакет SUBACK ДОЛЖЕН иметь тот же идентификатор пакета, что и пакет SUBSCRIBE, который он подтверждает |
[MQTT-6.8.4-3] | Если Сервер получает пакет SUBSCRIBE, содержащий фильтр тем, который идентичен существующему фильтру тем Подписки, он ДОЛЖЕН полностью заменить существующую Подписку новой Подпиской. Фильтр темы в новой Подписке будет идентичен фильтру темы в предыдущей Подписке, хотя его максимальное значение QoS может отличаться. Любые существующие сохраненные сообщения, соответствующие фильтру темы, ДОЛЖНЫ быть повторно отправлены, но поток публикаций НЕ ДОЛЖЕН прерываться |
[MQTT-6.8.4-4] | Если Сервер получает пакет SUBSCRIBE, который содержит несколько фильтров тем, он ДОЛЖЕН обрабатывать этот пакет, как если бы он получил последовательность из нескольких пакетов SUBSCRIBE, за исключением того, что он объединяет их ответы в один ответ SUBACK |
[MQTT-6.8.4-5] | Пакет SUBACK, отправленный Сервером Клиенту, ДОЛЖЕН содержать код возврата для каждого фильтра тем/пары QoS. Этот код возврата ДОЛЖЕН показать максимальное QoS, которое было предоставлено для этой Подписки, или указать на сбой подписки |
[MQTT-6.8.4-6] | Сервер может предоставить более низкий максимальный QoS, чем запросил подписчик. QoS сообщений полезной нагрузки, отправленных в ответ на подписку, ДОЛЖНЫ быть минимальным QoS изначально опубликованного сообщения и максимального QoS, предоставленного Сервером. Серверу разрешено отправлять дубликаты копий сообщения подписчику в случае, когда исходное сообщение было опубликовано с QoS 1, а максимальным предоставленным QoS был QoS 0 |
[MQTT-6.9.3-1] | Порядок кодов возврата в пакете SUBACK ДОЛЖЕН соответствовать порядку фильтров тем в пакете SUBSCRIBE |
[MQTT-6.9.3-2] | Коды возврата SUBACK, отличные от 0x00, 0x01, 0x02 и 0x80, зарезервированы и НЕ ДОЛЖНЫ использоваться |
[MQTT-6.10.1-1] | Биты 3, 2, 1 и 0 фиксированного заголовка управляющего пакета UNSUBSCRIBE зарезервированы и ДОЛЖНЫ быть установлены на 0, 0, 1 и 0 соответственно. Сервер ДОЛЖЕН обрабатывать любое другое значение как искаженное и закрывать сетевое соединение |
[MQTT-6.10.3-1] | Фильтры тем в пакете UNSUBSCRIBE ДОЛЖНЫ быть закодированными строками UTF-8, как определено в разделе 4.5.3, формируя непрерывный пакет |
[MQTT-6.10.3-2] | Фильтры тем в пакете UNSUBSCRIBE ДОЛЖНЫ быть закодированными строками UTF-8, как определено в пункте 4.5.3, формируя непрерывный пакет |
[MQTT-6.10.4-1] | Фильтры тем (независимо от того, содержат ли они подстановочные знаки или нет), поставляемые в пакете UNSUBSCRIBE, ДОЛЖНЫ сравниваться по каждому символу с текущим набором фильтров тем, хранящихся на Сервере для Клиента. Если какой-либо фильтр точно соответствует, то его собственная Подписка удаляется, в противном случае никакой дополнительной обработки не происходит |
[MQTT-6.10.4-2] | Если Сервер удаляет подписку, он ДОЛЖЕН завершить поставку любых сообщений QoS 1 или QoS 2, которые он начал отправлять Клиенту |
[MQTT-6.10.4-3] | Если Сервер удаляет подписку, он ДОЛЖЕН прекратить добавлять новые сообщения для доставки Клиенту |
[MQTT-6.10.4-4] | Сервер ДОЛЖЕН отвечать на запрос UNSUBCRIBE, отправив пакет UNSUBACK. Пакет UNSUBACK ДОЛЖЕН иметь тот же идентификатор пакета, что и пакет UNSUBSCRIBE |
[MQTT-6.10.4-5] | Даже если никакие Подписки на темы не удалены, Сервер ДОЛЖЕН отправить UNSUBACK |
[MQTT-6.10.4-6] | Если Сервер получает пакет UNSUBSCRIBE, содержащий несколько фильтров тем, он ДОЛЖЕН обрабатывать этот пакет, как если бы он получил последовательность из нескольких пакетов UNSUBSCRIBE, за исключением того, что он отправляет только один ответ UNSUBACK |
[MQTT-6.12.4-1] | Сервер ДОЛЖЕН отправить пакет PINGRESP в ответ на пакет PINGREQ |
[МQTT-6.14.1-1] | Сервер ДОЛЖЕН проверить, чтобы зарезервированные биты были установлены на ноль, и прервать соединение с Клиентом, если они не равны нулю |
[MQTT-6.14.4-1] | После отправки пакета DISCONNECT Клиент ДОЛЖЕН прервать сетевое соединение |
[MQTT-6.14.4-2] | После отправки пакета DISCONNECT Клиент НЕ ДОЛЖЕН отправлять больше управляющих пакетов этим сетевым подключением |
[MQTT-6.14.4-3] | При получении DISCONNECT Сервер ДОЛЖЕН отменить любое сообщение, связанное с текущим подключением, без его публикации, как описано в разделе 6.1.2.5 |
[MQTT-7.1.0-1] | Клиент и Сервер ДОЛЖНЫ сохранять состояние сеанса на протяжении всего сеанса |
[MQTT-7.1.0-2] | Сеанс ДОЛЖЕН длиться как минимум до тех пор, пока есть активное сетевое соединение |
[MQTT-7.3.1-1] | В протоколе доставки QoS 0 отправитель: |
[MQTT-7.3.2-1] | В протоколе доставки QoS 1 отправитель ДОЛЖЕН: |
[MQTT-7.3.2-2] | В протоколе доставки QoS 1 получатель ДОЛЖЕН: |
[MQTT-7.3.3-1] | В протоколе доставки QoS 2 отправитель: |
[MQTT-7.3.3-2] | В протоколе доставки QoS 2 получатель ДОЛЖЕН: |
[MQTT-7.4.0-1] | Когда Клиент повторно подключается к параметру "Очистить сеанс", установленному на 0, Клиент и Сервер ДОЛЖНЫ повторно отправлять любые неподтвержденные пакеты PUBLISH (где QoS>0) и пакеты PUBREL с использованием их исходных идентификаторов пакетов |
[MQTT-7.5.0-1] | Когда Сервер получает право собственности на входящее сообщение приложения, он ДОЛЖЕН добавить его в состояние сеанса для тех Клиентов, которые имеют соответствующие Подписки. Правила соответствия определены в разделе 7.7 |
[MQTT-7.5.0-2] | Клиент ДОЛЖЕН подтвердить, что любой опубликованный пакет, который он получает в соответствии с применимыми правилами QoS, независимо от того, выбирает ли он обработку сообщения приложения о том, что оно содержит |
[MQTT-7.6.0-1] | Когда он повторно отправляет какие-либо пакеты PUBLISH, он ДОЛЖЕН повторно отправить их в том порядке, в котором были отправлены исходные пакеты PUBLISH (это относится к сообщениям QoS 1 и QoS 2) |
[MQTT-7.6.0-2] | Клиент ДОЛЖЕН отправлять пакеты PUBACK в том порядке, в котором были получены соответствующие пакеты PUBLISH (сообщения QoS 1) |
[MQTT-7.6.0-3] | Клиент ДОЛЖЕН отправлять пакеты PUBREC в том порядке, в котором были получены соответствующие пакеты PUBLISH (сообщения QoS 2) |
[MQTT-7.6.0-4] | Клиент ДОЛЖЕН отправлять пакеты PUBREL в том порядке, в котором были получены соответствующие пакеты PUBREC (сообщения QoS 2) |
[MQTT-7.6.0-5] | Сервер ДОЛЖЕН по умолчанию рассматривать каждую тему как "упорядоченную тему". Он МОЖЕТ предоставить административный или иной механизм, позволяющий рассматривать одну или несколько тем как "неупорядоченную тему" |
[MQTT-7.6.0-6] | Когда Сервер обрабатывает сообщение, опубликованное в упорядоченной теме, он ДОЛЖЕН следовать приведенным выше правилам при доставке сообщений каждому из своих подписчиков. Кроме того, он ДОЛЖЕН отправлять пакеты PUBLISH Клиентам (по той же теме и QoS) в том порядке, в котором они были получены от любого указанного Клиента |
[MQTT-7.7.1-1] | Символы подстановки могут использоваться в фильтрах тем, но НЕ ДОЛЖНЫ использоваться в названии темы |
[MQTT-7.7.1-2] | Многоуровневый подстановочный знак ДОЛЖЕН быть указан либо самостоятельно, либо после разделителя тематических уровней. |
[MQTT-7.7.1-3] | Одноуровневый шаблон можно использовать на любом уровне фильтра тем, включая первый и последний уровни. Если он используется, он ДОЛЖЕН занимать весь уровень фильтра |
[MQTT-7.7.2-1] | Сервер НЕ ДОЛЖЕН соединять фильтры тем, которые начинаются с символа подстановки (# или +) с названиями тем, начинающимися с символа $ |
[MQTT-7.7.3-1] | Все названия тем и фильтры тем ДОЛЖНЫ иметь как минимум один символ |
[MQTT-7.7.3-2] | Название темы и фильтры тем НЕ ДОЛЖНЫ включать нулевой символ (Unicode U + 0000) |
[MQTT-7.7.3-3] | Название темы и фильтры темы - это кодированные строки UTF-8, они НЕ ДОЛЖНЫ кодировать более 65535 байт |
[MQTT-7.7.3-4] | Когда выполняется соединение в соответствии с подпиской Сервер НЕ ДОЛЖЕН выполнять какую-либо стандартизацию названий тем или фильтров тем, а также любую модификацию или замену непризнанных символов |
[MQTT-7.8.0-1] | Если не указано иное, если Сервер или Клиент сталкиваются с нарушением протокола, они ДОЛЖНЫ закрыть сетевое соединение, на которое получен такой управляющий пакет, который вызвал нарушение протокола |
[MQTT-7.8.0-2] | Если Клиент или Сервер обнаруживают несистематическую ошибку при обработке входящего управляющего пакета, они ДОЛЖНЫ закрыть сетевое соединение, на которое получен такой управляющий пакет |
[MQTT-8.0.0-1] | Управляющие пакеты MQTT ДОЛЖНЫ быть отправлены в бинарные пакеты данных WebSocket. Если получен какой-либо другой тип пакета данных, получатель ДОЛЖЕН прервать сетевое соединение |
[MQTT-8.0.0-2] | Один пакет данных WebSocket может содержать множественные или частичные управляющие пакеты MQTT. Получатель НЕ ДОЛЖЕН предполагать, что управляющие пакеты MQTT соответствуют рамкам пакета данных WebSocket |
[MQTT-8.0.0-3] | Клиент ДОЛЖЕН включать "mqtt" в список суб-протоколов WebSocket, который он предлагает |
[MQTT-8.0.0-4] | Имя суб-протокола WebSocket, выбранное и возвращаемое Сервером, должно быть "mqtt" |
[MQTT-9.0.0-1] | Сервер, который принимает входящие подключения и устанавливает исходящие подключения к другим Серверам, ДОЛЖЕН соответствовать как Клиенту MQTT, так и Серверу MQTT |
[MQTT-9.0.0-2] | Соответствующие реализации НЕ ДОЛЖНЫ требовать использования каких-либо расширений, определенных вне этой спецификации, чтобы взаимодействовать с любой другой совместимой реализацией |
[MQTT-9.1.1-1] | Соответствующий Сервер ДОЛЖЕН поддерживать использование одного или нескольких базовых транспортных протоколов, которые обеспечивают упорядоченный, не допускающий потерь поток байтов от Клиента к Серверу и от Сервера к Клиенту |
[MQTT-9.1.2-1] | Соответствующий Клиент ДОЛЖЕН поддерживать использование одного или нескольких базовых транспортных протоколов, которые обеспечивают упорядоченный, не допускающий потерь поток байтов от Клиента к Серверу и от Сервера к Клиенту |