Кратко

  • RFC 1913 позволял серверам Whois++ передавать компактное «предварительное знание»: уникальные термины, указывавшие на нижележащие серверы, где могла быть запись. Это маршрутизация запроса, а не доказательство записи.
  • Несколько путей уменьшали зависимость от одной иерархии, но создавали граф, который обходил клиент. Свежесть, циклы, восстановление адреса, разрастание поиска и цена оставались отдельными задачами.
  • В 1999 году механизм обобщили в Common Indexing Protocol; сам Whois++ в 2006 году перевели в Historic после обзора IETF, назвавшего его определённым, но не использованным протоколом.

Полезное исчезновение

Пример RFC 1913 содержит двух пользователей и один домен. Для каждого шаблона и атрибута centroid сохраняет по одному экземпляру каждого встретившегося слова. «Smith» остаётся один раз независимо от числа записей. Слова из общей фразы разделяются. Идентификатор записи, число совпадений, порядок, совместное появление, происхождение и подтверждение текущего состояния исчезают.

Это не испорченная база, а сознательно узкое утверждение. Чтобы отсечь бесполезную ветвь, индексу не нужна копия всех данных. Он сообщает лишь: согласно имеющемуся резюме, это слово встречалось в таком атрибуте где-то ниже. Корректный результат — направление к следующему серверу, а не окончательный ответ.

Сеть над источниками

Опубликованный в августе 1995 года RFC 1835, Architecture of the WHOIS++ service, ввёл типизированные шаблоны и структурированные пары атрибут–значение. Он разделил базовые серверы с полными записями и индексные серверы с предварительным знанием и указателями. Одна машина могла играть обе роли, но подсказка не становилась исходной записью.

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

В феврале 1996 года RFC 1913, Architecture of the Whois++ Index Service, наложил на записи mesh-сеть. Индекс мог собирать centroids базовых или других индексных серверов и формировать собственное резюме. Сервер мог иметь несколько родителей и входить одновременно в географическую, административную и топологическую иерархии. Уникальная идентичность записи больше не задавала единственный путь к ней.

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

У изменения было несколько часов

RFC 1913 определял аутентифицированные запросы POLL: полный centroid или изменения выбранных шаблонов и полей. Нижний сервер мог послать DATA-CHANGED, после чего получатель решал, делать ли новый опрос и когда.

Одно обновление распадалось на события: менялась запись, пересчитывался centroid, уходило уведомление, его принимали, выполняли опрос, проверяли отчёт, применяли его локально и позже передавали выше. Код 227 означал, что передача принята и зарегистрирована для дальнейшего действия. Он не означал повсеместного применения.

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

Клиенту достался граф

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

RFC 1914, How to Interact with a Whois++ Mesh, также опубликованный в феврале 1996 года, описал обход. Клиент соединялся, отправлял запрос, получал записи и направления, закрывал соединение и выбирал следующую цель. Он вёл множество уже опрошенных серверов и мог расширять поиск за начальную точку.

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

Постоянное имя и устаревшее место

Имя хоста, IP-адрес и порт в направлении могли происходить из опроса недельной давности. После неудачного соединения клиент мог взять стабильный server handle и запросить у Directory of Servers последнюю известную точку.

Разделение идентичности и местоположения позволяло переносить сервис без мгновенного обновления всех кэшей. Но «последнее известное» не равно «доступно сейчас». Новый адрес тоже мог не ответить. RFC 1913 различал недостижимый сервер и достижимый хост с недоступной службой. Идентификатор исправлял старый указатель, но не запускал процесс.

Граница безопасности тоже была открыта. RFC 1913 прямо не обсуждал безопасность. RFC 1914 советовал чёрные списки на случай поддельных серверов Whois++. Это не доказательство фактической атаки, но свидетельство того, что каждое направление переводило клиента в другую административную область и к новому утверждению о данных.

Идея пережила продукт

В августе 1999 года RFC 2651, The Architecture of the Common Indexing Protocol, назвал CIP развитием и уточнением распределённого индексирования Whois++. Обмен индексами отделили от протокола доступа, индексные объекты обобщили, а их содержимое описали как подсказки для маршрутизации запросов. Реальные результаты по-прежнему извлекались нативным протоколом доступа.

Архитектурное различие способно пережить первоначальную службу. Whois++ связывал centroid с шаблонным каталогом; CIP пытался сохранить повторно используемый механизм компактного знания между серверами.

В марте 2006 года RFC 4450, Getting Rid of the Cruft, зафиксировал консервативный пересмотр старых Proposed Standards. RFC 1835, 1913 и 1914 попали в набор для перевода в Historic; Whois++ был назван среди протоколов, которые определили, но не использовали. Это не отменяет эксперименты и программы — RFC 2651 упоминает Digger. Это решение IETF о том, что документы больше не представляли текущую практику, достойную статуса Proposed Standard.

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

Источники

  • RFC 1835, RFC 1913, RFC 1914, RFC 2651 и RFC 4450 имеют по одной ссылке в тексте анализа.