中間発表用の要旨を制作するためのメモ
研究テーマ
マルチプラットフォーム対応P2Pファイル共有ソフトの開発
- マルチプラットフォーム ← 現状はRuby。Javaに移行するかもしれないので曖昧にする
- ピュア型に対する未練から「ハイブリッド型」と入れない。
概要
問題点を述べたあとに研究のアピールポイントを並べ、その研究をする利点について書く。
現状のファイル共有ソフトには次のような問題点がある。
問題点
- 主なコミュニケーションツールであるMSNメッセンジャーは一対一のファイル交換しか出来ず、専用サーバを介すので遅い。
- 手軽に扱える小規模なP2Pファイル共有ソフトがない
- マルチプラットフォームで扱えるソフトが少ない。
その問題設定は適切か？
その問題設定は本当に問題となっているか？
- LimeWire(Java) はマルチプラットフォームで動作し気軽にP2Pネットワークを構築出来る。
→仲間内でのファイル共有は不可能。
現実味のある問題か？
そのため次の要件を満足できるソフトウェアの開発をすることにした。
研究のアピールポイントは？
- MSNメッセンジャーのようにファイル転送に専用サーバを介さないので高速に動作する。
- Rubyが動く環境（Windows, Linux, Max OS, モバイル端末等）でならどこでも動作する。
- (Javaが動く環境（Windows, Linux, Max OS, モバイル端末等）でならどこでも動作する)
- (Java で開発されているため、複数の OS に対応している。)
- レジューム機能があるので安心してファイル共有出来る。
何が革新的なの？
- JavaでP2Pファイル共有
複数の利点があったとして一番のポイントは？
No.1 どんなOSでも動作し起動したら簡単な設定のみで即ファイル共有。
限られたグループの中で(LimeWireとの差別化)ファイルを公開出来る
限られたグループの中で(LimeWireとの差別化)ファイルを公開出来る
その研究をすることで良いことはあるの？
誰が得するの？
- 複数OSのユーザー、ビギナーからプロフェッショナルまで
どのように得するの？
- 体育祭で撮影した大量の写真、動画を簡単に探し出し、高速ダウンロード出来る
本当に得するの？
- 既存のアップローダーで公開→パスワード管理が面倒。転送が一対一だから遅い。
- Winny や Share で公開→
- MSNメッセンジャーでフォルダ共有機能で交換→専用サーバを介すので遅い。
現在までの経過
- 各班員がそれぞれ独自のP4U(仮称)を作り始める。
- その中で一つの完成度の高いP4U(仮称)が誕生する。
- 他の班員が完成度の高いP4U(仮称)の製作に集中する。
- 現在はGUI版とCUI版が存在し、
CUI版は次の仕様を満たしている。
クライアント
クライアント
- upフォルダにあるファイルを自動でインデックスサーバーに登録する
- インデックスサーバーにファイルを登録
- インデックスサーバーの登録ファイルを削除
- インデックスサーバーから登録ファイルを検索
- インデックスサーバーの登録ファイルをダウンロード
- クライアントを安全に終了する
- クライアントの登録要求を受理しファイルを登録する
- クライアントの削除要求を受理しファイルを削除する
- クライアントのファイル要求を受理しファイル所有者を紹介する
また、CUI版は次の仕様を満たしている。
クライアント
クライアント
- ファイルの検索結果を表示
RubyではGUIの実装が困難であると判断し、Javaへ移行することを決定
現状の問題点
- Ruby のスレッドは遅いので IO#select へ移行したい。
- Ruby だと GUI 実装と配布に難あり
→wxRuby(1)では Thread が正常に動作しない
→GUI を使用する為には別途 wxRuby の導入が必要となり目的にそぐわない恐れ
→最終的には公開を検討しているため、改善する必要が有る
→GUI を使用する為には別途 wxRuby の導入が必要となり目的にそぐわない恐れ
→最終的には公開を検討しているため、改善する必要が有る
- より高速な転送を可能にする為に、多重ダウンロード方式(2)を実装することも検討する
- 各プラットフォーム間の差異を吸収しきれていない (ex: 文字コードの違いによる文字化け)
(1) wxRuby は Ruby のマルチプラットフォーム対応GUI実装ライブラリである
(2) 複数のファイル所持者からダウンロードする方法
今後の予定
- Java に完全移行する
- GUI の実装を最優先とする
- 多重ダウンロード方式導入について検討する
