BitTorrent では、クライアントは .torrent ファイルで指定されたトラッカーに接続します。トラッカーは一種の集中型サーバーであり、出発点です。したがって、BitTorrent は純粋な p2p ではありません。
純粋な p2p システムを開発したい場合は、ルーティング オーバーレイ ネットワークを設計する必要があります。すべてのノードには、ルーターのようにルーティング テーブルがあります。ただし、ルーティング オーバーレイ ネットワークでも、各ノードは少なくとも 1 つの既存のノード (GUID、IP アドレス) を最初に認識している必要があります。では、どうすればこれを判断できるでしょうか。固定集中型サーバーのように、「最初に接続する 1 つの既存のノード」を永久に保持する必要がありますか? もしそうなら、これは完全に分散化された方法ではないと思います。
あなたが説明する解決策（よく知られているIPアドレスを備えた中央ピアを定義する）は唯一のものではありません。
もう 1 つの解決策は、HTML ページ (または json ファイル) をネット上のよく知られた URL に投稿し、この項目に、このピアが最初に接続できるピアの更新されたリストが含まれていることを確認することです。このリストは、ピアがダウンした場合に更新できます。最終的には、複数の URL を使用できます。
純粋な P2P システムは理論的な概念であり、実際には完全に実装することはできません。
エニーキャストを使用できます。したがって、最初の他のクライアントが応答し、そのような最初の「クライアントリスト」を送信する場合があります。クライアントがそれらに接続して、より多くのリストを取得できる場所。
古典的に、私はアドレスにマルチキャストを実装し、他のクライアントの応答を待ちます。
まず、真のピア ツー ピア ネットワークは必ずしも分散化されているわけではありません。第 2 に、分散化は必ずしも、ネットワーク自体が中央集権化されている可能性がある二次サービスを利用しないことを意味するわけではありません。
これらの問題の両方における主な問題は、ネットワーク ソリューションの主要なリソースが相互に関連するピアを介して分散されているかどうかです。
たとえば、ピア ツー ピアのビデオ会議では中央の連絡先サービスを使用できますが、真のピア ツー ピアの範囲に入る前にピアがそのような問題を解決する限り、純粋なピア ツー ピアのままです。これも分散化されます。
結局のところ、ピアツーピアを使用して解決しようとしているものです。ビデオ会議はビデオ会議です。あるピアでビデオが録画されて始まり、別のピアでビデオが表示されて終了します。このデータの各バイトがピア間で直接転送される限り (会議に何百ものピアが存在する場合や、これらのピアがお互いをどのように見つけたかに関係なく)、それは真のピアツーピア ビデオ会議です。
ビデオ ピアは引き続き通常のリングにあることに注意してください。また、連絡先リストでは IP ではなくロケーション情報にノード キーが引き続き使用される可能性があることに注意してください。これは依然として IP を介して構築されるため、ネットワーク オーバーレイであり、ピア レベルでのアドレス指定スキームを置き換えて、真のピア ツー ピア ネットワークを促進します。
結局のところ、ネットワーク接続の概念です。IP は、パケットが特定のアドレスに到達するまで、不特定のルーターにパケットをプッシュするだけです。各エンドポイント間の「接続」は、上位のソフトウェア レベル内にのみ存在します (TCP/IP を処理する場合を含む)。接続とは、誰が誰で、各ポイントがデータをどのように処理できるかなどを理解するためにソフトウェア内で使用される単なるデータです。ピアツーピア ネットワーク オーバーレイはこのデータを効果的に分散し、各ピアが通信するために大量の接続を作成する必要をなくします。巨大な範囲。これには分散化は必要ありません (ピアツーピア通信が集中化されていない限り)。システム内のセカンダリ サービスがネットワークの範囲を制限したり、実際のピアツーピア ネットワークを集中化したりする必要はありません。
したがって、あなたの質問に答えるために、ピアツーピアと見なされるために最初にどこに接続するかは問題ではなく、さまざまなピアツーピア サービスがサービス設計に基づいてこれを処理します。