get_peers クエリのメインライン DHT ノードによって送信される udp パケットの最大サイズは? 3000 個のピアを格納するとき、ノードはどのように応答しますか? (その場合、パケットは非常に大きくなります)。メインラインの DHT クライアントはどのように応答を処理しますか?
前もって感謝します。
get_peers クエリのメインライン DHT ノードによって送信される udp パケットの最大サイズは? 3000 個のピアを格納するとき、ノードはどのように応答しますか? (その場合、パケットは非常に大きくなります)。メインラインの DHT クライアントはどのように応答を処理しますか?
前もって感謝します。
IPv6 DHT については、1024 バイトの上限が定義されています。http://bittorrent.org/beps/bep_0032.htmlを参照してください。
値リスト (返されるピア) に関しては、ノードは完全なリストではなく、パケット サイズに適合するランダム化されたサブセットを返す必要があります。
IPv6 は途中のフラグメンテーションをサポートしていないことに注意してください。したがって、より大きなパケットを送信したい場合、TCP とは異なり、UDP ソケットはそれを自動的に行わないため、送信者はパケットを保守的にフラグメント化する (信頼性が低下する) か、ソケット エラー処理を実装してユーザー空間で再送信する必要があります。これらの複雑さと非効率性を回避するには、パケット内の可変サイズのデータを所定のサイズに収まるまで圧縮することをお勧めします。
他の bittorrent トラッカーと同様に、応答にはすべてのピアが含まれる必要はなく、ランダムに選択されます。
最も人気のあるクライアント (uT、BTML、および libtorrent-rasterbar についてのみ話すことができます) は、MTU サイズを想定しており、それを超えないようにしています。想定される MTU サイズは1500バイト (通常の最大イーサネット フレーム サイズ) を下回っています。これは通常、インターネットでも見られるパス MTU の上限です。通常、そこから数十バイトを削って、PPPoE やその他のトランスポートで実行される接続をカバーすることをお勧めします。
IPv6 経由でパケットを送信する場合、Teredo (1280 バイト) 経由の場合はさらに低い MTU を使用するように注意する必要がありますが、私が言及したこれらのクライアントはまだ IPv6 経由の DHT をサポートしていません。
正確には、uTorrent は 1500 の MTU - 20 バイトの IP ヘッダー - 8 バイトの UDP - ヘッダー - 24 バイトの潜在的なGRE ヘッダー- 潜在的なPPPoE ヘッダーの 8 バイト -潜在的なMPPE ヘッダーの 2 バイトを想定しています。つまり、 1438バイトの UDP ペイロードです。
パケットがパス MTU を超えた場合でも、IP レイヤーはそれらをフラグメント化し、bittorrent クライアントに対して透過的にエンドポイントでマージします。