現在、通常の HTTP GET 経由でダウンロードされている Jetty Web サーバーからファイルを提供しています。
ただし、ユーザーが Web シーディングを介してファイルをダウンロードできる P2P モデルに興味があります。これは、libtorrent を使用する Jetty サーバーのコンテキストでどのように実装されますか?
次に、Jetty Web サーバー上のすべてのファイルを永久に「シード」したくありません。代わりに、「オンデマンド」でファイルをシードできるようにしたいだけです。たとえば、やみくもに torrent をシードするのではなく、(GET や webseed などを介して) 要求が届いた場合にファイルをデマンドに利用できるようにしたいと考えています。
多数のファイルがあり、何万ものファイルを同時にシードできるかどうかわからないため、必要に応じてシードまたはアップロードしたいと考えています。ところで、同時にシードできるファイル数の上限を知っている人はいますか?
libtorrent 部分に関する関連ドキュメントはこちら: http://www.rasterbar.com/products/libtorrent/manual.html#http-seeding仕様はhttp://bittorrent.org/beps/bep_0019.htmlおよびhttp ://bittorrent.org/beps/bep_0017.html (どちらも「url シード」と「http シード」として libtorrent でサポートされています)。
IIRC、BEP19 (webseeds、または urlseeds) は、サーバー POV からかなり単純であり、そこで特別なことをする必要はありません。そのファイルに対する通常の HTTP 要求の場合と同じように、ファイルを提供するだけです(したがって、 、質問の2番目の部分はここではあまり意味がありません）。
BEP17 では、一意の http エンドポイントを使用し、get パラメータを渡してクライアントが必要とするものを指定します (たとえば、より適切なスロットリング制御と範囲選択が可能になります) (例: http://example.com/seed/?info_hash =X&piece=Y&ranges=Z )。
この 2 番目のアプローチは、ダウンロードするものを (プログラムで) より細かく制御したい場合により柔軟ですが、要求を処理するために、より多くのコードを記述する必要があることは明らかです。
繰り返しますが、サーバーの POV から見ると、これは通常の HTTP トランザクションとそれほど変わらず、ここでの「シード」について特別なことは何もありません。ファイルを提供するだけです (それぞれに独自の URL があり、直接またはハンドラーを介して)。
BEP19 を使用して、メタデータ部分に「url-list」拡張子を追加します (ファイルの完全な URL: http://example.com/seeds/SOMEFILE.txt - 複数ファイルの torrent に注意してください)。一方、BEP17 はキー「httpseeds」を使用します (エンドポイントで、例: http://example.com/seed/ )。
Jetty がメタデータの生成も処理するかどうかに応じて、URL をより予測可能にし、メタデータの生成をより単純にするために、BEP17 よりも BEP19 を好むかもしれません...
それが役立つことを願っています。