6

データ ソースがペタスケールであり、ユーザーが最大数テラバイトを必要とする大規模なデータ配布の問題に bittorrent を使用することを検討しています。いくつかの詳細

  • 潜在的に数百万の torrent の数
  • 100Mb から 100Gb までの torrent サイズ
  • シーダーとして機能できる世界中のクラスターの安定したセット。それぞれが torrent 全体の大きなサブセット (平均で 60% など) を保持します。
  • 平均して数テラバイトのデータをダウンロードしたい比較的少数の同時ユーザー (100 未満)。

アクティブな torrent の数は、利用可能な合計に比べて少ないと予想されますが、サービスの品質が重要であるため、各 torrent に複数のシーダーが必要であるか、新しいシーダーを起動するための何らかのメカニズムが必要です。

私の質問は、BitTorrent クライアントが膨大な数のトレントのシード処理を処理できるかということです。そのほとんどはアイドル状態です。クラスター内のシーダー間で torrent をストライピングする必要がありますか?それとも、各ノードがアクセスできるすべての torrent をシードすることができますか? どのクライアントが最高の仕事をするでしょうか? シーダーのクラスターを管理するためのツールはありますか?

トラッカーはこのレベルまで拡張できると思います。

4

4 に答える 4

5

2 つの主な問題があります。

  1. 各 torrent は (通常) 定期的にトラッカーにアナウンスする必要があります。これにより、かなりの量の帯域幅が使用される可能性があります。
  2. BitTorrent クライアント自体は、多数のトレントに対応できるように作成する必要があります。

トラッカーのトラフィックについては、100 万の torrent があると仮定しましょう。通常の再アナウンス間隔は 30 分ですが、1 時間に設定されているトラッカーもあります。控えめに言って、トラッカーが 1 時間のアナウンス間隔を使用していると仮定します。1 時間あたり 100 万回の GET リクエストを行う必要があります。たとえば、各リクエストが 400 バイト上で 100 バイト下であるとします (ほとんどの応答にピアが含まれていないと仮定すると)。これはそれほど悪くはありませんが、TCP では接続を確立するために追加のラウンドトリップが必要になることに注意してください。つまり、さらに 40 バイトがダウンし、40 バイトがアップします。

これは、 UDP トラッカーを使用するだけで軽減できます。そうすれば、必要な接続メッセージは 1 つだけになり、アナウンスごとに接続 ID を再利用できます。各アナウンス メッセージは 100 バイトになり、返されるメッセージももう少しコンパクトになります。60 バイトと仮定しましょう。トレントを発表し続けるためだけに、28 kB/秒のアップと 16 kB/秒のダウンが得られます。このためには、適切な udp トラッカーをサポートするクライアント (たとえば、接続 ID をキャッシュするもの) が必要です。

シードが送信する実際のデータと比較して重要ではないと仮定すると、それほど悪くはありません。

ただし、必ずしも torrent を別々のデータ センターにストライピングする必要はありません。HTTP サーバーを使用して torrent をシードすることもできます。すべての主要な bittorrent クライアントは http シードをサポートしているため、トラッカーへのアナウンスについて心配する必要はありません (URL は .torrent 自体に焼き付けられます)。

トレントでうまくスケーリングするクライアントについては、確かなことはわかりません。測定は行っていません。100 万個のランダムな torrent を生成し、それを読み込もうとするのはかなり簡単です。

libtorrent rasterbarでいくつかの最適化作業を行って、多くの torrent で適切にスケーリングできるようにしましたが、何百万も試していません。

このトピックに関するブログ投稿をここに書きました。

于 2011-07-31T22:06:34.973 に答える
3

あなたはHekateを探しているかもしれません 。現在、せいぜいプレアルファ版ですが、あなたが説明しているものにかなり近いものです。

于 2011-08-29T04:56:51.040 に答える
1

無用なトラッカーのアナウンスと数百万単位のスクレイピング (およびアナウンス間隔ごとの) のオーバーヘッドの下で崩壊しないようにするには、現在要求されているアイテムの現在のワーキング セットのみをロードするようにシード クラスターを制限する必要があります。いずれにせよ、ダウンローダーは中央の場所から .torrent ファイルを取得 (ダウンロード) する必要があり、それがシード クラスターへのロードをトリガーする可能性があります。または、シード クラスタのいずれからも発信されていないアナウンスを認識して、特定の情報ハッシュのアクティビティを判断します。

rTorrent は高速レジューム (つまり、適切に準備された .torrent がロードされたときにハッシュが発生しないことを意味します) を備えており、xmlrpc を介して制御できるため、アイドル状態のアイテムを廃止できます。そうすれば、.torrent のダウンロードによって、実際のデータが次の 24 時間、または群れに活動がある限り利用できるようになります。

于 2011-07-31T04:15:44.777 に答える
0

プロトコルではこれが可能ですが、どのクライアントが何百万もの torrent にスケーリングするかはわかりません。最悪の場合、独自のシードのみのクライアントを作成する必要があります。

ユースケースに最も関連するプロトコル機能は、ピアが別のピアに接続するときに、接続しているピアが torrent の情報ハッシュを最初に送信することになっていることです。これは、単一のリッスン TCP ポートを使用して無制限の量の torrent をシードできることを意味し、アイドル時に使用されるリソースはほぼゼロです。

これは、BitTorrent プロトコル仕様で見つけることができます:

両側が同じ値を送信しない場合、接続が切断されます。考えられる例外の 1 つは、ダウンローダが 1 つのポートで複数のダウンロードを実行したい場合、着信接続が最初にダウンロード ハッシュを提供するのを待ち、それがリストにある場合は同じもので応答する可能性があることです。

このBittorrent Protocol Specification v1.0でも同じことがわかりました。

接続の開始者は、ハンドシェイクをすぐに送信する必要があります。複数のトレントを同時に提供できる場合、受信者は開始者のハンドシェイクを待つことができます (トレントは info_hash によって一意に識別されます)。

ただし、負荷を増加させることが 1 つあります。それはトラッカーです。通常のトラッカー プロトコルでは、各クライアントはトラッカーに対して、アップロードした量などの情報とともに、所有する各 torrent を定期的に通知する必要があります。数百万の torrent がある場合、これはやや高い負荷になります。独自の大量シードのみのクライアントを作成している場合は、シーダーをトラッカーに通知するための別のプロトコルを作成することをお勧めします。

于 2011-07-24T21:31:36.863 に答える