ピアツーピアグラフ管理インタフェースおよび方法
【課題】ピアツーピア（Ｐ２Ｐ）ネットワーク内でグラフ管理を提供するアプリケーションプログラミングインターフェースおよび方法を提供すること。
【解決手段】より具体的には、グラフの作成およびアクセス、ノードおよびグラフ情報の取出し、レコード（データ）の追加、修正、削除、管理、グラフデータのインポートおよびエクスポート、グラフノード間の直接通信、グラフへのセキュリティプロバイダの追加、存在情報の設定および取出し、イベント通知への登録、および他のユーティリティ／サポート機能のための新規な、また改善されたＰ２Ｐアプリケーションプログラミングインターフェース（ＡＰＩ）および方法が提供される。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、機能の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【解決手段】より具体的には、グラフの作成およびアクセス、ノードおよびグラフ情報の取出し、レコード（データ）の追加、修正、削除、管理、グラフデータのインポートおよびエクスポート、グラフノード間の直接通信、グラフへのセキュリティプロバイダの追加、存在情報の設定および取出し、イベント通知への登録、および他のユーティリティ／サポート機能のための新規な、また改善されたＰ２Ｐアプリケーションプログラミングインターフェース（ＡＰＩ）および方法が提供される。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、機能の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にピアツーピア環境内でのグラフおよびデータレコード管理に関し、より詳細には、ピアツーピアのグラフ作成および管理のためのアプリケーションプログラミングインターフェースおよび方法、ならびに、ピアツーピアのグラフ内でのレコード（データ）およびノードの管理に関する。
【背景技術】
【０００２】
インターネットに関するさまざまな通信技術によって、共通の関心を有する諸ユーザが、共同作業し、ファイルを共有し、互いにチャットし、プレゼンテーションやグループ会議のためにオーディオやビデオをマルチキャストし、複数競技者のゲームに参加することが可能になっている。しかし、現在、インターネット上のほとんどの通信は、サーバ中心の環境内で行われ、それによって通信はすべて大規模な中央サーバに流れ込み、あるいはこれを介して流通するのであり、個人はそのような通信に加入し参加するためにこのようなサーバに接続することができる。
【０００３】
ピアツーピア技術が再出現したため、インターネット通信の現行のサーバ中心型モデルは、急速に置き換えられつつある。実際、ピアツーピア技術は、サーバをベースとするインターネット通信の制約から解放されて、サーバのない環境でユーザが互いに接続することを可能にする。ピアツーピアをベースとするシステムでは、通信がネットワーク内のピア間で直接行われるため、ユーザの匿名性およびプライバシーを維持することができる。しかし、ピアツーピアネットワーク内では、個々の通信およびファイル共有は比較的よく確立されているが、ピアツーピア環境内での情報の確立、獲得、接続、維持、共有については十分とはいえない。
【０００４】
ピアツーピア通信や実際すべてのタイプの通信は、選択されたエンティティ間またはノード間で有効な通信が確立されるか否かによってその成否が左右される。ピアツーピアネットワーク内で形成されたピア（たとえば、ユーザまたはマシン）またはグループをこれらのエンティティまたはノードとすることができる。ノード間の接続によってピアツーピアのグラフを形成されるが、これにより通信および情報をノードへ渡し、またはノード間で渡すことが可能となる。しかし、エンティティは、ネットワーク内のエンティティの移動、トポロジの変化、アドレス貸し出しの更新ができないこと、並びにグループの機能または目的の変化などのために変わる可能性のある１つまたはいくつかのアドレスを有することがある。したがって、従来のアーキテクチャにおいては、このアドレスに関する問題に対し、各エンティティに安定した名前を割り当てること、および接続が必要とされるとき、この名前を「解決」して現在のアドレスにすることにより解決を図っている。この名前−アドレス変換は、非常に確固としたものでなければならず、また容易かつ高速な更新を可能にするものでなければならない。
【０００５】
エンティティのアドレスが、接続を試みるエンティティによって見つけられる尤度を高めるために、多数のピアツーピアプロトコルにおいて、さまざまな機構を介することによってエンティティがその個々のアドレスまたはグループアドレスを公表することが可能になっている。また、いくつかのプロトコルにおいては、ネットワーク内の他者からの要求を処理することにより、クライアントが他のエンティティのアドレスの知識を得ることが可能になっている。実際、このアドレス知識の獲得により、確固たるグラフを維持することによってこれらのピアツーピアネットワークを動作させるのに成功する。すなわち、ネットワーク内の他のピアおよびグループに関する情報が優れているほど（すなわち、グラフがより確固たるものであるほど）、特定の資源またはレコードの探索が集中する尤度が高くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
サーバ中心の環境の場合と同様に、ピアツーピアのグラフは、グラフ内でインターネットファイルの探索および共有を可能にするために完全に開放することができる。しかし、ピアツーピアネットワークは、分散されたユーザまたはピアのグラフとして形成されるため、ネットワーク内のピアすべてが共有情報を知ることができるようになる前に、通信またはデータ（レコード）をあるピアから別のピアに渡すことが必要である。そのような経路設定を提供するシステムとしては、ＵｓｅｎｅｔおよびＯＳＰＦがある。しかし、そのような現行のシステムには、現在までのところ限界があり、ピアツーピア技術の発展と完成を制限している。さらに、ピアツーピアネットワークは、現在、適切なグラフ管理を欠いており、メンバの１つがグループを離れても、断続的にグラフを「分断」または分割することができない。そのような場合には、もはやグラフの一方からの情報を、１つピアの離脱によって生み出されたのと反対の側のピアメンバに渡すことができない。他の欠点は、そのような分離を検出するための適切な機構が存在しないことである。
【０００７】
したがって、当技術分野では、当技術分野に存在する上述の、および他の問題に対処するピアツーピアのグラフおよびレコードを管理するインターフェースが求められている。
【課題を解決するための手段】
【０００８】
本願に開示されている本発明の概念は、ピアツーピア（Ｐ２Ｐ）ネットワーク内でのグラフ管理のための新規な、また改善されたシステムおよび方法を含む。より具体的には、本発明は、グラフの作成およびアクセス、ノードおよびグラフ情報の取出し、レコード（データ）の追加、修正、削除、管理、グラフデータのインポートおよびエクスポート、グラフのノード間の直接通信、グラフへのセキュリティプロバイダの追加、存在情報の設定および取出し、イベント通知への登録、および他のユーティリティ／サポート機能のための新規な、または改善されたＰ２Ｐアプリケーションプログラミングインターフェース（ＡＰＩ）および方法を目的とする。
【０００９】
本発明の一実施形態においては、ピアツーピアグラフを確立するために、またはピア間でデータを効率的かつ確実に渡すために、ＡＰＩおよび方法がアプリケーション作成者に公開される。グラフ処理の基本構造は、各ノードが、グラフ内のデータの一貫したビューを確実に持つようにする。グラフ処理技術の中核部分（ｃｏｒｅ ｐｉｅｃｅ）は、グラフノードである。ノードは、ネットワーク上の個人の特定のインスタンスを示す。ノードは互いに接続することができ、ノードのネットワークまたはグラフを形成する。ノードは、レコードの形態で相互にデータを送信することができる。
【００１０】
レコードは、本質的に、グラフ内のノードすべてに押し流される（送信される）データ群である。レコードがノードによって受信された後で、ノードは、そのレコードをデータベースまたはデータ記憶内に配置する。グラフ処理は、各ノードのデータベースがまったく同じデータのビューを確実に有するようにする責任を負う。グラフ処理は、各ノードを同期させておく。ノードが接続し、またグラフから切断されたとき、グラフ内で分離または「分割」が発生する可能性がある。グラフ処理はまた、これらの分離を検出し修復する責任を負う。グラフ内のノードは、望まれれば、従来のグラフ接続とは別個の接続を作成することができる。これらの直接接続は、ノードが任意のデータを互いに送信することを可能にする。最後に、グラフ処理は、アプリケーションがイベント通知を登録し、また受信することを可能にするイベンティングインフラストラクチャを有する。イベント通知は、グラフ処理が使用し、グラフ内で変化が発生した場合アプリケーションに警告する機構である。
【００１１】
本発明の一実施形態においては、グラフ作成／アクセス管理を提供するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。ＡＰＩは、新しいグラフを作成し、接続のために既存のグラフを開き、接続のためにアクセスされる特定のポートを開き、指定されたＩＰアドレスでアクセスされるポートへの接続を開始し、開発者がグラフ用のセキュリティプロバイダを指定することを可能にし、セキュリティのないレコードをグラフに追加し、グラフ内のセキュリティのないレコードを更新し、セキュリティのないレコードをグラフから削除する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。これらのインターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、これらのインターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１２】
本発明の他の実施形態においては、グラフ／ノード情報を取り出し、管理するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、ノード情報を取得し、ノード属性を設定し、グラフプロパティを取得し、グラフ状況を取得し、グラフプロパティを設定し、現在のグラフ時間をローカルシステム時間に変換する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１３】
本発明の他の実施形態においては、レコード管理を実現するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、レコードを追加し、レコードを更新し、レコードを削除し、レコードを取り出し、レコードを列挙（ｅｎｕｍｅｒａｔｅ）し、レコードを探索し、期間を延長したレコードの妥当性検査を行う。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１４】
本発明の他の実施形態においては、ノードがそのデータベースをエクスポートし、別のノードからデータベースをインポートすることを可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１５】
本発明の他の実施形態においては、ノードがグラフ内のノードすべてを列挙することを可能にし、ノードがその存在をグラフ内に設定することを可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１６】
本発明の他の実施形態においては、ユーティリティ／サポート関数を提供するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、一覧内の次の項目を取り出し、列挙を終了し、項目数を取得し、他のＡＰＩによって取り出されたデータを解放する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１７】
本発明の他の実施形態においては、ピア間の直接通信を可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、直接通信を開き、直接通信を閉じ、データを送信し、ノードに接続を列挙する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１８】
本発明の他の実施形態においては、イベントインフラストラクチャを提供するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、イベント通知に登録し、イベントを登録抹消し、イベントデータを取り出す。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１９】
本明細書に組み込まれ、本明細書の一部を形成する添付の図面は、本発明のいくつかの態様を示し、説明と共に本発明の原理を説明するのに有効である。
【００２０】
本発明について、いくつかの好ましい実施形態と共に述べることになるが、本発明をこれらの実施形態に限定する意図はない。反対に、添付の特許請求の範囲によって定義される本発明の精神および範囲内に含まれる代替の実施形態、変更される実施形態、および等価な形態のすべてを包含するものとする。
【図面の簡単な説明】
【００２１】
【図１】本発明が常駐する例示的なコンピュータシステムを一般的に示すブロック図である。
【図２】本発明のシステムおよび方法が特に適用されるピアツーピア（Ｐ２Ｐ）インターフェースフレームワークを示す簡略化されたフレームワーク図である。
【発明を実施するための形態】
【００２２】
同じ参照番号は同じ要素を指す図面を参照して、好適なコンピューティング環境内で実施されるように本発明を示す。必ずしも必要ではないが、本発明については、パーソナルコンピュータによって実行されるプログラムモジュールなど、コンピュータ実行可能命令の一般的な文脈で説明を行う。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、当業者なら、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサをベースとする家電またはプログラム可能な家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成と共に本発明を実施することができることを理解するであろう。本発明はまた、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散コンピューティング環境内で実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルと遠隔双方のメモリ記憶デバイス内に配置することができる。
【００２３】
図１は、本発明を実施することができる好適なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も暗示しないものとする。コンピューティング環境１００は、例示的な動作環境１００に示されている構成要素のいずれか１つまたは組合せに関してどんな依存性も要件も有すると解釈すべきでない。
【００２４】
本発明は、多数の他の汎用または専用コンピューティングシステム環境または構成と共に動作可能である。本発明と共に使用するのに適している可能性のある周知のコンピューティングシステム、環境、および／または構成の例には、それだけには限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサをベースとするシステム、セットトップボックス、プログラム可能な家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。
【００２５】
本発明について、コンピュータによって実行される、プログラムモジュールなどコンピュータ実行可能命令の全体的な状況で述べることができる。一般に、プログラムモジュールは、特定のタスクを実行する、あるいは特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散コンピューティング環境内で実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含むローカルと遠隔双方のコンピュータ記憶媒体内に位置する可能性がある。
【００２６】
図１を参照すると、本発明を実施するための例示的なシステムが、コンピュータ１１０の形態で汎用コンピューティングデバイスを含む。コンピュータ１１０の構成要素には、それだけには限らないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含むさまざまなシステム構成要素を処理装置１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺機器バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含むいくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例を挙げると、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｅ）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００２７】
コンピュータ１１０は、一般に、さまざまなコンピュータ読取可能な媒体を含む。コンピュータ読取可能な媒体は、コンピュータ１１０によってアクセスすることができる任意の入手可能な媒体とすることができ、揮発性媒体と不揮発性媒体、取外し可能なおよび固定の媒体を共に含む。限定ではなく例を挙げると、コンピュータ読取可能な媒体は、コンピュータ記憶媒体と通信媒体を含む。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性と不揮発性、取外し可能なおよび固定の媒体が共に含まれる。コンピュータ記憶媒体には、それだけには限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用することができ、コンピュータ１１０によってアクセスすることができる他の任意の媒体が含まれる。通信媒体は、一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の移送機構など変調データ信号に統合し、任意の情報送達媒体を含む。「変調データ信号」という用語は、情報を信号に符号化するようにその特性の１つまたは複数が設定された、または変化した信号を意味する。限定ではなく例を挙げると、通信媒体は、有線ネットワークまたは直接配線接続など有線媒体と、音響、ＲＦ、赤外線および他の無線媒体など無線媒体とを含む。上記のいずれかの組合せもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。
【００２８】
システムメモリ１３０は、読出し専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２など揮発性および／または不揮発性メモリの形態でコンピュータ記憶媒体を含む。起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は、一般にＲＯＭ１３１内に記憶されている。一般にＲＡＭ１３２は、処理装置１２０によって直ちにアクセス可能な、かつ／または現在動作されているデータおよび／またはプログラムモジュールを含む。限定ではなく例を挙げると、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７を示す。
【００２９】
コンピュータ１１０はまた、他の取外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体を含むことができる。例にすぎないが、図１は、固定の不揮発性磁気媒体との間で読出しまたは書込みをするハードディスクドライブ１４０、取外し可能な不揮発性磁気ディスク１５２との間で読出しまたは書込みをする磁気ディスクドライブ１５１、ＣＤ ＲＯＭまたは他の光媒体など取外し可能な不揮発性光ディスク１５６との間で読出しまたは書込みをする光ディスクドライブ１５５を示す。例示的な動作環境内で使用することができる他の取外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。一般にハードディスクドライブ１４１は、インターフェース１４０など固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、一般に、インターフェース１５０など取外し可能なメモリインターフェースによってシステムバス１２１に接続されている。
【００３０】
上記で論じ、図１に示されたドライブとその関連コンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータを記憶する。たとえば、図１では、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７を記憶して示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７と同じであることも異なっていることもできることに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７は、最低でも異なるコピーであることを示すために異なる番号が与えられている。ユーザは、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１など、入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含むことができる。これらの、また他の入力デバイスは、システムバスに結合されるユーザ入力インターフェース１６０を介して処理装置１２０に接続されることがしばしばであるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他のタイプのディスプレイデバイスもまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７やプリンタ１９６など他の周辺出力デバイスを含むことができ、これらは、出力周辺機器インターフェース１９５を介して接続することができる。
【００３１】
コンピュータ１１０は、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータに対する論理接続を使用してネットワーク環境内で動作することができる。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードとすることができ、図１には、メモリ記憶デバイス１８１だけ示されているが、一般に、パーソナルコンピュータ１１０に関して上述した要素の多数または全部を含む。図１に表された論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１と広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。そのようなネットワーク環境は、事務所、全社コンピュータネットワーク、イントラネット、インターネットで普通である。
【００３２】
パーソナルコンピュータ１１０は、ＬＡＮネットワーク環境内で使用されるとき、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。コンピュータ１１０は、ＷＡＮネットワーク環境内で使用されるとき一般に、インターネットなどＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は、内部にあっても外部にあってもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、パーソナルコンピュータ１１０に関して図示されたプログラムモジュール、またはその一部分を、遠隔メモリ記憶デバイス内に記憶することができる。限定ではなく例を挙げると、図１は、メモリデバイス１８１に常駐する遠隔アプリケーションプログラム１８５を示す。図のネットワーク接続は例であり、コンピュータ間で通信リンクを確立する他の手段を使用することができることは理解されよう。
【００３３】
以下の説明では、別段の表示がない限り、本発明について、１つまたは複数のコンピュータによって実行される動き、および動作を記号で表したものを参照して述べる。したがって、そのような動きおよび動作は、「コンピュータによって実行される」と呼ばれることがあり、コンピュータの処理装置によって、構造化された形態でデータを表す電気信号が操作されることを含むことを理解されたい。この操作は、データを変換し、またはコンピュータのメモリシステム内のロケーションでデータを維持し、当業者にはよく理解できる方法で、コンピュータの動作を再構成し、または他の方法で変更する。データが維持されるデータ構造は、データの形式によって定義された特定の特性を有するメモリの物理ロケーションである。しかし、本発明について前述の文脈で述べると、当業者なら、以下で述べるさまざまな動きおよび動作をハードウェアで実施することもできることが理解され、限定をする意味ではないのである。
【００３４】
上記で紹介したように、ピアツーピア（Ｐ２Ｐ）プロトコルが成功するか否かは、選択されたエンティティ間で有効な通信を確立するプロトコルの能力に左右される。同様に、そのようなＰ２Ｐネットワーク内でのグループの形成は本能力に依拠する。特定のユーザは、さまざまな方法で、異なるアドレスを有するさまざまなロケーションでネットワークに接続することがあるため、好ましい手法としては、ユーザまたはグループに一意の同一性を割り当て、次いで、その同一性をプロトコルを介して特定のアドレスまたはアドレス群に解決するものがある。本発明の同一性管理システムおよび方法が特に適用されるそのようなピアツーピア名前解決プロトコル（ＰＮＲＰ）は、それによって本発明は限定されないが、２００１年８月２９日に出願された「Peer-To-Peer Name Resolution Protocol (PNRP) And Multilevel Cache For Use Therewith」という名称の同時係属の特許出願第０９／９４２，１６４号、２００２年４月１５日に出願された「Multi-Level Cache Architecture and Cache Management Method for Peer-To-Peer Name Resolution Protocol」という名称の同時係属の特許出願第１０／１２２，８６３号、および、２００１年９月１９日に出願された「Peer-To-Peer Group Management and Method For Maintaining Peer-To-Peer Graphs」という名称の同時係属の特許出願第０９／９５５，９２３号に述べられており、これらの教示および開示は、それらを参照することによりその全体を本明細書に組み込む。
【００３５】
しかし、本発明のＰ２Ｐグラフ処理インターフェースおよび方法は、これら同時係属の特許出願の特定のピアツーピアプロトコルに限定されず、均等な効力で他の解決プロトコルに適用することができることを、当業者なら以下の教示から理解するであろう。同様に、２００１年９月１９日に出願された「Peer-To-Peer Name Resolution Protocol (PNRP) Security Infrastructure And Method」という名称の同時係属の特許出願第０９／９５６，２６０号は、必ずしもネットワークに過剰なトラフィックの負担をかけることなしに、ネットワーク内のさまざまなエンティティの同一性が有効であることを保証する、基礎となるセキュリティインフラストラクチャについて述べている。Ｐ２Ｐグループ化環境では、２００１年９月１９日に出願された「Peer-To-Peer Name Resolution Protocol (PNRP) Group Security Infrastructure and Method」という名称の同時係属の特許出願第０９／９５５，９２４号が、そのようなグループに使用される基礎となるセキュリティインフラストラクチャについて述べている。これら特許出願の教示および開示もまた、それらを参照することによりその全体を組み込む。しかし、本発明のインターフェースおよび方法は、そのようなＰＮＲＰに特に適用され、そのようなＰＮＲＰと相互作用するが、本発明がそれによって限定されず、Ｐ２Ｐグラフ管理機能を提供したいと望むどのＰ２Ｐシステムまたはプロトコルにも適用されることを、当業者なら理解するであろう。
【００３６】
ＰＮＲＰについて述べている上述の組み込まれた同時係属の特許出願に論じられているように、および有用な背景を提供するためには個々のピア間でピア関係を確立することは、既存のピアツーピアネットワーク内でコストのかかるプロセスである。しかし、ＰＮＲＰでは、各ノードが、ネットワーク内の他のノードへの参照のリストを含むルーティングテーブルを蓄積する。各ノードエントリについて、ノード識別、アドレス、ノードのキー、このノードのキーとローカルノードのキーとの間の距離を含むことができるアドレス情報が獲得される。ローカルノードは、遠隔ノードについて学習するたびに、そのノードが既知であるかどうか、既知でない場合にはエントリをルーティングテーブルに入力するかどうか検査する。各エントリは、キャッシュオーナからのその「距離」によって決定される「理想的なキャッシュレベル」を有する。新しいエントリは、その距離に対応するキャッシュレベルに追加し、あるいはエントリの「理想的なキャッシュレベル」がまだ破られていない場合には最も低いレベルに追加することができるだけである。
【００３７】
ＰＮＲＰ内の個々のピア間の通信の場合、ノードは、照会を受信すると既に訪れたノードを除いて、キーが標的に最も合致するそのルーティングテーブル内のエントリを探索する。次いで、エントリを公示したノードに照会が直接転送される。適切なエントリがない場合には、そこから要求が受信されたノードに要求が送り返され、このノードは、それ自体のテーブル内の別のエントリを試すことになる。この要求は、キーがターゲットに合致するエントリに達した場合に成功となる。最大ステップ数で標的に達しなかった場合、または、そこから要求が受信されたノードが、可能な隣接者すべてを試し、否定応答を受信した場合に不成功となる。成功した要求の場合には、中間ホップすべてによって応答が中継される。この応答は、標的キーを保持するノードのアドレスを搬送し、エントリは、中間ノードのルーティングテーブル内に挿入される。
【００３８】
ここで、本発明のグラフ管理システムおよび方法が特に適用される１つのＰ２Ｐ環境が提供されたので、次に図２について説明を行う。図２は、本発明が存在することができる例示的なＰ２Ｐフレームワーク２００を示すが、そのようなフレームワークと共に使用することだけに限定されない。実際、本発明のＰ２Ｐグラフ管理システムおよび方法は、Ｐ２Ｐ同一性の完全な管理を可能にするインターフェースの調整された論理集合を必要とするフレームワークとともに、またはそれを望むさまざまなフレームワークと共に使用することができる。当然ながら、当業者なら、さまざまなアプリケーションプログラムが本発明のＡＰＩを使用し、Ｐ２Ｐ環境内で望ましいさまざまなユーザ同一性の管理を可能にする豊かなユーザインターフェースおよび１組の関数が提供されることを理解するであろう。
【００３９】
図２に示されているように、基礎となるＰ２Ｐグラフ処理インターフェース２０２は、Ｐ２Ｐフレームワーク２００内で必要とされる情報すべてを含むデータ記憶２０４を使用する。データ記憶内の情報はまた、Ｐ２Ｐグラフ内での生産的な参加に必要なセキュリティを提供するＰ２Ｐグラフセキュリティ管理インターフェース２０６によって使用される。また、Ｐ２Ｐシステムが機能することを可能にするために、一般に何らかの形態のＰ２Ｐ名前−アドレス解決２０８が提供される。上記で論じたように、１つのそのようなシステムが、上記の同時係属の特許出願に述べられているＰＮＲＰシステムである。本発明のＰ２Ｐグラフ処理インターフェース２０２もまた、このフレームワーク２００内に含まれる。これらの同一性管理インターフェース２１０の一実施形態の説明は、本明細書と同日に出願された「Peer-To-Peer Identity Management Interfaces And Methods」という名称の同時係属の特許出願第１０／３０９８６４号に含まれており、その教示および開示は、それらを参照することによりその全体を本明細書に組み込む。最後に、この例示的なフレームワーク２００では、Ｐ２Ｐグループ内で適切な参加を可能にするために、１組のグループ化インターフェース２１２が提供されている。
【００４０】
ここで、特に本発明のシステムおよび方法によって提供されるＰ２Ｐグラフ処理インターフェース２０２を考察すると、ＡＰＩのこのグループは、ピアツーピアグラフを確立するために、およびピア間でデータを効率的かつ確実に渡すために、アプリケーション開発者に公開される。グラフ処理の基本構造２０２は、各ノードが、グラフ内のデータの一貫したビューを確実に有するようにする。グラフ処理技術の中核部分は、グラフノードである。ノードは、ネットワーク上の個人の特定のインスタンスを示す。ノードは互いに接続することができ、ノードのネットワークまたはグラフを形成する。ノードは、レコードの形態で互いの間においてデータを送信する。
【００４１】
レコードは、本質的にグラフ内のノードすべてに押し流される（送信される）データ群である。レコードがノードによって受信された後で、ノードは、そのレコードをデータベースまたはデータ記憶内に配置する。グラフ処理は、各ノードのデータベースがまったく同じデータのビューを確実に有するようにしなければならない。グラフ処理は、各ノードを同期させておく。ノードが接続し、またグラフから切断したとき、グラフ内で分離または「分割」が発生する可能性がある。グラフ処理はまた、これらの分離を検出し修復しなければならない。グラフ内のノードは、そうするように望む場合には、従来のグラフ接続とは別個の接続を作成することができる。これらの直接接続は、ノードが任意のデータを互いに送信することを可能にする。最後に、グラフ処理は、アプリケーションがイベント通知を登録し、および受信することを可能にするイベントインフラストラクチャを有する。イベント通知は、グラフ処理が使用する機構であって、グラフ内で何かが変化したことに対してアプリケーションに警告する機構である。
【００４２】
ピアグラフを確立するとのユーザの最初の所望に基づいて、アプリケーションプログラムは、本発明のＡＰＩの初期化およびクリーンアップ関数を呼び出す。これらのＡＰＩは、グラフ処理の基本構造２０２の起動およびシャットダウンを行う。グラフ処理起動ルーチンにより、使用を望む基本構造の正確なバージョンをアプリケーションが指定することが可能になる。Ｐ２Ｐグラフ処理を使用が可能となる前に、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数を呼び出し、どのバージョンを使用したいかをグラフ処理の基本構造２０２に伝えなければならない。次いで、グラフ処理の基本構造は、要求されたバージョンであって、かつサポートしている最も高いバージョンで応答する。Ｐｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎ関数ＡＰＩが、呼び出さなければならない最後のＡＰＩである。これは、アプリケーションが基本構造を使い終えたことをグラフ処理の基本構造２０２に伝える。本発明の一実施形態においては、Ｐｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎ関数への呼出しは、Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数への各呼出しに合致しなければならない。
【００４３】
これらの関数は、Ｐ２Ｐグラフ処理の基本構造に関するバージョン情報を含むピアバージョンデータ構造を使用する。この構造のパラメータは、コーラーの使用をインストール済みＰ２Ｐダイナミックリンクライブラリ（ｄｌｌ）が期待するＰ２Ｐプロトコルのバージョン、およびインストール済みＰ２Ｐｄｌｌがサポートできる最も高いＰ２Ｐプロトコルのバージョンである。通常、これらは同じである。
【００４４】
起動を開始するために、アプリケーションは、他のどの関数が呼び出されるよりも前に、まずＰｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数を呼び出す。この関数に渡されるパラメータは、要求されているバージョンである。これは、ピアツーピアプロトコルのバージョンのうちコーラーが使用できる最も高いバージョンである。このパラメータは、上位バイトがマイナーバージョン（改訂版）を指定し、下位バイトがメジャーバージョン番号を指定するワードであることが望ましい。この関数の出力パラメータは、Ｐ２Ｐ ＡＰＩのバージョンを指定する、また、システムにインストールされているＰ２Ｐ ｄｌｌによって提供されるサポートの詳細を受け取るピアバージョンデータ構造（上述）へのポインタである。この関数の戻り値は、動作の成功または失敗を示す。エラーメッセージは、失敗のタイプまたは理由を示す。エラーメッセージは、要求された関数を実行するのにメモリが結果的に不十分であったのエラー、サポートされていないバージョンの指定、すなわち、要求されたバージョンが、ローカルマシンにインストールされているＰ２Ｐサブシステムによってサポートされていないことに起因するエラーを含む。
【００４５】
シャットダウンを開始するために、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎ関数を呼び出す。この関数は、ＡＰＩ Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐに対する呼出しによって割り振られたどの資源もクリーンアップする。上記で示されているように、Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐに対する各呼出しについて１つのＰｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎに対する呼出しが存在することが好ましい。この関数に必要とされるパラメータはない。この関数は、シャットダウン関数の成功または失敗の表示を返す。エラーの場合には、関数は適切なエラーコードを返す。
【００４６】
Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数を呼び出した後で、アプリケーションが行わなければならない次のタスクは、使用のためグラフをセットアップすることである。このため、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数またはＰｅｅｒ Ｇｒａｐｈ Ｏｐｅｎ関数の呼び出しを行う。アプリケーションが新規の構造を作成したい場合には、まずグラフのプロパティを指定しなければならない。このプロパティは、グラフをセットアップするために必要とされる基本要素を指定する。次に、アプリケーションは、ノードと関連付けるためにデータベース名を指定しなければならない。プロパティとデータベース名に加えて、アプリケーションは、グラフにセキュリティを追加するために使用したいセキュリティインターフェースを指定しなければならない。最後に、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数を呼び出し、新しいグラフを作成する。アプリケーションは、グラフを作成した後で遠隔ノードから入ってくる接続要求を「聴取」するために、Ｐｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数を呼び出さなければならない。
【００４７】
アプリケーションが、使用のためグラフをセットアップする第２の方法は、既存のグラフを開くことである。アプリケーションがグラフを開こうとする場合、２つのシナリオがある。第１のシナリオでは、グラフがノードによって初めて開かれようとしている（すなわち、そのグラフのためのデータがノードのデータベース内に存在しない）。この状況では、アプリケーションは、まずＰｅｅｒ Ｇｒａｐｈ Ｏｐｅｎ関数を呼び出さなければならない。この呼出しで、アプリケーションは、接続するグラフ、グラフ内で使用する同一性、グラフと関連付けるデータベースを指定しなければならない。さらに、アプリケーションは、そのグラフを元々作成したＰｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数内に指定されているグラフのクリエータと同じセキュリティインターフェースを指定しなければならない。アプリケーションが初めてグラフを「開いた」後で、アプリケーションは、アプリケーションが（何らかの帯域外（ｏｕｔ ｏｆ ｂａｎｄ：ＯＯＢ）機構を介して）「発見」したノードのＩＰを使用してＰｅｅｒ Ｇｒａｐｈ Ｃｏｎｎｅｃｔ関数を呼び出さなければならない。ノードはまだデータベースを有していないため、Ｐｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数に対するどの呼出しも失敗することになる。（以下で論じるように）グラフ処理レイヤ２０２がノードを残りのグラフと同期した後で、アプリケーションは自由にＰｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数を呼び出し、遠隔ノードから入ってくる接続要求を「聴取」する。
【００４８】
第２のシナリオでは、一度グラフが発見されると、ノードがグラフを再び「開く」ことが可能となる。アプリケーションは、初めてそのグラフを開いたときと同じ情報を指定しなければならない。ここでの違いは、その以前のグラフとの関係からノードがデータベースを有しているため、Ｐｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数に対するどの呼出しも成功することになる点である。しかし、接続する他のノードが発見されなかった後で、または、この場合も、発見機構２０８を介して得られたＩＰアドレスを使用してＰｅｅｒ Ｇｒａｐｈ Ｃｏｎｎｅｃｔ関数を呼び出した後に同期済みイベントを受け取った後でのみ行うべきである。
【００４９】
ノードは、グラフを作成し、または開いた後で、グラフハンドルを受け取る。このハンドルは、本発明の以下のグラフ処理ＡＰＩのほとんどで使用される。ノードがグラフから切断したいと望むときには、Ｐｅｅｒ Ｇｒａｐｈ Ｃｌｏｓｅ関数を呼び出し、グラフを閉じるだけで十分である。
【００５０】
前述のグラフ起動／シャットダウンプロセスでは、アプリケーションは、ピアグラフプロパティを指定することが必要であった。これは、グラフポリシーについてのデータと他の情報を保持するＰｅｅｒ Ｇｒａｐｈ Ｐｒｏｐｅｒｔｉｅｓデータ構造を介して行う。このデータ構造に含まれる情報は、このデータ構造のサイズの指定をバイトで含む。この情報はまた、グラフ内でのピアの挙動に関連するピアグラフプロパティフラグのビットマスクを含む。これらのフラグについては、以下で論じる。たとえばリンクローカル、サイトローカルなど、どの範囲でグラフＩＤを公表（ｐｕｂｌｉｓｈ）すべきかを定義するＳｃｏｐｅ Ｆｌａｇ。アプリケーションはまた、グラフ内で送信することができるレコードの最大サイズ（データおよび属性）をこの構造内で指定すべきである。Ｐｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数によって設定されることになるこのグラフの一意のグラフＩＤ識別子もまた指定しなければならない。この識別子は、マシン／ユーザの組合せについて一意でなければならない。さらに、グラフのクリエータの一意のクリエータＩＤ識別子が必要とされる。グラフのフレンドリ名（ｆｒｉｅｎｄｌｙ ｎａｍｅ）もまたこの構造内に提供すべきであるが、これはＮＵＬＬに設定することができる。グラフについて述べるための任意選択のコメントフィールドもまた、この構造内に提供される。グラフ内のレコードの存在寿命（Ｐｒｅｓｅｎｃｅ Ｌｉｆｅｔｉｍｅ）を制限するために、存在レコードが満了する前のレコード数が提供される。最後に、１つのグラフが含むことができる存在レコードの最大数が指定される。これのデフォルトは、実際のグラフサイズに基づいて動的に計算させることである。
【００５１】
上記で紹介したピアグラフプロパティフラグには、ハートビートフラグと期間延長（ｄｅｆｅｒ ｅｘｐｉｒａｔｉｏｎ）フラグが含まれる。ハートビートフラグは、グラフ作成時に指定され、グラフ内のノードがハートビートを公表し、グラフ内に存在し続けていることをグラフ内の他のノードに知らせるかどうか判定する。期間延長フラグは、グラフが接続されていないとき、ノードがそのグラフ内の少なくとも１つの他のノードに接続されるまで満了が発生しないことを示す。
【００５２】
一度グラフが確立されると、ノードは、何らかの形態のセキュリティを使用し、レコードの妥当性検査をして人々をグラフ内に認証する。この機能を提供する本発明のピアセキュリティインターフェースは、ＡＰＩがユーザの妥当性検査をするために呼び出すことになるグラフ処理の基本構造２０２へのセキュリティインターフェースを指定すること、およびグラフ内のレコードを安全にし、および解放することを可能にする。さらに、このセキュリティインターフェースは、アプリケーションが、セキュリティＳＳＰの実装を含むｄｌｌのパスを指定することを可能にする。アプリケーションがコールバックにＮＵＬＬを指定した場合には、基本構造は、レコードを安全にするために関数を呼び出すかわりに、レコードのセキュリティフィールド内にＣＲＣチェックサムを入れる。そのような場合には、レコードの妥当性検査をするために関数を呼び出すかわりに、基本構造はＣＲＣチェックサムを検証する。
【００５３】
このセキュリティインターフェースに使用される構造用のパラメータは、構造のサイズ、ＳＳＰインターフェースを実装するＤＬＬの任意選択のフルパス名、任意選択のパッケージ名を含む。また、このパラメータは、セキュリティ情報のバイト数、およびセキュリティ情報へのポインタ（グラフを作成する、または開く際に使用されることになるバイト）を含むことができる。セキュリティコンテキストへ任意選択のポインタであって、レコードを妥当性検査する必要があるとき呼び出されることになる妥当性検査レコード関数へのポインタもまた同様に含まれる。セキュリティレコードへのポインタがＮＵＬＬの場合には、この妥当性検査レコードポインタもまたＮＵＬＬでなければならない。さらに、レコードを安全にする必要があるとき呼び出されることになる関数へのポインタを含むことができる。しかし、妥当性検査レコード関数へのポインタがＮＵＬＬの場合には、これもまたＮＵＬＬでなければならない。最後に、このセキュリティインターフェース構造は、セキュアレコードコールバックによって割り振られた任意のデータを解放するために使用される関数へのポインタを含むことができる。
【００５４】
ｐｅｅｒ ｖａｌｉｄａｔｅ ｒｅｃｏｒｄ ｃａｌｌｂａｃｋは、レコードの妥当性検査をするために呼び出すインターフェースを指定する。このＡＰＩが基本構造によって呼び出されたとき、ピアレコード変更タイプの１つが渡される。これは、そのレコードに対して実行されるだけの動作である。アプリケーションは、この変更タイプに基づいてレコードを検証すべきである。アプリケーションが、レコードを検証するために依然としてより多くの情報を必要としている場合には、Ｅ＿ＤＥＦＦＥＲＥＤを返すことができ、グラフ処理ＡＰＩは、それを保留リスト（ｓｅｔ ａｓｉｄｅ ｌｉｓｔ）内に入れることになる。セキュリティ機構は、そのレコードの妥当性検査をするのに十分な情報を得た後で、ｐｅｅｒ ｇｒａｐｈ ｖａｌｉｄａｔｅ ｄｅｆｅｒｒｅｄ ｒｅｃｏｒｄｓ関数を呼び出さなければならない。一度この関数が呼び出されると、保留リスト内のどのレコードも、再び妥当性検査に提供されることとなる。ピアレコード妥当性検査関数のパラメータは、このレコードに関連付けられたグラフ、セキュリティコンテキストへのポインタ、妥当性検査をするレコード、妥当性検査の理由を述べるピアレコード変更タイプを含む。
【００５５】
ピアレコード変更タイプ（ｐｅｅｒ ｒｅｃｏｒｄ ｃｈａｎｇｅ ｔｙｐｅ）フラグは、変更タイプパラメータを介してコールバックに渡される。これらは、特定のレコードをどのように変更するかを関数に通知するために提供される。これは、そのタイプのレコード変更に対して作用する能力をセキュリティ関数群に与える。たとえば、これらの変更タイプは、ピアレコードの追加（レコードＩＤまたはレコードタイプは、データベースに追加されている）、レコードの更新（レコードＩＤまたはレコードタイプは、グラフ内で更新されている）、レコードの削除（レコードＩＤまたはレコードタイプは、グラフから削除されている）、またはレコードの満了（レコードＩＤまたはレコードタイプは、データベースから消滅している）を含むことができる。
【００５６】
ｐｅｅｒ ｓｅｃｕｒｅ ｒｅｃｏｒｄ ｃａｌｌｂａｃｋは、レコードを安全にするために呼び出すインターフェースを指定する。このＡＰＩが基本構造によって呼び出されると、ピアレコード変更タイプの１つが渡される。これは、そのレコードに対してちょうど実行された動作を反映する。次いで、アプリケーションは、この変更タイプに基づいてレコードを検証すべきである。このコールバックのパラメータは、このレコードに関連付けられたグラフ、セキュリティコンテキストへのポインタ、安全にするレコード、妥当性検査の理由を述べるピアレコード変更タイプフラグ、このレコード用のセキュリティデータ（たとえば署名）を含む。
【００５７】
ｐｅｅｒ ｆｒｅｅ ｓｅｃｕｒｉｔｙ ｄａｔａ ｃａｌｌｂａｃｋは、セキュリティコールバックによって返されたデータを解放するために呼び出すインターフェースを指定する。そのパラメータは、このレコードに関連付けられたグラフ、セキュリティコンテキストへのポインタ、解放すべきセキュリティデータへのポインタを含む。この関数は、動作が成功した場合に成功の表示を返し、そうでない場合には、この関数は、遭遇したエラーのタイプを示すエラー値を返す。これらは、無効なパラメータに起因するエラー、メモリ量の不足、その特定のＰ２Ｐ ＩＤを有するグラフがすでに存在する場合のエラーを含む。
【００５８】
このピアアドレスタグ構造は、グラフノードに接続するとき使用するＩＰアドレスについての情報を保持していることに留意されたい。この構造は、渡される構造のサイズ、および接続するノードのＩＰｖ６アドレスを示すパラメータを含む。
【００５９】
以上、セキュリティインターフェースを含めて、ピアグラフの作成および管理について述べたので、次に、上記で述べた関数を実施するのに必要とされる特定のインターフェースの詳細に注目して説明を行う。
【００６０】
上述のように、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅインターフェースへの呼出しは、完全に新しいグラフを作成する。また、そのグラフに関連する情報、およびそのグラフが使用することになるセキュリティのタイプを指定する機会を提供する。この呼出しにより、グラフハンドルが割り振られるが、ネットワーク接続は確立されない。この関数を呼び出した後で、アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ関数を呼び出す前に、イベントを登録する（ｓｕｂｓｃｒｉｂｅ）機会を有する。これらのイベントＡＰＩは、アプリケーションがグラフに接続されていない場合に首尾よく呼び出すことができるＡＰＩだけである。この期間中、他のどのＡＰＩ呼出しも、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩが呼び出されるまで失敗することになる。このｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅインターフェースのパラメータは、グラフのすべてのプロパティ、作成時にこのグラフに関連付けるデータベースの名前、このグラフ用のセキュリティプロバイダについて必要とされる情報すべてを含むセキュリティインターフェースへのポインタを含む。このパラメータは任意選択であり、すなわちＮＵＬＬとすることができる。これがＮＵＬＬに設定されている場合には、ＡＰＩは、上記で論じたＣＲＣチェックサム機構を使用する。このＡＰＩの出力は、作成されたグラフ用のハンドルに設定される。
【００６１】
上記で論じたｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩは、ローカルノードまたは遠隔ノードによって以前に作成されたグラフを開く。この呼出しにより、グラフハンドルが割り振られるが、ネットワーク接続は確立されない。先のＡＰＩの場合と同様に、アプリケーションは、このＡＰＩを呼び出した後で、イベントを登録するための機会を有する。しかし、アプリケーションは、入ってくる接続を受け入れるために、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩを呼び出さなければならない。このとき初めてグラフがこのノードによって開かれた場合には、そのノードがグラフに接続し同期するまで、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩへのどの呼出しも失敗することになることに留意されたい。このようにして、このノードは、古くなった、または誤った情報（レコード）を新しいノードに押し流すことができない。
【００６２】
このｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩのパラメータは、開くグラフの一意のグラフ識別子（マシン／ユーザの組合せについて一意でなければならない）、グラフを開く人の一意の識別子、作成時にこのグラフに関連付けるデータベースの名前を含む。このグラフ用のセキュリティプロバイダについて必要とされる情報を含むセキュリティインターフェースへのポインタもまた提供することができる。使用する場合、これは、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ関数内に指定されているセキュリティインターフェースと同じとしなければならない。パラメータはまた、レコード同期優先配列（ｒｅｃｏｒｄ ｓｙｎｃｈｒｏｎｉｚｅ ｐｒｅｃｅｄｅｎｃｅ ａｒｒａｙ）内のレコードタイプ数、レコードが同期される順序を示すレコードタイプの配列を含む。デフォルトの順序が使用される場合には、このパラメータをＮＵＬＬにすることができる。最後に、作成されたグラフへのハンドルが提供される。このＡＰＩは、この関数の成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、および接続を処理する他のグラフメンバを見つけることができないためのエラーの表示を含む。
【００６３】
グラフが、上述のように作成され、または開かれると、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩが呼び出され、次に来る接続の聴取を開始するようグラフに通知する。すなわち、このＡＰＩを呼び出すことができるようになる前に、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ ＡＰＩまたはｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩを呼び出さなければならない。やはり上記で示されているように、このとき初めてグラフが開かれた場合には、そのノードがｐｅｅｒ ｇｒａｐｈ ｃｏｎｎｅｃｔ ＡＰＩを介してグラフに接続し、そのレコードをグラフと同期するまで、このＡＰＩへのどの呼出しも失敗することになる。このＡＰＩのパラメータは、聴取を開始するグラフ、聴取するｉｐｖ６スコープ、聴取するｉｐｖ６スコープＩＤ、聴取するポートを含む。このＡＰＩは、成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、不十分なメモリによるエラーの表示、提供されたハンドルが無効であるためのエラーの表示を含む。
【００６４】
ノードは、グラフ内の新しいノードに接続したいと望む場合、ｐｅｅｒ ｇｒａｐｈ ｃｏｎｎｅｃｔ ＡＰＩを呼び出す。これが初めての接続である場合には、やはりこのＡＰＩは、グラフデータベースを同期しようと試みることになる。このＡＰＩのパラメータは、グラフのハンドル、所与のアドレスで接続される人の一意のＩＤ（指定されたアドレスで複数の同一性が接続される可能性があるため必要とされる）、接続されるノードのアドレスなどについての詳細を含む構造へのポインタ、以下で論じる直接接続ＡＰＩと共に使用される接続ＩＤへのポインタを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、不十分なメモリによるエラーの表示、提供されたポインタが無効であるとのエラーの表示を含む。
【００６５】
ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ ＡＰＩへの、またはｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩへの呼出しによって得られたグラフハンドルを無効にする。また、このグラフについてネットワークすべてを閉鎖する。このＡＰＩのパラメータは、切断されるグラフのハンドルである。このＡＰＩは、成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、および、提供されたハンドルが無効であるとのエラーの表示を含む。
【００６６】
ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ＡＰＩは、ノードをグラフから切断することを可能にするが、そのグラフを削除するわけではない。関連グラフのデータのそのような削除を実行するためには、アプリケーションがｐｅｅｒ ｇｒａｐｈ ｄｅｌｅｔｅ ＡＰＩを呼び出す必要があるであろう。このＡＰＩのパラメータは、データを削除するグラフの名前、データを削除するピアＩＤ、削除するグラフに関連付けられたデータベースの名前を含む。このＡＰＩは、成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、提供されたハンドルが無効であるとのエラーの表示、要求された関数を実行するためのアクセスが拒絶されたとのエラーの表示を含む。
【００６７】
今述べた本発明のシステムおよび方法によって提供されるグラフ形成および管理機能に加えて、本発明は、アプリケーションがグラフ／ノード情報を取り出し、管理することを可能にするアプリケーションプログラミングインターフェースを提供する。この情報の管理は、ノード特有の情報を容れたピアノード情報データ構造によって容易になる。このデータ構造のパラメータは、データ構造のサイズ、その隣接者に対するノード接続を識別する一意の識別子、（上述の作成またはオープン関数の実行の間にそのノードについて設定された）ピアの識別子、ピアアドレスの配列内のアドレス数、このインスタンスがどのアドレスおよびポートについてグループトラフィックを聴取するかを示すピアアドレスの配列、この特定のノードについて述べる属性を容れるために使用されるストリングデータフィールドを含む。
【００６８】
このデータ構造を使用する本発明の１つのインターフェースは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｏｄｅ ｉｎｆｏｒｍａｔｉｏｎ ＡＰＩである。このインターフェースは、ユーザのいるノードについてノード特有の情報を取り出すために呼び出される。所与のマシン上に、あるグラフのいくつかのノードが存在する可能性がある、たとえば複数のユーザが所与のマシン上のグラフに参加している可能性があるために、この情報は、実際にはマシン毎ではなく、ノード特有であることに留意されたい。このインターフェースのパラメータは、グラフハンドル、アプリケーションが情報を取得したいと望むノードのノードＩＤを含む。ゼロに設定されている場合には、このインターフェースは、ローカルノードについての情報を取り出すことになる。この出力は、ローカルノードについての情報を含むピアノード情報データ構造である。ＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、不十分なメモリによるエラーの表示、提供されたハンドルが無効である（たとえば、ノードがもはやグラフに接続されていない）とのエラーの表示を含む。
【００６９】
ノードについての情報を取り出すことに加えて、本発明は、ローカルノードのインスタンスに対してアプリケーションがピアノード情報データ構造の属性を設定することを可能にする。この関数のパラメータは、グラフハンドル、およびアプリケーションがローカルノードに関連付けたい属性を示すストリングを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００７０】
ノード情報を取り出すための能力に加えて、本発明は、現行のグラフのプロパティを取り出す能力を提供する。アプリケーションは、現行のグラフプロパティを取り出すｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｐｒｏｐｅｒｔｉｅｓ関数を呼び出すことができる。返される構造は、現行のグラフプロパティについての情報を含む。この関数のパラメータは、グラフのハンドルであって、成功時にはグラフプロパティ構造へのポインタである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、不十分なバッファサイズによるエラーの表示を含む。
【００７１】
本発明はまた、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｓｔａｔｕｓ関数への呼出しを介して、グループの状況の取出しを可能にする。この関数のパラメータは、グループへのハンドル、グループの状態として現在設定されている１組のピアグラフ状態フラグ（ｐｅｅｒ ｇｒａｐｈ ｓｔａｔｕｓ ｆｌａｇ）である。これらのフラグを使用し、ノードが接続を聴取しているか否か、ノードが他のノードに対する接続を有するか否か、ノードのデータベースが同期されているか否かを示すことができる。
【００７２】
情報を取り出すことに加えて、本発明はまた、アプリケーションがグラフプロパティを設定することを可能にするインターフェースを提供する。この関数のパラメータは、グラフのハンドル、グラフプロパティ構造へのポインタを含む。このインターフェースは、グラフサイズ、フレンドリ名、グラフを含むことができる存在レコードの数、存在レコードが満了する前の秒数（存在寿命）をアプリケーションが修正することを可能にするのが望ましい。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。
【００７３】
本発明のシステムおよび方法はまた、現在のグラフ時間をローカルシステム時間に変換するインターフェースを提供する。このインターフェースのパラメータは、グラフのハンドル、変換されるグラフ時間へのポインタ、グラフ時間から導出されたローカルシステム時間に設定される出力を含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。
【００７４】
以上、本発明のグラフ初期化／クリーンアップ関数、グラフ作成／アクセス関数、およびグラフ／ノード情報関数について述べたので、次に、本発明のレコード管理機能に注目して説明する。レコードは、グラフのノード間で通信する方法である。レコードは、グラフを形作り、良好な接続を確実にするために使用される。レコードは、２つの部分、１）バージョン、クリエータ、タイプを含む、レコードについての情報を有するヘッダと、２）グループ全体にわたって押し流されるアプリケーション定義データであるコンテント部とを備える。このコンテント部はまた、データについて述べる名前−値属性をアプリケーションが追加することを可能にするＸＭＬ構造を含む。このフィールドは、探索ＡＰＩが調べる情報を指定するために使用することができる。
【００７５】
本発明の一実施形態によれば、一度ノードがグラフ上で「聴取」されると、ノードは、グループ内で通信され記憶されるデータを操作することができる。アプリケーションが最初にしなければならないことは、レコードを獲得することである。アプリケーションはこれを、１）新規のレコードを作成する、または２）アクセス機能を使用する、という２つの方法のうちのいずれかで行うことができる。新規のレコードを作成するために、アプリケーションは、必要とされる情報およびデータでピアレコードを満たすことによって開始する。これを行った後で、ｐｅｅｒ ｇｒａｐｈ ａｄｄ ｒｅｃｏｒｄ関数を呼び出し、レコードをデータベースに追加する。この関数は、レコードをデータベースに追加することに加えて、グラフ内の残りのノードにレコードを押し流す。
【００７６】
アプリケーションは、そうする代わりに既存のレコードを獲得しようと決めた場合には、本発明のアクセス関数を使用することができる。アプリケーションがデータベースからレコードを取り出すために使用することができるそのような関数がいくつかある。第１は、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｒｅｃｏｒｄ関数である。このＡＰＩは、アプリケーションによって指定されたレコードＩＤ（ＧＵＩＤ）から特定のレコードを取得する。第２は、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩまたはｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩなど、列挙関数を介する。ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩは、レコードタイプ、またはノードの同一性に基づいてレコードの列挙を返す。ｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩは、属性フィールド内のデータに基づいてレコードをフィルタリングするために使用される探索クエリを受け入れる。各ＡＰＩは、（以下で論じる）ピアネットワーク化列挙ＡＰＩと共に使用することができる列挙を返す。
【００７７】
レコードが作成され、または取り出された後で、アプリケーションは、レコードを更新または削除することができる。アプリケーションは、レコードの更新を望む場合、単に望むフィールドを更新し、ｐｅｅｒ ｇｒａｐｈ ｕｐｄａｔｅ ｒｅｃｏｒｄ ＡＰＩを呼び出す。このＡＰＩは、データベース内のレコードを更新し、グラフ内の各ノードにレコードを押し流す。最後に、ｐｅｅｒ ｇｒａｐｈ ｄｅｌｅｔｅ ｒｅｃｏｒｄ ＡＰＩを呼び出すことによって、レコードをグラフから削除することができる。このＡＰＩは、実際にはレコードをデータベースから除去しないことに留意されたい。そのかわりに、このＡＰＩは、削除するためにレコードをマークし、残りのグラフにこの削除を伝える。レコードは、満了するまでデータベースから除去されない。
【００７８】
本発明のＡＰＩによって使用されるレコード管理構造は、ピアデータ構造を含む。アプリケーションが見るこのレコードオブジェクトは、ピアデータ構造によって定義され、そのパラメータとして、バッファポインタによって指されるデータのサイズ（バイト）、およびデータ自体を含むバッファへのポインタを含む。ピアレコードデータ構造は、そのパラメータとして構造のサイズを含み、このサイズは、ピアレコードヘッダのサイズに設定しなければならない。また、パラメータは、レコードのタイプ、Ｐ２Ｐ基本構造によって提供されたレコードのＩＤ、アプリケーションがｐｅｅｒ ｇｒａｐｈ ａｄｄ ｒｅｃｏｒｄ ＡＰＩまたはｕｐｄａｔｅ ｒｅｃｏｒｄ ＡＰＩを呼び出したとき基本構造によって提供されたレコードバージョンを含む。このデータ構造はまた、レコードに適用されるべき任意の特別な処理を示すさまざまなフラグを含むことができる。レコードクリエータの一意の識別子もまた含まれ、レコードを変更する最後の人の一意の識別子も同様である。このデータ構造はまた、ＸＭＬストリングとして指定され、レコードに関連付けられる属性−値ペアの集合を含む。属性は、探索エンジンが、レコードに関連するデータを捜す所である。ここに置かれたレコードの内容についての情報は、エンジンによって見つけ出される。エンジンが属性を認識して「見つける」ために、このストリングは、探索ＸＭＬ方式（ｓｅａｒｃｈ ＸＭＬ ｓｃｈｅｍｅ）に従わなければならない。従わない場合には、探索エンジンは、このレコードに関連する結果を返さないことになる。Ｐ２Ｐ基本構造によって提供されたときレコードが作成されたＵＴＣ時間、レコードが満了するＵＴＣ時間、レコードが最後に修正されたＵＴＣ時間もまた、この構造に含まれる。ＣＲＣチェックサムをデフォルトとして使用するピアデータ構造用のセキュリティデータもまた含まれる。最後に、このデータ構造は、実際のレコードデータを含む。
【００７９】
上記で論じたフラグは、自動リフレッシュと呼ばれるピアレコードフラグを含む。このフラグは、このレコードが満了しようとする際レコードを自動的にリフレッシュするよう、Ｐ２Ｐシステム内で使用されているグループ化ＡＰＩ群に伝えるために使用される。設定することができる他のピアレコードフラグを削除済みと呼ぶ。このフラグは、レコードが削除済みとマークされていることを示す。
【００８０】
以上、本発明のレコード管理ＡＰＩ群およびデータ構造について述べたので、次に、上述した個々のレコード管理ＡＰＩ群の各々の詳細に注目して説明する。最初に、ｐｅｅｒ ｇｒａｐｈ ａｄｄ ｒｅｃｏｒｄ ＡＰＩは、上記で紹介したように、グラフに新しいレコードを追加するために使用される。このＡＰＩを用いて追加されたレコードは、グラフ内の各ノードに送られる。このＡＰＩのパラメータは、グラフハンドル、レコードデータへのポインタ、およびグラフ内のレコードを一意に識別するレコードＩＤに対して設定されるポインタを含む。レコード内では、サイズ、タイプ、および満了だけが必要とされ、一方、データおよび属性は任意選択であることに留意されたい。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。アクセスの拒絶は、追加することができないレコードタイプをピアが追加を試みたとき発生する。
【００８１】
上記で紹介したｐｅｅｒ ｕｐｄａｔｅ ｒｅｃｏｒｄ ＡＰＩは、グラフ内でレコードを更新する。さらに、この関数は、バージョン番号を更新し、グラフ内の各ノードにレコードを押し流す。この関数のパラメータは、グラフハンドル、およびレコードに関連付ける新しいデータへのポインタを含む。修正することができるレコード内のフィールドは、サイズ、フラグ、属性、満了時間（より長い満了時間に）、セキュリティデータ、およびデータ自体である。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。
【００８２】
上記で説明したように、ｐｅｅｒ ｇｒａｐｈ ｄｅｌｅｔｅ ｒｅｃｏｒｄ ＡＰＩは、レコードをグラフ内で削除済みとマークする。このＡＰＩは、実際にはレコードをデータベースから除去しない。そのかわり、レコードを削除済みとマークしてグラフに送り出す。これは、グラフ内の各ノードがデータベースの同一のビューを確実に有するようにするために行われる。このＡＰＩのパラメータは、グラフハンドル、削除するレコードＩＤへのポインタ、およびローカルフラグである。このフラグが真に設定されている場合には、このＡＰＩは、グラフの他のノードにこの削除を送り出さない。このＡＰＩは、そうするかわりにローカルデータベースから除去するだけである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。レコードを削除することは、レコードヘッダ内でピアＲＦ無効フラグ（ｐｅｅｒ ＲＦ ｉｎｖａｌｉｄ ｆｌａｇ）を設定してレコードを更新することにより、レコードを無効とマークして次いでそのレコードを満了させることを意味する。しかし、実際のレコードペイロードは、削除することが好ましい。
【００８３】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｒｅｃｏｒｄ ＡＰＩは、アプリケーションが、レコードＩＤを介して特定のレコードを取り出すことを可能にする。返されたレコードは、ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ ＡＰＩを呼び出すことによって解放すべきである。このＡＰＩのパラメータは、グラフハンドル、取り出すレコードＩＤへのポインタ、取り出されたレコードへのポインタに対して設定されるポインタである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、レコードがデータベースにないことの表示、アクセスの拒絶によるエラーの表示を含む。
【００８４】
ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩは、特定のタイプおよび／またはクリエータのレコードすべてにわたって反復を開始する。これは、現在時間でのレコードのスナップショットである。このＡＰＩのパラメータは、グラフハンドル、反復を行うレコードのタイプへのポインタである。このポインタがＮＵＬＬである場合には、このＡＰＩは、全レコードにわたって反復を行うことになる。このＡＰＩはまた、ピアＩＤを識別するパラメータを含む。指定されている場合には、このＡＰＩは、そのピアＩＤによって作成されたレコード群だけにわたって反復を行うことになる。ＮＵＬＬの場合には、このＡＰＩは、すべてのユーザによって作成されたレコードにわたって反復を行う。このＡＰＩはまた、反復へのハンドルを生成する。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００８５】
ｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩは、特定のレコードを探索するために使用される。このＡＰＩのパラメータは、グラフハンドル、クエリを記述されたＸＭＬストリング、および列挙ハンドルである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、初期化するのに失敗したことによるエラーの表示、他のレコードがないことによるエラーの表示を含む。
【００８６】
新しいレコードがグラフ隣接者から入ってきたとき、ｐｅｅｒ ｇｒａｐｈ ｖａｌｉｄａｔｅ ｄｅｆｅｒｒｅｄ ｒｅｃｏｒｄｓ ＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ ＡＰＩまたはｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩへの呼出しの期間中にピアセキュリティインターフェース内で指定されたｖａｌｉｄａｔｅ ｒｅｃｏｒｄ ｃａｌｌｂａｃｋを呼び出すことによって、レコードの妥当性検査を試みることになる。セキュリティモジュールが妥当性検査を実行するのに必要とする情報すべてをまだ有していない場合がある。そのような場合には、このＡＰＩは、レコードの妥当性検査をするのではなく、期間延長エラーメッセージを返すことになる。次に、グラフ処理レイヤは、レコードを一時期間延長テーブルに移動する。セキュリティモジュールは、妥当性検査の実行を準備する際、ｐｅｅｒ ｇｒａｐｈ ｖａｌｉｄａｔｅ ｄｅｆｅｒｒｅｄ ｒｅｃｏｒｄｓ ＡＰＩを呼び出し、グラフ処理レイヤにどの期間延長レコードも再提出するように依頼することができる。パラメータは、グラフハンドル、レコードＩＤ群へのポインタ内に指定されたレコードＩＤ（ｒｅｃｏｒｄ ｉｄｅａ）の数を含む。これがゼロの場合には、グラフ処理レイヤは、現在期間延長されているあらゆるレコードについてｖａｌｉｄａｔｅ ｒｅｃｏｒｄ関数を呼び出すことになる。最後に、このＡＰＩは、再び妥当性検査すべきレコードＩＤの配列へのポインタのパラメータを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラー、および「初期化されていない場合」のエラーの表示を含む。
【００８７】
以上、本発明のレコード管理ＡＰＩ群の説明を完了したので、次に、本発明のグラフ処理ＡＰＩ群の一部を形成するエクスポート／インポートＡＰＩに注目して説明する。アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｅｘｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことにより、データベースを特定のファイルにエクスポートすることができる。アプリケーションは、ノードがグラフに少なくとも１回接続し、上記で論じたｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩをアプリケーションが呼び出した後でのみ行うことができる。アプリケーションはまた、ｐｅｅｒ ｇｒａｐｈ ｉｍｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことにより、データベースをインポートすることができる。アプリケーションは、有効なグラフハンドルを得た後でのみ行うことができる。
【００８８】
ｐｅｅｒ ｇｒａｐｈ ｅｘｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩは、異なるマシンに移動しｐｅｅｒ ｇｒａｐｈ ｉｍｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことによってそこにインポートすることができるファイル内に、グラフデータベースをエクスポートする。このＡＰＩのパラメータは、グラフのハンドル、エクスポートされたデータが記憶されるファイルへのパスである。そのファイルがすでに存在し、いずれかのデータを含む場合には、その中のデータは上書きされることになる。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００８９】
ｐｅｅｒ ｇｒａｐｈ ｉｍｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩは、ｐｅｅｒ ｉｍｐｏｒｔ ｇｒａｐｈ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことによって得られるグラフデータベースを示すファイルをインポートする。このＡＰＩは、上記で説明したｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩをユーザがまだ呼び出していない場合にのみ首尾よく呼び出すことができる。このＡＰＩのパラメータは、グラフのハンドル、およびインポートするファイルへのパスを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００９０】
本発明のグラフ処理ＡＰＩ群はまた、ノードに関係する存在情報の管理および通信を可能にする。ｐｅｅｒ ｇｒａｐｈ ｓｅｔ ｐｒｅｓｅｎｃｅ ＡＰＩは、ノードがグラフに能動的に接続され、グラフを聴取していることを他のグラフメンバに通知するために使用される。このＡＰＩのパラメータは、グラフハンドル、および真の場合にノードが「存在する」情報をそのグラフに押し流されるフラグである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラー、および「初期化されていない場合」のエラーの表示を含む。
【００９１】
ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｎｏｄｅｓ ＡＰＩは、グラフ内のノードすべての列挙を開始するために使用される。グラフポリシーに応じて、接続されている一部のノードは、その存在を公表していないために一覧（ｅｎｕｍｅｒａｔｉｏｎ）に現れない可能性がある。このＡＰＩのパラメータは、グラフハンドル、アプリケーションがノードの一覧を得たいと望むピアＩＤ、存在するピアにわたって反復を行うために使用される列挙ハンドルへのポインタである。アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩを使用して実際のピアを取り出し、ｐｅｅｒ ｇｒａｐｈ ｅｎｄ ｅｎｕｍｅｒａｔｉｏｎ ＡＰＩを使用し、この一覧に関連付けられた資源を解放する。ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｐｒｅｓｅｎｃｅ ＡＰＩへの呼出しから返された列挙ハンドルに対して使用されたとき、ピアノード情報タイプ（ｔｙｐｅ ｐｅｅｒ ｎｏｄｅ ｉｎｆｏｒｍａｔｉｏｎ）のデータを返すことになる。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「初期化されていない場合」のエラーの表示を含む。
【００９２】
本発明のグラフ処理ＡＰＩ群はまた、ユーティリティ／サポート関数を含む。これらは、２タイプのユーティリティ／サポート関数である。第１は列挙サポートであり、第２はメモリサポートである。列挙関数は、アプリケーションが受け取ったピア一覧への任意のハンドルに対して作用する。ピア一覧へのハンドルは、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩおよびｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓなどの関数から得ることができる。一度一覧が得られると、アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｉｔｅｍ ｃｏｕｎｔ ＡＰＩを呼び出すことによって、一覧内のアイテム数を取得することができる。一覧からアイテムを取得するために、アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩを呼び出さなければならない。アプリケーションは、一覧から受け取りたいアイテムの数を指定することができる。アプリケーションが、一覧内にあるものより多くのアイテムを要求した場合には、この関数は、一覧内のアイテムの数を返す。メモリサポート関数は、ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ関数である。アプリケーションは、グラフ処理ＡＰＩからデータを受け取った場合には、この関数を使用してデータを「解放」しなければならない。さらに、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩは、このＡＰＩを使用して解放しなければならないデータを返す。
【００９３】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩは、ピア一覧へのハンドルを返す任意のＡＰＩへの呼出しによって開始された反復内で次のアイテムを取得する。そのようなＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩ、ｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩ、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｎｅｉｇｈｂｏｒｓ ＡＰＩ、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｐｒｅｓｅｎｃｅ ＡＰＩを含む。返されたアイテムはすべて、ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ ＡＰＩへの単一の呼出しを使用して解放しなければならない。アプリケーションは、返されるレコードの範囲を要求することができる。このＡＰＩは、要求されたレコードの数以下を返すことになる。返されるデフォルト数は１である。このＡＰＩのパラメータは、列挙ハンドル、読み取るアイテムの数（戻りの際、読み取られたアイテムの実際の数が含まれる）、アイテムの配列へのポインタである。返される実際のデータは、一覧のタイプによって決まる。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、並びに「アイテムが１つもない場合」、および「初期化されていない場合」のエラーの表示を含む。
【００９４】
ｐｅｅｒ ｇｒａｐｈ ｅｎｄ ｅｎｕｍｅｒａｔｉｏｎ ＡＰＩは、一覧に関連付けられたどの資源も終了させ、解放する。一覧が１つもアイテムを含まない場合には、アイテムが１つもないことを示すエラーが返される。このＡＰＩの唯一のパラメータは、クリーンアップする一覧へのハンドルである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効なハンドルによるエラーの表示を含む。
【００９５】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｉｔｅｍ ｃｏｕｎｔ ＡＰＩは、一覧内の最大数のアイテムを取り出すために使用される。一覧において反復している間に、いくつかのアイテムが無効になる可能性があるため、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩから返されるアイテムの数は、ここで返されるアイテム数より少ない可能性がある。これは、ハンドルが最初に作成されたとき、一覧内のアイテムの数を示す。この基本構造の動的な性質のため、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩを介して取り出されるアイテムの数がこの数に等しくなる保証はない。このＡＰＩのパラメータは、グラフハンドル、一覧内のレコードの数である。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００９６】
ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ ＡＰＩは、上記で説明したさまざまなグラフ処理ＡＰＩ群によって返された資源を解放する。グラフ処理ＡＰＩによって返されたどのデータも、このＡＰＩを使用して解放しなければならない。このＡＰＩのパラメータは、解放するアイテムへのポインタである。
【００９７】
本発明のシステムおよび方法はまた、ノード対ノード直接通信を実現する。直接通信ＡＰＩ群は、データを押し流す必要なしに、ノードが互いにメッセージを送信することを可能にする。アプリケーションは、隣接者（すなわち、グラフ処理の基本構造のためアプリケーションが接続を有するノード）または直接接続（すなわち、アプリケーションが直接通信ＡＰＩと接続を開始したためローカルノードに接続されている遠隔ノード）にデータを送信することができる。アプリケーションは、直接接続の生成を所望の場合、まずｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩを呼び出さなければならない。これは接続を確立する。一度接続が確立されると、ノードは、ｐｅｅｒ ｇｒａｐｈ ｓｅｎｄ ｄａｔａ ＡＰＩを介して、接続上でデータを送信することができる。アプリケーションは、この送信ＡＰＩ内の「タイプ」パラメータを介して送信されるデータのタイプを記載することができることに留意されたい。アプリケーションは、直接接続を終えた後で、ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩを呼び出して接続を解体しなければならない。直接接続は、グラフの維持を考慮していない。アプリケーションはまた、隣接者フラグを指定すること、およびｐｅｅｒ ｇｒａｐｈ ｓｅｎｄ ｄａｔａ ＡＰＩを使用することによって、隣接者ノードにデータを送信することができる。アプリケーションは、直接接続確立／クローズ関数のどちらも呼び出す必要がない。
【００９８】
これらの直接通信ＡＰＩ群は、ピア接続情報構造と呼ばれる直接通信構造を使用する。この構造のパラメータは、渡される構造のサイズ、この構造が参照する接続のタイプ、この接続の接続ＩＤ、接続される他端のノードのノードＩＤ、アプリケーションが接続を有するノードのピアＩＤ、および接続のアドレスを含む。接続のタイプは、２つのフラグによって示される。ピア接続隣接者フラグ（ｐｅｅｒ ｃｏｎｎｅｃｔｉｏｎ ｎｅｉｇｈｂｏｒ ｆｌａｇ）は、この接続が隣接者接続であることを指定し、ピア接続直接フラグ（ｐｅｅｒ ｃｏｎｎｅｃｔｉｏｎ ｄｉｒｅｃｔ ｆｌａｇ）は、この接続が直接接続であることを指定する。
【００９９】
ｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩは、上述の直接接続を生成する。グラフ処理ＡＰＩ群は、データを送信するために、アプリケーションがグラフ内のノードとの接続を確立することを可能にする。この接続は、グラフ維持に役立たない。このＡＰＩのパラメータは、グラフのハンドル、あるアドレスで接続される人の一意のＩＤ（指定されたアドレスで複数の同一性が接続される可能性があるため必要とされる）、接続されるノードのアドレスなどについての詳細を含む構造へのポインタ、および直接接続の接続ＩＤを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「所与のＩＤを有するピアが存在しない場合」のエラーの表示を含む。また、ピアノードが接続を拒否したことを示すためのエラーがある。
【０１００】
ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩは、特定の直接接続を閉鎖する。このＡＰＩのパラメータは、グラフのハンドル、および切断する隣接者のＩＤである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「所与のＩＤを有する接続が存在しない場合」のエラーの表示を含む。
【０１０１】
ｐｅｅｒ ｇｒａｐｈ ｓｅｎｄ ｄａｔａ ＡＰＩは、接続されている隣接者または直接接続にデータを送信するために使用される。この関数は、データがネットワークレイヤに渡されると直ちに戻ることになる。換言すれば、グラフ処理レイヤは、他方の側からの肯定応答を待たない。このＡＰＩのパラメータは、グラフのハンドル、データを送信する接続の一意の識別子、送信されるデータのアプリケーション定義「タイプ」、次のパラメータによって指されるバイト数、隣接者に送信する実際のデータを含む。このポイントツーポイントデータを受け取るための機構の特徴は、ピアグラフイベント入来データタイプ（ｔｙｐｅ ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｉｎｃｏｍｉｎｇ ｄａｔａ）のイベントに登録することにある。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「接続が存在しない場合」のエラーの表示を含む。
【０１０２】
ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｃｏｎｎｅｃｔｉｏｎｓ ＡＰＩは、そのパラメータとして、グラフのハンドル、上記で論じたピア接続フラグに基づいて列挙する接続のタイプ、および接続の一覧へのポインタを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「接続が存在しない場合」のエラーの表示を含む。
【０１０３】
本発明のイベントインフラストラクチャは、グラフとそれに関連付けられたデータの変更についてアプリケーションに通知することを可能にする。アプリケーションが変更について通知を受け取りたい場合には、アプリケーションが最初にしなければならないことは、通知を受けたいイベントを特定する登録構造を完成させることである。この登録により、アプリケーションは、通知を受けたいイベントタイプを指定することが可能になる。イベントが、関連付けの可能な特定のタイプのデータを有する場合には、これもまた登録内で指定される。たとえば、アプリケーションは、特定のレコードタイプの変更について通知するために登録することができる。そのためには、アプリケーションは、イベントタイプとしてピアグラフイベントレコード変更済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅｄ）イベント、および通知を受けたいレコードタイプのＧＵＩＤを指定する登録構造を作成する。
【０１０４】
アプリケーションは、登録構造を得た後で、ｐｅｅｒ ｇｒａｐｈ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩを呼び出し、そのイベントを関連付けたいイベントハンドルを指定する。あるイベントハンドルにいくつかのイベントを関連付けることができることに留意されたい。一度アプリケーションが関心のあるイベントが発生したならば、イベントハンドルは、イベントが発生したことを知らされる。次いで、アプリケーションは、そのイベントに関連付けられたデータを取り出すために、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａ ＡＰＩを呼び出さなければならない。このＡＰＩは、２つの重要なデータを含む構造を返す。第１は、イベントに関連付けられた登録であり、第２は、そのイベントに関連付けられたデータである。アプリケーションは、アイテムが１つもないことを示すエラーメッセージが発生するまで、引き続きｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａを呼び出すべきである。アプリケーションは、特定のハンドルに関連付けられたイベントについてもはや通知を望まないとき、ｐｅｅｒ ｇｒａｐｈ ｕｎ−ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩを呼び出すことによって、単にその関心を登録抹消する。
【０１０５】
本発明のイベントインフラストラクチャは、７つのデータ構造を使用する。第１は、ピアグラフイベント登録（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｇｉｓｔｒａｔｉｏｎ）構造である。アプリケーションは、イベント通知に登録するとき、通知登録を解釈するために必要とされるコンテキストデータを含み、および通知が発生すると通知に関連するデータを返すために使用されるピアイベント登録構造の配列を提供する。この構造のパラメータは、ピアが関心のあるイベントのタイプ（下記で指定されるイベントタイプの１つでなければならない）、およびレコードタイプを含む。指定されたイベントタイプがレコードに作用する場合には、指定されたレコードタイプのレコードに対してだけイベントを発するように、このレコードタイプを指定することができる。このパラメータは、すべてのレコードタイプについてイベントを発生させるためにＮＵＬＬとすることができる。このフィールドは、レコードに対して作用するイベントタイプについて無視される。この登録は、アプリケーションが通知を受けたいイベントタイプを取る。
【０１０６】
イベントタイプは、グラフが変更済み状況を有する（接続された、など）、グラフプロパティ構造内のフィールドが変更された（このイベントが発せられた場合には、アプリケーションはすでに変更を有し、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｐｒｏｐｅｒｔｉｅｓ ＡＰＩを使用して、更新された構造を取得しなければならないため、データは使用可能でない）、レコードタイプ（または特定のレコード）が何らかの形で変更された、ピアの直接接続が変更された、ピア隣接者との接続が変更された、直接または隣接者接続から（フラッディングではなく）データが受信された、グラフが不安定になった（クライアントは、新しいノード上でｐｅｅｒ ｇｒａｐｈ ｃｏｎｎｅｃｔ ＡＰＩを呼び出すことによって応答すべきである）、グラフ内でノードの存在状況が変更された、およびある種のレコードタイプの同期がとられたことに関するイベントを含むことができる。
【０１０７】
アプリケーションは、一度イベント通知を受け取ると、データをそのイベントに関連付けることができる。データはすべて、ピアグラフイベントデータ（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄａｔａ）構造内に一般化される。イベントに応じて、ユニオン内の適切なフィールドが書き込まれる（ｆｉｌｌ ｏｕｔ）。ユニオン内のフィールドの１つを除くすべては、この構造へのポインタである。ユニオンの各メンバが定義される。構造内のどれも「設定」することができない。イベントタイプはイベントに対応するイベントデータであり、状態フィールドは、ピアグラフイベント状態変更（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｓｔａｔｕｓ ｃｈａｎｇｅ）イベントが発せられた場合に書き込まれる。これは、ノードのグラフとの接続に関して何かが起こったことを意味する。入来データフィールドは、ピアグラフイベント隣接者データ（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｅｉｇｈｂｏｒ ｄａｔａ）またはピアグラフイベント直接データ（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄｉｒｅｃｔ ｄａｔａ）イベントが発せられた場合に書き込まれる。これは、隣接者または直接接続から送られたのではなくノードがデータを受信したことを意味する。レコード変更データフィールドは、ピアグラフイベントレコード変更（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅ）イベントが発せられた場合に書き込まれる。これは、アプリケーションが通知を依頼したレコードまたはレコードタイプが変更されたことを意味する。接続変更データフィールドは、ピアグラフイベント隣接者接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｅｉｇｈｂｏｒ ｃｏｎｎｅｃｔｉｏｎ）またはピアグラフイベント直接接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ）イベントが発せられた場合に書き込まれる。これは、隣接者または直接接続状態の何らかの面が変更されたことを意味する。ノード変更データフィールドは、ピアグラフイベントノード変更済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｏｄｅ ｃｈａｎｇｅｄ）イベントが発せられた場合に書き込まれる。これは、グラフ存在状態内の何らかのノードが変更されたことを意味する。同期データフィールドは、ピアグラフイベント同期済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｓｙｎｃｈｒｏｎｉｚｅｄ）イベントが発せられた場合に書き込まれる。これは、何らかのレコードタイプが同期するのを終えたことを意味する。
【０１０８】
ピアイベント入来データ（ｐｅｅｒ ｅｖｅｎｔ ｉｎｃｏｍｉｎｇ ｄａｔａ）構造では、ユニオンは、入来データイベントが発せられた場合にデータへのポインタを含む。これは、隣接者または直接接続からの押し流しでなくノードがデータを受信したことを意味する。この構造のフィールドは、構造のサイズ、データが来た接続の一意の識別子、入来データのアプリケーション定義データタイプ、および受け取った実際のデータを含む。
【０１０９】
ピアイベントレコード変更データ（ｐｅｅｒ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅ ｄａｔａ）は、ピアグラフイベントレコード変更（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅ）イベントが発せられた場合にユニオンがそれへのポインタを含む構造である。これは、アプリケーションが通知を依頼したレコードまたはレコードタイプが変更されたことを意味する。この構造は、構造のサイズ、アプリケーションがイベントを登録したレコードまたはレコードタイプに発生した変更のタイプ、変更された一意のレコードＩＤ、および変更された一意のレコードタイプを含む。ピアレコード変更タイプは、レコードＩＤまたはレコードタイプがデータベースに追加されたことを示すためのピアレコード追加済み（ｐｅｅｒ ｒｅｃｏｒｄ ａｄｄｅｄ）タイプ、レコードＩＤまたはレコードタイプがグラフ内で更新されたことを示すためのピアレコード更新済み（ｐｅｅｒ ｒｅｃｏｒｄ ｕｐｄａｔｅｄ）タイプ、レコードＩＤまたはレコードタイプがグラフから削除されたことを示すためのピアレコード削除済み（ｐｅｅｒ ｒｅｃｏｒｄ ｄｅｌｅｔｅｄ）タイプ、およびレコードＩＤまたはレコードタイプがデータベースから消滅したことを示すためのピアレコード満了済み（ｐｅｅｒ ｒｅｃｏｒｄ ｅｘｐｉｒｅｄ）タイプを含む。
【０１１０】
ピアイベント接続変更データ（ｐｅｅｒ ｅｖｅｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｈａｎｇｅ ｄａｔａ）構造は、ピアグラフイベント隣接者接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｅｉｇｈｂｏｒ ｃｏｎｎｅｃｔｉｏｎ）イベントまたはピアグラフイベント直接接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ）イベントが発せられた場合にユニオンがそれへのポインタを含む構造である。これは、隣接者または直接接続状態の何らかの面が変更されたことを意味する。この構造は、構造のサイズ、隣接者または直接接続が受けた変更のタイプ、変更元の接続の一意の識別子、および変更元のノードの一意の識別子を含む。ピア接続状況タイプは、新しいノードがローカルノードに接続されたことを示すピア接続済み（ｐｅｅｒ ｃｏｎｎｅｃｔｅｄ）タイプ、接続が切断された（ローカルノードによって、または遠隔ノードによって行うことができる）ことを示すピア切断済み（ｐｅｅｒ ｄｉｓｃｏｎｎｅｃｔｅｄ）タイプ、およびそのノードへの接続の試みが失敗したことを示すピア接続失敗（ｐｅｅｒ ｃｏｎｎｅｃｔｉｏｎ ｆａｉｌｅｄ）タイプを含む。
【０１１１】
ピアイベントノード変更データ（ｐｅｅｒ ｅｖｅｎｔ ｎｏｄｅ ｃｈａｎｇｅ ｄａｔａ）構造は、ピアグラフイベントノード変更済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｏｄｅ ｃｈａｎｇｅｄ）イベントが発せられた場合にユニオンがそれへのポインタを含む構造である。これは、グラフ内の何らかのノードが、その存在状態を変更したことを意味する。この構造は、構造のサイズ、ノードの新しい存在状態（ピア存在変更タイプ）、変更されたノードのグラフの一意のＩＤ、および変化したノードのピアＩＤを含む。ピア存在変更タイプは、ノードがグラフ内に存在するようになったことを示すピア存在変更接続済み（ｐｅｅｒ ｐｒｅｓｅｎｃｅ ｃｈａｎｇｅ ｃｏｎｎｅｃｔｅｄ）タイプ、ノードがグラフから消えたことを示すピア存在変更切断済み（ｐｅｅｒ ｐｒｅｓｅｎｃｅ ｃｈａｎｇｅ ｄｉｓｃｏｎｎｅｃｔｅｄ）タイプ、およびノードがその情報（たとえば、属性）を更新したことを示すピア存在変更更新済み（ｐｅｅｒ ｐｒｅｓｅｎｃｅ ｃｈａｎｇｅ ｕｐｄａｔｅｄ）タイプを含む。
【０１１２】
ピアイベント同期済みデータ（ｐｅｅｒ ｅｖｅｎｔ ｓｙｎｃｈｒｏｎｉｚｅｄ ｄａｔａ）構造は、構造のサイズ、および同期されたレコードのタイプを含む。
【０１１３】
以上、イベントインフラストラクチャと、その中で使用されるデータ構造について述べたので、次に、個々のＡＰＩ群の詳細に注目して説明する。ｐｅｅｒ ｇｒａｐｈ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩは、グラフおよびイベントタイプに関連する変更について通知を受けることへのピアの関心を登録する。このＡＰＩのパラメータは、グラフのハンドル、新しいイベントに基づいて伝えられるイベントハンドルを含む。イベントハンドルは、自動リセットとすべきである。伝えられたとき、アプリケーションは、取り出すアイテムが１つもないことの表示が返されるまで、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａ ＡＰＩを呼び出さなければならない。また、パラメータは、ピアイベント登録データ構造の数のカウント、要求されている通知についてのデータを含むピアイベント登録データ構造の配列へのポインタ、および通知を登録抹消するためのｐｅｅｒ ｕｎ−ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ｈａｎｄｌｅ ＡＰＩへの呼出しの中で使用することができるピアイベントハンドルを含む。このＡＰＩは、成功または失敗の表示を返す。この失敗表示は、無効な引数による失敗の表示を含む。
【０１１４】
ｐｅｅｒ ｇｒａｐｈ ｕｎ−ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩは、グラフおよびレコードタイプに関連する変更について通知を受けることへのアプリケーションの関心を登録抹消する。このＡＰＩのパラメータは、ｐｅｅｒ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ｈａｎｄｌｅ ＡＰＩへの呼出しから得られたハンドルである。このＡＰＩは、成功または失敗の表示を返す。この失敗表示は、無効な引数による失敗の表示を含む。
【０１１５】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａ ＡＰＩは、アプリケーションがイベントを取り出すことを可能にする。取り出すイベントが１つもないことを示す表示が返される。イベントはすべて、データをピアグラフイベントデータ構造の形態で受け取る。どのイベントが発せられたかに応じて、対応するデータ構造が返される。このＡＰＩのパラメータは、ｐｅｅｒ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ｈａｎｄｌｅ ＡＰＩへの呼出しによって得られたハンドル、および通知についてのデータを含む。
【０１１６】
Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＸＰオペレーティングシステムに特に適した本発明のインターフェースおよび方法の一実施形態においては、ＡＰＩ群を以下のようにすることができる。
【０１１７】
【表１】
【０１１８】
【表２】
【０１１９】
【表３】
【０１２０】
【表４】
【０１２１】
本発明のさまざまな実施形態に関する前記説明は、例示および説明のために提供されている。消尽、または開示されたその実施形態に本発明を限定することは意図されていない。上記の示唆に鑑みて、多数の修正形態または変形形態が可能である。考察した実施形態は、本発明の原理とその実際的な応用を最もよく示し、それによって、さまざまな実施形態で、および企図されている特定の使用に適したさまざまな修正形態と共に、当業者が本発明を使用することを可能にするように選択され述べられた。そのような修正形態および変形形態はすべて、添付の特許請求の範囲が公平に、法的に、正当に権利を与えられる広さに従って解釈されたとき、添付の特許請求の範囲によって決定される本発明の範囲内にある。
【符号の説明】
【０１２２】
１００ コンピューティングシステム環境
１１０ コンピュータ
１２０ 処理装置
１３０ システムメモリ
１２１ システムバス
１３１ ＲＯＭ
１３２ ＲＡＭ
１３３ 基本入出力システム（ＢＩＯＳ）
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ インターフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ インターフェース
１５１ 磁気ディスクドライブ
１５２ 取外し可能な不揮発性磁気ディスク
１５５ 光ディスクドライブ
１５６ 取外し可能な不揮発性光ディスク
１６０ ユーザ入力インターフェース
１６１ ポインティングデバイス
１６２ キーボード
１７０ ネットワークインターフェースまたはアダプタ
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ 広域ネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８１ メモリ記憶デバイス
１８５ 遠隔アプリケーションプログラム
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺機器インターフェース
１９６ プリンタ
１９７ スピーカ
２００ Ｐ２Ｐフレームワーク
２０２ Ｐ２Ｐグラフ処理インターフェース
２０４ データ記憶
２０６ Ｐ２Ｐグラフセキュリティ管理インターフェース
２０８ Ｐ２Ｐ名前−アドレス解決
２１０ 同一性管理インターフェース
２１２ グループ化インターフェース
【技術分野】
【０００１】
本発明は、一般にピアツーピア環境内でのグラフおよびデータレコード管理に関し、より詳細には、ピアツーピアのグラフ作成および管理のためのアプリケーションプログラミングインターフェースおよび方法、ならびに、ピアツーピアのグラフ内でのレコード（データ）およびノードの管理に関する。
【背景技術】
【０００２】
インターネットに関するさまざまな通信技術によって、共通の関心を有する諸ユーザが、共同作業し、ファイルを共有し、互いにチャットし、プレゼンテーションやグループ会議のためにオーディオやビデオをマルチキャストし、複数競技者のゲームに参加することが可能になっている。しかし、現在、インターネット上のほとんどの通信は、サーバ中心の環境内で行われ、それによって通信はすべて大規模な中央サーバに流れ込み、あるいはこれを介して流通するのであり、個人はそのような通信に加入し参加するためにこのようなサーバに接続することができる。
【０００３】
ピアツーピア技術が再出現したため、インターネット通信の現行のサーバ中心型モデルは、急速に置き換えられつつある。実際、ピアツーピア技術は、サーバをベースとするインターネット通信の制約から解放されて、サーバのない環境でユーザが互いに接続することを可能にする。ピアツーピアをベースとするシステムでは、通信がネットワーク内のピア間で直接行われるため、ユーザの匿名性およびプライバシーを維持することができる。しかし、ピアツーピアネットワーク内では、個々の通信およびファイル共有は比較的よく確立されているが、ピアツーピア環境内での情報の確立、獲得、接続、維持、共有については十分とはいえない。
【０００４】
ピアツーピア通信や実際すべてのタイプの通信は、選択されたエンティティ間またはノード間で有効な通信が確立されるか否かによってその成否が左右される。ピアツーピアネットワーク内で形成されたピア（たとえば、ユーザまたはマシン）またはグループをこれらのエンティティまたはノードとすることができる。ノード間の接続によってピアツーピアのグラフを形成されるが、これにより通信および情報をノードへ渡し、またはノード間で渡すことが可能となる。しかし、エンティティは、ネットワーク内のエンティティの移動、トポロジの変化、アドレス貸し出しの更新ができないこと、並びにグループの機能または目的の変化などのために変わる可能性のある１つまたはいくつかのアドレスを有することがある。したがって、従来のアーキテクチャにおいては、このアドレスに関する問題に対し、各エンティティに安定した名前を割り当てること、および接続が必要とされるとき、この名前を「解決」して現在のアドレスにすることにより解決を図っている。この名前−アドレス変換は、非常に確固としたものでなければならず、また容易かつ高速な更新を可能にするものでなければならない。
【０００５】
エンティティのアドレスが、接続を試みるエンティティによって見つけられる尤度を高めるために、多数のピアツーピアプロトコルにおいて、さまざまな機構を介することによってエンティティがその個々のアドレスまたはグループアドレスを公表することが可能になっている。また、いくつかのプロトコルにおいては、ネットワーク内の他者からの要求を処理することにより、クライアントが他のエンティティのアドレスの知識を得ることが可能になっている。実際、このアドレス知識の獲得により、確固たるグラフを維持することによってこれらのピアツーピアネットワークを動作させるのに成功する。すなわち、ネットワーク内の他のピアおよびグループに関する情報が優れているほど（すなわち、グラフがより確固たるものであるほど）、特定の資源またはレコードの探索が集中する尤度が高くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
サーバ中心の環境の場合と同様に、ピアツーピアのグラフは、グラフ内でインターネットファイルの探索および共有を可能にするために完全に開放することができる。しかし、ピアツーピアネットワークは、分散されたユーザまたはピアのグラフとして形成されるため、ネットワーク内のピアすべてが共有情報を知ることができるようになる前に、通信またはデータ（レコード）をあるピアから別のピアに渡すことが必要である。そのような経路設定を提供するシステムとしては、ＵｓｅｎｅｔおよびＯＳＰＦがある。しかし、そのような現行のシステムには、現在までのところ限界があり、ピアツーピア技術の発展と完成を制限している。さらに、ピアツーピアネットワークは、現在、適切なグラフ管理を欠いており、メンバの１つがグループを離れても、断続的にグラフを「分断」または分割することができない。そのような場合には、もはやグラフの一方からの情報を、１つピアの離脱によって生み出されたのと反対の側のピアメンバに渡すことができない。他の欠点は、そのような分離を検出するための適切な機構が存在しないことである。
【０００７】
したがって、当技術分野では、当技術分野に存在する上述の、および他の問題に対処するピアツーピアのグラフおよびレコードを管理するインターフェースが求められている。
【課題を解決するための手段】
【０００８】
本願に開示されている本発明の概念は、ピアツーピア（Ｐ２Ｐ）ネットワーク内でのグラフ管理のための新規な、また改善されたシステムおよび方法を含む。より具体的には、本発明は、グラフの作成およびアクセス、ノードおよびグラフ情報の取出し、レコード（データ）の追加、修正、削除、管理、グラフデータのインポートおよびエクスポート、グラフのノード間の直接通信、グラフへのセキュリティプロバイダの追加、存在情報の設定および取出し、イベント通知への登録、および他のユーティリティ／サポート機能のための新規な、または改善されたＰ２Ｐアプリケーションプログラミングインターフェース（ＡＰＩ）および方法を目的とする。
【０００９】
本発明の一実施形態においては、ピアツーピアグラフを確立するために、またはピア間でデータを効率的かつ確実に渡すために、ＡＰＩおよび方法がアプリケーション作成者に公開される。グラフ処理の基本構造は、各ノードが、グラフ内のデータの一貫したビューを確実に持つようにする。グラフ処理技術の中核部分（ｃｏｒｅ ｐｉｅｃｅ）は、グラフノードである。ノードは、ネットワーク上の個人の特定のインスタンスを示す。ノードは互いに接続することができ、ノードのネットワークまたはグラフを形成する。ノードは、レコードの形態で相互にデータを送信することができる。
【００１０】
レコードは、本質的に、グラフ内のノードすべてに押し流される（送信される）データ群である。レコードがノードによって受信された後で、ノードは、そのレコードをデータベースまたはデータ記憶内に配置する。グラフ処理は、各ノードのデータベースがまったく同じデータのビューを確実に有するようにする責任を負う。グラフ処理は、各ノードを同期させておく。ノードが接続し、またグラフから切断されたとき、グラフ内で分離または「分割」が発生する可能性がある。グラフ処理はまた、これらの分離を検出し修復する責任を負う。グラフ内のノードは、望まれれば、従来のグラフ接続とは別個の接続を作成することができる。これらの直接接続は、ノードが任意のデータを互いに送信することを可能にする。最後に、グラフ処理は、アプリケーションがイベント通知を登録し、また受信することを可能にするイベンティングインフラストラクチャを有する。イベント通知は、グラフ処理が使用し、グラフ内で変化が発生した場合アプリケーションに警告する機構である。
【００１１】
本発明の一実施形態においては、グラフ作成／アクセス管理を提供するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。ＡＰＩは、新しいグラフを作成し、接続のために既存のグラフを開き、接続のためにアクセスされる特定のポートを開き、指定されたＩＰアドレスでアクセスされるポートへの接続を開始し、開発者がグラフ用のセキュリティプロバイダを指定することを可能にし、セキュリティのないレコードをグラフに追加し、グラフ内のセキュリティのないレコードを更新し、セキュリティのないレコードをグラフから削除する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。これらのインターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、これらのインターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１２】
本発明の他の実施形態においては、グラフ／ノード情報を取り出し、管理するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、ノード情報を取得し、ノード属性を設定し、グラフプロパティを取得し、グラフ状況を取得し、グラフプロパティを設定し、現在のグラフ時間をローカルシステム時間に変換する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１３】
本発明の他の実施形態においては、レコード管理を実現するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、レコードを追加し、レコードを更新し、レコードを削除し、レコードを取り出し、レコードを列挙（ｅｎｕｍｅｒａｔｅ）し、レコードを探索し、期間を延長したレコードの妥当性検査を行う。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１４】
本発明の他の実施形態においては、ノードがそのデータベースをエクスポートし、別のノードからデータベースをインポートすることを可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１５】
本発明の他の実施形態においては、ノードがグラフ内のノードすべてを列挙することを可能にし、ノードがその存在をグラフ内に設定することを可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１６】
本発明の他の実施形態においては、ユーティリティ／サポート関数を提供するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、一覧内の次の項目を取り出し、列挙を終了し、項目数を取得し、他のＡＰＩによって取り出されたデータを解放する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１７】
本発明の他の実施形態においては、ピア間の直接通信を可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、直接通信を開き、直接通信を閉じ、データを送信し、ノードに接続を列挙する。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１８】
本発明の他の実施形態においては、イベントインフラストラクチャを提供するアプリケーションプログラミングインターフェース（ＡＰＩ）が提供される。これらのＡＰＩは、イベント通知に登録し、イベントを登録抹消し、イベントデータを取り出す。これらのインターフェースの各々は、これらのインターフェースを使用してグラフを管理し利用するアプリケーションプログラムから渡されるさまざまなパラメータを利用する。インターフェースは、関数の成功または失敗を示す値を返す。失敗の場合、インターフェースは、失敗の原因となった問題に関する表示を提供する。
【００１９】
本明細書に組み込まれ、本明細書の一部を形成する添付の図面は、本発明のいくつかの態様を示し、説明と共に本発明の原理を説明するのに有効である。
【００２０】
本発明について、いくつかの好ましい実施形態と共に述べることになるが、本発明をこれらの実施形態に限定する意図はない。反対に、添付の特許請求の範囲によって定義される本発明の精神および範囲内に含まれる代替の実施形態、変更される実施形態、および等価な形態のすべてを包含するものとする。
【図面の簡単な説明】
【００２１】
【図１】本発明が常駐する例示的なコンピュータシステムを一般的に示すブロック図である。
【図２】本発明のシステムおよび方法が特に適用されるピアツーピア（Ｐ２Ｐ）インターフェースフレームワークを示す簡略化されたフレームワーク図である。
【発明を実施するための形態】
【００２２】
同じ参照番号は同じ要素を指す図面を参照して、好適なコンピューティング環境内で実施されるように本発明を示す。必ずしも必要ではないが、本発明については、パーソナルコンピュータによって実行されるプログラムモジュールなど、コンピュータ実行可能命令の一般的な文脈で説明を行う。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、当業者なら、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサをベースとする家電またはプログラム可能な家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成と共に本発明を実施することができることを理解するであろう。本発明はまた、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散コンピューティング環境内で実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルと遠隔双方のメモリ記憶デバイス内に配置することができる。
【００２３】
図１は、本発明を実施することができる好適なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も暗示しないものとする。コンピューティング環境１００は、例示的な動作環境１００に示されている構成要素のいずれか１つまたは組合せに関してどんな依存性も要件も有すると解釈すべきでない。
【００２４】
本発明は、多数の他の汎用または専用コンピューティングシステム環境または構成と共に動作可能である。本発明と共に使用するのに適している可能性のある周知のコンピューティングシステム、環境、および／または構成の例には、それだけには限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサをベースとするシステム、セットトップボックス、プログラム可能な家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。
【００２５】
本発明について、コンピュータによって実行される、プログラムモジュールなどコンピュータ実行可能命令の全体的な状況で述べることができる。一般に、プログラムモジュールは、特定のタスクを実行する、あるいは特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散コンピューティング環境内で実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含むローカルと遠隔双方のコンピュータ記憶媒体内に位置する可能性がある。
【００２６】
図１を参照すると、本発明を実施するための例示的なシステムが、コンピュータ１１０の形態で汎用コンピューティングデバイスを含む。コンピュータ１１０の構成要素には、それだけには限らないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含むさまざまなシステム構成要素を処理装置１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺機器バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含むいくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例を挙げると、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｅ）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００２７】
コンピュータ１１０は、一般に、さまざまなコンピュータ読取可能な媒体を含む。コンピュータ読取可能な媒体は、コンピュータ１１０によってアクセスすることができる任意の入手可能な媒体とすることができ、揮発性媒体と不揮発性媒体、取外し可能なおよび固定の媒体を共に含む。限定ではなく例を挙げると、コンピュータ読取可能な媒体は、コンピュータ記憶媒体と通信媒体を含む。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性と不揮発性、取外し可能なおよび固定の媒体が共に含まれる。コンピュータ記憶媒体には、それだけには限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用することができ、コンピュータ１１０によってアクセスすることができる他の任意の媒体が含まれる。通信媒体は、一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の移送機構など変調データ信号に統合し、任意の情報送達媒体を含む。「変調データ信号」という用語は、情報を信号に符号化するようにその特性の１つまたは複数が設定された、または変化した信号を意味する。限定ではなく例を挙げると、通信媒体は、有線ネットワークまたは直接配線接続など有線媒体と、音響、ＲＦ、赤外線および他の無線媒体など無線媒体とを含む。上記のいずれかの組合せもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。
【００２８】
システムメモリ１３０は、読出し専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２など揮発性および／または不揮発性メモリの形態でコンピュータ記憶媒体を含む。起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は、一般にＲＯＭ１３１内に記憶されている。一般にＲＡＭ１３２は、処理装置１２０によって直ちにアクセス可能な、かつ／または現在動作されているデータおよび／またはプログラムモジュールを含む。限定ではなく例を挙げると、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７を示す。
【００２９】
コンピュータ１１０はまた、他の取外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体を含むことができる。例にすぎないが、図１は、固定の不揮発性磁気媒体との間で読出しまたは書込みをするハードディスクドライブ１４０、取外し可能な不揮発性磁気ディスク１５２との間で読出しまたは書込みをする磁気ディスクドライブ１５１、ＣＤ ＲＯＭまたは他の光媒体など取外し可能な不揮発性光ディスク１５６との間で読出しまたは書込みをする光ディスクドライブ１５５を示す。例示的な動作環境内で使用することができる他の取外し可能な／固定の、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。一般にハードディスクドライブ１４１は、インターフェース１４０など固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、一般に、インターフェース１５０など取外し可能なメモリインターフェースによってシステムバス１２１に接続されている。
【００３０】
上記で論じ、図１に示されたドライブとその関連コンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータを記憶する。たとえば、図１では、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７を記憶して示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７と同じであることも異なっていることもできることに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７は、最低でも異なるコピーであることを示すために異なる番号が与えられている。ユーザは、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１など、入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含むことができる。これらの、また他の入力デバイスは、システムバスに結合されるユーザ入力インターフェース１６０を介して処理装置１２０に接続されることがしばしばであるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他のタイプのディスプレイデバイスもまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７やプリンタ１９６など他の周辺出力デバイスを含むことができ、これらは、出力周辺機器インターフェース１９５を介して接続することができる。
【００３１】
コンピュータ１１０は、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータに対する論理接続を使用してネットワーク環境内で動作することができる。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードとすることができ、図１には、メモリ記憶デバイス１８１だけ示されているが、一般に、パーソナルコンピュータ１１０に関して上述した要素の多数または全部を含む。図１に表された論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１と広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。そのようなネットワーク環境は、事務所、全社コンピュータネットワーク、イントラネット、インターネットで普通である。
【００３２】
パーソナルコンピュータ１１０は、ＬＡＮネットワーク環境内で使用されるとき、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。コンピュータ１１０は、ＷＡＮネットワーク環境内で使用されるとき一般に、インターネットなどＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は、内部にあっても外部にあってもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、パーソナルコンピュータ１１０に関して図示されたプログラムモジュール、またはその一部分を、遠隔メモリ記憶デバイス内に記憶することができる。限定ではなく例を挙げると、図１は、メモリデバイス１８１に常駐する遠隔アプリケーションプログラム１８５を示す。図のネットワーク接続は例であり、コンピュータ間で通信リンクを確立する他の手段を使用することができることは理解されよう。
【００３３】
以下の説明では、別段の表示がない限り、本発明について、１つまたは複数のコンピュータによって実行される動き、および動作を記号で表したものを参照して述べる。したがって、そのような動きおよび動作は、「コンピュータによって実行される」と呼ばれることがあり、コンピュータの処理装置によって、構造化された形態でデータを表す電気信号が操作されることを含むことを理解されたい。この操作は、データを変換し、またはコンピュータのメモリシステム内のロケーションでデータを維持し、当業者にはよく理解できる方法で、コンピュータの動作を再構成し、または他の方法で変更する。データが維持されるデータ構造は、データの形式によって定義された特定の特性を有するメモリの物理ロケーションである。しかし、本発明について前述の文脈で述べると、当業者なら、以下で述べるさまざまな動きおよび動作をハードウェアで実施することもできることが理解され、限定をする意味ではないのである。
【００３４】
上記で紹介したように、ピアツーピア（Ｐ２Ｐ）プロトコルが成功するか否かは、選択されたエンティティ間で有効な通信を確立するプロトコルの能力に左右される。同様に、そのようなＰ２Ｐネットワーク内でのグループの形成は本能力に依拠する。特定のユーザは、さまざまな方法で、異なるアドレスを有するさまざまなロケーションでネットワークに接続することがあるため、好ましい手法としては、ユーザまたはグループに一意の同一性を割り当て、次いで、その同一性をプロトコルを介して特定のアドレスまたはアドレス群に解決するものがある。本発明の同一性管理システムおよび方法が特に適用されるそのようなピアツーピア名前解決プロトコル（ＰＮＲＰ）は、それによって本発明は限定されないが、２００１年８月２９日に出願された「Peer-To-Peer Name Resolution Protocol (PNRP) And Multilevel Cache For Use Therewith」という名称の同時係属の特許出願第０９／９４２，１６４号、２００２年４月１５日に出願された「Multi-Level Cache Architecture and Cache Management Method for Peer-To-Peer Name Resolution Protocol」という名称の同時係属の特許出願第１０／１２２，８６３号、および、２００１年９月１９日に出願された「Peer-To-Peer Group Management and Method For Maintaining Peer-To-Peer Graphs」という名称の同時係属の特許出願第０９／９５５，９２３号に述べられており、これらの教示および開示は、それらを参照することによりその全体を本明細書に組み込む。
【００３５】
しかし、本発明のＰ２Ｐグラフ処理インターフェースおよび方法は、これら同時係属の特許出願の特定のピアツーピアプロトコルに限定されず、均等な効力で他の解決プロトコルに適用することができることを、当業者なら以下の教示から理解するであろう。同様に、２００１年９月１９日に出願された「Peer-To-Peer Name Resolution Protocol (PNRP) Security Infrastructure And Method」という名称の同時係属の特許出願第０９／９５６，２６０号は、必ずしもネットワークに過剰なトラフィックの負担をかけることなしに、ネットワーク内のさまざまなエンティティの同一性が有効であることを保証する、基礎となるセキュリティインフラストラクチャについて述べている。Ｐ２Ｐグループ化環境では、２００１年９月１９日に出願された「Peer-To-Peer Name Resolution Protocol (PNRP) Group Security Infrastructure and Method」という名称の同時係属の特許出願第０９／９５５，９２４号が、そのようなグループに使用される基礎となるセキュリティインフラストラクチャについて述べている。これら特許出願の教示および開示もまた、それらを参照することによりその全体を組み込む。しかし、本発明のインターフェースおよび方法は、そのようなＰＮＲＰに特に適用され、そのようなＰＮＲＰと相互作用するが、本発明がそれによって限定されず、Ｐ２Ｐグラフ管理機能を提供したいと望むどのＰ２Ｐシステムまたはプロトコルにも適用されることを、当業者なら理解するであろう。
【００３６】
ＰＮＲＰについて述べている上述の組み込まれた同時係属の特許出願に論じられているように、および有用な背景を提供するためには個々のピア間でピア関係を確立することは、既存のピアツーピアネットワーク内でコストのかかるプロセスである。しかし、ＰＮＲＰでは、各ノードが、ネットワーク内の他のノードへの参照のリストを含むルーティングテーブルを蓄積する。各ノードエントリについて、ノード識別、アドレス、ノードのキー、このノードのキーとローカルノードのキーとの間の距離を含むことができるアドレス情報が獲得される。ローカルノードは、遠隔ノードについて学習するたびに、そのノードが既知であるかどうか、既知でない場合にはエントリをルーティングテーブルに入力するかどうか検査する。各エントリは、キャッシュオーナからのその「距離」によって決定される「理想的なキャッシュレベル」を有する。新しいエントリは、その距離に対応するキャッシュレベルに追加し、あるいはエントリの「理想的なキャッシュレベル」がまだ破られていない場合には最も低いレベルに追加することができるだけである。
【００３７】
ＰＮＲＰ内の個々のピア間の通信の場合、ノードは、照会を受信すると既に訪れたノードを除いて、キーが標的に最も合致するそのルーティングテーブル内のエントリを探索する。次いで、エントリを公示したノードに照会が直接転送される。適切なエントリがない場合には、そこから要求が受信されたノードに要求が送り返され、このノードは、それ自体のテーブル内の別のエントリを試すことになる。この要求は、キーがターゲットに合致するエントリに達した場合に成功となる。最大ステップ数で標的に達しなかった場合、または、そこから要求が受信されたノードが、可能な隣接者すべてを試し、否定応答を受信した場合に不成功となる。成功した要求の場合には、中間ホップすべてによって応答が中継される。この応答は、標的キーを保持するノードのアドレスを搬送し、エントリは、中間ノードのルーティングテーブル内に挿入される。
【００３８】
ここで、本発明のグラフ管理システムおよび方法が特に適用される１つのＰ２Ｐ環境が提供されたので、次に図２について説明を行う。図２は、本発明が存在することができる例示的なＰ２Ｐフレームワーク２００を示すが、そのようなフレームワークと共に使用することだけに限定されない。実際、本発明のＰ２Ｐグラフ管理システムおよび方法は、Ｐ２Ｐ同一性の完全な管理を可能にするインターフェースの調整された論理集合を必要とするフレームワークとともに、またはそれを望むさまざまなフレームワークと共に使用することができる。当然ながら、当業者なら、さまざまなアプリケーションプログラムが本発明のＡＰＩを使用し、Ｐ２Ｐ環境内で望ましいさまざまなユーザ同一性の管理を可能にする豊かなユーザインターフェースおよび１組の関数が提供されることを理解するであろう。
【００３９】
図２に示されているように、基礎となるＰ２Ｐグラフ処理インターフェース２０２は、Ｐ２Ｐフレームワーク２００内で必要とされる情報すべてを含むデータ記憶２０４を使用する。データ記憶内の情報はまた、Ｐ２Ｐグラフ内での生産的な参加に必要なセキュリティを提供するＰ２Ｐグラフセキュリティ管理インターフェース２０６によって使用される。また、Ｐ２Ｐシステムが機能することを可能にするために、一般に何らかの形態のＰ２Ｐ名前−アドレス解決２０８が提供される。上記で論じたように、１つのそのようなシステムが、上記の同時係属の特許出願に述べられているＰＮＲＰシステムである。本発明のＰ２Ｐグラフ処理インターフェース２０２もまた、このフレームワーク２００内に含まれる。これらの同一性管理インターフェース２１０の一実施形態の説明は、本明細書と同日に出願された「Peer-To-Peer Identity Management Interfaces And Methods」という名称の同時係属の特許出願第１０／３０９８６４号に含まれており、その教示および開示は、それらを参照することによりその全体を本明細書に組み込む。最後に、この例示的なフレームワーク２００では、Ｐ２Ｐグループ内で適切な参加を可能にするために、１組のグループ化インターフェース２１２が提供されている。
【００４０】
ここで、特に本発明のシステムおよび方法によって提供されるＰ２Ｐグラフ処理インターフェース２０２を考察すると、ＡＰＩのこのグループは、ピアツーピアグラフを確立するために、およびピア間でデータを効率的かつ確実に渡すために、アプリケーション開発者に公開される。グラフ処理の基本構造２０２は、各ノードが、グラフ内のデータの一貫したビューを確実に有するようにする。グラフ処理技術の中核部分は、グラフノードである。ノードは、ネットワーク上の個人の特定のインスタンスを示す。ノードは互いに接続することができ、ノードのネットワークまたはグラフを形成する。ノードは、レコードの形態で互いの間においてデータを送信する。
【００４１】
レコードは、本質的にグラフ内のノードすべてに押し流される（送信される）データ群である。レコードがノードによって受信された後で、ノードは、そのレコードをデータベースまたはデータ記憶内に配置する。グラフ処理は、各ノードのデータベースがまったく同じデータのビューを確実に有するようにしなければならない。グラフ処理は、各ノードを同期させておく。ノードが接続し、またグラフから切断したとき、グラフ内で分離または「分割」が発生する可能性がある。グラフ処理はまた、これらの分離を検出し修復しなければならない。グラフ内のノードは、そうするように望む場合には、従来のグラフ接続とは別個の接続を作成することができる。これらの直接接続は、ノードが任意のデータを互いに送信することを可能にする。最後に、グラフ処理は、アプリケーションがイベント通知を登録し、および受信することを可能にするイベントインフラストラクチャを有する。イベント通知は、グラフ処理が使用する機構であって、グラフ内で何かが変化したことに対してアプリケーションに警告する機構である。
【００４２】
ピアグラフを確立するとのユーザの最初の所望に基づいて、アプリケーションプログラムは、本発明のＡＰＩの初期化およびクリーンアップ関数を呼び出す。これらのＡＰＩは、グラフ処理の基本構造２０２の起動およびシャットダウンを行う。グラフ処理起動ルーチンにより、使用を望む基本構造の正確なバージョンをアプリケーションが指定することが可能になる。Ｐ２Ｐグラフ処理を使用が可能となる前に、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数を呼び出し、どのバージョンを使用したいかをグラフ処理の基本構造２０２に伝えなければならない。次いで、グラフ処理の基本構造は、要求されたバージョンであって、かつサポートしている最も高いバージョンで応答する。Ｐｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎ関数ＡＰＩが、呼び出さなければならない最後のＡＰＩである。これは、アプリケーションが基本構造を使い終えたことをグラフ処理の基本構造２０２に伝える。本発明の一実施形態においては、Ｐｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎ関数への呼出しは、Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数への各呼出しに合致しなければならない。
【００４３】
これらの関数は、Ｐ２Ｐグラフ処理の基本構造に関するバージョン情報を含むピアバージョンデータ構造を使用する。この構造のパラメータは、コーラーの使用をインストール済みＰ２Ｐダイナミックリンクライブラリ（ｄｌｌ）が期待するＰ２Ｐプロトコルのバージョン、およびインストール済みＰ２Ｐｄｌｌがサポートできる最も高いＰ２Ｐプロトコルのバージョンである。通常、これらは同じである。
【００４４】
起動を開始するために、アプリケーションは、他のどの関数が呼び出されるよりも前に、まずＰｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数を呼び出す。この関数に渡されるパラメータは、要求されているバージョンである。これは、ピアツーピアプロトコルのバージョンのうちコーラーが使用できる最も高いバージョンである。このパラメータは、上位バイトがマイナーバージョン（改訂版）を指定し、下位バイトがメジャーバージョン番号を指定するワードであることが望ましい。この関数の出力パラメータは、Ｐ２Ｐ ＡＰＩのバージョンを指定する、また、システムにインストールされているＰ２Ｐ ｄｌｌによって提供されるサポートの詳細を受け取るピアバージョンデータ構造（上述）へのポインタである。この関数の戻り値は、動作の成功または失敗を示す。エラーメッセージは、失敗のタイプまたは理由を示す。エラーメッセージは、要求された関数を実行するのにメモリが結果的に不十分であったのエラー、サポートされていないバージョンの指定、すなわち、要求されたバージョンが、ローカルマシンにインストールされているＰ２Ｐサブシステムによってサポートされていないことに起因するエラーを含む。
【００４５】
シャットダウンを開始するために、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎ関数を呼び出す。この関数は、ＡＰＩ Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐに対する呼出しによって割り振られたどの資源もクリーンアップする。上記で示されているように、Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐに対する各呼出しについて１つのＰｅｅｒ Ｇｒａｐｈ Ｓｈｕｔｄｏｗｎに対する呼出しが存在することが好ましい。この関数に必要とされるパラメータはない。この関数は、シャットダウン関数の成功または失敗の表示を返す。エラーの場合には、関数は適切なエラーコードを返す。
【００４６】
Ｐｅｅｒ Ｇｒａｐｈ Ｓｔａｒｔｕｐ関数を呼び出した後で、アプリケーションが行わなければならない次のタスクは、使用のためグラフをセットアップすることである。このため、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数またはＰｅｅｒ Ｇｒａｐｈ Ｏｐｅｎ関数の呼び出しを行う。アプリケーションが新規の構造を作成したい場合には、まずグラフのプロパティを指定しなければならない。このプロパティは、グラフをセットアップするために必要とされる基本要素を指定する。次に、アプリケーションは、ノードと関連付けるためにデータベース名を指定しなければならない。プロパティとデータベース名に加えて、アプリケーションは、グラフにセキュリティを追加するために使用したいセキュリティインターフェースを指定しなければならない。最後に、アプリケーションは、Ｐｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数を呼び出し、新しいグラフを作成する。アプリケーションは、グラフを作成した後で遠隔ノードから入ってくる接続要求を「聴取」するために、Ｐｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数を呼び出さなければならない。
【００４７】
アプリケーションが、使用のためグラフをセットアップする第２の方法は、既存のグラフを開くことである。アプリケーションがグラフを開こうとする場合、２つのシナリオがある。第１のシナリオでは、グラフがノードによって初めて開かれようとしている（すなわち、そのグラフのためのデータがノードのデータベース内に存在しない）。この状況では、アプリケーションは、まずＰｅｅｒ Ｇｒａｐｈ Ｏｐｅｎ関数を呼び出さなければならない。この呼出しで、アプリケーションは、接続するグラフ、グラフ内で使用する同一性、グラフと関連付けるデータベースを指定しなければならない。さらに、アプリケーションは、そのグラフを元々作成したＰｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数内に指定されているグラフのクリエータと同じセキュリティインターフェースを指定しなければならない。アプリケーションが初めてグラフを「開いた」後で、アプリケーションは、アプリケーションが（何らかの帯域外（ｏｕｔ ｏｆ ｂａｎｄ：ＯＯＢ）機構を介して）「発見」したノードのＩＰを使用してＰｅｅｒ Ｇｒａｐｈ Ｃｏｎｎｅｃｔ関数を呼び出さなければならない。ノードはまだデータベースを有していないため、Ｐｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数に対するどの呼出しも失敗することになる。（以下で論じるように）グラフ処理レイヤ２０２がノードを残りのグラフと同期した後で、アプリケーションは自由にＰｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数を呼び出し、遠隔ノードから入ってくる接続要求を「聴取」する。
【００４８】
第２のシナリオでは、一度グラフが発見されると、ノードがグラフを再び「開く」ことが可能となる。アプリケーションは、初めてそのグラフを開いたときと同じ情報を指定しなければならない。ここでの違いは、その以前のグラフとの関係からノードがデータベースを有しているため、Ｐｅｅｒ Ｇｒａｐｈ Ｌｉｓｔｅｎ関数に対するどの呼出しも成功することになる点である。しかし、接続する他のノードが発見されなかった後で、または、この場合も、発見機構２０８を介して得られたＩＰアドレスを使用してＰｅｅｒ Ｇｒａｐｈ Ｃｏｎｎｅｃｔ関数を呼び出した後に同期済みイベントを受け取った後でのみ行うべきである。
【００４９】
ノードは、グラフを作成し、または開いた後で、グラフハンドルを受け取る。このハンドルは、本発明の以下のグラフ処理ＡＰＩのほとんどで使用される。ノードがグラフから切断したいと望むときには、Ｐｅｅｒ Ｇｒａｐｈ Ｃｌｏｓｅ関数を呼び出し、グラフを閉じるだけで十分である。
【００５０】
前述のグラフ起動／シャットダウンプロセスでは、アプリケーションは、ピアグラフプロパティを指定することが必要であった。これは、グラフポリシーについてのデータと他の情報を保持するＰｅｅｒ Ｇｒａｐｈ Ｐｒｏｐｅｒｔｉｅｓデータ構造を介して行う。このデータ構造に含まれる情報は、このデータ構造のサイズの指定をバイトで含む。この情報はまた、グラフ内でのピアの挙動に関連するピアグラフプロパティフラグのビットマスクを含む。これらのフラグについては、以下で論じる。たとえばリンクローカル、サイトローカルなど、どの範囲でグラフＩＤを公表（ｐｕｂｌｉｓｈ）すべきかを定義するＳｃｏｐｅ Ｆｌａｇ。アプリケーションはまた、グラフ内で送信することができるレコードの最大サイズ（データおよび属性）をこの構造内で指定すべきである。Ｐｅｅｒ Ｇｒａｐｈ Ｃｒｅａｔｅ関数によって設定されることになるこのグラフの一意のグラフＩＤ識別子もまた指定しなければならない。この識別子は、マシン／ユーザの組合せについて一意でなければならない。さらに、グラフのクリエータの一意のクリエータＩＤ識別子が必要とされる。グラフのフレンドリ名（ｆｒｉｅｎｄｌｙ ｎａｍｅ）もまたこの構造内に提供すべきであるが、これはＮＵＬＬに設定することができる。グラフについて述べるための任意選択のコメントフィールドもまた、この構造内に提供される。グラフ内のレコードの存在寿命（Ｐｒｅｓｅｎｃｅ Ｌｉｆｅｔｉｍｅ）を制限するために、存在レコードが満了する前のレコード数が提供される。最後に、１つのグラフが含むことができる存在レコードの最大数が指定される。これのデフォルトは、実際のグラフサイズに基づいて動的に計算させることである。
【００５１】
上記で紹介したピアグラフプロパティフラグには、ハートビートフラグと期間延長（ｄｅｆｅｒ ｅｘｐｉｒａｔｉｏｎ）フラグが含まれる。ハートビートフラグは、グラフ作成時に指定され、グラフ内のノードがハートビートを公表し、グラフ内に存在し続けていることをグラフ内の他のノードに知らせるかどうか判定する。期間延長フラグは、グラフが接続されていないとき、ノードがそのグラフ内の少なくとも１つの他のノードに接続されるまで満了が発生しないことを示す。
【００５２】
一度グラフが確立されると、ノードは、何らかの形態のセキュリティを使用し、レコードの妥当性検査をして人々をグラフ内に認証する。この機能を提供する本発明のピアセキュリティインターフェースは、ＡＰＩがユーザの妥当性検査をするために呼び出すことになるグラフ処理の基本構造２０２へのセキュリティインターフェースを指定すること、およびグラフ内のレコードを安全にし、および解放することを可能にする。さらに、このセキュリティインターフェースは、アプリケーションが、セキュリティＳＳＰの実装を含むｄｌｌのパスを指定することを可能にする。アプリケーションがコールバックにＮＵＬＬを指定した場合には、基本構造は、レコードを安全にするために関数を呼び出すかわりに、レコードのセキュリティフィールド内にＣＲＣチェックサムを入れる。そのような場合には、レコードの妥当性検査をするために関数を呼び出すかわりに、基本構造はＣＲＣチェックサムを検証する。
【００５３】
このセキュリティインターフェースに使用される構造用のパラメータは、構造のサイズ、ＳＳＰインターフェースを実装するＤＬＬの任意選択のフルパス名、任意選択のパッケージ名を含む。また、このパラメータは、セキュリティ情報のバイト数、およびセキュリティ情報へのポインタ（グラフを作成する、または開く際に使用されることになるバイト）を含むことができる。セキュリティコンテキストへ任意選択のポインタであって、レコードを妥当性検査する必要があるとき呼び出されることになる妥当性検査レコード関数へのポインタもまた同様に含まれる。セキュリティレコードへのポインタがＮＵＬＬの場合には、この妥当性検査レコードポインタもまたＮＵＬＬでなければならない。さらに、レコードを安全にする必要があるとき呼び出されることになる関数へのポインタを含むことができる。しかし、妥当性検査レコード関数へのポインタがＮＵＬＬの場合には、これもまたＮＵＬＬでなければならない。最後に、このセキュリティインターフェース構造は、セキュアレコードコールバックによって割り振られた任意のデータを解放するために使用される関数へのポインタを含むことができる。
【００５４】
ｐｅｅｒ ｖａｌｉｄａｔｅ ｒｅｃｏｒｄ ｃａｌｌｂａｃｋは、レコードの妥当性検査をするために呼び出すインターフェースを指定する。このＡＰＩが基本構造によって呼び出されたとき、ピアレコード変更タイプの１つが渡される。これは、そのレコードに対して実行されるだけの動作である。アプリケーションは、この変更タイプに基づいてレコードを検証すべきである。アプリケーションが、レコードを検証するために依然としてより多くの情報を必要としている場合には、Ｅ＿ＤＥＦＦＥＲＥＤを返すことができ、グラフ処理ＡＰＩは、それを保留リスト（ｓｅｔ ａｓｉｄｅ ｌｉｓｔ）内に入れることになる。セキュリティ機構は、そのレコードの妥当性検査をするのに十分な情報を得た後で、ｐｅｅｒ ｇｒａｐｈ ｖａｌｉｄａｔｅ ｄｅｆｅｒｒｅｄ ｒｅｃｏｒｄｓ関数を呼び出さなければならない。一度この関数が呼び出されると、保留リスト内のどのレコードも、再び妥当性検査に提供されることとなる。ピアレコード妥当性検査関数のパラメータは、このレコードに関連付けられたグラフ、セキュリティコンテキストへのポインタ、妥当性検査をするレコード、妥当性検査の理由を述べるピアレコード変更タイプを含む。
【００５５】
ピアレコード変更タイプ（ｐｅｅｒ ｒｅｃｏｒｄ ｃｈａｎｇｅ ｔｙｐｅ）フラグは、変更タイプパラメータを介してコールバックに渡される。これらは、特定のレコードをどのように変更するかを関数に通知するために提供される。これは、そのタイプのレコード変更に対して作用する能力をセキュリティ関数群に与える。たとえば、これらの変更タイプは、ピアレコードの追加（レコードＩＤまたはレコードタイプは、データベースに追加されている）、レコードの更新（レコードＩＤまたはレコードタイプは、グラフ内で更新されている）、レコードの削除（レコードＩＤまたはレコードタイプは、グラフから削除されている）、またはレコードの満了（レコードＩＤまたはレコードタイプは、データベースから消滅している）を含むことができる。
【００５６】
ｐｅｅｒ ｓｅｃｕｒｅ ｒｅｃｏｒｄ ｃａｌｌｂａｃｋは、レコードを安全にするために呼び出すインターフェースを指定する。このＡＰＩが基本構造によって呼び出されると、ピアレコード変更タイプの１つが渡される。これは、そのレコードに対してちょうど実行された動作を反映する。次いで、アプリケーションは、この変更タイプに基づいてレコードを検証すべきである。このコールバックのパラメータは、このレコードに関連付けられたグラフ、セキュリティコンテキストへのポインタ、安全にするレコード、妥当性検査の理由を述べるピアレコード変更タイプフラグ、このレコード用のセキュリティデータ（たとえば署名）を含む。
【００５７】
ｐｅｅｒ ｆｒｅｅ ｓｅｃｕｒｉｔｙ ｄａｔａ ｃａｌｌｂａｃｋは、セキュリティコールバックによって返されたデータを解放するために呼び出すインターフェースを指定する。そのパラメータは、このレコードに関連付けられたグラフ、セキュリティコンテキストへのポインタ、解放すべきセキュリティデータへのポインタを含む。この関数は、動作が成功した場合に成功の表示を返し、そうでない場合には、この関数は、遭遇したエラーのタイプを示すエラー値を返す。これらは、無効なパラメータに起因するエラー、メモリ量の不足、その特定のＰ２Ｐ ＩＤを有するグラフがすでに存在する場合のエラーを含む。
【００５８】
このピアアドレスタグ構造は、グラフノードに接続するとき使用するＩＰアドレスについての情報を保持していることに留意されたい。この構造は、渡される構造のサイズ、および接続するノードのＩＰｖ６アドレスを示すパラメータを含む。
【００５９】
以上、セキュリティインターフェースを含めて、ピアグラフの作成および管理について述べたので、次に、上記で述べた関数を実施するのに必要とされる特定のインターフェースの詳細に注目して説明を行う。
【００６０】
上述のように、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅインターフェースへの呼出しは、完全に新しいグラフを作成する。また、そのグラフに関連する情報、およびそのグラフが使用することになるセキュリティのタイプを指定する機会を提供する。この呼出しにより、グラフハンドルが割り振られるが、ネットワーク接続は確立されない。この関数を呼び出した後で、アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ関数を呼び出す前に、イベントを登録する（ｓｕｂｓｃｒｉｂｅ）機会を有する。これらのイベントＡＰＩは、アプリケーションがグラフに接続されていない場合に首尾よく呼び出すことができるＡＰＩだけである。この期間中、他のどのＡＰＩ呼出しも、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩが呼び出されるまで失敗することになる。このｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅインターフェースのパラメータは、グラフのすべてのプロパティ、作成時にこのグラフに関連付けるデータベースの名前、このグラフ用のセキュリティプロバイダについて必要とされる情報すべてを含むセキュリティインターフェースへのポインタを含む。このパラメータは任意選択であり、すなわちＮＵＬＬとすることができる。これがＮＵＬＬに設定されている場合には、ＡＰＩは、上記で論じたＣＲＣチェックサム機構を使用する。このＡＰＩの出力は、作成されたグラフ用のハンドルに設定される。
【００６１】
上記で論じたｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩは、ローカルノードまたは遠隔ノードによって以前に作成されたグラフを開く。この呼出しにより、グラフハンドルが割り振られるが、ネットワーク接続は確立されない。先のＡＰＩの場合と同様に、アプリケーションは、このＡＰＩを呼び出した後で、イベントを登録するための機会を有する。しかし、アプリケーションは、入ってくる接続を受け入れるために、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩを呼び出さなければならない。このとき初めてグラフがこのノードによって開かれた場合には、そのノードがグラフに接続し同期するまで、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩへのどの呼出しも失敗することになることに留意されたい。このようにして、このノードは、古くなった、または誤った情報（レコード）を新しいノードに押し流すことができない。
【００６２】
このｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩのパラメータは、開くグラフの一意のグラフ識別子（マシン／ユーザの組合せについて一意でなければならない）、グラフを開く人の一意の識別子、作成時にこのグラフに関連付けるデータベースの名前を含む。このグラフ用のセキュリティプロバイダについて必要とされる情報を含むセキュリティインターフェースへのポインタもまた提供することができる。使用する場合、これは、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ関数内に指定されているセキュリティインターフェースと同じとしなければならない。パラメータはまた、レコード同期優先配列（ｒｅｃｏｒｄ ｓｙｎｃｈｒｏｎｉｚｅ ｐｒｅｃｅｄｅｎｃｅ ａｒｒａｙ）内のレコードタイプ数、レコードが同期される順序を示すレコードタイプの配列を含む。デフォルトの順序が使用される場合には、このパラメータをＮＵＬＬにすることができる。最後に、作成されたグラフへのハンドルが提供される。このＡＰＩは、この関数の成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、および接続を処理する他のグラフメンバを見つけることができないためのエラーの表示を含む。
【００６３】
グラフが、上述のように作成され、または開かれると、ｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩが呼び出され、次に来る接続の聴取を開始するようグラフに通知する。すなわち、このＡＰＩを呼び出すことができるようになる前に、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ ＡＰＩまたはｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩを呼び出さなければならない。やはり上記で示されているように、このとき初めてグラフが開かれた場合には、そのノードがｐｅｅｒ ｇｒａｐｈ ｃｏｎｎｅｃｔ ＡＰＩを介してグラフに接続し、そのレコードをグラフと同期するまで、このＡＰＩへのどの呼出しも失敗することになる。このＡＰＩのパラメータは、聴取を開始するグラフ、聴取するｉｐｖ６スコープ、聴取するｉｐｖ６スコープＩＤ、聴取するポートを含む。このＡＰＩは、成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、不十分なメモリによるエラーの表示、提供されたハンドルが無効であるためのエラーの表示を含む。
【００６４】
ノードは、グラフ内の新しいノードに接続したいと望む場合、ｐｅｅｒ ｇｒａｐｈ ｃｏｎｎｅｃｔ ＡＰＩを呼び出す。これが初めての接続である場合には、やはりこのＡＰＩは、グラフデータベースを同期しようと試みることになる。このＡＰＩのパラメータは、グラフのハンドル、所与のアドレスで接続される人の一意のＩＤ（指定されたアドレスで複数の同一性が接続される可能性があるため必要とされる）、接続されるノードのアドレスなどについての詳細を含む構造へのポインタ、以下で論じる直接接続ＡＰＩと共に使用される接続ＩＤへのポインタを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、不十分なメモリによるエラーの表示、提供されたポインタが無効であるとのエラーの表示を含む。
【００６５】
ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ ＡＰＩへの、またはｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩへの呼出しによって得られたグラフハンドルを無効にする。また、このグラフについてネットワークすべてを閉鎖する。このＡＰＩのパラメータは、切断されるグラフのハンドルである。このＡＰＩは、成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、および、提供されたハンドルが無効であるとのエラーの表示を含む。
【００６６】
ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ＡＰＩは、ノードをグラフから切断することを可能にするが、そのグラフを削除するわけではない。関連グラフのデータのそのような削除を実行するためには、アプリケーションがｐｅｅｒ ｇｒａｐｈ ｄｅｌｅｔｅ ＡＰＩを呼び出す必要があるであろう。このＡＰＩのパラメータは、データを削除するグラフの名前、データを削除するピアＩＤ、削除するグラフに関連付けられたデータベースの名前を含む。このＡＰＩは、成功または失敗の表示を返す。これらのエラー表示は、無効な引数によるエラーの表示、提供されたハンドルが無効であるとのエラーの表示、要求された関数を実行するためのアクセスが拒絶されたとのエラーの表示を含む。
【００６７】
今述べた本発明のシステムおよび方法によって提供されるグラフ形成および管理機能に加えて、本発明は、アプリケーションがグラフ／ノード情報を取り出し、管理することを可能にするアプリケーションプログラミングインターフェースを提供する。この情報の管理は、ノード特有の情報を容れたピアノード情報データ構造によって容易になる。このデータ構造のパラメータは、データ構造のサイズ、その隣接者に対するノード接続を識別する一意の識別子、（上述の作成またはオープン関数の実行の間にそのノードについて設定された）ピアの識別子、ピアアドレスの配列内のアドレス数、このインスタンスがどのアドレスおよびポートについてグループトラフィックを聴取するかを示すピアアドレスの配列、この特定のノードについて述べる属性を容れるために使用されるストリングデータフィールドを含む。
【００６８】
このデータ構造を使用する本発明の１つのインターフェースは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｏｄｅ ｉｎｆｏｒｍａｔｉｏｎ ＡＰＩである。このインターフェースは、ユーザのいるノードについてノード特有の情報を取り出すために呼び出される。所与のマシン上に、あるグラフのいくつかのノードが存在する可能性がある、たとえば複数のユーザが所与のマシン上のグラフに参加している可能性があるために、この情報は、実際にはマシン毎ではなく、ノード特有であることに留意されたい。このインターフェースのパラメータは、グラフハンドル、アプリケーションが情報を取得したいと望むノードのノードＩＤを含む。ゼロに設定されている場合には、このインターフェースは、ローカルノードについての情報を取り出すことになる。この出力は、ローカルノードについての情報を含むピアノード情報データ構造である。ＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、不十分なメモリによるエラーの表示、提供されたハンドルが無効である（たとえば、ノードがもはやグラフに接続されていない）とのエラーの表示を含む。
【００６９】
ノードについての情報を取り出すことに加えて、本発明は、ローカルノードのインスタンスに対してアプリケーションがピアノード情報データ構造の属性を設定することを可能にする。この関数のパラメータは、グラフハンドル、およびアプリケーションがローカルノードに関連付けたい属性を示すストリングを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００７０】
ノード情報を取り出すための能力に加えて、本発明は、現行のグラフのプロパティを取り出す能力を提供する。アプリケーションは、現行のグラフプロパティを取り出すｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｐｒｏｐｅｒｔｉｅｓ関数を呼び出すことができる。返される構造は、現行のグラフプロパティについての情報を含む。この関数のパラメータは、グラフのハンドルであって、成功時にはグラフプロパティ構造へのポインタである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、不十分なバッファサイズによるエラーの表示を含む。
【００７１】
本発明はまた、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｓｔａｔｕｓ関数への呼出しを介して、グループの状況の取出しを可能にする。この関数のパラメータは、グループへのハンドル、グループの状態として現在設定されている１組のピアグラフ状態フラグ（ｐｅｅｒ ｇｒａｐｈ ｓｔａｔｕｓ ｆｌａｇ）である。これらのフラグを使用し、ノードが接続を聴取しているか否か、ノードが他のノードに対する接続を有するか否か、ノードのデータベースが同期されているか否かを示すことができる。
【００７２】
情報を取り出すことに加えて、本発明はまた、アプリケーションがグラフプロパティを設定することを可能にするインターフェースを提供する。この関数のパラメータは、グラフのハンドル、グラフプロパティ構造へのポインタを含む。このインターフェースは、グラフサイズ、フレンドリ名、グラフを含むことができる存在レコードの数、存在レコードが満了する前の秒数（存在寿命）をアプリケーションが修正することを可能にするのが望ましい。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。
【００７３】
本発明のシステムおよび方法はまた、現在のグラフ時間をローカルシステム時間に変換するインターフェースを提供する。このインターフェースのパラメータは、グラフのハンドル、変換されるグラフ時間へのポインタ、グラフ時間から導出されたローカルシステム時間に設定される出力を含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。
【００７４】
以上、本発明のグラフ初期化／クリーンアップ関数、グラフ作成／アクセス関数、およびグラフ／ノード情報関数について述べたので、次に、本発明のレコード管理機能に注目して説明する。レコードは、グラフのノード間で通信する方法である。レコードは、グラフを形作り、良好な接続を確実にするために使用される。レコードは、２つの部分、１）バージョン、クリエータ、タイプを含む、レコードについての情報を有するヘッダと、２）グループ全体にわたって押し流されるアプリケーション定義データであるコンテント部とを備える。このコンテント部はまた、データについて述べる名前−値属性をアプリケーションが追加することを可能にするＸＭＬ構造を含む。このフィールドは、探索ＡＰＩが調べる情報を指定するために使用することができる。
【００７５】
本発明の一実施形態によれば、一度ノードがグラフ上で「聴取」されると、ノードは、グループ内で通信され記憶されるデータを操作することができる。アプリケーションが最初にしなければならないことは、レコードを獲得することである。アプリケーションはこれを、１）新規のレコードを作成する、または２）アクセス機能を使用する、という２つの方法のうちのいずれかで行うことができる。新規のレコードを作成するために、アプリケーションは、必要とされる情報およびデータでピアレコードを満たすことによって開始する。これを行った後で、ｐｅｅｒ ｇｒａｐｈ ａｄｄ ｒｅｃｏｒｄ関数を呼び出し、レコードをデータベースに追加する。この関数は、レコードをデータベースに追加することに加えて、グラフ内の残りのノードにレコードを押し流す。
【００７６】
アプリケーションは、そうする代わりに既存のレコードを獲得しようと決めた場合には、本発明のアクセス関数を使用することができる。アプリケーションがデータベースからレコードを取り出すために使用することができるそのような関数がいくつかある。第１は、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｒｅｃｏｒｄ関数である。このＡＰＩは、アプリケーションによって指定されたレコードＩＤ（ＧＵＩＤ）から特定のレコードを取得する。第２は、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩまたはｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩなど、列挙関数を介する。ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩは、レコードタイプ、またはノードの同一性に基づいてレコードの列挙を返す。ｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩは、属性フィールド内のデータに基づいてレコードをフィルタリングするために使用される探索クエリを受け入れる。各ＡＰＩは、（以下で論じる）ピアネットワーク化列挙ＡＰＩと共に使用することができる列挙を返す。
【００７７】
レコードが作成され、または取り出された後で、アプリケーションは、レコードを更新または削除することができる。アプリケーションは、レコードの更新を望む場合、単に望むフィールドを更新し、ｐｅｅｒ ｇｒａｐｈ ｕｐｄａｔｅ ｒｅｃｏｒｄ ＡＰＩを呼び出す。このＡＰＩは、データベース内のレコードを更新し、グラフ内の各ノードにレコードを押し流す。最後に、ｐｅｅｒ ｇｒａｐｈ ｄｅｌｅｔｅ ｒｅｃｏｒｄ ＡＰＩを呼び出すことによって、レコードをグラフから削除することができる。このＡＰＩは、実際にはレコードをデータベースから除去しないことに留意されたい。そのかわりに、このＡＰＩは、削除するためにレコードをマークし、残りのグラフにこの削除を伝える。レコードは、満了するまでデータベースから除去されない。
【００７８】
本発明のＡＰＩによって使用されるレコード管理構造は、ピアデータ構造を含む。アプリケーションが見るこのレコードオブジェクトは、ピアデータ構造によって定義され、そのパラメータとして、バッファポインタによって指されるデータのサイズ（バイト）、およびデータ自体を含むバッファへのポインタを含む。ピアレコードデータ構造は、そのパラメータとして構造のサイズを含み、このサイズは、ピアレコードヘッダのサイズに設定しなければならない。また、パラメータは、レコードのタイプ、Ｐ２Ｐ基本構造によって提供されたレコードのＩＤ、アプリケーションがｐｅｅｒ ｇｒａｐｈ ａｄｄ ｒｅｃｏｒｄ ＡＰＩまたはｕｐｄａｔｅ ｒｅｃｏｒｄ ＡＰＩを呼び出したとき基本構造によって提供されたレコードバージョンを含む。このデータ構造はまた、レコードに適用されるべき任意の特別な処理を示すさまざまなフラグを含むことができる。レコードクリエータの一意の識別子もまた含まれ、レコードを変更する最後の人の一意の識別子も同様である。このデータ構造はまた、ＸＭＬストリングとして指定され、レコードに関連付けられる属性−値ペアの集合を含む。属性は、探索エンジンが、レコードに関連するデータを捜す所である。ここに置かれたレコードの内容についての情報は、エンジンによって見つけ出される。エンジンが属性を認識して「見つける」ために、このストリングは、探索ＸＭＬ方式（ｓｅａｒｃｈ ＸＭＬ ｓｃｈｅｍｅ）に従わなければならない。従わない場合には、探索エンジンは、このレコードに関連する結果を返さないことになる。Ｐ２Ｐ基本構造によって提供されたときレコードが作成されたＵＴＣ時間、レコードが満了するＵＴＣ時間、レコードが最後に修正されたＵＴＣ時間もまた、この構造に含まれる。ＣＲＣチェックサムをデフォルトとして使用するピアデータ構造用のセキュリティデータもまた含まれる。最後に、このデータ構造は、実際のレコードデータを含む。
【００７９】
上記で論じたフラグは、自動リフレッシュと呼ばれるピアレコードフラグを含む。このフラグは、このレコードが満了しようとする際レコードを自動的にリフレッシュするよう、Ｐ２Ｐシステム内で使用されているグループ化ＡＰＩ群に伝えるために使用される。設定することができる他のピアレコードフラグを削除済みと呼ぶ。このフラグは、レコードが削除済みとマークされていることを示す。
【００８０】
以上、本発明のレコード管理ＡＰＩ群およびデータ構造について述べたので、次に、上述した個々のレコード管理ＡＰＩ群の各々の詳細に注目して説明する。最初に、ｐｅｅｒ ｇｒａｐｈ ａｄｄ ｒｅｃｏｒｄ ＡＰＩは、上記で紹介したように、グラフに新しいレコードを追加するために使用される。このＡＰＩを用いて追加されたレコードは、グラフ内の各ノードに送られる。このＡＰＩのパラメータは、グラフハンドル、レコードデータへのポインタ、およびグラフ内のレコードを一意に識別するレコードＩＤに対して設定されるポインタを含む。レコード内では、サイズ、タイプ、および満了だけが必要とされ、一方、データおよび属性は任意選択であることに留意されたい。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。アクセスの拒絶は、追加することができないレコードタイプをピアが追加を試みたとき発生する。
【００８１】
上記で紹介したｐｅｅｒ ｕｐｄａｔｅ ｒｅｃｏｒｄ ＡＰＩは、グラフ内でレコードを更新する。さらに、この関数は、バージョン番号を更新し、グラフ内の各ノードにレコードを押し流す。この関数のパラメータは、グラフハンドル、およびレコードに関連付ける新しいデータへのポインタを含む。修正することができるレコード内のフィールドは、サイズ、フラグ、属性、満了時間（より長い満了時間に）、セキュリティデータ、およびデータ自体である。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。
【００８２】
上記で説明したように、ｐｅｅｒ ｇｒａｐｈ ｄｅｌｅｔｅ ｒｅｃｏｒｄ ＡＰＩは、レコードをグラフ内で削除済みとマークする。このＡＰＩは、実際にはレコードをデータベースから除去しない。そのかわり、レコードを削除済みとマークしてグラフに送り出す。これは、グラフ内の各ノードがデータベースの同一のビューを確実に有するようにするために行われる。このＡＰＩのパラメータは、グラフハンドル、削除するレコードＩＤへのポインタ、およびローカルフラグである。このフラグが真に設定されている場合には、このＡＰＩは、グラフの他のノードにこの削除を送り出さない。このＡＰＩは、そうするかわりにローカルデータベースから除去するだけである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、アクセスの拒絶によるエラーの表示を含む。レコードを削除することは、レコードヘッダ内でピアＲＦ無効フラグ（ｐｅｅｒ ＲＦ ｉｎｖａｌｉｄ ｆｌａｇ）を設定してレコードを更新することにより、レコードを無効とマークして次いでそのレコードを満了させることを意味する。しかし、実際のレコードペイロードは、削除することが好ましい。
【００８３】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｒｅｃｏｒｄ ＡＰＩは、アプリケーションが、レコードＩＤを介して特定のレコードを取り出すことを可能にする。返されたレコードは、ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ ＡＰＩを呼び出すことによって解放すべきである。このＡＰＩのパラメータは、グラフハンドル、取り出すレコードＩＤへのポインタ、取り出されたレコードへのポインタに対して設定されるポインタである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、レコードがデータベースにないことの表示、アクセスの拒絶によるエラーの表示を含む。
【００８４】
ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩは、特定のタイプおよび／またはクリエータのレコードすべてにわたって反復を開始する。これは、現在時間でのレコードのスナップショットである。このＡＰＩのパラメータは、グラフハンドル、反復を行うレコードのタイプへのポインタである。このポインタがＮＵＬＬである場合には、このＡＰＩは、全レコードにわたって反復を行うことになる。このＡＰＩはまた、ピアＩＤを識別するパラメータを含む。指定されている場合には、このＡＰＩは、そのピアＩＤによって作成されたレコード群だけにわたって反復を行うことになる。ＮＵＬＬの場合には、このＡＰＩは、すべてのユーザによって作成されたレコードにわたって反復を行う。このＡＰＩはまた、反復へのハンドルを生成する。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００８５】
ｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩは、特定のレコードを探索するために使用される。このＡＰＩのパラメータは、グラフハンドル、クエリを記述されたＸＭＬストリング、および列挙ハンドルである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、初期化するのに失敗したことによるエラーの表示、他のレコードがないことによるエラーの表示を含む。
【００８６】
新しいレコードがグラフ隣接者から入ってきたとき、ｐｅｅｒ ｇｒａｐｈ ｖａｌｉｄａｔｅ ｄｅｆｅｒｒｅｄ ｒｅｃｏｒｄｓ ＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｃｒｅａｔｅ ＡＰＩまたはｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩへの呼出しの期間中にピアセキュリティインターフェース内で指定されたｖａｌｉｄａｔｅ ｒｅｃｏｒｄ ｃａｌｌｂａｃｋを呼び出すことによって、レコードの妥当性検査を試みることになる。セキュリティモジュールが妥当性検査を実行するのに必要とする情報すべてをまだ有していない場合がある。そのような場合には、このＡＰＩは、レコードの妥当性検査をするのではなく、期間延長エラーメッセージを返すことになる。次に、グラフ処理レイヤは、レコードを一時期間延長テーブルに移動する。セキュリティモジュールは、妥当性検査の実行を準備する際、ｐｅｅｒ ｇｒａｐｈ ｖａｌｉｄａｔｅ ｄｅｆｅｒｒｅｄ ｒｅｃｏｒｄｓ ＡＰＩを呼び出し、グラフ処理レイヤにどの期間延長レコードも再提出するように依頼することができる。パラメータは、グラフハンドル、レコードＩＤ群へのポインタ内に指定されたレコードＩＤ（ｒｅｃｏｒｄ ｉｄｅａ）の数を含む。これがゼロの場合には、グラフ処理レイヤは、現在期間延長されているあらゆるレコードについてｖａｌｉｄａｔｅ ｒｅｃｏｒｄ関数を呼び出すことになる。最後に、このＡＰＩは、再び妥当性検査すべきレコードＩＤの配列へのポインタのパラメータを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラー、および「初期化されていない場合」のエラーの表示を含む。
【００８７】
以上、本発明のレコード管理ＡＰＩ群の説明を完了したので、次に、本発明のグラフ処理ＡＰＩ群の一部を形成するエクスポート／インポートＡＰＩに注目して説明する。アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｅｘｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことにより、データベースを特定のファイルにエクスポートすることができる。アプリケーションは、ノードがグラフに少なくとも１回接続し、上記で論じたｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ＡＰＩをアプリケーションが呼び出した後でのみ行うことができる。アプリケーションはまた、ｐｅｅｒ ｇｒａｐｈ ｉｍｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことにより、データベースをインポートすることができる。アプリケーションは、有効なグラフハンドルを得た後でのみ行うことができる。
【００８８】
ｐｅｅｒ ｇｒａｐｈ ｅｘｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩは、異なるマシンに移動しｐｅｅｒ ｇｒａｐｈ ｉｍｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことによってそこにインポートすることができるファイル内に、グラフデータベースをエクスポートする。このＡＰＩのパラメータは、グラフのハンドル、エクスポートされたデータが記憶されるファイルへのパスである。そのファイルがすでに存在し、いずれかのデータを含む場合には、その中のデータは上書きされることになる。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００８９】
ｐｅｅｒ ｇｒａｐｈ ｉｍｐｏｒｔ ｄａｔａｂａｓｅ ＡＰＩは、ｐｅｅｒ ｉｍｐｏｒｔ ｇｒａｐｈ ｄａｔａｂａｓｅ ＡＰＩを呼び出すことによって得られるグラフデータベースを示すファイルをインポートする。このＡＰＩは、上記で説明したｐｅｅｒ ｇｒａｐｈ ｌｉｓｔｅｎ ＡＰＩをユーザがまだ呼び出していない場合にのみ首尾よく呼び出すことができる。このＡＰＩのパラメータは、グラフのハンドル、およびインポートするファイルへのパスを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００９０】
本発明のグラフ処理ＡＰＩ群はまた、ノードに関係する存在情報の管理および通信を可能にする。ｐｅｅｒ ｇｒａｐｈ ｓｅｔ ｐｒｅｓｅｎｃｅ ＡＰＩは、ノードがグラフに能動的に接続され、グラフを聴取していることを他のグラフメンバに通知するために使用される。このＡＰＩのパラメータは、グラフハンドル、および真の場合にノードが「存在する」情報をそのグラフに押し流されるフラグである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラー、および「初期化されていない場合」のエラーの表示を含む。
【００９１】
ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｎｏｄｅｓ ＡＰＩは、グラフ内のノードすべての列挙を開始するために使用される。グラフポリシーに応じて、接続されている一部のノードは、その存在を公表していないために一覧（ｅｎｕｍｅｒａｔｉｏｎ）に現れない可能性がある。このＡＰＩのパラメータは、グラフハンドル、アプリケーションがノードの一覧を得たいと望むピアＩＤ、存在するピアにわたって反復を行うために使用される列挙ハンドルへのポインタである。アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩを使用して実際のピアを取り出し、ｐｅｅｒ ｇｒａｐｈ ｅｎｄ ｅｎｕｍｅｒａｔｉｏｎ ＡＰＩを使用し、この一覧に関連付けられた資源を解放する。ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｐｒｅｓｅｎｃｅ ＡＰＩへの呼出しから返された列挙ハンドルに対して使用されたとき、ピアノード情報タイプ（ｔｙｐｅ ｐｅｅｒ ｎｏｄｅ ｉｎｆｏｒｍａｔｉｏｎ）のデータを返すことになる。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「初期化されていない場合」のエラーの表示を含む。
【００９２】
本発明のグラフ処理ＡＰＩ群はまた、ユーティリティ／サポート関数を含む。これらは、２タイプのユーティリティ／サポート関数である。第１は列挙サポートであり、第２はメモリサポートである。列挙関数は、アプリケーションが受け取ったピア一覧への任意のハンドルに対して作用する。ピア一覧へのハンドルは、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩおよびｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓなどの関数から得ることができる。一度一覧が得られると、アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｉｔｅｍ ｃｏｕｎｔ ＡＰＩを呼び出すことによって、一覧内のアイテム数を取得することができる。一覧からアイテムを取得するために、アプリケーションは、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩを呼び出さなければならない。アプリケーションは、一覧から受け取りたいアイテムの数を指定することができる。アプリケーションが、一覧内にあるものより多くのアイテムを要求した場合には、この関数は、一覧内のアイテムの数を返す。メモリサポート関数は、ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ関数である。アプリケーションは、グラフ処理ＡＰＩからデータを受け取った場合には、この関数を使用してデータを「解放」しなければならない。さらに、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩは、このＡＰＩを使用して解放しなければならないデータを返す。
【００９３】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩは、ピア一覧へのハンドルを返す任意のＡＰＩへの呼出しによって開始された反復内で次のアイテムを取得する。そのようなＡＰＩは、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｒｅｃｏｒｄｓ ＡＰＩ、ｐｅｅｒ ｇｒａｐｈ ｓｅａｒｃｈ ｒｅｃｏｒｄｓ ＡＰＩ、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｎｅｉｇｈｂｏｒｓ ＡＰＩ、ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｐｒｅｓｅｎｃｅ ＡＰＩを含む。返されたアイテムはすべて、ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ ＡＰＩへの単一の呼出しを使用して解放しなければならない。アプリケーションは、返されるレコードの範囲を要求することができる。このＡＰＩは、要求されたレコードの数以下を返すことになる。返されるデフォルト数は１である。このＡＰＩのパラメータは、列挙ハンドル、読み取るアイテムの数（戻りの際、読み取られたアイテムの実際の数が含まれる）、アイテムの配列へのポインタである。返される実際のデータは、一覧のタイプによって決まる。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、並びに「アイテムが１つもない場合」、および「初期化されていない場合」のエラーの表示を含む。
【００９４】
ｐｅｅｒ ｇｒａｐｈ ｅｎｄ ｅｎｕｍｅｒａｔｉｏｎ ＡＰＩは、一覧に関連付けられたどの資源も終了させ、解放する。一覧が１つもアイテムを含まない場合には、アイテムが１つもないことを示すエラーが返される。このＡＰＩの唯一のパラメータは、クリーンアップする一覧へのハンドルである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効なハンドルによるエラーの表示を含む。
【００９５】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｉｔｅｍ ｃｏｕｎｔ ＡＰＩは、一覧内の最大数のアイテムを取り出すために使用される。一覧において反復している間に、いくつかのアイテムが無効になる可能性があるため、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩから返されるアイテムの数は、ここで返されるアイテム数より少ない可能性がある。これは、ハンドルが最初に作成されたとき、一覧内のアイテムの数を示す。この基本構造の動的な性質のため、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｎｅｘｔ ｉｔｅｍ ＡＰＩを介して取り出されるアイテムの数がこの数に等しくなる保証はない。このＡＰＩのパラメータは、グラフハンドル、一覧内のレコードの数である。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示を含む。
【００９６】
ｐｅｅｒ ｇｒａｐｈ ｆｒｅｅ ｄａｔａ ＡＰＩは、上記で説明したさまざまなグラフ処理ＡＰＩ群によって返された資源を解放する。グラフ処理ＡＰＩによって返されたどのデータも、このＡＰＩを使用して解放しなければならない。このＡＰＩのパラメータは、解放するアイテムへのポインタである。
【００９７】
本発明のシステムおよび方法はまた、ノード対ノード直接通信を実現する。直接通信ＡＰＩ群は、データを押し流す必要なしに、ノードが互いにメッセージを送信することを可能にする。アプリケーションは、隣接者（すなわち、グラフ処理の基本構造のためアプリケーションが接続を有するノード）または直接接続（すなわち、アプリケーションが直接通信ＡＰＩと接続を開始したためローカルノードに接続されている遠隔ノード）にデータを送信することができる。アプリケーションは、直接接続の生成を所望の場合、まずｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩを呼び出さなければならない。これは接続を確立する。一度接続が確立されると、ノードは、ｐｅｅｒ ｇｒａｐｈ ｓｅｎｄ ｄａｔａ ＡＰＩを介して、接続上でデータを送信することができる。アプリケーションは、この送信ＡＰＩ内の「タイプ」パラメータを介して送信されるデータのタイプを記載することができることに留意されたい。アプリケーションは、直接接続を終えた後で、ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩを呼び出して接続を解体しなければならない。直接接続は、グラフの維持を考慮していない。アプリケーションはまた、隣接者フラグを指定すること、およびｐｅｅｒ ｇｒａｐｈ ｓｅｎｄ ｄａｔａ ＡＰＩを使用することによって、隣接者ノードにデータを送信することができる。アプリケーションは、直接接続確立／クローズ関数のどちらも呼び出す必要がない。
【００９８】
これらの直接通信ＡＰＩ群は、ピア接続情報構造と呼ばれる直接通信構造を使用する。この構造のパラメータは、渡される構造のサイズ、この構造が参照する接続のタイプ、この接続の接続ＩＤ、接続される他端のノードのノードＩＤ、アプリケーションが接続を有するノードのピアＩＤ、および接続のアドレスを含む。接続のタイプは、２つのフラグによって示される。ピア接続隣接者フラグ（ｐｅｅｒ ｃｏｎｎｅｃｔｉｏｎ ｎｅｉｇｈｂｏｒ ｆｌａｇ）は、この接続が隣接者接続であることを指定し、ピア接続直接フラグ（ｐｅｅｒ ｃｏｎｎｅｃｔｉｏｎ ｄｉｒｅｃｔ ｆｌａｇ）は、この接続が直接接続であることを指定する。
【００９９】
ｐｅｅｒ ｇｒａｐｈ ｏｐｅｎ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩは、上述の直接接続を生成する。グラフ処理ＡＰＩ群は、データを送信するために、アプリケーションがグラフ内のノードとの接続を確立することを可能にする。この接続は、グラフ維持に役立たない。このＡＰＩのパラメータは、グラフのハンドル、あるアドレスで接続される人の一意のＩＤ（指定されたアドレスで複数の同一性が接続される可能性があるため必要とされる）、接続されるノードのアドレスなどについての詳細を含む構造へのポインタ、および直接接続の接続ＩＤを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「所与のＩＤを有するピアが存在しない場合」のエラーの表示を含む。また、ピアノードが接続を拒否したことを示すためのエラーがある。
【０１００】
ｐｅｅｒ ｇｒａｐｈ ｃｌｏｓｅ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ ＡＰＩは、特定の直接接続を閉鎖する。このＡＰＩのパラメータは、グラフのハンドル、および切断する隣接者のＩＤである。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「所与のＩＤを有する接続が存在しない場合」のエラーの表示を含む。
【０１０１】
ｐｅｅｒ ｇｒａｐｈ ｓｅｎｄ ｄａｔａ ＡＰＩは、接続されている隣接者または直接接続にデータを送信するために使用される。この関数は、データがネットワークレイヤに渡されると直ちに戻ることになる。換言すれば、グラフ処理レイヤは、他方の側からの肯定応答を待たない。このＡＰＩのパラメータは、グラフのハンドル、データを送信する接続の一意の識別子、送信されるデータのアプリケーション定義「タイプ」、次のパラメータによって指されるバイト数、隣接者に送信する実際のデータを含む。このポイントツーポイントデータを受け取るための機構の特徴は、ピアグラフイベント入来データタイプ（ｔｙｐｅ ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｉｎｃｏｍｉｎｇ ｄａｔａ）のイベントに登録することにある。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「接続が存在しない場合」のエラーの表示を含む。
【０１０２】
ｐｅｅｒ ｇｒａｐｈ ｅｎｕｍｅｒａｔｅ ｃｏｎｎｅｃｔｉｏｎｓ ＡＰＩは、そのパラメータとして、グラフのハンドル、上記で論じたピア接続フラグに基づいて列挙する接続のタイプ、および接続の一覧へのポインタを含む。このＡＰＩは、成功または失敗の表示を返す。このエラー表示は、無効な引数によるエラーの表示、および「接続が存在しない場合」のエラーの表示を含む。
【０１０３】
本発明のイベントインフラストラクチャは、グラフとそれに関連付けられたデータの変更についてアプリケーションに通知することを可能にする。アプリケーションが変更について通知を受け取りたい場合には、アプリケーションが最初にしなければならないことは、通知を受けたいイベントを特定する登録構造を完成させることである。この登録により、アプリケーションは、通知を受けたいイベントタイプを指定することが可能になる。イベントが、関連付けの可能な特定のタイプのデータを有する場合には、これもまた登録内で指定される。たとえば、アプリケーションは、特定のレコードタイプの変更について通知するために登録することができる。そのためには、アプリケーションは、イベントタイプとしてピアグラフイベントレコード変更済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅｄ）イベント、および通知を受けたいレコードタイプのＧＵＩＤを指定する登録構造を作成する。
【０１０４】
アプリケーションは、登録構造を得た後で、ｐｅｅｒ ｇｒａｐｈ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩを呼び出し、そのイベントを関連付けたいイベントハンドルを指定する。あるイベントハンドルにいくつかのイベントを関連付けることができることに留意されたい。一度アプリケーションが関心のあるイベントが発生したならば、イベントハンドルは、イベントが発生したことを知らされる。次いで、アプリケーションは、そのイベントに関連付けられたデータを取り出すために、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａ ＡＰＩを呼び出さなければならない。このＡＰＩは、２つの重要なデータを含む構造を返す。第１は、イベントに関連付けられた登録であり、第２は、そのイベントに関連付けられたデータである。アプリケーションは、アイテムが１つもないことを示すエラーメッセージが発生するまで、引き続きｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａを呼び出すべきである。アプリケーションは、特定のハンドルに関連付けられたイベントについてもはや通知を望まないとき、ｐｅｅｒ ｇｒａｐｈ ｕｎ−ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩを呼び出すことによって、単にその関心を登録抹消する。
【０１０５】
本発明のイベントインフラストラクチャは、７つのデータ構造を使用する。第１は、ピアグラフイベント登録（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｇｉｓｔｒａｔｉｏｎ）構造である。アプリケーションは、イベント通知に登録するとき、通知登録を解釈するために必要とされるコンテキストデータを含み、および通知が発生すると通知に関連するデータを返すために使用されるピアイベント登録構造の配列を提供する。この構造のパラメータは、ピアが関心のあるイベントのタイプ（下記で指定されるイベントタイプの１つでなければならない）、およびレコードタイプを含む。指定されたイベントタイプがレコードに作用する場合には、指定されたレコードタイプのレコードに対してだけイベントを発するように、このレコードタイプを指定することができる。このパラメータは、すべてのレコードタイプについてイベントを発生させるためにＮＵＬＬとすることができる。このフィールドは、レコードに対して作用するイベントタイプについて無視される。この登録は、アプリケーションが通知を受けたいイベントタイプを取る。
【０１０６】
イベントタイプは、グラフが変更済み状況を有する（接続された、など）、グラフプロパティ構造内のフィールドが変更された（このイベントが発せられた場合には、アプリケーションはすでに変更を有し、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｐｒｏｐｅｒｔｉｅｓ ＡＰＩを使用して、更新された構造を取得しなければならないため、データは使用可能でない）、レコードタイプ（または特定のレコード）が何らかの形で変更された、ピアの直接接続が変更された、ピア隣接者との接続が変更された、直接または隣接者接続から（フラッディングではなく）データが受信された、グラフが不安定になった（クライアントは、新しいノード上でｐｅｅｒ ｇｒａｐｈ ｃｏｎｎｅｃｔ ＡＰＩを呼び出すことによって応答すべきである）、グラフ内でノードの存在状況が変更された、およびある種のレコードタイプの同期がとられたことに関するイベントを含むことができる。
【０１０７】
アプリケーションは、一度イベント通知を受け取ると、データをそのイベントに関連付けることができる。データはすべて、ピアグラフイベントデータ（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄａｔａ）構造内に一般化される。イベントに応じて、ユニオン内の適切なフィールドが書き込まれる（ｆｉｌｌ ｏｕｔ）。ユニオン内のフィールドの１つを除くすべては、この構造へのポインタである。ユニオンの各メンバが定義される。構造内のどれも「設定」することができない。イベントタイプはイベントに対応するイベントデータであり、状態フィールドは、ピアグラフイベント状態変更（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｓｔａｔｕｓ ｃｈａｎｇｅ）イベントが発せられた場合に書き込まれる。これは、ノードのグラフとの接続に関して何かが起こったことを意味する。入来データフィールドは、ピアグラフイベント隣接者データ（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｅｉｇｈｂｏｒ ｄａｔａ）またはピアグラフイベント直接データ（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄｉｒｅｃｔ ｄａｔａ）イベントが発せられた場合に書き込まれる。これは、隣接者または直接接続から送られたのではなくノードがデータを受信したことを意味する。レコード変更データフィールドは、ピアグラフイベントレコード変更（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅ）イベントが発せられた場合に書き込まれる。これは、アプリケーションが通知を依頼したレコードまたはレコードタイプが変更されたことを意味する。接続変更データフィールドは、ピアグラフイベント隣接者接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｅｉｇｈｂｏｒ ｃｏｎｎｅｃｔｉｏｎ）またはピアグラフイベント直接接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ）イベントが発せられた場合に書き込まれる。これは、隣接者または直接接続状態の何らかの面が変更されたことを意味する。ノード変更データフィールドは、ピアグラフイベントノード変更済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｏｄｅ ｃｈａｎｇｅｄ）イベントが発せられた場合に書き込まれる。これは、グラフ存在状態内の何らかのノードが変更されたことを意味する。同期データフィールドは、ピアグラフイベント同期済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｓｙｎｃｈｒｏｎｉｚｅｄ）イベントが発せられた場合に書き込まれる。これは、何らかのレコードタイプが同期するのを終えたことを意味する。
【０１０８】
ピアイベント入来データ（ｐｅｅｒ ｅｖｅｎｔ ｉｎｃｏｍｉｎｇ ｄａｔａ）構造では、ユニオンは、入来データイベントが発せられた場合にデータへのポインタを含む。これは、隣接者または直接接続からの押し流しでなくノードがデータを受信したことを意味する。この構造のフィールドは、構造のサイズ、データが来た接続の一意の識別子、入来データのアプリケーション定義データタイプ、および受け取った実際のデータを含む。
【０１０９】
ピアイベントレコード変更データ（ｐｅｅｒ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅ ｄａｔａ）は、ピアグラフイベントレコード変更（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｒｅｃｏｒｄ ｃｈａｎｇｅ）イベントが発せられた場合にユニオンがそれへのポインタを含む構造である。これは、アプリケーションが通知を依頼したレコードまたはレコードタイプが変更されたことを意味する。この構造は、構造のサイズ、アプリケーションがイベントを登録したレコードまたはレコードタイプに発生した変更のタイプ、変更された一意のレコードＩＤ、および変更された一意のレコードタイプを含む。ピアレコード変更タイプは、レコードＩＤまたはレコードタイプがデータベースに追加されたことを示すためのピアレコード追加済み（ｐｅｅｒ ｒｅｃｏｒｄ ａｄｄｅｄ）タイプ、レコードＩＤまたはレコードタイプがグラフ内で更新されたことを示すためのピアレコード更新済み（ｐｅｅｒ ｒｅｃｏｒｄ ｕｐｄａｔｅｄ）タイプ、レコードＩＤまたはレコードタイプがグラフから削除されたことを示すためのピアレコード削除済み（ｐｅｅｒ ｒｅｃｏｒｄ ｄｅｌｅｔｅｄ）タイプ、およびレコードＩＤまたはレコードタイプがデータベースから消滅したことを示すためのピアレコード満了済み（ｐｅｅｒ ｒｅｃｏｒｄ ｅｘｐｉｒｅｄ）タイプを含む。
【０１１０】
ピアイベント接続変更データ（ｐｅｅｒ ｅｖｅｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｈａｎｇｅ ｄａｔａ）構造は、ピアグラフイベント隣接者接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｅｉｇｈｂｏｒ ｃｏｎｎｅｃｔｉｏｎ）イベントまたはピアグラフイベント直接接続（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｄｉｒｅｃｔ ｃｏｎｎｅｃｔｉｏｎ）イベントが発せられた場合にユニオンがそれへのポインタを含む構造である。これは、隣接者または直接接続状態の何らかの面が変更されたことを意味する。この構造は、構造のサイズ、隣接者または直接接続が受けた変更のタイプ、変更元の接続の一意の識別子、および変更元のノードの一意の識別子を含む。ピア接続状況タイプは、新しいノードがローカルノードに接続されたことを示すピア接続済み（ｐｅｅｒ ｃｏｎｎｅｃｔｅｄ）タイプ、接続が切断された（ローカルノードによって、または遠隔ノードによって行うことができる）ことを示すピア切断済み（ｐｅｅｒ ｄｉｓｃｏｎｎｅｃｔｅｄ）タイプ、およびそのノードへの接続の試みが失敗したことを示すピア接続失敗（ｐｅｅｒ ｃｏｎｎｅｃｔｉｏｎ ｆａｉｌｅｄ）タイプを含む。
【０１１１】
ピアイベントノード変更データ（ｐｅｅｒ ｅｖｅｎｔ ｎｏｄｅ ｃｈａｎｇｅ ｄａｔａ）構造は、ピアグラフイベントノード変更済み（ｐｅｅｒ ｇｒａｐｈ ｅｖｅｎｔ ｎｏｄｅ ｃｈａｎｇｅｄ）イベントが発せられた場合にユニオンがそれへのポインタを含む構造である。これは、グラフ内の何らかのノードが、その存在状態を変更したことを意味する。この構造は、構造のサイズ、ノードの新しい存在状態（ピア存在変更タイプ）、変更されたノードのグラフの一意のＩＤ、および変化したノードのピアＩＤを含む。ピア存在変更タイプは、ノードがグラフ内に存在するようになったことを示すピア存在変更接続済み（ｐｅｅｒ ｐｒｅｓｅｎｃｅ ｃｈａｎｇｅ ｃｏｎｎｅｃｔｅｄ）タイプ、ノードがグラフから消えたことを示すピア存在変更切断済み（ｐｅｅｒ ｐｒｅｓｅｎｃｅ ｃｈａｎｇｅ ｄｉｓｃｏｎｎｅｃｔｅｄ）タイプ、およびノードがその情報（たとえば、属性）を更新したことを示すピア存在変更更新済み（ｐｅｅｒ ｐｒｅｓｅｎｃｅ ｃｈａｎｇｅ ｕｐｄａｔｅｄ）タイプを含む。
【０１１２】
ピアイベント同期済みデータ（ｐｅｅｒ ｅｖｅｎｔ ｓｙｎｃｈｒｏｎｉｚｅｄ ｄａｔａ）構造は、構造のサイズ、および同期されたレコードのタイプを含む。
【０１１３】
以上、イベントインフラストラクチャと、その中で使用されるデータ構造について述べたので、次に、個々のＡＰＩ群の詳細に注目して説明する。ｐｅｅｒ ｇｒａｐｈ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩは、グラフおよびイベントタイプに関連する変更について通知を受けることへのピアの関心を登録する。このＡＰＩのパラメータは、グラフのハンドル、新しいイベントに基づいて伝えられるイベントハンドルを含む。イベントハンドルは、自動リセットとすべきである。伝えられたとき、アプリケーションは、取り出すアイテムが１つもないことの表示が返されるまで、ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａ ＡＰＩを呼び出さなければならない。また、パラメータは、ピアイベント登録データ構造の数のカウント、要求されている通知についてのデータを含むピアイベント登録データ構造の配列へのポインタ、および通知を登録抹消するためのｐｅｅｒ ｕｎ−ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ｈａｎｄｌｅ ＡＰＩへの呼出しの中で使用することができるピアイベントハンドルを含む。このＡＰＩは、成功または失敗の表示を返す。この失敗表示は、無効な引数による失敗の表示を含む。
【０１１４】
ｐｅｅｒ ｇｒａｐｈ ｕｎ−ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ＡＰＩは、グラフおよびレコードタイプに関連する変更について通知を受けることへのアプリケーションの関心を登録抹消する。このＡＰＩのパラメータは、ｐｅｅｒ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ｈａｎｄｌｅ ＡＰＩへの呼出しから得られたハンドルである。このＡＰＩは、成功または失敗の表示を返す。この失敗表示は、無効な引数による失敗の表示を含む。
【０１１５】
ｐｅｅｒ ｇｒａｐｈ ｇｅｔ ｅｖｅｎｔ ｄａｔａ ＡＰＩは、アプリケーションがイベントを取り出すことを可能にする。取り出すイベントが１つもないことを示す表示が返される。イベントはすべて、データをピアグラフイベントデータ構造の形態で受け取る。どのイベントが発せられたかに応じて、対応するデータ構造が返される。このＡＰＩのパラメータは、ｐｅｅｒ ｒｅｇｉｓｔｅｒ ｅｖｅｎｔ ｈａｎｄｌｅ ＡＰＩへの呼出しによって得られたハンドル、および通知についてのデータを含む。
【０１１６】
Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＸＰオペレーティングシステムに特に適した本発明のインターフェースおよび方法の一実施形態においては、ＡＰＩ群を以下のようにすることができる。
【０１１７】
【表１】
【０１１８】
【表２】
【０１１９】
【表３】
【０１２０】
【表４】
【０１２１】
本発明のさまざまな実施形態に関する前記説明は、例示および説明のために提供されている。消尽、または開示されたその実施形態に本発明を限定することは意図されていない。上記の示唆に鑑みて、多数の修正形態または変形形態が可能である。考察した実施形態は、本発明の原理とその実際的な応用を最もよく示し、それによって、さまざまな実施形態で、および企図されている特定の使用に適したさまざまな修正形態と共に、当業者が本発明を使用することを可能にするように選択され述べられた。そのような修正形態および変形形態はすべて、添付の特許請求の範囲が公平に、法的に、正当に権利を与えられる広さに従って解釈されたとき、添付の特許請求の範囲によって決定される本発明の範囲内にある。
【符号の説明】
【０１２２】
１００ コンピューティングシステム環境
１１０ コンピュータ
１２０ 処理装置
１３０ システムメモリ
１２１ システムバス
１３１ ＲＯＭ
１３２ ＲＡＭ
１３３ 基本入出力システム（ＢＩＯＳ）
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ インターフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ インターフェース
１５１ 磁気ディスクドライブ
１５２ 取外し可能な不揮発性磁気ディスク
１５５ 光ディスクドライブ
１５６ 取外し可能な不揮発性光ディスク
１６０ ユーザ入力インターフェース
１６１ ポインティングデバイス
１６２ キーボード
１７０ ネットワークインターフェースまたはアダプタ
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ 広域ネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８１ メモリ記憶デバイス
１８５ 遠隔アプリケーションプログラム
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺機器インターフェース
１９６ プリンタ
１９７ スピーカ
２００ Ｐ２Ｐフレームワーク
２０２ Ｐ２Ｐグラフ処理インターフェース
２０４ データ記憶
２０６ Ｐ２Ｐグラフセキュリティ管理インターフェース
２０８ Ｐ２Ｐ名前−アドレス解決
２１０ 同一性管理インターフェース
２１２ グループ化インターフェース
【特許請求の範囲】
【請求項１】
複数のノードを含むネットワークにおいてアプリケーションプログラムが通信を行って、ピアツーピアグラフを管理するための、前記複数のノードのうちのいずれかのノードにより処理される方法であって、
前記アプリケーションプログラムから、
取り出されるノードのグラフハンドル、情報が望まれるノードのノード識別、および前記ノードについての情報を含むピアノード情報データ構造へのポインタを含む複数の呼出しパラメータを有するノード情報取得呼出し、
設定されるノードのグラフハンドル、および前記ノードに関連付ける属性を表すストリングを含む複数の呼出しパラメータを有するノード属性設定呼出し、
取り出されるグラフプロパティのグラフハンドル、およびグラフプロパティへのポインタを含む複数の呼出しパラメータを有するグラフプロパティ取得呼出し、
グループハンドル、前記グループハンドルに対応する現在前記グループの状況として設定されている１組のピアグラフ状況フラグを含む複数の呼出しパラメータを有するグラフ状況取得呼出し、
設定されるグラフプロパティのグラフハンドル、およびグラフプロパティデータ構造へのポインタを含む複数の呼出しパラメータを有するグラフプロパティ設定呼出し、および
時間変換のグラフハンドル、変換されるグラフ時間へのポインタ、およびグラフ時間から導出されたローカルシステム時間へのポインタを含む複数の呼出しパラメータを有するグラフ時間からのシステム変換呼出し、からなるグループから選択された複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップと、
前記グラフ管理呼出しを構文解析し、前記複数の呼出しパラメータを取り出すステップと、
前記グラフ管理呼出しの成功／失敗を示す値を前記アプリケーションプログラムに返すステップと
を備え、
前記複数のノードの各ノードは、ネットワーク内の他のノードへの参照のリストを含むルーティングテーブルを蓄積し、該ノードについて、ノード識別、アドレス、ノードのキー、該ノードのキーとローカルノードのキーとの間の距離を含むアドレス情報を獲得し、
前記グラフ内の前記複数のノードすべてに送信されるデータ群であるレコードが前記ノードによって受信された後で、前記ノードは該レコードをデータベースまたはデータ記憶内に配置することを特徴とする方法。
【請求項２】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、グラフのプロパティ群、作成時に前記グラフに関連付けるデータベースの名前、前記グラフ用のセキュリティプロバイダについての情報、および前記グラフへのハンドルを含む複数の呼出しパラメータを有するグラフ作成呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、開かれるグラフの識別子である第１の一意の識別子、前記グラフを開く人の識別子である第２の一意の識別子、前記グラフ用のセキュリティプロバイダについての情報、配列内のレコードタイプ数、レコードが同期される順序を示すレコードタイプの配列、および前記グラフへのハンドルを含む複数の呼出しパラメータを有するグラフオープン呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、聴取するグラフへのハンドル、聴取するＩＰｖ６スコープ、聴取するＩＰｖ６スコープ識別子、および聴取するポートを含む複数の呼出しパラメータを有するグラフ聴取呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、接続されるグラフのハンドル、１つのＩＰアドレスで接続される人の一意の識別、前記人についての情報を含むデータ構造へのポインタ、および接続識別へのポインタを含む複数の呼出しパラメータを有するグラフ接続呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、切断するグラフへのハンドルを含む複数の呼出しパラメータを有するグラフクローズ呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、データを削除するグラフの名前、データを削除するピア識別、および削除するグラフに関連付けられたデータベースの名前を含む複数の呼出しパラメータを有するグラフ削除呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
アプリケーションプログラムとサーバプロセスの間で通信を行って、ピアツーピアグラフを管理する方法であって、
前記アプリケーションプログラムから、
取り出されるノードのグラフハンドル、情報が望まれるノードのノード識別、および前記ノードについての情報を含むピアノード情報データ構造へのポインタを含む複数の呼出しパラメータを有するノード情報取得呼出し、
設定されるノードのグラフハンドル、および前記ノードに関連付ける属性を表すストリングを含む複数の呼出しパラメータを有するノード属性設定呼出し、
取り出されるグラフプロパティのグラフハンドル、およびグラフプロパティへのポインタを含む複数の呼出しパラメータを有するグラフプロパティ取得呼出し、
グループハンドル、前記グループハンドルに対応する現在前記グループの状況として設定されている１組のピアグラフ状況フラグを含む複数の呼出しパラメータを有するグラフ状況取得呼出し、
設定されるグラフプロパティのグラフハンドル、およびグラフプロパティデータ構造へのポインタを含む複数の呼出しパラメータを有するグラフプロパティ設定呼出し、および
時間変換のグラフハンドル、変換されるグラフ時間へのポインタ、およびグラフ時間から導出されたローカルシステム時間へのポインタを含む複数の呼出しパラメータを有するグラフ時間からのシステム変換呼出し、からなるグループから選択された複数の呼出しパラメータを有するグラフおよびノード情報管理呼出しを受信するステップと、
前記グラフおよびノード情報管理呼出しを構文解析し、前記複数の呼出しパラメータを取り出すステップと、
前記グラフおよびノード情報管理呼出しの成功／失敗を示す値を前記アプリケーションプログラムに返すステップと
を備えたことを特徴とする方法。
【請求項９】
複数のノードを含むネットワークにおいてアプリケーションプログラムが通信を行って、ピアツーピアグラフを管理するための、前記複数のノードのうちのいずれかのノードにより処理される方法であって、
前記アプリケーションプログラムから、
レコード追加のグラフハンドル、レコードデータへのポインタ、およびグラフ内のレコードを一意に識別するレコード識別へのポインタを含む複数の呼出しパラメータを有するレコード追加呼出し、
レコード更新のグラフハンドル、および更新されるレコードに関連付ける新しいデータへのポインタを含む複数の呼出しパラメータを有するレコード更新呼出し、
レコード削除のグラフハンドル、削除するレコードのレコード識別へのポインタ、および前記レコードがローカルデータベース内にあるかどうかの表示を含む複数の呼出しパラメータを有するレコード削除呼出し、
レコード取出しのグラフハンドル、取り出すレコードのレコード識別へのポインタ、および前記取り出されたレコードへのポインタを含む複数の呼出しパラメータを有するレコード取得呼出し、
レコード列挙のグラフハンドル、反復を行うレコードのタイプへのポインタ、レコードを反復すべきピア識別へのポインタ、および反復へのハンドルを含む複数の呼出しパラメータを有するレコード列挙呼出し、
レコード探索のグラフハンドル、クエリが記述されたＸＭＬストリング、および列挙ハンドルを含む複数の呼出しパラメータを有するレコード探索呼出し、および
妥当性検査期間延長レコードのグラフハンドル、再び妥当性検査をすべきレコード識別の配列内のレコード数、および再び妥当性検査をすべきレコード識別の前記配列を含む複数の呼出しパラメータを有する期間延長レコード妥当性検査呼出し、からなるグループから選択された複数の呼出しパラメータを有するレコード管理呼出しを受信するステップと、
前記レコード管理呼出しを構文解析し、前記複数の呼出パラメータを取り出すステップと、
前記レコード管理呼出しの成功／失敗を示す値を前記アプリケーションプログラムに返すステップと
を備えたことを特徴とする方法。
【請求項１】
複数のノードを含むネットワークにおいてアプリケーションプログラムが通信を行って、ピアツーピアグラフを管理するための、前記複数のノードのうちのいずれかのノードにより処理される方法であって、
前記アプリケーションプログラムから、
取り出されるノードのグラフハンドル、情報が望まれるノードのノード識別、および前記ノードについての情報を含むピアノード情報データ構造へのポインタを含む複数の呼出しパラメータを有するノード情報取得呼出し、
設定されるノードのグラフハンドル、および前記ノードに関連付ける属性を表すストリングを含む複数の呼出しパラメータを有するノード属性設定呼出し、
取り出されるグラフプロパティのグラフハンドル、およびグラフプロパティへのポインタを含む複数の呼出しパラメータを有するグラフプロパティ取得呼出し、
グループハンドル、前記グループハンドルに対応する現在前記グループの状況として設定されている１組のピアグラフ状況フラグを含む複数の呼出しパラメータを有するグラフ状況取得呼出し、
設定されるグラフプロパティのグラフハンドル、およびグラフプロパティデータ構造へのポインタを含む複数の呼出しパラメータを有するグラフプロパティ設定呼出し、および
時間変換のグラフハンドル、変換されるグラフ時間へのポインタ、およびグラフ時間から導出されたローカルシステム時間へのポインタを含む複数の呼出しパラメータを有するグラフ時間からのシステム変換呼出し、からなるグループから選択された複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップと、
前記グラフ管理呼出しを構文解析し、前記複数の呼出しパラメータを取り出すステップと、
前記グラフ管理呼出しの成功／失敗を示す値を前記アプリケーションプログラムに返すステップと
を備え、
前記複数のノードの各ノードは、ネットワーク内の他のノードへの参照のリストを含むルーティングテーブルを蓄積し、該ノードについて、ノード識別、アドレス、ノードのキー、該ノードのキーとローカルノードのキーとの間の距離を含むアドレス情報を獲得し、
前記グラフ内の前記複数のノードすべてに送信されるデータ群であるレコードが前記ノードによって受信された後で、前記ノードは該レコードをデータベースまたはデータ記憶内に配置することを特徴とする方法。
【請求項２】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、グラフのプロパティ群、作成時に前記グラフに関連付けるデータベースの名前、前記グラフ用のセキュリティプロバイダについての情報、および前記グラフへのハンドルを含む複数の呼出しパラメータを有するグラフ作成呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、開かれるグラフの識別子である第１の一意の識別子、前記グラフを開く人の識別子である第２の一意の識別子、前記グラフ用のセキュリティプロバイダについての情報、配列内のレコードタイプ数、レコードが同期される順序を示すレコードタイプの配列、および前記グラフへのハンドルを含む複数の呼出しパラメータを有するグラフオープン呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、聴取するグラフへのハンドル、聴取するＩＰｖ６スコープ、聴取するＩＰｖ６スコープ識別子、および聴取するポートを含む複数の呼出しパラメータを有するグラフ聴取呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、接続されるグラフのハンドル、１つのＩＰアドレスで接続される人の一意の識別、前記人についての情報を含むデータ構造へのポインタ、および接続識別へのポインタを含む複数の呼出しパラメータを有するグラフ接続呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、切断するグラフへのハンドルを含む複数の呼出しパラメータを有するグラフクローズ呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記アプリケーションプログラムから、複数の呼出しパラメータを有するグラフ管理呼出しを受信するステップは、データを削除するグラフの名前、データを削除するピア識別、および削除するグラフに関連付けられたデータベースの名前を含む複数の呼出しパラメータを有するグラフ削除呼出しを、前記アプリケーションプログラムから受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
アプリケーションプログラムとサーバプロセスの間で通信を行って、ピアツーピアグラフを管理する方法であって、
前記アプリケーションプログラムから、
取り出されるノードのグラフハンドル、情報が望まれるノードのノード識別、および前記ノードについての情報を含むピアノード情報データ構造へのポインタを含む複数の呼出しパラメータを有するノード情報取得呼出し、
設定されるノードのグラフハンドル、および前記ノードに関連付ける属性を表すストリングを含む複数の呼出しパラメータを有するノード属性設定呼出し、
取り出されるグラフプロパティのグラフハンドル、およびグラフプロパティへのポインタを含む複数の呼出しパラメータを有するグラフプロパティ取得呼出し、
グループハンドル、前記グループハンドルに対応する現在前記グループの状況として設定されている１組のピアグラフ状況フラグを含む複数の呼出しパラメータを有するグラフ状況取得呼出し、
設定されるグラフプロパティのグラフハンドル、およびグラフプロパティデータ構造へのポインタを含む複数の呼出しパラメータを有するグラフプロパティ設定呼出し、および
時間変換のグラフハンドル、変換されるグラフ時間へのポインタ、およびグラフ時間から導出されたローカルシステム時間へのポインタを含む複数の呼出しパラメータを有するグラフ時間からのシステム変換呼出し、からなるグループから選択された複数の呼出しパラメータを有するグラフおよびノード情報管理呼出しを受信するステップと、
前記グラフおよびノード情報管理呼出しを構文解析し、前記複数の呼出しパラメータを取り出すステップと、
前記グラフおよびノード情報管理呼出しの成功／失敗を示す値を前記アプリケーションプログラムに返すステップと
を備えたことを特徴とする方法。
【請求項９】
複数のノードを含むネットワークにおいてアプリケーションプログラムが通信を行って、ピアツーピアグラフを管理するための、前記複数のノードのうちのいずれかのノードにより処理される方法であって、
前記アプリケーションプログラムから、
レコード追加のグラフハンドル、レコードデータへのポインタ、およびグラフ内のレコードを一意に識別するレコード識別へのポインタを含む複数の呼出しパラメータを有するレコード追加呼出し、
レコード更新のグラフハンドル、および更新されるレコードに関連付ける新しいデータへのポインタを含む複数の呼出しパラメータを有するレコード更新呼出し、
レコード削除のグラフハンドル、削除するレコードのレコード識別へのポインタ、および前記レコードがローカルデータベース内にあるかどうかの表示を含む複数の呼出しパラメータを有するレコード削除呼出し、
レコード取出しのグラフハンドル、取り出すレコードのレコード識別へのポインタ、および前記取り出されたレコードへのポインタを含む複数の呼出しパラメータを有するレコード取得呼出し、
レコード列挙のグラフハンドル、反復を行うレコードのタイプへのポインタ、レコードを反復すべきピア識別へのポインタ、および反復へのハンドルを含む複数の呼出しパラメータを有するレコード列挙呼出し、
レコード探索のグラフハンドル、クエリが記述されたＸＭＬストリング、および列挙ハンドルを含む複数の呼出しパラメータを有するレコード探索呼出し、および
妥当性検査期間延長レコードのグラフハンドル、再び妥当性検査をすべきレコード識別の配列内のレコード数、および再び妥当性検査をすべきレコード識別の前記配列を含む複数の呼出しパラメータを有する期間延長レコード妥当性検査呼出し、からなるグループから選択された複数の呼出しパラメータを有するレコード管理呼出しを受信するステップと、
前記レコード管理呼出しを構文解析し、前記複数の呼出パラメータを取り出すステップと、
前記レコード管理呼出しの成功／失敗を示す値を前記アプリケーションプログラムに返すステップと
を備えたことを特徴とする方法。
【図１】
【図２】
【図２】
【公開番号】特開２０１１−１８８４８６（Ｐ２０１１−１８８４８６Ａ）
【公開日】平成２３年９月２２日（２０１１．９．２２）
【国際特許分類】
【出願番号】特願２０１１−４３１３４（Ｐ２０１１−４３１３４）
【出願日】平成２３年２月２８日（２０１１．２．２８）
【分割の表示】特願２００３−４０３８２７（Ｐ２００３−４０３８２７）の分割
【原出願日】平成１５年１２月２日（２００３．１２．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２３年９月２２日（２０１１．９．２２）
【国際特許分類】
【出願日】平成２３年２月２８日（２０１１．２．２８）
【分割の表示】特願２００３−４０３８２７（Ｐ２００３−４０３８２７）の分割
【原出願日】平成１５年１２月２日（２００３．１２．２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]