Кратко

  • В RFC 891 обмен HELLO давал задержку туда-обратно для маршрутизации и переносил смещение часов, связанное с путём, однако эти результаты проходили разные проверки.
  • Минимальная приемлемая задержка определяла носитель наблюдения, а не хозяина времени: эталонный host ID задавался конфигурацией CLOCK-HID.
  • Равенство длин пакетов, удержание записей, действительность даты и локальная процедура коррекции разделяли получение сообщения, принятие маршрута и перевод часов.

В RFC 891 есть полезный пример частичного согласия. Узел вправе принять новый маршрут из HELLO, но не менять связанное с ним смещение часов, если длины последнего отправленного и принятого HELLO не совпали. Одно наблюдение дошло до двух процедур, и лишь одна сочла его достаточным.

Так выглядела не ошибка ранней архитектуры, а продуманное совместное использование данных. DCN был небольшим локальным миром: до 256 хостов и шлюзов, часто на PDP-11 или LSI-11 Fuzzball, с точечными и многоточечными линиями. Каждый узел мог пересылать пакеты, работать шлюзом и предоставлять службы. Отдельного локального руководителя маршрутизации не было.

В Host Table для цели хранились выходной процесс, измеренная круговая задержка, смещение часов, время обновления и счётчик жизни. Один физический Fuzzball мог представлять несколько виртуальных хостов. Отдельная Net Table связывала внешние сети со шлюзами и обычно принадлежала конфигурации, кроме изменений процессами GGP или EGP.

Измерение работало до общей настройки часов

HELLO внутри одной сети использовали IP-протокол 63 и переносили табличные значения задержки и смещения. Современный реестр номеров протоколов IANA сохраняет для 63 запись “any local network”. Она доказывает регистрацию номера, но не нынешнее распространение DCN.

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

Неверный формат или checksum отбрасывали сообщение. Затем начинались проверки конкретного потребителя. Для точного смещения требовалась одинаковая длина последнего принятого и переданного HELLO. Маршрутизатор мог обновить путь и сохранить прежнее смещение.

Фраза «один протокол для времени и маршрутов» без этого условия скрывает главное. Общим был транспорт доказательства, а не полномочие принимать решение.

Быстрый путь отвечал на вопрос «куда», а не «кому верить»

Узел складывал задержку до соседа с объявленной соседом задержкой до цели. Новый выход принимался лишь при выигрыше сверх настроенного порога. В описанной реализации фигурировали примерно 100 миллисекунд порога, 120 секунд удержания Host Table и 30 секунд максимального значения пути. Это исторические параметры реализации, не обязательные константы.

При принятии пути в таблицу попадало и сопровождавшее его смещение. Поэтому лучший маршрут действительно становился каналом времени. Но хозяин эталона не выбирался соревнованием задержек. Его host ID был заранее записан в CLOCK-HID.

Ближайший сосед мог дать прекрасную метрику, не получив права на перевод часов. Даже значение от CLOCK-HID нуждалось в действительной дате и проходило локальный алгоритм поправки. Достижимость, идентичность и эффект оставались независимыми.

Метрика помнила, откуда пришла

Если вернуть выученный маршрут через ту же линию без изменения, соседи могут начать подтверждать маршрут друг другу. RFC 891 подставляла в обратном направлении MAXDELAY. Поздняя RFC 2453 даёт удобные термины для сравнения: split horizon, poisoned reverse, triggered updates и count to infinity.

Сравнение не устанавливает прямое происхождение RIP от Hellospeak. Оно показывает общий предел: число без входной линии теряет происхождение и может превратить чужое сообщение в мнимое собственное знание.

Счётчик жизни и hold-down также сохраняли историю. Исчезнувшая запись не становилась мгновенно чистой новой записью. У маршрута, смещения и локальных часов были связанные, но разные сроки действительности.

После большого перевода часы временно переставали быть прибором

Документ различал физические, видимые и фактически выдаваемые часы. Небольшая поправка вводилась постепенно переносом доли CLK.DELTA; предложенные параметры ограничивали скорость величиной менее примерно двух миллисекунд в секунду.

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

Видимые часы переходили через ноль в полночь UT, поэтому хотя бы раз в сутки требовалось действительное обновление даты и времени от эталона. Наличие маршрута к CLOCK-HID не означало наличия свежей даты.

Ранее RFC 778 описывала службу часов DCNET с метками ICMP и GGP для односторонней и круговой задержки. RFC 891 встроила подобное измерение в постоянно обновляемое распределённое состояние маршрутов.

Hellospeak повлиял на NTP, но не был NTP

RFC 1059 позднее назвала протокол Fuzzball «Hellospeak», прямо указала на сильное влияние объединения времени и маршрутизации на NTP и одновременно признала схему непригодной за пределами локальной среды.

Первое предложение NTP в RFC 958 использовало UDP, иерархию и формат сообщений, но не задавало алгоритмы синхронизации и фильтрации, поиск пиров или аутентификацию. RFC 1305 затем описала фильтрацию и выбор нескольких серверов, границы ошибок и логические часы, выросшие из работы с Fuzzball.

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

Источники и границы

Материал опирается на RFC 778, RFC 891, RFC 958, RFC 1059, RFC 1305, RFC 2453 и реестр IANA. Они не доказывают современное развёртывание DCN, одинаковость всех параметров, аутентификацию эталона, симметрию задержек, прямую родословную к RIP или гарантию, что минимальная круговая задержка означает минимальную ошибку времени.