要約

  • RFC 1913 の「forward knowledge」は、下位サーバーのどこかに語があったことを示す重複除去済みの要約だった。問い合わせ経路の選別には使えても、個々のレコードの証明にはならない。
  • 複数の索引経路は単一階層への依存を減らす一方、クライアントが辿るべきグラフを生んだ。鮮度、ループ、接続先の復旧、探索量、課金は別々の責任として残った。
  • 発想は後に Common Indexing Protocol へ一般化されたが、Whois++ 自体は2006年、IETFの審査で「定義されたが使われなかった」プロトコルとされ、Historicへ移された。

消えるからこそ役に立つ

RFC 1913 の三レコードの例は、巨大な構成図より雄弁である。二人のユーザーと一つのドメインから、各テンプレート・属性に一度でも現れた語を一つずつ取り出す。「Smith」が一件にあっても千件にあっても、要約には一つしかない。「Labatt Beer」は二つの語として残るが、同じ値の中で隣り合っていた事実は失われる。

これは壊れたデータベースではない。主張の範囲を意図的に小さくした索引である。索引サーバーの仕事が、次に問い合わせる価値のある下位サーバーを選ぶことなら、全レコードを複製する必要はない。明らかに無関係な枝を切れるだけの情報があればよい。

ただし圧縮が消したものは明示しなければならない。レコード識別子、件数、共起、順序、値の提出者、問い合わせ時点での存続である。一致が意味するのは、手元の索引状態によれば、あるテンプレートのある属性にその語が下位のどこかで現れた、ということだけだ。返るのは結論ではなく referral（参照先）である。

レコードの上に網を置く

1995年8月の RFC 1835「Architecture of the WHOIS++ service」は、従来の人間向けで緩やかな WHOIS レコードを、型付きテンプレートと構造化された属性・値へ拡張した。満たされたテンプレートを持つ base server と、forward knowledge と参照先を持つ index server も分けた。一台の物理サーバーが両方を担えても、論理上の証拠は別物だった。

一台の中央ディレクトリに全情報を集めれば、保存、通信量、障害を集中させる。厳格な階層だけに頼れば、利用者は情報の所属を先に知る必要があり、上位ノードに負荷が集まる。地理や組織の枝を横断して「あるサービスを提供する人」を探す yellow pages 型の問いにも弱い。

1996年2月の RFC 1913「Architecture of the Whois++ Index Service」は、レコードの上に mesh を置いた。索引サーバーは base server や別の index server の centroid を集約でき、同じサーバーが地理・管理・ネットワーク構成など複数の上位索引に属せた。レコードの一意な識別子と、そのレコードへ至る探索経路は切り離された。

これは間接参照による分散化だった。原データは base server に残り、mesh はヒントを運ぶ。特定テンプレートや属性だけを扱う専門索引も作れる。利用者は場所を知らずに検索できる。しかし、どの経路も目的地の現実を所有してはいない。「次を尋ねる理由」を持つだけである。

更新には複数の時計があった

forward knowledge は保守されなければ古くなる。RFC 1913 は認証付きの POLL を定め、全 centroid または特定テンプレート・属性の変更を要求できるようにした。下位側は DATA-CHANGED で変化を通知できるが、受信した索引側が、いつ再取得するかを決める。

一つの変更に見えても、実際には時刻が分かれる。base record が変わり、centroid が変わり、通知が送られ、受理され、POLL が実行され、報告が認証され、索引に反映され、さらに上位へ伝わる。応答コード227は、変更通知を受け付けて後続処理のため記録したことを意味した。全索引への反映完了ではない。

古い肯定情報は、語が既に消えたサーバーへクライアントを送る。遅れた新情報は、新しく一致したサーバーを探索対象から落とす。RFCは実運用の発生率を示していないため、未知の数字を補って設計を断罪すべきではない。確実に言えるのは、更新の受領証や索引の時刻だけでは、端から端までの鮮度を証明できないことだ。

グラフの負担はクライアントへ移った

mesh は図では階層に見えても木ではない。複数の親は代替経路を作ると同時に循環も作る。RFC 1913 は索引収集関係に hop count を持たせ、当時の版では最大8を示した。問い合わせの referral については、既訪問サーバーをクライアントが記録する方法を示した。

RFC 1914「How to Interact with a Whois++ Mesh」は、その責任を手順にした。クライアントは接続し、質問し、レコードと referral を受け、切断した後で次の接続先を選ぶ。既に問い合わせたサーバーの集合を保ち、必要なら誰が誰を索引しているかを尋ねて探索を広げる。

どこから始めるかは依然として重要だった。最初のローカルサーバーは、自分が知る mesh しか見せない。展開すれば広く探せるが、無料でも自動的に賢明でもない。RFC 1914 は、すべての referral を盲目的に追えば資源コストが指数的に増え得ると警告した。応答が有料の領域も想定され、クライアントには高価なサーバーの blacklist、時間・費用の上限、中止操作が必要だった。

完全性は一回の応答の性質ではなくなった。開始点、参照先、循環検知、探索拡張、予算、blacklist、各サーバーの稼働状況の組み合わせで決まる。仕様は到達可能な範囲を辿る算法を記述できても、何を「到達可能」「続ける価値あり」とするかは運用判断だった。

安定した名前でも、場所は古くなる

RFC 1914 は、referral に入ったホスト名、IPアドレス、ポートが、数週間前のPOLL時点のキャッシュかもしれないと記した。接続できなくても、サーバーという識別対象まで消えたとは限らない。安定した server handle を Directory of Servers に問い合わせ、最新既知の接続先を取り直せる。

識別子と場所の分離は合理的である。移転のたびに全キャッシュを同時更新しなくてよい。しかし「最新既知」は「現在到達可能」ではない。取り直した接続先も失敗し得る。RFC 1913 は、対象サーバーに到達不能な場合と、ホストは到達可能だがサービスが応答しない場合を別コードにした。handle は古いポインタを直せても、稼働中のプロセスを作れない。

安全性も完結していなかった。RFC 1913 は安全上の問題を扱わないと明記した。RFC 1914 は偽の Whois++ サーバーが現れ得るとして blacklist を勧めた。これは攻撃の実例を証明しない。ただ、参照先を追う行為が、別の管理主体と別のデータ主張を信頼する決定だったことを示す。

製品が退いても抽象は残った

1999年8月の RFC 2651「The Architecture of the Common Indexing Protocol」は、CIP を Whois++ の分散索引概念の発展・洗練と位置づけた。索引交換をディレクトリのアクセス方式から分離し、索引オブジェクトを一般化した。交換されるのは問い合わせ経路を選ぶヒントであり、実データの取得には別の native data-access protocol が必要だとした。

一つの公開サービスとして定着しなくても、設計上の区別は生き残り得る。Whois++ はテンプレート型ディレクトリと centroid を密結合した。CIP は、コンパクトな知識をサーバー間で渡し、後の問い合わせをデータ保持者へ近づける部分を再利用しようとした。

2006年3月の RFC 4450「Getting Rid of the Cruft」は、古い Proposed Standard を保守的に見直した経緯を報告した。RFC 1835、1913、1914はHistoricへ移す集合に入り、Whois++ は「定義されたが使われなかった」プロトコルの例とされた。実験や実装が一度もなかったという意味ではない。RFC 2651 自身が Digger を挙げている。これは、当時の文書化された現行実務を表す Proposed Standard ではない、というIETFの判断である。

したがって、この歴史は中央集権が分散を倒した物語ではない。mesh は実在する発見問題に答え、その抽象も続いた。残った課題は、ヒントから事実へ移るたびに発生する証拠と責任の受け渡しだった。

出典

  • RFC 1835、RFC 1913、RFC 1914、RFC 2651、RFC 4450へのリンクは本文中に各一回掲載した。