要約

  • ボランティアは comp.mail.maps にホストと接続の情報を構造化して投稿し、pathaliasがメール経路を計算できるようにした。
  • その地図はリアルタイムで検証された公式トポロジーではない。各サイトは自分の情報を加え、記録の正確さは運用者による報告と訂正に左右された。

宛先までの道筋をホスト名の列で表せても、どの機械が中継を引き受けるかを知らなければ配達は始まらない。Stargate Internet Museumの後年の記録によると、1984年1月、USENIXのBirds-of-a-Feather会合で30人以上がUUCPの地図を作り、保守する役割を引き受けた。pathaliasはすでに経路を計算できたが、入力となる完全な地図がなかった。参加者はUUCP Projectを名乗り、Usenetの comp.mail.maps で地域ごとの更新を配り始めた。USENIXの当初資金が尽きても、活動はボランティアによって続いたという。

この地図は中央のルーターが全員に指示する仕組みではない。各レコードにはホスト名、組織、連絡先、機器、接続先、申告された費用や接続頻度などが記された。1985年7月の日付を持つREADMEの再録によれば、pathaliasは共有地図だけでなく各サイトの Path.* も読み込んだ。結果としてメール経路はそれぞれの場所で計算された。共通ファイルは候補となる中継先を知らせたが、ローカルな運用事情を置き換えなかった。

接続の条件は一様ではない。構内網や専用線もあれば、市内電話、長距離電話、夜間だけの呼び出しに依存するリンクもある。READMEが示すpathaliasの費用値は、伝送速度だけでなく、おおむね経過時間を重視していた。遅くても頻繁につながる線が、高速でも高価な回線より使いやすいことがある。これはメール転送の費用モデルであり、IPの遅延測定でも、宛先がその時点で到達可能だという保証でもない。

公開範囲にも方針があった。多数の構内コンピューターを持つ組織には、少数のゲートウェイを載せ、内部の詳細は公開しない補助ファイルに置くことが勧められた。記載すべきなのはUUCPから到達できるホストであり、すべての機械ではない。地図の役割はメールソフトと連絡先を探す人への情報提供だった。直接のIP接続、稼働中のサービス、あるいはインターネット全体への参加を証明するものではない。

1988年のオーストラリアの利用者団体誌は、この記述が現場でどう使われたかを示す。1986年以降、ACSnetのノード情報は aus.map に集められ、あるホストに保管され、一部は世界向けのUUCP地図に渡された。シドニー大学では、ニュース投稿を集めてshell archiveを展開し、検索用索引を作るスクリプトが動いた。地図は、どの組織が機械を運用するか、どのUnixを使うかといった、ネットワーク状態ファイルだけでは分からない質問に答えた。ただし、状態ファイルを置き換えるものではなく、補完するものと説明されている。

記事が挙げる266件はACSnetの記録で、世界のUUCPホスト数ではない。新しいノードが自発的に情報を寄せないこと、停止中の機械と消滅した機械を見分けにくいことも記されている。ニュース交換先の関係は、地図の中で最も信頼しにくい情報の一つだった。共通の記述はネットワークを見やすくするが、何が現存するかを人が確認する問題までは解かない。

1990年11月のUsenet投稿には、収集した comp.mail.maps を展開し、毎晩のcronでpathaliasを動かし、ローカル経路ファイルを更新し、処理エラーを管理者にメールする例がある。自動化で利用までの間隔は短くなったが、投稿内容が検証済みになるわけではない。1987年の動的な再ルーティングに関する議論では、経路データベースの更新が遅く、ループを確実に防ぐには不十分だという懸念が示された。

成果は「一枚の完全な地図」ではなかった。ボランティアが情報を集め、Usenetが更新を運び、各サイトの処理がそれを読み込み、各々が条件に応じた経路を計算する分業である。公開ファイルをすべての接続についての運用知識だと見なさずに、蓄積交換型のネットワークを理解しやすくした。

出典