専用の中央サーバーを使用せずにピアを見つける既知の方法はありますか?
つまり、インターネットへの接続を切断して再接続するが、毎回新しい IP アドレスを取得するピアがあり、登録する専用サーバーを設定せずにそれらに接続したい場合。
ピアの電子メール アドレスを使用して、接続されたピアのマニフェストを定期的に送信し、ある種のタイムコードを使用して、専用サーバーの必要性を否定することを考えていました。これは、以前に知られているすべてのピア アドレスを試した後、どのピアにも接続できなかった場合のフォールバックになります。しかし、ピアを見つける既存のモデルの方が望ましいでしょう。
より多くを発見するために、少なくとも 1 つの最初のピアを知る必要があることを回避する方法はありません。Gnutella や Gnutella2 などの完全な P2P プロトコル、またはより単純な Overnet (Storm Worm によって有名になった) は、少数のピアのスタートアップ リストを持つ各クライアントに基づいています。これらは、たとえば、Web ベースの自動トラッカーから取得できます。クライアントは、ファイル検索を委任する場合など、他のピアに追加のアドレスを要求することにより、ネットワーク全体またはネットワークの一部を検出します。
集中型のリソースをまったく持てない場合は、ブロードキャストされたメッセージを介して最初のピアを見つけ、最終的には IP アドレスをスキャンすることをお勧めします。最初のアプローチは意味のあるものですが、少なくとも 98% のケースでは結果が得られません。もちろん、後者のアプローチはインターネットを悪用するものであり、ほとんどの国で違法です。
私は本当に、ある種の中央トラッカーを持つことを再考したいと思います. ウェブサーバー上の PHP スクリプトのような単純なものでもかまいません (今日の gnutella ネットワークは、お互いを知らない人々によってホストされている 10 から 20 のそのようなスクリプトによって支えられています)。そして、これは確かに電子メールよりも軽量です (少なくともスパム フィルタが原因で、いずれにしても機能しません)。
イントラネット内のピアの限られたケースでは、ブロードキャスト UDP メッセージを既知のポートに送信して、ピアに報告を求めることができます。
BitcoinQT クライアントはさまざまな方法を使用してノードを見つけます。そのうちのいくつかは役立つ場合があります。
IRC は使用されなくなりましたが、最も簡単に実装できる可能性があります。
バージョン 0.6.x 以降、Bitcoin クライアントはデフォルトで IRC ブートストラップを使用しなくなり、バージョン 0.8.2 以降、IRC ブートストラップのサポートは完全に削除されました。以下のこのドキュメントは、ほとんどの以前のバージョンで正確です。
ノードは、自身のアドレスを学習して共有するだけでなく、IRC チャネルを介して他のノード アドレスについても学習しました。irc.cppを参照してください。
自身のアドレスを学習した後、ノードは自身のアドレスをニックネームとして使用する文字列にエンコードしました。その後、#bitcoin00 と #bitcoin99 の間で名前が付けられた IRC チャネルにランダムに参加しました。その後、WHO コマンドを発行しました。スレッドは、チャネルに表示される行を読み取り、チャネル内の他のノードの IP アドレスをデコードしました。これは、ノードがシャットダウンされるまで、永久にループで実行されました。
クライアントが IRC からアドレスを発見したとき、アドレスのタイムスタンプを現在の時刻に設定しましたが、51 分の「ペナルティ」を使用しました。つまり、実際にはほぼ 1 時間前に表示されたように見えました。
データを投稿できる既存のフォーラムを活用してください。秘密の IRC チャネル、写真へのデータの埋め込み、写真共有サイト 4chan への投稿、captia ログインなどなしでアプリケーションがログインしてデータを投稿できる任意のサイトを考えてみてください。
http://chatzilla.hacksrus.com/faq/#password
もう 1 つの戦略は、デジタル通貨トランザクションにメッセージを埋め込むことです。ぶらぶらしそうな安いコインを選んでください... DOGEまたはMOONコインかもしれません。ウォレット機能をアプリに組み込みます。アプリが制御するアドレス間でマイクロ トランザクションをやり取りできるようにします。マイナー料金はまだかかりますが、これはわずかな金額です。後でトランザクションへのメタデータの追加が禁止されたとしても、MOON で IP アドレスに相当するトランザクションを作成し、アプリで MOON コインのバニティ アドレスを使用できます。新しいノードがオンラインになったときに、ブロックチェーンで何を検索すればよいかを認識できるようにします (2daMOON%bootStr@pM3)。SEND - 104.003021133 MOON IP = 104.3.21.133 高価な提案ではありません。
オプション 3 を使用しない限り、接続を開始するために常に中央サーバーが必要になりますが、3 つの方法があります。
あなたの例では、ピアが登録されるある種の中央サーバーがまだあります。プロトコルが唯一の違いです。
古い質問ですが、私はこの問題について自分で考えていたので、2セントを広告します。つまり、ノードが少なくとも 1 つの有効なピアを認識している場合、中央サーバーは必要ありません。新しいノードは、現在のメンバーによってネットワークに追加される必要があります (アプリケーションによっては、招待されるか、ノードが別のノードを生成するなど)。
仮定して：
エージェントはピアを追跡します。このアドレス帳のサイズとエントリの管理方法は、システムの性質によって異なります。たとえば、ピアが安定したアドレスを使用している場合、ピアが接続されている時間
エージェントはピア情報を他のピアと共有します
少なくとも一部のエージェントは、ノードがアドレス帳を更新するためにネットワークに接続する頻度に比べて、比較的長い期間利用可能のままです (またはノードが安定したアドレスを持っている)。
ピアアドレスに加えて、可用性情報も追跡されます (システムに応じて、ここに多くのオプションがあります。例には、ピアが安定したアドレスを持っているかどうか、最後に見たとき、何らかの可用性メトリック、コンテンツ/サービスタイプ情報、アドレスが有効な場合まで) が含まれます。既知)
新しいエージェントは、少なくとも 1 つの有効なピアで初期化されます (セントラル ノードである必要はなく、任意の有効なノードにすることができます)。
悪意のあるピアが存在する可能性がある場合は、信頼メカニズムが必要です。
ピアがオンラインになると、そのピア テーブル内のピアにクエリを実行してアクティブなピアを検出し、有効期限が切れたダイナミック アドレスを削除する可能性があります。ノードはピア情報を交換し、ノード自体がリンクされる場合があります。このピアの発見/交換は、十分なサイズおよび/または品質のピア リストまで、特定の数のホップまたはランダム ウォークを介して続行できます。
さらにいくつかの詳細：
ノードは、ノード アドレスが変更される頻度に関連する頻度でピア情報を接続および共有するため、アドレス帳が古くならず、ノードが切断されることはありません。
ノードは、最も安定したノードの周りに集中化する傾向を避けるために、受け入れるピアの数を制限する必要がある場合があります。
ノードは、保持するピアを選択する必要があります。つまり、データを交換する可能性が高いもの (例: 履歴に基づく重み)
ノード リンクは、アプリケーションに応じて非対称または対称の場合があります。
簡単に言えば、中央サーバーなしでこれを行う方法はありません。
これを行うには、動的 DNS を使用するかどうかに関係なく、1 つまたは複数の中央サーバーが必要です。クライアントは、どこに接続すべきかを発見する方法を必要とします。これを行う唯一の真に賢明な方法は、独自のサーバーを使用することです。最も単純なシナリオでは、応答として IP アドレスを送信するだけで済みます。
仮想サーバーは月額約 15 ドルで利用できます。IMO は、他人の帯域幅を使用したり乱用したりするよりもかなり安価です。
[編集]。
簡単に言うと、次のような方法があります。
振り返ってみると、一連のピアをクラスター コントローラーとして指定し、動的 DNS サービスを使用して、他のピアがクラスター コントローラーを検出できるようにすることだと思います。
ダイナミック DNS プロバイダーを選択します。名前は myc.ath.cx にします (私はhttp://www.dyndns.com/を使用します)。
各ピアは、クラスタ コントローラになることができる必要があります。クラスタ コントローラには、接続されている他のすべてのピアのリストが含まれます。
ピアが開始されると、myc.ath.cx を検索して接続を試みます。一定時間、たとえば 30 秒以内に接続できない場合は、DNS エントリの登録を引き継ぎます。
他のピアを発見したいピアは、単に myc.ath.cx を照会するだけで、リストが提供されます。
すべてのピアは、コントローラをクラスタ化する必要がある場合に備えて、ピアのリストを定期的にダウンロードする必要があります。
クラスタ コントローラは、定期的に DNS エントリを照会します。IP アドレスが変更された場合、クラスタ コントローラではなくなったことを認識します。そのため、現在 DNS エントリを持つクラスタ コントローラに接続し、既知のホストのリストを提供します。
クラスタ コントローラは、リスト上のホストに定期的にアクセスして、ホストがまだ有効であることを確認します。
ただし、電子メールを送信する方法は専用サーバーを使用します。正確には、ピアの電子メール サーバー。
大まかに言えば、ピアが使用しているインターネットへの接続を特徴付けることができない限り、ある種の専用ストレージまたはサーバーを使用せずにそれが可能だとは思いません (斜めではありますが、電子メールのアプローチはそうです)。
基本的に、X 個のピアのセットがあり、それが Y 時間接続され、その後 Z 時間グリッドから外れている場合...基本的に、その可能性について確率方程式を構築できます。最後に接続したピアのセットは引き続き使用できます。その確率が 1 に近づく場合 (上記の X、Y、および Z の特定のセットに対して)、ほとんどの場合、ストレージを使用せずにピア ツー ピア ネットワークを維持できます。
おそらくもっと精神的に。「専用の中央サーバー」を用意する代わりに、シンプルなオンライン無料サービスを使用してピア リストを指定します。yahoo グループなどを設定します。クライアントは自動的にそれを調べて、一連のピアを照会するためのピア アドレスを取得できます。クライアントは、認証を使用してグループに投稿するようにコーディングできます。また、他のユーザーが既知のアクティブなピアのセットを要求できるように、定期的にその IP アドレスを投稿できます。
本当に巧妙になりたい場合は、基本的にステガノグラフィー手法を使用して、ピアの位置情報を隠すことができます。つまり、「何とか」のグーグル検索を取得します。保護されていない (CAPTCHA のない) メッセージ ボードを持つ、結果にリストされた最初のサイトを見つけます。「間違いなく」（または何でも）で始まる3番目（または何でも）の投稿を見つけ、そこに最初のメッセージのヘッダーを見つけ、そこにピアのIPアドレスがあります。それでもうまくいかない場合は、検索用語のリストを次の用語に移動します。
しかし、それは卑劣です。:-)
サービス検出には、中央ディレクトリまたはある種のブロードキャスト プロトコルを使用できます。それらを Google のインデックスに登録できると仮定すると、特定のページに固有のまれな単語を含む Web サイトを各ピアが運営するシステムを考えることができます。次に、これらの単語に基づく Google 検索結果を使用して、潜在的なピアを特定できます。これは基本的に、(騒がしく遅い) インターネット ブロードキャストになります。
ページ構造がよく知られているパターンであるか、そのピアの識別可能な接続情報が含まれている場合、検索結果でそれらを簡単に区別できます。このような公開ディレクトリを使用すると、形成されたネットワーク内の侵害されたノードに対して無防備になりますが、これは、何らかのセキュリティ メカニズムがない P2P ネットワークにほぼ当てはまります。
Web サイトをクロールして、Google (または他の検索エンジン) によって特定の難解な検索用語のセットに対して上位にランク付けされるようにすることが秘訣です。いくつかの方法を考えることができますが、それらは私が使用する方法ではありません。正当なサービスのためには、お金を使うか、ディレクトリとして機能する無料の Web サイトを見つけたいと思います。
その目的のために既存の専用サーバーを再利用できますか?
特に動的 DNS を使用して各ピアを登録することを考えていますが、少し醜いことをいとわない場合は、既知の Hotmail アカウントまたは Google Doc などへのアクセスを共有します。
すでに確立されている中央サーバーを探している場合は、次のページのメタサーバーエントリを参照してください。http：//martindevans.appspot.com/
そこにピアを登録すると、他のピアがそれらを見つけることができます。明らかにこれは中央サーバーですが、メンテナンスは必要ありません。