Кратко

  • Для поиска ресурсов Cronus задавал общий вопрос, который не доходил до участников за шлюзом. Инженеры BBN решили переносить выбранные вопросы процессами на хостах, сохраняя работу шлюзов без изменений.
  • Такое размещение позволяло менять список получателей силами операторов Cronus, даже если шлюзами заведовала другая организация. Цена свободы — процесс на общем компьютере просыпался из-за каждого UDP-пакета.

Ken Lebowitz и David Mankins из BBN описали в RFC 947 не только передачу пакетов, но и неприятный вопрос для создателей Cronus: кто должен менять сеть, когда состав системы меняется? Распределённая система находила ресурсы и получала сведения о серверах с помощью общего запроса. Внутри одной Ethernet его слышали соседние машины; за шлюзом его уже не слышали, хотя обмен по известным адресам оставался возможен. Поставить повторитель в шлюз значило бы зависеть от людей, которые управляли инфраструктурой другой организации.

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

Выбранный вместо этого компьютер VAX обслуживал и сообщения, которые собирался отбросить. Каждый поступивший UDP-пакет будил процесс пересылки; лишь затем программа решала, относится ли он к нужному ей обмену. Разработчики прямо указали на этот лишний труд в отчёте о вполне удачном для них эксперименте. Так автономия настройки получила измеримое ограничение: система могла сама менять круг получателей, пока общий хост выдерживал стоимость отбора.

Так заканчивается практическая часть RFC 947, опубликованной в июне 1985 года. Её авторы, Ken Lebowitz и David Mankins из BBN Laboratories, работали над Cronus — распределённой операционной системой для разных типов компьютеров. Вопрос был простым по формулировке: как дать её запросам добраться до участников за пределами одной локальной сети?

Cronus использовал TCP и UDP. Для поиска ресурсов и получения сведений о состоянии серверов он также отправлял широковещательные пакеты. Такой запрос слышали узлы местной сети, поэтому отправителю не требовалось заранее перечислять всех, кто мог ответить. Но участник на другом физическом сегменте этого обращения не получал.

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

Ещё RFC 919 от 1984 года объясняла цену такого удобства: каждый компьютер, слышащий общий запрос, тратит на него некоторое усилие. У Cronus этот расход проявился и в дополнительном узле, который расширял область рассылки.

Кому доверить список адресов

Разработчики разделили ретрансляцию на два процесса. Первый отбирал локальные широковещательные UDP-пакеты, первоначально по портам, используемым Cronus. Затем он упаковывал их в сообщение для второго процесса на удалённой сети. Тот снова рассылал пакет по своему LAN, сохраняя исходный адрес отправителя.

При запуске процесс пересылки читал конфигурационный файл. Там задавались адреса удалённых ретрансляторов и правила отбора для каждого из них. Процесс устанавливал TCP-соединения и периодически повторял неудачные попытки. Можно было указать и обычный компьютер: ему отправлялась отдельная UDP-дейтаграмма, без требования снова разослать её по сети.

Этот файл давал операторам Cronus собственное место для изменения связей системы. Разработчики рассматривали и расширение функций интернет-шлюзов. Но тогда понадобились бы новые средства управления списками, поддержка производителей оборудования и возможность выбирать сообщения с учётом потребностей приложения.

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

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

Что обеспечивало работу

Чтобы удалённый процесс сохранял адрес первоначального отправителя, пришлось добавить специальную возможность в реализацию TCP/IP от BBN. Привилегированным процессам разрешили отправлять IP-пакеты с адресом другого узла. За внешней прозрачностью передачи стояло конкретное изменение сетевого программного обеспечения.

Адрес использовался и для предотвращения повторной пересылки. Процесс не соединялся с ретранслятором на собственном LAN и не пересылал пакеты с источником за пределами этого LAN. Эти меры должны были удерживать уже повторённые сообщения от возвращения по кругу. Проверкой личности отправителя они не являлись.

В описанном опыте две сети Ethernet разделяли ещё две локальные сети. Между конечными сетями пакеты проходили минимум через два шлюза. Служба работала на VAX под 4.2BSD UNIX с сетевым ПО BBN. Авторы сообщали о нескольких месяцах работы, удовлетворявшей их задачам. Это свидетельство о конкретной установке, без данных о широком распространении решения.

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

Авторы обсуждали перенос фильтрации в системное ядро, оставляя настройку и повторную отправку в пользовательском коде. Другим вариантом был специализированный сервис на микрокомпьютере с системой реального времени, уже входившем в конфигурацию Cronus. RFC фиксирует этот план, но не сообщает о завершённом переносе.

Расширение системы поэтому можно увидеть с двух сторон одного компьютера. Операторы получили список связей, который могли менять сами. Машина получила постоянную обязанность проверять входящий поток. В этой небольшой истории раннего Интернета самостоятельность настройки измерялась ещё и работой, необходимой для её поддержания. RFC 922 описывает современный эксперименту контекст IP-широковещания при наличии подсетей. Более поздний RFC 1112 определил расширения для групповой передачи, но не свидетельствует о замене именно этого решения Cronus.