Summary

  • Проект рабочей группы CoRE, версия 22, обновлённый 2 ноября 2026 года, предлагает брокер CoAP для клиентов, которые надолго теряют связь. Издатели отправляют PUT, подписчики наблюдают ресурс данных или читают его последнюю версию. Документ ещё проходит оценку IESG.
  • Раздел 3.3 определяет запрос последней опубликованной версии. Доступ к предыдущим версиям и число хранимых записей оставлены возможной будущей спецификации.
  • Наличие темы, принятие публикации и действующая подписка — разные состояния. Успешный код ответа без опции Observe не подтверждает подписку.

Представим датчик на промышленной площадке. В полдень он сообщает превышение температуры, через час — норму. Пульт технической службы этот час был отключён. После возвращения пульт получает у брокера нормальное последнее значение. Теперь всё действительно нормально; о том, что случилось между двумя соединениями, эта цифра молчит. Сценарий придуман для проверки пределов проекта, а не взят из отчёта о конкретной аварии.

Проект IETF описывает брокер, который держит коллекции тем. У каждой темы есть ресурс настройки и отдельный ресурс данных. Издатель отправляет PUT на URI данных. Подписчик посылает туда GET с Observe: 0 по механизму RFC 7641 и затем получает изменения. Простой GET возвращает текущую версию. URI темы и URI её данных могут не иметь общей структуры; адрес данных берётся из свойства topic-data. Устройства могут размыкать соединение, а брокер остаётся точкой встречи для состояния.

Что именно отсутствует

После создания темы ресурс данных уже существует, но первой публикации ещё не было. Для этого проект использует предлагаемый ответ 2.06 No Content. Если ресурса вообще нет, обычно приходит 4.04 Not Found. Если издатель отправил значение, GET выдаёт последнее. На панели эти ответы легко покрасить одинаковым серым цветом. Тогда пустая новая тема, удалённая тема и тема с текущим значением теряют свои различия.

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

Есть ещё граница между ответом и подпиской. При Observe: 0 ответ 2.05 Content с опцией Observe приносит текущие данные и подтверждает наблюдение. Пустая тема может ответить 2.06 No Content с Observe, а первую публикацию прислать позже. Если Observe нет, клиент должен считать подписку неуспешной, даже когда код ответа выглядит успешным. Достигнув лимита max-subscribers, брокер опцию не добавляет. Программа, проверяющая только 2.05, объявит включённый контроль там, где его нет.

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

Квитанция брокера не доказывает доставку

Успешный PUT обычно получает 2.04 Changed по модели запросов CoAP из RFC 7252. Брокер принял обновление. Это не квитанция от каждого подписчика и не запись о выполненной команде приложения. При слишком высокой скорости отправки возможен ответ 4.29 Too Many Requests; значение Max-Age указывает паузу до повтора. Отправленные, отклонённые и принятые публикации должны различаться в журнале.

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

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

Проект CoRE pubsub · RFC 7641 · RFC 7252