Кратко

  • Mary Ann Horton участвовала в организации UUCP Mapping Project: администраторы сообщали о соседях, региональные добровольцы правили данные, а каждый узел рассчитывал маршруты со своей точки зрения.
  • Рабочая карта существовала благодаря распределённой ответственности за раскрытие, стоимость, вычисление, шлюзы и имена; без обновления тот же файл становился источником ошибок.

Строка duke!research!ucbvax!user была не только адресом. Она предписывала, какие машины по очереди сохранят целое письмо и передадут его после следующего сеанса связи. Любой узел мог перестать звонить, сменить правила или отказаться от междугородней платы.

Работа Mary Ann Horton перенесла знание о таких путях из памяти пользователей в поддерживаемый процесс. Это не история единоличного изобретения, а пример того, как связь становится услугой через общее описание и локальные решения.

Карта одной сети не была картой другой

В интервью USENIX Horton вспоминает логические карты Usenet, раздававшиеся на конференциях 1982 и 1983 годов. Их брали для маршрутизации почты, хотя граф распространения новостей и более широкая почтовая сеть UUCP не совпадали. Пропущенные связи переносили нагрузку на наиболее отзывчивые ретрансляторы.

К 1984 году логическая схема стала слишком ветвистой. Horton выпустила географическую карту, а Bill и Karen Shannon подготовили восьмистраничную логическую. Но дополнительная бумага не назначала ответственного за изменения, проверку противоречий и дату следующей версии.

Каждое ребро имело экономику. Университеты могли запрещать дальние звонки, а корпоративные площадки — принимать крупные счета. Линия могла работать только при вызове с одной стороны, редко устанавливаться или быть ненадёжной. Наличие связи не гарантировало пригодного маршрута.

Региональные хранители общего набора

На неформальной встрече USENIX в Вашингтоне в январе 1984 года оформился UUCP Mapping Project. Добровольцы отвечали за регионы, собирали сведения о площадках и соседях, устраняли несогласованность и публиковали обновления в comp.mail.maps.

Числа относятся к разным этапам. Музей Stargate говорит более чем о тридцати участниках начальной встречи, страница достижений Horton — примерно о пятидесяти в команде. Более широкие обзоры учитывают дополнительных региональных авторов. Единого точного итога эти источники не дают.

Руководство тоже описано по-разному. Horton пишет, что созвала встречу и возглавила создание проекта. Проект заключительного документа 2000 года приписывает начальное руководство финансируемым USENIX этапом Karen Summers-Horton и указывает, что Horton управляла проектом с 1985 года. Обе версии следует атрибутировать, а не превращать процесс в биографию одного основателя.

RFC 850 установил границу раскрытия. Запрос senduuname мог вернуть соседей UUCP для карты, причём администратор имел право отредактировать ответ. Телефоны, пароли и частный файл дозвона запрещалось публиковать. Для поиска маршрута нужна смежность, но не секреты соединения.

«Наименьшая стоимость» была политикой

pathalias создали Steve Bellovin и Peter Honeyman. Программа представляла сеть ориентированным графом, присваивала ребру неотрицательную стоимость и оператор адресации, затем вариантом алгоритма Dijkstra заранее вычисляла пути от локального узла.

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

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

Таблица была полезным локальным взглядом, а не глобальной фотографией. Сообщество публиковало утверждения, pathalias применял местную оценку, почтовая программа исполняла её. Horton вместе с Adam Buchsbaum работала над smail, использовавшим таблицы без необходимости показывать пользователю весь bang path.

Стабильное имя над меняющимся путём

В «What Is a Domain?» Horton поясняет: точки домена не задают последовательность машин. Домен — абсолютное имя в административной иерархии; таблица, резолвер или шлюз всё ещё выбирает следующий переход.

RFC 819 связывает домен с полномочиями именования и ответственностью за преобразование, противопоставляя его относительным исходным маршрутам UUCP. RFC 920 называет домены административными сущностями, которым не обязательны общая география, топология, техника или протокол.

По воспоминаниям Horton, в 1986 году UUCP Project вместе с BITNET, CSNET и сообществом ARPANET участвовал в общем пространстве имён. Её страница достижений говорит о более чем 150 UNIX-организациях без прямого Интернета, получивших почту .com или .edu в 1986–1988 годах. Это ретроспективная оценка участницы, а не независимая перепись.

RFC 976 реализовал совместимость. Вместо нового несовместимого формата он принял существующие правила доменов и сообщений, разделил хосты по возможностям и потребовал расширенной поддержки от шлюзов. За user@domain таблица продолжала строить пошаговый путь UUCP.

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

Право объявить карту устаревшей

Проект заключения сообщает, что в августе 2000 года базу заморозили из-за падения использования. Он предупреждает: старые данные способны потерять или неверно доставить письмо. Документ остался Internet-Draft, поэтому это свидетельство самого проекта, а не принятый стандарт.

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

Современное обнаружение работает быстрее, но не отменяет институционального вопроса. Связь — наблюдение, маршрут — решение, имя — обещание непрерывности. Наследие Horton состоит в ясном требовании: кто публикует изменение и кто отнимает полномочия у устаревшей карты?

Источники

  1. Wikimedia Commons: портрет Mary Ann Horton 2012 года
  2. Завершение UUCP Mapping Project, Internet-Draft
  3. Профиль UC Berkeley EECS
  4. Mary Ann Horton: достижения
  5. Mary Ann Horton: история Интернета
  6. Stargate Internet Museum: проект UUCP
  7. Stargate Internet Museum: UUCP и почта
  8. Pathalias: The Care and Feeding of Relative Addresses
  9. Mary Ann Horton: What Is a Domain?
  10. RFC 1036: обмен сообщениями USENET
  11. RFC 819: соглашение об именах доменов
  12. RFC 850: обмен сообщениями USENET
  13. RFC 920: требования к доменам
  14. RFC 974: маршрутизация почты и доменная система
  15. RFC 976: формат обмена почтой UUCP
  16. Интервью USENIX с Mary Ann Horton