設計のシンプルさ。 エピソード2. DHTとPEX

ピアツーピアのBitTorrentネットワークは非常に人気があります。 そして、そのようなネットワークが完全に火工品ではなく潜在的に危険なウェブサイト、トラッカーに基づいていることはさらに不快です。 したがって、BitTorrentが生きているので、残りを分散させるためにさまざまな試みが行われました-ピアのリストを取得します。



コンピューターサイエンスの学生は、一般的な思考パターンを持っています。 DHT!」 DHT、分散ハッシュテーブル -投機的に単純なアイデア:ハッシュテーブルのキー範囲はピアに散在し、相互リンクと歓声が構築されます。 Hooray-お尻の穴。 シミュレータやクラスタとは異なり、実際のネットワークに直面すると、膨大な数の問題が発生するためです。 たとえば、ピアの半分以上がNATおよびファイアウォールの背後に隠れているため、他のピアではなく1つのピアでDHT要求に応答します。これは予測が困難です。 ピアは常に行き来し、一部のピアはバグがあり、悪意のあるピアがあり、誰かがダイヤルアップで接続されています。 これをすべて予測し、対応するプラグを締めるために、私は一生懸命働かなければなりませんでした。 そして、結果のコードはまだ苦情を提起しています。 根本的な問題は、DHTが独自のルールに従って独自のP2Pネットワークを構築することを余儀なくされることです。 複雑さ、有効性、セキュリティに悪影響を及ぼします。



同じ方向でのもう1つの試みはPEX(ピア交換)*であり、 既に接続されているピアが既に接続されている相手のアドレスを単に交換するゴシッププロトコルです。 当初はBram Cohen(BitTorrentの著者)がPEXが群れの崩壊につながると確信していたため、プロトコルには困難な運命がありました。 彼はすぐにある種のシミュレーターを作成し、完全な崩壊を見ました。 少し前に、群れもバラバラになった理由を理解しているように思えました。 私もシミュレーターを作成しましたが、群​​れの崩壊のための合理的なパラメーターでは、それを達成できませんでした。 どうやら、彼にはある種の間違いがありました。



そして、PEXは正常に動作します。 もともとは非公式のクライアントに実装されたもので、AzureusとµTorrentのようです(2番目はBitTorrent Incによってまだ購入されていません)。 徐々に、ut_pexと呼ばれるµTorrentの実装が一般的に受け入れられるようになりました。 このプロトコルは非常に効果的です。ラップトップから特別なBitTorrentスパイダーを使用して、数分で100,000の群れのすべてのピアを書き換えました。 仕事の論理は単純で指数関数的です。 トラッカーから20個のピアを受け取り、2個のピアを正常に結合すると、すぐにut_pexによってさらに200個を取得します。 まあなど。 プロトコル自体は非常にシンプルで、1つの(!)メッセージで構成されています。 別の一般的な思考パターン:誰もが2つのメッセージがあるはずだと考えています:要求と応答。 いいえ、リクエストはありません。 メッセージだけが非常に小さいため、保存する意味がありません。 そして、リクエストには多くの問題があります。 したがって、ut_pexを理解していることをピアが認識すると、ピアは定期的にIPアドレスを送信します。 libtorrent-rasterbarのut_pex実装は、同じ場所にあるかなりコンパクトなDHT実装よりも7倍少ないスペースを占有します**。



*そして、 ウィキペディアでPEXについて書かれているのは、オリジナルの研究または単にがらくたです。



**注意深い読者は詐欺に気付くかもしれません-ut_pexはピアを開始する必要があるため、追跡の完全な分散化を提供ません。 秘密を共有します。 DHTもこれを提供しません。 まず、ユーザーはサイトにアクセスします。そうしないと、ユーザーを組み立てることが困難です。 第二に、私が知っていることから、DHTは実際にはルートサーバーからブートストラップします(これだけが大きな秘密です!:))



コンピューターシステムの中で最も安価で、最速で、最も信頼性の高いコンポーネントは、そこにないものです。 -G.ベル



All Articles