ダウンロード機能の実装
＠ 進み具合
ダウンローダーが完成して、ユニットテストレベルでは、大き目のファイルもダウンロードできている。
ただし、誰もこいつを呼び出してない。
「ダウンロード機能は殺しています」ってのは、ある意味嘘でした。ダウンロードだけの機能は存在するけど、保存する処理ができていない。
＠ 今のところの全体的なイメージ
ダウンロードは、キャッシュタスクという人に担当させることにした。
キャッシュタスクは、キャッシュファイルの管理を担当し、ダウンローダー、アップローダー、プロキシー、デコーダー、エンコーダーという5種類のワーカースレッドを生成することができる。
ダウンローダーは、指定されたファイルをダウンロードし、受信ブロック単位でキャッシュタスクへ投げる。キャッシュタスクは受け取ったブロックでキャッシュファイルを更新する。
アップローダーは、考え中。
ダウンローダーはファイルIOに関与しないため、わりと高速に動くようにし、アップローダーはキャッシュの先読みにより、わりと高速に動くようにする。
中継を行うプロキシーは、ダウンロードとアップロードを同時に行うが、キャッシュアクセスはダウンロード時のみとする。動作速度は、ダウンロード速度に依存する。
デコーダーは、完全化したキャッシュファイルを復号し、ダウンロード済みファイルを作る。
エンコーダーは、アップロードフォルダに置かれたファイルをキャッシュファイルに変換する。
＠ 問題となる点
- メモリ使用量
できればデータブロックのやりとりはスタックだけを使いたい。
=> メモリアロケートするとGCのコレクタが動くまで開放されないので無駄なメモリが大量発生する
ただし、本当にそうしてしまうと並列処理がうまくできなくなるので、今のところサイクリックなリソースプールのようなものを使う予定。
10ブロック分くらいのメモリを順番にぐるぐる使う。1周回って戻ってくる頃には、先頭ブロックはもう使われていないだろういう考え。
- 転送リンクはだれが管理するか
転送リンク接続（アップロード要求）は、あくまでノードタスクが管理する予定。
ダウンロードは、ダウンローダーが転送リンク接続を行う予定。
このへんよくまとめたほうがいい。実は考え中。特にアップロードに関して。
- キャッシュファイルのフォーマット
Winnyと同じにはしない予定。
単純なフォーマットで作る。
などなど。
ブロックは、先頭から順番に格納したいが、そうもいかない場合（多重ダウンロードなど）があるので、インデックスが必要かも？
