cyukan_presen_2

マルチプラットフォーム対応
P2Pファイル共有ソフトの開発
石川 直樹 木下 陽介 関野 誠
高木 元気 保坂 智之 吉田 侑基
担当教諭 仲道 嘉夫
何故P2Pファイル共有ソフトを作ろうと思ったのか
動機
体育祭の画像を共有したい!
アップローダーに画像をアップロード
→パスワード設定、サイズ制限対策のファ
イル分割で手間がかかる
アップローダーの上限サイズは
50MB
合計30MBの体育祭画像をアップロード
→過去の30MB分のファイルが消えた
ユーザーが体育祭の画像群をダ
ウンロード
→パスワード認証が面倒
→ファイルは分割されているので結合する
のが面倒
→一つのサーバに処理が集中するため重い
アップロードした人は過去のフ
ァイルを消してしまった
→過去のファイルを消さないために、暗黙
の自主規制が発生しアップロードされるフ
ァイルは重要なものに限られる
現状の解決策
• 外部のアップローダーを使用する
→広告が邪魔
→セキュリティも心配
• MSNメッセンジャーで共有する
→転送が壊滅的に遅い場合がある
→そもそもクラスメイト全員のアドレスを
知らないし調べるのも面倒
現状をふまえた上での解決策
ファイル共有ソフトを「自分で」作ったら
全て解決可能
→独自のソフトウェアの開発を決定
構造のイメージ、転送の仕組み
概要
ハイブリッド型とは何か
• 画像は Wiki にアップロード出来なくなる
ので省略(hybrid.eps)
プロトコルの詳細
• 画像は Wiki にアップロード出来なくなる
ので省略(hybrid.eps の左上の説明を消し
コマンドを書き加えた画像)
ソフトに求める機能・性能
要求仕様
Windows, Linux, Max OS
それぞれで完全動作させたい
• Ruby + wxRuby での開発決定
• これが原因で後に問題が生じることになる
とは誰も思わなかった・・・
• (以降、wxRuby に関する記述は Java版
が完成したら編集し直して「現在までの経
過」に追加する)
煩わしい設定はいっさい無し
GUI を作りやすい開発環境にした方が良い
→wxRuby でも使いやすいGUIデザイナが
あるし、XRC に出力すれば Ruby, C++か
ら利用可能
→またまた、これが原因で後に問題が生じ
ることになるとは誰も思わなかった・・・
高速にファイルを転送
複数ユーザーから同時にファイルを受信す
れば通常よりも早くファイル転送可能
→現在は1対1でファイルを転送
レジューム機能も欲しい
誰もが24時間フルタイムでパソコンを付け
っぱなしに出来るわけではない
→完全に実装済み
P4U(仮称)の人生
現在までの経過
誕生までの経過
1. 役割分担とか面倒だから各自勝手に作ろ
う
2. CUI版、GUI版と2つのP4U(仮称)が誕生
3. GUI版は wxRuby のバグで開発が進まず
4. 完成度の高いCUI版に開発が集中する
誕生してから現在まで
1. 2つのP4U(仮称)が結合される
2. GUI版の開発は相変わらず進まない
3. しかしGUIのソフトを公開したい
4. GUI版で問題連発
5. CUI版は動作の安定化、レジューム機能の
実装など順調に開発が進む
Ruby + wxRuby という開発環境による問題と確定した解決策
JAVAへの移行を決定した4つの
問題点
問題その1
wxRuby の不具合①
• wxRuby でも wxGlade で XRC を出力す
れば快適にGUI開発可能
• →不具合① プログラムに XRC を読み込む
と Dialog が呼べなくなる
問題その1
wxRuby の不具合②
• 不具合②新たにスレッドを生成すると
wxRuby のGUI描写スレッド(EDT:Event
Dispatch Thread)が停止する
• EDTが実行権を占有してしまうため
Thread.pass(他のスレッドに実行権を譲
る命令)を用いて明示的にスケジューリン
グを行えば解決可能
• →なぜかThread.passが動かない
wxRuby の不具合に対する対応
• wxRuby はオープンソースなので本来な
らそのプログラムを編集しバグを直すべき
→今の実力では不可能
• よって現在はバグレポートにとどめる(ま
だ未報告)
問題その2
各プラットフォーム間での差異
• 通常は wxRuby が自動で対処してくれる
がソケットは範囲外
• 文字コードの違いによって文字が表示され
ないなどの不具合が生じた
問題その3
Ruby の Thread は遅い
• 転送速度に影響を与えてしまう
問題その4
一般向け配布が困難
• 製作途中の段階でWindows用実行ファイ
ルのサイズが11MBを越える
• →UPX を用いれば3.8MBまで圧縮可能だ
が消費メモリ量が増大する
• →よって Ruby + wxRuby を持たない環
境に配布するのは困難
• →これらの問題からJavaへの移行を決定
した
仕組みの問題
「ハイブリッド型」の問題
• ハイブリッド型ではサーバ管理者が必須
• →個人に負担がかかり良くない
• →しかし、特定ファイルの流通を止められ
るなどのメリットもある
• サーバが止まるとクライアントは何も出来
ない
• →障害に弱い。
• →ピュア型への移行を決定した
今後の予定
Java への移行
• Java版が完成するだろうから書かないで
おく
ピュア型への移行
• ピュア型のイメージ図
• サーバ管理者が不要で障害に強い
ご静聴ありがとうございました