私は現在、無料のペストリーDHTを使用していくつかのパフォーマンステストを行っています。Freepastryは、Javaで実行されるオープンソースのDHTです。
目標は、特定の数のノードがダウンしたときのDHTへの影響を監視することです。私の問題は、ノードを削除する最善の方法がわからないことです。現在、各ノードは私のマシンの異なるポートで実行されています。Pastry APIのdestroy（）メソッドを使用してこれらのノードを破棄していますhttp://www.freepastry.org/FreePastry/javadoc21a3/rice/pastry/PastryNode.html#destroy（）
これがノード障害のシミュレーションでは非現実的である可能性があり、tcpkillを使用するなどの別の方法でノードを強制終了する必要があるかどうかが心配です。
Mac OS Xユキヒョウを実行していますが、何か提案を聞きたいですか？
ノード障害にはさまざまな形式があります。
最も一般的なのは、DHTを実行しているアプリケーションがシャットダウンされたためにノードがオフラインになることです。
国内インターネット接続の動的IPの変更は、それに関する既存のルーティングテーブルエントリをすべて無効にするため、基本的に微妙に異なる効果がありますが、全体的なノード数は減少しません。あなたは1つを失い、あなたは新しいものを手に入れます。
もう1つの一般的な問題は、NATによる到達可能性の問題です。そのノードの可視性は、NATタイプと、最近ノードに接続したかどうかによって異なります。
結果として生じるチャーンの影響は、実際には非常に複雑になる可能性があります。まず第一に、個々のノードの稼働時間は一般に指数分布に従います。多くは短期間しか利用できず、数日または数か月間安定しているものはほとんどありません。
実際にネットワークの90％を構成する、中程度から長寿命のノードの安定したコアがあると想定します。同じノードの10％が絶えず存在し、存在しなくなると、オーバーヘッドトラフィックが発生しますが、ネットワークに大きな影響を与えることはありません。解約率は高くなりますが、影響はほとんどありません。
ノード母集団の10％が10分後にオフラインになり、非アクティブなプールからの新しいノードセットに置き換えられた場合、基本的に10分ごとに冗長性の10％が失われます。ノード間のデータレプリケーションがそれに追いついていないか、存在すらしていない場合、データは指数関数的に減衰します。また、解約率は高くなりますが、大きな影響があります。
どのようなシミュレーションが現実を最もよく反映するのかさえわかりません。最も現実的な制約は、潜在的なノードの固定プールを持つことだと思います。これは、DHTの実装がインストールされているコンピューターです。
次に、各ノードは、平均して稼働している時間と平均して下降する時間のプロファイルを持ちます（これらの2つのパラメーターは互いに部分的に相関しています。通常、長時間稼働ノードのダウンタイムはそれほど長くありません。おそらく常にオンになっているため）。そして、各ノードはこれらのパラメータに独立して作用します。実際には、ここで簡単に確認できるように、時刻も役割を果たします：http: //dsn.tm.uni-karlsruhe.de/english/2936.php
つまり...簡単に言えば、いくつかのノードをランダムに実行して強制終了するだけでは、影響が大きく異なるため、DHTの回復力について現実的な結果は得られません。
技術的な部分としては、それらすべてを同じJava VMで実行し、マルチスレッドまたはノンブロッキングIOを使用して、各インスタンスを別々のVMで実行するオーバーヘッドを削減することをお勧めします。これにより、より現実的な方法でアップタイムとダウンタイムをスケジュールすることもできます。
1台のコンピューターに複数のIPを割り当てることができるため、IP /ポート数に基づいて、コンピューター上で数十万のノードを実行できるはずです。しかし、プロセスのリソース消費は、最終的には最速のシステムでさえも行き詰まります。これは、実際にそれを適切に拡張するために実装されているDHT実装がほとんどないためです。
したがって、現実に近いものを得るには、コンピューターごとに数千のノードがあるネットワークでこれを実行する必要があります。
それか、実際の実装を実行する代わりに、より数学的なシミュレーションに頼ります。