要約

  • RFC 966 は、一つのグループアドレスに複数のホストを結び付け、参加者が変わっても端末が同じ宛先へ問い合わせられる構想を示した。
  • 送信者はグループの一員でなくてもよい。宛先の存在は、受信者の在席や応答の保証にはならない。

端末が起動サーバーの古いアドレスしか知らなければ、そのサーバーの交換は端末の停止につながる。起動できない端末自身に新住所を探させることはできず、運用者が一台ずつ接続先を直す必要がある。全員へのブロードキャストも、答えを持たない機械に負担を掛ける。Steve Deering と David Cheriton は1985年12月の RFC 966 で、サービスを担うホスト群に一つの宛先を与える案を示した。機械の切り替えと利用者の設定変更を切り離そうとしたのである。ただし群は空でもよい。固定したのは問い合わせ先であって、応答そのものではない。文書は議論を求める提案で、普及の実績報告ではない。

文書には二つの用途がある。第一は、同じデータグラムを複数の宛先へ運ぶこと。第二は、相手をまだ知らない利用者がサービスを発見することだ。例では、ファイル名を知っているサーバーが分からなくても、そのサービス群に問い合わせ、該当するサーバーから個別に返事を受ける。名前サーバー群や起動サーバー群のように、恒久的な識別子は役割を指せる。しかし、どの機械がその役割を引き受けるかは時点によって異なる。

ホストは複数の群に参加でき、設計案は群アドレスだけで到達可能なホストまで検討した。短命な群は分散プログラムとともに生まれ、最後の参加者が去れば消える。CreateGroup、JoinGroup、LeaveGroup という操作は、この変動を扱うためのものだった。したがって、長く登録された識別子を見ても、その瞬間に受付中のサーバーがあるとは言えない。

「開かれた群」は、外部から送信できるという意味である。端末は起動サーバー群に加入せずに問い合わせられる。参加資格には別途アクセスキーで制限を掛ける案があったが、これは受信者として群に入る資格の話だ。送信可能であること、群のメンバーになれること、アプリケーションが要求を受け付けることを同じ許可と読むべきではない。

宛先を柔軟にするほど、転送側には更新された情報が必要になる。RFC 966 は、どのネットワークに群の参加者がいるかをゲートウェイが把握する方式を描く一方、その記録を分散した装置間で新鮮に保つ問題は未解決だと明記した。繰り返し送っても特定の参加者を体系的に取り逃がさない「カバレッジ」を望んだが、失敗通知は手掛かりにとどめた。送信という行為から、全員への配送やサービスの完了は導けない。

後続の RFC 988 は1986年、恒久的なのは群のアドレスで、参加者ではないと明示した。RFC 1112 は1989年、ベストエフォート配送には全員への完全な到着も共通の順序も保証がないと記した。三つの文書を並べると、初期提案のすべてが採用されたという話ではなく、宛先とメンバーを分ける考えが残ったことが見える。

今日のクラウドサービスでも、利用者に見せるサービス名を保ったまま、裏側の機械を交換したい場面がある。RFC 966 が現代の仕組みを直接生んだという話ではない。ここで見えるのは、提供者の交代を利用者の宛先変更に直結させないという設計上の課題だ。一方で、参加記録、転送経路、実際の返答は別々に確かめなければならない。

原資料と限界

根拠は RFC 966、RFC 988、RFC 1112 と、比較対象の RFC 919 に限る。これらから最初の運用事例、採用率、個別サービスの成功率は分からない。