Кратко

  • RFC 3082 позволяет пользовательскому агенту подписаться на изменения служб вместо постоянных запросов; путь уведомлений различается в сетях с Directory Agent и без него.
  • Если DA исчезает, уже извещённые агенты служб могут продолжать отправку, но новый агент может не узнать о подписке. Продолжение старых уведомлений не доказывает, что новые службы остались в зоне охвата.

Запрос — это не поток событий

В основе Service Location Protocol лежала работа по требованию: агенты служб (SA) объявляли услуги, а пользовательские агенты (UA) запрашивали их при необходимости. Приложению, которое хотело видеть каждое появление или исчезновение службы сразу, приходилось периодически опрашивать сеть. Опубликованный в марте 2001 года RFC 3082 предлагал уведомлять клиентов об изменениях и отказаться от повторных запросов. Это экспериментальный протокол, а не Интернет-стандарт.

Переход от запросов к подписке выглядит простым, пока не появляется новый SA: кто сообщит ему, что UA уже слушает? RFC 3082 даёт разные ответы для небольшой сети без Directory Agent (DA) и сети с DA. Состояние подписки в этих вариантах хранится по-разному.

Две топологии — две цены

В небольшой сети без DA агенты SA широко рассылают регистрацию и снятие регистрации по IP multicast, а при его отсутствии в IPv4 — широковещательно. UA получают уведомления о разных типах служб и областях, затем отбирают нужные. Новый SA не нужно централизованно знакомить с каждой подпиской, зато получатели обрабатывают лишние сообщения, а администратор должен контролировать область рассылки.

В крупной сети с DA UA добавляет расширение Subscribe к запросу службы. DA возвращает multicast-группы NotifyAt для нужных типа и областей. Существующие SA он может уведомить через DAAdvert; для совпадающего нового SA та же инструкция может прийти в SrvAck при регистрации. Если объявление службы истекло без штатного снятия регистрации, DA также отправляет уведомление об удалении. Основную массу событий по-прежнему рассылают сами SA: DA не становится центральным ретранслятором каждого события.

Работа распределена, но распределено и состояние. DA хранит подписки, уже извещённые SA запоминают адреса групп, UA вступает в эти группы, а выделение и срок действия multicast-адреса образуют отдельное состояние. Чтобы разные DA не рассылали одинаковый NotifyAt, каждый ждёт равномерно случайное время от нуля до трёх секунд и слушает совпадающие сообщения других DA. Это подавляет дубликаты, но не копирует таблицу подписок и не создаёт общей постоянной базы.

Что исчезает, а что продолжает работать

В разделе 10 описан именно частичный отказ. При неожиданном исчезновении DA теряется информация о подписках UA, хранившаяся у него. Но UA продолжают получать уведомления от существующих SA: эти SA уже получили NotifyAt. Новый SA не узнает о подписке, если только другой DA тоже не хранит эту информацию.

UA может обнаружить запасной DA лишь после активного запроса. Поэтому новая служба способна зарегистрироваться уже после отказа прежнего DA, но до того, как UA найдёт замену и обновит подписку. Поток выглядит живым, поскольку старые службы продолжают появляться; новой службы в нём может не оказаться вовсе.

Механизм восстановления сначала защищает уже известные отправители. Они продолжают уведомлять до окончания подписки; если другого DA нет, они игнорируют срок и продолжают до обнаружения нового. После регистрации в новом DA ответ SrvAck показывает, обновил ли UA подписку. Но RFC прямо признаёт остаточное окно: SA, запустившиеся между восстановлением DA и обновлением подписки UA, всё ещё не получат уведомление. Если UA важно узнать о каждой новой службе, ему следует подписаться у каждого вновь обнаруженного DA, поддерживающего нужные области. Несколько устройств сами по себе не дублируют состояние подписки.

Уведомление — не доказательство завершённой услуги

Остальные правила также требуют разделять свидетельства. Multicast-уведомления повторяются в течение 15 секунд с экспоненциальным увеличением интервала. RFC говорит, что это повышает вероятность доставки хотя бы одного сообщения, но не гарантирует получение и не создаёт постоянный журнал для повторного воспроизведения. Список атрибутов может превысить MTU UDP; бит переполнения подсказывает UA позднее запросить недостающие атрибуты у SA или DA. RFC предусматривает и блоки аутентификации, которые UA может проверить.

Однако аутентичное сообщение не доказывает, что его получили все слушатели, что endpoint сейчас доступен или что приложение завершило операцию.

Следует отдельно учитывать подписку UA, сохранённое у DA состояние типа и области, полученный SA блок NotifyAt, участие в multicast-группе, отправку события, его фактическое получение, дополнительный запрос при нехватке атрибутов и сам обмен с услугой. RFC 3082 определяет некоторые переходы, но не объединяет их в единое сквозное подтверждение.

Эти две части заголовка не противоречат друг другу. RFC 3082 не утверждает, что отказ одного DA прекращает все уведомления: существующие SA могут продолжать, а другой DA — сохранить покрытие. Вывод уже и полезнее: непрерывность работы отправителей, уже узнавших о подписке, не равна охвату тех, кто появится позже. Переход от опроса к уведомлениям меняет место, где система должна помнить о слушателях, и состояние, которое требуется восстановить после сбоя.

Источники

Текст и история: RFC 3082, запись RFC Editor, история Datatracker, RFC 2608: SLPv2, RFC 2119, RFC 2373, RFC 2730 и RFC 2908. Только редакционные линзы, не доказательства поведения SLP: Lu Heng, Running-Code Primacy и On Reality Layers.