Кратко

  • Observe поддерживает у клиента актуальное представление ресурса CoAP по модели best effort и eventual consistency, но не гарантирует получение каждого промежуточного состояния.
  • 24-битное сравнение, условие 128 секунд и Max-Age определяют свежесть и порядок; они не дают долговечной очереди, смещений или повторного чтения истории.
  • После перезапуска ответственной системе нужны явные доказательства повторной регистрации, текущего представления и известных пробелов; для полной истории требуется отдельный журнал или очередь.

Отношение создается одним GET

Клиент посылает GET с Observe=0 и выбранным Token. Если успешный ответ 2.xx тоже содержит Observe, сервер создал запись наблюдателя, связанную с конечной точкой и Token. Следующие уведомления — дополнительные ответы на исходный запрос. Если сервер не может или не хочет хранить запись, он вправе ответить как на обычный GET без Observe. Клиент понимает, что изменений не будет и нужен опрос.

Так неизменный датчик не заставляет батарейное устройство и узкий канал повторять одинаковые запросы. Кэши и прокси могут участвовать, а несколько клиентов — разделить одну регистрацию вверх по цепочке. RFC при этом прямо не претендует на замену более общих publish/subscribe-систем.

Доставка остается best effort. Цель — eventual consistency: если ресурс перестал меняться, зарегистрированные наблюдатели в итоге получают текущее представление. При перегрузке или слишком частых изменениях сервер может пропустить сколько угодно промежуточных состояний. Сохранить настоящее и сохранить историю — разные задачи.

Малое поле требует строгого сравнения

Уведомление повторяет Token и несет Observe. Сервер использует младшие 24 бита строго возрастающей последовательности. Клиент применяет серийную арифметику, чтобы малое значение после оборота считалось новее большого значения до оборота.

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

Последовательность также не должна проходить больше половины 24-битного пространства менее чем за 256 секунд. Это защищает порядок, но не описывает восстановление после рестарта. Сохранился ли счетчик, Token, список наблюдателей и кэш — отдельные факты реализации.

Max-Age превращает текущее в неизвестное

Max-Age показывает, как долго допустимо расхождение наблюдаемого и реального состояния. Когда возраст больше, клиент не вправе считать представление текущим. Он может обновить его или повторно зарегистрироваться с тем же Token.

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

ACK подтверждает только приход конкретного confirmable-сообщения CoAP. Уведомления могут быть confirmable или non-confirmable независимо от первоначального запроса. Подтверждение одного пакета не восстанавливает состояния, которые сервер имел право не отправлять.

Отмена тоже имеет распределенное состояние

Клиент может забыть наблюдение и позднее ответить Reset на confirmable-уведомление с неизвестным Token. Либо он отправляет GET с прежним Token и Observe=1. Reset или запрос отмены могут потеряться, поэтому сервер некоторое время сохраняет запись после локального завершения у клиента.

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

Прокси восстанавливает собственную картину

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

Это не обвинение в нарушении стандарта. Это граница доказательств. Журнал должен различать уведомление источника, кэш-валидацию, обновление и новую регистрацию, иначе восстановление выглядит как непрерывная история, которой не было.