(57)【要約】特許請求された方法およびシステムは、１組の仮想プロキシホストを使用して仮想プロキシを動的に構成することについて述べている。仮想プロキシホストは、ネットワーク上の発見されたサービスのレコードを含む共有データストアを維持してもよい。仮想プロキシホストは、共有データストアを使用して、発見要求に応答するように共に働いてもよい。仮想プロキシホストを有するネットワーク上のクライアントは、仮想プロキシホストへのユニキャストの発見要求に限定され、それによって、ブロードキャスト・トラフィックが減少され得る。【選択図】図１
2009534939.tif 000002
【特許請求の範囲】
【請求項１】
デバイスのネットワークのための発見プロキシサービスを提供する方法であって、
共有可能データストアを作成するステップであって、前記共有可能データストアが、発見されたサービスのレコードを含む、ステップと、
前記共有可能データストアを第１のホストに関連付けるステップと、
前記第１のホストで、前記第１のホストが発見プロキシであることを示す第１のプローブマッチでクライアントプローブに応答するステップと、
前記第１のホストで、前記共有可能データストアに基づいて解決要求を解決するステップとを含む方法。
【請求項２】
ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシが使用可能かどうか周期的に判断し、ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシが使用可能な場合は、前記第１のホストによってクライアントプローブに応答し、解決要求を解決することを控えるステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１のホストで、前記共有可能データストアに関連する第２のホストから第２のプローブマッチを受信し、前記第２のプローブマッチの受信から遅延期間経過後に、前記第１のホストで、第１のプローブマッチによりクライアントプローブに応答するステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記第１のホストで、前記共有可能データストアに関連する第２のホストから第２のプローブマッチを受信し、前記第２のプローブマッチを受信すると、前記第１のホストで前記第１のプローブマッチでクライアントプローブに応答することを控えるステップをさらに含む、請求項１に記載の方法。
【請求項５】
第２のホストによって、前記第１のホストが共有データストアに関連付けられているかどうか判断し、前記第１のホストが前記共有データストアに関連付けられている場合は、第２のホストを前記共有可能データストアに関連付けるステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記第１のホストが共有可能データストアに関連付けられているかどうか判断するステップが、前記第１のホストからＨｅｌｌｏメッセージまたはプローブマッチのうちの１つを受信すると、前記第２のホストによって前記第１のホストに問い合わせるステップを含む、請求項５に記載の方法。
【請求項７】
前記第１のホストが共有データストアに関連付けられているかどうか判断するステップが、前記第１のホストが共有データストアに関連付けられていることの表示を求めてプローブマッチをチェックするステップを含む、請求項５に記載の方法。
【請求項８】
前記第１のホストが共有データストアに関連付けられているかどうか判断するステップが、前記第１のホスト上で、前記第２のホストによるピア名前解決プロトコル解決プロセスを開始するステップを含む、請求項５に記載の方法。
【請求項９】
クライアントプローブに応答し、解決要求を解決するステップが、発見プロトコルを介して実施され、共有可能なデータストアを作成し、前記第１および第２のホストのうちの１つを前記共有可能データストアに関連付けるステップが、前記発見プロトコルと異なる第２のプロトコルによって実施される、請求項５に記載の方法。
【請求項１０】
前記第１および第２ホストエンティティのうちの１つを、プローブマッチでクライアントプローブに応答するように指定するステップをさらに含む、請求項５に記載の方法。
【請求項１１】
前記共有可能なデータストアが、分散データストアおよび複製データストアのうちの１つである、請求項５に記載の方法。
【請求項１２】
前記第１および第２ホストエンティティのうちの１つを、前記データストアの分散に基づいて解決要求を解決するように指定するステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
第１のホストが共有可能データストアに関連付けられているかどうか判断し、前記第１のホストが共有可能データストアに関連付けられている場合は、第２のホストを前記共有可能データストアに関連付けるステップであって、前記共有可能データストアが、発見されたサービスのレコードを含む、ステップと、
前記第１および第２のホストのうちの１つを、プローブおよび解決要求のうちの１つに応答するように指定するステップと、
ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシが使用可能かどうか周期的に判断し、ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシが使用可能な場合は、前記第１および第２のホストによる前記プローブおよび解決要求のうちの１つへの応答を控えるステップとを含む操作を実施するためのコンピュータ実行可能命令を含むコンピュータ読取り可能媒体。
【請求項１４】
前記共有可能なデータストアが分配型ハッシュテーブルであり、前記第１および第２ホストのうちの１つを、プローブおよび解決要求のうちの１つに応答するように指定するステップが、発見されたサービスの前記レコードのハッシュに基づく、請求項１３に記載のコンピュータ読取り可能媒体。
【請求項１５】
前記分散ハッシュテーブルが、ピアツーピアネットワークを介して操作される、請求項１３に記載のコンピュータ読取り可能媒体。
【請求項１６】
発見プロトコルを介して通信するデバイスのネットワークと、
プローブおよび解決メッセージのうちの１つを前記ネットワークにブロードキャストするクライアントデバイスと、
前記ネットワーク上の発見されたサービスのレコードを含む共有可能データストアと、
前記共有可能なデータストアの部分を格納する第１のホストデバイス、および前記共有可能なデータストアの第２の部分を格納する第２のホストデバイスであって、前記第１および第２のホストのうちの１つが、前記発見プロトコルを介して前記プローブおよび解決メッセージのうちの１つに応答する、第１のホストデバイスおよび第２のホストデバイスとを含むシステム。
【請求項１７】
ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシである第３のホストをさらに含み、前記第１のホストが、前記第３のホストがＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシであると判断すると、クライアントプローブおよび解決要求に応じることを止める、請求項１６に記載のシステム。
【請求項１８】
前記第１のホストが、プローブおよび解決メッセージへの応答を調整するために、前記発見プロトコルとは別の第２のプロトコルを介して前記第２のホストと通信する、請求項１６に記載のシステム。
【請求項１９】
前記第１および第２の部分がハッシュ関数によって決定される、請求項１６に記載のシステム。
【請求項２０】
前記第１のホストおよび第２のホストのうちの１つが、前記ハッシュ関数に基づいて前記プローブおよび解決メッセージのうちの１つに応答する、請求項１９に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
Ｗｅｂサービス発見（ＷＳ−Ｄｉｓｃｏｖｅｒｙ）プロトコルなど、ブロードキャストベースの発見プロトコルは、大きいサブネット、あるいは多くのサービスおよび／または要求元を含むサブネット上のかなりの帯域幅を消費することがある。ブロードキャストベース発見プロトコルを実装するオープンネットワークでは、あまりに多くのサービス／要求元がプローブおよび／または解決メッセージを同時に送信しているとき、ブロードキャストストームが発生することがある。ストームは、通信システムを凌駕し、発見プロセス内部および外部で通信遅延を引き起こすことがある。一部のブロードキャストプロトコルは、通信の隙間を生じさせるために、メッセージ待機トリガなど、ネットワークトラフィックを減少させる機構を有し得るが、多くのデバイスを含む大きいサブネットは依然として、データストームおよび通信障害を受ける。
【０００２】
一部のブロードキャストベース発見プロトコルは、専用サーバ上で使用可能なＷＳ−Ｄｉｓｃｏｖｅｒｙサービスのストアを維持するホスト型発見プロキシをサポートしてもよい。サービス発見のためにネットワーク全体にわたるプローブメッセージを送信するのではなく、ホストは、単にプロキシと対話して、そのサービス解決プロセスを実施してもよい。プロキシは、ホストがプロキシへのユニキャスト問合せを単に実施して発見を実施し得るように発見情報を格納することによって、ネットワークトラフィックを減少させることができる。
【０００３】
プロキシの使用はネットワークトラフィックを減少させ得るが、プロキシは、企業がホストサーバを明示的に配置することを必要とすることがあり、それによって、ネットワーク展開および管理コストが増すことがある。
【発明の開示】
【課題を解決するための手段】
【０００４】
特許請求された方法およびシステムは、共有データストアを管理するホストのサブネットを使用してアドホック仮想プロキシを提供する。特許請求された方法およびシステムは、仮想プロキシサブネットに参加することができないレガシーデバイスを含み得るエンティティのより大きいネットワークの上に、仮想プロキシホストのサブネットを置いてもよい。要求された方法およびシステムは、アドホックプロキシが、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）へのクライアントの参加に基づいて作成されることを可能にする。
【０００５】
一実施形態では、アドホックプロキシは、動的データの発見および取出し、解決サービスの提供、ならびにＬＡＮ上のサービスの通知のために使用されてもよい。
【０００６】
一実施形態では、特許請求されたアドホックプロキシは、ＷＳ−Ｄｉｓｃｏｖｅｒｙ環境内のデバイスデータ、および／または簡易サービス発見プロトコル（ＳＳＤＰ：Ｓｉｍｐｌｅ  Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ）環境内のデバイスデータを管理するために使用されてもよい。
【発明を実施するための最良の形態】
【０００７】
下記本文は、複数の異なる実施形態についての詳細な説明を述べているが、説明の法的範囲は、本特許の冒頭に記載された特許請求の範囲の言葉によって定められることを理解されたい。詳細な説明は、例示的なものにすぎないと解釈すべきであり、あらゆる可能な実施形態について述べることは、不可能でないにせよ、非実用的であるので、あらゆる可能な実施形態について述べているとは限らない。現在の技術、または本特許の出願日の後に開発された技術を使用して複数の代替実施形態が実施されてもよく、それは、やはり特許請求の範囲内に含まれる。
【０００８】
「本明細書では、用語「ｘｘ」は・・・を意味するものと定義される」という文または類似の文を使用して用語が本特許において明示的に定義されない限り、その用語の意味を、その平易または通常の意味を超えて明示的にまたは暗黙的に限定する意図はなく、こうした用語は、（特許請求の範囲の言語以外の）本特許のいずれかの節でなされるいずれかの言明に基づいて範囲が限定されるものと解釈されるべきでないことも理解されたい。本特許の冒頭の特許請求の範囲に記載されたいずれかの用語が、単一の意味に合致するように言及されている範囲においては、これは、読者を混乱させないように分かりやすくするために行われており、こうした特許請求の範囲の用語は、暗黙的にまたは別のやり方でその単一の意味に限定されるものではない。最後に、特許請求の範囲の要素が、いずかの構造についての記述なしに単語「手段」および機能を記述することによって定義されない限り、特許請求範囲のいかなる要素も、米国特許法第１１２条６項の適用に基づいて解釈されることは意図されていない。
【０００９】
図１は、特許請求された方法および装置のブロックのためのシステムが実装され得る適切なコンピューティングシステム環境１００の一例を示している。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、特許請求の範囲の方法および装置の使用または機能性の範囲に関して限定を示唆するものではない。コンピューティング環境１００は、例示的な動作環境１００に示された構成要素のいずれか１つの構成要素またはその組合せに関する依存性または要件を有するものと解釈すべきでない。
【００１０】
特許請求された方法および装置のブロックは、他の複数の汎用または特別目的コンピューティングシステム環境または構成で動作可能である。特許請求の範囲の方法または装置で使用するのに適し得る、よく知られているコンピューティングシステム、環境および／または構成の例には、それだけに限らないが、パーソナルコンピュータ、サーバコンピュータ、手持ち式またはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。
【００１１】
特許請求に記載された方法および装置のブロックは、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で述べられ得る。一般に、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。この諸方法および装置は、通信ネットワークを介してリンクされたリモート処理装置よってタスクが実施される分散コンピューティング環境内でも実施され得る。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含めて、ローカルとリモートの両方のコンピュータ記憶媒体に置かれてもよい。
【００１２】
図１を参照すると、特許請求された方法および装置のブロックを実施するための例示的なシステムが、コンピュータ１１０の形の汎用コンピューティングデバイスを含んでいる。コンピュータ１１０の構成要素は、それだけに限らないが、処理装置１２０、システムメモリ１３０、ならびにシステムメモリを含めて様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１を含んでもよい。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バスおよび様々なバスアーキテクチュアのいずれかを使用したローカルバスを含めて、複数のタイプのバス構造のいずれかであり得る。限定するためではなく、例を挙げると、こうしたアーキテクチュアには、業界標準アーキテクチュア（ＩＳＡ：Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロチャネルアーキテクチュア（ＭＣＡ：Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ：Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ：Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとしても知られている周辺コンポーネント相互接続（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００１３】
コンピュータ１１０は一般に、様々なコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１１０によってアクセスされてもよい任意の使用可能な媒体とすることができ、揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体を含む。限定するためではなく、例を挙げると、コンピュータ読取り可能媒体は、コンピュータ記憶媒体と通信媒体とを含んでもよい。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュールまたは他のデータなどの情報を格納するための任意の方法または技術で実装された揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体を含む。コンピュータ記憶媒体には、それだけに限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶デバイス、あるいは所望の情報を格納するために使用されてもよく、またコンピュータ１１０によってアクセスされてもよい他の任意の媒体が含まれる。通信媒体は一般に、コンピュータ読取り可能命令、データ構造体、プログラムモジュールまたは他のデータを、搬送波や他の移送機構などの変調されたデータ信号として実施し、また任意の情報送達媒体を含む。用語「変調されたデータ信号」は、信号中の情報を符号化するなどのやり方でその特性の１つまたは複数が設定されまたは変更された信号を意味する。限定のためではなく、例を挙げると、通信媒体は、有線ネットワークや直接有線ネットワークなどの有線媒体、ならびに音響、ＲＦ、赤外線などの無線媒体、および他の無線媒体を含む。上記内容のどんな組合せもまた、コンピュータ読取り可能媒体の範囲内に含まれるべきである。
【００１４】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）１３１およびランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）１３２などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）１３３は一般に、ＲＯＭ  １３１に格納される。ＲＡＭ  １３２は一般に、処理装置１２０によって即時にアクセス可能であり、かつ／またはそれによる操作を現在受けているデータおよび／またはプログラムモジュールを含む。限定するためではなく、例示するために、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７を示している。
【００１５】
コンピュータ１１０は、他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。例示するためだけに、図１は、取外し不可能な不揮発性の磁気媒体から読み出しまたはそこに書き込むハードディスクドライブ１４０、取外し可能な不揮発性の磁気ディスク１５２から読み出しまたはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光学媒体などの取外し可能な不揮発性の光ディスク１５６から読み出しまたはそこに書き込む光ディスクドライブ１５５を示している。例示的な動作環境で使用されてもよい他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体には、それだけに限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は一般に、インターフェース１４０などの取外し不可能なメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスク装置１５１および光ディスクドライブ１５５は一般に、インターフェース１０５など、取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００１６】
上記に論じられ、図１に示されたドライブおよびその関連するコンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュールおよびコンピュータ１１０のための他のデータの記憶域を提供する。図１で、たとえば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７を格納するものとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７と同じであっても、それとは異なってもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７は、少なくともそれらがそれぞれ異なるコピーであることを示すために、ここでは異なる番号が付与されている。ユーザは、キーボード１６２、およびマウス、トラックボールまたはタッチパッドと一般に呼ばれるポインティング装置１６１などの入力デバイスによって、コンピュータ１１０にコマンドおよび情報を入力してもよい。他の入力デバイス（図示せず）は、マイクロホン、ジョイスティック、ゲームパッド、衛星放送アンテナ、スキャナなどを含み得る。これらおよび他の入力装置はしばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）などの他のインターフェースおよびバス構造によって接続されてもよい。モニタ１９１または他のタイプの表示デバイスもまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、出力周辺インターフェース１９０によって接続されてもよいスピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスを含むこともできる。
【００１７】
コンピュータ１１０は、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で動作してもよい。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、また図１にはメモリ記憶デバイス１８１だけが示されているが、コンピュータ１１０に関して上記で述べられた諸要素の多くまたはすべてを一般に含む。図１に示された論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１と広域ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）１７３とを含むが、他のネットワークを含むこともできる。こうしたネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。
【００１８】
ＬＡＮネットワーキング環境内で使用されるときき、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ  １７１に接続される。ＷＡＮネットワーキング環境内で使用されるとき、コンピュータ１１０は一般に、モデム１７２、あるいはインターネットなどのＷＡＮ  １７３を介して通信を確立する他の手段を含む。内部にあることも、外部にあることもあるモデム１７２は、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続されてもよい。ネットワーク化された環境では、コンピュータ１１０に関して示したプログラムモジュール、またはその一部は、リモートメモリ記憶デバイス内に格納されてもよい。限定のためではなく、例示するために、図１は、リモートアプリケーションプログラム１８５を、メモリデバイス１８１内に常駐するものとして示している。示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段が使用されてもよいことが理解されよう。
【００１９】
発見は、クライアントが１つまたは複数のターゲットサービスを探索することを伴ってもよい。この探索は、一致が見つかるまでクライアントが可能なターゲットサービスにメッセージを送信するポーリングプロセスを伴ってもよい。図２は、クライアント２０２が一連のユニキャストメッセージ２０４を潜在的なターゲットサービス２０６〜２１６に送信し得るユニキャストポーリングプロセスを示している。
【００２０】
あるいは、図３は、クライアント３０２がターゲットサービスを見つけるためにマルチキャストグループ３０４〜３１６にマルチキャスト発見要求を送信し得ることを示している。この状況では、クライアントがメッセージを送信してもよく、このメッセージは、受信側によって、ネットワーク全体にさらに伝播される。ターゲットサービス、たとえば３１０が応答すると、クライアント３０２は、経路３１８によって示されたユニキャストを介して、発見されたターゲット３１０と直接通信してもよい。
【００２１】
図４は、Ｗｅｂサービス動的発見（ＷＳ−Ｄｉｓｃｏｖｅｒｙ）プロトコルであり得るブロードキャストベース発見プロトコルを使用する一般的な発見プロセスを示している。他のブロードキャストベースのプロトコルもまた、同じ一般的なやり方で動作してもよい。ＷＳ−Ｄｉｓｃｏｖｅｒｙなど、発見プロトコルは、ネットワーク上のウェブサービスを見つけるための２つのポーリングタイプ操作、すなわちプローブおよび解決操作を定義してもよい。ターゲットサービス４２０は、マルチキャストプローブ４０４をいつでも受信し、ターゲットサービス４２０がプローブと一致する場合は、ユニキャストプローブマッチ（ＰＭ：ｐｒｏｂｅ  ｍａｔｃｈ）４０６を送信してもよい。プローブマッチは、サービスがクライアントのニーズに対処できることを示してもよい。一致する他のターゲットサービスもまた、ユニキャストＰＭ４０７を送信してもよい。その後、クライアントとサービスは、（たとえばユニキャストを介して）直接対話してもよい４１２。
【００２２】
名前でターゲットサービスを見つけるために、クライアント４４０は、同じマルチキャストグループに、解決要求４０８または解決メッセージを解決してもよい。ターゲットサービス４２０は、マルチキャスト解決４０８をいつでも受信し、それが解決のターゲットである場合は、ユニキャスト解決マッチ（ＲＭ：ｒｅｓｏｌｖｅ  Ｍａｔｃｈ）４１０または解決応答を送信してもよい。解決メッセージは、サービスを名前で見つけるときに使用されてもよい。サービスからの解決マッチは、クライアントがサービスを識別し、それと通信することができるように、アドレスおよび他の識別情報を含んでもよい。応答は、マルチキャストプローブメッセージおよび／または解決ではなく、ユニキャスト送信として直接送信されてもよい。マルチキャストを行わない他のブロードキャストベースプロトコルは、知られているノードへの一連のユニキャスト・ポーリング・メッセージを使用して発見を実施し、それによって、一致を求めて各ノードに別々にポーリングしてもよい（図２を参照）。
【００２３】
ポーリングは、多くのサービスおよび／または要求元を含むサブネットのかなりの帯域幅を消費することがある。図３に示されるように、単一のマルチキャストメッセージは、ネットワーク内のノード間で指数関数的に増加する伝送波で伝播され得る。より大きいサブネットでは、あまりにも多くの要求元がプローブおよび／または解決メッセージを同時に送信するとき、ブロードキャストストームが生じることがある。ストームは、メッセージ送達に非常に大きい遅延が生じ、またはメッセージパケットが衝突するときにメッセージ送達が行われないことにより、ネットワークの機能障害を引き起こすことがある。一部の発見プロトコルは、メッセージストームの機会を減らすための特定の機構を提供する。たとえば、一部の発見プロトコルは、通信の隙間を生じさせるためのメッセージ待機トリガを実装してもよい。この状況では、サービスは、他のサービスから要求または応答メッセージを検出した後、それ自体のメッセージを送信する前に、ある継続時間の間、待機するよう求められ、それによって、通信の隙間を生じさせてもよい。
【００２４】
さらに、ポーリングの必要性を最小限に抑えるために、発見プロトコルは、ターゲットサービスが、ネットワークに参加するとその存在について告げる告知をマルチキャストグループに送信することを可能にしてもよい。たとえば、サービスがネットワークに接続するとき、サービスは、Ｈｅｌｌｏメッセージ４０２を送信することによってその到着を告知してもよい。ある状況では、これらの告知は、マルチキャストプロトコルを使用してネットワークを介して送信されてもよい。告知を送信するこのプロセスによって、ネットワーク上のポーリングの必要性を減少させることができる。告知をリッスンすることによって、クライアントは、不必要なプロービングを行わずに、新たに使用可能なターゲットサービスを検出してもよい。たとえば、クライアント４４０が告知を受信するとき、クライアント４４０は、プローブマッチに類似の情報を含み得る告知を格納し、プローブを行わずに、その情報を使用して、知られているサービスに直接接続してもよい。また、ターゲットサービスがネットワークを離れるとき、ターゲットサービスは、マルチキャストＢｙｅ  ４１４を送信しようと努めてもよい。Ｂｙｅメッセージ４１４を受信するクライアント４４０は、それに応じてそのレコードを更新し、したがって現在使用不可能なサービスへの参照を取り除いてもよい。
【００２５】
サービス告知およびメッセージ待機トリガは、ネットワークトラフィックを減少させるのに役立ち得るが、大きいサブネットは、マルチキャストプローブおよび解決送信のせいで、ブロードキャストストームを依然として被ることがある。したがって、ネットワークトラフィック量を制限し、発見プロセスを最適化するために、図５に示されるように、一部の発見プロトコルは、発見プロキシをも実装する。ＷＳ−Ｄｉｓｃｏｖｅｒｙプロトコルは、一般的なホスト型プロキシ５０２、ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシをサポートしてもよく、このプロキシは、発見されたＷＳ−Ｄｉｓｃｏｖｅｒｙサービスのストア５０４を維持する。ストアは、プロキシ５０２によって受信されたＨｅｌｌｏおよびＢｙｅメッセージ５０６など、サービス告知に基づいて取込みが行われてもよい。次いで、ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシは、発見要求に直接応答してもよい５０８。
【００２６】
ホスト型プロキシが新しくインストールされる場合、クライアント５０１は、依然としてブロードキャストのみのモードで動作してもよい。この場合、クライアントは、マルチキャストプローブ５１０を依然として送信してもよい。しかし、ネットワーク規模のブロードキャスト解決メッセージを発見サービスに送信し続けるのではなく、ホストは、プロキシ５０２を認識すると、発見を実施するために、単にホスト型プロキシ５０２と対話してもよい。発見プロキシを使用する管理型ネットワークでは、クライアントが発見プロキシを認識すると、プローブが、ユニキャストで発見プロキシに送信されてもよい５０８。プロキシ５０２は、マルチキャスト発見要求が必要とされ得ないように発見情報を格納することによって、ネットワークトラフィックを減少させることができる。
【００２７】
図６は、発見プロキシを伴う一般的なＷＳ−Ｄｉｓｃｏｖｅｒｙ発見プロセスを示している。このモデルでは、ターゲットサービス６０２は、非プロキシ設定と同じ機能性を有し続け得る。換言すると、ターゲットサービスは、マルチキャストＨｅｌｌｏおよびＢｙｅ、解決およびプローブ、ならびにユニキャストＰＭおよびＲＭを伴う応答を送信可能であり得る。しかし、ターゲットサービスが発見プロキシに登録されると、発見プロキシは、プローブおよび解決メッセージへの応答を引き継ぐことができる。プロキシを使用すると、クライアント発見要求を、プロキシへのユニキャストメッセージへと有効に減少させることができる。ホスト型発見プロキシがインストールされる場合、発見プロキシは、発見されたサービスのストアを作成してもよく（図５を参照）、このストアを、Ｈｅｌｌｏマルチキャスト６１２をリッスンすることによって生成してもよい。同じようにで、ターゲットサービスがネットワークを離れ、または使用不可能になるとき、プロキシは、Ｂｙｅメッセージ６２６を受信するときにエントリを取り除いてもよい。あるいは、発見プロキシは、（たとえば管理者によって）ネットワークデバイスの現在のリストが事前に取り込まれてもよい。
【００２８】
発見プロキシもサービスと見なされ得るので、発見プロキシ６０４は、それ自体の特別のＨｅｌｌｏメッセージ６１４でその存在を告知してもよい。その後、このメッセージを受信するクライアント６０６は、プロキシのサービスを利用してもよく、クライアント６０６は、ネットワーク規模のプローブの送信をもはや要求され得ない。具体的には、発見プロキシが、マルチキャストによって送信されたプローブまたは解決要求を検出するとき、発見プロキシは、それ自体についてのＨｅｌｌｏ告知を送信してもよい。これらの告知をリッスンすることによって、クライアントは、発見プロキシを検出し、その振舞いを、発見プロキシを使用するように修正してもよい。さらに、ネットワークトラフィックは、ユニキャストＨｅｌｌｏ  ６１２およびＢｙｅ  ６２６を発見プロキシに直接送信するようにターゲットサービスに指示することによってさらに減少され得る。クライアントは、発見を実施するために、単にユニキャストプローブ６１６をプロキシ６０４に送信してもよい。次いで、プロキシ６０４は、ユニキャスト応答６１８を返送してもよい。同様に、クライアント６０６は、プロキシ６０４にユニキャスト解決６２０を送信してもよく、プロキシ６０４は、クライアント６０６がその後にサービス６０２との直接のリンクを確立し得るように、必要なサービス情報を付けて解決マッチ６２２を返してもよい。発見プロキシが応答せず、または別のやり方で使用不可能になる場合、図４に示されるように、クライアントは、標準のブロードキャスト解決プロセスの使用に戻ってもよい。
【００２９】
ＷＳ−Ｄｉｓｃｏｖｅｒｙなど、一部の発見プロトコルは、よく知られている動的ホスト構成プロトコル（ＤＨＣＰ：ｄｙｎａｍｉｃ  ｈｏｓｔ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）レコードの使用など、他の何らかの管理手段によって確立されている発見プロキシにプローブメッセージが送信され得る構成を可能にすることもできることに留意されたい。ＤＨＣＰ、ＤＮＳ、ドメインコントローラ、ディレクトリのような明示的ネットワーク管理サービスがインストールされ得るこれらの状況では、ＷＳ−Ｄｉｓｃｏｖｅｒｙ仕様は、クライアントおよび／またはターゲットサービスがそれぞれ異なるやり方で振る舞うように構成され得る状況を提供することができる。たとえば、仕様は、発見プロキシのアドレスを含むＤＨＣＰレコードを定義してもよく、その仕様に従うと、ネットワークエンティティは、送信メッセージをマルチキャストグループにではなく、この発見プロキシに送信するように求められ得る。
【００３０】
ブロードキャストベースの発見プロトコルでは、高価なリソース消費を被ることがある。このモデルでは、ポーリングおよび／または解決要求がマルチキャストで送信されたか、それともユニキャストで送信されたかにかかわらず、複数のネットワークエンティティが、解決要求を処理するように求められ得る。たとえば、サービスがプローブに応答してプローブマッチを送信することを求められ得ないとしても、サービスは、応答すべきかどうか判断するために、受信されたプローブを依然として処理しなければならないことがある。この処理は、ネットワーク上の各デバイスへのＣＰＵ割当てを必要とし得る。この通信はネットワーク帯域幅をも減少させ、装置の数が増加するにつれて、メッセージ衝突が頻繁に発生することがある。あまりにも多くのデバイスがネットワーク上にあり、それらすべてが発見プロセスを同時に実行する必要があるとき、ブロードキャストストームの危険も存在し得る。
【００３１】
発見プロキシの実装によってネットワークトラフィックが減少され得るが、発見プロキシの使用は、コストも伴い得る。たとえば、発見プロキシは一般に、プロキシをホストするために、サーバまたは専用デバイスを必要とすることがある。２つ以上のサブネットを有する企業ネットワークでは、それぞれのサブネットについて、別個のサーバ／プロキシが必要であり得る。あるいは、複数のサブネット間でサーバプロキシを共有するには、複雑なネットワーク構成が必要とされ得る。さらに、プロキシ使用に付随して管理コストが生じ得る。たとえば、プロキシサーバを構成し維持するために、管理者が必要であり得る。したがって、直接のブロードキャスト解決プロセスの使用と、プロキシサーバの使用の間には、ネットワーク効率と管理業務の間のトレードオフが存在する。
【００３２】
図７は、アドホックプロキシまたは仮想プロキシの一般的なシステム実施形態を示している。仮想プロキシは、共通のオーバーレイプロトコル（破線７１０を使用して示される）の下で動作し、共有データストア７１２を使用する１組のホスト７０２〜７０８から構築されてもよい。１組のホスト７０２〜７０８は、ホストのサブネットワーク７０１を形成してもよく、これらのホストは、共通のオーバーレイプロトコル７１０を介して互いに通信して、発見情報の共有データストアを維持し、サブネットワークに参加することができないレガシーエンティティ７２０〜７２６と、仮想プロキシを形成するサブネットワークの一部であるエンティティ７０２〜７０８との両方にプロキシサービスを提供することが可能であり得る。仮想プロキシは、複数のホストエンティティで構成され得るとしても、既存の発見プロトコル７４０を使用して発見プロキシサービスを提供してもよい。１組のホスト７０２〜７０８は、仮想プロキシと見なされてもよく、あるいはサブネットワークのホスト（７０２、７０４、７０６または７０８）の各ホストは、プロキシのそれぞれが、サブネットワークの他のいずれかのホストと同じように発見プロキシとして働くことが可能であり得るので、仮想プロキシと見なされてもよい。換言すると、ネットワーク上のクライアント（たとえば７３２）にとって、サブネットワークのどの仮想プロキシホストも、各仮想プロキシホストが同じ共有データストア７１２を使用するので、同じ仮想プロキシのように見え得る。
【００３３】
仮想プロキシは、いずれかのクライアント発見要求のための単一の一般的な発見プロキシとして働いてもよい。一実施形態では、仮想ホストは、発見要求に応えるために使用される発見プロトコルと異なるオーバーレイプロトコルを介して通信してもよい。仮想ホストは、共有データストアを作成し維持するのに必要なデータを通信するための第１のプロトコル、および発見のための第２のプロトコルを使用してもよい。一実施形態では、発見プロトコルは、ＷＳ−Ｄｉｓｃｏｖｅｒｙプロトコルや簡易サービス発見プロトコル（ＳＳＤＰ）など、既存の発見プロトコルであってもよく、オーバーレイプロトコルは、（以下にさらに論じられる）ホスト群の間で共有データストアを維持することができ得るピアツーピアオーバーレイネットワークまたは他のプロトコルであってもよい。
【００３４】
知られている、または以前に発見されたサービスおよび／またはデバイスのレコード、ならびに対応するアクセス情報を維持するために、共有データストアが、仮想プロキシホストのサブネットによって使用されてもよい。共有データストアは、ピアツーピアグラフによって維持された分散データストアであっても、一般的なオペレーティングシステムによって提供されたファイル複製サービス（ＦＲＳ：ｆｉｌｅ  ｒｅｐｌｉｃａｔｉｏｎ  ｓｅｒｖｉｃｅ）を使用して、ネットワーク化されたデバイス群によって維持された複製データストアであってもよい。ＦＲＳを操作するデバイスのネットワークに参加するホストは、分散データストアのコピーを自動的に取り出してもよく、この分散データストでは、コピーのいずれに対する変更も、ＦＲＳによって維持された他のコピーに伝播され得る。ファイル複製サービスは、発見プロトコルとは異なるプロトコルを使用して通信してもよい。
【００３５】
ピアツーピアグラフは、相互接続された１組のノードを表し得る。ピアツーピアグラフが分散データストアを維持する場合、それぞれのピアエンティティは、共有データストアの一部だけを格納し維持することができ、そこから、分散データストアという用語が生じている。一実施形態では、ピアツーピアグラフの分散データストアは、ハッシュ関数を使用して、ピアのグループ間で分割されてもよい。図８は、一実施形態で使用され得る一般的な分散ハッシュテーブル（ＤＨＴ：ｄｉｓｔｒｉｂｕｔｅｄ  ｈａｓｈ  ｔａｂｌｅ）を示している。分散ハッシュテーブル８００は、ピアツーピアネットワーク４０５を形成するピアエンティティ８０１〜８０４のグループにわたって維持されてもよい。この実施形態では、ピアツーピアネットワークは、仮想プロキシを形成してもよい。分散ハッシュテーブル内のエントリは、たとえばハッシュ関数を使用して、論理的に分割され、またはグループ化されてもよい。ハッシュ関数は、組織的な何らかのやり方でレコードをひとまとめにしてもよく、それによって、取出しの効率が高まる。ＤＨＴは、２つの主要な特性、１）複数のノード（たとえばノード４０１〜４０４）間のテーブル（たとえばテーブル４００）の分散、および２）レコードを公開し、取り出すための方法を提供するルーティング機構（図示せず）を有し得る。ルーティング機構および分散は、Ｃｈｏｒｄ、Ｐａｓｔｒｙ、ＰＮＲＰ、Ｔａｐｅｓｔｒｙなどのオーバーレイプロトコルによって管理されてもよい。
【００３６】
図９は、仮想ホストが、以下の動作の実施によって特徴付けられ得ることを示している：共有データストアを取得し、１組のピアと同期させること９０２、グラフ内の他の仮想プロキシホストへの１組の接続を維持すること９０４、発見クエリを受信すると、それがプロキシであると応答すること９０６、共有データストアにレコードを公開し、またはそこからレコードを削除することによって、サービス告知を処理すること９０８、および分散データストア内の探索によって発見クエリを処理し、応答を返すこと９１０。
【００３７】
図１０は、ネットワーク発見プロトコルとしてＷＳ−Ｄｉｓｃｏｖｅｒｙ、共有データストアとして複製データストア１００２を使用する一実施形態を示している。仮想ホストは、共通の複製データストア１００２を維持するために、ファイル複製サービスを使用して動作してもよい。仮想ホストは、他のネットワークエンティティとの１組の接続を維持する責任を担い得る。仮想プロキシホストがプロキシの問合せを受信するとき、仮想プロキシは、それがプロキシ１００４であると応答してもよい。仮想プロキシ１０００が告知１００６を受信するとき、仮想プロキシ１０００は、（Ｈｅｌｌｏメッセージについては）複製データストア１００２にレコードを公開し、（Ｂｙｅメッセージについては）レコードを削除してもよい。一実施形態では、データストアレコードは、新しい告知１００６を受信することによりリフレッシュされない限り、終了してもよい。仮想プロキシホストが問合せ要求１００８を受信する場合、プロキシは、グラフデータストアを探索し、それに応じて応答してもよい。
【００３８】
図７に示されるように、ネットワーク内に、仮想プロキシを実装する２つのタイプのネットワークエンティティが存在し得る：仮想プロキシホスト７０２〜７０８を認識することがあり、仮想プロキシホストになることができるネットワークエンティティ、および仮想プロキシホストを認識しないことがあり、仮想プロキシホストになることができないネットワークエンティティ、たとえばレガシーデバイス７２０〜７３６。レガシーデバイスは、一般的なプロキシを探索するためのプローブを送信するように、上記と同様に動作してもよい。ネットワークが仮想プロキシを実装する場合、仮想プロキシは、その発見サービスがレガシーデバイスによって使用されてもよいプロキシであると告げてもよい。このように、仮想プロキシホストと同様に、レガシークライアントも、仮想プロキシシステムによるサービスを受けてもよい。既存の発見プロトコルによって定義された通常のホスト型プロキシも、仮想プロキシの代わりに使用されてもよい。
【００３９】
図１１は、仮想プロキシを実装することができるネットワークにホストが参加するための一プロセス実施形態を示している。ホストは、ブートするとき、標準発見プロトコル、たとえばＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシによって定義された発見プロキシが存在するかどうか判断するために、問合せを１１０２を発行してもよい。これは、問合せまたはポーリングを介して行われてもよい（このプロセスは、プロキシ情報がたとえばＤＨＣＰ応答またはＤＮＳ問合せなど、他の手段によって使用可能である場合はスキップされてもよいことに留意されたい）。標準ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシが応答し、または使用可能である場合１１０４、その後、ホストは、プロキシを使用してもよい１１０６。この実施形態では、ホスト型ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシが、仮想プロキシよりも優先してもよい。この１つの理由は、そのネットワーク上のデバイスが仮想プロキシを実装できるかどうか管理者が知っていると見なされてもよく、またＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシを手動で実装することが、管理者が仮想プロキシよりも手動プロキシを使用することを意図的に選んでいることを示し得るからであり得る。
【００４０】
ＷＳ−Ｄｉｓｃｏｖｅｒｙプロキシが使用可能でない場合は、アドホック／仮想プロキシホストが使用可能であるかどうか判断するためにチェックが行われてもよい１１０８。（このチェック１１０８は、初期プロキシ問合せ１１０２中に得られたデータに基づいて実施されてもよく、あるいは、それは、第２のネットワーク問合せを必要とし得ることに留意されたい。）仮想プロキシホストが存在する場合は、新しいホストは、プロキシ１１１４を使用してもよい。さらに、ホストは、仮想プロキシホスト１１１０となることができる場合は、仮想プロキシグラフ１１１２に参加してもよい。仮想プロキシホストを接続するプロセスは、ブートストラッピングと呼ばれることがあり、新しいホストがネットワークに参加するときはいつでも、１組の仮想プロキシピアが既存のグラフに基づく。一実施形態では、ブートストラッピングプロセスは、基礎となるプロトコルによって容易にされる動的プロセスであり得る。基礎プロトコルを使用して、プロキシホストの集まりは、発見サービスを堅牢なホスト群に合わせてスケーリングするために互いにリンクされてもよく、ブロードキャスト・トラフィックを減少させながら、多くのクライアントにサービスする容量が提供される。
【００４１】
既存の仮想プロキシが存在しない場合は、ホストが仮想プロキシホストとなることが可能かどうか判断するためのチェックが行われてもよい１１１６。ホストは、仮想プロキシホストを形成することができる場合は、共有可能なデータストアを作成し、１つのホストの新しいグラフを作成し、それが仮想プロキシであると告知することによって、仮想プロキシサービスを開始してもよい１１１８。その後、仮想プロキシホストは、発見サービスレコードを生成するために告知を記録してもよく、その後、仮想ホストとして、将来の発見要求に応じてもよい。ホストは、仮想プロキシホストになることができない場合は、上記と同様に、標準ブロードキャストポーリングを使用してもよい１１２０。ホストは、将来ネットワークから使用できるようになり得るどんなプロキシをも発見することを求める要求を周期的に発行してもよい。
【００４２】
一実施形態では、仮想プロキシが確立される場合は、仮想プロキシホストは、ホスト型ＷＳ−Ｄｉｓｃｏｖｅｒｙが実装されているかどうか判断するために周期的にチェックしてもよい。こうしたホスト型プロキシが実装される場合は、仮想プロキシホストは、仮想プロキシとして実施することを止めてもよい。これは、グラフを分解し、共有データストアを削除することを伴い得る。この場合も、これは、手動で作成されたホスト型発見プロキシを、仮想プロキシよりも優先することを保証するように実施されてもよい。
【００４３】
新しいホストは、既存のプロキシが仮想プロキシかどうか複数のやり方で判断してもよい。一実施形態では、仮想プロキシは、それが仮想プロキシホストであることを示すために、プローブや解決マッチなどの発見応答にフラグまたは他の情報を含めてもよい。仮想プロキシホストになることができる新しいホストは、このフラグを捜し、そのフラグを検出すると、それに応じて振る舞ってもよい。たとえば、仮想プロキシになることができるホストは、ネットワークに参加し、それ自体のグラフを作成する前のある期間の間、プロキシホストとしては非アクティブであってもよい。それは、既存のプロキシホストからプローブマッチを受信すると、次いで、既存の仮想プロキシグラフに参加するプロセスを開始してもよい。
【００４４】
別の実施形態では、仮想プロキシになることができるホストは、プロキシが存在することを示すネットワークから、発見応答または告知を受信してもよい。応答を送信したプロキシが標準ホスト型プロキシであるか、それとも仮想プロキシであるか判断するために、新しいホストは、プロキシに問い合わせてもよい。たとえば、新しいホストは、発見応答または告知を介してプロキシについて知ると、プロキシに問い合わせてもよい。プロキシが仮想プロキシである場合は、仮想プロキシは適切に応答し、新しいホストは、応答を受信すると、既存の仮想プロキシグラフに参加してもよい。分散データストアが共有データストアとして使用される実施形態では、オーバーレイプロトコルを使用して通信可能であるホストは、オーバーレイプロトコルの機能性を使用して、仮想プロキシが存在するかどうか判断してもよい。たとえば、ピアツーピアネットワークでは、ピア名前解決プロトコルが、新しいホストによって、仮想ホストが存在するかどうか判断するために使用されてもよい。この通信は、発見プロトコルの外部で行われてもよい。このプロセスの一実施形態では、オーバーレイ解決手法は、問合せプロセスに先行してもよい。一実施形態では、新しいホストは、仮想プロキシを決定するために、まずＰＮＲＰの使用を試み、次いで、ＰＮＲＰの試みが失敗する場合は、プロキシに問い合わせてもよい。
【００４５】
仮想プロキシサブネットワークは、セキュリティ規定を実装してもよい。たとえば、一実施形態では、仮想プロキシサブネットワークは、新しいホストが仮想プロキシグラフに参加可能となる前に、認証を要求してもよい。これは、プロキシグラフに参加可能などんなホストもが参加することを許される非セキュリティ保護仮想プロキシに対して、セキュリティ保護された仮想プロキシと呼ばれることがある。
【００４６】
ネットワーク内に２つ以上の仮想プロキシホストがある場合は、プロキシサービスを提供するために、仮想プロキシホスト間で何らかの調整が必要であり得る。プローブが仮想ホストサブネットによって受信される場合は、プローブは、複数のやり方で対処されてもよい。一実施形態では、使用可能な２つ以上のプロキシホストがある場合は、既存の仮想のプロキシホストはそれぞれ、時間切れまたは時間遅延を用いてプローブに応答してもよい。これは、メッセージ重複または衝突の可能性を減少させるのに役立ち得る。このプロセスは、クライアントが２つ以上のプロキシ間で選択することを許され得る場合に使用されてもよい。別の実施形態では、バックオフ・プロセスが実施されてもよい。この場合、プローブを最初に受信する仮想ホストが応答を送信してもよく、ネットワーク内の他の仮想ホストは、応答の送信を控えてもよい。この場合、第１の仮想ホストが、クライアントにサービスしてもよい。別の実施形態では、ネットワーク内に２つ以上の仮想ホストが存在する場合は、選出プロセスが実施されてもよく、このプロセスでは、ある仮想ホストが、すべての発見要求に応答する１次ホストに指定される。
【００４７】
別の実施形態では、どの仮想ホストが特定の発見要求に応答するか決定することは、データシェア内のレコード分散に基づいてもよい。これは、分散データストアが共有データストアとして使用される一実施形態において適用可能であり得る。上記に論じられたように、ＤＨＴなど、分散データストアは、レコードを、ＤＨＴを維持するピア間で分散してもよい。一実施形態では、仮想プロキシホストが応答するかどうかは、仮想プロキシホストが責任を担っているかどうか、それともプローブに応答するのに必要な解決情報を格納するかどうかに基づいてもよい。したがって、この実施形態では、発見要求を解決するためのレコードを含む仮想プロキシホストが、応答するように指定されてもよい。この指定は、発見プロトコルの外部で（たとえばオーバーレイプロトコルを使用して）実施されてもよい。レコードの分散が、それを分散するために使用される関数、たとえばハッシュ関数に対応し得るので、発見要求を適切なホストノードに向けるために、ハッシュ関数が使用されてもよい。これは、発見プロトコルを介して行われてもよい。たとえば、ユニキャスト発見要求を最初に受信する仮想ホストが、適切なノードを決定し、ユニキャスト発見要求を適切なノードに再送してもよく、次いで、適切なノードが、要求に応答する。
【００４８】
別の実施形態では、仮想プロキシホストは、共有データストアに関連付けられており、ストア内のレコードにアクセス可能である限り、プローブに応答してもよい。この状況では、仮想プロキシホストは、仮想ホストが必要なデータ部分を格納するかどうかにかかわらず、メッセージを解決するのに必要なデータを共有データストア内で見つける責任を担ってもよい。こうした場合では、仮想プロキシホストは、発見プロトコルではなく、オーバーレイプロトコルを使用して、別の仮想のプロキシホストと通信してもよい。たとえば、仮想プロキシホストは、ピアツーピアネットワークプロトコル介してデータの一部を格納し得る別の仮想プロキシホストと通信してもよい。
【００４９】
特許請求された方法およびシステムは、プロキシを構成し維持する負担を、管理者によって維持された専用サーバから、発見されたサービスのストアを分散し共有する１組の仮想プロキシホストへと移す。仮想プロキシホストは、共有データストアを形成し、共有データストアを使用してクライアントにサービスすることができる少なくとも１つのホストを取り入れることによって動的に作成されてもよい。これらの仮想プロキシホストは、オーバーレイプロトコルまたは複製サービスに含まれる機能性によって実装され得るので、専用サーバ、または管理者の監視を必要としないことがある。ますます多くの仮想のプロキシホストがネットワークに参加するにつれて、プロキシホストは、より堅牢なプロキシサービスを形成するために次々にブートストラップしてもよい。さらに、サブネットは、ネットワーク内に複数のエンドポイントを有することがあるので、クライアントは、隣接またはより近いノードによってより効率的にサービスされ得る。
【００５０】
レガシークライアントが、仮想プロキシホストを実装するネットワークの一部である場合は、クライアントは、マルチキャスト発見要求を送信する必要がなく、その代わりに、最も近くの仮想プロキシホストへのそのアクセスを利用する。レガシークライアントは、仮想ホストサブネットワークを標準発見ホストと見なし、仮想ホストが標準ホスト型発見プロキシであるかのように、複数の仮想ホストのうちの１つと対話してもよい。クライアントが仮想プロキシホストである場合は、クライアントは、プローブのために発見プロトコルを使用する必要がないことがある。クライアントは、サービスアドレスを取得するために、単に共有データストアにアクセスしてもよい。したがって、本明細書に述べたように仮想プロキシホストを使用することによって、システムは、管理コストを減少させながら、ネットワークトラフィックを減少させることができ得る。
【図面の簡単な説明】
【００５１】
【図１】特許請求の範囲に従って動作し得るコンピューティングシステムのブロック図である。
【図２】ユニキャストポーリングプロセスを示す図である。
【図３】マルチキャストポーリングプロセスを示す図である。
【図４】ブロードキャストベース発見プロトコルを使用する一般的な発見プロセスを示す図である。
【図５】発見プロキシを使用する一般的なブロードキャストベース発見システムを示す図である。
【図６】発見プロキシを伴う一般的なＷＳ−Ｄｉｓｃｏｖｅｒｙ発見プロセスを示す図である。
【図７】アドホックプロキシまたは仮想プロキシの一般的なシステム実施形態を示す図である。
【図８】一実施形態で使用され得る一般的な分散ハッシュテーブル（ＤＨＴ）を示す図である。
【図９】仮想ホスト特性を示す図である。
【図１０】ネットワーク発見プロトコルとしてＷＳ−Ｄｉｓｃｏｖｅｒｙ、および共有データストアとして複製データストア１００２を使用する一実施形態を示す図である。
【図１１】仮想プロキシを実装することができるネットワークに参加するホストのプロセス実施形態を示す図である。
【図１】
2009534939.tif 000003
【図２】
2009534939.tif 000004
【図３】
2009534939.tif 000005
【図４】
2009534939.tif 000006
【図５】
2009534939.tif 000007
【図６】
2009534939.tif 000008
【図７】
2009534939.tif 000009
【図８】
2009534939.tif 000010
【図９】
2009534939.tif 000011
【図１０】
2009534939.tif 000012
【図１１】
2009534939.tif 000013
【国際調査報告】
2009534939.tif 000014
2009534939.tif 000015