JP4684534B2 - ピアツーピア環境においてキャッシュされた資源間における資源の相同性 - Google Patents

Description

本発明は、ネットワーキングの分野に属し、より具体的にはピアツーピアネットワーキングに関する。

本出願は、２０００年１１月２２日出願の米国仮出願第６０／２５２,６５８号「A Locator and Tracking Service for Peer-to-Peer Resources」および２０００年１１月２２日出願の米国仮出願第６０／２５２,６５９号「A Universal Naming Scheme for Peer-to-Peer Resources」の双方の出願を基礎とする優先権を主張し、これらの各々の発明は、参照により本発明に組み込まれている。

本出願は、２００１年９月１３日出願の米国出願第０９／９５２,６５２号「Locator and Tracking Service for Peer-to-Peer Resources」に関連する。

本出願は、２００１年９月１３日出願の米国出願第０９／９５２,８０８号「Universal Naming Scheme for Peer-to-Peer Resources」に関連する。

データネットワークは、「クライアントとサーバ」との対話に基づいて行われる。サーバは、種々のネットワーク資源へのアクセスを提供し、あるいはサービスする。クライアントは、そのサーバから資源へのアクセスを要求する。インターネット接続業者（ＩＳＰ）は、サーバの一例である。クライアントはＩＳＰからインターネットへのアクセスを要求し、ＩＳＰはアクセスを提供する。クライアントがＩＳＰを介してインターネットにアクセスすると、クライアントは、何百万という様々なインターネット上のサーバが提供する事実上無限の種類の更なる資源へのアクセスを要求することができる。

伝統的なクライアント−サーバ環境において、資源（ｒｅｓｏｕｒｃｅ）は、ずっと多くのクライアントからの要求（ｒｅｑｕｅｓｔ）を受け持つ比較的少数の集中化されたサーバにしばしば集約される。この伝統的な手法で数個のサーバ上に資源を集約することには問題がある。例えば、このようなサーバは、膨大な量の要求を処理することが可能な非常に高速のマシン上で動作する必要がある。一度に数千あるいは数百万にもなるクライアントによるトランザクションを扱うことができるサーバ機およびネットワーク接続は、その購入や保守が非常に高価であると思われる。

さらに、例外的に高速のネットワークであった場合、最も高速の集中化されたサーバですらネットワークのボトルネックになる可能性がある。例えば、全国的なニュースがあったようなとき、ほとんどのニュースサイトにおいて最新の情報にアクセスする総時間数は、ネットワークトラフィックが増大するため劇的に増大する傾向がある。さらに、これらの大規模な集中化された装置が何らかの原因で障害となる場合、所望の資源へのアクセスを拒絶されるクライアントは数百万にも及ぶであろう。この弱点から集中化されたサーバはハッカーやサイバーテロリストたちの格好の標的となりうるのである。

伝統的でないネットワーキングの１つの手法は、ピアツーピア対話に基づくものである。ピアツーピア環境においては、トランザクションはエンドユーザ、あるいはピア（ｐｅｅｒ）、装置の間で行われる。各ピアは、資源の消費者および提供者の双方とすることができる。すなわち、ピアは、伝統的なクライアントのように動作して、他のいずれかに格納された資源へのアクセスを要求することもでき、その同じピアが、伝統的なサーバのように動作して、そこに格納された資源への要求に応答することもできる。

ピアツーピアネットワーキングには、理論的に言って伝統的な手法を越える多くの利点がある。巨大な数のクライアントトランザクションを集中化されたサーバに流し込まずに、複数のピアが協働してサーバ全体を置き換えることが可能となる。例えば、資源が多くのピア装置上にコピーおよびキャッシュされる場合、資源への要求は、これらのピアのいずれかの１つによって提供することができ、あるいは同時にいくつかのピアによっても、その資源のため総計のダウンロード帯域を最大にするため、複数のピアの各々に一部のみ提供させることによって提供することができる。資源を複数のピアに拡散させることによって、集中化されたサーバにおけるボトルネックは、改善させることができる。また、エンドユーザピア装置は比較的低価格の傾向にあり、ほとんどのネットワーキング環境に既に存在している。ピア装置の処理能力を累積させて、および可能な帯域を用いることによって、多くの高価な集中化されたサーバを減らして、実質上ネットワークの全体のコストを削減させることができる。

ピアツーピアネットワーキング手法の更なる利点は、コンテンツの発信（ｐｕｂｌｉｓｈｉｎｇ）に衝突がないことである。ピアツーピアのシステムにおいて、すべてのピア装置が情報の消費者および発信者の双方でありうるなら、このようなシステムにおいて情報を発信することは、新しいファイルを作成するのと同じくらい容易となりうる。これによって、クライアント−サーバ環境におけるコンテンツの発信に関連する衝突は完全に（例えば、企業のインターネットポータル上で発信される際の関連するステップのように）除去され、したがって、ユーザがより多くのコンテンツを相互に共有することを促進させる。この種の共有は、通常、ユーザによって共有されることのない最新の企業にとって重要な情報を含む「情報の孤島」（例えば、ユーザのデスクトップやラップトップ）によってイントラネットが構成されるような状況において特に関連する。

残念なことに、ネットワークトラフィックおよび資源を管理するためのほとんどの伝統的手法は、ピアツーピアネットワーキングに適応させるのに適していない。例えば、サーバをワールドワイドウェブ（ＷＷＷ）上に置くことは、そのドメイン名システム（ＤＭＳ）に依存する。ＤＮＳは、インターネットホスト、あるいはサーバの名前を付けるために用いられる確立した階層的スキームである。ＤＮＳは、ホスト名を解決してインターネットプロトコル（ＩＰ）アドレスを得られるように設計される。すなわち、ＤＮＳは人間にとって意味のあるＵＲＬ、例えばｗｗｗ．ＵＳｎｅｗｓ．ｃｏｍのホスト名の部分を解決して、インターネットルータやスイッチにとって意味のあるＩＰアドレス、例えば２０５．２４５．１７２．７２．を得る。所与のホスト装置のＩＰアドレスおよび関連するホスト名は、インターネット全体を通して種々のＤＮＳサーバに知らされ、ホスト名を用いて作成されたクライアントの（例えば、その所定のホスト名を含むＵＲＬを要求するといった）要求は、正確なＩＰアドレスに正規に経路付けられる。この情報の伝播や更新は、数時間あるいは数日のオーダの比較的長い時間間隔を取る可能性がある。

ＤＮＳは、所定のホストにおいてすべてが可能なネットワーク資源をロケーティングするため、および比較的変化のないＩＰアドレスを有するホストについては、うまく機能する。

しかし、ピアは動的にアロケートされるＩＰアドレスを持つことがしばしばある。すなわち、ピアがインターネット上に記録される度に、そのピアは異なるＩＰアドレスを持つ可能性がある。例えば、企業ユーザは、静的には割り当てられない（企業およびＩＳＰの双方がホストアドレスを割り当てるために動的ホスト構成プロトコル（ＤＨＣＰ）を用いると考える）異なるＩＰアドレスを用いて、ラップトップをインターネットにオフィスまたは自宅から切り替えて接続する場合がある。ピアのログオン時間の満了が、ＤＮＳシステムを介して新たなＩＰアドレスを伝播させるのに必要な時間間隔より短いことは稀なことではない。このような場合のほとんどの時間において、ＤＮＳホスト名を用いてピアを発見することは不可能か、あるいは信頼できないものである。

さらに、コピーおよびキャッシュされたピアツーピア資源は、多数のロケーションにおいて同時に使用することができる場合がある。企業のイントラネット環境において、このような場合としては、数ユーザによってアクセスされる市場レポートがある。資源をキャッシュすることは多くの理由から利点がある。最初に、それは資源の有効性を高める。例えば、ラップトップから発信された資源が企業のサーバ上に組織的にキャッシュされる場合、これらの資源は、発信者がその日のうちにラップトップを閉まって帰宅した後も継続して有効であろう。次に、キャッシュすることによって、資源をそれらが使用されるロケーションの（ネットワークトポロジの用語で）「より近傍（ｃｌｏｓｅｒ）」に維持することが認められる。例えば、地理的に分散した企業においては、各オフィスごとに「出来立ての」文書をキャッシュすることには、それらの文書にアクセスする際よりよいレスポンスを得ることから利点がある。

しかし、資源の新しいバージョンが生成されると、他のピアに格納された資源の古いコピーは時代遅れとなり、その新しいバージョンがピアの間を伝播すると無効とされる（すなわち、もはや使用されない）。これは、ＤＮＳのもう１つの欠点、すなわち（十分なきめ細かさに不足するため）個々の資源を追跡し、および動的に変化するＩＰアドレスを有し、同一の資源の異なるバージョンを潜在的に格納する複数のロケーションにおいて有効な資源を追跡することができないことを示している。

さらに、同じ資源について複数のピアのコピーが存在する場合、所望の要求にとって「最もよい」あるいは「最も近傍の」コピーの小集合を選択することができることが重要である。これを可能にするためには、キャッシュされた資源の最新のコピーを有し、その資源の提供が可能なすべての同等なピアのロケーションを追跡することが必要である。

以下、本発明の実施例を図面とともに示す。しかし、添付される図面は本出願の発明の範囲を限定するものではない。図面においては、同様の参照符号によって同様の構成が示される。

以下の詳細な説明において、本発明の完全な理解を提供するために多くの具体的な詳細が示される。しかし、本発明はこれらの具体的な詳細がなくても実施することができること、本発明は示された実施形態に制限されないこと、および本発明は種々の代替される形態で実施することができることは当業者が理解するところであろう。その他、周知の方法、手続き、コンポーネントおよび回路は細部までは説明しない。

説明の一部は、当業者が他の当業者に作業の概要を伝えるために通常用いられる用語を用いてなされるであろう。また、説明の一部は、プログラム命令の実行によって実装されるオペレーションの言語でなされるであろう。当業者にはよく理解されるように、これらのオペレーションは、しばしば例えば電気コンポーネントを介して格納し、転送し、組み合わせ、およびその他操作することができる電気、磁気または光信号の形態をとる。

種々のオペレーションは、本発明の理解を支援するような方法で順に実行される複数に分けられたステップとして説明されるであろう。しかし、説明の順序は、これらのオペレーションが示された順序で実行する必要があるように、あるいは順序に依存するように解釈すべきではない。最後に、繰り返し使用される「一実施形態において」は、同じ実施形態をさしていることは、実際そうであっても必須ではない。

概観
以下に示すように、多くの発明が、ピアツーピアネットワーク環境においてピア間で資源の追跡および配置を行う資源名前付けサービス（Ｒｅｓｏｕｒｃｅ Ｎａｍｉｎｇ Ｓｅｒｖｉｃｅ：ＲＮＳ）に関連して説明される。ＲＮＳは、ピア資源が現在ピア間のいずれのロケーションで使用可能であったとしても、その資源を一意に識別する資源名前付けスキームに依存する。ＲＮＳは、既存のネットワーキングスキーム、例えばドメインネームシステム（ＤＮＳ）の不十分さを、ピアツーピアネットワーキングの能力の利点をフルに生かして克服する。

図１は、本発明のピアツーピアの一実施形態を示す図である。例示された実施形態において、ピアツーピア領域（ｒｅａｌｍ）１５０（本明細書では、単に「領域」と呼ぶ。）は、レジストラ１１０、ゲートサーバ１２０、多数のＲＮＳサーバ１３０、および多数のピア１４０を含む。ピア１４０は、ピア資源（図示せず）を格納するか、さもなければ使用することができる。レジストラ１１０と、ＲＮＳサーバ１３０と、ゲートサーバ１２０とはともに、本領域において発信されたピア資源を追跡し、配置し、アクセスするためのロケータおよびアクセスサービスを提供する。レジストラおよびゲートサーバが各１つ、もしくはいくつかのＲＮＳサーバおよびピアが図１に示されるが、本発明はこれらの構成がいずれの数であっても実施することができる。

本領域に参加するため、各ピア１４０は、まずレジストラ１１０に登録する。登録処理の一部として、レジストラ１１０は、各ピアに領域内で一意となる識別子を割り当て、および各ピアを所定のＲＮＳサーバにも割り当てるが、本明細書ではこれをそのピアに対する「ホームＲＮＳサーバ」と呼ぶ。所与のピア１４０のための一意の識別子は、そのピアの管理下にあるか、またはそのピアにより発信される領域１５０内のピア資源を識別するために用いられる。

ピア１４０をレジストラ１１０に登録するために、多くの手法を使用することができる。一実施形態においては、ピア１４０はウェブに基づく登録処理を用いて、識別情報（ｉｄｅｎｔｉｔｙ）を獲得しレジストラ１１０に登録することができる。登録の際は、ピア１４０とレジストラ１１０との間で一連の対話が備えられ、ユーザの識別情報、領域１５０内にある構成の間の通信を保護するための暗号キー、種々のピア資源にアクセスするための請求情報、ピア１４０がその割り当てられたＲＮＳサーバと互換性を持つことを可能にするダウンロードおよびインストールソフトウェア、その他を伝える。

所定のピア１４０のためのホームＲＮＳサーバを選択するためにもまた、レジストラ１１０は多くの手法を用いることができる。一実施形態において、レジストラ１１０は、ピア１４０が用いているソフトウェアの種類あるいはバージョンを識別し、そのソフトウェアと互換性があり、ネットワークトポロジの用語でその登録されているピア１４０の「近傍」にあるとレジストラ１１０に評価されるＲＮＳサーバのリストを生成する。ついで、レジストラ１１０は、候補のＲＮＳサーバのリストをそのピア１４０に提供して、ピア１４０がリストにあるＲＮＳサーバの各々にネットワーク経路のテストをして、最もよい応答時間を有する１つまたは複数を特定することができるようにする。すなわち、ネットワークトポロジに基づいて、ピア１４０は、いくつかのＲＮＳサーバについて他のサーバよりも、物理的距離またはネットワーク媒体の速度のいずれかにおいて「より近傍」にある可能性がある。一実施形態においては、ピアの選択は単に提案としてレジストラ１１０に返される。すなわち、レジストラ１１０は、ＲＮＳサーバの候補リストにおいて相対的なトラフィック負荷といった要因にしたがってピアが選択したＲＮＳサーバ１３０にピア１４０を割り当てる場合もあり、割り当てない場合もある。このような場合、レジストラ１１０は、提案されたＲＮＳサーバの相対的ネットワークトラフィック負荷が所定のレベルより低ければ、単にその提案されたＲＮＳサーバを割り当ててピア１４０のためのホームＲＮＳサーバとする。そうでなければ、レジストラは、例えば候補のＲＮＳサーバにおいて最も低い相対的ネットワークトラフィック負荷を有する異なるＲＮＳサーバを割り当てることができる。

レジストラ１１０は、同一の手法を何度も用いて領域１５０において新たなＲＮＳサーバを登録し、および選択されたピア１４０を再割り当てして新たなＲＮＳサーバをホームにすることもできる。すなわち、一実施形態において、レジストラ１１０は、ＲＮＳサーバのための一意な識別子を割り当て、互換性のあるピア１４０のセットを特定し、その新たなＲＮＳサーバに好適なピアのセットを提案させ、ついでピアのセットを選択して他の要因に加えその提案に基づき新たなＲＮＳサーバをそのホームとする。これに代わる実施形態において、新たなＲＮＳサーバを登録し、ピアを割り当てるため、数多くの手法を用いることができる。例えば、新たなＲＮＳサーバに、レジストラ１１０に登録する時間を越える新たなピアを蓄積することを認める場合もある。

各ＲＮＳサーバ１３０は、割り当てられたピアにおける資源のロケーションおよび使用可能性に加えて、（ＩＰアドレスまたはＩＰポート番号で）現在のネットワークロケーションおよびそのＲＮＳサーバに割り当てられたすべてのピアの状態（オンラインまたはオフライン）を追跡する。

一般的に、２つのステップの処理で資源はアクセスされる。まず、資源はロケータサービスを用いてロケーティングされなければならない。次に、その資源はロケータサービスによって返されるロケーションまたはロケーションのセットにおいて実際にアクセスする。

領域１５０内のピア１４０に対してピア資源をアクセスする際の第１のステップは、ピアが割り当てられたホームＲＮＳサーバ１３０との通信を含む。ホームＲＮＳサーバ１３０は、可能であればレジストラ１１０および他のＲＮＳサーバ１３０と共同して、その資源が使用することができることを期待される領域１５０内の１つまた複数のロケーションを決定する。一実施形態においては、ホームＲＮＳサーバ１３０によって要求するピア１４０に返されたロケーションのセットは、そのＲＮＳサーバ１３０にとって既知の他の情報に加え、ピア１４０のその時点のネットワーク識別情報（特に、その時点のＩＰアドレスあるいはＩＰアドレス）、その領域におけるその時点のネットワークトラフィック負荷に依存する。ピア１４０によっては、与えられたロケーションにおいて資源を実際にアクセスするための第２のステップが取られる。ピアが資源をアクセスすると、ピアは任意で資源をキャッシュし、現在その資源をキャッシュしていることをホームＲＮＳサーバに通知し、およびキャッシュされた資源を他のピアがアクセスすることができるようにすることができる。

クライアント装置は、本発明が適用されなかった場合、あるいはこの領域１５０のレジストラ１１０に登録されなかった場合、領域１５０の外に置かれることが考えられる。このような装置は、その時点の領域１５０からの情報をアクセスする場合があるが、通常、この領域において情報を発信することはできないであろう。

領域１５０外のクライアント装置のために、外部のネットワークトラフィック１２５はゲートサーバ１２０を介して領域１５０に向けられる。ゲートサーバ１２０は、可能であればレジストラ１１０および１つまたは複数のＲＮＳサーバと共同して、その資源を使用できることが期待される領域１５０内の１つまたは複数のピア１４０のロケーションを、上述の資源のロケーションの処理に従って決定する。クライアント装置がこの資源をホスティングするピアと互換性があるか否かにより、ゲートサーバ１２０は、単に装置のロケーションを応答するだけで、クライアント装置に自身で直接資源をアクセスさせる場合がある。クライアント装置が互換でない場合、ゲートサーバ１２０は数多くの動作、例えばあたかも装置のゲートサーバが資源であるかのように、クライアント装置として資源をアクセスし応答するといったことを行うことができる。

本明細書で用いられるように、各資源は生来的に１つのピアに関連し、これはマスタ発信者と呼ばれ、各資源は別のピアにおいて使用することもでき、これはキャッシング発信者と呼ばれる。通常、マスタ発信者のみが、資源を発信し、変更し、および削除する権限を持つ。

ロケーティングサービスは、資源のマスタ発信者をその資源のアドレスで一意に識別するとともに、マスタ発信者に関連する資源のための相対的経路を含む資源アドレス付けスキームと考える。しかし、このアドレス付けスキームは、アドレスはマスタ発信者自身へ要求を方向付けする（ｄｉｒｅｃｔ）必要はなく、マスタ発信者に応答する資源ロケーティングサービスに方向付ける必要がある場合、一意である。

この「転換された」アドレス付けスキームを用いて、ロケーティングサービスは、多くのキャッシング発信者に加えてマスタ発信者へ要求を方向付けすることができる。資源のマスタ発信者がオンラインではない場合、障害の場合、他のトラフィックで手一杯の場合またはその他すぐには使用できない場合ですら、その資源はキャッシング発信者から継続して使用することができる。潜在的に多くのピアが資源をキャッシングすることができるため、また専用のピアは事前に（ｐｒｏａｃｔｉｖｅｌｙ）資源をキャッシングするため、ロケータサービスは、巨大な量の要求を継続して、および信頼性を持って提供することができる。

ロケータサービスは、動的に変化するアドレスを有するピアに格納される資源を追跡することもできる。例えば、一実施形態において、ピア１４０には、モデムを用いてインターネットサービスプロバイダ（ＩＳＰ）を介してネットワークに接続する装置が含まれる。これらのピアの１つがインターネットに接続するたびに、ＩＳＰは、新しいＩＰアドレスを、例えば動的ホスト構成プロトコル（ＤＨＣＰ）を用いて割り当てる。さらに、これらのピアの１つが接続されるたびに、そのピアはホームＲＮＳサーバに接触して、その時点のＩＰアドレスおよびポート番号が何であるかを知らせる。次に、ホームＲＮＳサーバは、新たなロケーションを持つピアのために有するすべてのレコードを更新することができる。次いで、それがログオンされている間に、そのピアは定期的にそのホームＲＮＳサーバに「ＰＩＮＧ」を送信して、サーバにまだログオンしていることを知らせる。ＰＩＮＧが停止すると、ホームＲＮＳサーバは、そのレコードを更新してそのロケーションが不活性になったことを示す。これに代わる実施形態においては、その時点における一時的および／または移動型のピアのロケーションおよび使用可能性を追跡するため、数多くの手法を用いることができる。

資源のロケーティング
図２は、資源のロケーティングの一実施形態をより詳細に示す図である。例示される実施形態は、ゲートサーバが同様の機能を実施することができるが、ＲＮＳサーバの視点からのものである。図２は、多くの実装の具体的な詳細が含まれる。他の実施形態には、図２に例示する要素すべてが含まれない場合があり、また異なる順番で実行されたり、追加の要素が含まれたりする場合がある。

まず、ＲＮＳサーバ１３０は、２１０においてピア１４０から、またはゲートサーバ１２０から、所定の資源のロケーションに対する資源要求を受信する。この要求は、ＲＮＳサーバが属する領域内にある資源およびその資源のマスタ発信者を一意に特定する。この要求は、この所定のロケータサービスに特化したメッセージプロトコルからＨＴＴＰのように一般に受けいれられるプロトコルまで数多くの形態をとることができる。

２２０において、ＲＮＳサーバは、その固有のメモリをチェックして、それが要求された資源に対応する資源のレコードを有するか否かを決定する。一実施形態においては、資源レコードに、その資源がロケーティングされることを期待される１つまたは複数のロケーションに加えて、資源およびマスタ発信者のための一意の識別子が含まれる。このレコードはまた、所定のロケーションが活性化されることが期待されているか否か（ネットワークにログインするか否か）を示す場合がある。この場合、ＲＮＳサーバは、この要求からの一意の識別子と記録された一意の識別子のリストとを比較する。

このＲＮＳサーバが合致するレコードを有する場合、ＲＮＳサーバはこのレコードが通用しているものとする。レコードがその資源について活性化されたロケーションをリストに載せている場合、ＲＮＳサーバは、２３０においてその資源情報およびロケーションのセットをもって応答する。このレコードは、資源がキャッシュされた０またはそれ以上の活性化されたロケーションをリストに載せる。レコードがその資源について複数の活性化されたロケーションをリストに載せている場合、そのＲＮＳサーバは、要求者が選択する複数のロケーションをもって応答することができる。同一の資源について成功した要求に対し、ＲＮＳサーバは、複数のロケーションへのネットワークトラフィックのバランスを取るため、例えばラウンドロビン式でロケーションのセットを選択して、異なるロケーションのセットによって応答することができる。一実施形態において、ＲＮＳサーバは、要求者にネットワークトポロジの用語で「近く（ｐｒｏｘｉｍａｌ）」にあるアドレスをその要求者に提供し、したがってネットワークトラフィックを最適化するために、要求者のネットワーク（ＩＰ）アドレスに基づき２３０において返されるためのロケーションを選択することができる。

このＲＮＳサーバが合致する資源のレコードを有する場合、あるいはＲＮＳサーバが合致する資源のレコードを有するが、実際にはその資源について活性化されたロケーションがリストに載っていない場合、ＲＮＳサーバは、そのメモリをチェックして、それが２４０において要求される資源の発信者についての発信者レコードを有するか否かを決定する。一実施形態において、発信者レコードには、マスタ発信者に割り当てられたホームＲＮＳサーバのための識別子に加え、マスタ発信者のための一意の識別子が含まれる。この場合、ＲＮＳサーバはこの要求からの一意の識別子と記録された発信者識別子とを比較する。

ＲＮＳサーバが、合致する発信者レコードを有しない場合、ＲＮＳサーバは、このレコードは通用しているとみなし、２５０においてマスタ発信者がローカルであるか否かを決定する。すなわち、ＲＮＳサーバは、それがマスタ発信者のホームＲＮＳサーバであるか否かを決定する。

マスタ発信者がローカルの場合、ＲＮＳサーバは、２６０において、その資源についての状態情報をマスタ発信者から取得して（内部資源レコードを生成することによって）キャッシュし、２３０において、資源状態情報をその要求者に提供する。この状態情報は、マスタ発信者がその時点で活性化されているか否か（ネットワークにログインしているか否か）、およびまだ資源が存在するか否かの情報を含むことができる。活性化されたマスタ発信者に資源が存在するか否かを決定するため、ＲＮＳサーバは、マスタ発信者にクエリを出す。マスタ発信者が資源が存在することを示す場合、ＲＮＳサーバは、発信者のロケーションを含む資源のレコードを生成し、そのレコードをキャッシュして、発信者と再度通信することなくその資源についての続く要求を満たすことができるようにする。

ＲＮＳサーバは、その発信者レコードからローカルの発信者が活性化されているか否かを認識することができる。例えば、一実施形態において、ローカルの発信者は、ネットワーク上でオンラインになるたびにログインし、次いで規則に基づいてＲＮＳサーバに「ＰＩＮＧ」を送信して、ＲＮＳサーバにローカルの発信者はまだ活性化されていることを知らせる。これに代わる実施形態において、マスタ発信者が活性化されているか否かを決定するために、ＲＮＳサーバからのクエリ、発信者のログアウト手続きなどを含む、数多くの手法を用いることができる。

ローカルの発信者が不活性化されていると決定される場合、ＲＮＳサーバは、その発信者に関連して有するレコードはすべて更新される。すなわち、所定の発信者を資源としてリストに載せているいずれの資源についてのいずれのレコードも更新して、その発信者が活性化されていないことを示すことができる。もちろん、資源が存在しないおよび／またはその資源の発信者が不活性である場合、２３０において、ＲＮＳサーバは正規のエラーメッセージを返すであろう。

２５０において、マスタ発信者がローカルの発信者ではないが、ＲＮＳサーバが２４０において発信者レコードを発見した場合、ＲＮＳサーバは、リモートのＲＮＳサーバ（すなわり、マスタ発信者のために割り当てられたホームＲＮＳサーバ）に、２７０においてその資源についてリモートＲＮＳサーバによって返された状態情報を取得して（資源のレコードを生成することによって）キャッシュするためのマスタ発信者および資源の識別子によってクエリを出す。リモートのＲＮＳサーバは、その所有するメモリのレコードに基づいてこのクエリに即座に応答することができる場合がある。例えば、リモートＲＮＳサーバは、資源が使用されることが期待される追加の活性化されたロケーションを含むレコードを有することがある。リモートのＲＮＳサーバがその資源について活性化されたロケーションのレコードを持たない場合、リモートＲＮＳサーバは、そのマスタ発信者が現在活性化されているならば、そのマスタ発信者にクエリを出すことができる。リモートＲＮＳサーバからの応答に基づいて、２３０においてローカルＲＮＳサーバは応答を行う。また、その資源が存在するようには思われない場合、または現時点で使用できない場合、ＲＮＳサーバはそれに応じて応答するであろう。ローカルＲＮＳサーバは、リモートＲＮＳサーバから得たものは何でもキャッシュし、将来その資源に対する要求があった場合、リモートＲＮＳサーバに頼ることなくサービスを提供することができるようにする。一実施形態において、一のリモートＲＮＳサーバをホームとするマスタ発信者によって発信された資源に関する情報のキャッシングは、リースに基づいて実装される。すなわち、キャッシュされた情報は、それがリモートＲＮＳサーバから取得された後は、特定の時間の間有効であると考えることができる。それで、その間におけるキャッシュされた情報に対する追加の要求は、リモートＲＮＳサーバに接触することなくサービスすることができる。

２４０に戻って、ＲＮＳサーバがその資源に対する発信者のレコードを有していないと判断する場合、２９０において、そのＲＮＳサーバは、マスタ発信者がローカルの発信者である（すなわち、このサーバがマスタ発信者にとってのホームＲＮＳサーバである）か否かを決定する。マスタ発信者がこのＲＮＳサーバをホームにしている場合、このアルゴリズムは、上述のようにブロック２６０における要求に対し応答し続ける。

ブロック２９０において、そのマスタ発信者がこのＲＮＳサーバをホストとしていると判断される場合、２８０においてＲＮＳサーバはレジストラ１１０に解決を求める。レジストラ１１０は、登録された各ピアおよび各ピアがホームとして割り当てられたＲＮＳサーバのレコードを維持する。レジストラから、ＲＮＳサーバは、発信者が登録されているか否か、そうであれば、いずれのＲＮＳサーバにその発信者が割り当てられたかを知る。また、ＲＮＳサーバはその情報を（発信者レコードを生成することによって）キャッシュして、将来同一のマスタ発信者に方向付けられた要求のためにレジストラに接触することを回避する。

もちろん、２９５において、その発信者が登録されない場合、２７０において接触すべきリモートＲＮＳサーバはなく、２３０においてローカルのＲＮＳサーバは、適切なメッセージを返すであろう。しかし、この発信者が登録される場合、上述したように２７０において、ＲＮＳサーバは先に進められ、リモートＲＮＳサーバに接触し、したがってブロック２３０において、その要求に応答する。

上述のように、ＲＮＳサーバの一実施形態においては、そのＲＮＳサーバをホームとするピアがオンラインまたはオフラインか否かが追跡される。ピアが使用可能かどうかは、発信者レコードの一部として追跡することができる。例えば、発信者レコードは次のフォームとすることができる：

例示される実施形態において、ピアがそのホームＲＮＳサーバにログインするたびに、ＲＮＳサーバはピアのレコードを更新して、ピアの状態がオンラインであることを表示し、ピアの現在のＩＰアドレスおよびポート番号を記録する。ピアがログアウトしたと判断すると、ＲＮＳサーバは再びピアのレコードを更新してピアの状態がオフラインであることを表示する。

これに代わる実施形態において、ＲＮＳサーバはまた、他のＲＮＳサーバをホームとするピアの状態をも追跡する。例えば、リモートＲＮＳサーバの状態情報は、現在のロケーション情報とともにリースに基づきキャッシュされ、その状態情報を特定の時間間隔の間有効とみなすようにすることができる。

ピアの状態を追跡することによって、ＲＮＳサーバは、ピアのロケーションが、例えばピアのログアウトや新しいＩＰアドレスによるログインのように変化するときでも継続して資源レコードを維持することができる。

例えば、資源レコードのエントリは次のようなフォームとすることができる：

ＲＮＳサーバがその資源に対する要求を受信すると、ＲＮＳサーバは、一意の資源識別子に基づいて対応する資源レコードを特定し、それらのリストから発信者識別子のセットを選択する。次いで、ＲＮＳサーバは発信者レコードを調べて対応する発信者の現在の状態を決定し、およびオンラインにあることを示す状態の各選択された発信者に対する現在のＩＰアドレスおよびポート番号を返す。

他の実施形態においては、資源レコードのエントリは次のフォームである：

この例において、その資源の発信者の一意の識別子をリストに載せるのではなく、資源レコードは、その資源についての実際のネットワークロケーションをリストに載せる。この場合、ＲＮＳサーバがその資源に対する要求を受信すると、ＲＮＳサーバはリストに載せられたロケーションのなかから選択し、その発信者を調査する中間のステップなしに選択されたロケーションを返して、その選択されたロケーションのいずれがオンラインであると期待されるかを判断する。それらのネットワークロケーションの変化に合わせ、その発信者についての現在のロケーションを維持するため、ＲＮＳサーバはその資源レコード全体をスキャンして、オフラインにあると判断される発信者に対応するロケーションにフラグを立てる。発信者がさらにログインすると、ＲＮＳサーバは再び資源レコードをスキャンし、フラグを除去して、その古いロケーションを現在のロケーションに置き換える。

もちろん、ＲＮＳサーバは、数多くの実施形態において、レコードを編成し利用する。例えば、資源レコードおよび発信者レコードは、２つのリストに分ける代わり、単一のリストにする場合がある。あるいはまた、発信者レコードはさらに、ＲＮＳサーバに割り当てられたピアのリストに加え、他のＲＮＳサーバに割り当てられた別のリストに分割することができる。そして、もちろん、発信者の現時点の状態を追跡して発信者のネットワークロケーションを更新するために対応する種々の手法をとることができる。

ピアプラットフォーム
図３は、図１のピア１４０の一実施形態をより詳細に示す図である。ピア１４０は、ピアプラットフォーム３７０、ピアツーピアアプリケーション３４５、ウェブブラウザ３６５、並びに２つの永続的構造、発信者ディレクトリ３８０および資源キャッシュ３８５を含む。

ピアツーピアアプリケーション３４５は、種々のピアツーピアアプリケーションおよびウェブサービス、例えばすべての参加者がゲームソフトのコピーを実行する分散型ゲームアプリケーションのいずれかを示す。ブラウザ３６５は、多くのウェブブラウザ、例えばネットスケープナビゲータ、マイクロソフト（登録商標）インターネットエクスプローラなどのいずれかを表す。永続的構造３８０および３８５は、種々の永続的メモリ装置、例えば種々の方法のいずれかでアドレス付けされ、編成されたハードディスク、フラッシュメモリ、などのいずれかを表す。ピア１４０の他の実施形態は、追加の要素を含むことができ、別途調整された要素を持つことができ、例示される要素のすべてを含まない場合もある。

ピアプラットフォーム３７０は、ピア１４０についてのすべてのピアツーピアトラフィック３２０および資源ロケータトラフィック３１０を割り込みおよび方向付けを行う。ピアプラットフォーム３７０は、直接ロケータサービスにインタフェースするための資源ロケータ３３０、ピアツーピアアプリケーション３４５に直接インタフェースするためのアプリケーションプログラミングインタフェース（ＡＰＩ）３４０、ピアツーピア要求３２０（以下により完全に説明する）を提供するためのサーバ３５０およびウェブブラウザ３６５およびピアツーピアアプリケーション３４５とインタフェースをとるためのプロキシコンポーネント３６０を含む。一実施形態において、ピアプラットフォーム３７０は、ピア１４０上のアプリケーションとして、入出力関数などを実行するためのピア１４０のオペレーティングシステムサービスを用いて動作する。一実施形態においては、ピアプラットフォーム３７０は、ピア１４０のオペレーティングシステムまたはファームウェアに組み込まれる。

図３を参照すると、ピアプラットフォーム３７０は、ピア資源を、その資源またはこれらの資源への参照を発信ディレクトリにおいて配置することにより「発信する」ことができる。一実施形態において、発信は、プラットフォーム３７０によって提供される適切なユーザインタフェースを介してユーザによって達成することができる（図３には示されない）。一実施形態においては、プラットフォーム３７０のＡＰＩ３４０において適切な関数をコールすることによって適切なピアツーピアアプリケーション３４５により実行することができる。

他の装置は、ピア１４０によって発信されたコンテンツを、ちょうど他の資源のようなこのピア１４０により発信されるトップレベルのディレクトリまたはディレクトリへのアクセスを要求することによって閲覧することができる。ピアツーピアトラフィック３２０としてピア１４０に入ってくるこのような要求は、結果として他のユーザがコンテンツを閲覧することとなる場合があり、またＲＮＳサーバの要求において、例えばデータ復旧動作の一部でクラッシュした後送信される場合がある。

図４は、資源のロケーティングを行う別の実施形態をより詳細に示す図であり、この場合プラットフォーム３７０からの視点である。ゲートサーバは、同様の機能を実行する。他の実施形態は、図４に示す要素をすべてを含まない場合があり、異なる順序で要素を実行し、および追加の要素を含む場合がある。

図４を参照すると、ピア１４０がネットワークまたはピア資源に対する要求をピアツーピアアプリケーション３７０またはウェブブラウザ３６５のいずれかから生成されると、プラットフォーム３７０のプロキシコンポーネント３６０はブロック４１０において要求を受信する。

ブロック４２０において、プロキシコンポーネント３６０はピアツーピアコンテンツに対する要求か否かを検査する。この要求がウェブ上のまたはインターネット上で発信された正規のネットワーク資源に対するものであると判断される場合、プロキシコンポーネント３６０は、この要求に対し単にパススルー、すなわち要求を特定のウェブサーバに送信するか、またはピア１４０を用いて、もしくは必要な場合ピア１４０に専用の既存のプロキシで接続するといった動作をするだけである。一実施形態においては、プラットフォーム３７０は、ピア１４０によって提供されるＵＲＬのフォーマットに基づいてこの判断を行う。別の実施形態では、プラットフォーム３７０は、動的にこの判断を行うが、これは「動的ピアツーピア領域同一性（ｄｙｎａｍｉｃ Ｐｅｅｒ-ｔｏ-Ｐｅｅｒ Ｒｅａｌｍ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）」の下に後述するであろう。この要求が正規のネットワーク資源、例えばワールドワイドウェブページについて「ｗｗｗ」を含むＵＲＬを有すると仮定すると、４２５において、この要求は正規のネットワークトラフィック３２５として進められる。

しかし、この要求がピア資源に対するもの、例えば「ｐｐｐ」または「ｒｎｓ」を含むＵＲＬを有する場合、プラットフォームは、４３０においてアドレス付けされたロケータサービスが既知であるか否かを判断する。すなわち、プラットフォーム３７０は、ピア資源が発信された領域についてロケータサービスを接触するための確実な接触情報を必要とする場合があるが、その領域はピア１４０が登録されたのと同じ領域の場合もあり異なる場合もある。たとえば、プラットフォーム３７０は、そのロケータサービスのためのＩＰアドレスおよびＩＰポート番号を知ることが必要な場合がある。

そのロケータサービスが既知の場合、４４０において、この要求は資源ロケータトラフィック３１０として、そのピア１４０は、既に述べたように登録処理の間そのホームとしてきたホームＲＮＳサーバ１３０に方向付けられる。次いで、ホームＲＮＳサーバは、図２において説明された以前のステップを実行してその領域で発信されるコンテンツのロケーティングを行い、またはロケータサービスに接触してリモートピア資源のロケーティングを行う。

そのロケータサービスが既知ではない場合、プラットフォーム３７０は、４３５において、まず必要とされる接触情報を取得してキャッシュする。一実施形態においては、プラットフォーム３７０は、その接触情報に対する要求をロケータサービスに正規のネットワークトラフィック３２５として送信する。ロケータサービスのゲートサーバ１２０は、この要求を受信して処理する。この要求は単にピア１４０によって要求される元のピア資源アドレスを含むのみとすることができる。あるいはまた、プラットフォーム３７０は、この要求において、それがピアツーピアプラットフォームであり、ロケータサービスに都合よく互換性を判断させるための種々の情報を含むことを表示する。ゲートサービスが必要とされる情報に応答する場合、プラットフォーム３７０はキャッシュ３８５にその情報をキャッシュして、将来再びその情報を問い合わせなければならなくなることを回避することができる。これに続いて、プラットフォーム３７０は、４４０において、要求をそのホームＲＮＳサーバに、リモートロケータのための取得された接触情報を含め送信する。４３５において、ロケータサービスが存在しない、または応答しないと判断された場合、４４０において、プラットフォーム３７０はその要求を送信することができないが、これに代えて、４４０および４４５を飛ばして、４５０において正式なエラーメッセージを返す。

４４０において、この要求が送信される場合、４４５において、プラットフォーム３７０は、そのホームＲＮＳサーバからの応答を待ち、その資源のための１つまたは複数のロケーションが受信されたか否かを見るため検査を行う。ロケーションが受信されない場合、プラットフォーム３７０は、４５０において正式なエラーメッセージを返す。１つまたは複数のロケーションが受信される場合、４６０において、プラットフォーム３７０は１つまたは複数のロケーションを選択して試行する。ついで、４２５において、その要求はピアツーピアトラフィック３２０として直接選択されたロケーションに送信される。一実施形態において、クライアントによって選択されたロケーションが使用できないか、または資源を含んでない場合、４４５において、プラットフォーム３７０は、ロケータサービスにより返された他のロケーションを試行し続けることができる。一実施形態においては、複数のロケーションが使用可能であり、資源を提供することができる場合、プラットフォーム３７０は、複数のロケーションを越えて資源を取得してくるか否かを決定することができる。プラットフォーム３７０は、まずいずれのロケーションを試行するかを決定するために数多くの手法を用いることができる。ロケーションが応答しないことを証明する場合、プラットフォーム３７０は、事前にキャッシュされたこれらのロケーションの中からその資源のためのロケーションを選択することができる。

コピーすることができる種々の資源について、その資源のアクセスが成功すると、プラットフォーム３７０は任意にそのキャッシュ３８５に資源のコピーをキャッシュし、したがってその資源のためにキャッシュする発信者となることができる。この場合、プラットフォーム３７０は、そのホームＲＮＳサーバに資源ロケータインタフェース３３０を介して、それがその資源のためにキャッシュする発信者となったことを通知することもできる。次いで、ホームＲＮＳサーバは、そのピアのロケーションをその資源のロケーションのリストに追加するであろう。このピアあるいは他のピアからのこの資源に対する将来の要求は、ホームＲＮＳサーバによってピア１４０に方向付けされ、キャッシュ３８５からサービスを提供することができる。

ピア１４０からの要求の受信に加えて、プラットフォーム３７０はまた、資源ロケータトラフィック３１０および／またはピアツーピアトラフィック３２０のフォームでキャッシュされた資源に対する要求を受信する。これらの要求は、同様にキャッシュ３８５からサービスを提供することができる。

図３および４に示される実施形態においては、別のプロトコルが、一方ではピアツーピアトラフィック３２０と正規のネットワークトラフィック３２５とで用いられ、他方では、資源ロケータトラフィック３１０で用いられる。資源のロケーションの間を交換されるメッセージは、正規のネットワークトラフィック３２５またはピアツーピアトラフィック３２０よりも特定の性質を持っているので、その資源ロケータトラフィック３１０のためのプロトコルは、より簡潔にすることができる。例えば、ＨＴＴＰのようなテキストベースのプロトコルを用いるのではなく、プラットフォーム３７０は、より帯域効率のいいメッセージのバイナリ復号化を用いることによって、そのホームＲＮＳサーバと通信することができる。これらの帯域を節約することによって、同一のＲＮＳサーバ１３０をホームとするピア１４０の数を都合よく増大させることができる。これに代わる実施形態において、すべてのタイプのトラフィックに対し単一のプロトコルを使用することができる。

ゲートサーバ
上述の通り、図１のゲートサーバ１２０は、図２において説明したＲＮＳサーバ１３０および図３において説明したピアプラットフォーム３７０と同様の機能を実装する。すなわち、ゲートサーバ１２０がピア資源を資源アドレスのフォームでピアプラットフォーム３７０として受信する場合、ゲートサーバ１２０は、その資源へのアクセスを正式なピアツーピアフォームに変換するステップを実行する。

その資源を要求する互換のピア装置に対して、ゲートサーバ１２０は、接触情報を提供して、ピアのプラットフォームが直接ピアの要求を送信することができるようにする。この場合、ゲートサーバ１２０は、単にその要求者に、これはそのホームＲＮＳサーバに接触するため要求者に必要とされるピア資源への要求であることを通知する。互換性のある要求者は、ゲートサーバからの応答をインタプリットすることができ、したがってそのホームＲＮＳサーバを用いて資源のロケーションを解決して直接与えられたロケーションをアクセスするであろう。

互換性のない装置に対して、ゲートサーバ１２０は、その要求をピアフォームに変換して、プロキシとしてその要求している装置に代わって動作する。この場合、ゲートサーバはまず、プラットフォーム３７０がするのと同様にその要求を処理し、次いで、要求者に代わってその資源をアクセスするという特別なステップを行う。すなわち、要求者がファイルのコピーを要求している場合、ゲートサーバは、資源をアクセスし、ファイルをダウンロードし、およびそれを要求者に送る。この最後の点において、ゲートサーバ１２０は、ゲートサーバが実際に資源をアクセスするピア１４０と同様の機能を実装する。

ピアツーピア資源アドレス付けスキーム
上記で議論したように、ＲＮＳアドレス付けスキームは、ＲＮＳサーバロケータサービスの重要な部分である。一実施形態においては、ＲＮＳアドレス付けスキームは、現在ワールドワイドウェブの資源を名前付けするために用いられるＵＲＬスキームと全体的に互換性がある。すなわち、ウェブページとピアツーピア資源との間のリンクが可能であり、一の資源から他の資源への移行がユーザにとって完全に透過とすることができる。例えば、ウェブページ内のリンクは、同一の文法的構造を有し、そのリンクが伝統的なウェブページに接続されるか、ピアツーピア資源に接続するかにかかわりなく、変更されないウェブブラウザによって逆参照（ｄｅ−ｒｅｆｅｒｅｎｃｅ）することができる。

ＲＮＳアドレス付けスキームの本実施形態は、ＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と同様の階層的名前付けスキームを使用する。例えば、ＵＲＬのように、ピア資源アドレスは次のフォームとすることができる：

アクセスプロトコルの例としては、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ハイパーテキスト転送プロトコルオーバＳＳＬ（セキュアソケットレイヤ）接続（ＨＴＴＰＳ）、ファイル転送プロトコル（ＦＴＰ）その他がある。この領域は、ピア資源が発信されたピアツーピア領域１５０に対応しており、その領域１５０のゲートサーバ１２０のＤＮＳ（ドメインネームサーバ）ホスト名と同一になるよう選択される。したがって、領域名は、ちょうどドメイン名が一意であるように、ネットワーキング環境において一意である。

例示される実施形態において領域の次に来るのは、ピア識別子である。これは、所定の資源のマスタ発信者に対するピア識別子に対応する。前述のように、ピア識別子はレジストラ１１０によって割り当てられ、領域１５０内で一意となる。

資源はさらに、多くのレベルの階層、例えばピア内の資源に対する経路名に基づいて編集することができる。

動的ピアツーピア領域識別子
一実施形態において、ピアツーピア資源アドレスは、文法的に正規のウェブＵＲＬに従い、文法的な約束によってウェブＵＲＬと異なることはできない。代わって、資源アドレスは、例えばそのアドレスが逆参照されると、動的に認識される。これにより領域を名前付けする際、極めて柔軟な取り扱いが可能となる。例えば、図１の実施形態において上述したように、外部ネットワークトラフィック１２５はゲートサーバ１２０によって受信される。ゲートサーバ１２０は資源アドレスを解決して、送信者に資源ロケータへクエリをどのように送信するかを指示する。そうでなければ、ゲートサーバ１２０が資源アドレスを解決し、送信者の代わりに資源をアクセスする。

図６は、資源アドレスをゲートサーバの視点から解決する一実施形態を示す図である。

６１０において、ゲートサーバは、正規のウェブＵＲＬとして資源アドレスを受信する。

６２０において、要求者が互換性のあるピア装置の場合、６３０において、ゲートサーバは、要求者にその固有の資源ロケータサービスを用いて資源をアクセスするよう指示する。一実施形態においては、ゲートサーバは、要求者が要求者による要求に含まれる特殊なＨＴＴＰヘッダに基づくピア装置であることを認識することができる場合がある。例えば、これは、要求者のタイプを「互換性のあるピア装置」と特定する「Ｖｉａ」ヘッダとすることができる。あるいはまた、要求者とゲートサーバとが追加のメッセージを交換して、互換性を確認する場合もある。要求者が互換性あるピア装置の場合、その要求者は、領域名をキャッシュして、資源アドレスを将来ゲートサーバに送信することを回避することができる。

６２０において要求者がピア装置でない場合、６４０において、ゲートサーバは要求されたコンテンツを取得して要求者に返す。

資源相同性
複数のロケーションにキャッシュすることができ、時間を越えて変更することができる資源に対して、キャッシュ相同性（ｃｏｈｅｒｅｎｃｅ）は重要となる可能性がある。すなわち、資源が複数のピアによってキャッシュされ、次いでマスタ発信者がその資源を更新する場合、期限切れのキャッシュされたデータを用いて要求にサービスを提供しないことが重要である。「相同性のあるキャッシュ」とは、資源の有効なキャッシュされたコピーがそのマスタ資源と同一であることを意味する。

資源の種類に依存して、期限切れのデータが問題となる場合もあれば、問題とならない場合もある。例えば、その資源が愛好家の「その日のジョーク」というウェブサイトの場合、ユーザは、キャッシュされたデータが２、３日古くても気にしないかもしれない。一方、その資源がディトレーダのウェブサイト上にある株式相場表示データの場合、ユーザは迅速な更新を要求するであろう。すなわち、そのデータの優先度が高ければ高いほどキャッシュ相同性の基準への要求はより厳しくなる可能性がある。

複数の同一の資源アドレスを維持する資源に対する複数の更新に対処するため、資源識別子が用いられる。所与の資源のための資源識別子は、資源のバージョン番号に加え資源アドレスを含む。一実施形態においては、資源識別子は次のようにプラットフォーム３７０によって生成される：資源アドレスは、ピア１４０が登録されていた領域、ピア識別子、およびピア発信者ディレクトリ３８０にある発信される資源の相対ファイルシステムパスの組み合わせとして生成される：資源のバージョン番号は、その発信ディレクトリ３８０を検査することによってピアツーピアプラットフォーム３７０により定められるように、その資源の最後の作成時または変更時に基づく。

マスタ発信者が資源を作成または変更するたびに、マスタ発信者は、資源の最新の作成または変更のデータおよび時刻に基づいて新たな資源バージョン番号を生成する。

一実施形態においては、資源バージョン番号がピア装置で設定される時計の違いに影響されないことを保証するため、ピアは中央の領域の時計に同期させる。時計の同期は、例えばピア装置がオンラインになり、そのＲＮＳサーバにそのピアの現在のＩＰアドレスを通知するとき実行することができる。さらに、ピア装置での時計の狂いがバージョンの番号付けに影響しないことを保証するため、ピアは規則的に中央の時計に再同期することができる。これに代わる実施形態においては、バージョン番号をプラットフォーム３７０によって順次生成することができる。

相同性のあるデータを高次に保証する一方法としては、マスタ発信者のみに資源を変更させ、およびアクセス前に現在の資源識別子をマスタ発信者によって検査することをすべての要求に必要とさせることである。例えば、資源が要求されるたびにロケータサーバはマスタ発信者に資源の現バージョンについてのクエリを発行し、現バージョンが発見されることを期待されるロケーションのリストを有する現バージョンを返す。

ピアが資源をキャッシュし、続いてその資源を再び要求する場合、その資源のバージョンがピアのキャッシュ３８５にキャッシュされているとしても、ロケータがもっとも最新のバージョンを返し、ピアがそのキャッシュされたコピーが同一のバージョンであると検証するまで、ピアはその資源をアクセスしないであろう。バージョンが変更されていた場合、要求しているピアはそのキャッシュから時代遅れのバージョンを廃棄して、ロケータサービスによって供給されたそのリストから資源の新たなバージョンをアクセスする。

ピア１４０またはゲートサーバ１２０が、キャッシュしている発信者から資源を取り込む場合、資源識別子にあるバージョンの表示が資源ロケータの要求の結果返された期待されるバージョンと合致することを保証するため検査することができる。ピア１４０が期待されるのと異なるバージョンと認識する場合、これはその資源の古いバージョンをキャッシュしている発信者のせいかもしれない。この場合、ピア１４０はロケータの要求の結果ＲＮＳサーバによって返された他のいずれかのロケーションを試行しなければならないか、またはロケータ要求を一から繰り返すことを選択することができる。

事前に（ｐｒｏａｃｔｉｖｅｌｙ）マスタ発信者にクエリを発行することによって、マスタ発信者に対し途方もない量のデータトラフィックを生成することができる。例えば、数百万のピアを有する領域において、その資源についてのマスタ発信者が通常の５６Ｋモデムでネットワークに結合するデスクトップコンピュータの場合、マスタ発信者は、ロケータサービストラフィックがストリームライン化されたフォーマットを用いたとしても、ロケータサービストラフィックに対して容易にボトルネックになる。

問題とはならないが、やや低いレベルの相同性は、現バージョンについて事前にマスタ発信者にクエリを発酵する以外に、変化および／または変更をレポートするマスタ発信者に依存する。例えば、マスタ発信者が更新されたバージョンを発信するたびに、マスタ発信者はそのホームＲＮＳサーバに変化を通知する。すなわち、マスタ発信者は、ホームＲＮＳサーバにその資源に関連する新たな資源識別子を通知する。ＲＮＳサーバがマスタ発信者からの通知しない場合、ＲＮＳサーバは要求された資源に対する現在のレコードは正しいと考える。これは図２の実施形態の場合である。

ＲＮＳサーバがマスタ発信者よりも、ロケータサービストラフィックに対してより高速の帯域幅のデータ接続を持つより強健な装置である可能性がある。この場合、ボトルネックになる可能性をずっとより低くするため、資源をアクセスする前にＲＮＳサーバが要求のサービスを提供する。さらに、非常に大きいピアツーピア領域においては、単一のホームＲＮＳサーバがボトルネックになる可能性がある。少なくとも、この手法によって本来別の目的で費やされるべき帯域が大量に消費される可能性がある。

ホームＲＮＳサーバやマスタ発信者から種々のバージョン番号を常に要求するのではなく、時々キャッシュを単に流す（ｆｌｕｓｈ）という手法がある。ＲＮＳサーバが資源のレコードを現在有する場合、ＲＮＳサーバはそのレコードを使用する。ピアがキャッシュされた資源のコピーを有する場合、ピアはそのキャッシュされたコピーを使用する。キャッシュされた項目の生存期間は資源の優先度に基づいて調整することができる。その項目の優先度が高くなればなるほど、よりしばしば流される可能性がある。

資源を変更する権限が一のマスタユーザに限られない場合、キャッシュ相同性は可能であるが、より大きなオーバヘッドを扱う必要がある。例えば、多くのユーザが資源をキャッシュして、それを共同で変更する場合、各ユーザによって生成される新たなバージョンの各々は、資源がキャッシュされたすべてのロケーションをＲＮＳサーバが追跡することを考慮して、すべての他のユーザに同報される可能性がある。

これに代わる多くの手法が、上述の手法の組み合わせを含めキャッシュ相同性のために使用することができる。特定の実施形態においては、ユーザは任意で種々の資源に対して要求されるキャッシュ相同性のレベルを選択することができる。

図５は、ＲＮＳサーバから見た所定のレコードに対するキャッシュ相同性スキームの一実施形態を示す図である。例示される実施形態において、このＲＮＳサーバをホームとするピアは、資源を事前にアクセスしてキャッシュする。次いで、ＲＮＳサーバはそのピアをその資源についてキャッシュする発信者としてリストに載せ、およびそのピアによってキャッシュされた資源について資源識別子を（バージョン表示を含め）リストに載せている資源レコードをキャッシュする。ピアは、その資源が使用することができることを期待されるいくつかのロケーションのリストの中の一箇所とすることができる。

５１０において、ＲＮＳサーバはキャッシュされたレコードに対する要求を監視する。監視の間、ＲＮＳサーバは、５２０において、キャッシュされたレコードが時間切れかどうかを監視する。すなわち、レコードはＲＮＳサーバがどの程度の時間それをキャッシュするかに関する時間制限を有する。時間切れになった場合、５４０において、レコードが流され処理は終了する。この時間制限は、所定の資源に対するすべてのロケーションを参照するすべてのレコードに適用される場合もあり、またそれはキャッシュする発信者のロケーションだけに適用される場合もある。５４０においてキャッシュする発信者のロケーションのみが流される場合、その資源についてより最近キャッシュされたロケーションは、ＲＮＳサーバにおいて資源レコードに継続して維持することができる。

キャッシュされたレコードに対する要求を待つ間、５３０においてＲＮＳサーバはまた、ローカルのマスタが資源を更新したか否かを監視する。すなわち、その資源いついてのマスタ発信者はまた、このＲＮＳサーバをホームとする場合、マスタ発信者はＲＮＳサーバに、いつその資源がＲＮＳサーバに新たな資源識別子を送信することによって更新されるかを通知するであろう。この場合、５４０において、ＲＮＳサーバはその資源の古いバージョンについてのロケーションのレコード全部を流す。

一実施形態においては、マスタ発信者は、そのホームＲＮＳサーバに、予めそのホームＲＮＳサーバによって調べられた（およびそのホームＲＮＳサーバが、そのためにキャッシュされた資源レコードを有する）変更の資源についての情報を送信するだけで選択的にそのホームＲＮＳサーバに資源の更新を通知することができる。

一実施形態において、ホームＲＮＳサーバはまた、マスタ発信者に、ホームＲＮＳサーバがキャッシュされた資源レコードを廃棄することを選択するときはいつでも通知することができる、このような通知に続いて行うことができる。

他の実施形態においては、ホームＲＮＳサーバは、キャッシュされた資源レコードがマスタ発信者にマスタ発信者が、一時的にその資源についての変更通知のホームＲＮＳサーバへの送信を、その資源が再びマスタ発信者に関しホームＲＮＳサーバによって調べられるまで停止する場合があることを示す状態表示をマスタ発信者から受信した変更通知に返信することができる。

資源が時間切れになるか、またはマスタ発信者によって更新されるまで待つ間、ＲＮＳサーバはまた、５３５において、キャッシュしている発信者がその資源を流したか否かを監視する。ピアがもはやその資源をキャッシュしていない場合、その資源に関してそのピアのロケーションをキャッシュし続ける理由はない。一実施形態においては、ピアプラットフォームは、いつ新たな資源が生成されるか、いつ資源が変更されるか、およびいつ資源が削除されるかをそれらのＲＮＳサーバに通知する。これによって、ＲＮＳサーバはそれらのレコードを更新する。

５１０にもどると、キャッシュされたレコードに対する要求が受信される場合、５５０においてそのＲＮＳサーバは、キャッシュされた状態を提供する。ＲＮＳサーバは、別のＲＮＳサーバをホームとするマスタ発信者からの資源変更は監視しないことに留意されたい。すなわち、例示される実施形態において、リモートＲＮＳサーバをホームとするマスタ発信者によって発信された資源の状態の変化は図５のＲＮＳサーバによって無視される。換言すれば、資源レコードが時間切れでない場合、そのレコードは有効と考えられる。この手法は、ＲＮＳサーバ内のトラフィックを非常に低減させることができる。リモートのマスタ発信者についてのレコードの生存時間を短く保つことによって、かなり高いレベルの相同性を維持することができる。

これに代わる実施形態において、レコードを流すため、多くの追加の基準を用いることができる。例えば、ＲＮＳサーバがメモリ空間が少なくなった場合、レコードを流すことができる。ついで、より多くのメモリが使用可能になると、ＲＮＳサーバは、発信された資源の現在の状態についてピアにクエリを発行することによってレコードを再生成することができる。

実装および代替の実施形態
図１のピア１４０のようなピアは、広範な種々の装置とすることができる。一実施形態においては、ピアはエンドユーザ装置、例えばデスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルド装置、などである。１つのピアは、ネットワーキング環境における他のいずれかのロケーションで使用可能な資源へのアクセスを要求するクライアントのように動作し、また同様にそのピアにおいて使用可能な資源についての要求に対しサービスを提供するサーバのようにも動作することができる。あるピアにおいて使用可能な資源は、ファイル、可能なファイルのディレクトリ、ピアに接続する機器、ウェブサービス、マイクロソフト（登録商標）．ＮＥＴサービス、アプリケーションインスタンス、所定のユーザ（チャットの参加者など）を含む場合がある。

ＲＮＳロケータサービストラフィックは、実際にほとんどの資源にアクセスする際に必要なデータ量に比較して、少ない量のデータトラフィックしか要求されない。換言すると、ピアは、単にＲＮＳサーバに資源が見つかるロケーションを問い合わせ、実際にその資源をアクセスするためのロケーションまたは一連のロケーションに行くだけである。この２つのステップの処理によって、ＲＮＳネットワークは例外的に「スケーラブル」となるが、これは巨大な数のピアをサポートし、特に困難を受けることなく急速に成長することができることを意味する。たとえば、最初のステップは非常に小さいデータしか使用しないので、ＲＮＳサーバは時間当たり非常に大きな数の小さな要求を扱うことができる。データトラフィックの容量は、ピア間で直接交換される。容量を追加するのは、より多くのＲＮＳサーバを追加してより多くのピアを登録するように容易である。

図１において、領域１５０の要素は、相互に種々のネットワーク転送プロトコル、例えばユーザダイアグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）のいずれか、および種々のアプリケーションプロトコル、例えば専用プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）などのいずれかを用いて通信する。領域１５０を含むネットワーキング環境は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、私設ネットワーク、公開のインターネットなどを含む。これに代わる実施形態においては、領域１５０はスタンドアロンネットワークを含む。

ＲＮＳサーバは、暗号化、ファイヤウォールなどを含む数多くのセキュリティ手法を使用することができる。種々のプロトコルツールもまた、パケットが失われたり、受信が順序誤りになったり、重複して受信したりするなどの信頼性のないネットワーキング環境に適応するため使用することができる。例えば、要求および応答はパイプラインおよび／または複数回送信とすることができる。各トランザクションは「ノンス」を含むが、これは同一の要求に対し複数の応答が合ったときこれを区別するために、トランザクションを開始するものによって生成される一意の識別子である。

図７は、広範な分類のコンピュータシステム、例えばパーソナルコンピュータ、ワークステーション、および／または組み込みシステムを示すことを企図するハードウェアシステム７００の一実施形態を示す図である。例示される実施形態において、ハードウェアシステム７００は、高速バス７０５に結合したプロセッサ７１０を含み、高速バス７０５は、入出力（Ｉ／Ｏ）バス７１５にバスブリッジ７３０を介して結合する。一時メモリ７２０は、バス７０５に結合する。永久メモリ７４０は、バス７１５に結合する。Ｉ／Ｏ装置７５０は、ディスプレイ装置、キーボード、１つまたは複数の外部ネットワークインタフェースを含むことができる。

特定の実施形態は更なるコンポーネントを含み、上記のすべてを含むことを必要とせず、あるいは１つまたは複数のコンポーネントを組み合わせることができる。例えば、一時メモリ７４０は、プロセッサ７１０とともにオンチップとすることができる。あるいはまた、永久メモリ７２０は、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）とすることができ、その場合、ソフトウェアルーチンはＥＥＰＲＯＭからとられて実行される。実施形態によっては、コンポーネントのすべてが結合する単一のバスを用いる場合もあり、あるいは１つまたは複数の追加のバスおよび種々の追加のコンポーネントを結合することができるバスブリッジを用いる場合がある。当業者は、これに代わる内部ネットワーク、例えばメモリコントローラハブおよびＩ／Ｏコントローラハブを持つ高速システムバスに基づく内部ネットワークに精通しているであろう。追加のコンポーネントとしては、追加のプロセッサ、ＣＤ ＲＯＭドライブ、追加のメモリ、その他の本技術分野で既知の周辺コンポーネントを含むことができる。

一実施形態において、上述の通り本発明は、１つまたは複数のハードウェアシステム、例えば図７のハードウェアシステム７００を用いて実装される。複数のコンピュータが用いられる場合、それらのシステムは結合して、外部ネットワーク、例えばローカルエリアネットワーク（ＬＡＮ）、インターネットプロトコル（ＩＰ）ネットワークなどを介して通信することができる。一実施形態において、本発明は、コンピュータ内の１つまたは複数の実行ユニットによって実行されるソフトウェアルーチンとして実装される。所与のコンピュータのために、ソフトウェアルーチンは、永久メモリ７４０のような記憶装置に格納することができる。

あるいはまた、図８に示すように、ソフトウェアルーチンは、機械読取可能な記憶媒体８２０、例えばディスケット、ＣＤ-ＲＯＭ、磁気テープ、デジタルビデオまたは多用途ディスク（ＤＶＤ）、レーザディスク、ＲＯＭ、フラッシュメモリなどを用いて、格納される機械実行可能命令８１０とすることができる。一連の命令は、ローカルに格納する必要はなく、リモートの記憶装置、例えばネットワーク上のサーバ、ＣＤ ＲＯＭ装置、フロッピ（登録商標）などから、例えば図７のＩ／Ｏ装置７５０を介して受信することができる。

いずれのソースによっても、命令を記憶装置から一時メモリ７２０にコピーし、プロセッサ７１０によってアクセスおよび実行することができる。一実施形態において、これらのソフトウェアルーチンはＣ言語で記述される。しかし、これらのルーチンが広範な種類のプログラム言語のいずれかで実装することができることが理解されるべきである。

これに代わる実施形態において、本発明は別々のハードウェアまたはファームウェアで実装される。例えば、アプリケーションスペシフィック統合回路（ＡＳＩＣｓ）は、上述の関数（ｆｕｎｃｔｉｏｎ）の１つまたは複数によってプログラムすることができる。別の実施例において、本発明の１つまたは複数の関数は、追加の回路基板上の１つまたは複数のＡＳＩＣで実装することができ、この回路基板は上述のコンピュータに挿入される。別の実施例では、フィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）または静的プログラマブルゲートアレイ（ＳＰＧＡ）を用いて、本発明の１つまたは複数の関数を実装することができる。さらに別の実施形態では、ハードウェア及びソフトウェアの組み合わせが用いられて、本発明の１つまたは複数の関数を実装することができる。

以上によって、資源名前付けサービスが説明された。当業者は、本詳細な説明を読んだ後本発明の多くの代替および変更を理解するが、例示により説明した所定の実施形態は、いかなる方法でも、限定的に解釈することを意図するものではないことは理解されるであろう。したがって、所定の実施形態の詳細な参照は特許請求の範囲を制限することを意図したものではない。

ピアツーピアの領域の一実施形態を示す図である。 ＲＮＳサーバからみたピア資源をロケーティングする一実施形態を説明する図である。 ピアの一実施形態を示す図である。 図３で示されるピアプラットフォームから見たピア資源をロケーティングする一実施形態を示す図である。 キャッシュ相同性スキームの一実施形態を示す図である。 ピア資源アドレスを解決する一実施形態を示す図である。 本発明を実行するハードウェアシステムの一実施形態を示す図である。 本発明の機械読取可能命令を格納する機械読取可能な記憶媒体の一実施形態を示す図である。

Claims (9)

1. ロケータサービスを提供するレジストラ、少なくとも１つの資源名前付けサービス（ＲＮＳ）サーバおよびゲートサーバ並びに各々が資源ロケータインタフェースを有するピアを含むピアツーピア領域ネットワーク環境において、ピア間で資源を追跡し、ロケーティングするコンピュータ実装方法であって、
   前記レジストラにピアを登録するステップと、
   前記レジストラにより、ピアに前記レジストラの領域内で一意となる識別子を提供するステップと、
   前記レジストラにより、前記ピアを所定のＲＮＳサーバに割り当てるステップと、
   前記割り当てられたＲＮＳサーバにより、ＩＰアドレスまたはＩＰポート番号を含む、現在のネットワークロケーションを追跡するステップと、
   前記ピアにより、前記ロケータサービスを使用し、前記資源ロケータインタフェースを介して資源をロケーティングするステップと、
   前記ピアにより、前記ロケータサービスが提供するロケーションにおいて前記資源をアクセスするステップと、
   前記ピアにより、前記アクセスされた資源をキャッシュするステップと、
   前記ピアにより、前記ピアが前記キャッシュされた資源のためのキャッシュとして動作していることを前記ＲＮＳサーバに通知し、および前記登録処理の間に前記レジストラから取得した一意の識別子を使用して、前記キャッシュされた資源を他のピアがアクセスすることができるようにするステップと、
   前記ピアにより、定期的に前記割り当てられたＲＮＳサーバにＰＩＮＧを送信して、前記ピアがまだログオンしていることを知らせるステップと、
   前記割り当てられたＲＮＳサーバが定期的なＰＩＮＧを前記ピアから受信しない場合、前記割り当てられたＲＮＳサーバが、そのレコードを更新して前記ロケーションが不活性になったことを示すステップと
   を備えたことを特徴とする方法。
2. 前記資源ロケータサービスは、前記資源アドレスにおいて資源のマスタ発信者をその資源のアドレスで一意に識別するとともに、前記マスタ発信者に関連する資源のための相対的経路を含む資源アドレス付けスキームを推定することを特徴とする請求項１に記載の方法。
3. 前記資源をロケーティングするステップは、前記ＲＮＳサーバにより所定のロケーションのための資源要求を前記ピアから受信するステップを含むことを特徴とする請求項１に記載の方法。
4. 前記資源をロケーティングするステップは、前記ＲＮＳサーバが、それが要求された資源に対応する資源のレコードを有するか否か、そのメモリをチェックし、有するときは前記資源の情報および前記資源のロケーションのセットをもって応答するステップをさらに含むことを特徴とする請求項３に記載の方法。
5. 前記ＲＮＳサーバは、異なるロケーションのセットを含む同一の資源についての成功した要求に対し、複数のロケーションへのネットワークトラフィックのバランスを取るため、ラウンドロビン式を含む選択方式を用いてロケーションのセットを選択することを特徴とする請求項４に記載の方法。
6. 前記ＲＮＳサーバは、合致するレコードを有しないときは、前記資源についての状態情報をマスタ発信者から取得してキャッシュし、該資源状態情報をその前記要求者に提供することを特徴とする請求項４に記載の方法。
7. 前記要求は、メッセージプロトコルまたはＨＴＴＰのフォームをとることを特徴とする請求項３に記載の方法。
8. 請求項１に記載の各ステップをコンピュータに実行させる命令を備えたコンピュータプログラム。
9. 請求項２乃至７のいずれかに記載のステップをコンピュータに実行させる命令を備えたコンピュータプログラム。

Images