Кратко

  • Проект Athena создал Zephyr для маршрутизации коротких срочных уведомлений в растущей сети рабочих станций, где локальное вещание и электронная почта не справлялись по разным причинам.
  • Аутентифицированная личность, место входа, выбранная видимость, подписка на тему и доставка сообщения были разными состояниями; ни одно не доказывало доступность человека или факт чтения.

Первая задача заключалась не в том, чтобы вывести текст в окно. Нужно было найти адресата, когда вычисления переходили с общей машины на множество сетевых рабочих станций. В планах Athena на 1987–1988 годы описан этот переход в кампусе. Файловый сервер должен был предупредить пользователей об остановке; служба печати — сообщить о выполнении задания; ассистент преподавателя мог обратиться к целой группе. Электронная почта сохраняла сообщения, но требовала ожидания и заранее составленного списка адресатов.

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

Поэтому Zephyr задумали как транспорт уведомлений, на котором могли работать разные службы связи. В докладе USENIX 1988 года описана базовая передача и надстроечные уровни подписок и определения местоположения. Технический план от 5 июня 1989 года уточняет устройство системы: на каждой рабочей станции работает HostManager (zhm), в каждом сеансе входа — клиент WindowGram (zwgc), а несколько серверов Zephyr отвечают за регистрацию, маршрутизацию и состояние. У уведомления были отдельные заголовок маршрутизации и данные клиента. Серверы определяли адресатов по заголовку, не разбирая текст сообщения. Файловый сервер мог отправить уведомление известным пользователям; служба без заранее известной аудитории публиковала его в классе, а заинтересованные клиенты подписывались.

Подписка была явно заданным состоянием, а не призывом ко всему кампусу. Сервер хранил тройку из класса, экземпляра и адресата. Клиент запрашивал подписку, после чего совпадающие уведомления направлялись заинтересованным пользователям. zwrite указывал конкретную личность получателя. Kerberos предоставлял аутентифицированные принципы, служившие Zephyr ID. Система могла отличить подтверждённую учётную запись от строки имени в тексте. Но аутентификация отвечала на вопрос «какая личность отправила запрос?», а не на вопрос «вправе ли отправитель искать местоположение или прерывать любого адресата?». Контроль доступа, настройки видимости и привилегированные аварийные уведомления рассматривались отдельно.

У данных о присутствии были свои ограничения. Zephyr регистрировал вход пользователя и его местоположение, чтобы доставить уведомление без необходимости знать, какой именно терминал он использует. Разработчики предупреждали, что база местоположений — не безошибочный актуальный список. Запись показывала, что система получила сообщение об аутентифицированном входе. При сбое рабочей станции уведомление о выходе могло не поступить, и устаревшая запись оставалась. Обратный вывод тоже неверен: отсутствие видимого местоположения не доказывает, что пользователь не входил, поскольку он мог скрыть эти данные.

Перезагрузка и отсутствие ответа запускали очистку старого состояния. Это уменьшало ошибки, но не делало распределённую службу безошибочным свидетелем.

В плане 1989 года перечислены шесть уровней видимости: none, opstaff, realm-visible, realm-announced, net-visible и net-announced. Возможность искать местоположение и рассылка уведомлений о входе и выходе управлялись по-разному. Руководство MIT для пользователей 1993 года также отделяло команду hide от отключения Zephyr: скрытие местоположения не мешало другим отправлять уведомления. Это более узкий контроль, чем универсальная кнопка «не связываться».

Надёжность транспорта была отдельным вопросом. Zephyr использовал UDP и добавлял несколько уровней подтверждения там, где они были нужны приложению. Разработчики отмечали дубликаты, изменение порядка, потери и отсутствие управления потоком. Пример zwrite гарантировал отправку, но не доставку или ровно одну копию. Подтверждение сервера, подтверждение клиента и прочтение сообщения человеком были разными событиями. Zephyr помогал быстро координировать действия, но транспортная квитанция не доказывала согласие, внимание или выполнение работы.

К 1993 году руководство MIT описывало личные и групповые Zephyrgrams как обычные инструменты Athena; исследование 1996 года рассматривало канал Zephyr Help как синхронную службу поддержки. Это свидетельства использования внутри MIT, а не доказательство того, что Zephyr стал универсальной моделью мгновенных сообщений. Его история важна прежде всего проведённой границей: идентичность помогала маршрутизации, вход пополнял запись о местоположении, подписка выражала интерес к классу уведомлений, а разрешение, достижимость и внимание человека оставались отдельными вопросами.

Источники