平成 16 年度卒業研究発表会（日本大学工学部情報工学科） G-9 Tapestry を利用したインスタントメッセンジャーの提案 Instant Messenger Application in P2P Network based on Tapestry 136087 １ 白石俊之 １桁けが一致することを表す。レベルの数は、ノード ID の桁数と一致する。それぞれのレベルでのエントリ数は、 ノード ID の基数と一致する。例えば、ノード ID が８進 数４桁ならば、レベルの数は４個となり、それぞれのレ ベルでのエントリ数は８個となる。また、エントリの重 複はありえる。図 1 は、ノード ID が 4 進数 4 桁のとき の例である。 はじめに インスタントメッセンジャー（以下、IM）とは、事前 に登録したメンバー間でメッセージ（文字列やバイナリ データ）交換を行うアプリケーションである。IM の１つ に、Microsoft[1]が提供している MSN Messenger[2]があ る。MSN Messenger では、メンバーリストなどの情報 はすべてサーバーに格納され、メンバーのオンライン／ オフラインの管理もサーバーが行う。また、メッセージ もサーバー経由で送信される。従って、MSN Messenger は、クライアント／サーバー型システムである。一方、 本稿では、IM を、P2P 型システムで実装する方式を提 案する。 ２ ノード ID : 3201 L1 L2 L3 L4 ４．２ 1 1030 3132 3211 - 2 2100 3220 3202 3 3311 3232 3203 隣接マップ メッセージの送信 メッセージを特定ノード宛に送信するには、まず自身 の隣接マップの中から、メッセージの宛先ノード ID に最 も近いエントリを取得し、該当ノードにメッセージを転 送する。それを受信したノードも同様に、隣接マップの 中から宛先ノード ID に最も近いエントリを取得し、該当 ノードにメッセージを転送する。これを宛先ノードまで 繰り返していくことで、メッセージが宛先まで届けられ る。この処理の流れを図２に示す。また、宛先ノード ID は、必ずしも存在するノードのものである必要はない。 存在しないノード宛にメッセージを送信することもでき る。その場合、宛先ノード ID に最も近いノード ID を持 つノードに届けられる。このノードのことを、Tapestry ではルートノードと呼んでいる。 P2P 型システムで実装する上での問題点 3200 0203 src L1 1030 1210 図２ ５ L2 0112 L2 2100 Tapestry は、DHT (Distributed Hash Table)の 1 つで ある。それぞれのノードは、一意のハッシュ値（ノード ID と呼ばれる）で識別される。Tapestry では、それぞ れのノードを識別可能であるため、ある特定のノードと メッセージの交換が可能である。 2103 1101 3201 Tapestry ４．１ 0 0203 3012 3200 図１ MSN Messenger [2]では、それぞれのクライアントは 電子メールアドレスで識別される。クライアントは、オ ンライン中はサーバーに常時接続しており、メッセージ はサーバー経由で送信される。そのため、メンバー間で メッセージを交換するとき、お互いに相手の IP アドレス を知らなくても問題ない。しかしながら、P2P 型システ ムでは相手の電子メールアドレスを知っていても、IP ア ドレスを知らないと通信ができない。この場合、どのよ うな方法で相手の IP アドレスを取得するのかが問題に なる。この問題を解決するために Tapestry [3]を利用す る。また、P2P 型システムでは、メンバーリストやメン バーのオンライン／オフライン状態を管理するサーバー が存在しないため、これらの情報はそれぞれのノードが 管理する必要がある。 ４ (****) (3***) (32**) (320*) IM の実装に必要な機能 IM を実装する上で、以下の４つの機能が必要となる。 (1) メンバー（ノード）の識別 (2) メンバー登録および、メンバーリストの管理 (3) メンバーのオンライン／オフライン状態の管理 (4) オンラインメンバーへのメッセージの送信 ３ ［竹中研究室］ dest L4 1213 メッセージの送信 提案方式 ５．１ Tapestry を利用する利点 Tapestry を利用する利点は、P2P 型システムにおいて、 それぞれのノードを一意のハッシュ値によって識別でき ることである。IM では、登録したメンバーとのみ通信を 行うため、どのノードがメンバーなのかを判断するため にも、それぞれのノードを識別できる必要がある。 また、ノード ID に変化しないものを使用することで、 IP アドレスの変化に対応できる。隣接マップのエントリ は、該当ノードが Tapestry に参加してくるたびに更新さ れる。そのため、ノード ID が変化しない限り、IP アド レスがいくら変化しても、メッセージの転送処理には影 響を与えない。 隣接マップ Tapestry では、それぞれのノードが隣接マップと呼ば れる、自身のノード ID と近いノード ID で構成されてい るルーチングテーブルを保持する。隣接マップのエント リは、ノード ID とそれに対応した IP アドレスである。 隣接マップのエントリは、図１のように、自身のノー ド ID と先頭から何桁まで一致するのかによってレベル 分けされている。レベル１（L1）は、自身のノード ID と１桁も一致しないことを表し、レベル（L2）は、先頭 19 平成 16 年度卒業研究発表会 G-9 ５．２ になったときも同様である。しかし、提案方式ではメン バーの状態を管理するサーバーが存在しないので、それ ぞれのノードで対応する必要がある。そのため、ノード は Tapestry に参加した後、自身のメンバーリストに登録 されているノードに、 「オンライン通知メッセージ」を送 信する。このメッセージを受信したメンバーは、メッセ ージの送信元に自身の「オンライン通知メッセージ」を 返信する。一方、オフラインになるときは、 「オフライン 通知メッセージ」をメンバーに送信する。このメッセー ジを受信したメンバーは、メッセージの送信元のメンバ ーがオフラインになったと判断する。これらの処理によ り、それぞれのノードはメンバーのオンライン／オフラ インの状態を確認することができる。 何らかの障害が発生して、ノードがメンバーに「オフ ライン通知メッセージ」を送信せずに、オフラインにな る可能性もある。これを考慮して、ノードは定期的（例 えば、１分間隔）に「生存通知メッセージ」を送信する ことにする。もし、このメッセージを受信しなくなれば、 該当メンバーがオフラインであると判断する。 ノードの識別子 Tapestry のノード ID には、１６進数４０桁（１６０ ビット）の値が使用される。これは、人間にとって非常 に覚えづらい。ノード ID は、次項で説明するメンバー登 録時に相手から教えてもらう必要があるため、なるべく 人間にとって覚えやすいものが望ましい。そのため、ノ ード ID は、MSN Messenger のように電子メールアドレ スを使用し、そのハッシュ値を用いる。電子メールアド レスは、単なる数字の羅列に比べれば、人間にとって圧 倒的に覚えやすい。また、電子メールアドレスであれば、 重複する心配もない。 ５．３ メンバー登録 メンバー登録を行う場合、登録したいノードの識別子 を、何らかの方法で知る必要がある。次に、登録したい ノードをメンバーリストに仮登録し、それの識別子のハ ッシュ値（ノード ID）宛に「メンバー登録要求メッセー ジ」を送信する。これに対する返信メッセージがない場 合は、相手ノードがオフラインであると判断し、一定期 間（例えば、２時間）定期的（例えば、５分間隔）にそ のメッセージを送信し続ける。 「メンバー登録要求メッセ ージ」を受信したノードは、登録を許可するか、拒否す るかの返答をメッセージの送信元に返送する。もし、返 信メッセージの内容が「登録許可」であれば、メンバー の仮登録を本登録にする。もし「登録拒否」であれば、 仮登録したメンバーを削除する。これらの処理により、 ユーザーが許可したノードのみがメンバーリストに追加 される。メンバーリストは、それぞれのノードのローカ ルディスクに格納される。 ５．４ ５．６ Tapestry の場合、メッセージが宛先に届くまでに、複 数ノードを経由することになる。チャットの場合は交換 されるメッセージは短い文字列のため、メッセージのサ イズは小さくなる。しかし、ファイル転送の場合は、メ ッセージのサイズも大きくなり、転送に時間かかるため、 経路上のノードに負荷をかけることになる。そのため、 メンバー間は直接通信することが望ましい。しかしメン バーと直接通信するためには、相手の IP アドレスを取得 する必要がある。IP アドレスの取得には、Tapestry を利 用する。あるノードの IP アドレスの取得したい場合は、 そのノード宛に「IP アドレス要求メッセージ」を送信す る。このメッセージを受信したノードは、自身の IP アド レスを含むメッセージを返信する。この処理によって、 ノードは任意のノードの IP アドレスを取得することが できる。IP アドレスの取得後は、Tapestry を利用せず、 メンバー間で直接通信する。 メンバーリストのバックアップ メンバー登録により作成されたメンバーリストは、ク ライアント／サーバー型システムの IM の場合、サーバ ーに保持されるため、消える可能性は非常に低い。しか しながら、提案方式の場合、メンバーリストはそれぞれ のノードが各自保持するため、OS の再インストールなど の理由により消える可能性がある。そのため、メンバー リストのコピーをバックアップとして、他の複数のノー ドに保持させることにする。 メンバーの追加や削除などによりメンバーリストが更 新されると、ノードは自身のノード ID のハッシュ値を n 回計算し、異なる n 個の ID を生成する。次に生成した ID 宛に、自身のメンバーリストのコピーを含むメッセー ジを送信する。このメンバーリストのコピーは、それぞ れの ID のルートノードに保持される。 メンバーリストが消えてしまった場合、メンバーリス トのコピーを送信したときと同じ方法で、n 個の ID を生 成し、その ID 宛に「メンバーリスト要求メッセージ」を 送信する。このメッセージを受信したノードは、該当す るメンバーリストのコピーを保持しているか調べ、もし 保持していれば、メッセージの送信元に該当するメンバ ーリストのコピーを送信する。この処理によって、ノー ドは、自身のメンバーリストを取得できる。 ５．５ メンバー間の通信 ６ むすび 今回は、Tapestry を利用して P2P 型システムで IM を 実現する方式を提案した。しかしながら、提案方式では 通信の安全性に関しては考慮していない。例えば、 Tapestry の場合、メッセージが宛先まで到達するまでに 複数のノードを経由する。その場合、経路上の悪意のあ るノードによって、メッセージの内容が改竄されるかも 知れない。また、悪意のあるノードが、別ノードのノー ド ID を使って、成り済ましを行おうとするかもしれない。 また、ノード ID が偶然重複してしまうこともあるかもし れない。今後は、このようなことを防ぐことができる方 式を提案するとともに、実際に動作するアプリケーショ ンの開発を行う予定である。 参考文献 [1] Microsoft Corporation http://www.microsoft.com [2] MSN Messenger http://messenger.msn.co.jp [3] Ben Y. Zhao/John Kubiatowicz et al., Tapestry: An infrastructure for fault-tolerant wide-area location and routing. Tech. Rep. UCB/CSD-01-1141, University of California at Berkeley Computer Science Department, 2001 オンライン／オフライン状態の確認 クライアント／サーバー型システムの IM では、メン バーのオンライン／オフラインの状態は、サーバーが管 理している。あるメンバーがオンラインになると、その ことを他のメンバーにサーバーが通知する。オフライン 20
© Copyright 2024 Paperzz
