要約

  • 問題は予測できる。サービスが再起動後に空きポートを選び直すと、古い接続先を覚えたクライアントは呼び出せない。固定ポートを全プログラムに割り当てれば、今度は共有ポート空間の調整が必要になる。
  • RFC 1057のPortmapperは、変わる接続先を固定の照会口から調べられるようにした。ただし回答が示すのはホスト上の登録であり、稼働や応答者の身元ではない。

サービスのポートは変わり、照会先は変わらない

仮定の例を考えよう。ファイルサービスの再起動後、サーバーは別の空きポートで待ち受け、クライアントは以前のポートへ要求を送る。ホストもRPCプログラムも同じなのに、接続先だけが変わったため要求は届かない。クライアントは新しい位置を推測できず、全サービスに固定ポートを求めれば、今度は限られたポート番号の調整が増える。

Sun Microsystemsが1988年6月に公開したRFC 1057は、別の仕組みを記述した。プログラム番号とバージョンはクライアントが求めるサービスを示し、TCPまたはUDPが転送方式を示す。既知の111番ポートで待ち受けるホスト上のPortmapperが、それらをサーバーの選んだポートに対応付ける。クライアントはまず照会し、その後でサービスに接続する。RPC呼び出しと接続先の解決は別の段階だった。

PMAPPROC_SET は登録を行う。サーバーは同じホスト上のmapperに、プログラム番号、バージョン、転送プロトコル、待受ポートを渡す。同一のプログラム・バージョン・プロトコルの組み合わせは重複登録できない。サービス終了時には PMAPPROC_UNSET で登録を取り消す。クライアントの PMAPPROC_GETPORT に対してゼロが返れば、その組み合わせの登録はない。

役割分担は明快だった。サービスが待受位置を選び、mapperが予測可能な入口からその選択を公開し、クライアントが返されたポートを使う。照会の慣例は固定され、サービスの宛先は動的だった。

照会結果が示さないこと

mapperの回答が示すのは、そのホストの登録表の内容である。RFC 1057は GETPORT を経路全体のヘルスチェックとも、ネットワーク経路が開いている証明とも、ポートを使うプログラムの暗号学的な身元証明とも定めていない。クライアントは接続し、RPCを呼び、結果を解釈しなければならない。サービスが停止しても登録が残れば、照会は成功して接続は失敗する。登録自体がなければ、接続先の解決で失敗する。

「見つかった」という言葉は「登録されている」より強く聞こえやすい。ポート番号が示すのは、そのサービスがそこを待受先として登録したということだけだ。パケットが届くか、サービスがこのクライアントを受け入れるか、要求した手続きが完了するかは分からない。RFCは認証と転送の意味を別に扱い、Portmapperがそれらを代行するとはしていない。

登録表は世界中のRPCプログラムを載せる台帳でもない。サービスを動かすホストごとのローカルな表だった。クライアントは別の情報源からホストアドレスを得て、そのホストのmapperにポートを尋ねる。つまり発見は層に分かれる。名前や設定がホストを示し、プログラム番号とバージョンがインターフェースを選び、Portmapperが転送先を返す。

RFC 1057には登録一覧を返す PMAPPROC_DUMP と、ブロードキャストRPCを支援する PMAPPROC_CALLIT もある。クライアントはブロードキャスト先の固定mapperポートへ要求を送り、受信した各mapperはローカル登録サービスを呼び出せる。RFCの規定では、実行が成功した場合だけ結果が返り、それ以外は応答しない。ホストごとにサービスのポートが違っても呼び出しを試せるが、配信保証や応答ホスト全体の一覧にはならない。

プログラム番号にも調整の境界があった。RFC 1057はSun定義、利用者定義、一時利用、予約済みの範囲を分けた。論理的なプログラム識別子は、動的な転送ポートと別に保たれる。番号はRPCプログラムを指し、ホストごとに解決する値はその実体の待受場所を指す。

TCP/UDPポートから汎用アドレスへ

初期のPortmapperはTCPとUDPのポート番号を扱った。1995年のRFC 1833はPort Mapperのバージョン2に加えて、RPCBINDバージョン3と4を記述した。サービスの転送先が起動ごとに変わり得る一方で、クライアントはサーバーのアドレスにある既知の照会先を必要とする。RPCBINDは転送アドレスを汎用アドレス文字列で表し、ネットワーク識別子も持たせたため、TCP/UDPポート以外へ対応範囲を広げた。

後年の文書は、1988年の設計範囲をはっきりさせる。RFC 1057はRPCプログラムを一つの転送ポートに固定せず、プログラムとバージョンを転送方式ごとの待受先へ結び付ける照会慣例を定義した。RFC 5531も後に、RPCのメッセージ形式とバインディング、ランデブーの仕組みを独立したものとして記述している。

この仕組みの利点は限定的だが明確だった。共通の照会規約を使えば、クライアントはサービスのポートを事前に知る必要がない。固定ポートの消費を抑え、各インスタンスがローカルにポートを選べる。その代わり、呼び出し前に照会が一回増え、起動、登録、停止、登録解除に追随する状態管理が必要になる。

RFCが記録するのは設計であって、当時の導入数や実測の信頼性ではない。古い登録がどの程度発生したか、各システムがどれほど早く修正したかは示さない。確実に言えるのは構造のことだ。Portmapperは安定したローカル照会先を通じてRPCの接続先を探せるようにしたが、到達性、認証、手続きの成功は後続の確認に残した。

一次資料：RFC 1057 — RPC version 2、RFC 1833 — ONC RPCのBinding Protocol、RFC 5531 — ONC RPC version 2。