私のペストリーの理解は、想像力を駆使しても完全ではありませんが、多かれ少なかれ機能するアルゴリズムのバージョンを構築するには十分でした. つまり、私が知る限り、私の実装は適切に機能します。
最初の質問に答えるには:
プロトコルによると、この [最初の] ノードには、この時点でルーティング テーブルが設定されているはずです。しかし、この時点ではリング内に他のノードはありません。では、どのようにしてルーティング テーブルの作成を開始するのでしょうか?
最初にノードとその状態/ルーティング テーブルを作成することで、この問題を解決しました。考えてみれば、ルーティング テーブルは、ネットワーク内の他のノードに関する単なる情報です。これはネットワーク内の唯一のノードであるため、ルーティング テーブルは空です。空のルーティング テーブルを作成する方法があると思いますか?
2 番目の質問に答えるには:
2 番目のノードがリングへの参加を希望する場合、最初のノードに Join メッセージ (ノード ID を含む) を送信します。このメッセージは、リング内に既に存在する、この 2 番目のノードで使用可能な最も近いネイバーにホップ単位で渡されます。これらのホップは、この新しい 2 番目のノードのルーティング テーブル エントリの作成に貢献します。繰り返しますが、十分な数のノードがない場合、これらすべてのエントリはどのように作成されるのでしょうか?
ペストリーについて説明している論文(PDF 警告!) をもう一度見てください。ノードがクラスタに参加して終了するプロセスを説明するのにかなり良い仕事をしています。
メモリが機能する場合、2 番目のノードは、そのノード ID を含むだけでなく、実際にはそのノード ID をメッセージのキーとして使用するメッセージを送信します。メッセージは、ネットワーク内の他のメッセージと同様にルーティングされるため、新しく参加したノードの ID に最も近い ID を持つノードにすばやく到達することが保証されます。メッセージが通過するすべてのノードは、新しく結合されたノードに状態テーブルを送信し、それを使用して状態テーブルにデータを入力します。この論文では、計算コストを削減することを意図した方法で状態テーブルにデータを入力するために情報を使用する際に、情報の出所を考慮に入れる詳細なロジックについて説明していますが、私の実装ではそれを無視しました。実装するのに費用がかさむのではなく、費用がかさむからです。
ただし、質問に具体的に答えるには、2 番目のノードが Join メッセージを最初のノードに送信します。最初のノードは、状態テーブル (空) を 2 番目のノードに送信します。2 番目のノードは、状態テーブルの送信者 (最初のノード) をその状態テーブルに追加し、次に、受信した状態テーブル内の適切なノードを自身の状態テーブルに追加します (この場合、ノードはありません)。最初のノードは、2 番目のノードの ID に近い ID を持つノードにメッセージを転送しますが、そのようなノードは存在しないため、メッセージは「配信された」と見なされ、両方のノードがこの時点でネットワークに参加していると見なされます。時間。
3 番目のノードが参加し、Join メッセージを 2 番目のノードにルーティングする必要がある場合、2 番目のノードは 3 番目のノードに状態テーブルを送信します。次に、3 番目のノードの ID が 1 番目のノードの ID に近いと仮定すると、2 番目のノードはメッセージを最初のノードに転送し、ノードは 3 番目のノードに状態テーブルを送信します。3 番目のノードは、これらの受信した状態テーブルから状態テーブルを作成し、その時点でネットワークに参加していると見なされます。
それが役立つことを願っています。