JP4271620B2 - 分散型データ処理／管理装置及びその方法 - Google Patents

Description

本発明は、分散ハッシュ表技術を応用した分散型データ処理システムに係わり、特にシステムの応答の高速化を図った経路表の構成を特徴とする分散型データ処理／管理装置及びその方法に関する。

特定のサーバによらずに、ネットワークに継続的あるいは一時的に接続した計算機群によって構成される、分散型データ処理および管理システムとして、分散ハッシュ表技術を応用したシステムが知られている。
このようなシステムにおいて、ネットワークに継続的あるいは一時的に接続した計算機群は、ハッシュ関数を適用することにより得られる識別子を基準にして、お互いにアプリケーションレイヤネットワークを用いて接続している。

処理あるいは管理対象のデータは、ハッシュ関数を適用することにより得られる識別子によりアプリケーションレイヤネットワーク上を転送され、転送先計算機上で処理あるいは管理される。
このようなシステムの応答を高速化するためには、アプリケーションレイヤネットワーク上の転送にかかる時間を短縮することが望ましい。

ここで、分散型データ処理および管理システムに適用する分散ハッシュ表技術として、米国ＭＩＴ大学のThe Chord Projectが良く知られている（非特許文献１及び２参照）。
上記Chordシステムにおいては、ハッシュ関数としてSHA-1を採用しており、１６０ビットのハッシュ空間を構成する。
処理あるいは管理対象のデータは、ハッシュ関数SHA-1により１６０ビットの識別子が割り当てられる。

また、システムを構成する計算機についても、ネットワーク識別子、具体的には、IPアドレスとポート番号の組に対して、ハッシュ関数SHA-1を適用した１６０ビットの識別子により認識される。
ここで、上記１６０ビットのハッシュ空間は、図９に示すように、循環しているものとされる。
すなわち、２^１６０−１識別子から見て、正の方向（矢印Ａ）に１つ進んだ識別子は０であり、一方、識別子０から見て負の方向（矢印Ｂ）に１つ進んだ識別子は２^１６０−１である。

処理あるいは管理対象のデータは、割り当てられた識別子に基づき、システムを構成する計算機のいずれかが担当する。
また、上記データを処理あるいは管理するとき、ちょうど該当する識別子を持つ計算機がない場合は、データの識別子から見て正の方向において、次に現れる識別子を持つ計算機が担当することになる。
そして、システムを構成する計算機は、アプリケーションネットワークを構成することによってお互いに通信を行う。

このときのアプリケーションネットワークは、以下のように構成される。
システムを構成する計算機は、自身の識別子から見て正の方向について次に現れる識別子を持つ計算機を、自らのSUCCESSORとして認識している。
この場合認識しているとは、SUCCESSORのIPアドレスとポート番号とを知っており（保持しており）、SUCCESSORに対してメッセージを送信可能であることをあらわしている。
システムを構成する計算機は、同様に、自身の識別子から見て負の方向について次に現れる識別子を持つ計算機を、自らのPREDECESSORとして認識している。
この場合認識しているとは、PREDECESSORのIPアドレスとポート番号とを知っており（保持しており）、PREDECESSORへのメッセージの送信可能が明確であることをあらわしている。

以上のようにして構成されたアプリケーションネットワーク上において、識別子Ｘを持つ計算機がＹを識別子とするデータを担当する計算機にメッセージを送信する際、SUCCESSORに対して転送を繰り返すことでメッセージの送信が完了することは自明である。
ただし、システムを構成する計算機の数がＮであるとき、メッセージの転送回数は平均してＮ／２となり、Ｎが大きな数の場合に時間がかかりすぎるという問題が生じる。
このため、Chordシステムは上記問題に対して、FINGERと呼ばれる経路表（経路テーブル）を採用している。

システムを構成する計算機（ノード）は、エントリ０からエントリ１５９までの１６０エントリからなる経路表を有している。
ここで、識別子Ｘを持つ計算機について、エントリｉ（０≦ｉ≦１５９）としてのノードは、Ｘ＋２^ｉmod２^１６０の識別子のデータを担当する計算機（すなわち、ちょうどＸ＋２^ｉmod２^１６０の識別子を持つ計算機か、そのような計算機がない場合は、Ｘ＋２^ｉmod２^１６０の識別子から見て正の方向において次に現れる識別子を持つ計算機）となる。

このとき、エントリｉの経路表には、該当する計算機の識別子と、ネットワーク識別子、すなわち、IPアドレス及びポート番号が格納される。
このように構成された経路表を各計算機が有する場合、それらの計算機から構成されるアプリケーションネットワーク上において、識別子Ｘを有する計算機が、Ｙを識別子とするデータを担当する計算機にメッセージを送信するプロセスは以下の通りである。
まず、エントリｉは、自身の経路表を検索して、Ｙを正の方向で越えない識別子のうち最もＹに近づく識別子を含むエントリを抽出し、その識別子を持つ計算機にメッセージを転送する。

転送先の計算機においても、同様に、自身の経路表を検索して、Ｙを正の方向で越えない識別子のうち最もＹに近づく識別子を含むエントリを抽出し、その識別子を持つ計算機にメッセージを転送する。
以降の計算機においても、同様の処理を繰り返すことにより、識別子Ｙを持つ計算機にメッセージが到達することは自明である。
そして、経路表の構成から、転送を行う毎にハッシュ空間上での距離が半分になるため、FINGERを採用したシステムにおいては、システムを構成する計算機の数がＮの時、メッセージは最大log(Ｎ)回の転送を行うことで目的地に到達する。

経路表自体も、上記の特性を利用することにより効率的に構成することができる。
エントリｉは、ｉ＝０からｉ＝１５９までの順番で帰納的に構成される。
そして、ｉ＝０のとき、Ｘ＋２^０mod２^１６０＝Ｘ＋１mod２^１６０であり、エントリ０はSUCCESSOR（Ｘから見て正の方向において次に現れる識別子を持つ計算機）となる。
ここで、エントリｉ−１までが既に求められているとして、エントリｉを求めるには、識別子Ｘ＋２^ｉmod２^１６０のデータを担当する計算機（Ｘ＋２^ｉmod２^１６０ちょうどか、そのような識別子を持つ計算機が存在しない場合は、Ｘ＋２^ｉmod２^１６０計算機から見て正の方向において次に現れる識別子の計算機）宛にメッセージを送信することになる。

しかしながら、このとき、既に求められているエントリ０からエントリｉ−１までのうちで識別子Ｘ＋２^ｉmod２^１６０を、正の方向において越えない識別子のなかから、最も識別子Ｘ＋２^ｉmod２^１６０の計算機に近づくエントリ、すなわち、エントリｉ−１の計算機に対してメッセージを転送すればよい。
上述した転送により、ハッシュ空間上での距離は半分になる。
そして、転送先の計算機で経路表が適切に構成されていれば、転送先からも転送ごとに距離が半分になる。

このため、最大ｉ回の転送で目的地である識別子Ｘ＋２^ｉmod２^１６０のデータを担当する計算機（Ｘ＋２^ｉmod２^１６０ちょうどか、そのような識別子を持つ計算機が存在しない場合は、Ｘ＋２^ｉmod２^１６０から見て正の方向において次に現れる識別子の計算機)にメッセージは到達する。
このようにしてエントリｉは求められる。以上の処理により、エントリ０からエントリ１５９は効率的に構成されうる。
以上で述べた方法をシステムを構成する各計算機で定期的に繰り返し行うことで、各計算機のFINGERによる経路表は適切に保たれる。
http：／／www．pdos．lcs．mit．edu／chord／ Ion Stoica，Robert Morris，David Karger，M．Frans Kaashoek，and Hari Balakrishnan，Chord：A Scalable Peer-to-peer Lookup Service for Internet Applications，ＡＣＭ ＳＩＧＣＯＭＭ 2001，SanDeigo，CA，August 2001，pp．149−160

上述したように、特許文献１及び２に示すChordシステムは、FINGERによる経路表構成法の採用により、システムを構成する計算機の数がＮのとき、アプリケーションネットワーク上で最大1og(Ｎ)回、平均してlog(Ｎ)／２回の転送を繰り返すことにより、任意の２計算機の間でメッセージを送信することができる。
しかしながら、Chordシステムをインターネットに適用したとして、システムを構成する計算機の数が１００万台程度であるとした場合、log(１０^６)≒２０であることから、平均して１０回の転送がアプリケーションネットワーク上で必要となる。

これはアプリケーションネットワーク上での転送回数であり、経由するルータの数で考えた場合、更に大きな転送回数となる。
したがって、Chordシステムは、理論上効率的なシステムであるとはいえ、実動作環境への適用を考える場合、応答時間の制約から、この転送回数は可能な限り少なくすべきものである。
また、ChordシステムのFINGERによる経路表構成法には、以下に示すように、大きな無駄が存在する。

システムを構成する計算機が１００万(≒２^２０)台程度であるとき、ハッシュ関数SHA-1によって、それぞれの識別子は、１６０ビットのハッシュ空間上に均一に散らばることが期待される。
このとき、隣接する二つの識別子は、平均して２^１４０離れた位置に存在していることになる。
すなわち、識別子Ｘを有するある計算機にとって、そのSUCCESSORは、およそＸ＋２^１４０mod２^１６０という識別子を待つことになる。

この場合、FINGERによる経路表構成法においては、エントリ０からエントリ１４０近傍までが、すべて同じエントリを待つことを意味する。
このため、経路表には１６０エントリが保持されているが、その大半が無駄に使われていることになる。
FINGERは一回の転送ごとに目的地へのハッシュ空間上の距離を半分にすることができたが、無駄に使われているエントリを工夫することにより、一回の転送ごとにFINGERよりも効率よく目的地へのハッシュ空間上の距離をつめることが可能である。

本発明は、このような事情に鑑みてなされたもので、FINGERとは異なる経路表構成法を採用することにより、経路表の無駄を省き、１００万台程度の計算機から構成されるインターネットワイドなシステムの場合、Chordシステムよりも少ない転送回数を実現し、システムの応答時間を改善する分散型データ処理／管理装置及びその方法を提供するものである。

本発明の分散型データ処理／管理装置は、分散ハッシュ表技術を用いた160ビットのハッシュ空間を有するChordシステムと同様のメッセージ転送機能を有する分散型データ処理／管理装置であって、通信ネットワークと接続され、他の分散型データ処理／管理装置とメッセージの送受信を行う通信処理部と、該通信処理部において受信したメッセージが自身の担当するデータでないことを検出した場合、該メッセージを転送すべき他の分散型データ処理／管理装置を決定するため、経路表を再構成する経路表処理部とを有し、Chordシステムの経路表構成法が、ｉ番目のエントリについて、自身の識別子から２^ｉだけ離れた識別子を基準とするのに対し、前記経路表処理部が、自身の識別子から、unit×base^ｉだけ離れた識別子を基準として、ｉ番目のエントリに対する経路表の再構成を行うことを特徴とする。
unit＝(自身の識別子から正方向において次に出現する装置の識別子)−(自身の識別子)
base＝２×unit^{（−１／１６０）}

本発明の分散型データ処理／管理装置は、メッセージの送信経路を示す前記経路表が格納された経路表管理部を有し、前記経路表処理部が一定周期毎に該経路表管理部における経路表の再構成を行うことを特徴とする。

本発明の分散型データ処理／管理方法は、分散ハッシュ表技術を用いた160ビットのハッシュ空間を有するChordシステムと同様のメッセージ転送過程を有する分散型データ処理方法であって、通信ネットワークと接続され、他の分散型データ処理／管理装置とメッセージの送受信を行う通信処理過程と、該通信処理過程において受信したメッセージが自身の担当するデータでないことを検出した場合、該メッセージを転送すべき他の分散型データ処理／管理装置を決定するため経路表を再構成する経路表処理過程とを有し、Chordシステムの経路表構成法が、ｉ番目のエントリについて、自身の識別子から２^ｉだけ離れた識別子を基準とするのに対し、前記経路表処理過程において、自身の識別子から、unit×base^ｉだけ離れた識別子を基準として、ｉ番目のエントリに対する経路表の再構成を行うことを特徴とする。
unit＝(自身の識別子から正方向において次に出現する装置の識別子)−(自身の識別子)
base＝２×unit^{（−１／１６０）}

本発明の分散型データ処理／管理方法は、メッセージの送信経路を示す前記経路表が格納された経路表管理部を有し、前記経路表処理過程が一定周期毎に行われ、該経路表管理部における経路表の再構成を行うことを特徴とする。

Chordシステムにおいては、識別子Ｘを持つある計算機の経路表の構成を、エントリｉについて、識別子「Ｘ＋２^ｉmod２^１６０」を持つデータを担当する計算機の識別子としていた。
一方、本発明においては、経路表のエントリ数について、ChordシステムのFINGERによるものと同様に、１６０エントリとするが、エントリｉについて、以下の（１）式から求められる値の識別子を有するデータを担当する計算機の識別子とする。
エントリｉの識別子＝Ｘ＋unit×base^ｉmod２^１６０ …（１）
ただし、
unit＝（ＸのＳＵＣＣＥＳＳＯＲの識別子）−Ｘ
base＝２×unit^{（−１／１６０）}
とする。

本実施例においては、１６０ビットのハッシュ空間を１６０回同じbaseなる数で割り算した場合、最終的に「（ＸのＳＵＣＣＥＳＳＯＲの識別子)−Ｘ」が得られるように、baseの値を選択している。
上述のようにbaseを選ぶことにより、ｉ＝０の場合、上記（１）式は、ＳＵＣＣＥＳＳＯＲの識別子となり、エントリ０はＳＵＣＣＥＳＳＯＲとなる。
また、ｉ＝１の場合、baseは１以上であるため、エントリ１はＳＵＣＣＥＳＳＯＲの識別子より正の方向で越えた識別子となることがわかる。すなわちエントリ０とエントリ１は異なることがわかる。

ChordシステムのＦＩＮＧＥＲの場合は、unitを１とし、baseを２とした構成となっているため、大半のエントリにおいて同じ識別子を持つ装置となったが、本発明においては同じ識別子を有する装置となることをを避けることが可能となる。
ここで、各エントリの対象が異なるだけで、他の構成はChordシステムにおけるＦＩＮＧＥＲによる経路表（もしくは経路テーブル）構成法と同様のプロセスとなり、また、メッセージの転送についても同様である。

以上説明したように、本願発明の分散型データ処理／管理装置によれば、経路表の構成法を工夫することにより、シミュレーションの結果から、１００万台程度の計算機から構成されるインターネットワイドなシステムに対して、従来のChordシステムと同程度の手間で、Chordシステムと比べて約半分の転送回数を実現し、システムの応答時間を改善し、かつ、Chordシステムと比べて経路表の無駄なエントリを省くことができ、経路表を有効に活用することを可能とした。

以下、本発明の一実施形態による装置を図面を参照して説明する。図１は同実施形態による分散型データ処理／管理装置の構成例を示すブロック図である。また、この図１は複数の分散型データ処理／管理装置が通信ネットワークＴにより、相互に接続している形態を示している。
この図において、本実施形態の分散型データ処理／管理装置は１、通信ネットワークＴと接続され、他の分散型データ処理／管理装置とメッセージの送受信を行うため、または自身が担当するデータを含むか否かを検出するための通信処理部２と、通信処理部２において受信したメッセージが自身が担当するデータを含む場合にその処理を行うためのデータ処理部３と、データ処理部３において処理するデータを読み出しあるいは書き込みするためのデータ管理部４と、通信処理部２において受信したメッセージが自身が担当するデータでない場合にメッセージを転送すべき他の分散型データ処理／管理装置を決定するため、また、経路表を適切に保つために定期的に経路表管理部５の再構成を行うための経路表処理部６と、経路表処理部６によって定期的に再構成される経路表を格納するための経路表管理部５と、を有している。
上述したように、分散型データ処理／管理装置は、通信処理部２を介して、通信ネットワークＴと接続され、通信ネットワークＴの提供するメッセージ配信機能を利用して、他の分散型データ処理／管理装置相互間のメッセージの送受信を行う。

次に、図２を参照して、経路表管理部６に格納される経路表の説明を行う。図２は、経路表管理部６に格納される経路表のデータ構造の一例を示したものである。
経路表は、エントリ０からエントリ１５９までの１６０エントリで構成される。
ここで、各エントリは、エントリ番号と、分散型データ処理／管理装置の識別子と、分散型データ処理／管理装置のIPアドレスと、分散型データ処理／管理装置のポート番号とからなる。
そして、経路表は、更にSUCCESSORとPREDECESSORとを管理する二つの特別なエントリを有しており、これらのエントリの構成も同様である。

次に、図３を参照して、分散型データ処理／管理装置間で送受信されるメッセージの説明を行う。図３は、上記メッセージのフォーマットの一例を示したものである。
メッセージは、図３に示すように、メッセージの送信先を示す送信先識別子と、メッセージによって運ばれるデータの処理方法を示すコマンドと、送信するデータと、送信元装置のIPアドレスと、送信元装置のポート番号との各項目を有している。

次に、図１及び図４を参照して、本実施例の分散型データ処理／管理装置１のデータ受信処理の動作を説明する。図４は、本実施例の分散型データ処理／管理装置１のデータ受信処理の流れを示すフローチャートである。
通信処理部２は、通信ネットワークＴに接続後、他の分散型データ処理／管理装置からのメッセージを受信する（ステップＳ１）。
そして、通信処理部２は、受信したメッセージの送信先識別子を見て、自身が担当するデータを含むか否かを検出、すなわち自身が担当すべきデータであるか否かを判断する。

すなわち、通信処理部２は、メッセージの送信先識別子がPREDECESSORの識別子から見て正の方向にあり、かつ、自身の識別子から見て負の方向にあるときは自身が担当すべきデータであることを検出し、上述したいずれかの条件が満たされない場合、自身が担当すべきデータではないことを検出する（ステップＳ２）。
そして、通信処理部２は、自身が担当すべきデータであると判断した場合、このメッセージをデータ処理部３へ出力する。

これにより、データ処理部３は、メッセージに示されているコマンドに従い、含まれるデータに対してデータ処理を行う。
その際、データ処理部３は、必要に応じてデータ管理部４へのデータの書き込み、あるいは、データの読み出しを行う。
また、データ処理部３は、必要に応じて、データ処理の結果を、メッセージの送信元IPアドレス及び送信元ポート番号を用い、送信元の分散型データ処理／管理装置に応答する（ステップＳ３）。

一方、通信処理部２は、受信したメッセージの送信先識別子から、このメッセージが自身が担当すべきデータを含んでいないことを検出した場合、このメッセージを他の分散型データ処理／管理装置への転送を試みる。
このとき、通信処理部２は、経路表処理部３を介して、経路表管理部６に格納されている経路表から、メッセージの送信先識別子を正の方向において越えないものの中から、最もメッセージに含まれる送信先識別子に近づく識別子を持つエントリを検索する（ステップＳ４）。

そして、経路表処理部４は、上記経路表から抽出したエントリから、転送すべき分散型データ処理／管理装置のIPアドレス及びポート番号を読み取り、メッセージの転送先の分散型データ処理／管理装置を決定する（ステップＳ５）。
これにより、通信処理部２は、得られたIPアドレス及びポート番号の示す分散型データ処理／管理装置に対して、メッセージの転送を行う（ステップＳ６）。

次に、図１及び図５を参照して、本実施例の分散型データ処理／管理装置１のデータ送信処理の動作を説明する。図５は、本実施例の分散型データ処理／管理装置１のデータ送信処理の流れを示すフローチャートである。
通信処理部２は、データ処理あるいは管理のため、他の分散型データ処理／管理装置に対して、メッセージを送信する必要が生じた場合、ハッシュ関数SHA-1を適用して所定の数値として得られる送信先識別子と、データの処理方法を現すコマンドと、データと、送信元である自身のIPアドレスと、自身のポート番号とを有する、図３に示すメッセージを生成する（ステップＳ１１）。

次に、経路表処理部５は、経路表管理部６に格納されている経路表を検索して、メッセージの送信先識別子を正の方向において越えないものの中から、最も送信先識別子に近づく識別子を持つエントリを抽出する（ステップＳ１２）。
そして、経路表処理部５は、抽出したエントリから、転送すべき分散型データ処理／管理装置のIPアドレス及びポート番号を読み取り、送信先の分散型データ処理／管理装置を決定する（ステップＳ１４）。
これにより、通信処理部２は、上述のように得られたIPアドレス及びポート番号の示す分散型データ処理／管理装置に対して、メッセージの送信を行う（ステップＳ１４）。

次に、図１及び図６を参照して、本実施例の分散型データ処理／管理装置１の経路表の再構成処理の動作を説明する。図６は、本実施例の分散型データ処理／管理装置１の経路表の再構成処理の流れを示すフローチャートである。
経路表処理部５は、エントリｉに設定すべき他の分散型データ処理／管理装置の識別子を求めるためのターゲット識別子Ｉを０に設定して、初期化を行う（ステップＳ２１）。
次に、経路表処理部５は、上記ターゲット識別子Ｉを計算する。

すなわち、具体的には、以下の式を用いターゲット識別子を計算する。
ターゲット識別子 ＝ Ｘ＋unit×base^ｉmod２^１６０
ただし、Ｘ＝自身の識別子
Unit＝SUCCESSORの識別子−Ｘ
Base＝２×unit^{（−１／１６０）}
である。

また、プログラム処理系によっては、２^１００をこえるような巨大な数に対するべき乗の計算が困難である場合がある。
たとえば、Java（登録商標）言語が上記場合にあたり、このような場合、上記baseの計算には下記の変形式を用いる。
Base＝２×unit^{（−１／１６０）} ＝ ２×２^{(−log(unit)/１６０)}
ここで、log(unit)はおおよそunitのビット長であるとしてよい。

そこで、
Base＝２×２^{（−（unitのビット長）／１６０）}
となる。
そして、Java（登録商標）言語であれば、unitがBigIntegerであるとして、
Base＝２×Math.pow(２，−(unit．bitLength())／１６０）
により計算可能となる。
経路表処理部５は、上述したのような演算処理により、ターゲット識別子Ｉを求める（ステップＳ２２）。

次に、経路表処理部５は、得られたターゲット識別子から、エントリｉに格納すべき分散型データ処理／管理装置の情報が既知であるか否かの判定を行う。
このとき、経路表処理部５は、Ｉ＝０であるとき、常に既知であると判定し、一方、Ｉ≧１であるとき、エントリｉ−１の識別子を正の方向において越えない場合に既知であると判定し、超える場合に既知ではないことを判定する（ステップＳ２３）。
そして、経路表管理部５は、ターゲット識別子に関わる分散型データ処理／管理装置の情報が既知でない場合、判定結果を通信処理部２に対して通知する。
これにより、通信処理部２は、送信先識別子として得られたターゲット識別子と、担当する分散型データ処理／管理装置からの応答を促すコマンドと、データとしてヌルデータと、自身のIPアドレスと、自身のポート番号とを有するメッセージの生成を行う（ステップＳ２４）。

次に、通信処理部２は、エントリｉ−１の分散型データ処理／管理装置のIPアドレスとポート番号あてに、作成したメッセージの送信を行う。
これにより、送信先の分散型データ処理／管理装置においては、すでに説明したメッセージ受信処理と同様に、自身が担当するものであると判断する分散型データ処理／管理装置まで、メッセージの転送を繰り返し行う。
そして、メッセージが最終的に到連した分散型データ処理／管理装置においては、自身についての情報、すなわち、識別子、IPアドレス、及びポート番号の応答を、メッセージの送信元に対して行う（ステップＳ２５）。

次に、通信処理部２（送信元の分散型データ処理／管理装置）は、メッセージが最終的に到連した分散型データ処理／管理装置端末からの応答を受信する（ステップＳ２６）。
そして、通信処理部２は、ターゲット識別子に関わる分散型データ処理／管理装置が既知であると判定した場合、また、応答を受信した場合、経路表処理部２に対して経路表の再構成を指示する。
これにより、経路表処理部５は、ターゲット識別子に関わる分散型データ処理／管理装置が既知でないと判定され、かつ、応答を受信した場合、経路表管理部６に格納される経路表のエントリｉの更新を行う（再構成を行う）。

このとき、経路表処理部５は、応答を受信した場合、応答のメッセージから取り出した識別子、IPアドレス、及びポート番号によりエントリｉの更新を行う。
一方、経路表処理部５は、ターゲット識別子に関わる分散型データ処理／管理装置が既知であると判定されている場合、エントリｉ−１と同じ識別子、IPアドレス、及びポート番号によりエントリｉを更新する（ステップＳ２７）。
そして、経路表処理部５は、ｉが１６０以上になったか否かを検出し、ｉが１６０以上となったことを検出した場合、経路表の再構成の処理を終了し、ｉが１６０未満であることを検出した場合、処理をステップＳ９へ進める（ステップＳ２８）。

次に、経路表処理部５は、ｉを１だけ増加させて、処理をステップＳ２２へ戻す（ステップＳ２９）。
上述した処理が、経路表再構成の一連の手続きである。
また、分散型データ処理／管理装置１は、一定の周期において、定期的に（例：１分ごと）、上述した経路表再構成処理を繰り返すし、常に、経路表を適切に保たせる。

次に、図７及び図８を参照して、本実施例のシミュレーション結果の説明を行う。図７及び図８は、１００万台の装置からなるシステムについてのシミュレーション結果を示した表及びグラフである。
図７に示す表における列は、それぞれシミュレーションに用いた装置数、装置数に対応したChordを用いた場合の平均転送回数、装置数に対応した本発明での平均転送回数、装置数に対応した本発明の平均転送回数をChordでの平均転送回数で割ったものである。

また、図８は、Chordでの平均転送回数と本発明での平均転送回数とをグラフにプロットしたものであり、横軸がシミュレーションに用いた装置数であり、縦軸が平均点総回数を示している。
図７及び図８から明らかなように、シミュレーション結果は、本発明がChordシステムに比べて約半分の転送回数を実現しており、転送回数を削減することが可能であることを示している。

なお、図１における分散型データ処理／管理装置の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりメッセージの送受信における分散型データ処理／管理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷシステムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

分散型データ処理／管理装置の内部構成と、通信ネットワークＴに複数の分散型データ処理／管理装置１が接続している様を図示したものである。 図１の経路表管理部に格納される経路表の構成例を示す概念図である。 分散型データ処理／管理装置間で送受信されるメッセージのフォーマット例を図示したものである。 分散型データ処理／管理装置のメッセージ受信に関する手順を示したフローチャートである。 分散型データ処理／管理装置のメッセージ送信に関する手順を示したフローチャートである。 分散型データ処理／管理装置の経路表再構成の手順を示したフローチャートである。 Chordシステムと本発明のそれぞれについて、平均転送回数を求めるシミュレーション結果において、使用した装置数と上記平均回数との対応を示す表である。 Chordシステムと本発明のそれぞれについて、平均転送回数を求めるシミュレーション結果において、使用する装置数と上記平均回数との対応を示すグラフである。 ハッシュ空間における識別子の循環性を説明する概念図である（時計回りに順次エントリが移動する）。

符号の説明

１…分散型データ処理／管理装置
２…通信処理部
３…データ処理部
４…データ管理部
５…経路表処理部
６…経路表管理部
Ｔ…通信ネットワーク

Claims (4)

1. 分散ハッシュ表技術を用いた160ビットのハッシュ空間を有するChordシステムと同様のメッセージ転送機能を有する分散型データ処理／管理装置であって、
   通信ネットワークと接続され、他の分散型データ処理／管理装置とメッセージの送受信を行う通信処理部と、
   該通信処理部において受信したメッセージが自身の担当するデータでないことを検出した場合、該メッセージを転送すべき他の分散型データ処理／管理装置を決定するため、経路表を再構成する経路表処理部と
   を有し、
   Chordシステムの経路表構成法が、ｉ番目のエントリについて、自身の識別子から２^ｉだけ離れた識別子を基準とするのに対し、
   前記経路表処理部が、自身の識別子から、unit×base^ｉだけ離れた識別子を基準として、ｉ番目のエントリに対する経路表の再構成を行うことを特徴とする分散型データ処理／管理装置。
   unit＝(自身の識別子から正方向において次に出現する装置の識別子)−(自身の識別子)
   base＝２×unit^{（−１／１６０）}
2. メッセージの送信経路を示す前記経路表が格納された経路表管理部を有し、
   前記経路表処理部が一定周期毎に該経路表管理部における経路表の再構成を行うことを特徴とする請求項１記載の分散型データ処理／管理装置。
3. 分散ハッシュ表技術を用いた160ビットのハッシュ空間を有するChordシステムと同様のメッセージ転送過程を有する分散型データ処理／管理方法であって、
   通信ネットワークと接続され、他の分散型データ処理／管理装置とメッセージの送受信を行う通信処理過程と、
   該通信処理過程において受信したメッセージが自身の担当するデータでないことを検出した場合、該メッセージを転送すべき他の分散型データ処理／管理装置を決定するため経路表を再構成する経路表処理過程と
   を有し、
   Chordシステムの経路表構成法が、ｉ番目のエントリについて、自身の識別子から２^ｉだけ離れた識別子を基準とするのに対し、
   前記経路表処理過程において、自身の識別子から、unit×base^ｉだけ離れた識別子を基準として、ｉ番目のエントリに対する経路表の再構成を行うことを特徴とする分散型データ処理／管理方法。
   unit＝(自身の識別子から正方向において次に出現する装置の識別子)−(自身の識別子)
   base＝２×unit^{（−１／１６０）}
4. メッセージの送信経路を示す前記経路表が格納された経路表管理部を有し、
   前記経路表処理過程が一定周期毎に行われ、該経路表管理部における経路表の再構成を行うことを特徴とする請求項３記載の分散型データ処理／管理方法。
   

Images