Кратко

  • Who-Provides? рассылался, когда адрес поставщика был неизвестен, и собирал положительные ответы; отсутствие ответа не становилось доказательством отсутствия ресурса.
  • Адресный Do-You-Provide? требовал и пустого отрицательного ответа, а They-Provide от посредника оставался подсказкой, которую обычно следовало проверить у названного узла.
  • Имя ресурса повторяло цепочку демультиплексирования, поэтому поддержка транспорта или порта не давала права объявлять поддержку любой специализации выше.

В примере RFC 887 только что запущенный хост хочет отправить первый пакет за пределы своей сети, но не знает ни одного шлюза. Resource Location Protocol предлагал не вшивать обязательный адрес, а задать вопрос локальной сети.

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

Имя ресурса проходило по уровням обработки

Спецификатор начинался с номера самого нижнего Internet-протокола, используемого для доступа. Затем шли длина и естественные значения, которые выбирали обработчик на следующих уровнях. Для DNS поверх UDP пример содержал протокол 17 и порт 53.

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

Полное «да» возникало только во втором случае. Поддержка TFTP не означала поддержку конкретного механизма передачи аварийного дампа через TFTP. Нижний уровень не мог присвоить себе смысл верхней функции.

Широковещательный вопрос звал только тех, кто отвечал положительно

Who-Provides? обычно уходил в широковещательную рассылку. Хост с хотя бы одним совпадением отвечал I-Provide; остальные могли молчать.

Это сокращало поток ответов, но не объясняло тишину. Возможно, поставщика не было; возможно, потерялись запрос или ответ; возможно, служба работала без RLP. RFC 919 описывал IP broadcast как ненадёжный, неупорядоченный и допускающий дубликаты. Каждый такой пакет также нагружал все услышавшие его хосты.

Поиск избавлял от части статической настройки, но не превращался во всеобщую перепись.

Пустой адресный ответ был настоящим, но узким отрицанием

Do-You-Provide? направлялся конкретному хосту. Получатель должен был ответить, даже если не предоставлял ничего из списка. Пустой I-Provide становился явным отрицанием для этого адресата и запроса.

RFC 887 запрещал широковещательную отправку такого сообщения. Обязанность каждого узла прислать отрицание вызвала бы лавину. Перед группой говорили только положительные участники; названный собеседник должен был сообщить и «да», и «нет».

Этот отказ не говорил за другие хосты и не обещал неизменность во времени. Его надёжность вытекала из точной области действия.

Посредник называл кандидата, а не свидетельствовал за него

Who-Anywhere-Provides? и Does-Anyone-Provide? позволяли спросить известный «умный» хост о третьих машинах. Это помогало сетям без broadcast и узлам, собравшим сведения на других интерфейсах.

Ответ They-Provide содержал предполагаемые адреса. RFC 887 прямо разрешал не доверять косвенной информации без проверки и обычно рекомендовал отправить названному кандидату Do-You-Provide?.

В примере DNS посредник указывает S, но прямой запрос к S получает пустой список. Клиент исключает S, повторяет поиск, узнаёт о T и только от T получает подтверждение UDP 53. Посредник мог не обманывать: его знание могло устареть.

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

Флаг Local-Only ограничивал адреса IP-сетью запрашивающего и определял правильный локальный исходный адрес многосетевого хоста. Область была частью вопроса.

Message-ID связывал пакеты, но не удостоверял личность

16-битный Message-ID помогал сопоставлять ответы с запросом. Он не подтверждал отправителя, разрешение или криптографическую свежесть. Контрольная сумма UDP тоже не была подписью.

Даже прямой I-Provide означал лишь заявление хоста о названном ресурсе. Успех следующей операции, полнота реализации, право клиента и длительная работоспособность оставались отдельными проверками.

Поздние протоколы иначе оформили область и доверие

Сравнение не доказывает прямого наследования. RFC 2608 строил SLPv2 из типов и атрибутов служб, User, Service и Directory Agents и административных областей. Для URL и атрибутов появилась аутентификация, но не конфиденциальность.

RFC 6762 обеспечил DNS-подобные операции в локальном канале без обычного unicast DNS-сервера. RFC 6763 описал именованные экземпляры служб, найденные по типу и домену. Представление изменилось, но источник, область, время и результат не слились.

Запись порта 39 пережила утверждение о работающей службе

RFC 887 назначил UDP-порт 39. Нынешний реестр IANA имён служб и транспортных портов сохраняет rlp на порту 39 для TCP и UDP. Это административная запись, а не счётчик установок.

RFC 6335 указывает, что назначение не является одобрением приложения, а трафик на порту может не относиться к зарегистрированной службе. Реестр координирует пространство, но не видит исполнения.

Источники и пределы

Материал опирается на RFC 887, RFC 919, RFC 2608, RFC 6762, RFC 6763, RFC 6335 и реестр IANA. Они не измеряют распространение RLP, не устанавливают причинную линию к последующим системам и не подтверждают нынешнее поведение продуктов или сетей.