Rendezvous について

Rendezvous ってのは、Apple が提案した標準である、IP 上の zero-configuration ネットワークのことなんだ。ここでは、Rendezvous が解決する問題と、その解決法について話をするぜっ。

なんで Rendezvous？

この 20 年間で、すっごいたくさんの数の広域ネットワークのプロトコルが、現れては消えていったんだ。最近は、ある 1 つのプロトコル、TCP/IP だ、が、すべてのコンピュータでほぼ標準になったんだ。これはすごいことだぜっ、だって大部分のコンピュータと、たくさんのネットワーク機器が、共通の言葉をしゃべるんだからな。

だけど、もう 1 つ別のプロトコルも、それなりの数だけ、生き残っているんだ。これを書いている時点では、Macintosh のユーザには AppleTalk をコンピュータとプリンタにしゃべらせている人もまだいるんだ。ネットワークゲームは、インターネット用に IP と、ローカルエリア用に AppleTalk の両方をサポートしないといけないんだ。TCP/IP は統一的なプロトコルとして現れたんだけど、Mac ユーザは AppleTalk をあきらめることに抵抗し続けているんだ。なんで？

答えは簡単だ。ease-of-use。使いやすいからだ。TCP/IP はまだ設定が大変。AppleTalk はそんなことはない。

たとえば、何台かの Mac OS 9 かそれ以前の Mac を Ethernet ハブでつないだら、簡単に使用可能なプリンタとか、ファイルサーバとか、その他の可能なサービスを全部見つけることができるでしょ。これって、集中管理のためのネットワークアドレスを割り当てることも必要ないし、集中的なネームサーバもないし、可能なサービスの集中管理も必要ないんだ。

伝統的な IP ネットワークだと、こういうことは全然違うんだ。ネットワークアドレスを割り当てるために、固定的な IP アドレスを使わないといけないんだ。さらに、手でそれを入力するんだ。または、誰かが DHCP サーバか、それに似たような動的にアドレスを割り当てるサービスを、セットアップしないといけないんだ。名前からサービスを見つけるためには、誰かが DNS サーバを立ち上げて、名前とアドレスの変換をやらせないといけないんだ。さらに、たいていは、すでに決まっているポート番号（well knwon ports）を調べてきて、それを使ってサービスを使わないといけないんだ。可能なサービスを探すのは、完全に別の問題だ。たくさんの数の IP サービスを探すためのプロトコルが、現れては消えていった。だけど、主流になったものは 1 つもない。ここに挙げたことをやるには、セットアップできるだけの技術的な知識を持ったっ人が必要なんだ。

いわゆるネットワーク管理者じゃない人が、ネットワークのセットアップをするケースは、もっとあるんだ。家族でプリタンや、ファイルや、インターネットへの接続を共有するために、セットアップする。会議でデータを交換するために、臨時のネットワークをセットアップする。会社の中のよく管理されているネットワークであっても、デバイスをつないだり、外したりしないといけない。いまのところ、こういうことは IP アドレスとドメインネームの、手作業での設定が必要になるんだ。

こういう、いわば新しい種類のネットワーク管理者達は、サブネットマスクや DNS サーバの設定をしたくはないんだ。AppleTalk はこういったネットワーク設定の問題を解決してたんだけど、別の欠点によって苦しめられていた。それは、「おしゃべり」であること（訳注：パケットの数が多いこと）、セキュリティモデルが組み込まれていなこと、そして業界から無視されていることだ。業界は IP で標準化されているんだから、IP での設定無し（zero-cofiguration）ネットワークの標準を求めているんだ。Rendezvous がこのニーズを満たすぜ。

設定無し（Zero Configuration）：1 つの例

設定無しネットワークが秘めている力はでかいぜ。毎日やってるプリント作業を考えてくれ。一度、プリンタの設定をすれば、アプリケーションの「印刷」コマンドを選ぶのは、簡単なことだよね。だけど、きみの PowerBook を持って、隣の家の人に編集したムービーを見せに行くとしよう。観賞会が終わったあと、その人が出てた場面を印刷したいかもしれない。もし、その家のプリンタが Rendezvous をサポートしていれば、簡単だ。

印刷しようとして、PowerBook を広げれば、ワイアレスネットワークをすぐに見つけるんだ。で、ワープロで場面のリストを開いて、「印刷」コマンドを選択する。そうすると、その人の家のプリタンタが、プリンタダイアログに自動的に現れるんだ。あとは、「印刷」をクリックして、場面のリストを印刷すればいい。

たとえば、きみの娘のバンドの最近の演奏をあげたい、とも考えるかもしれない。そのときは、音楽共有アプリケーションを立ち上げれば、相手のアプリケーションがすぐにネットワークできみが共有しているファイルを見つけるんだ。これで、音楽ファイルのコピーを作れる。ホストの名前や IP アドレスを打ち込むことなしにね。

このシナリオは、下の図 1 に描かれているんだ。ステップ 1 では、隣の人の家で PowerBook を開ける。そうすると、PowerBook は無線ルータからアドレスが割り当てられるか、自分でローカルアドレスを割り当てる。ステップ 2 では、印刷ダイアログを開けたとき、ネットワークに使用可能なプリンタを尋ねる。そして隣の人のプリンタを見つける。最後に、ステップ 3 では、音楽共有ソフトを立ち上げると、隣の人のコンピュータがそれを見つけて接続する。

印刷とファイル共有は、設定無し IP ネットワークから恩恵を受けれる、すでにあるアプリケーションだ。そこに秘められている力は、ネットワークゲーム、分散プロセスアプリケーション、他にもたくさんのネットワークアプリケーションを助けるんだ。さらに、完全に新しいクラスの IP デジタルデバイスへの扉を開けるぜ。

図 1 典型的な設定無しネットワークのセッション

Rendezvous はいったい何？

Rendezvous は、Apple が提案した IP 上の設定無しネットワークの標準なんだ。Rendezvous は ZERCONF ワーキンググループ、Internet Engineering Task Force (IETF) の 1 つ、から来ていてるんだ。ZEROCONF ワーキンググループの要求と解決法の提案は、基本的に 3 つの領域になるんだ：

Rendezvous はこの 3 つの問題を解決するんだ。設定無しネットワークを問題解決に使うことによって、他のネットワーク標準の利点を残しながら、IP ネットワークが新しい使いやすさを獲得するんだ。家でのネットワークとか、小さいネットワークでシステム管理者を置きたくないようなとこで、IP アドレスを割り当てる必要ないし、ホスト名を付けなくてもいいし、ネットワーク上のサービスを使うためにアドレスを入力する必要すらないんだ。究極的には、ユーザが、どんなネットワークサービスが使えるかを見て、それを使うだけ、っていう感じにするべきなんだ。

アドレス割り当ての問題は、自動割り当てリンクローカルアドレス（self-assigned link-local addressing）で解決されているんだ。あるホストが他のホストにパケットを送るとき、リンクレイヤの payload（Ethernet とかの物理的なネットワークで現れるパケットの中身）がまったく変化しないで届くなら、その 2 つのホストは同じリンクにある、と考えることができるんだ。原理的には、Ethernet ネットワークでは、これは 2 つのホストの間で、IP ルータが関与していない、ってことを意味するんだ。自動割り当てリンクローカルアドレスは、ホストがランダムな IP アドレスをリンクローカルの範囲で拾ってくることで、実現しているんだ。こいつは Mac OS 8.5、Windows 98、Mac OS X version 10.0 の IPv4 で使われているぜ。IPv6 の仕様もこいつを含んでいるんだ。

名前付け問題では、小さな単一ネットワークなら、マルチキャスト DNS を解決法として提案するぜ。これは、DNS のパケットを IP マルチキャストを使って送信する、っていうことだ。Mac OS X version 10.2 からは、ユーザがローカルホスト名を自分のコンピュータ用に選ばなくてもいいんだ。Rendezvous 名が、システム環境設定の共有パネルにあるんだ。この名前は、DNS ホスト名みたいに、どっかに中央で管理する人がいるんじゃないし、そういう人を割り当てなくていいんだ。これは小さな単一ネットワークでのみ重要になるんだ。ネットワークの他の人達は、ssh とか ftp みたいなコマンドラインツールではローカルホスト名を使えるし、Web ブラウザでは URL を使える。実際には、どこでも昔ながらの DNS ホスト名を使えるんだ。システムに、こいつは昔ながらの DNS ホスト名じゃなくて、ローカルなホスト名なんだぜ、っていうことを示すために、.local. っていう拡張子を付け加えるんだ。たとえば、Web ブラウザで steve.local. って打てば、DNS サーバに訊きにいくんじゃなくて、ローカルネットワークにマルチキャストで訊く、っていうことになる。つまり、DNS にアクセスできない状況でも、Rendezvous のホストにはつなげることができる、っていうことだ。

Rendezvous のホスト名の後に .local. って打つのがめんどうくさいなら、システム環境設定のネットワークパネルの検索ドメインに、apple.com とか earthlink.net とかいう感じで local って入れればいいんだ。この自動的に .local. を付加しない、ってのはわざとユーザの選択にまかせたんだ。予想しないマルチキャストを嫌う人もいるからね。

Rendezvous の最後の要素は、サービスの検索だ。サービス検索は、アプリケーションが可能なサービスを見つけだしてくることができて、そいつの IP アドレスとポート番号を解決できるようにするんだ。Rendezvous の解決法は、ローカルネットワークのサービスの情報を、マルチキャスト DNS の DNS resource records に入れておく、っていうことだ。Mac OS X の将来のリリースでは、Dynamic DNS Update を使って、昔ながらの DNS サーバのレコードに入れておくのも対応すると思うよ。

サービスはデバイスじゃないよ

サーバとかネットワーク機器とかネットワークプログラミングとかを扱っていると、サービスっていう言葉を物理的なハードウェアと勘違いしちゃうのはしょうがないよね。これは忘れよう。デバイス中心な見方だと、ネットワークはたくさんのホストとデバイスの集まりで、それぞれがサービスを持っていた。たとえば、ネットワークはサーバマシンとクライアントマシンでできている。デバイス中心な見方だと、クライアントはサーバにどんなサービスがあるか訊きにいって、リストを得る（FTP とか HTTP とか）。で、どのサービスを使うか決める。ある意味では、これはネットワークの実際のレイアウトを模倣している。それぞれのサービスは、たぶん同じ物理ハードウェアで動いている。インタフェースはシステムを模倣している。

ユーザから見ると、デバイス中心の見方はとても使いやすいってわけじゃない。ユーザは、仕事を片付けたいわけで、デバイスにどんなサービスがあるか訊きたいわけじゃない。「どのプリンタが使えるの？」っていう質問は、それぞれのデバイスに「どんなサービスが動いているの？」って訊いてから、結果から割り出すのより、ずっと分かりやすい。

さらに言えば、サービスは特定の IP アドレスやホスト名に、常に結び付けられているわけじゃない。Web サイトは、よく違ったアドレスのたくさんのサーバにホスティングされている。この場合、ホスト名はサービスを表している、とも言える。組織の中では、ネットワーク管理者が、負荷のバランスを取るために、サービスのサーバを動かすかもしれない。クライアントがホスト名を記録していたら（いまんとこ多くの場合そうなんだけど）、サービスのホストが変わったらアクセスできないよね。

Rendezvous はサービス中心の見方を使うんだ。ホストではなくて、サービスのタイプで訊きにいくんだ。アプリケーションはサービスの名前を保持するんだ、アドレスじゃないよ。だから、ポート番号や、IP アドレスや、ましてやホスト名が変わっても、アプリケーションは接続することができるんだ。デバイスよりサービスに集中することで、ユーザのブラウジングはもっと使いやすくなって、トラブルが起きにくくなるんだ。

「おしゃべり」を避ける

Rendezvous は、AppleTalk レベルの使いやすさを、その主要な欠点であった、「おしゃべり」を避けながら達成したんだ。サーバなしアドレス割り当て、名前割り当て、サービス検索は、ネットワークのトラフィックを深刻なまでに増大する可能性があるんだ。だけど、Rendezvous にはこのトラフィックを最小にするための、いくつかのステップがあるんだ。

Rendezvous が使うオーバーヘッドを減らすための機構は、以下の通りだ。

キャッシュ

Mac OS X がマルチキャスト DNS を受けて返事をしたら、そいつをキャッシュしておくぜ。これですでに訊かれた情報については、マルチキャストしなくて済む。たとえば、あるホストが LPR のプリンタスプーラを訊いてきたら、プリンタのリストがマルチキャストされる。それはすべてのホストが見るんだ。次にあるホストがプリンタスプーラのリストが必要なったら、それはもうキャッシュにあるんで、もう一回訊きにいく必要はないんだ。

同じ返事を控える

同じ質問に対する同じ答えを避けるために、サービスの質問はすでに分かっている答えを含むんだ。たとえば、あるホストがプリンタをブラウズしようとする。最初の質問にはなにも含まれていなくて、答えを得る。仮に 50 のプリンタサービスがあったとしよう。そのホストが次にプリンタサービスについて質問するときは、質問はすでに分かっている 50 のプリンタサービスを含むんだ。そのリストに入っていないプリンタサービスを持っているホストだけが、その質問に答えるんだ。

Rendezvous が使う方法は他にもある。あるホストが、別のホストがすでに同じ質問に答えているのに気付いたら、そのホストは返事をするのを控えるんだ。

指数関数的な遅れとサービスのアナウンス

ホストがサービスをブラウズしていたら、新しいサービスが来たかどうか見るために、連続的にひたすらネットワークを見にいくわけじゃないんだ。ホストは最初の質問を送った後、次の質問を指数関数的に遅らせるんだ。1 秒後、2 秒後、4 秒後、8 秒後、って感じで。最大値は 4096 秒後だ（1 時間強）。

これは、新しいサービスを見つけるのに 1 時間かかるっていうことじゃないよ。ネットワークでサービスを始めるときは、新しいサービスが来たよーん、っていうアナウンスを同じように指数関数的に遅らせて送る。これが、バックグラウンドでの雑音を最小にして、かつ新しいサービスをすぐに見つけるための方法だ。