Libtorrent

実装されたBEP

BEP（BitTorrent Enhancement Proposal）は、BitTorrent拡張提案プロセスの一部である。BEPとは、BitTorrentコミュニティに情報を提供する設計文書であり、またはBitTorrentプロトコルの新機能を説明するものである。BEPは、機能の簡潔な技術仕様と、その機能の根拠を提供すべきである。BEPは、新機能の提案、問題に対するコミュニティの意見収集、BitTorrentに関する設計決定の記録手段として機能することを目的としている。BEPの著者は、コミュニティ内でコンセンサスを構築し、反対意見を記録する責任を負う。

BEPはバージョン管理されたリポジトリ内でreStructured textファイルとして管理されており、そのリビジョン履歴は機能提案の歴史的記録となる^[2]

BEPには以下の三種類がある。

1. Standards Track BEPは、BitTorrentプロトコルの拡張、またはプロトコル内のアクター（現在はクライアント、トラッカー、Webサーバ）の動作の変更を記述する。
2. Informational BEPは、BitTorrent設計上の問題について説明したり、BitTorrentコミュニティに対して一般的なガイドラインや情報を提供するが、拡張提案は行わない。Informational BEPは必ずしもBitTorrentコミュニティのコンセンサスや推奨を反映しているわけではないため、ユーザーや実装者はこれらを無視してもよいし、参考にしてもよい。
3. Process BEPは、BitTorrentを取り巻くプロセスを説明したり、プロセスへの変更（または出来事）を提案する。Process BEPはStandards Track BEPに似ているが、BitTorrentプロトコル以外の分野に適用される。これらは単なる推奨にとどまらず、ユーザーは通常これを無視できない。例としては、リリーススケジュール、手順、ガイドライン、意思決定プロセスの変更、BitTorrent開発に使用されるツールや環境の変更などがある。

Merkle hash tree torrents

これはBitTorrentプロトコルのBEP30である。Merkle hash tree torrentsは、ピースハッシュを形成するハッシュツリーのルートハッシュのみをトレントファイルに含めることを可能にする拡張である^[5]。この機能の主な利点は、トレント内にいくつピースがあっても、.torrentファイルのサイズが常に一定であることである。.torrentファイルのサイズはファイル数に応じてのみ増加する（ファイル名を含める必要があるため）。

通常のトレントでは、クライアントはピースを検証する前に、複数のブロックを異なるピアから取得しなければならない。ピースのサイズが大きくなるほど、ピース全体をダウンロードして検証するまでに時間がかかる。ピースが検証されるまで、そのデータはスウォームと共有できないため、ピースサイズが大きいほど、ピアによってダウンロードされたデータの再配布までの時間が長くなる。平均すると、データはクライアントのバッファ内で検証待ちの状態になる時間が長くなる。

もう一つの大きなピースサイズの問題は、ピースが失敗した場合に悪意のある、またはバグのあるピアを特定しにくくなり、再ダウンロードに時間がかかり、成功するまでに試行回数が増えることである。

通常のトレントにおけるピースサイズは、.torrentファイルのサイズとピースサイズとのトレードオフである。例えば、4GBのファイルでは、.torrentファイルのサイズを大きくしすぎないようにするために、ピースサイズが2MBまたは4MBになることが多い。

Merkle hash tree torrentsは、この.torrentファイルサイズとピースサイズのトレードオフを解消することで、これらの問題を解決する。ピースサイズを最小のブロックサイズ (16KB) にし、これによりピアは他のピアから受け取ったすべてのデータブロックを即座に検証することが可能になる。これによりターンアラウンドタイムが最小化され、悪意のあるピアの特定の問題は完全に排除される。