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