要約

  • Project Athenaは、増え続けるワークステーション網で短く即時性の高い通知を届けるためZephyrを設計した。ローカル放送と電子メールはそれぞれ異なる弱点を抱えていた。
  • 認証されたID、ログイン場所、本人が選ぶ公開範囲、トピック購読、メッセージ配信は別の状態であり、どれも利用可能性や既読を示すものではなかった。

最初の課題は、画面にメッセージを表示することではない。共有コンピューターから多数のネットワーク接続ワークステーションへ移る中で、宛先の利用者をどう見つけるかだった。Athenaの1987～88年の計画は、キャンパスの計算環境が変わる様子を記録している。ファイルサーバーは停止予定を利用者に知らせたい。印刷サービスは作業完了を伝えたい。ティーチングアシスタントは授業参加者に連絡したい。電子メールはメッセージを保存できるが、遅延があり、送信者が宛先を列挙する必要がある。ネットワーク放送は速いもののローカル網に限られ、各端末が少数宛の通知を処理する。設計者の整理は明快だった。メールは遅く扱いにくい。放送は一時的で規模に弱い。

そこでZephyrは、さまざまな通信サービスの下で動く通知トランスポートとして設計された。1988年のUSENIX論文は基本層と、購読・利用者位置の上位サービスを説明する。1989年6月5日の技術計画では、通常、各ワークステーションにHostManager（zhm）、ログインセッションごとにWindowGramクライアント（zwgc）を置き、複数のZephyrサーバーが登録、ルーティング、状態を扱う構成が示された。通知には経路制御用のヘッダーとクライアントデータがあり、サーバーは本文を解釈せずにヘッダーから宛先を求める。ファイルサーバーは既知の利用者に通知を送り、受け手が定まらないサービスはクラスに通知を送り、関心のあるクライアントが購読する。

購読は明示的な状態であり、キャンパス全体への呼びかけではない。サーバーはクラス、インスタンス、宛先の組を記録する。クライアントが購読を登録すると、一致する通知だけが関係する利用者へ配送される。zwriteは特定の宛先を指定する。Kerberosが認証済み主体を提供し、それがZephyr IDとなるため、システムは認証されたアカウントと本文に書かれた単なる名前を区別できた。ただし認証が答えるのは「どのIDが要求を送ったか」であり、「その送信者に全利用者を検索し割り込む権限があるか」ではない。アクセス制御、公開設定、特権を要する緊急通知は別々に扱われた。

在席情報にも限界がある。Zephyrはログインと場所を登録し、送信者がどの端末にセッションがあるか知らなくても通知を届けた。設計者は、場所データベースを完全なリアルタイム名簿と見なさないよう注意している。登録が示すのは認証されたログインが報告されたことだ。端末がクラッシュすればログアウト通知が出ず、古い情報が残る。反対に、場所が見えないからといって利用者がログインしていないとは限らない。本人が位置情報を公開しない選択もできる。再起動時やサーバーが端末の応答を確認できないときに古い状態を消す仕組みはあったが、分散サービスを無謬の証人にはできなかった。

1989年の計画はnone、opstaff、realm-visible、realm-announced、net-visible、net-announcedという6段階の公開設定を列挙する。場所を調べられるかと、ログイン・ログアウトを通知するかは別の制御だった。MITの1993年の利用者向けガイドもhideとサービス停止を区別し、位置を隠しても他者が通知を送ることは妨げないと説明した。これは万能な「連絡しないで」という設定より限定的な制御だった。

配送の信頼性も別の問題である。ZephyrはUDPを使い、必要に応じた複数段階の確認応答を加えた。設計者は重複、順序逆転、損失、フロー制御の欠如を明記した。zwriteの説明が保証するのは送信であり、到着や一度だけの配信ではない。サーバーの確認、クライアントの確認、人がWindowGramを読むことは異なる出来事だ。Zephyrは迅速な連携に役立つが、配送の受領記録だけで同意、注意、作業完了を判断することはできない。

1993年のMITガイドは個人宛とグループ宛のZephyrgramをAthenaの一般的な道具として扱い、1996年の研究はMITのZephyr Helpを同期型サポートの事例として調べた。これはMITでの利用を示すが、即時通信全体の普遍的なモデルになった証拠ではない。Zephyrの歴史で重要なのは、IDは経路指定を支え、ログインは位置記録になり、購読は通知クラスへの関心を表した一方、許可、到達可能性、人の注意は別の問いとして残ったことだ。

参考資料