要約

  • WHOIS++ の参照に含まれるホスト名や IP アドレスは古くなり得たため、安定したサーバーハンドルから最新既知の接続先を引く仕組みが必要だった。
  • それでも接続可能性、レコードの所在、メッシュ全体の完全性は証明されず、クライアントが参照を追い、循環を避け、失敗を記録する必要があった。
  • 探索範囲を広げれば発見可能性は上がる一方、時間、帯域、場合によっては応答料金も増え、最終的な停止は証拠範囲を決める統治判断になった。

古い住所は不在証明にならない

WHOIS++ のインデックスサーバーは、回答そのものではなく SERVER-TO-ASK を返すことができた。そこには次に問い合わせるサーバーの情報が含まれる。しかし、そのホスト名や IP アドレスは、以前のポーリングで得られたものかもしれない。RFC 1914 は、その値が数週間古い可能性まで明記した。

接続に失敗したクライアントは、そこで検索を終える必要はなかった。参照に含まれる比較的安定したサーバーハンドルを使い、Directory of Servers に現在として記録されたホスト名を問い合わせられた。接続先が変わっても、識別子を手がかりに追跡できるという発想だった。

ただし、この復旧手順は証拠の意味を限定する。ハンドルは生きたサービスそのものではない。Directory of Servers が返すのも最後に知られた接続先であり、現在到達可能であること、同じデータを保持していること、期待した応答を返すことまでは保証しない。古い住所への接続失敗、ハンドル検索、代替住所、再接続の結果は、それぞれ別の受領記録として残さなければならない。

特別なディレクトリにも入口が要った

Directory of Servers は、WHOIS++ サーバーのハンドル、ホスト名、ポート、説明属性を公開する特別なサービスだった。どこから検索を始めるかを選ぶ助けにはなったが、そのサービス自身のホスト名とポートは事前設定が必要だった。発見のためのディレクトリも、無前提には発見できなかった。

RFC 1914 は、そこで得た候補を直ちに自動選択するより、利用者に提示することを勧めた。良い入口は一つの世界ランキングで決まるものではなく、問い合わせ内容、距離、費用、利用方針によって変わるからだ。メッシュに単一の必須ルートがないことは、入口の選択が不要であることを意味しなかった。

通常の検索も、実用上できるだけ近い設定済みサーバーから始める想定だった。だが「近い」はデータの地理的範囲ではない。米国にあるサーバーがスウェーデンのレコードをポーリングしている例を、文書自身が挙げている。国を限定したいなら、その条件を問い合わせに明示する必要があった。

一つの応答が次の接続を生んだ

基本のやり取りは短い。クライアントが接続し、問い合わせを送り、応答を受け、切断する。応答にはレコードが入る場合も、別の問い合わせ先が入る場合もあった。参照は「この先に可能性がある」という前方知識であり、レコードの存在を証明する回答ではない。

そのため、調整はクライアントに移った。インデックスサーバーは候補を示す。基底サーバーは自らのレコードを管理する。クライアントは候補のどれを実際の接続に変えるかを決め、異なる応答をまとめる。最初のサーバーの空回答だけでは、メッシュ全体にレコードがないとは言えなかった。

さらに範囲を広げるとき、クライアントは polled-by と polled-for の関係を調べ、新しいインデックスサーバーを見つけ、同じ問い合わせを繰り返した。検索対象を調べながら、検索路そのものも発見していく設計だった。

循環を止めるのはクライアントの記憶だった

複数の階層や近道を許せば、構造は木ではなくグラフになる。一つの基底サーバーが複数のインデックス系統に属することもあり、別の経路から既訪問のサーバーへ戻ることもある。各サーバーは、一回の接続だけを見てクライアントの全行程を知ることができない。

RFC 1914 は、循環の検出と除去をすべてクライアントの責任にした。例示アルゴリズムは QueriedServers、AnswerList、OriginalServers、これから問い合わせる ServerList を分けた。問い合わせ前に既訪問か確認し、同じサーバーを二度たどらない。

これは実装上の細部ではなく、完全性を監査する台帳である。最終レコードだけを保存しても、別の枝が重複として除外されたのか、接続不能だったのか、ブラックリストに入っていたのか、そもそも発見されなかったのかは分からない。二つのクライアントが同じ質問から違う一覧を返しても、基底データが矛盾しているとは限らない。入口、参照、キャッシュ、訪問順、停止条件が異なればよい。

広げるほど費用と不確実性も増えた

RFC 1914 は、自動的かつ無制限な拡張を推奨しなかった。参照を盲目的に追えば、資源消費が指数的に増える可能性があると警告した。想定されたメッシュの一部では応答に料金が発生しており、探索の深さは金銭的な判断にもなり得た。

さらに一枝たどることは、見逃しを減らす可能性と同時に、遅延、通信量、重複、障害、請求を増やす。速いクライアントは、遅い枝を切ることで速さを作れる。広いクライアントは、待ち続けるために故障しているように見える。結果件数だけでは、この交換条件を評価できない。

文書は特定サーバーを除外する仕組みと、長時間の処理を利用者が止められることを求めた。停止は検索外の操作ではない。どこまでを「調べた範囲」とみなせるかを決定する、証拠上の操作だった。

centroid はレコードではなく可能性だった

RFC 1913 の centroid は、インデックスが参照先を選ぶための圧縮された前方知識だった。テンプレート名、属性名、そして各属性のどこかに一度以上現れた単語を重複なしで保持する。全レコードを複製せずに、ある語が存在しそうな基底サーバーを探せる。

しかし、単語が centroid にあることは、どのレコードにあるか、二つの語が同じレコードに共存するか、情報が新しいか、記述が真実かを示さない。参照を正当化するだけで、結果を返すのは基底サーバーである。centroid の一致、参照の受領、接続成功、レコードの取得は一つの出来事ではない。

RFC 1835 も、分散管理される基底データと、それを見つけるインデックスサービスを分けた。問い合わせと認証の枠組みはあっても、メッシュ全体を代表する単一の真実機関が成立したわけではない。

ブラックリストは認証ではない

偽の WHOIS++ サーバーが持ち込まれる可能性に対し、RFC 1914 はクライアントのブラックリストを挙げた。これは利用者または運用者が特定の相手を拒否する局所的な統制である。リストにない相手すべてが認証済みになるわけではなく、未知と信頼は同義ではない。

参照を出したインデックス、最後に知られた住所を出した Directory of Servers、名前を解決した DNS、接続を運んだネットワーク、応答した基底サーバーは、それぞれ異なる主張をする。クライアントはそれらをローカル方針と組み合わせる。どの受領記録も単独では鎖全体を保証しない。

CIP は負担を制御権として捉え直した

1999年の RFC 2651 は、同じ索引の考え方を Common Indexing Protocol として一般化した。クライアントが難しい仕事を背負うという批判を認めつつ、その責任によって結果集合の大きさ、検索速度、深さを制御できると説明した。単一ルートは拡張性の理由で退けられ、循環処理も引き継がれ、入口の選び方は依然として重要だった。

これは WHOIS++ が世界的に普及した証拠ではない。RFC 2968 の TISDAG シナリオも、後続の実験と提案を示すにとどまる。1996年2月に公開された RFC 1914 は現在 Historic で、WNILS は終了しているが、資料から正確な稼働数、問い合わせ量、実際の応答料金、停止日を逆算することはできない。

残る歴史的教訓は、分散探索の負担と裁量が同じ場所にあったことだ。ルートを一つにしない選択は、調整を消さず、クライアントの探索方針へ移した。

「見つからない」には行程表が要る

負の結果を守るには、元の問い合わせ、明示した地理・属性条件、開始サーバー、受け取ったすべての参照、centroid やポーリング情報の版、ハンドルと接続先、キャッシュ時刻、DNS と接続の結果、既訪問集合、ブラックリスト、時間・回数・料金の上限、利用者が停止した理由が必要になる。

それがなければ、ゼロ件は最初のサーバーにない、centroid に語がない、参照先が古い、代替先も落ちている、高価な枝を切った、循環として省いた、利用者が中止した、あるいは到達可能な範囲を本当に尽くした、のどれでもあり得る。RFC 1914 のメッシュに必須の一つの根はなかった。だからこそ、完全性にはクライアントが残す説明可能な経路が必要だった。

出典