JP5177919B2 - インデックスサーバとその方法 - Google Patents
インデックスサーバとその方法 Download PDFInfo
- Publication number
- JP5177919B2 JP5177919B2 JP2012506309A JP2012506309A JP5177919B2 JP 5177919 B2 JP5177919 B2 JP 5177919B2 JP 2012506309 A JP2012506309 A JP 2012506309A JP 2012506309 A JP2012506309 A JP 2012506309A JP 5177919 B2 JP5177919 B2 JP 5177919B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- node information
- server
- index server
- storage unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
- G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
- G06F16/1837—Management specially adapted to peer-to-peer storage networks
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Description
本発明は、一般にピアツーピア(P2P)ネットワークに関し、特に、P2Pネットワークのインデックスサーバとその方法に関する。
P2Pネットワークは、アドホック方式で複数のユーザによって形成される分散型ネットワークである。これらのユーザは「ノード」と称される。ノードは、データファイル、計算能力、記憶性能および帯域幅などの様々なリソースを共有することが可能である。データファイル(以下、データあるいはファイルとも称される)は、画像ファイル、オーディオファイル、ビデオファイルなどを含んでいる。ノードがファイルをダウンロードしたい場合、P2Pネットワーク内のどのノードがそのファイルを有するか、すなわち、どのノードがそのファイルを提供できるかを知らなければならない。既存のP2Pシステムは、通常、ファイルのメタデータを格納するために集中型のインデックスサーバを用いる。ファイルのメタデータは、ファイルの属性、例えばそのファイルのサイズやそのファイルを提供可能なノードを記述する。このメタデータはファイルを提供可能なノードによってインデックスサーバに報告される。ファイルをダウンロードしたいノード(要求側ノード)から要求を受信すると、インデックスサーバは、情報のメタデータを参照することにより、ファイルを提供可能なノードのサブセット(部分集合)を要求側ノードに通知する。その後、要求側ノードとノードのサブセットの間でファイルの送信が発生する。
通常、既存のインデックスサーバは、要求側ノードに通知するそのようなサブセットをランダムに選択する。そのようなランダムな応答は、重大な「クロスISPトラフィック(cross−ISP traffic)」問題を引き起こす。すなわち、第1のインターネット・サービス・プロバイダ(ISP)ISP1によって提供されるノード、言いかえればISP1内のノードは、たとえISP1内の他のノードがダウンロード可能なデータを有しても、ISP2内のノードからデータをダウンロードしてしまう。
クロスISPトラフィックを減少するため、位置認識記憶構造(location−aware storage structure)が、大規模P2Pネットワークシステムにおいてメタデータを格納するために提案されている。
大規模P2Pネットワークにおけるメタデータ情報の記憶と検索の問題について、以下に説明する。
サイズO(N×D)のメタデータ・テーブルを仮定する。ここで、DはP2Pネットワークにおいて共有されるファイルの合計数であり、NはP2Pネットワーク内のノードの合計数である。メタデータ・テーブルは、D個のファイルにそれぞれ関連するD個のメタデータを含んでいる。
以下、1つのファイルに関連する1つのメタデータを、例えば、「ファイルのメタデータ」あるいは「ファイルに関連するメタデータ・エントリ」と称する。メタデータ・エントリは、1以上のノード情報項目を含んでいる。各ノード情報項目はファイルを提供する1つのノードについて記述する。
以下、1つのファイルに関連する1つのメタデータを、例えば、「ファイルのメタデータ」あるいは「ファイルに関連するメタデータ・エントリ」と称する。メタデータ・エントリは、1以上のノード情報項目を含んでいる。各ノード情報項目はファイルを提供する1つのノードについて記述する。
1.複数のインデクシングサーバにそれぞれのファイルのメタデータ・エントリを拡張的な方法でどのように分配するか。
2.要求Req(M、Di、T)が要求側ノードから受信されるとき(ここで、Mは要求側ノードの標識(例えば、IPアドレス)、Diは希望するファイルの標識、TはノードMが取得することを望むファイルDiに関連するノード情報項目(例えば、ノードのアドレス)の数である)、応答は以下のように作成すべきである。
i)メタデータ・テーブルにおけるファイルDiに関連するノード情報項目の数がTより小さいか或いはTと等しい場合、要求側ノードMにできるだけ多くのノード情報項目を返す。
ii)メタデータ・テーブルにおけるファイルDiに関連するノード情報項目の数がTより大きい場合、ファイルDに関連するノード情報項目からT個のノード情報項目を選択する。選択されたT個のノード情報項目は、要求側ノードにできるだけ接近しているノードを示すべきである。
i)メタデータ・テーブルにおけるファイルDiに関連するノード情報項目の数がTより小さいか或いはTと等しい場合、要求側ノードMにできるだけ多くのノード情報項目を返す。
ii)メタデータ・テーブルにおけるファイルDiに関連するノード情報項目の数がTより大きい場合、ファイルDに関連するノード情報項目からT個のノード情報項目を選択する。選択されたT個のノード情報項目は、要求側ノードにできるだけ接近しているノードを示すべきである。
ここで、ノードの位置は、例えば、(ISP,Region)として定義され、ノードを提供するインターネット・サービス・プロバイダとノードの地理的エリアを示す。ノードと要求側ノードの間の「接近度」は以下のように定義される。2つのノードAとBについて、ノードAが要求側ノードと同一のISP内にあり、ノードBがそうでなければ、ノードAはノードBより要求側ノードに接近している。
ノードAとBの両方が要求側ノードと同一のISP内にあるか、或いはAもBも要求側ノードと同一のISP内にない場合、およびノードAが要求側ノードと同一のエリア内にあり、ノードBがそうでなければ、ノードAはノードBより要求側ノードに接近している。
さらに、両方のノードAとBが、要求側ノードと同一のISP及び同一のエリア内にある場合、あるいは、ノードAとBの両方が要求側ノードと異なるISP及び異なるエリア内にある場合、ノードAとBは、要求側ノードへの「接近度」に関して任意に順序付けられる。
ノードAとBの両方が要求側ノードと同一のISP内にあるか、或いはAもBも要求側ノードと同一のISP内にない場合、およびノードAが要求側ノードと同一のエリア内にあり、ノードBがそうでなければ、ノードAはノードBより要求側ノードに接近している。
さらに、両方のノードAとBが、要求側ノードと同一のISP及び同一のエリア内にある場合、あるいは、ノードAとBの両方が要求側ノードと異なるISP及び異なるエリア内にある場合、ノードAとBは、要求側ノードへの「接近度」に関して任意に順序付けられる。
中国特許出願公開101355591(A)「P2Pネットワークとその調整方法」(特許文献1)においては、メタデータ・テーブルがファイル次元に分配される。
具体的には、複数のインデックスサーバがDHTネットワークを形成する。各ファイルのメタデータは、ファイルのIDに従って対応するインデックスサーバ内に格納される。要求側ノードがデータファイルを要求している時、さらに具体的にはデータファイルを提供可能なノードに関する情報を要求している時、要求側ノードは自身のホームインデックスサーバ(home indexing server)に要求を送信する。その要求は、DHTネットワーク内を経由して、ファイルのIDに基づいてファイルのメタデータを格納するために割り当てられている目的インデックスサーバ(destination indexing server)に到着する。
目的インデックスサーバは、ホームインデックスサーバにファイルのメタデータを送信し、そして、ホームインデックスサーバは、要求側ノードに対する「接近度」に従ってメタデータによって示されるノードをソートし、N個の最も近いノードを要求側ノードに通知する。
具体的には、複数のインデックスサーバがDHTネットワークを形成する。各ファイルのメタデータは、ファイルのIDに従って対応するインデックスサーバ内に格納される。要求側ノードがデータファイルを要求している時、さらに具体的にはデータファイルを提供可能なノードに関する情報を要求している時、要求側ノードは自身のホームインデックスサーバ(home indexing server)に要求を送信する。その要求は、DHTネットワーク内を経由して、ファイルのIDに基づいてファイルのメタデータを格納するために割り当てられている目的インデックスサーバ(destination indexing server)に到着する。
目的インデックスサーバは、ホームインデックスサーバにファイルのメタデータを送信し、そして、ホームインデックスサーバは、要求側ノードに対する「接近度」に従ってメタデータによって示されるノードをソートし、N個の最も近いノードを要求側ノードに通知する。
具体的には、各インデックスサーバはローカルのフィンガーテーブル(Finger Table)を保持している。要求を受信すると、インデックスサーバは、フィンガーテーブル上でDHT探索(DHT lookup)を実行する。インデックスサーバが要求されたファイルのメタデータを格納していれば、ヒットが生じる。そうでなければ、フィンガーテーブルが、その要求を送る次のホップインデックスサーバ(hop indexing server)を示す。DHTアルゴリズムは、要求が経由するホップ数が、O(log(n))であることを保証する。ここで、nはDHTネットワーク内のインデックスサーバの数である。
DHTアルゴリズムの実施詳細については、I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, Chord: A Scalable Peer−to−peer Lookup Service for Internet Applications, In Proceedings of SIGCOMM 2001, San Deigo, CA, August 2001(非特許文献1)に記載されている。
DHTアルゴリズムの実施詳細については、I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, Chord: A Scalable Peer−to−peer Lookup Service for Internet Applications, In Proceedings of SIGCOMM 2001, San Deigo, CA, August 2001(非特許文献1)に記載されている。
I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, Chord: A Scalable Peer−to−peer Lookup Service for Internet Applications, In Proceedings of SIGCOMM 2001, San Deigo, CA, August 2001
以上から分かるように、データファイルを提供するP2Pネットワーク内のノードの数がますます多くなるに従い、対応するインデックスサーバ内に格納されるデータファイルに関連するメタデータ・エントリのサイズがそれに応じて増大する。
例えば、PPLive(Gale Huang, PPLive − A Practical P2P Live System with Huge Amount of Users)の運用データによる報告によれば、2005年に人気のテレビ番組「Super Girl」のオンライン生中継ビデオを観たユーザはピーク時に25万人以上であった。
よって、「Super Girl」生中継ビデオのデータファイルのノード情報を格納するのに割り当てられている1つのサーバ内にこれらのすべてのユーザ(ノード)に関する情報を格納することは非常に難しい。
それと同時に、データファイルに関連するノード情報についての要求を要求側ノードから受信した時、サーバは、データファイルを提供する全てのノードを位置に応じてソートするのに多くの時間を費やさなければならず、このことが、要求側ノードに対する応答において許容し難い遅延を引き起こす。
例えば、PPLive(Gale Huang, PPLive − A Practical P2P Live System with Huge Amount of Users)の運用データによる報告によれば、2005年に人気のテレビ番組「Super Girl」のオンライン生中継ビデオを観たユーザはピーク時に25万人以上であった。
よって、「Super Girl」生中継ビデオのデータファイルのノード情報を格納するのに割り当てられている1つのサーバ内にこれらのすべてのユーザ(ノード)に関する情報を格納することは非常に難しい。
それと同時に、データファイルに関連するノード情報についての要求を要求側ノードから受信した時、サーバは、データファイルを提供する全てのノードを位置に応じてソートするのに多くの時間を費やさなければならず、このことが、要求側ノードに対する応答において許容し難い遅延を引き起こす。
そのため、効率的な方法でP2Pネットワークのメタデータを格納し検索することができるインデックスサーバとそれを動作させる方法が必要となる。
本発明は、上記の課題を解決するインデックスサーバとその方法を提供することを目的とする。
本発明の好ましい形態による、ピアツーピア・ネットワークのインデックスサーバは、データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットと、メタデータ記憶ユニットを監視して情報項目の数がしきい値を越える、メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットとを備える。
本発明のこの好ましい形態による、データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットを含む、ピアツーピア・ネットワークのインデックスサーバによる方法は、情報項目の数がしきい値を越える、メタデータ記憶ユニット内に格納されたエントリを識別するために、メタデータ記憶ユニットを監視するステップと、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するステップとを含む。
本発明によれば、効率的な方法でP2Pネットワークのメタデータを格納し検索することができるインデックスサーバを提供することができる。
本発明の上記および他の特徴、並びに効果は、図面を参照して説明された下記の好適な実施例からさらに明らかになるであろう。添付図面において、同一の又は類似する参照符号は、同一又は類似する構成要素を示している。
本発明の第1の実施の形態によるインデックスサーバを示すブロック図である。
第1の実施の形態のインデックスサーバのノード情報管理ユニットの動作を示すフローチャートである。
第1の実施の形態によるインデックスサーバのメッセージ処理ユニット、ノード情報検索ユニット、および他の構成要素の動作を示すフローチャートである。
第1の実施の形態のインデックスサーバのノード情報検索ユニットによる動作の詳細を説明するフローチャートである。
本発明の第2の実施の形態によるインデックスサーバを示すブロック図である。
第2の実施の形態によるインデックスサーバのメッセージ処理ユニット、ノード情報検索ユニット、DHT探索ユニット、および他の構成要素の動作を示すフローチャートである。
本発明の第3の実施の形態によるインデックスサーバを示すブロック図である。
第3の実施の形態によるインデックスサーバのメッセージ処理ユニットと他の構成要素の動作を示すフローチャートである。
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
図1は、本発明の第1の実施の形態によるインデックスサーバ100を示すブロック図である。図2は、第1の実施の形態のインデックスサーバ100のノード情報管理ユニット102の動作を示すフローチャートである。図3は、第1の実施の形態によるインデックスサーバ100のメッセージ処理ユニット104、ノード情報検索ユニット105及び他の構成要素の動作を示すフローチャートである。図4は、第1の実施の形態のインデックスサーバ100のノード情報検索ユニット105の動作をさらに詳細に説明するフローチャートである。以下、インデックスサーバ100の構成と動作について、図1〜図4と関連して説明する。
インデックスサーバ100は、メタデータ記憶ユニット101、ノード情報管理ユニット102、転送ログ記憶ユニット103、メッセージ処理ユニット104およびノード情報検索ユニット105を含んでいる。
メタデータ記憶ユニット101は、P2Pネットワークについてのメタデータを格納する。特に、インデックスサーバ100は、P2Pネットワークにおいて共有される1以上のデータファイルと関連付するメタデータを格納するために配置される。当業者であれば、データファイルと関連するメタデータを格納するためのインデックスサーバを配置する種々の方法を十分に理解するであろう。その1つは、上記背景技術と次に述べる第2の実施の形態において説明するように、DHTネットワークにおけるようにデータファイルのIDに基づいてデータファイルを格納するためのインデックスサーバを決定することである。しかし、本発明は、特定のデータファイルのメタデータを格納するためのインデックスサーバを割り当て、指定し、決定する何れの特定の方法にも限定されない。
より具体的には、メタデータ記憶ユニット101は、1以上のメタデータ・エントリを格納する。各メタデータ・エントリは、1以上のデータファイル内の異なるデータファイルの1つと関連している。各エントリは、1以上のノード情報項目を含んでいる。各ノード情報項目は、関連するデータファイルを提供することが知られているノードとそのノードの位置を示している。
例えば、メタデータ記憶ユニット101に格納されるエントリは、以下ようなの形式をとる。
data_id: node_id1(ip1, port1, location1), node_id2(ip2, port2, location2), …,
ここで、data_idは、エントリと関連するデータファイルの識別子(ID)である。node_id1(ip1、port1、location1)は、データファイルを提供するノードを示すノード情報項目である。ノードのIDがnode_id1である場合、ノードのアドレスは(ip1、port1)であり、ノードの位置はlocation1である。
上述のように、ノードの位置は、(ISP,Region)として定義される。
例えば、メタデータ記憶ユニット101に格納されるエントリは、以下ようなの形式をとる。
data_id: node_id1(ip1, port1, location1), node_id2(ip2, port2, location2), …,
ここで、data_idは、エントリと関連するデータファイルの識別子(ID)である。node_id1(ip1、port1、location1)は、データファイルを提供するノードを示すノード情報項目である。ノードのIDがnode_id1である場合、ノードのアドレスは(ip1、port1)であり、ノードの位置はlocation1である。
上述のように、ノードの位置は、(ISP,Region)として定義される。
当業者であれば、データファイルのメタデータがファイルの他の属性についての情報(例えば、ファイルのサイズ)を含むことを十分に理解するであろう。これらの属性については、説明を分かり易くするためにここでは省略する。
ノード情報管理ユニット102は、ノード情報項目の数がしきい値を越えるエントリがメタデータ記憶ユニットに格納されているかどうかを判定するためにメタデータ記憶ユニット10を監視し、肯定的な判定に応じて、ノード情報項目の一部分を他のサーバに転送する。この転送される一部分は、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含んでいる。
図2において、ノード情報管理ユニット102の動作を詳細に説明する。図2に示すように、ステップS101において、ノード情報管理ユニット102は、常時あるいは周期的に、メタデータ記憶ユニット101を監視し、ノード情報項目の数がしきい値を越えるエントリがメタデータ記憶ユニットに格納されているかどうかを判定する。言い換えれば、メタデータの記憶をインデックスサーバ100に割り当てているデータファイルを提供するサーバの数が閾値を越えているかどうかを判定する。
判定の結果が否定的ならば、処理はステップS101に戻り、ノード情報管理ユニット102がメタデータ記憶ユニット101の監視を継続する。そうでなければ、処理はステップS103に進む。
例えば、データファイルD1と関連するメタデータ・エントリを格納するために、インデックスサーバ100が割り当てられると仮定する。データファイルD1を提供することが可能なP2Pネットワーク内のノードの数が次第に多くなると、メタデータ記憶ユニット101に格納されたデータファイルD1に関連するエントリのノード情報項目の数が、しきい値(例えば、TH1)を超える。
この場合、ステップS103において、ノード情報管理ユニット102は、転送処理を開始する。この処理において、ノード情報項目の数が多くなりすぎたエントリのノード情報項目の一部分あるいは全てが、他の負荷の小さなサーバに転送される。
この転送される一部分は、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含んでいる。
この転送される一部分は、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含んでいる。
例えば、ノード情報管理ユニット102は、各グループが異なるISP内のノードを示すノード情報項目を含むように、エントリに含まれるノード情報項目を、ISPに基づいて1以上のグループに分割する。
次いで、ノード情報管理ユニット102は、それぞれのグループ内のノード情報項目の数を確定し、1以上のグループ中でノード情報項目の数が最大のグループ(以下、最大グループと称する)を識別する。
その後、ノード情報管理ユニット102は、最大グループ内のノード情報項目の数がしきい値(例えば、しきい値TH1)より大きいかどうかを判定する。
判定結果が否定的ならば、ノード情報管理ユニット102は、そのグループのノード情報項目をインデックスサーバ100から負荷が小さいと判定される他のインデックスサーバ(言いかえれば、現時点で、余り多くのノード情報を格納していない他のインデックスサーバ)へ転送する。
当業者であれば、そのような負荷の小さなサーバを判定するのに様々な方法があることを理解するであろう。本発明はどのような特定な方法にも限定されない。
簡単でかつ効果的な方法の例として、インデックスサーバ100が、インデックスサーバ100と同一のP2Pネットワーク上で動作するインデックスサーバのリストから2つの他のインデックスサーバをランダムに選択し、負荷のより小さい方をノード情報転送の宛先として選択する方法がある。
次いで、ノード情報管理ユニット102は、それぞれのグループ内のノード情報項目の数を確定し、1以上のグループ中でノード情報項目の数が最大のグループ(以下、最大グループと称する)を識別する。
その後、ノード情報管理ユニット102は、最大グループ内のノード情報項目の数がしきい値(例えば、しきい値TH1)より大きいかどうかを判定する。
判定結果が否定的ならば、ノード情報管理ユニット102は、そのグループのノード情報項目をインデックスサーバ100から負荷が小さいと判定される他のインデックスサーバ(言いかえれば、現時点で、余り多くのノード情報を格納していない他のインデックスサーバ)へ転送する。
当業者であれば、そのような負荷の小さなサーバを判定するのに様々な方法があることを理解するであろう。本発明はどのような特定な方法にも限定されない。
簡単でかつ効果的な方法の例として、インデックスサーバ100が、インデックスサーバ100と同一のP2Pネットワーク上で動作するインデックスサーバのリストから2つの他のインデックスサーバをランダムに選択し、負荷のより小さい方をノード情報転送の宛先として選択する方法がある。
他方、最大グループ内のノード情報項目の数がしきい値より大きければ、ノード情報管理ユニット102は、さらに、最大グループに含まれるノード情報項目を、エリアに応じて1以上のサブグループに分割する(各サブグループが異なるエリアのノードを示すノード情報項目を含むように)。
その後、ノード情報管理ユニット102は、1以上のサブグループのうちノード情報項目の数が最大のサブグループを負荷の小さいサーバに転送する。
さらに、ノード情報管理ユニット102は、1以上の他の負荷の小さなサーバに他のサブグループを転送する。
その後、ノード情報管理ユニット102は、1以上のサブグループのうちノード情報項目の数が最大のサブグループを負荷の小さいサーバに転送する。
さらに、ノード情報管理ユニット102は、1以上の他の負荷の小さなサーバに他のサブグループを転送する。
最大のグループ内のノード情報項目が1以上の他のインデックスサーバに転送された後、エントリ中の残りのノード情報項目の数が、しきい値よりまだ大きければ、ノード情報管理ユニット102は、エントリ内の残りのノード情報項目の数がしきい値より小さくなるまで、残りのノード情報項目について上記の処理を繰り返す。
ノード情報管理ユニット102は、ノード情報項目の数がしきい値を越える、メタデータ記憶ユニット101内の他のエントリについて上記の処理を繰り返す。
図1へ戻ると、そこに示されるように、インデックスサーバ100は、さらに、転送ログ記憶ユニット103を備えている。この転送ログ記憶ユニット103は、転送ログのテーブルを格納する。
これにより、ステップS103においてエントリのノード情報項目の一部分あるいは全てを他のサーバに転送する時、ステップS104において、ノード情報管理ユニット102は、転送ログ記憶ユニット103を更新する。
これにより、ステップS103においてエントリのノード情報項目の一部分あるいは全てを他のサーバに転送する時、ステップS104において、ノード情報管理ユニット102は、転送ログ記憶ユニット103を更新する。
特に、ノード情報管理ユニット102は、転送ログが、転送された一部分と関連するデータファイル、その一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲(例えば、(ISP,Region))を反映するように、転送ログ記憶ユニット103内の転送ログを生成し又は更新する。
テーブル1は、データファイルD1を提供し、(ISP1、R1)に位置する20個のノードに関する情報がインデックスサーバIS−Iに転送されていること、データファイルD1を提供し、(ISP1、R2)に位置する10個のノードに関する情報がインデックスサーバIS−IIに転送されていること、データファイルD1を提供し、(ISP2、R1)に位置する5個のノードに関する情報がインデックスサーバIS−IIIに転送されていること、データファイルD1を提供し、ISP3に位置する15個のノードに関する情報がインデックスサーバIS−IVに転送されていることを示している。
テーブル内の「MR」は、インデックスサーバIS−IVに転送された情報が、ISP3と1以上のエリアにあるノードと関連していることを示している。
テーブル内の「MR」は、インデックスサーバIS−IVに転送された情報が、ISP3と1以上のエリアにあるノードと関連していることを示している。
加えて、いくつかのノード情報項目が別のサーバに転送された後、転送されたノード情報項目と関連するデータファイルを提供し、その位置が転送されたノード情報項目によって示されるノードに接近しているノードを示すノード情報項目が将来的に受信されると、ノード情報管理ユニット102は、受信したノード情報項目をさらに別のサーバに転送し、それにより転送ログテーブルを更新する。
例えば、将来、インデックスサーバ100が、(ISP1、R1)にあるノードがデータファイルD1を提供することができることを示す情報(そのノードによって報告される)を受信すると、その情報は、インデックスサーバIS−Iに転送され、そこに格納される。そして、例えば、テーブル1の第1行の数「20」が「21」に更新される。
例えば、将来、インデックスサーバ100が、(ISP1、R1)にあるノードがデータファイルD1を提供することができることを示す情報(そのノードによって報告される)を受信すると、その情報は、インデックスサーバIS−Iに転送され、そこに格納される。そして、例えば、テーブル1の第1行の数「20」が「21」に更新される。
更に、インデックスサーバ100から転送されたノード情報を受信するインデックスサーバも、インデックスサーバ100と同様、自身のメタデータ記憶ユニットを監視し転送処理を開始する。
上記の例を続けると、インデックスサーバ100から転送されたノード情報を受信した後、インデックスサーバIS−Iは、それらをデータファイルD1と関連するエントリとして自身のメタデータ記憶ユニットに格納する。
次いで、インデックスサーバIS−Iは、常時あるいは周期的に自身のメタデータ記憶ユニットを監視する。そして、インデックスサーバIS−Iは、自身のメタデータ記憶ユニットに格納される、D1と関連するエントリと、そのノード情報の格納がインデックスサーバIS−Iに割り当てられているデータファイルと関連するエントリを含むエントリのうち、何れのエントリが非常に多くのノード情報項目を含んでいるかどうかを判定し、そのエントリ内のノード情報項目の負荷の小さなサーバへの転送を開始し、続いて自身の転送ログテーブルを更新する。
上記の例を続けると、インデックスサーバ100から転送されたノード情報を受信した後、インデックスサーバIS−Iは、それらをデータファイルD1と関連するエントリとして自身のメタデータ記憶ユニットに格納する。
次いで、インデックスサーバIS−Iは、常時あるいは周期的に自身のメタデータ記憶ユニットを監視する。そして、インデックスサーバIS−Iは、自身のメタデータ記憶ユニットに格納される、D1と関連するエントリと、そのノード情報の格納がインデックスサーバIS−Iに割り当てられているデータファイルと関連するエントリを含むエントリのうち、何れのエントリが非常に多くのノード情報項目を含んでいるかどうかを判定し、そのエントリ内のノード情報項目の負荷の小さなサーバへの転送を開始し、続いて自身の転送ログテーブルを更新する。
図1へ戻ると、インデックスサーバ100は、さらにメッセージ処理ユニット104を含んでいる。メッセージ処理ユニット104は、インデックスサーバ100の外部の装置から受信し、或いは外部の装置に送信するメッセージを処理する。例えば、受信したメッセージは、ノード情報に対する外部装置からの要求である可能性がある。この場合、メッセージ処理ユニット104は、要求を調べ、受信した要求のタイプを決定する。また、メッセージ処理ユニット104は、インデックスサーバ100の他の構成要素に、受信したメッセージのタイプに基づいて対応した動作を実行させる。メッセージ処理ユニット104は、さらに、インデックスサーバ100の他の構成要素によって指示される通りメッセージを作成し外部装置に送信する。この場合におけるメッセージ処理ユニット104と他の構成要素の動作について、図3を参照して以下に詳細に説明する。
図3に示すように、ステップS201において、メッセージ処理ユニット104は、外部装置から要求を受信するのを待ち、ステップS202において、メッセージ処理ユニット104は、要求を受信したかどうかを判定する。受信していなければ、ステップS201に戻り、受信していれば、ステップS203において、メッセージ処理ユニット104は、要求のタイプを決定する処理を行う。
具体的には、外部装置は、P2Pネットワーク内の、以下のようなノード(要求側ノード)である。P2Pネットワークにおいて他のノード(要求側ノードのピア)からデータファイルをダウンロードすることを希望し、どのノードがそのデータファイルを提供可能であるかを知る必要のあるノード。
外部装置が要求ノードである場合、その要求は、指定されたデータファイルを提供するノードの数Tに関する情報を対象として要求側ノードによってなされ、要求側ノードから直接的にあるいは他の中間の装置を介して間接的にインデックスサーバ100によって受信されるノード情報要求である。
以下、図3に示すように、そのようなノード情報要求を「タイプ1のノード情報要求」と称する。
以下、図3に示すように、そのようなノード情報要求を「タイプ1のノード情報要求」と称する。
あるいは、外部装置が、別のサーバが先の監視と転送処理期間中に、インデックスサーバ100について説明したと同様の方法でデータファイルに関連するノード情報項目の一部分をインデックスサーバ100に転送した後、そこで実行されるノード情報検索の処理中に、インデックスサーバ100からのデータファイルに関連するノード情報を取得することを決定する他のインデックスサーバである場合がある。他のインデックスサーバを要求側サーバと呼ばれる。この場合、要求側サーバから受信した要求は、例えば、指定されたデータファイルを提供するN個のノードに関する情報についてなされたノード情報要求である。
以下、図3に示すように、そのノード情報要求を「タイプ2のノード情報要求」と称する。
以下、図3に示すように、そのノード情報要求を「タイプ2のノード情報要求」と称する。
ステップS203において、受信した要求がタイプ1のノード情報要求であると決定されると、メッセージ処理ユニット104は、ステップS204において、ノード情報検索ユニット105に要求されたノード情報の検索と取得を実行させ、ステップS205において、取得したノード情報を要求側ノードに返す。
一方、ステップS203において、受信した要求がタイプ2のノード情報要求であると決定されると、メッセージ処理ユニット104は、ステップS206において、ノード情報検索ユニット105に要求されたノード情報の検索と取得を実行させ、ステップS207において、獲得したノード情報を要求側サーバに返す。
上記したような2つのタイプの要求以外に、メッセージ処理ユニット104は、もちろん、他のメッセージ、信号、データ、情報等を処理することが可能であることに留意すべきである。例えば、外部装置は、インデックスサーバ100に対してノード情報を転送することを決定する転送元サーバとなり得る。そして、この場合、受信されるメッセージは、転送元サーバによってノード情報の転送が開始されることを示す、転送すべきノード情報項目と一緒或いは別個のメッセージである。この場合、メッセージ処理ユニット104は、メタデータ記憶ユニット101に、転送元サーバから転送されたノード情報項目を関連データファイルと関連して格納させる。
図1に示すように、インデックスサーバ100はさらにノード情報検索ユニット105を備えている。
ノード情報検索ユニット105は、要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニット101と指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも1つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、メタデータ記憶ユニット101と転送ログ記憶ユニット103におけるノード情報検索を実行する。
以下、ノード情報検索ユニット105の動作について、図4に示すフローチャートを参照して詳細に説明する。
ノード情報検索ユニット105は、要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニット101と指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも1つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、メタデータ記憶ユニット101と転送ログ記憶ユニット103におけるノード情報検索を実行する。
以下、ノード情報検索ユニット105の動作について、図4に示すフローチャートを参照して詳細に説明する。
要求が、ISP1によって提供されエリアR1に位置する要求側ノードがデータファイルD1を取得することが可能なT個のノードを示す情報についての要求であると仮定する。
ノード情報検索ユニット105はそのような要求に従ってノード情報検索処理を実行する。
ノード情報検索ユニット105はそのような要求に従ってノード情報検索処理を実行する。
ステップS301から処理が開始する。ノード情報検索ユニット105は、D1を提供可能でISP1とR1に位置するノードを示す、できるだけ多くの(ただし、Tより多くない)ノード情報項目を検索しセット1として取得する。
例えば、ノード情報検索ユニット105は、まず、D1と(ISP1、R1)に関連する転送ログが存在するかどうかを判定するために、転送ログ記憶ユニット103に格納された転送ログテーブルを検索する。
転送ログが存在すれば、ノード情報検索ユニット105は、そのログにおいて示される転送されたノード情報項目の数が、Tより大きいか或いは等しいかを判定する。
ノード情報項目の数がTより大きいか或いは等しければ、ノード情報検索ユニット105は、D1を提供し、(ISP1、R1)に位置するT個のノードを要求するタイプ2のノード情報要求を、ログにおいて示されるインデックスサーバ(例えば、IS−I)に送信するようメッセージ処理ユニット104に指示する。
インデックスサーバIS−Iからのノード情報応答を受信した後、ノード情報検索ユニット105は、応答に含まれるノード情報項目をセット1として用いる。
しかし、ログに示される数がTより小さければ、同様の方法でインデックスサーバIS−Iから指示された数のノード情報項目を取得した後、ノード情報検索ユニット105は、自身のメタデータ記憶ユニット101から必要なノード情報項目を見つけ出そうと試みる。
しかしながら、上述したように、(ISP1、R1)におけるD1提供ノードに関する情報の最初の転送が実行された後に受信されたD1を提供し(ISP1、R1)に位置するノードに関する全ての情報もインデックスサーバIS−Iに転送されていれば、その後、ノード情報検索ユニット105が、自身のメタデータ記憶ユニット101において(ISP、R1)に位置するD1提供ノードに関する必要なノード情報項目を見つけ出す確率は非常に低くなる。
一実施例において、ノード情報検索ユニット105は、この場合、時間を節約するために自身のメタデータ記憶ユニット101を検索するのをスキップすることが可能である。
例えば、ノード情報検索ユニット105は、まず、D1と(ISP1、R1)に関連する転送ログが存在するかどうかを判定するために、転送ログ記憶ユニット103に格納された転送ログテーブルを検索する。
転送ログが存在すれば、ノード情報検索ユニット105は、そのログにおいて示される転送されたノード情報項目の数が、Tより大きいか或いは等しいかを判定する。
ノード情報項目の数がTより大きいか或いは等しければ、ノード情報検索ユニット105は、D1を提供し、(ISP1、R1)に位置するT個のノードを要求するタイプ2のノード情報要求を、ログにおいて示されるインデックスサーバ(例えば、IS−I)に送信するようメッセージ処理ユニット104に指示する。
インデックスサーバIS−Iからのノード情報応答を受信した後、ノード情報検索ユニット105は、応答に含まれるノード情報項目をセット1として用いる。
しかし、ログに示される数がTより小さければ、同様の方法でインデックスサーバIS−Iから指示された数のノード情報項目を取得した後、ノード情報検索ユニット105は、自身のメタデータ記憶ユニット101から必要なノード情報項目を見つけ出そうと試みる。
しかしながら、上述したように、(ISP1、R1)におけるD1提供ノードに関する情報の最初の転送が実行された後に受信されたD1を提供し(ISP1、R1)に位置するノードに関する全ての情報もインデックスサーバIS−Iに転送されていれば、その後、ノード情報検索ユニット105が、自身のメタデータ記憶ユニット101において(ISP、R1)に位置するD1提供ノードに関する必要なノード情報項目を見つけ出す確率は非常に低くなる。
一実施例において、ノード情報検索ユニット105は、この場合、時間を節約するために自身のメタデータ記憶ユニット101を検索するのをスキップすることが可能である。
しかしながら、(ISP1、R1)に位置するD1提供ノードに関する情報が他のサーバに転送されていないことを転送ログテーブルが示せば、ノード情報検索ユニット105は、自身のメタデータ記憶ユニット101を検索し、セット1として用いるできるだけ多くの(ただし、Tより多くない)ノード情報項目を見つけ出す。
ステップS302において、ノード情報検索ユニット105は、セット1に含まれるノード情報項目の数(以降、|Set1|と表し、これを他の集合にも適用する)がTより大きいか或いは等しいかを判定する。
数がTより大きいか或いは等しい場合、ステップS303において、ノード情報検索ユニット105は、要求側ノード(タイプ1のノード情報要求の場合)あるいは要求側サーバ(タイプ2のノード情報要求の場合)に対してノード情報応答としてセット1を返却するようにメッセージ処理ユニット104に指示する。
数がTより大きいか或いは等しい場合、ステップS303において、ノード情報検索ユニット105は、要求側ノード(タイプ1のノード情報要求の場合)あるいは要求側サーバ(タイプ2のノード情報要求の場合)に対してノード情報応答としてセット1を返却するようにメッセージ処理ユニット104に指示する。
他方、|Set1|がTより小さければ、検索処理はステップS304へ進む。
そこで、ノード情報検索ユニット105は、ステップS301におけると同様の方法で、D1を提供可能でISP1に位置するがR1に位置しないノードを示すできるだけ多くの(ただし、(T − |Set 1|)より多くない)ノード情報項目を、セット2として検索し取得する。
ステップS305において、ノード情報検索ユニット105は、(|Set1|+|Set2|)の和がTより大きいか或いは等しいかを判定する。
そうであれば、ステップS306において、ノード情報検索ユニット105は、セット1とセット2の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返却するようにメッセージ処理ユニット104に指示する。
そこで、ノード情報検索ユニット105は、ステップS301におけると同様の方法で、D1を提供可能でISP1に位置するがR1に位置しないノードを示すできるだけ多くの(ただし、(T − |Set 1|)より多くない)ノード情報項目を、セット2として検索し取得する。
ステップS305において、ノード情報検索ユニット105は、(|Set1|+|Set2|)の和がTより大きいか或いは等しいかを判定する。
そうであれば、ステップS306において、ノード情報検索ユニット105は、セット1とセット2の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返却するようにメッセージ処理ユニット104に指示する。
和がTより小さければ、検索処理はステップS307へ進む。そこで、ノード情報検索ユニット105は、ステップS301におけると同様の方法で、D1を提供可能でISP1に位置しないがR1に位置するノードを示すできるだけ多くの(ただし、(T−|Set1|−|Set2|)より多くない)ノード情報項目を、セット3として検索し取得する。
ステップS308において、ノード情報検索ユニット105は、(|Set1|+|Set2|+|Set 3|)の和がTより大きいか或いは等しいかを判定する。
そうであれば、ステップS309において、ノード情報検索ユニット105は、セット1とセット2とセット3の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返すようにメッセージ処理ユニット104に指示する。
ステップS308において、ノード情報検索ユニット105は、(|Set1|+|Set2|+|Set 3|)の和がTより大きいか或いは等しいかを判定する。
そうであれば、ステップS309において、ノード情報検索ユニット105は、セット1とセット2とセット3の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返すようにメッセージ処理ユニット104に指示する。
そうでなければ、検索処理はステップS310へ進む。そこで、ノード情報検索ユニット105は、D1を提供可能でISP1に位置せずかつR1にも位置しないノードを示すできるだけ多くの(ただし、(T−|Set1|−|Set2|−|Set3|)より多くない)ノード情報項目を、セット4として検索し取得する。
このステップにおいて、ノード情報検索ユニット105は、転送ログテーブルを検索し、他のサーバからノード情報項目を取得する必要がなく、単に自身のメタデータ記憶ユニット101からD1に関連する(T−|Set1|−|Set2|−|Set3|)個のノード情報項目の数をランダムに検索することが可能であることに留意すべきである。
最後に、ステップS311において、ノード情報検索ユニット105は、セット1とセット2とセット3及びセット4の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返却するようにメッセージ処理ユニット104に指示する。
このステップにおいて、ノード情報検索ユニット105は、転送ログテーブルを検索し、他のサーバからノード情報項目を取得する必要がなく、単に自身のメタデータ記憶ユニット101からD1に関連する(T−|Set1|−|Set2|−|Set3|)個のノード情報項目の数をランダムに検索することが可能であることに留意すべきである。
最後に、ステップS311において、ノード情報検索ユニット105は、セット1とセット2とセット3及びセット4の和集合を、要求側ノードあるいは要求側サーバに対してノード情報応答として返却するようにメッセージ処理ユニット104に指示する。
図5は、本発明の第2の実施の形態によるインデックスサーバ100Aを示すブロック図である。
図6は、第2の実施の形態によるインデックスサーバ100Aのメッセージ処理ユニット104A、ノード情報検索ユニット105、DHT探索ユニット106、および他の構成要素の動作を示すフローチャートである。第1の実施の形態と同一或いは類似の要素は、同一或いは類似の参照符号を付して表わし、その詳細な説明は省略する。
図6は、第2の実施の形態によるインデックスサーバ100Aのメッセージ処理ユニット104A、ノード情報検索ユニット105、DHT探索ユニット106、および他の構成要素の動作を示すフローチャートである。第1の実施の形態と同一或いは類似の要素は、同一或いは類似の参照符号を付して表わし、その詳細な説明は省略する。
図5に示すように、インデックスサーバ100Aは、メタデータ記憶ユニット101と、ノード情報管理ユニット102と、転送ログ記憶ユニット103と、メッセージ処理ユニット104Aと、転送ログ記憶ユニット103およびDHT探索ユニット106を備えている。
第2の実施の形態は、分散ハッシュテーブル(Distributed Hash Table:DHT)ネットワークにおける本発明の適用を示している。本実施の形態において、インデックスサーバ100Aは、DHTネットワーク内にある。
この場合、インデックスサーバ100Aが受信することができるノード情報要求は、上記説明したようなタイプ1のノード情報要求とタイプ2のノード情報要求を含んでいる。
タイプ1のノード情報要求は、要求側ノードから直接送信された要求(インデックスサーバ100Aが要求側ノードのホームインデックスサーバ(home indexing server)である場合)、あるいは要求側ノードによって発行され、DHTネットワーク内の他のインデックスサーバを経由してインデックスサーバ100Aに到着した要求である。
タイプ1のノード情報要求は、インデックスサーバ100Aを目的インデックスサーバとして明示的に指定しない。そのような要求を受信すると、DHT探索ユニット106はDHT探索(DHT lookup)を実行し、それに応じてインデックスサーバ100Aが動作する。
第1の実施の形態と同様、第2の実施の形態におけるタイプ2のノード情報要求は、他のサーバがノード情報検索を実行しており、インデックスサーバ100Aから必要なノード情報を取得可能であることを見つけ出した場合に、その他のサーバから送信されたノード情報要求である。タイプ2のノード情報要求は、インデックスサーバ100Aを目的インデックスサーバとして明示的に指定する。
そのような要求を受信すると、ノード情報検索ユニット105は直接ノード情報検索を実行し、インデックスサーバ100Aがそれに応じて動作する。
この場合、インデックスサーバ100Aが受信することができるノード情報要求は、上記説明したようなタイプ1のノード情報要求とタイプ2のノード情報要求を含んでいる。
タイプ1のノード情報要求は、要求側ノードから直接送信された要求(インデックスサーバ100Aが要求側ノードのホームインデックスサーバ(home indexing server)である場合)、あるいは要求側ノードによって発行され、DHTネットワーク内の他のインデックスサーバを経由してインデックスサーバ100Aに到着した要求である。
タイプ1のノード情報要求は、インデックスサーバ100Aを目的インデックスサーバとして明示的に指定しない。そのような要求を受信すると、DHT探索ユニット106はDHT探索(DHT lookup)を実行し、それに応じてインデックスサーバ100Aが動作する。
第1の実施の形態と同様、第2の実施の形態におけるタイプ2のノード情報要求は、他のサーバがノード情報検索を実行しており、インデックスサーバ100Aから必要なノード情報を取得可能であることを見つけ出した場合に、その他のサーバから送信されたノード情報要求である。タイプ2のノード情報要求は、インデックスサーバ100Aを目的インデックスサーバとして明示的に指定する。
そのような要求を受信すると、ノード情報検索ユニット105は直接ノード情報検索を実行し、インデックスサーバ100Aがそれに応じて動作する。
インデックスサーバ100Aの動作について図6を参照して説明する。
ステップS201、S202において要求を受信すると、メッセージ処理ユニット104Aは、ステップS203Aにおいて、要求のタイプを判定する。
要求がタイプ1のノード情報要求であれば、処理はステップS208へ進むみ、そこで、DHT探索ユニット106は、インデックスサーバ100Aによって保持されるローカルのフィンガーテーブル(Finger Table)(図示しない)を用いることにより、DHT探索を実行する。ステップS209において、DHT探索ユニット106は、ローカルのフィンガーテーブル(Finger Table)上の探索がヒットしたかどうかを判定する。
ヒットしていれば、処理はステップS204へ進み、そこで、ノード情報検索ユニット105に要求に従ってノード情報の検索と取得を実行させ、その後、ステップS205において、取得したノード情報は、要求側ノードに応答として送信される。
インデックスサーバ100Aが要求側ノードのホームインデックスサーバでなければ、インデックスサーバ100Aは、ホームインデックスサーバを介して取得したノード情報を要求側ノードに送信することに留意されたい。
要求がタイプ1のノード情報要求であれば、処理はステップS208へ進むみ、そこで、DHT探索ユニット106は、インデックスサーバ100Aによって保持されるローカルのフィンガーテーブル(Finger Table)(図示しない)を用いることにより、DHT探索を実行する。ステップS209において、DHT探索ユニット106は、ローカルのフィンガーテーブル(Finger Table)上の探索がヒットしたかどうかを判定する。
ヒットしていれば、処理はステップS204へ進み、そこで、ノード情報検索ユニット105に要求に従ってノード情報の検索と取得を実行させ、その後、ステップS205において、取得したノード情報は、要求側ノードに応答として送信される。
インデックスサーバ100Aが要求側ノードのホームインデックスサーバでなければ、インデックスサーバ100Aは、ホームインデックスサーバを介して取得したノード情報を要求側ノードに送信することに留意されたい。
他方、ステップS209においてヒットしなければ、処理はステップS210へ進み、そこで、DHT探索ユニット106は、フィンガーテーブル(Finger Table)によって示される次のホップサーバ(hop server)のもとにノード情報要求を送信するようメッセージ処理ユニット104Aに指示する。
ステップS203Aにおいて要求がタイプ2のノード情報要求と判定されると、処理はステップS206に進み、そこで、ノード情報検索ユニット105は、要求に従ってノード情報を検索し取得し、その後、ステップS207において、取得したノード情報が、要求側サーバのもとに応答として送信される。
図7は、本発明の第3の実施の形態によるインデックスサーバ100Bを示すブロック図である。図8は、第3の実施の形態に従ってインデックスサーバ100Bのメッセージ処理ユニット104Bと他の構成要素の動作を示すフローチャートである。第2の実施の形態と同一或いは類似の要素は、同一或いは類似の参照符号を付して表わし、その詳細な説明は省略する。
図7に示すように、第3の実施の形態は、要求側ノードに対して修正を加えている。
第2の実施の形態において、要求側ノードによって発行されたデータファイルに関連する要求は、ホームインデックスサーバにまず送信され、それが目的インデックスサーバに到着するまで、すなわち、フィンガーテーブルにおいてヒットすることを見出すサーバに到着するまで、DHTネットワーク内を経由する。
データファイルと関連する後続の要求を直接目的インデックスサーバに送信することができれば、応答の遅延はより一層減少する。
要求側ノードによって送信され、目的インデックスサーバを明示的に指定するそのような後続の要求を、ここで、タイプ3のノード情報要求と称する。
第2の実施の形態において、要求側ノードによって発行されたデータファイルに関連する要求は、ホームインデックスサーバにまず送信され、それが目的インデックスサーバに到着するまで、すなわち、フィンガーテーブルにおいてヒットすることを見出すサーバに到着するまで、DHTネットワーク内を経由する。
データファイルと関連する後続の要求を直接目的インデックスサーバに送信することができれば、応答の遅延はより一層減少する。
要求側ノードによって送信され、目的インデックスサーバを明示的に指定するそのような後続の要求を、ここで、タイプ3のノード情報要求と称する。
この目的のために、図7に示す要求側ノード200は、ノード情報要求ユニット201と、探索ユニット202およびキャッシュユニット203を備えている。
特定のデータファイルに関連しかつそのデータファイルに対する目的インデックスサーバを示すノード情報応答を受信した後、そのデータファイルと目的インデックスサーバの間の関連付けが、キャッシュユニット203内に格納される。
その後、ノード情報要求ユニット201がそのデータファイルに関連する別のノード情報要求を送信しようとする時、探索ユニット202は、キャッシュユニット203内を調べ、そのデータファイルに関連付けられている目的インデックスサーバを決定する。
その後、ノード情報要求ユニット201は、その目的インデックスサーバに対してタイプ3のノード情報要求を直接送信する。
特定のデータファイルに関連しかつそのデータファイルに対する目的インデックスサーバを示すノード情報応答を受信した後、そのデータファイルと目的インデックスサーバの間の関連付けが、キャッシュユニット203内に格納される。
その後、ノード情報要求ユニット201がそのデータファイルに関連する別のノード情報要求を送信しようとする時、探索ユニット202は、キャッシュユニット203内を調べ、そのデータファイルに関連付けられている目的インデックスサーバを決定する。
その後、ノード情報要求ユニット201は、その目的インデックスサーバに対してタイプ3のノード情報要求を直接送信する。
目的インデックスサーバがインデックスサーバ100Bであると仮定する。インデックスサーバ100Bは、そのメッセージ処理ユニット104Bがさらにタイプ3のノード情報要求を判別可能であるという点で、第2の実施の形態によるインデックスサーバ100Aと相違する。
具体的には、図8に示すように、要求を受信した後、メッセージ処理ユニット104Bは、ステップS203Bにおいて、そのタイプを判定する。
タイプ3のノード情報要求であれば、処理はステップS208とS209をスキップし、直接ステップS204へ進み、そこで、ノード情報検索ユニット105は、要求に従ってノード情報を検索して取得し、その後、ステップS205において、ノード情報応答が要求側ノード200に直接送信される。
タイプ3のノード情報要求であれば、処理はステップS208とS209をスキップし、直接ステップS204へ進み、そこで、ノード情報検索ユニット105は、要求に従ってノード情報を検索して取得し、その後、ステップS205において、ノード情報応答が要求側ノード200に直接送信される。
以上、本発明についてその好適な実施例を参照して説明したが、当該技術に精通した当業者には、本発明の精神と範囲から逸脱することなく他の様々な修正、変更、追加を行うことが可能なことは明らかであろう。したがって、本発明の範囲は上記の具体的な実施例に限定されず、付記した請求項によってのみ限定される。
さらに、上記実施形態の一部分又は全部は、以下の付記のようにも記載されうるが、これに限定されない。
(付記1)
ピアツーピア・ネットワークのインデックスサーバであって、
データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットと、
前記メタデータ記憶ユニットを監視して前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットと
を備えることを特徴とするインデックスサーバ。
ピアツーピア・ネットワークのインデックスサーバであって、
データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットと、
前記メタデータ記憶ユニットを監視して前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットと
を備えることを特徴とするインデックスサーバ。
(付記2)
転送ログ記憶ユニットをさらに備え、
前記ノード情報管理ユニットは、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする付記1に記載のインデックスサーバ。
転送ログ記憶ユニットをさらに備え、
前記ノード情報管理ユニットは、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする付記1に記載のインデックスサーバ。
(付記3)
他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする付記1に記載のインデックスサーバ。
他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする付記1に記載のインデックスサーバ。
(付記4)
前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割し、1以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送することにより、転送を実行することを特徴とする付記1に記載のインデックスサーバ。
前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割し、1以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送することにより、転送を実行することを特徴とする付記1に記載のインデックスサーバ。
(付記5)
前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割し、1以上のグループ中でノード情報項目の数が最大のグループを識別し、最大数が前記しきい値を越えるかどうか判定し、最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送し、最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、1以上のサブグループに分割し、1以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送することにより、転送を実行することを特徴とする付記1に記載のインデックスサーバ。
前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割し、1以上のグループ中でノード情報項目の数が最大のグループを識別し、最大数が前記しきい値を越えるかどうか判定し、最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送し、最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、1以上のサブグループに分割し、1以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送することにより、転送を実行することを特徴とする付記1に記載のインデックスサーバ。
(付記6)
第1のノード情報項目が他のサーバに転送された後、第1のノード情報項目と関連するデータファイルを提供し、その位置が第1のノード情報項目によって示されるノードに接近しているノードを示す第2のノード情報項目が受信されると、ノード情報管理ユニットが、前記第2のノード情報項目を他のサーバに転送することを特徴とする付記1に記載のインデックスサーバ。
第1のノード情報項目が他のサーバに転送された後、第1のノード情報項目と関連するデータファイルを提供し、その位置が第1のノード情報項目によって示されるノードに接近しているノードを示す第2のノード情報項目が受信されると、ノード情報管理ユニットが、前記第2のノード情報項目を他のサーバに転送することを特徴とする付記1に記載のインデックスサーバ。
(付記7)
要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも1つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するノード情報検索ユニット105をさらに備えることを特徴とする付記2に記載のインデックスサーバ。
要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも1つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するノード情報検索ユニット105をさらに備えることを特徴とする付記2に記載のインデックスサーバ。
(付記8)
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定することを特徴とする付記7に記載のインデックスサーバ。
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定することを特徴とする付記7に記載のインデックスサーバ。
(付記9)
要求に応答して、指定されたデータファイルの標識を用いてDHT探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するDHTネットワーク内で要求を経由させ、ヒットが生じれば、ノード情報検索ユニットに前記検索を実行させる分散ハッシュテーブル探索ユニットをさらに備えることを特徴とする付記7に記載のインデックスサーバ。
要求に応答して、指定されたデータファイルの標識を用いてDHT探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するDHTネットワーク内で要求を経由させ、ヒットが生じれば、ノード情報検索ユニットに前記検索を実行させる分散ハッシュテーブル探索ユニットをさらに備えることを特徴とする付記7に記載のインデックスサーバ。
(付記10)
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定しないことを特徴とする付記9に記載のインデックスサーバ。
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定しないことを特徴とする付記9に記載のインデックスサーバ。
(付記11)
データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットを含む、ピアツーピア・ネットワークのインデックスサーバによる方法であって、
前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別するために、前記メタデータ記憶ユニットを監視するステップと、
識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するステップと
を含むことを特徴とする方法。
データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットを含む、ピアツーピア・ネットワークのインデックスサーバによる方法であって、
前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別するために、前記メタデータ記憶ユニットを監視するステップと、
識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するステップと
を含むことを特徴とする方法。
(付記12)
前記インデックスサーバが転送ログ記憶ユニットをさらに含み、
前記一部分が他のサーバに転送される時、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする付記11に記載の方法。
前記インデックスサーバが転送ログ記憶ユニットをさらに含み、
前記一部分が他のサーバに転送される時、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする付記11に記載の方法。
(付記13)
他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする付記11に記載の方法。
他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする付記11に記載の方法。
(付記14)
前記転送ステップが、
各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割するステップと、
1以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送するステップを含むことを特徴とする付記11に記載の方法。
前記転送ステップが、
各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割するステップと、
1以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送するステップを含むことを特徴とする付記11に記載の方法。
(付記15)
前記転送ステップが、
各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割するステップと、
1以上のグループ中でノード情報項目の数が最大のグループを識別するステップと、
最大数が前記しきい値を越えるかどうかを判定するステップと、
最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送するステップと、
最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、1以上のサブグループに分割し、1以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送するステップを含むことを特徴とする付記11に記載の方法。
前記転送ステップが、
各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割するステップと、
1以上のグループ中でノード情報項目の数が最大のグループを識別するステップと、
最大数が前記しきい値を越えるかどうかを判定するステップと、
最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送するステップと、
最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、1以上のサブグループに分割し、1以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送するステップを含むことを特徴とする付記11に記載の方法。
(付記16)
第1のノード情報項目が他のサーバに転送された後、第1のノード情報項目と関連するデータファイルを提供し、その位置が第1のノード情報項目によって示されるノードに接近しているノードを示す第2のノード情報項目が受信されると、前記第2のノード情報項目を他のサーバに転送することを特徴とする付記11に記載の方法。
第1のノード情報項目が他のサーバに転送された後、第1のノード情報項目と関連するデータファイルを提供し、その位置が第1のノード情報項目によって示されるノードに接近しているノードを示す第2のノード情報項目が受信されると、前記第2のノード情報項目を他のサーバに転送することを特徴とする付記11に記載の方法。
(付記17)
要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも1つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するステップをさらに含むことを特徴とする付記12に記載の方法。
要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも1つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するステップをさらに含むことを特徴とする付記12に記載の方法。
(付記18)
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定することを特徴とする付記17に記載の方法。
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定することを特徴とする付記17に記載の方法。
(付記19)
要求に応答して、指定されたデータファイルの標識を用いてDHT探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するDHTネットワーク内で要求を経由させ、ヒットが生じれば、前記検索を実行するステップをさらに含むことを特徴とする付記17に記載の方法。
要求に応答して、指定されたデータファイルの標識を用いてDHT探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するDHTネットワーク内で要求を経由させ、ヒットが生じれば、前記検索を実行するステップをさらに含むことを特徴とする付記17に記載の方法。
(付記20)
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定しないことを特徴とする付記19に記載の方法。
前記要求が、目的インデックスサーバとしてのインデックスサーバを指定しないことを特徴とする付記19に記載の方法。
100:インデックスサーバ
101:メタデータ記憶ユニット
102:ノード情報管理ユニット
103:転送ログ記憶ユニット
104:メッセージ処理ユニット
105:ノード情報検索ユニット
106:DHT探索ユニット
200:要求側ノード
201:ノード情報要求ユニット
202:探索ユニット
203:キャッシュユニット
101:メタデータ記憶ユニット
102:ノード情報管理ユニット
103:転送ログ記憶ユニット
104:メッセージ処理ユニット
105:ノード情報検索ユニット
106:DHT探索ユニット
200:要求側ノード
201:ノード情報要求ユニット
202:探索ユニット
203:キャッシュユニット
Claims (10)
- ピアツーピア・ネットワークのインデックスサーバであって、
データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットと、
前記メタデータ記憶ユニットを監視して前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別し、識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するノード情報管理ユニットと
を備えることを特徴とするインデックスサーバ。 - 転送ログ記憶ユニットをさらに備え、
前記ノード情報管理ユニットは、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする請求項1に記載のインデックスサーバ。 - 他のサーバが、負荷が小さいと判定されたサーバであることを特徴とする請求項1に記載のインデックスサーバ。
- 前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割し、1以上のグループ中で最大数のノード情報項目を含むグループを、他のサーバに転送することにより、転送を実行することを特徴とする請求項1に記載のインデックスサーバ。
- 前記ノード情報管理ユニットは、各グループが異なるインターネット・サービス・プロバイダ(ISP)内のノードを示すノード情報項目を含むように、前記識別されたエントリに含まれるノード情報項目を、1以上のグループに分割し、1以上のグループ中でノード情報項目の数が最大のグループを識別し、最大数が前記しきい値を越えるかどうか判定し、最大数が前記しきい値を越えなければ、識別されたグループを他のサーバに対して転送し、最大数がしきい値より大きければ、識別したグループに含まれるノード情報項目を、各サブグループが異なるエリアのノードを示すノード情報項目を含むように、1以上のサブグループに分割し、1以上のサブグループのうちノード情報項目の数が最大のサブグループを他のサーバに転送することにより、転送を実行することを特徴とする請求項1に記載のインデックスサーバ。
- 第1のノード情報項目が他のサーバに転送された後、第1のノード情報項目と関連するデータファイルを提供し、その位置が第1のノード情報項目によって示されるノードに接近しているノードを示す第2のノード情報項目が受信されると、ノード情報管理ユニットが、前記第2のノード情報項目を他のサーバに転送することを特徴とする請求項1に記載のインデックスサーバ。
- 要求側ノードからの指定されたデータファイルを提供するノードに関する情報についての要求に従って、メタデータ記憶ユニットと指定されたデータファイルに関連するノード情報項目の一部分が転送された他のサーバの少なくとも1つから、指定されたデータファイルを提供し要求側ノードにできるだけ近接して位置するノードを示すノード情報項目を取得するために、前記メタデータ記憶ユニットと転送ログ記憶ユニットにおけるノード情報検索を実行するノード情報検索ユニット105をさらに備えることを特徴とする請求項2に記載のインデックスサーバ。
- 要求に応答して、指定されたデータファイルの標識を用いてDHT探索を実行し、インデックスサーバ上でヒットが生じるかどうかを判定し、ヒットが生じなければ、インデックスサーバが属するDHTネットワーク内で要求を経由させ、ヒットが生じれば、ノード情報検索ユニットに前記検索を実行させる分散ハッシュテーブル探索ユニットをさらに備えることを特徴とする請求項7に記載のインデックスサーバ。
- データファイルと関連するエントリであって、該データファイルを提供するサーバと該サーバの位置を示す複数の情報項目を含む1以上のエントリを格納するメタデータ記憶ユニットを含む、ピアツーピア・ネットワークのインデックスサーバによる方法であって、
前記情報項目の数がしきい値を越える、前記メタデータ記憶ユニット内に格納されたエントリを識別するために、前記メタデータ記憶ユニットを監視するステップと、
識別されたエントリ内に含まれる情報項目の一部分であって、その位置が互いに接近しているノードを示すノード情報項目を可能な限り多く含む一部分を他のサーバに転送するステップと
を含むことを特徴とする方法。 - 前記インデックスサーバが転送ログ記憶ユニットをさらに含み、
前記一部分が他のサーバに転送される時、転送ログが、転送された一部分と関連するデータファイル、該一部分が転送される他のサーバ、転送された一部分によって示されるノードの位置範囲を反映するように、前記転送ログ記憶ユニット内の転送ログを生成し又は更新することを特徴とする請求項9に記載の方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2010/000379 WO2011116502A1 (en) | 2010-03-26 | 2010-03-26 | Indexing server and method therefor |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2012514278A JP2012514278A (ja) | 2012-06-21 |
JP5177919B2 true JP5177919B2 (ja) | 2013-04-10 |
Family
ID=44672431
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012506309A Expired - Fee Related JP5177919B2 (ja) | 2010-03-26 | 2010-03-26 | インデックスサーバとその方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20110282883A1 (ja) |
JP (1) | JP5177919B2 (ja) |
CN (1) | CN102947821A (ja) |
WO (1) | WO2011116502A1 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5651093B2 (ja) * | 2011-10-28 | 2015-01-07 | 株式会社日立製作所 | 分散id管理方法および分散id管理システム |
CN103581207A (zh) * | 2012-07-18 | 2014-02-12 | 富泰华工业(深圳)有限公司 | 云端数据存储***及基于该***的数据存储与共享方法 |
US9824092B2 (en) * | 2015-06-16 | 2017-11-21 | Microsoft Technology Licensing, Llc | File storage system including tiers |
CN106844510B (zh) * | 2016-12-28 | 2021-01-15 | 北京五八信息技术有限公司 | 一种分布式数据库集群的数据迁移方法和装置 |
EP3821587A1 (en) * | 2018-07-11 | 2021-05-19 | Telefonaktiebolaget LM Ericsson (publ) | System and method for distributed indexing in peer-to-peer networks |
JP7131357B2 (ja) * | 2018-12-12 | 2022-09-06 | 富士通株式会社 | 通信装置、通信方法、および通信プログラム |
WO2022021357A1 (zh) * | 2020-07-31 | 2022-02-03 | 华为技术有限公司 | 一种文件块下载方法及装置 |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5963944A (en) * | 1996-12-30 | 1999-10-05 | Intel Corporation | System and method for distributing and indexing computerized documents using independent agents |
US7555553B2 (en) * | 2002-10-01 | 2009-06-30 | Hewlett-Packard Development Company, L.P. | Placing an object at a node in a peer-to-peer system based on storage utilization |
US7788400B2 (en) * | 2003-09-19 | 2010-08-31 | Hewlett-Packard Development Company, L.P. | Utilizing proximity information in an overlay network |
US7596618B2 (en) * | 2004-12-07 | 2009-09-29 | Hewlett-Packard Development Company, L.P. | Splitting a workload of a node |
JP2006227763A (ja) * | 2005-02-15 | 2006-08-31 | Nec Soft Ltd | データ共有システム、データ共有方法及びプログラム |
US8090813B2 (en) * | 2006-09-19 | 2012-01-03 | Solid State Networks, Inc. | Methods and apparatus for data transfer |
JP2008234563A (ja) * | 2007-03-23 | 2008-10-02 | Nec Corp | オーバレイ管理装置、オーバレイ管理システム、オーバレイ管理方法およびオーバレイ管理用プログラム |
US7827147B1 (en) * | 2007-03-30 | 2010-11-02 | Data Center Technologies | System and method for automatically redistributing metadata across managers |
CN101060534B (zh) * | 2007-06-13 | 2013-01-16 | 中兴通讯股份有限公司 | 一种p2p网络应用的***及网络侧*** |
US8238237B2 (en) * | 2007-06-18 | 2012-08-07 | Sony Computer Entertainment Inc. | Load balancing distribution of data to multiple recipients on a peer-to-peer network |
JP2009032053A (ja) * | 2007-07-27 | 2009-02-12 | Sony Corp | データ受信システム |
US8315999B2 (en) * | 2007-08-29 | 2012-11-20 | Nirvanix, Inc. | Policy-based file management for a storage delivery network |
JP5119844B2 (ja) * | 2007-10-09 | 2013-01-16 | 沖電気工業株式会社 | ファイル転送システム、ファイル転送方法、ファイル転送プログラム及びインデックスサーバ |
CN101355591A (zh) * | 2008-09-12 | 2009-01-28 | 中兴通讯股份有限公司 | 一种p2p网络及其调度方法 |
US20110153737A1 (en) * | 2009-12-17 | 2011-06-23 | Chu Thomas P | Method and apparatus for decomposing a peer-to-peer network and using a decomposed peer-to-peer network |
-
2010
- 2010-03-26 US US13/125,684 patent/US20110282883A1/en not_active Abandoned
- 2010-03-26 WO PCT/CN2010/000379 patent/WO2011116502A1/en active Application Filing
- 2010-03-26 CN CN2010800040475A patent/CN102947821A/zh active Pending
- 2010-03-26 JP JP2012506309A patent/JP5177919B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2012514278A (ja) | 2012-06-21 |
CN102947821A (zh) | 2013-02-27 |
US20110282883A1 (en) | 2011-11-17 |
WO2011116502A1 (en) | 2011-09-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5177919B2 (ja) | インデックスサーバとその方法 | |
US7565450B2 (en) | System and method for using a mapping between client addresses and addresses of caches to support content delivery | |
US7725596B2 (en) | System and method for resolving network layer anycast addresses to network layer unicast addresses | |
CN101841553B (zh) | 网络上请求资源的位置信息的方法、用户节点和服务器 | |
WO2010127618A1 (zh) | 一种实现流媒体内容服务的***和方法 | |
JP2010504668A (ja) | リソース配信の方法、システム、およびエッジサーバ | |
CN111464661B (zh) | 负载均衡方法、装置、代理设备、缓存设备及服务节点 | |
JP2013514733A (ja) | ピアツーピア・ネットワーク内でサービスを突き止める方法および装置 | |
US10530893B2 (en) | Method for managing packets in a network of information centric networking (ICN) nodes | |
CN103107944B (zh) | 一种内容定位方法和路由设备 | |
US20140222988A1 (en) | Method for adaptive content discovery for distributed shared caching system | |
JP2004199578A (ja) | コンテンツ配信方法及び装置並びにプログラム及び記録媒体 | |
Gao et al. | Distributed caching in unstructured peer-to-peer file sharing networks | |
JP4533923B2 (ja) | 階層型ピアツーピアシステムにおける負荷バランシング機能を有するスーパーピア及び該スーパーピアを動作させる方法 | |
US9003034B2 (en) | Method for operating a local area data network | |
JP4923115B2 (ja) | 自己組織型分散オーバーレイ・ネットワークにおいてオブジェクトへの参照を分散させる方法、コンピュータプログラム、及びノード、並びに自己組織型分散オーバーレイ・ネットワーク | |
KR101073659B1 (ko) | 네트워크 혼잡 감소를 위하여 파일을 투명하게 내려받기 위한 방법 | |
Dannewitz et al. | Complex queries in P2P networks with resource-constrained devices | |
Ryu et al. | An effective peer-to-peer web caching system under dynamic participation of peers | |
CN115834597A (zh) | 一种内容分发方法及客户端、电子设备、存储介质 | |
Pacitti et al. | Content Distribution in P2P Systems | |
JP2012078903A (ja) | ノード装置、ノード装置用プログラムおよび情報処理方法 | |
Hou et al. | An intelligent media delivery prototype system with low response time | |
JP2006065636A (ja) | メタデータ検索方法、利用者端末、およびメタデータ検索プログラム | |
Shen | CORP: A COoperative file Replication Protocol for structured P2P networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121220 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20121227 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130107 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |