[p2p-sim-dev 0087] Re: =?iso-2022-jp?b?GyRCJVUlISUkJWslLSE8RVBPPyROJDskJCRHO0UbKEI=?= =?iso-2022-jp?b?GyRCTU1CZ0l9JEtKUTk5ISohKRsoQg==?=

[<abe...@gm...>]

ファイルキー登録を適切なキーサーバに登録する方法につきまして
案がありますので、メールにて展開します。

まず前提として、現在wikiに書いているシステムがベースです。

〔結論〕システム管理サーバ(管理サーバ)にファイルキー登録を代行させる

一般ノードはファイルキーに適切なクラスタキーワードを設定していきます。
ファイル1：A,B,C,D
ファイル2：A,E,F,G
ファイル３：H,I,J
ファイル４：L,M,N
ここで、一般ノードのファイルキー登録用クラスタ情報には限界があるので
グループ化することになります。

クラスタ情報：A  ファイル１、ファイル２
クラスタ情報：H　ファイル３、ファイル4

見たいな感じです。グループ化はクラスタ情報の共通部分でまとめるイメージとなります。
ただし、グループ化にも限界数があるため、
限界がきたらファイル4のように無理やり当てはめることになります。

さてここで管理サーバに登録を依頼します。
ファイル1の場合は、クラスタ情報Aに近い管理サーバにファイルキー登録を依頼します。
この際、ファイルキー内部情報として適切なクラスタ情報(A,B,C,D)も入れておきます。

後は管理サーバ内の情報からより近い管理サーバを見つけファイルキー情報を
再送します。再送先の管理サーバも同様の処理を繰り返します。
そんな具合で、定数回ホップし、より近い管理サーバに到達したところで
その下にぶら下がるキーサーバのうちもっとも近いキーサーバに登録します。

ホップを何度か行うためファイル4も適切な場所に登録されます。
またホップする際には当然ファイルキー内部情報を使用します。（言うまでもないか)

当然、負荷が増大するため
システム管理サーバ＜キーサーバ＜一般ノード
と言う比率ではなく
キーサーバ＜システム管理サーバ＜一般ノード
となるかもしれません。

名前も、管理サーバというより窓口サーバ？になるかもしれません。

追加案として

ホップしている間、ホップ先の管理サーバにぶら下がるキーサーバのクラスタ情報もチェックして、
一番近いキーサーバ情報を記憶しておき、定数回に達した時点での
一番近いキーサーバに登録する。

というのはどうでしょう？
いっそのこと検索も管理サーバにやらせてしまいますか？

<利点＞
キーサーバの負荷を減らせる。
管理サーバが多重登録を行うため、一般ノードの負荷も減らせる。

<欠点>
いまのところ思い浮かばない。

あとはキーサーバは管理サーバに登録する必要がありますが、
管理サーバのほうがノード数が増える場合、その辺の処理が変更になるかもしれません