平成１５年度卒業論文 P2P 技術を用いたチャットの研究 情報通信工学科 情報通信システム学講座 0010135 渡辺 陽介 指導教官 寺田 実 助教授 提出日 ２００４年 １月３０日 概要 研究目的 計算機による人と人とが会話を行うツールの需要が増えてきた。現在、公開されてい るチャットシステムは Server Client モデル、Hybrid P2P モデルをとっているものばか りで Pure P2P モデルをとっているものはない。もし Pure P2P モデルで実現できれば、 Single Point of Failure の解決になりシステムの信頼性、安定性も向上すると考えられ る。さらに既存のチャットシステムの長所、短所も調査することによって、利便性のある Pure P2P モデルのチャットシステムを作成することが本研究の目的である。 方法 予備実験として、Sever Client モデル、Hybrid P2P モデルのチャットツールを作成す る。最後に本研究の目標である Pure P2P モデルのチャットツールを作成し数十ノードの 小さなネットワークで実用実験を行い、その他のモデルとの違い (Single Point of Failure の解決になったか) や既存のチャットツールとの比較をし、評価する。 結論 Client Server モデルや Hybrid P2P モデルで稼動しているチャットシステムの問題点 である Single Point of Failure の回避を PureP2P モデルでチャットシステムを稼動させ 実現させた。技術的な問題として抱えていたアカウント管理や初期接続先問題を最善に解 決することには至らなかったが、本実験で行った、数十ノードで構成される小さなネット ワークでは、サーバーを必要としない、このチャットツールは、Hybrid P2P モデルで作 成されたチャットツールより実用性高いものと評価できた。 2 目次 目次 序論 5 1.1 本研究の背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 本研究の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 本研究の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1 関連研究と本研究の位置付け 10 2.1 関連研究 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 関連研究と本研究の位置付け . . . . . . . . . . . . . . . . . . . . . . . . 19 システムの設計 20 3.1 予備実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2 システムの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 システムの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2 3 実装 4 26 4.1 個人情報の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 ネットワークに参加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3 ネットワーク介入成功時 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4 他ノードの表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5 他ノードとの会話 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.6 ネットワークからの離脱 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 評価 34 5.1 方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.2 実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3 結果・考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 結論 36 結論・今後の課題と展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5 6 6.1 謝辞 38 目次 3 参考文献 39 付録 40 4 図目次 図目次 1 ネットワークモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 LimeChat(IRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Yahoo メッセンジャーメイン画面 . . . . . . . . . . . . . . . . . . . . . 11 4 Yahoo メッセンジャー会話画面 . . . . . . . . . . . . . . . . . . . . . . 12 5 Yahoo メッセンジャーログインアラート . . . . . . . . . . . . . . . . . 12 6 Yahoo メッセンジャーログアウトアラート . . . . . . . . . . . . . . . . 12 7 MSN メッセンジャーメイン画面 . . . . . . . . . . . . . . . . . . . . . 13 8 MSN メッセンジャー会話画面 . . . . . . . . . . . . . . . . . . . . . . . 14 9 MSN メッセンジャーログインアラート . . . . . . . . . . . . . . . . . . 14 10 Gnutella ネットワークへの参加 . . . . . . . . . . . . . . . . . . . . . . 15 11 Gnutella ping・pong のルーティング . . . . . . . . . . . . . . . . . 16 12 Gnutella query・queryHit のルーティング . . . . . . . . . . . . . . 17 13 Gnutella push のルーティング . . . . . . . . . . . . . . . . . . . . . 18 14 サーバー用プログラム会話画面 . . . . . . . . . . . . . . . . . . . . . . 21 15 クライアント用プログラム会話画面 . . . . . . . . . . . . . . . . . . . . 21 16 クライアント用 Main Window . . . . . . . . . . . . . . . . . . . . . . 23 17 他クライアントとの会話画面 . . . . . . . . . . . . . . . . . . . . . . . 23 18 Info Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 19 同時期介入の問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 20 Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 21 IM Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1 序論 5 1 序論 1.1 本研究の背景 近年、計算機およびパーソナルコンピューター（PC）の普及が進み、また各計算機の 処理速度も記憶容量もかつてとは比べられないほど速く大きくなり、今も向上し続けてい る。同時に計算機同士を結ぶネットワークも各職場、各家庭まで届くようになった。 DSL(Digital Subscriber Line)、光回線により伝送速度も大幅に上がった。ネットワー クで繋がれたことにより、離れた場所にいる人たちとデータのやり取りが可能になった。 当然、離れた場所にいる人と会話をしたいと思う。そういった時の会話の方法の一つと して E-MAIL が挙げられる。E-MAIL の利点として、送信が容易で２４時間いつでも送 れる等の利点もあるが、しかし送信者にすぐ読んでもらえるかというのは E-MAIL では 保証できない。 E − MAIL の他にチャットと言うものがある。チャットとは他の人と計算機を通して 会話する事である。チャットの初めは、テキストのみの会話であったが、伝送速度や計算 機の処理速度の向上により、音声会話やカメラによる映像のやり取りをも可能としてい る。チャットの利点としては電話と同じように同期的に会話ができる。読み手側も計算機 のモニター上で他の作業をしながら会話をすることができるので電話のように相手の時間 を完全に奪ってしまうものではなく、読み手側が取捨選択できるのである。このような利 点があり職場での利用も取り入れられつつある [1]。 1.1.1 ネットワークモデル 計算機どうしがネットワークでつながるモデルとして大きく三つ上げられる (図 1)[2] ■Client Server モデル クライアントがサーバーにのみコネクションを張る 例：www などの主要アプリケーション ■Hybrid P2P モデル サーバーから他のクライアントの情報を得ることで、クライアント同士、P2P にコネク ションを張ることができる 1 序論 6 例：NAPSTER、MSN メッセンジャーのような主要 IM ツール ■Pure P2P モデル ノード同士で P2P でコネクションが張ることができる。 例：Gnutella[3]、WINNY[4]、FREENET[5] 図1 1.1.2 ネットワークモデル 公開されているチャットシステム ■IRC（Internet Relay Chat） [6] 1988 年にフィンランドで開発され、1990 年には日本でも利用が開始されたネットワー クリアルタイム会議システム。IRC では、同時に世界中にいる多数の相手と会話を行なう ことができ、いつでも好きな時に会話に参加したり会話から抜け出したりする事が可能で あるなど、talk や phone と比較して非常に便利なシステムになっている。 そもそもは日本国外で UNIX 上で開発されたシステムだが，現在ではさまざまな人々 の努力により UNIX, Windows, Macintosh などのさまざまな環境から利用できる。日本 字による会話を行なえるようなクライアント (ユーザが利用するプログラム) も数多く作 られている． IRC サーバ は IRC クライアントから、チャンネル作成などの様々な要求を処理する． サーバーは一般に単体でも動作するが，他のサーバと連携することにより，複数のサー 1 序論 7 バー群全体が 1 つのシステムを構成することもできる．このことにより，IRC は全世界 中の人々が同時に会話することを実現している．また複数のサーバーを持つことにより回 線の飽和、サーバーの処理の負担を分散させている。 1 対 1 の会話はもちろんのこと、チャンネルと言われるユーザーによって作成可能な部 屋に他ユーザーが参加することで複数人で会話することも可能。またファイル転送も可能 である。 ■Yahoo メッセンジャー [7] MSN メッセンジャー [8] Hybrid P2P モデルをとっているメッセンジャーツール。インスタントメッセージ （IM）の送受信が可能であり他クライアントの状態（接続中であるか等）もサーバーを介 して知ることができる。 Yahoo メッセンジャー 対応 OS は Windows 版、Macintosh 版 (OS 8.6 以上)、Java 版、i アプリ版 (携帯電 話) 、EZweb 版 (携帯電話) と多様なプラットフォーム、キャリアを持つ。特徴は高機能 なチャット（複数人で音声会話、WEB カメラによるリアルタイムの動画配信）ができる。 また、ニュースや株式などの情報サービスもあり、同アカウントで作成された Yahoo メー ルに受信するとアラートを発したり Yahoo オークションとも連動していて、高値を更新 したり、落札すると同様にアラートが発せられる。またファイル交換も可能である。 MSN メッセンジャー 対応 OS は Windows のみ。特徴としては Hotmail との連携で機能やサービスに富ん でいる。インターネットに接続すると、すぐに Hotmail の有無を確認し、着信があれば メッセージを表示してくれる。ファイル交換や電話をかける事も可能、WEB カメラによ る動画配信も可能で機能が豊富、かつ操作しやすい。 これらのメッセンジャーツールはクライアント∼サーバー間で主にマスターデータ（ア カウントデータ、ユーザーデータ）のやり取り、そしてメッセージのやり取りを行ってお り、クライアント∼クライアント間ではファイル交換（Peer to peer（P2P））を行って いる。 P2P でコネクションを張るには相手側の情報をサーバーから得る為、サーバーとコネ クションを張っていなければならない。 1 序論 1.1.3 8 Single Point of Failure Client Server モデル、Hybrid P2P モデル両方に抱える問題点として Single Point of Failure というのがある。これは、サーバーに障害が発生してしまうとシステム全体に障 害が発生してしまうということである。 これを回避するためのネットワークモデルが Pure P2P モデル、つまりサーバーを持た ないネットワークモデルでシステムを組むことである。これにより１点集中のサーバーと いうものがなくなり Single Point of Failure が回避される。今までサーバーが行っていた 処理を各ノード（今までに言うクライアント）に分散させてしまおうというものである。 各ノードを、サーバー + クライアントでサーバント (Servents) とも言う。 Pure P2P で稼動しているシステムは実現している。例として Gnutella、winny、 Freenet 等がある しかしチャットシステムでは、まだこの Pure P2P モデルを用いたものは実現されてい ない。要因の 1 つとして、サーバーが介在しない Pure P2P ネットワークモデルにおい て、アカウント管理に基づく個人認証システムの構築が難しいからであると思われる。 1.2 本研究の目的 前節で述べたとおり、計算機による人と人とが会話を行うツールの需要が増えてきた。 現在、公開されているチャットシステムは Server Client モデル、Hybrid P2P モデルを とっているものばかりで Pure P2P モデルをとっているものはない。もし Pure P2P モ デルで実現できれば、Single Point of Failure の解決になりシステムの信頼性、安定性も 向上すると考えられる。さらに既存のチャットシステムの長所、短所も調査することに よって、利便性のある Pure P2P モデルのチャットシステムを作成することが本研究の目 的である。 1.3 本研究の構成 この章では、序論 として、本研究の背景・目的について述べた。 第 2 章では、関連研究として、既存のチャットシステム、Pure P2P モデルのファイル転 1 序論 送システムについて紹介し、本研究がどのように位置付けられるのかを述べる。 第 3 章では、予備実験と本研究で作成するシステムの設計について述べる。 第 4 章では、設計に基づいた実装を行い、一連の流れを説明する。 第 5 章では、作成した Pure P2P モデルのチャットをテストした結果・考察を述べる。 第 6 章では、今後の課題・展望を述べ、結論とする。 9 2 関連研究と本研究の位置付け 10 2 関連研究と本研究の位置付け 2.1 関連研究 2.1.1 一般的につかわれているチャットシステム 前章で例をあげた３つの会話システムについて、どのような機能であり、GUI(Graphical User Interface) であるかを紹介する。 ■LimeChat(IRC Client ソフト)[9] • Client Server モデル • Lime Chat 以外にも様々なクライアントソフトが配布 • #(チャンネル名) と称される部屋で複数人で会話可 • (図 2) の右上のユーザー名が部屋にいる • @(ユーザー名) は、部屋におけるさまざまな権限を持つ 図 2 LimeChat(IRC) 2 関連研究と本研究の位置付け ■Yahoo メッセンジャー 11 • Hybrid P2P モデル • アカウントを YAHOO の WEB サイト [7]、もしくはクライアントソフト (図 3) か ら取得することで、どの計算機からもログイン可 • チャットルームを作成、参加することができる。 • 音声、動画チャットも可能 • ファイル送信、受信拒否などマウス操作で可能 • ID 検索が可能 • 各自が作ったプロフィール、ピクチャーフォルダを公開、閲覧可 • メイン画面の下部のタブの変更によりニュースや天気など閲覧可 (図 3) • 自分の状態をアイコン、テキストで知らせることができる (退席中など)(図 3) • チャットでは文字色、フォント、大きさが自由に変更可 (図 4) • アイコンや絵文字がチャットで使用可 (図 4) • 相手が入力中ならメッセージが会話画面下部に出る (図 4) • 友達リストに入ってる人がログイン、ログアウトするとアラート (図 5)(図 6) 図 3 Yahoo メッセンジャーメイン画面 2 関連研究と本研究の位置付け 図 4 Yahoo メッセンジャー会話画面 図5 Yahoo メッセンジャーログインアラート 図 6 Yahoo メッセンジャーログアウトアラート 12 2 関連研究と本研究の位置付け 13 ■MSN メッセンジャー • Hybrid P2P モデル • アカウントを MSN の WEB サイト [8] から取得することで、どの計算機からもロ グイン可 • ファイル送信、受信拒否などボタンを押すことで可能 • 音声、動画チャットも可能 • 自分の状態をアイコン、テキストで知らせることができる (退席中など)(図 7) • 会話では文字色、フォント、大きさが自由に変更可 (図 8) • アイコンや絵文字が用意されている (図 8) • 相手が入力中ならメッセージが会話画面下部に出る (図 8) • 友達リストに入ってる人がログインするとアラート (図 9) 図 7 MSN メッセンジャーメイン画面 2 関連研究と本研究の位置付け 図 8 MSN メッセンジャー会話画面 図 9 MSN メッセンジャーログインアラート 14 2 関連研究と本研究の位置付け 2.1.2 15 Pure P2P モデルをネットワークモデルとするシステム Gnutella、winny、Freenet 等、Pure P2P モデルをネットワークモデルとするシステ ムは稼動している。その中で Gnutella のプロトコルを紹介する ■Gnutella [2] • Pure P2P モデルのファイル共有、転送ソフト • ５種類の Descriptor によるメッセージのやり取りをする • 分散検索 接続からファイルのダウンロードまでの流れ １．TCP/IP コネクションの確立 ２．ネゴシエーション ３．Ping,Query の送信 (検索) ４．QueryHit の受信（検索結果） ５．ファイルのダウンロード（HTTP） ネゴシエーション ネットワークへの参加は (図 10) のように行う 図 10 Gnutella ネットワークへの参加 2 関連研究と本研究の位置付け 16 5 つの Descriptor ネットワーク状態を調べる、検索をかける、検索結果を返すなどの機能を持つメッセー ジを Descriptor と呼ぶ。Gnutella では、必要なときに適切な Descriptor を送受信するこ とで、検索とファイル交換機能を実現する ネットワーク上の他ノードの情報を得る ping・pong 以下の二つの Descriptor により知る。 • ping ： ネットワーク上の他ノードをの情報を知るのに使う。ping を受け取っ たサーバントは ping を broadcast し、pong を sendback する。 • pong ： ping への返答。接続された Gnutella サーバントのアドレス、及び、 ネットワークへと利用可能なデータの総量の情報を含む 図 11 Gnutella ping・pong のルーティング 右側のノードから ping を受け取ったノードは、自分の情報を付加した pong を右側のノー ドに sendback し、他のノードには ping をブロードキャストする。(図 11)。 2 関連研究と本研究の位置付け 検索の様子 query・queryHit 17 ファイルの検索を以下の二つの Descriptor により行う。 • query ： ファイルの検索をかける • queryHit ： 検索にヒットするファイルを持っているノードだけがこれを sendback する 図 12 Gnutella query・queryHit のルーティング 左下のノードから broadcast に発せられた query。query に Hit するファイルを持ってい なければ、他のノードに query を broadcast。query に Hit するファイルを持っていた右 下のノードは query をたどった道順をさかのぼって queryHit が左下の発信者まで返され る (図 12)。 2 関連研究と本研究の位置付け 18 ファイルの転送 push 通常は、HTTP GET メソッドで相手から直接ダウンロード。ファイルのリレー転送は しない。もしファイルを持っているノードがファイヤーウォールの中にいればコネクショ ンをかけることができないので、Push 要求を出すことで、ファイルを持っているノード からコネクションをかけてもらう。 • push ： queryHit への返答。Firewall の内側にいる相手からでもファイルを 受け取ることができる push は sendback である (図 13)。 図 13 Gnutella push のルーティング 右下のノードが query に相当するファイルを所持していたため sendback で queryHit を 左下のノードに返した。そしてファイルを欲する左下のノードは queryHit のたどった道 順で push を sendback し、右下のノードは左下のノードにコネクションを張り、push File する。 2 関連研究と本研究の位置付け 19 2.2 関連研究と本研究の位置付け 2.2.1 に挙げるように既に十分にチャットとして稼動しているシステムはあり、ソフト の信頼性、安定性は高いものである。かつ、各ソフトが改良を重ね利便性にも長けてい る。しかし、それでも Single Point of Failure の問題を抱えている。実例としても 2003 年 9 月に Yahoo CHAT のサーバーに障害が起こり、クライアント同士の会話へも機能障 害が起こった。また MSN メッセンジャーでも不定期に行われるサーバーのメンテナンス の為にメッセンジャーが一時使用不可能になることもある。サーバー一点集中型の欠点で ある。その欠点の回避法が Pure P2P モデルでのチャットシステムの開発である。2.2.2 のように Pure P2P モデルをとったファイル転送システムは存在するが、チャット（IM やグループチャット）は存在しない。というのも、技術的な課題として以下のような項目 が挙げられるからである ○アカウント管理（作成、保持） サーバーが存在しない Pure P2P モデルにおいて、今までサーバーで行っていた処理を 各ノードに分散処理させなければならない。チャットサーバーで行う主な処理であるアカ ウント管理（作成、保持）を分散処理させるのは困難である。また全ノードの状態把握の 難しさ等と言った技術課題が存在する。 ○初期接続ノード 同様にサーバーが存在しない Pure P2P モデルにおいて、ネットワークシステムに介入 する際に、今までならサーバーに接続をかけるのが Server Client モデル、Hybrid P2P モ デルの仕様であったが、Pure P2P モデルでは、いつも存在するノードは存在せず、ノー ドの場所 (IP) もノード数も動的に変化するものと考えられる。よって、ネットワークに 介入するための初期接続ノードをどのように設定するかも技術的問題である。 以下の課題の克服を目標とし、どんな環境からでも参加できる Pure P2P モデルでの チャットシステムの作成を目指し、既存のチャットシステムと比べた安定性、信頼性、 (GUI も含めた) 使いやすさを探っていこうというのが本研究である。 3 システムの設計 20 3 システムの設計 3.1 予備実験 今回、Pure P2P モデルのメッセジャーツールを作成する前に Server Client モデルに よる１対１の IM ツール、そして Hybrid P2P モデルを利用した複数人で会話可能のメッ センジャーツールの作成を予備実験として行った。 3.1.1 サーバークライアントモデルの IM ツール サーバー側のプログラムを待機させ、クライアント側のプログラムがサーバーへのソ ケットにコネクションをかけ、通信を始める。仕様は 1 対 1 のみの会話である。使用法と して、サーバープログラムは、起動と同時にクライアントからの接続を待ち受ける。クラ イアント側は, 待ち受けているサーバーの IP を入力することで、サーバーに接続に行き, 成功すると、1 対 1 の会話が可能となる。サーバーがダウンすると, そこでクライアント 側も終了となるが、クライアント側がダウンしてもサーバー側は、また待機状態に戻りク ライアントの接続を待ち受ける。JAVA で作成し、Server プログラム 200 行、Client プ ログラム 160 行である。 ○問題点 サーバープログラム、クライアントプログラムと異なった作りのためコネクションを張 るにはサーバーが待機状態で、いなければならない。またサーバーが存在しないと、クラ イアントだけでは、システムが成り立たない。つまり Single Point of Failure が存在し ている。仕様上、1 対 1 でのみの会話である 3 システムの設計 21 図 14 サーバー用プログラム会話画面 図 15 クライアント用プログラム会話画面 3 システムの設計 3.1.2 22 Hybrid P2P モデルのメッセンジャーツール 前節の IM ツールとは異なり、クライアントは 1 種類の同じプログラムを使うことがで きクライアント同士が会話することが可能となった。仕様として 1 対 1, または複数人で の会話が可能となった。また、サーバーに接続しているクライアントの情報を各クライア ントは知ることができる。このメッセンジャーツールには実装していないが、サーバープ ログラムでアカウント管理が可能である。 このツールの仕様として、サーバーは起動と同時にクライアントからの接続を待ち受け る。サーバーが管理する情報は、このチャットシステムにつながっているクライアントの ID、IP、待ちうけ port である。介入、離脱とともに、その情報は保存、消去される。ま た同時に各クライアントにも介入, 離脱したことを知らせる。クライアントプログラムは、 起動と同時に自分の ID、待ち受け port の設定を行い、その後サーバーに接続しシステム に介入する。介入することで、他のクライアントの情報 (ID、IP、待ち受け port) を得て、 P2P で会話を行うことができる。JAVA で作成し、Server プログラム 250 行、Client プ ログラム 700 行である。 ○問題点 クライアントプログラムを立ち上げてネットワークに介入するには、サーバーに接続す る。そして他のクライアントの情報を得るため、サーバーが存在しなければシステムは稼 動しない Single Point of Failure の問題は依然残る。 3 システムの設計 23 図 16 図 17 クライアント用 Main Window 他クライアントとの会話画面 会話の仕方は、Main Window(図 16) に表示されている ID を選択し、送信ボタンを押す ことで、IM Window が開き会話を始めることができる。複数人で会話をしたい時は、新 規加入させる ID を Main Window で選択し、IM Window(図 17) の”よぶ”ボタンを押 すと会話に招待することができる。 3 システムの設計 24 3.2 システムの概要 Pure P2P モデルによるメッセンジャーツールである。前章にも述べたが Pure P2P モ デルで作成するに置いて、技術的課題がいくつか存在する。本研究ではこれらの課題に以 下のような解決を図った。 ○アカウント管理はどうするか 今回、アカウント管理と言うのをやめ、起動時に設定するパスワードからハッシュ値を 計算し、ID の後ろに＠ (パスワードのハッシュ値) と言う形で付加するものとした。これ により、固有の ID を得ることができるものとした。というのも、パスワード (文字列) か らハッシュ値を計算することは容易だが、ハッシュ値から文字列を算出することは困難で あるからであり、 「ID ＠ (ハッシュ値)」を作成できるのは文字列を知る本人だけと言うこ とになり、個人認証として利用した。 ○初期ノードは、どこへするか サーバーを持たないため、プログラム起動後のネットワークへの介入を行う際に、ネッ トワークの、どのノードに介入を申し込みに行くかが問題である。今回は、初期接続ノー ドリストを事前に作成しておくことで初期接続の問題を回避するものとした。 会話システムは予備実験で行った Hybrid P2P モデルのメッセンジャーの会話システ ムを引き継ぐものとした。 各ノードはチャットシステムに介入している全ノードの情報を保持しているものという 仕様とし新規介入のノードは接続を受けたノードから、全ノードに情報を得ることで、全 ノードの状態を知ることとした。 3 システムの設計 3.3 システムの動作 プログラムの起動から終了までの流れは以下のようである。 １．起動 ２．個人情報の設定 ３．ネットワークに参加 ４．会話を実行・他ノードの管理 ５．ネットワークからの脱退 ６．他ノードの情報保存 ７．終了 各ステージでの処理、表示は次章の実装にて述べる 25 4 実装 26 4 実装 起動からの流れを追って、実装の中身を説明していく 4.1 個人情報の設定 まず起動と同時に個人情報の設定を行う。必要な情報として、myID、パスワード、使 用するポート (myport) を設定する (図 18)。 パスワードは前章の「システムの概要」でも述べたが、パスワードからハッシュ値を計 算し、ID の後ろに「ID ＠ (ハッシュ値)」とすることで固有の ID を作成する。 もし以前の起動で、このフィールドを設定している場合は、mydate.txt として外部ファ イルに記憶されており 2 度目の起動以降は、それが読み込まれ”OK”ボタンを押すだけ で設定可能となる。 図 18 Info Window 4 実装 27 4.2 ネットワークに参加 ネットワークに介入している他ノードの情報を得るためネットワーク上にいる他ノード に接続をかける（初期接続） どのノードに接続をかけるかは、いろいろな方法があるが今回は自分が保持している他 ノードの過去の情報 (nodelist.txt) を参照し、コネクションをかけていく。 他ノードの過去の情報とは、前回に接続が成功していたときに存在していた他ノードの 情報を保存したものである。 ノードリストを参照し接続先 IP と接続先 port を知りそこに向かって以下のようなメッ セージを投げかける connect,(myID),(myport),(接続先の IP) もしネットワークの介入が認められれば (connectport),(myIP) が返信される (その後の処理については次節)。 もし接続先のノードが不在であればコネクションが張れない (ConnectionRefused) と なる。また接続先が存在していても、その接続先がネットワークに介入途中であれば NG と返信が来る。認められなかった 2 つの場合においてはノードリストにある、次の参照 先へとコネクションをかける。 もしこのノードリストに記録されているどのノードにもコネクションが張れなかったと きには自分が１人目のオンラインノードとしてネットワークに存在し二人目の接続を待ち ながら待機する。nodelist.txt の形式は 4 実装 28 (nodeID),(IP),(port) (nodeID),(IP),(port) (nodeID),(IP),(port) と言う風に、１ノードが１行に表示され ”,”（カンマ）で区切られている。また今回 の仕様ではテキストに保存する他ノードは （起動してから終了するまでにオンラインになったノード）+（起動する前の nodelist.txt にあるノード） としている。 起動してから終了するまでが短かった場合、オンラインになったノードの数が少ない可能 性があり、次回、接続するノードが少ないため既存のネットワークに介入する事が失敗す る可能性がある。それを避けるために起動する前のノードリストもまた再度、使う事にし た。しかし接続するノード数が多量でも困るため、起動してから終了するまでにオンライ ンになったノードが１０件を満たさない場合にのみ起動する前の nodelist.txt にあるノー ドの情報も１０件に満たすまで加えることにした。 4.3 ネットワーク介入成功時 (connectport),(myIP) と言うメッセージを受けるとネットワーク介入の許可を得たので次は (接続先の IP) の (connectport) にコネクションを張る。 そしてネットワーク上にいる全ノードの情報を得る。 まず新ノードは以下のメッセージを発することで他ノードの情報を得たいとする。 getlist,(myID),(myIP),(myport) getlist を受信したノードは、全ノードに、加わる新ノードの情報を以下のメッセージで 知らせる。 4 実装 29 addmember,(新ノード ID),(新ノード IP),(新ノード port) これを受信したノードは、新しいノードがネットワーク上に入ってきたことを理解し、 持っているノード情報に加える。 その後、新ノードにネットワーク上にいる全ノードの情報が addmember コマンドによ り接続したノードから一件ずつ与えられる。メッセージコマンドは同じであり addmember,(ノード ID),(ノード IP),(ノード port) をネットワーク上にいるノードの数だけ受信し、ネットワーク上の全ノード情報を得 る。 ○新ノード介入時のエラー このメッセンジャーの初期のプログラムテストの時に、”getlist”を要求したにもかかわ らず、全ノード情報が得られなかったエラーが出た。以下の流れのときに発生 1. 新ノード A がネットワークに介入開始 2. ノード A が全ノードリストを受信するまえに、新たなノード B がノード A に接続要求 3. ノード B は、ノード A の不十分なノード情報を受信し、ネットワークの一部として動 作を開始してしまう。 これにより、仕様である「各ノードが全ノードの情報をもっている」が、B によって破綻 した。これを解決するために、２で、B は、全ノード情報をもっているノードにしか接続 できないようにして仕様の破綻を回避した。 しかし問題点はそれだけではなく、もう 1 つあった。それは、ネットワークの異なった ノードにそれぞれ同時期に新ノードがネットワーク介入を申し込んだ時である。この時に 新ノードに正しい新ノード情報が与えられない問題がある (図 19)。 4 実装 30 B C A D 図 19 同時期介入の問題 1. ノード A と D がほぼ同時期に介入する 2. ノード B、C は各ノードに新ノード介入 (addmember) を配る 3. ノード B が”addmemberA”をノード C に渡すまえに、ノード C がノード D に全ノー ド情報を伝える 4. 伝え終わった後、ノード B から”addmemberA”がノード C に届く 5. しかしノード D には”addmemberA”が伝わらない これも同様に「各ノードが全ノードの情報をもっている」が、ノード D によって破綻し た。数十ノードで使用する際はとても稀な事であるが、数万ノードの利用となれば頻繁に 起こってしまう問題ではないかと思う。これは解決に至らず、課題として残った。 4 実装 31 4.4 他ノードの表示 全ノード情報を参照し onlinfriend、offlinefriend、online と３つにグループ分けして表 示する (図 20)。 • onlin friend ： 友達登録をした人で現在オンラインである人 • offline friend ： 友達登録をした人であるが、現在オフラインである人 • online ： オンラインであるが友達登録をしていない人 ○友達リスト このメッセンジャーの仕様として、ネットワーク上にいる全ノードを表示させるように なっている。ノード数が増えてきたときに、その中から頻繁に会話する人を毎回探すの は大変なので、友達リストと言うグループを個々に作成することで、他ノードとの区別 をつける。友達リストに追加された ID は、たとえネットワーク上にいなくても”offline friend” として表示されている。友達リストの登録・解除は表示されている ID を選択し MainWindow 左にある”追加削除”ボタンを押すことによって変更することができる。 また友達リストは myfriend.txt としてプログラム終了時に記録され再度プログラムを 開始したときに、読み出される Main Window のメニューバーの”sound”にあるラジオボタンを on、off させることで、 メッセージ受信時のアラート音の有無を指定できる。 4.5 他ノードとの会話 Main Window にある onlinefriendID もしくは onlineID を選択して下部にある”送信” ボタンを押すと IMwindow(図 21) が１つ生成される。 4 実装 32 図 20 図 21 Main Window IM Window 4 実装 33 IMwindow は上部（TextArea）と下部（TextField）の二つから構成される。TextField に送信したい文字を入力し Enter ボタンで送信すると自分の TextArea に (myID)：(TextField に入力された文字) という形式で表示される。 また送信された側の画面には、文字を受信した時点で IMwindow が生成され同時に TextArea に (送信者 ID)：(送信 TextField に入力された文字) という形式で表示される。 複数人で会話をしたいときは Main Window と IM Window の二つをつかう。既存の IMwindow の右部に”よぶ”ボタンがある。Main Window の onlinefriend、online に存 在する ID を選択し”よぶ”ボタンを押すことで参加させることができる。 4.6 ネットワークからの離脱 まず、ネットワーク上にいる全ノードにネットワークから離脱することを以下のメッ セージで告げる。 deletemember,(離脱する ID) このメッセージを受け取った各ノードは、その ID に該当する情報を削除する。 そして離脱するノードは、4.1 のネットワークの介入で使用する初期接続ノードの記憶 （nodelist.txt）を現在保持している全ノードの情報を参考に作成する。また友達リスト (myfriend.txt) の作成、保存も行う。以上を終えることで、プログラムの終了とした。 5 評価 34 5 評価 今回作成した Pure P2P モデルのメッセンジャーを実際に使用し、既存のメッセン ジャーツールとの比較を交え評価とする。 5.1 方法 今回の実装の仕様により、NAT の内側と外側での会話は不可能であった。よって、今 回は同じ NAT 内の計算機６台を使用し同プログラムを稼動させテストを行った。 5.2 実験 ６台の計算機に同プログラムを配布し、そのうち５台に、残り１台 (A と呼ぶ) の IP,port を記したノードリストを配布した。A を起動させ、残りの５台はその後、任意の時間に ネットワークに介入し、思い思いに会話や、プログラムの起動、終了をして今回のツール の評価を行った。 5.3 結果・考察 ○アカウント（個人認証）管理について アカウントという形をやめ、ID の後ろに passward をハッシュ値にしたものをつけた。 会話中の発言部分の ID だけハッシュ値の表示を消し、他の部分は全部表示させてある。 既存のアカウント配布型のメッセンジャーシステムでは同じ ID は作成できないため、 ID をそのまま表示したり ID とは異なるニックネームを作成し、他クライアントに表示さ せることができる。 それに比べると、ID@(ハッシュ値) と言う表示は、見づらい表示でありプログラム内部 で個人認証を処理すべきではないかと感じた。 ○ Single Point of Failure について 1 つのノードがダウンしてもシステム自体はダウンしないので、Single Point of Failure の問題の解決にはなった。しかし、実装がまだ未熟な点もあり、突然ダウンしたノードに 対する処理ができていなかった。 5 評価 35 ○複数人で会話、アラート、会話画面などでの利便性の向上について 複数人で会話を行うこともできた。しかし既存のチャットシステムのように、文字の色 やフォントの大きさを変えることまではできず見栄えはあまりいいものではなかった。ま た TextArea に貼られた URL などのリンクの場合、既存のチャットソフトならクリック してブラウザと連動し表示させることが可能なのだが、今回のソフトでは、そのままの テキスト表示のままなので、閲覧するときには、テキストをコピーしブラウザを起動し て、アドレスを貼り付ける作業が必要となり、大変不便である。またアラートに関して は、メッセージを受信したときに、その IM Window が非アクティブウインドウならば音 を鳴らせるように実装した。また、同様にツールバーにある IM Window のアイコンを点 滅させることもした。この二つのアラートは計算機でほかの作業・仕事をしている時には とても有用なアラートである。 6 結論 36 6 結論 6.1 結論・今後の課題と展望 結論としては、Client Server モデルや Hybrid P2P モデルで稼動しているチャットシ ステムの問題点である Single Point of Failure の回避であった。そのために本実験では、 回避法として PureP2P モデルでチャットシステムを稼動させるものであった。技術的な 問題として抱えていたアカウント管理は、各ノードに分散処理させる形を取らず ID の後 ろにパスワードをハッシュ値に変えたものを付加することで個人の特定とした。また初期 接続ノードの問題は、あらかじめノードリストとして所持しておくことで初期接続先を確 保するものとした。そのような設計、実装を経て、数十ノードでの稼動を達成した。本実 験で行った、数十ノードで構成される小さなネットワークでは、サーバーを必要としな い、このチャットツールは、Hybrid P2P モデルで作成されたチャットツールより実用性 の高いものであると思う。しかし、まだ修正可能な課題も多くあったので、まだまだ改良 する余地があり、さらに実用性の増すチャットツールへとなるだろう。本実験はその足が かり的な研究となったと思う。 課題として、システムが正常に動作するには、色々な制約をつけなければならずまだま だ日常的に使用するには程遠いツールであった。他にも個人認証と言う点で弱い点が挙 げられる。本研究では、Pure P2P モデルにおけるアカウント管理が難点な事から、パス ワードからハッシュ値を計算して認証としたわけだが、他ノードにさらしている為、同じ ハッシュ値を見つけられる可能性もある。初期ノード接続をどこへするかという問題も同 様に Pure P2P モデルにおいては技術的に難点であり、今回は初期接続ノードを用意して リストにあるノードへ接続をかけていった。実験の結果としてはノード数が 10 以下と言 うことで、この方法でも可能であった。しかし、Hybrid P2P モデルなどのようにあらか じめ接続先がわかっている場合と比べ、ノードが動的に変化するため, 存在するノードを 探し出すまでに時間がかかったり、時には繋がらなかったりと言う問題が起こった。 また、実装できなかった機能が多く挙げられる。Info Window において password 入力 フィールドに入力された文字を ”*”などとコールバックしなかったこと。また、会話を テキストに保存したりする機能や、自分の状態を表示する機能、ID とは別にニックネー ムを表示させる機能等、まだまだ日常で使用するには機能的に不十分な点が多くあった。 また「実装」の章でも挙げた同時期に新ノードが介入する際に起こる問題についても、解 決に至らず課題として残った。 6 結論 37 展望としては、今回のソフトは移植性を重視して JAVA で作成している。いろんなプ ラットフォームで稼動することが目標である。既に JAVA は携帯電話でも稼動させるこ とができ、将来、IP 電話などのサービスが始まりネットワークと常時接続が可能となれ ば Pure P2P モデルをとったチャットシステムを乗せることで複数人でチャットするこ とも可能となり、とても便利なものになると思われる。 今回、NAT 内外で会話することが不可能であった。内側からコネクションを貼ること は可能だが、外側から内側に張ることが難しいからである。Pure P2P でチャットシステ ムを実現するためにもこう言った問題も解決していかなければならない。 また今回の実験では 10 ノード未満と小規模であったが、既存のメッセンジャーツール のユーザー数である数万ものユーザーがこのツールを使用したときにも本来は強固に稼動 しなければならない。しかし、今回の実装では未熟な点が多々あり、数万ノードに耐えれ るものではないと思われる。実際に、稼動させるにはそのような点にも注意を払わなけれ ばならない。それに増して、ユーザーに受け入れられるインターフェイスの作成にも力を 注がなければならないことも強く感じました。 今回の課題を踏まえて、これからのネットワークソフトウェアの作成に取り組んでいき たいと思う。 6 結論 38 謝辞 本研究は電気通信大学情報通信工学科情報通信国学講座寺田研究室において、寺田 実 助教授のご指導の下で卒業研究として行われました。 指導教官の 寺田 実 助教授には研究全般にわたって様々なご指導を頂きました。心より 御礼申し上げます。 東京大学大学院 博士課程３年 情報理工学系研究科 知能機械情報学専攻 の 丸山 一貴様 には、他大学からの出向であるにもかかわらず、非常に多くの技術的な支援をいただきま した。深く感謝申し上げます。 白井 雄一郎君、高木 一人君、五十嵐 知久君には、同研究室の卒業研究生として苦楽を 共にし、研究における相談やテスト、また日常の面で色々とお世話になりました。感謝申 し上げます。 参考文献 39 参考文献 [1] Mark Handel and James D.Herbsleb: What Is Chat Doing in the Workplace?, In CSCW ‘02,pp.1-10, New Orleans, Louisiana, USA、November 16-20, 2002. [2] 村井 純: ネットワークアーキテクチャー, http://www.soi.wide.ad.jp/class/20020022/materials for student/10/na-10done.pdf [3] The Gnutella Protocol Specification v0.4 , http://www.jnutella.org/docs/gnutellang/gnutella protocolv4.shtml [4] Winny Tips, http://www.nan.sakura.ne.jp/winny/ [5] Freenet: A Distributed Anonymous Information Storage and Retrieval System, http://de-co.info/freenet/icsi.html [6] IRC users in Japan Home Page, http://irc.kyoto-u.ac.jp/ [7] Yahoo メッセンジャー, http://messenger.yahoo.co.jp/ [8] MSN メッセンジャー, http://messenger.msn.co.jp/ [9] Lime Chat, http://www.dive-in.to/ mb-arts/ 40 参考文献 付録 通信プロトコル一覧 ノード情報関係 メッセージ 動作 connect,(myID),(myport),(接続先 IP) ネットワーク介入申し込み。 接続先の IP は接続先のノードに 自分の IP を教えるため (connectport),(myIP) ”connect”の sendback 介入を許可するときの返信 NG ”connect”の sendback 全ノードリストを所持していない時、出す getlist,(myID),(myIP),(myport) addmember,(addID),(addIP),(addport) deletemember,(deleteID) ネットワーク全ノードリストの申し込み。 自分のノードリストに (addID) の情報を加える ネットワーク離脱申し込み。 ノードリストから (deleteID) を削除 会話関係 メッセージ msg,(windowname),(発言) changeIM,(windowname),(addID) 動作 IM Window に (発言) を書き込む。 IM Window に (addID) を参加させる
© Copyright 2024 Paperzz
