アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
そこで拡散と寸止めですよ (スコア:0)
いつまでたってもシーダに負荷がかかるのは当然だと思いますよ。
P2Pダウンロードの要諦はいかに即消しを防ぎ、あちこちに
断片を残すかが重要なんで、BTが「キャッシュ」という形で
断片を残しにくい仕様上、1日程度寸止めして拡散しきってから
流すとか、ある程度流さないとファイルに復元できないとか、
拡散成績なんかで何らかのスコアをつけて、
高スコアのリーチャに優先的に流してシーダになってもらい、
下位のリーチャに流すという形をとらないと駄目駄目です。
ミラーFTPから持ってくるよりも結果的に早ければ問題はないのです。
BTの実装の問題なので、改良すればいいじゃないですか。
Share(仮)のターボ拡散アップロードモードとか、既に
それを解決しているP2P共有ネットワークは実在しますよ。
Re:そこで拡散と寸止めですよ (スコア:1, 参考になる)
実際のところトラッカー負荷への問題はDHTネットなど色々と模索されている部分もあるので、今後改良されるかもしれません。
また、ご指摘の初期シーダーへの負荷の問題については、一部のBTクライアントに実装されているスーパーシードモードで対処されていますよ。
拡散アップロードについては、DL効率重視のBTの思想とはなかなか相容れない部分もあると思いますので、BTで採用されるかは微妙なところかもしれません。
流行が廃れると消えやすいBTですが、逆にホットな場合のDL速度には捨てがたい魅力もあるわけで。
Shareのような「ある目的」を持ったP2Pネットワークの場合は、そのネットワーク自体の存続という目的などもあるので拡散するのに意味はあるのでしょうが、それだけがP2Pの目指すところでもないでしょうし。
既存のP2Pモデルにはそれぞれメリット・デメリットがあるので、全てのP2Pモデルが同じ方向性を取らなくても、適材適所で使えばいいんじゃないでしょうかね。