JP2004532471A - 分散コンピュータ・ネットワークのスケーラブルなリソース・ディスカバリおよび再構成 - Google Patents

Abstract

【課題】ユーザ・ノードのネットワークでリソースを発見する方法を提供すること。
【解決手段】この方法によれば、パブリッシュされるリソース要求が、ネットワークの第１ユーザ・ノードで受信され、そのリソース要求をサーバ・ノードに送信するか否かが決定される（たとえばランダムに）。そのリソース要求をサーバ・ノードに送信しないと決定される場合には、そのリソース要求は、直接接続を介してネットワークの第２ユーザ・ノードに転送される。そのリソース要求をサーバ・ノードに送信すると決定される場合には、そのリソース要求は、パブリケーションのためにサーバ・ノードに送信される。ユーザ・ノードおよび少なくとも１つのサーバ・ノードを含むタイプのコンピュータ・ネットワークで使用されるユーザ・ノードが提供され、ユーザ・ノードのそれぞれは、直接接続を介して少なくとも１つの他のユーザ・ノードに接続される。
【選択図】図１

Description

【技術分野】
【０００１】
本発明は、コンピュータ・ネットワークに関し、具体的には、分散コンピュータ・ネットワークでのスケーラブル・リソース・ディスカバリおよび動的再構成のフレームワークに関する。
【背景技術】
【０００２】
インターネットなどのコンピュータ・ネットワークを用いると、ユーザが、ファイルおよびハードウェアなどのリソースを共用できるようになる。インターネットの拡大およびワールド・ワイド・ウェブの標準規格の採用によって、ユーザによるファイルの表示およびダウンロードが、ほとんど苦労のないものになった。ユーザは、全くプログラミング言語を知る必要がない。単にインターネット・ブラウザを実行することによって、ユーザは、望みのファイルを表示し、ダウンロードするのに、ポイント・アンド・クリックを行うだけでよい。そのようなプログラムの可用性によって、文字どおり地球全体にまたがることができる分散コンピュータ・ネットワークを介して、非常に遠くに離れている同じ目的の個人の間での簡単な協同作業およびファイル共用が可能になる。
【０００３】
従来は、分散コンピュータ・ネットワークは、クライアント／サーバ・フレームワークを有するようにセット・アップされる。具体的に言うと、各ユーザは、クライアントであり、ネットワークを介してサーバ・ノードにアクセスでき、適当な許可があれば、サーバ・ノードにファイルをパブリッシュすることができる。ファイルをサーバ・ノードにパブリッシュしたならば、ネットワーク上の他のクライアントが、サーバ・ノードにアクセスして、そのファイルを表示するかダウンロードすることができる。さらに、サーバ・ノードは、クライアントが、ネットワークを介して到達可能な別のクライアントに自動的にファイルを送信できるようにすることができる。クライアントは、単に、所望の受信側を識別する情報と共にファイルをサーバ・ノードに送信し、サーバ・ノードは、対応するクライアントにそのファイルを送信する。サーバ・ノードは、クライアントがプリンタなどのハードウェア・リソースを共用できるようにするのにも使用することができる。
【０００４】
そのようなクライアント／サーバ・フレームワークを用いると、サーバ・ノードは、セキュリティを提供する責任を負わされる。たとえば、サーバ・ノードは、許可されたクライアントだけが、ネットワーク・リソースを使用する（たとえばファイルをダウンロードする）ことができ、正しいファイルだけがパブリッシュされることを保証しなければならない。さらに、サーバ・ノードは、single point of failure（単一機器の故障がシステム全体の故障となること）を表す。したがって、どれであれ、信頼性が要求されるクライアント／サーバ環境では、サーバ・ノードが、業務用強度（industrialstrength）を有し、システム・シャットダウンおよびデータ損失を防ぐために冗長システムを有しなければならない。さらに、すべてのクライアント対クライアント・リソース転送が、サーバ・ノードを通過するので、ネットワークに別のクライアントを追加することによって、サーバ・ノードに追加の負荷がかかり、ネットワーク性能が低下する。
【０００５】
そのようなクライアント／サーバ・フレームワークでは、クライアントが、ほとんどプライバシを有しない。通常、サーバ・ノードは、クライアントがネットワーク・リソースへのアクセスを許可される前に、認証を必要とする。クライアントが、認証証明を提供したならば、サーバ・ノードは、そのクライアントのネットワーク・アクティビティのすべてを、簡単にログ記録することができる。たとえば、サーバ・ノードは、クライアントによってアップロードされたファイルおよびダウンロードされたファイルのすべてのログを保持することができる。認証されないクライアントによるアクセスが許容される場合であっても、サーバ・ノードは、さまざまな独自の識別技法のいずれかを使用して、経時的にクライアント・アクティビティを追跡することができる。たとえば、サーバ・ノードは、クライアントに独自のクッキーを置き、後にそのクッキーを使用して、クライアントがサーバ・ノードにアクセスするたびにそのクライアントを識別することができる。
【０００６】
従来のクライアント／サーバ・フレームワークの短所の一部の解決の１つが、「viral」ネットワークによって提供される。そのようなネットワークでは、ユーザ・ノードが、非常に相互接続された仮想ネットワークに参加する１つまたは複数の既知のホストに接続される。その後、ユーザ・ノード自体は、リソースおよび使用可能なホストに関する要求に応答できるホスト・ノードになる。ネットワーク内の各ユーザは、すべての既知の隣接ノードにリソース要求を転送して、潜在的に各要求をネットワーク全体を介して伝搬させる。たとえば、Gnutellaシステムでは、そのようなviralネットワーク・フレームワークが使用される。Gnutellaは、公開されたネットワーク・プロトコルであり、ユーザに、各ユーザがファイル共用ネットワーク内のホスト・ノードとして活動できるようにするクライアント／サーバ・アプリケーション（http://Gnutella.wego.comで入手可能）を提供する。Gnutellaシステムは、暗号化およびライセンス供与によって保護される商業コンテンツを安全に配布するのに使用することができる。
【０００７】
viralネットワークは、ピアツーピア通信に基づく。ピアツーピアは、各当事者が類似する機能を有し、どちらの当事者でも通信セッションを開始することができる、通信モデルである。たとえば、Gnutellaアプリケーションでは、ピアツーピア通信を使用して、ユーザが、インターネットを介して互いにファイルを交換できるようにする。viralネットワークで使用されるピアツーピア・モデルは、各ピア（すなわちユーザ・ノード）がネットワーク内の他のピアの少なくとも１つの知識を有することに頼る。ファイルなどのリソースを検索する時に、ピアは、リソース要求を他の既知のピアに送信し、このピアは、その要求をそのピアに既知のピアに渡し、以下同様にして、要求がネットワーク全体に伝搬される。リソースを有し、要求を受信したピアは、そのリソース（またはそのリソースの可用性を示すメッセージ）を要求元のピアに送信することができる。そのようなフレームワークでは、集中ネットワーク機関（たとえば、サーバ・ノード）からの独立が提供されるので、viralネットワークのユーザは、強化されたプライバシを有し、singlepoint of failureが除去される。
【０００８】
図１に、例示的なviralネットワークを示す。このネットワーク内の各ノードは、クライアントおよびホストの両方として働くユーザを表し、１つまたは複数の他のノードに接続される。第１ノード２１０が、特定のリソース（たとえばファイル）を望む時に、第１ノード２１０は、既知のノード２０２、２０４、２０６、および２０８のすべてに要求を発行し、これらのノードも同じことを行う。たとえば、この要求は、ノード２０８、２１６、および２１８を介して連続して渡されることによって、第２ノード２１２に達する。第２ノード２１２は、要求されたリソースを有する場合に、適当なメッセージを第１ノード２１０に送信する（たとえば、要求がトラバースしたの同一の経路を逆に）ことによって応答する。要求されたリソースを有するノードが識別されたので、第１ノード２１０は、リソースをダウンロードするために、第２ノード２１２との直接ピアツーピア接続を開始することができる。viralネットワーク全体を通じて、任意の数のそのようなリソース要求、肯定応答、および転送を、同時に行うことができる。
【０００９】
viralネットワークでは、強化されたプライバシが提供され、single pointof failureが除去されるが、このフレームワークは、スケーラビリティに関連する短所を有する。大規模な非集中viralネットワークでは、参加ノードの数が増えるにつれて、効率的なリソース・ディスカバリが壊される。具体的に言うと、リソース要求は、ノードからノードへ伝搬されることだけができ、各ノードは、要求を比較的少数の他のノードに伝搬することだけができる。ネットワーク・トラフィックを制御し、非現実的な応答時間を防ぐために、実用的なシステムでは、「存続時間」または要求を転送できる回数に対するなんらかの限度（すなわち、ピア・ホップの最大回数）を使用しなければならない。これによって、非現実的に多い数の中間ノードを介して伝搬されることを必要とする経路によって分離された２つのノードまたはノードのグループが、効果的に切断される。さらに、要求伝搬に対するそのような制限によって、リソースに関する網羅的探索を実行することが不可能になる。というのは、そのような検索が、ネットワーク内のすべてのノードに要求が伝搬されることを必要とするからである。
【００１０】
さらに、最近、情報フロー・グラフを使用する、コンテンツベースのパブリッシュ−サブスクライブ・メッセージング・インフラストラクチャが提案された。たとえば、Gryphonシステム（http://www.research.ibm.com/Gryphonで説明されている）が、本発明の譲受人によって開発された。このシステムは、コンテンツベースのサブスクリプション・サービスを提供し、分散パブリッシュ／サブスクライブ通信およびデータベース技術の特徴をマージすることによるメッセージ・ブローカリングを実行する。Gryphonシステムの核には、イベントの選択的デリバリ、イベントの変換、および新しいイベントの生成を指定する情報フロー・グラフがある。
【００１１】
図２に、情報フロー・グラフを使用する例示的なコンテンツベースのパブリッシュ−サブスクライブ・メッセージング・インフラストラクチャを示す。このシステムでは、２つの情報ソースＮＹＳＥおよびＮＡＳＤＡＱから導出された株取引が、組み合わされ、変換され、フィルタリングされ、サブスクライブするクライアントに送達される。たとえば、あるユーザ３１２が、メッセージ・ブローカリング・サーバ３０２にサブスクライブし、１００万ドルを超える値を有する、ＮＹＳＥおよびＮＡＳＤＡＱの両方のすべての株取引を受け取ることを要求することができる。メッセージ・ブローカ３０２は、価格および量などの生の株取引情報を、ＮＹＳＥ３２４およびＮＡＳＤＡＱ３２６から受け取る。
【００１２】
ユーザ３１２からの情報要求に基づいて、サーバ３０２は、２つのソースからの株取引情報をマージし、生の価格および量の情報を、各取引の値情報に変換し、導出された値をフィルタリングして、１００万ドルを超える値を有する取引のサブセットを作る。類似する形で、サブスクライブするユーザのそれぞれ（たとえば、ノード３０４、３０６、および３０８）が、それ自体の判断基準を指定し、メッセージ・ブローカリング・サーバ３０２が、要求された情報を各ユーザに供給するために、情報選択、変換、フィルタリング、およびデリバリを実行する。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
図２のパブリッシュ−サブスクライブ・メッセージング・インフラストラクチャは、多数のユーザを有するメッセージング・システムによいスケーラビリティを提供するが、従来のクライアント／サーバ・フレームワークと同様に、ユーザは、ほとんどプライバシを有しない。すべてのユーザが、システムにサブスクライブする時に自分自身の身元を示さなければならず、すべての情報が、集中サーバを介してユーザに送達される。したがって、集中サーバは、システムの全ユーザと、各ユーザが望み、受け取る精確な情報とのログを簡単に維持することができる。集中メッセージブローカリング・サーバは、このシステムのsingle point of failureも表す。
【課題を解決するための手段】
【００１４】
スケーラブルなメッセージング・インフラストラクチャを提供して、スケーラビリティおよび性能の問題に対処すると同時に、非集中ネットワークの特徴のほとんどを保存する。少なくとも１つのパブリッシュ−サブスクライブ・サーバ・ノードが、中央機関としてではなく、メッセージング・インフラストラクチャ層として、非集中ネットワーク内に設けられる。したがって、非集中ネットワークでスケーラビリティを達成することができる。
【００１５】
本発明の一実施形態では、ユーザ・ノードのネットワーク内でリソースを発見する方法が提供される。この方法によれば、パブリッシュされるリソース要求が、ネットワークの第１ユーザ・ノードで受信され、そのリソース要求をサーバ・ノードに送信するか否かが決定される。そのリソース要求をサーバ・ノードに送信しないと決定される場合には、そのリソース要求は、直接接続を介してネットワークの第２ユーザ・ノードに転送される。そのリソース要求をサーバ・ノードに送信すると決定される場合には、そのリソース要求は、パブリケーションのためにサーバ・ノードに送信される。好ましい実施形態では、リソース要求をサーバ・ノードに送信するか否かの決定が、第１ユーザ・ノードによって行われるランダムな決定である。
【００１６】
本発明のもう１つの実施形態では、ユーザ・ノードおよび少なくとも１つのサーバ・ノードを含むタイプのコンピュータ・ネットワークで使用されるユーザ・ノードが提供され、ユーザ・ノードのそれぞれは、直接接続を介して少なくとも１つの他のユーザ・ノードに接続される。ユーザ・ノードには、パブリッシュされるリソース要求を受信する受信インターフェースと、サーバ・ノードにリソース要求を送信するか否かを決定する制御手段と、直接接続を介してネットワークの第２ユーザ・ノードにリソース要求を選択的に転送するか、パブリケーションのためにリソース要求をサーバ・ノードに送信する少なくとも１つの送信インターフェースとが含まれる。送信インターフェースは、制御手段がリソース要求をサーバ・ノードに送信しないと決定する時に、リソース要求を第２ユーザ・ノードに転送し、制御手段がリソース要求をサーバ・ノードに送信すると決定する時に、リソース要求をパブリケーションのためにサーバ・ノードに送信する。１つの好ましい実施形態では、制御手段が、ネットワークの他のユーザ・ノードのうちで、リソース要求が転送される第２ユーザ・ノードになる１つを、ランダムに選択する。
【００１７】
本発明を、例としてのみ、添付図面に関してこれから説明する。
【発明を実施するための最良の形態】
【００１８】
図３に、本発明の好ましい実施形態によるスケーラブル・ネットワーク・フレームワークを示す。図からわかるように、このフレームワークには、パブリッシュ−サブスクライブ・サーバ・ノード４０２と、複数のユーザ・ノード（たとえば４０４、４０６、および４１０）が含まれる。本発明の実施形態では、サーバ・ノード４０２を、単一のサーバによって、または任意の数のサーバからなる「サーバ・クラウド」によって実施することができる。そのようなサーバ・クラウドの個々のサーバは、さまざまな形で互いにおよびインターネットに接続することができ、データおよびパスの冗長性など、適当なレベルのサービスおよび有利な特徴を提供するために、遠くに離すことさえできる。
【００１９】
このフレームワーク内で、ユーザ・ノード４１６が、パブリッシュ−サブスクライブ・サーバ・ノード４０２に連絡し、あるメッセージの「チャネル」をサブスクライブすることによって、このネットワークに加入する。さらに、加入するユーザ・ノード４１６は、接続を求め、少なくとも１つの他のユーザ・ノード４１０、４１８、および４２０に直接に接続する（たとえば、地理的位置、接続速度、または共通の興味などの判断基準に基づいて）。この形で、ネットワーク内のユーザ・ノードのすべてが、メッセージング（図をわかりやすくするために図示せず）に関して集中パブリッシュ−サブスクライブ・サーバ・ノードに接続され、非集中viralタイプ・リソース共用ネットワークを形成するピアツーピア接続を介して互いに接続される。
【００２０】
図４は、本発明の第１の実施形態による、そのようなスケーラブル・ネットワーク・フレームワーク内でリソースを得る処理の流れ図である。ネットワーク内の第１ユーザ・ノード４１６が、リソース（たとえばファイル）を求める時に、必ず、リソース要求（または照会）が、サーバ・ノード４０２に送信され（ステップＳ１０）、サーバ・ノード４０２は、その要求のタイプに対応するチャネルにサブスクライブしたすべてのユーザ・ノードにその要求を送信することによって、リソース要求をパブリッシュする（ステップＳ１２）。この要求を受信し、進んでそのリソースを提供する第２ユーザ・ノード４２２は、第１ユーザ・ノード４１６に連絡し（ステップＳ１４）、第１ユーザ・ノード４１６および第２ユーザ・ノード４２２は、ピアツーピア接続をセット・アップして、要求されたリソースを第１ユーザ・ノード４１６に供給する（ステップＳ１６）。この形で、パブリッシュ−サブスクライブ・メッセージング・インフラストラクチャ層を用いると、要求元ノードから離れたノードに、非常に多数の中間ノードを含む直接接続経路によってリソース要求が到達できるようになる。
【００２１】
したがって、本発明によって提供されるスケーラブル・ネットワーク・フレームワークでは、ネットワーク内のユーザ・ノードの数が増える時に、効率的なリソース・ディスカバリが維持される。それと同時に、リソース自体は、サーバにパブリッシュされず、実際のリソース共用は、サーバを用いないので、サーバに対する需要が、従来のクライアント／サーバ・フレームワークより少ない。さらに、各検索要求が、関連チャネルにサブスクライブするすべてのユーザ・ノードにパブリッシュされるので、非常に多数のユーザ・ノードを含むネットワークで、許容可能な時間枠の中で、要求されたリソースに関する網羅的な（または少なくとも非常に広範囲の）検索を実行することが可能である。
【００２２】
好ましい実施形態では、パブリッシュ−サブスクライブ・メッセージング・インフラストラクチャによって、２タイプの「チャネル」または共用データ・ストリームがサポートされる。第１のタイプのチャネルは、「ノード・ディスカバリ・チャネル」であり、これは、非集中ネットワーク内の他のユーザ・ノードのディスカバリをサポートするのに使用される。ネットワークに加入するために、ユーザ・ノードは、サーバ・ノードのパブリッシュ−サブスクライブ・メッセージング・インフラストラクチャを使用して、それ自体を告知する。具体的に言うと、新しいユーザ・ノードからの加入告知が、サーバ・ノードを介して、１つまたは複数のノード・ディスカバリ・チャネルに経路指定されて、他のユーザ・ノードからの接続を求める。したがって、パブリッシュ−サブスクライブ・インフラストラクチャは、加入告知のブロードキャストを達成するために他のユーザ・ノードへの接続を確立する、汎用のトランスポート層（ＩＰ層の上の層に似た）として機能する。
【００２３】
そのような加入告知を、地理的位置、ネットワーク接続速度、使用可能なリソースのタイプ、および／または共通の関心などのカテゴリに基づいて、個々のノード・ディスカバリ・チャネルの間で分割することができる。したがって、新しいユーザ・ノードは、リモート・ユーザ・ノード（地理的とネットワーク・ホップに関しての両方で）を発見することができ、接続する時に、望みのタイプのリソースまたは許容可能な接続性属性を有するノードを優先することができる。さらに、各加入告知は、あるチャネルにサブスクライブするユーザ・ノードだけに送信されるので、非常に大きいネットワークのユーザ・ノードに、加入告知が常に多数押し寄せることはない。
【００２４】
第２のタイプのチャネルは、「リソース要求チャネル」であり、これは、リソース要求のパブリケーションを最適化するのに使用される。上で説明したように、サーバ・ノードは、特定のチャネル（１つまたは複数）にサブスクライブするすべてのユーザ・ノードにリソース要求を送信することによって、各リソース要求をパブリッシュする。これらのリソース要求チャネルは、ユーザ・ノードが望ましくない要求を効果的にフィルタ・アウトできるようにするために、リソース・タイプのさまざまな分類に分割することができる。さらに、ネットワーク内のすべてのユーザ・ノードに達するのではなく、リソース要求チャネルを使用することによって、リソース要求が、ユーザ・ノードの関連するサブセット（すなわち、関連する１つまたは複数のチャネルにサブスクライブするユーザ・ノード）だけに達することができるようになる。
【００２５】
したがって、技術文書の共用だけを望むユーザ・ノードは、マルチメディア・コンテンツの要求を浴びせかけられることはない。適用例に応じて、ユーザ・ノードおよび／またはサーバ・ノードは、個々の告知またはリソース要求をパブリッシュするチャネルを決定することができる。さらに、好ましい実施形態では、チャネルは、ユーザ・ノードによってパブリッシュされることによってのみ存在する。したがって、どのユーザ・ノードでも、新しいリソース・チャネルを作成し、その後、任意の通常な形で（たとえば、ウェブ・サイト、ニュースグループ、テレビジョン、またはダイレクト・メール広告を介して）、そのチャネルのサブスクリプションへの使用可能性を促進することができる。
【００２６】
図５は、本発明の第２の実施形態による、スケーラブル・ネットワーク・フレームワーク内でリソースを得る処理の流れ図である。ネットワーク内の第１ユーザ・ノード４１６が、リソース（たとえばファイル）を望む時に、必ず、リソース要求が、サーバ・ノード４０２に送信され（ステップＳ１０）、サーバ・ノード４０２は、要求のタイプに対応するチャネルにサブスクライブしているすべてのユーザ・ノードに送信することによって、リソース要求をパブリッシュする（ステップＳ１２）。さらに、第２の実施形態では、第１ノード４１６が、非集中ネットワークでそれが接続されているユーザ・ノード４１０、４１８、および４２０のすべてにもリソース要求を送信する。
【００２７】
この処理は、要求を受信するユーザ・ノードのそれぞれが、その要求を、接続されたユーザ・ノードに渡すことによって繰り返されて、要求が、非集中ネットワークのユーザ・ノードを介して伝搬される（ステップＳ１１）。たとえば、要求は、ノード４１０および４１４を介して連続して渡されることによって、第２ユーザ・ノード４０４に達する。さらに、いくつかの実施形態では、サーバ・ノードからリソース要求を受信する各ユーザ・ノード（たとえばユーザ・ノード４２２）も、非集中ネットワークで接続されているユーザ・ノードのすべてにリソース要求を送信する。第２ユーザ・ノード４０４が、要求を受信し（ユーザ・ノード伝搬を介するかサーバ・ノードからのいずれか）、そのリソースを進んで提供する場合には、第２ユーザ・ノード４０４は、第１ユーザ・ノード４１６に連絡し（ステップＳ１４）、ピアツーピア接続をセット・アップして、要求されたリソースを共用する（ステップＳ１６）。
【００２８】
したがって、第２の実施形態では、リソース要求が、メッセージング・インフラストラクチャ層を介してパブリッシュされる（第１の実施例と同様に）と同時に、非集中ネットワークのユーザ・ノードを介して伝搬される。この二重経路処理は、集中サーバ・ノードを介して渡される要求伝搬経路の代替物を提供するので、single point of failureが除去される。言い換えると、リソース要求は、サーバ・ノードがダウンしている時であっても、他のユーザ・ノードに伝搬される。さらに、第２の実施形態では、ユーザ・ノードのすべてが、パブリッシュ−サブスクライブ・インフラストラクチャに接続される必要はなく、その存在について知ることすら不要である。そのようなユーザ・ノードは、それに接続されているユーザ・ノードのすべてに単にリソース要求を転送することができる。この特徴を用いると、第２の実施形態を、すべてのユーザ・ノードの修正を必要とせずに、既存のネットワーク内で実施できるようになる。
【００２９】
図６は、本発明の第３の実施形態による、スケーラブル・ネットワーク・フレームワーク内でリソースを得る処理の流れ図である。この実施形態では、要求元ユーザ・ノードに、強化されたプライバシを与えるために、リソース要求が、サーバ・ノードに直接には送信されない。第３の実施形態では、リソース（たとえばファイル）が望まれる時に、必ず、要求元の第１ユーザ・ノード４１０が、図７に破線の矢印で示されているように、非集中ネットワークで接続された第２ユーザ・ノード４１４にリソース要求を送信する（ステップＳ２０）。第２ユーザ・ノード４１４は、その要求を、パブリッシュ−サブスクライブ・サーバ・ノード４０２、または非集中ネットワークでそれに接続されている別のユーザ・ノードのどちらに送信するかを決定する（ステップＳ２２）。すべてのユーザ・ノードが、メッセージングのために集中パブリッシュ−サブスクライブ・サーバ・ノードに接続されることが好ましい（図をわかりやすくするために図示せず）。
【００３０】
サーバ・ノード４０２に送信しないと決定される場合には、第２ユーザ・ノード４１４は、リソース要求を、図７に示されているように、接続されている別のユーザ・ノード４２０に転送する（ステップＳ２０）。この転送処理は、リソース要求を受信し、同一の決定を行うユーザ・ノードのそれぞれで繰り返される（ステップＳ２２）。第３ユーザ・ノード４１６が、サーバ・ノード４０２に送信すると決定する時に、リソース要求が、サーバ・ノード４０２に送信され（ステップＳ２４）、サーバ・ノード４０２は、要求のタイプに対応するチャネルにサブスクライブするすべてのユーザ・ノードに送信することによって、そのリソース要求をパブリッシュする（ステップＳ２６）。
【００３１】
好ましい実施形態では、要求をパブリッシュ−サブスクライブ・サーバ・ノードに送信するか否かの決定のそれぞれが、要求がサーバ・ノードに送信される可能性を与える、０と１の間の加重要因に基づいて、ユーザ・ノードによって行われる「ランダム」決定である。たとえば、加重要因が０．２５である場合に、ユーザ・ノードがサーバ・ノードに要求を送信する可能性は２５％、要求が別のユーザ・ノードに転送される可能性は７５％である。したがって、平均して、０．２５の加重要因は、リソース要求を、パブリッシュ−サブスクライブ・サーバ・ノードに送信される前に、他のユーザ・ノードに３回転送させる。加重要因の値は、所望のプライバシのレベルなどの要因に基づいてセットされる。さらに、加重要因を、ネットワーク全体を通じて使用される固定値とすることができ、あるいは、メッセージごとの基礎でユーザ・ノードによって設定することができる。転送の最大回数または最大経過時間などの他の判断基準も、要求を受信する各ユーザ・ノードによって行われる決定に組み込むことができる。
【００３２】
もう１つの実施形態では、要求をパブリッシュ−サブスクライブ・サーバ・ノードに送信するか否かの決定が、転送の固定された回数などの他の判断基準に基づいて行われる。たとえば、一実施形態では、各リソース要求が、必ず３つのユーザ・ノードを介して転送され、その後、パブリッシュ−サブスクライブ・サーバ・ノードに送信される。リソース要求が、別のユーザ・ノードに転送される時に、必ず、他のユーザ・ノードのどれが転送された要求を受信するかの選択が、転送するユーザ・ノードに接続されたユーザ・ノードの１つのランダムな選択を介して行われることが好ましい。
【００３３】
リソース要求が、サーバ・ノード４０２によってパブリッシュされた後に、その要求を受信し、リソースを進んで提供する第４ユーザ・ノード４２２が、第１ユーザ・ノード４１０に連絡する。具体的に言うと、図８に示されているように、第４ユーザ・ノード４２２は、パブリケーションのためにサーバ・ノード４０２にリソース要求を送信した第３ユーザ・ノード４１６に、応答を送信する（ステップＳ２８）。第３ユーザ・ノード４１６は、そこからリソース要求を受信したユーザ・ノード４２０に応答を転送し、この転送処理は、応答が第１ユーザ・ノード４１０に達するまで繰り返される（ステップＳ３０）。この時点で、第１ユーザ・ノード４１０は、第４ユーザ・ノード４２２に連絡して、直接ピアツーピア接続をセット・アップして、要求されたリソースを共用することができる（ステップＳ３２）。
【００３４】
好ましい実施形態では、リソースを有するユーザ・ノードからの応答に、リソース一致に関するメタデータが含まれる。応答が受信される時に、要求元ユーザ・ノードは、メタデータを評価し、応答するノードとの直接接続を行って、リソース自体を共用する（たとえば、要求されたファイルをダウンロードする）かどうかを決定する。複数の応答が受信される場合には、要求元ユーザ・ノードは、各応答のメタデータを評価し、任意の判断基準（たとえば、過去の経験、受信された順序、接続速度、または物理的位置）に基づいて、応答するユーザ・ノードの１つまたは複数を選択することができる。
【００３５】
さらに、好ましい実施形態では、リソースを有するユーザ・ノードからの応答が、既存の接続（要求がサーバ・ノードを介してトラバースした接続など）を介して経路指定され、新しいポイントツーポイント接続は、実際にリソースを転送するためにのみ確立される。そうでなければ、応答のそれぞれで、ユーザ・ノードが新しいポイントツーポイント接続を開始し、応答を受信するユーザ・ノードが、多数の応答を受信する時に、必ず圧倒される可能性がある。その代わりに、サーバ・ノードが、一致する「１回限り」の応答チャネルをセット・アップするか、リソース要求に応答するユーザ・ノードによって使用される永久的な応答チャネルをセット・アップすることができる。永久的な応答チャネルを介する応答のパブリッシュによって、将来の使用のために可能な関心の応答をアーカイブする「受動」ユーザ・ノードが促進される。
【００３６】
応答要求は、サーバ・ノードに直接に送信されるのではなく、１つまたは複数の他のユーザ・ノードを介して転送されるので、第３の実施形態では、要求元ユーザ・ノードにプライバシが提供される。リソースを要求する実際のユーザ・ノードは、サーバ・ノードにとって匿名のままになり、したがって、サーバ・ノードは、どのユーザがどのリソースを共用（または要求）しているかを追跡することができない。通常のviralネットワークと同様に、第３の実施形態では、実際にリソースを提供するユーザ・ノードだけが、リソース共用および要求元ノードの識別の知識を有する。さらに、通常のviralネットワークとは異なって、第３の実施形態では、パブリッシュ−サブスクライブ・メッセージング・インフラストラクチャ層を使用することによって、非常に多数のユーザ・ノードを有するネットワークでの効率的なリソース・ディスカバリが可能になる。したがって、本発明を用いると、強化されたユーザ・プライバシを維持しながら、非集中ネットワークでスケーラビリティを達成できるようになる。
【００３７】
上で説明した本発明の実施形態は、個々のメッセージを識別する機構を必要とする。好ましい実施形態では、すべてのメッセージ（すなわち、リソース要求または応答）に、一意の識別番号が割り当てられる。たとえば、一実施形態では、各ユーザ・ノードが、グローバルに一意である可能性が非常に高いグローバル一意メッセージ識別子（ＧＵＩＤ）を個別に生成できるようにする、Microsoft Corporation社によって開発されたアルゴリズムが使用される。さらに、各ユーザ・ノードは、応答（おそらくはリソース自体を含む）が、同一の経路を介して、メッセージを送信したユーザ・ノードに到達できるようにするために、少なくとも転送されたメッセージの制限されたヒストリを保管（たとえばテーブル内に）しなければならない。さらに、いくつかの実施形態に、リソース要求のループを防ぐ機構が含まれる。たとえば、グローバル一意メッセージ識別子ＧＵＩＤおよびノード・ヒストリ・テーブルを簡単に使用して、ループ防止機構を作成することができる。
【００３８】
本発明の実施形態を、単一のサーバ・ノードに関して上で説明したが、「point offailure」の懸念をさらに最小にするために、ネットワークに複数のパブリッシュ−サブスクライブ・サーバ・ノードを設けることができる。さらに、異なるサーバ・ノードを動作させ、ユーザ・ノード・サブスクリプションについて競争させることによって、競争するプロバイダが、ネットワーク内で共存することができる。さらに、上で説明した異なる実施形態の特徴を、さらなる応用のために組み合わせることができる。たとえば、本発明の一実施形態に、第３の実施形態のランダム化された要求転送と、第２の実施形態の二重伝搬／パブリケーションの両方が含まれる。ネットワーク・プロトコル、転送判断基準、およびメンバシップ判断基準などの他の設計選択を、簡単に適合させることができる。
【００３９】
本発明は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせで実現することができる。あらゆる種類のコンピュータ・システム、または本明細書に記載の方法を実行するように適合された他の装置が、適する。ハードウェアおよびソフトウェアの通常の組み合わせは、コンピュータ・プログラム製品を伴う汎用コンピュータ・システムとすることができ、このコンピュータ・プログラム製品は、ロードされ実行される時に、本明細書に記載の方法を実行するようにコンピュータ・システムを制御する。
【００４０】
本発明は、コンピュータ・プログラム製品で実施することもでき、このコンピュータ・プログラム製品には、本明細書に記載の方法の実施形態を可能にするすべての特徴が含まれ、このコンピュータ・プログラム製品は、コンピュータ・システムにロードされた時に、これらの方法を実行することができる。この文脈で、「コンピュータ・プログラム」には、ａ）別の言語、コード、または表記への変換、およびｂ）異なる材料形態での複製の一方または両方の後あるいは直接にのいずれかで、情報処理機能を有するシステムに特定の機能を実行させることを意図された命令の組の、あらゆる言語、コード、または表記でのすべての表現が含まれる。
【００４１】
各コンピュータ・システムに、１つまたは複数のコンピュータと、コンピュータがデータ、命令、メッセージ、またはメッセージ・パケットおよびコンピュータ可読媒体からの他のコンピュータ可読情報を読み取れるようにするコンピュータ可読媒体とを含めることができる。コンピュータ可読媒体には、ＲＯＭ、フラッシュ・メモリ、ハード・ディスク、フロッピ・ディスク、ＣＤ−ＲＯＭ、または他の永続記憶装置などの不揮発性メモリを含めることができる。さらに、コンピュータ可読媒体に、ＲＡＭ、バッファ、キャッシュ・メモリ、およびネットワーク回路などの揮発性記憶装置を含めることができる。さらに、コンピュータ可読媒体に、コンピュータがコンピュータ可読情報を読み取れるようにする、ネットワーク・リンクおよび／またはネットワーク・インターフェース（有線ネットワークまたは無線ネットワークを含む）などの一時的状態媒体内のコンピュータ可読情報を含めることができる。
【図面の簡単な説明】
【００４２】
【図１】例示的なviralネットワークを示す図である。
【図２】例示的なコンテンツベースのパブリッシュ−サブスクライブ・メッセージング・インフラストラクチャを示す図である。
【図３】本発明の好ましい実施形態によるスケーラブル・ネットワーク・フレームワークを示す図である。
【図４】本発明の第１の実施形態による、スケーラブル・ネットワーク・フレームワーク内でリソースを得る処理を示す流れ図である。
【図５】本発明の第２の実施形態による、スケーラブル・ネットワーク・フレームワーク内でリソースを得る処理を示す流れ図である。
【図６】本発明の第３の実施形態による、スケーラブル・ネットワーク・フレームワーク内でリソースを得る処理を示す流れ図である。
【図７】図６の処理の一部の例示的実施形態を示すスケーラブル・ネットワーク・フレームワークを示す図である。
【図８】図６の処理のもう１つの部分の例示的実施形態を示すスケーラブル・ネットワーク・フレームワークを示す図である。

Claims (20)

1. ユーザ・ノードのネットワークでリソースを発見する方法であって、
   パブリッシュされるリソース要求を前記ネットワークの第１ユーザ・ノードで受信するステップと、
   前記リソース要求をサーバ・ノードに送信するか否かを決定するステップと、
   前記リソース要求を前記サーバ・ノードに送信しないと決定される時に、前記リソース要求を直接接続を介して前記ネットワークの第２ユーザ・ノードに転送するステップと、
   前記リソース要求を前記サーバ・ノードに送信すると決定される時に、パブリケーションのために前記リソース要求を前記サーバ・ノードに送信するステップと
   を含む方法。
2. 前記決定するステップで、前記リソース要求を前記サーバ・ノードに送信するか否かの前記決定が、前記第１ユーザ・ノードによって行われるランダムな決定である、請求項１に記載の方法。
3. 前記決定するステップで、前記ランダムな決定が、前記第１ユーザ・ノードが前記リソース要求を前記サーバ・ノードに送信すると決定する確率に対応する加重要因に基づいて行われる、請求項２に記載の方法。
4. 前記転送するステップが、
   前記ユーザ・ノードのうちで前記第１ユーザ・ノードが接続されるユーザ・ノードを、前記第２ユーザ・ノードになるようにランダムに選択するサブステップと、
   前記第１ユーザ・ノードから前記第２ユーザ・ノードへ直接接続を介して前記リソース要求を転送するサブステップと
   を含む、請求項１に記載の方法。
5. 前記リソース要求を、前記サーバ・ノードを介して前記ネットワークの前記ユーザ・ノードの少なくとも一部にパブリッシュするステップをさらに含む、請求項１に記載の方法。
6. 前記パブリッシュするステップで、前記サーバ・ノードが、前記ネットワークの前記ユーザ・ノードのうちで１つまたは複数の選択されたリソース要求チャネルにサブスクライブするユーザ・ノードのすべてに前記リソース要求をパブリッシュする、請求項５に記載の方法。
7. 前記決定するステップで、前記リソース要求を受信したユーザ・ノードが、前記サーバ・ノードに前記リソース要求を送信すると決定するまで、前記決定するステップおよび前記転送するステップを繰り返すステップをさらに含む、請求項１に記載の方法。
8. 要求されるリソースを望む要求元ユーザ・ノードから前記第１ユーザ・ノードに、パブリッシュされる前記リソース要求を送信するステップと、
   前記要求元ユーザ・ノードが直接接続を介して接続される前記ユーザ・ノードのすべてに、前記要求元ユーザ・ノードから同一のリソース要求を送信するステップと
   をさらに含む、請求項１に記載の方法。
9. ユーザ・ノードのネットワークでリソースを発見するプログラムをエンコードされた計算機可読媒体であって、前記プログラムが、
   パブリッシュされるリソース要求を前記ネットワークの第１ユーザ・ノードで受信するステップと、
   前記リソース要求をサーバ・ノードに送信するか否かを決定するステップと、
   前記リソース要求を前記サーバ・ノードに送信しないと決定される時に、前記リソース要求を直接接続を介して前記ネットワークの第２ユーザ・ノードに転送するステップと、
   前記リソース要求を前記サーバ・ノードに送信すると決定される時に、パブリケーションのために前記リソース要求を前記サーバ・ノードに送信するステップと
   を実行する命令を含む、計算機可読媒体。
10. 前記決定するステップで、前記リソース要求を前記サーバ・ノードに送信するか否かの前記決定が、前記第１ユーザ・ノードによって行われるランダムな決定である、請求項９に記載の計算機可読媒体。
11. 前記決定するステップで、前記ランダムな決定が、前記第１ユーザ・ノードが前記リソース要求を前記サーバ・ノードに送信すると決定する確率に対応する加重要因に基づいて行われる、請求項１０に記載の計算機可読媒体。
12. 前記転送するステップが、
    前記ユーザ・ノードのうちで前記第１ユーザ・ノードが接続されるユーザ・ノードを、前記第２ユーザ・ノードになるようにランダムに選択するサブステップと、
    前記第１ユーザ・ノードから前記第２ユーザ・ノードへ直接接続を介して前記リソース要求を転送するサブステップと
    を含む、請求項９に記載の計算機可読媒体。
13. 前記プログラムが、前記リソース要求を、前記サーバ・ノードを介して前記ネットワークの前記ユーザ・ノードの少なくとも一部にパブリッシュするステップを実行する命令をさらに含む、請求項９に記載の計算機可読媒体。
14. 前記パブリッシュするステップで、前記サーバ・ノードが、前記ネットワークの前記ユーザ・ノードのうちで１つまたは複数の選択されたリソース要求チャネルにサブスクライブするユーザ・ノードのすべてに前記リソース要求をパブリッシュする、請求項１３に記載の計算機可読媒体。
15. 前記プログラムが、前記決定するステップで、前記リソース要求を受信したユーザ・ノードが、前記サーバ・ノードに前記リソース要求を送信すると決定するまで、前記決定するステップおよび前記転送するステップを繰り返すステップを実行する命令をさらに含む、請求項９に記載の計算機可読媒体。
16. 前記プログラムが、
    要求されるリソースを望む要求元ユーザ・ノードから前記第１ユーザ・ノードに、パブリッシュされる前記リソース要求を送信するステップと、
    前記要求元ユーザ・ノードが直接接続を介して接続されるユーザ・ノードのすべてに、前記要求元ユーザ・ノードから同一のリソース要求を送信するステップと
    を実行する命令をさらに含む、請求項９に記載の計算機可読媒体。
17. 複数のユーザ・ノードおよび少なくとも１つのサーバ・ノードを含むタイプのコンピュータ・ネットワークで使用されるユーザ・ノードであって、前記ユーザ・ノードのそれぞれが、直接接続を介して少なくとも１つの他のユーザ・ノードに接続され、前記ユーザ・ノードが、
    パブリッシュされるリソース要求を受信する受信インターフェースと、
    前記リソース要求を前記サーバ・ノードに送信するか否かを決定する制御手段と、
    前記リソース要求を直接接続を介して前記ネットワークの第２ユーザ・ノードに選択的に転送するか、パブリケーションのために前記リソース要求を前記サーバ・ノードに送信する、少なくとも１つの送信インターフェースと
    を含み、前記送信インターフェースが、前記制御手段が前記リソース要求を前記サーバ・ノードに送信しないと決定する時に、前記リソース要求を前記第２ユーザ・ノードに転送し、前記制御手段が前記リソース要求を前記サーバ・ノードに送信すると決定する時に、パブリケーションのために前記リソース要求を前記サーバ・ノードに送信する
    ユーザ・ノード。
18. 前記制御手段が、前記リソース要求を前記サーバ・ノードに送信するか否かをランダムに決定する、請求項１７に記載のユーザ・ノード。
19. 前記制御手段が、加重要因に基づいてランダムに決定する、請求項１８に記載のユーザ・ノード。
20. 前記制御手段が、前記ネットワークの他のユーザ・ノードのうちで、前記リソース要求が転送される前記第２ユーザ・ノードになるユーザ・ノードをランダムに選択する、請求項１７に記載のユーザ・ノード。

Images