要約

  • Cronusは離れたLANの資源を探したかったが、局所的な放送はゲートウェイを越えなかった。RFC 947ではホスト上の二つの役が必要な問いだけを選び、遠隔地で再放送した。
  • 管理者はゲートウェイ側の変更を待たずに宛先を調整できた。その代償として、共有ホストの転送プロセスは不要なUDPパケットの到着でも起こされた。

届かないのは通信ではなく問いかけ

Cronusがある仕事に使う資源を探すには、まず提供者を知らなければならない。局所的なブロードキャストは、この順序を逆にできた。相手のアドレスを知らなくても問いを投げ、資源を持つホストや状態を報告できるサーバーから答えを得られる。ところが放送を聞くのは、その物理ネットワークにつながったホストだけだ。別のLANの参加者には通常の通信経路があっても、存在を見つける最初の問いが届かない。

このため開発者が選ばなければならなかったのは、新しい経路だけではない。ネットワーク設備を管理する人に発見の仕組みを任せるか、Cronusを動かす側が自分で引き受けるかという運用上の境界でもあった。

資源が見つからなければ、到達可能なホストも分散システムの仕事には組み込めない。Cronusはサーバーの状態収集にも放送を使っていたため、遠隔LANを聞けないことは、参加者の存在と状態を知る手段に境界ができることを意味した。RFCはそこから生じた障害を報告していない。それでも、なぜ開発者が単なる経路ではなく発見の仕組みを作ったのかは、この用途から理解できる。

Ken LebowitzとDavid Mankinsが1985年6月に公表したRFC 947は、この違いを埋める実験を記録する。CronusはTCPとUDPを利用していた。放送で全員に届く情報を必要とするのはしばしば一部のホストだけで、著者らもマルチキャストの方が適していると認めている。ただ、当時使っていた一部のネットワーク実装にはその機能がなく、初期のCronus用ツールは放送を選んだ。ここで提案されたのはインターネット全体の放送規則ではなく、その既存の利用法を複数LANへ伸ばす方法だった。

送信側LANのホストにはforwarderが置かれた。特定のUDPポート番号または宛先アドレスに合う放送だけを拾い、遠隔LANのrepeaterへ向けたメッセージに包む。設定ファイルには相手のアドレスだけでなく、相手ごとにどのパケットを送るかも書けた。forwarderは各repeaterへのTCP接続を試み、接続が失敗すれば定期的にやり直す。受信側ではrepeaterが元の送信元アドレスを残し、当地のリンク層ブロードキャスト宛てとしてもう一度送る。

設定先がrepeaterではないホストなら、送信先をそのホストのアドレスに置き換え、ユニキャストのデータグラムとして渡す選択肢もあった。あらゆる放送を無条件に広げる仕組みではない。ゲートウェイは二つのホスト間の通信を通すが、どの放送を運ぶか、到着先で再放送するかは決めない。この役割分担こそ実験の骨格である。

設計図の外にいる管理者

著者らは当初からゲートウェイへの組み込みを比較対象にしていた。だが、受信側の一覧をゲートウェイに持たせ、その更新のため制御プロトコルも拡張する必要がある。選別にはゲートウェイが通常扱う層より上の知識が要るかもしれず、他社製機器が機能を実装する保証もない。さらに、ネットワーク設備を管理する主体とCronusを設定する主体が異なる場合、アプリケーションの変更が設備側の承認待ちになる。便利そうな配置は、運用上も便利とは限らなかった。

Cronusのカーネルに埋め込む案も退けられた。参加する全カーネルがほかの参加者のアドレスを知る必要が生じ、構成の変更が難しくなるからだ。ホストの独立したプロセスなら、放送を必要とする側が転送条件を管理しやすい。ただし自由度は、処理を引き受けるホストの責任と表裏一体だった。

再放送したパケットが戻ってきて循環する危険に対し、forwarderは同じLANにあるrepeaterへ接続せず、送信元アドレスが自分のLANに属さないパケットも転送しない。これらは文書で示された抑止策であり、完全なループ防止や送信者認証の証明ではない。元のアドレスを残すためには、別ホストの送信元アドレスを特権プロセスが指定できるようBBNのTCP/IP実装に特別な機能も加えた。見えている送信元欄と、身元の証明は区別しなければならない。

成功の報告と、残った費用

実際に記された構成は、物理的に離れた二つのEthernetの間に別の二つのLANがあるものだった。メッセージは少なくとも二台のゲートウェイを経由した。4.2BSD UNIXとBBNのネットワークソフトウェアを動かすVAXで、別々のforwarderとrepeaterのプロセスが数か月働き、著者らは用途にかなうと評価した。これは特定の試験についての当事者の報告で、広域での普及数や第三者による性能測定ではない。

むしろ処理負荷の記述は具体的だ。共有ホストに届くUDPパケットのたびにユーザー空間のforwarderが起き、不要なものをそこで捨てていた。著者らはフィルターだけをカーネルへ移し、設定や再放送をユーザー側に残す案を挙げた。また、専用のマイクロコンピューターによる実時間サービスへの移行も計画した。RFCは、そのいずれかが完了したとは述べていない。

RFC 919は放送が受信する各ホストに仕事を生むと注意し、RFC 922はサブネットがある場合のIP放送を扱った。Cronusの記録はそこに、どの機械が選別し、誰が設定を変え、どこで計算資源が消費されるかという具体性を加える。後のRFC 1112はIPマルチキャストの仕様を示すが、この試験を置き換えた証拠にはならない。

出典