○アカウント（個人認証）管理について
アカウントという形をやめ、IDの後ろにpasswardをハッシュ値にしたものをつけた。
会話中の発言部分のIDだけハッシュ値の表示を消し、他の部分は全部表示させてある。
既存のアカウント配布型のメッセンジャーシステムでは同じID は作成できないため、
IDをそのまま表示したりIDとは異なるニックネームを作成し、他クライアントに表示さ せることができる。
それに比べると、ID@(ハッシュ値)と言う表示は、見づらい表示でありプログラム内部 で個人認証を処理すべきではないかと感じた。
○Single Point of Failureについて
1つのノードがダウンしてもシステム自体はダウンしないので、Single Point of Failure の問題の解決にはなった。しかし、実装がまだ未熟な点もあり、突然ダウンしたノードに 対する処理ができていなかった。
○複数人で会話、アラート、会話画面などでの利便性の向上について
複数人で会話を行うこともできた。しかし既存のチャットシステムのように、文字の色 やフォントの大きさを変えることまではできず見栄えはあまりいいものではなかった。ま
たTextAreaに貼られたURLなどのリンクの場合、既存のチャットソフトならクリック
してブラウザと連動し表示させることが可能なのだが、今回のソフトでは、そのままの テキスト表示のままなので、閲覧するときには、テキストをコピーしブラウザを起動し て、アドレスを貼り付ける作業が必要となり、大変不便である。またアラートに関して は、メッセージを受信したときに、そのIM Windowが非アクティブウインドウならば音 を鳴らせるように実装した。また、同様にツールバーにあるIM Windowのアイコンを点 滅させることもした。この二つのアラートは計算機でほかの作業・仕事をしている時には とても有用なアラートである。
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とは別にニックネー ムを表示させる機能等、まだまだ日常で使用するには機能的に不十分な点が多くあった。
また「実装」の章でも挙げた同時期に新ノードが介入する際に起こる問題についても、解 決に至らず課題として残った。
展望としては、今回のソフトは移植性を重視して JAVAで作成している。いろんなプ ラットフォームで稼動することが目標である。既にJAVAは携帯電話でも稼動させるこ とができ、将来、IP電話などのサービスが始まりネットワークと常時接続が可能となれ
ばPure P2P モデルをとったチャットシステムを乗せることで複数人でチャットするこ
とも可能となり、とても便利なものになると思われる。
今回、NAT内外で会話することが不可能であった。内側からコネクションを貼ること は可能だが、外側から内側に張ることが難しいからである。Pure P2Pでチャットシステ ムを実現するためにもこう言った問題も解決していかなければならない。
また今回の実験では10ノード未満と小規模であったが、既存のメッセンジャーツール のユーザー数である数万ものユーザーがこのツールを使用したときにも本来は強固に稼動 しなければならない。しかし、今回の実装では未熟な点が多々あり、数万ノードに耐えれ るものではないと思われる。実際に、稼動させるにはそのような点にも注意を払わなけれ ばならない。それに増して、ユーザーに受け入れられるインターフェイスの作成にも力を 注がなければならないことも強く感じました。
今回の課題を踏まえて、これからのネットワークソフトウェアの作成に取り組んでいき たいと思う。
謝辞
本研究は電気通信大学情報通信工学科情報通信国学講座寺田研究室において、寺田 実 助教授のご指導の下で卒業研究として行われました。
指導教官の 寺田 実 助教授には研究全般にわたって様々なご指導を頂きました。心より 御礼申し上げます。
東京大学大学院 博士課程３年 情報理工学系研究科 知能機械情報学専攻 の 丸山 一貴様 には、他大学からの出向であるにもかかわらず、非常に多くの技術的な支援をいただきま した。深く感謝申し上げます。
白井 雄一郎君、高木 一人君、五十嵐 知久君には、同研究室の卒業研究生として苦楽を 共にし、研究における相談やテスト、また日常の面で色々とお世話になりました。感謝申 し上げます。
参考文献
[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-10-done.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/