>>884 >キャッシュに溜まるファイルは、
>
>1.自分でアップロードフォルダに突っ込み、
> かつ、外部からダウンロード要求を受けたファイル
>2.外部に対してダウンロード要求を行ったファイル
>
>以上の2種類だけのように見うけられます。
その理解であってますが、「3. たまたま中継したファイル」というのも加わります。
このシステムではファイルのヘッダ情報とボディを分離して扱い、ヘッダ情報(キー)は
単独でシェアされて行きます。そして、外部的にはこのヘッダ情報を持っているだけで
ファイル本体を持っているとみなしダウンロード要求が可能です。
ファイルの存在を知っていれば、そのファイルを持っていることと同じなわけです。
もちろん本体を持っているとは限りませんので、要求がきて本体が無ければ
そのとき改めて本体をダウンしに行きます。これにより中継動作が発生し、
だれが実際にファイルを持っているのかを隠すわけです。
今はこの中継部の実装が半端で芋づる式にしか転送できませんが、
今後の実装はこの辺りが中心になるでしょう。
基本的に親方向にキー情報が流れていくため上流にいるほどキーが溜まって
検索の必要がなくなります。結果的に上流ノードほど検索ヒットを受けるので、
ファイル本体をキャッシュする率が高くなり、下流に行くほど検索&ダウン要求する
率が高くなることになります。上流にいるほどDOMりやすいですが、セキュリティ
的には下流にいるほど安全です。
回線の早いDOM屋さんを身代わりの中継サーバーに使うことになります。
また、
> 足が付かない様にするため、DLしてはキャッシュをクリアする、
> という輩が生まれ出すような気もします。
これはその通りで足を付かなくするには、誰かがキャッシュを持っていったら
すぐそのキャッシュを消すと確実です。完全に中継するだけの動作になります。
もちろんこれをやると転送分帯域が無駄ですし、みんながみんなこれをやってしまうとヘッダだけ
出回ってデータ本体が見つからないという状況になります。最終的にUPフォルダに
持っている人のところにダウン要求が集まってくるという状況になるでしょう。
遅いだけで、それはそれで問題ないです。最終的に誰がUPしているのかは隠せます。
このキャッシュクリアはまだ実装されていませんがもちろん標準でつける予定で
キャッシュフォルダの大きさを指定することで行われるでしょう。もしキャッシュ容量が0に
指定されてると、キャッシュができるそばから消されていくという動作になると思います。