[題名] 次世代情報共有プロトコルの提案2 [作成] 2000年11月15日 daishi@axlight.com [検討事項] 1. 名称 2. ノードIDについて 3. グローバルハッシュ関数について 4. ノードの強さ 5. プロクシ機能について 6. キャッシュ機能について 7. 能動的な情報発信について 8. DTDの例 [詳細] 1. 名称 プロトコルの名称：Global Information Interchange Protocol (GIIP) プロトコルの名称：Global Information Exchange Protocol (GIEP) プロトコルの名称：Global Information Sharing Protocol (GISP) ... プロジェクトの名称(ソフトウエアの名称)：jnushare プロジェクトの名称(ソフトウエアの名称)：jnuchange ... 2. ノードIDについて ノードIDは各ノードに自己申告させる方法も考えられるが、 一意性を確保するために、Ohaha!と同様 ホストとポートより算出する方が好ましいのではないか。 ただ、Ohaha!とは異なりホストには、 IPアドレスだけではなくホスト名も許可する。 これにより、接続の度にIPアドレスが変わるノードでも、 ダイナミックDNSのサービスを使うことによって、 ノードIDを一定に保つことができる。 3. ノードの強さ すべてのノードが同等と扱われるのには問題がある。 ノードはそれぞれ、回線速度、CPU速度、記憶容量等が異なる。 T1に繋がっている高速マシンと、モデム接続の非力なマシンに 同じ仕事をやらせるのは酷であろう。 Ohaha!では、ノードの強さというものを導入している。 理由は知らないが、0から10の整数で表現される。 ノードの強さを各ノードに自己申告してもらい、 ノードのハッシュ値とキーワードのハッシュ値の近さを 計算するときに重み付けて行う。 この計算方法は全てのノードで同一でなければならない。 この計算をどのように行うのかは今後の課題である。 まずは、Ohaha!の方式を参照してみるとよいと思う。 4. グローバルハッシュ関数について Ohaha!の場合はどうやら、MD5を使用しているようだ。 これなら、一般的に知られている計算であるから都合よいだろう。 5. プロクシ機能について NAT利用ノードもそれ以外のノードも、あるノードのプロクシ機能を利用できる。 ノードAからノードBにHTTPリクエストがあった場合にノードBは、 ノードAが実際にHTTPリクエストを発行したのか、 別のノードXからのHTTPリクエストを転送したのか、 分からないようにできれば、匿名性もある程度実現できる。 逆にプロクシ経由であることを明示することもできるとよい。 プロクシ機能に関してはプロトコル仕様としては最低限の仕様にして、 ほとんどの部分は、実装推奨とすればよいのではないだろうか。 HTTP/1.1はプロクシも考慮されているので、 それをうまく使えるとよいのだが。 6. キャッシュ機能について HTTP/1.1のキャッシュと同様に扱う。 有効期限なども指定できる。 7. 能動的な情報発信について グローバルハッシュ関数を用いると、 新なアイテムを(理想的には)全ノードの発信することもできる。 ノードAが情報を発信すると仮定する。 ノードAのビューは、ノードL,ノードM,ノードN、であるとする。 ノードAはハッシュ値の取り得る全範囲a〜bを3分割して、 各ノードにアイテムとそのノードが担当するハッシュ値の範囲を発信する。 このとき、ノードLの担当する範囲には、 ノードLのノードIDのハッシュ値が含まれるべきであり、 ノードL,M,Nの範囲とノードAのノードIDハッシュ値は、 a〜bを重なりなくカバーすべきである。 ノードLはノードAと同様に、自分の担当するハッシュ値範囲を、 ビューのノードに分割し、以下これを繰り返す。 自分の担当すハッシュ値範囲に、ビューのノードのノードIDのハッシュ値(長い...) が一つも無い場合は終了する。(一つしかない場合は特殊扱い) このようにすると、理想的には全てのノードに重複なくアイテムが 送られるはずである。 ただ、これは、各ノードが十分な大きさのビューを持っていて、 どこから発信しても仲間外れになるノードがいないことを仮定している。 8. DTDの例 HTTP/1.1で配信されるXMLのDTD。 文法の誤りがある可能性あり。 ---- 以上