(57)【特許請求の範囲】
【請求項１】
ピアツーピアネットワークにおいてピアノードの識別を第１のノードに提供する方法であって、前記ピアノードの識別は、第２のノード内にキャッシュされるピアノードの識別から選択される方法において、
第２のノードにおいて、ピア名前解決プロトコル識別（ＰＮＲＰ  ＩＤｓ）を要求する前記第１のノードから、少なくともヘッダメッセージ要素およびハッシュされたｎｏｎｃｅ要素を含むＳＯＬＩＣＩＴメッセージを受信するステップと、
前記第２のノードにおいて、少なくともヘッダ肯定応答メッセージ要素、前記ハッシュされたｎｏｎｃｅメッセージ要素、およびＰＮＲＰ  ＩＤ配列メッセージ要素を含み、前記ＰＮＲＰ  ＩＤ配列メッセージ要素が前記第２のノードのキャッシュ内のＰＮＲＰ  ＩＤのリストを含む、ＡＤＶＥＲＴＩＳＥメッセージを生成するステップであって、該ハッシュされたｎｏｎｃｅメッセージ要素は、前記ＳＯＬＩＣＩＴメッセージに含まれるハッシュされたｎｏｎｃｅメッセージ要素からコピーされるステップと、
前記ＡＤＶＥＲＴＩＳＥメッセージを前記第１のノードに送信するステップと
を備えることを特徴とする方法。
【請求項２】
ピアツーピアネットワークにおいて認証ピアアドレス（ＣＰＡ）のセットを第１のノードに伝播する方法であって、
第２のノードにおいて、前記ＣＰＡのセットのフラッディングを要求する前記第１のノードから、少なくとも第１のヘッダメッセージ要素、ｎｏｎｃｅメッセージ要素、およびＰＮＲＰ  ＩＤ配列メッセージ要素を含むＲＥＱＵＥＳＴメッセージを受信するステップであって、前記ＰＮＲＰ  ＩＤ配列メッセージ要素が前記ＣＰＡのセットに対応するＰＮＲＰ  ＩＤのリストを含み、前記ＰＮＲＰ  ＩＤ配列メッセージ要素は、前記第２のノードから受信したＡＤＶＥＲＴＩＳＥメッセージに含まれるＰＮＲＰ  ＩＤ配列メッセージ要素から前記第１のノードにおいて選択されるステップと、
前記第２のノードにおいて、前記ＲＥＱＵＥＳＴメッセージに含まれるｎｏｎｃｅメッセージ要素をハッシュして、ハッシュされた該ｎｏｎｃｅメッセージ要素がＳＯＬＩＣＩＴメッセージ内で受信したハッシュされたｎｏｎｃｅメッセージ要素と一致するかチェックし、一致する場合、前記ＰＮＲＰ  ＩＤ配列メッセージ要素の既知のＰＮＲＰ  ＩＤの各々に対しＦＬＯＯＤメッセージを生成するステップであって、既知のＰＮＲＰ  ＩＤの各々は、前記第２のノードのキャッシュ内のＰＮＲＰ  ＩＤに対応し、前記ＦＬＯＯＤメッセージは、少なくとも第２のヘッダメッセージ要素、フラッドコントロールメッセージ要素、既知のＰＮＲＰ  ＩＤの各々に対応するＣＰＡ最良一致メッセージ要素、およびフラッディングされるリストを含むＩＰＶ６エンドポイント配列メッセージ要素を含むステップと、
前記ＦＬＯＯＤメッセージを前記第１のノードに送信するステップと
を備えることを特徴とする方法。
【請求項３】
前記第２のノードにおいて、少なくとも第３のヘッダメッセージ要素およびヘッダ肯定応答メッセージ要素を含むＡＣＫメッセージが前記第１のノードから受信された場合、前記ＦＬＯＯＤメッセージに対応する状態を解放するステップと、
前記ＡＣＫメッセージが前記第１のノードから受信される前にタイムアウト期間が経過した場合、前記第２のノードから前記第１のノードに前記ＦＬＯＯＤメッセージを再送し、前記タイムアウト期間を再設定するステップと、
前記第２のノードにおいて、最大数のタイムアウト期間が経過した場合、前記状態を解放し、前記第２のノードのキャッシュから前記第１のノードに対応するＣＰＡを除去するステップと
をさらに備えることを特徴とする請求項２に記載の方法。
【請求項４】
ピアツーピアネットワークの第１のノードに対するターゲットピア名前解決（ＰＮＲＰ）識別（ＩＤ）を認証ピアアドレス（ＣＰＡ）内で解決する方法であって、
第２のノードにおいて、ターゲットＰＮＲＰ  ＩＤの解決を要求する第１のノードから、少なくとも第１のヘッダメッセージ要素、解決コントロールメッセージ要素、前記ターゲットＰＮＲＰ  ＩＤに対応するターゲットＰＮＲＰ  ＩＤメッセージ要素、第１の妥当性確認ＰＮＲＰ  ＩＤメッセージ要素、現在のＣＰＡ最良一致メッセージ要素、およびＩＰＶ６エンドポイント配列メッセージ要素を含むＲＥＳＯＬＶＥメッセージを受信するステップと、
前記第２のノードにおいて、前記ＩＰＶ６エンドポイント配列メッセージ要素がＡｃｃｅｐｔｅｄのマークが付けられている少なくとも１つのアドレスを含むこと、最後の該アドレスが前記ＲＥＳＯＬＶＥメッセージの送信元と同一であること、ＮｅｘｔＨｏｐ  ＩＤがローカルで登録されていること、および前記ＩＰＶ６エンドポイント配列メッセージ要素内に前記第２のノードのエントリがないことをチェックし、これら全てのチェックをパスした場合に、少なくとも第２のヘッダメッセージ要素、ヘッダ肯定応答メッセージ要素、分割コントロールメッセージ要素、フラグフィールドメッセージ要素、第２の妥当性確認ＰＮＲＰ  ＩＤメッセージ要素、認証連鎖メッセージ要素、ＩＰＶ６参照メッセージ識別メッセージ要素、およびクラシファイアメッセージ要素を含むＡＵＴＨＯＲＩＴＹメッセージを生成するステップであって、前記認証連鎖メッセージ要素は、前記ＰＮＲＰ  ＩＤのＣＰＡの妥当性確認を補助するステップと、
前記ＡＵＴＨＯＲＩＴＹメッセージを前記第１のノードに送信するステップと
を備えることを特徴とする方法。
【請求項５】
前記第２のノードにおいてＡＵＴＨＯＲＩＴＹメッセージを生成するステップは、前記ＡＵＴＨＯＲＩＴＹメッセージが最大長より長い場合、前記ＡＵＴＨＯＲＩＴＹメッセージを２または３以上の断片化されたメッセージに分割するステップを含むことを特徴とする請求項４に記載の方法。
【請求項６】
前記第２のノードが前記ＲＥＳＯＬＶＥメッセージ要素に対応する局所的に登録されたＣＰＡを有する場合、
前記第２のノードにおいて、少なくとも第３のヘッダメッセージ要素、前記解決コントロールメッセージ要素、前記ターゲットＰＮＲＰ  ＩＤメッセージ要素、前記局所的に登録されたＣＰＡに対応する更新済みＣＰＡ最良一致要素、および前記ＩＰＶ６エンドポイント配列メッセージ要素を含む第１のＲＥＳＰＯＮＳＥメッセージを生成し、
前記第１のＲＥＳＰＯＮＳＥメッセージを前記第１のノードに送信することを特徴とする請求項４に記載の方法。
【請求項７】
前記第２のノードがＲＥＳＰＯＮＳＥメッセージを生成しない場合、
前記ＲＥＳＯＬＶＥメッセージを前記第２のノードから第３のノードへ転送し、
前記第３のノードに対応する第２のＣＰＡ最良一致要素を含む第２のＲＥＳＰＯＮＳＥメッセージを前記第３のノードから受信し、
前記第２のＲＥＳＰＯＮＳＥメッセージを前記第１のノードへ転送することを特徴とする請求項６に記載の方法。
【請求項８】
ピアツーピアネットワークにおいて第１のノードに対するピア名前解決プロトコル（ＰＮＲＰ）識別（ＩＤ）を妥当性確認する方法であって、
第２のノードにおいて、前記ＰＮＲＰ  ＩＤの妥当性確認を要求する前記第１のノードから、ＩＮＱＵＩＲＥメッセージを受信するステップであって、前記ＩＮＱＵＩＲＥメッセージは、少なくとも第１のヘッダメッセージ要素、第１のフラグフィールドメッセージ要素、および前記ＰＮＲＰ  ＩＤに対応する妥当性確認ＰＮＲＰ  ＩＤメッセージ要素を含み、前記第１のフラグフィールドメッセージ要素は、認証連鎖を送信するよう前記第２のノードに対し要求するフラグを含み、前記認証連鎖は、前記ＰＮＲＰ  ＩＤの認証ピアアドレス（ＣＰＡ）の妥当性を確認するのを補助するステップと、
前記ＰＮＲＰ  ＩＤが前記第２のノードにおいて局所的に登録されている場合、
前記第２のノードにおいて、ＡＵＴＨＯＲＩＴＹメッセージを生成するステップであって、前記ＡＵＴＨＯＲＩＴＹメッセージは、少なくとも第２のヘッダメッセージ要素、ヘッダ肯定応答メッセージ要素、分割コントロールメッセージ要素、第２フラグフィールドメッセージ要素、前記妥当性確認ＰＮＲＰ  ＩＤメッセージ要素、認証連鎖メッセージ要素、ＩＰＶ６参照メッセージ識別メッセージ要素、およびクラシファイアメッセージ要素を含み、該妥当性確認ＰＮＲＰ  ＩＤメッセージ要素は、前記ＩＮＱＵＩＲＥメッセージに含まれる妥当性確認ＰＮＲＰ  ＩＤメッセージ要素からコピーされるステップと、
前記ＡＵＴＨＯＲＩＴＹメッセージを前記第１のノードに送信するステップと
を備えることを特徴とする方法。
【請求項９】
請求項１乃至８の何れかに記載の方法を実行するためのコンピュータ実行可能命令を格納したコンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ピアツーピア基盤（ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）における通信プロトコルに関するものであり、より具体的には、ピアツーピアグラフ（ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｇｒａｐｈ）において構造化された通信（ｓｔｒｕｃｔｕｒｅｄ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）を可能にするメッセージ形式データ構造（ｍｅｓｓａｇｅ  ｆｏｒｍａｔ  ｄａｔａ  ｓｔｒｕｃｔｕｒｅｓ）に関するものである。
【背景技術】
【０００２】
インターネット上のさまざまな通信技術を使用することで、共通の関心を持つユーザ同士が、共同で作業をしたり、ファイルを共有したり、互いにチャットしたり、オーディオおよびビデオのマルチキャストをプレゼンテーションおよびグループ会合に利用したり、多人数参加型ゲームに参加したりすることが可能になる。しかし、現在は、インターネット上のほとんどの通信は、サーバ中心の環境で行われており、したがって、すべての通信は、個人がそのような通信への加入および参加のため接続できる大規模な中央サーバへ流れるか、またはそのようなサーバを通して流れる。
【０００３】
ピアツーピア技術が再び登場したことで、現在のインターネット通信のサーバ中心モデルはたちまち取って代わられようとしている。実際、ピアツーピア技術を利用すれば、ユーザは、サーバベースのインターネット通信の制約を受けることなく、サーバレス環境で互いにコンタクトを取りあうことができる。ピアツーピアベースのシステムでは、ネットワーク内のピア同士の間で直接通信が行われるため、ユーザの匿名性とプライバシーを保持することができる。しかし、ピアツーピアネットワーク内では、個々の通信およびファイル共有は比較的適切に機能するが、ピアツーピア環境での情報の確立、発見、結合、維持、および共有はうまく機能しない。
【０００４】
ピアツーピア通信、および実際には、あらゆる種類の通信が、選択されたエンティティまたはノード同士の間で有効な接続を確立できるかどうかに依存しているのである。これらのエンティティまたはノードは、ピアツーピアネットワーク内に形成されているピア同士（例えば、ユーザまたはマシン）またはグループである。ノード間の接続はピアツーピアグラフを形成し、これにより通信および情報をノードに渡したり、ノード同士の間でやり取りすることができる。しかし、例えば、エンティティがネットワーク内を移動する、トポロジが変更される、アドレスリースを更新できない、グループ機能または目的が変更されたなどの理由により、変更可能な１つまたは複数のアドレスがエンティティに設定される場合がある。したがって、このようなアドレス指定問題に対する古典的なアーキテクチャ面での解決策では、それぞれのエンティティに安定した名前を付け、接続が必要になったときにこの名前を現在のアドレスに「解決」する。翻訳を処理するためのこのような名前は非常に強固なものでなければならず、また更新を簡単にかつ迅速に行えるようなものでなければならない。
【０００５】
こうした接続しようとする試みにより、エンティティのアドレスが見つかる可能性を高めるために、エンティティは、多くのピアツーピアプロトコルを使用して、さまざまなメカニズムを通じて個別またはグループのアドレスを公開することができる。またいくつかのプロトコルでは、クライアントはネットワーク内の他のクライアントからの要求の処理を通じて他のエンティティのアドレスに関する情報を取得することができる。実際、このようなアドレス情報の取得は、堅牢なグラフを保持することによりこれらのピアツーピアネットワークが正常に動作することを可能にする。つまり、ネットワーク内の他のピアおよびグループに関する情報が適切であればあるほど（つまり、グラフが堅牢であるほど）、特定の資源または記録の探索が収束する可能性が高まる。
【０００６】
サーバ中心環境の場合のように、ピアツーピアグラフを完全オープンにすることで、インターネットによるグラフ内のファイル探索および共有を可能にできる。しかし、ピアツーピアネットワークは分散ユーザまたはピアのグラフとして形成されるため、ネットワーク内のすべてのピアが共有されている情報を認識するようになる前に、一方のピアから別方のピアへ通信およびデータ（記録）を受け渡す必要がある。このような経路選択方式をとるシステムとして、ＵｓｅｎｅｔとＯＳＰＦがある。しかし、内在する制限を持つこのような現在のシステムは、これまでピアツーピア技術の全面的な発展を妨げている制約を抱えている。さらに、現在、ピアツーピアネットワークは適切なグラフ管理機能を欠いており、メンバの１つがグループを抜けたときにグラフがたまに「分断」または分割される可能性がある。このような場合、グラフの一方の側からの情報は、ピアの一方の離脱により分割が生じたときにその分割の他方の側にあるピアメンバにもはや渡すことはできなくなる。他の欠点として、このような分割を検出するための適切なメカニズムが存在しないという点が挙げられる。
【０００７】
技術に存在する機能に関する問題に加えて、ネットワークトラフィックの量もまた、クラウド（ｃｌｏｕｄ）に参加しているピアを容易に圧倒してしまうほどである。メッセージのサイズおよび構造により、ピアがメッセージを迅速に処理する機能を込み入ったものとし、したがって、クラウドの規模が大きくなるにつれ通信の遅延や通信内容の脱落が生じる。
【０００８】
したがって、技術の中に存在する上記の問題および他の問題に対処するピアツーピアのメッセージングプロトコルおよびデータ構造が本技術では必要である。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本出願で開示されている本発明の概念は、ピアツーピアの名前解決プロトコルで使用するのに適しているメッセージの拡張可能なデータ構造を伴う。このメッセージデータ構造では、メッセージデータフィールドを使用して、ＰＮＲＰに役立つさまざまなメッセージを構築する。メッセージデータフィールドはそれぞれ、メッセージ要素を含む。第１のフィールドは、プロトコル情報を含み、メッセージのタイプを識別するメッセージヘッダ要素であるのが好ましい。
【００１０】
メッセージ自体の場合と同様、それぞれのメッセージ要素には多数のメッセージ要素のデータフィールドが含まれる。これらのメッセージ要素フィールドは、タイプフィールド、長さフィールド、およびメッセージ要素の内容またはペイロードを含む。タイプフィールドは、メッセージ要素のタイプを指定する識別子を含む。長さフィールドは、フィールドタイプおよび長さフィールドを含む、メッセージ要素の長さを識別する。
【課題を解決するための手段】
【００１１】
一実施形態では、Ｐｅｅｒ  Ｔｏ  Ｐｅｅｒ  Ｎａｍｅ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＰＮＲＰ）を正常に動作させるため、少なくとも１０個のメッセージが形成される。これらの１０個のメッセージは、ＲＥＳＯＬＶＥメッセージ、ＲＥＳＰＯＮＳＥメッセージ、ＳＯＬＩＣＩＴメッセージ、ＡＤＶＥＲＴＩＳＥメッセージ、ＲＥＱＵＥＳＴメッセージ、ＦＬＯＯＤメッセージ、ＩＮＱＵＩＲＥメッセージ、ＡＵＴＨＯＲＩＴＹメッセージ、ＡＣＫメッセージ、ＲＥＰＡＩＲメッセージを含む。これらのメッセージは、好ましい実施形態に存在する２２個の異なるメッセージ要素から構築される。
【発明を実施するための最良の形態】
【００１２】
本明細書に組み込まれ、その一部となっている付属の図面は、本発明のいくつかの態様を示しており、説明とあわせて、本発明の原理の説明に使用される。
【００１３】
本発明は、いくつかの好ましい実施形態に関して説明するが、それらの実施形態に限る意図はない。それどころか、特許請求の範囲で定義されている本発明の精神と範囲内に収まるすべての代替、変形、および等価物を対象とすることを目的とする。
【００１４】
図面では類似の参照番号は類似の要素を指しており、本発明は適当なコンピューティング環境で実装されているものとして説明されている。必須ではないが、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的状況において本発明を説明する。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、当業者であれば、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステム構成でも実施できることを理解するであろう。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶デバイスに置くことができる。
【００１５】
図１は、本発明を実装するのに適しているコンピューティングシステム環境１００の一実施例の図である。コンピューティングシステム環境１００は、適当なコンピューティング環境の一例にすぎず、本発明の用途または機能性の範囲に関する制限を示唆する意図はない。オペレーティング環境例１００に示されているいずれか１つのコンポーネントまたはその組み合わせに関係する依存関係または要求条件がコンピューティング環境１００にあるものと解釈すべきでない。
【００１６】
本発明は、他の数多くの汎用または専用コンピューティングシステム環境または構成で動作する。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド型またはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスのいずれかを含む分散コンピューティング環境などがあるが、それらに限定されるものではない。
【００１７】
本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況において説明することができる。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶デバイスなどのローカルとリモートの両方のコンピュータ記憶媒体内に配置できる。
【００１８】
図１では、本発明を実装するシステム例は、コンピュータ１１０の形態をとる汎用コンピューティングデバイスを備える。コンピュータ１１０が備えるコンポーネントとしては、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを備えるさまざまなシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１などがあるが、それらに限定されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺機器バス、および各種バスアーキテクチャを使用するローカルバスを含む数種類のバス構造のどれでもよい。例えば、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｅ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがあるが、それらに限定されるものではない。
【００１９】
コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスできる媒体であればどのような媒体でもよく、揮発性および不揮発性媒体、取り外し可能および固定媒体を含む。例えば、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができるが、それらに限定されるものではない。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および固定媒体を含む。コンピュータ記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）もしくはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶デバイス、または目的の情報を格納するために使用することができコンピュータ１１０によりアクセスできるその他の媒体があるが、それらに限定されるものではない。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波またはその他のトランスポートメカニズムなどの被変調データ信号によるその他のデータを実現し、さらに情報配信媒体を含む。「被変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体があるが、それらに限定されるものではない。上記のいずれの組み合わせもコンピュータ可読媒体の範囲に含まれるべきである。
【００２０】
システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は通常、ＲＯＭ  １３１内に格納される。通常、ＲＡＭ  １３２には、処理ユニット１２０に直接アクセス可能な、かつ／または処理ユニット１２０により現在操作されているデータおよび／またはプログラムモジュールが含まれている。例えば、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。
【００２１】
コンピュータ１１０は、その他の取り外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図１は、固定の不揮発性磁気媒体の読み出しまたは書き込みを行うハードディスクドライブ１４１、取り外し可能な不揮発性磁気ディスク１５２の読み出しまたは書き込みを行う磁気ディスクドライブ１５１、およびＣＤ  ＲＯＭまたはその他の光媒体などの取り外し可能な不揮発性光ディスク１５６の読み出しまたは書き込みを行う光ディスクドライブ１５５を示している。オペレーティング環境例で使用できる他の取り外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体としては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがあるが、それらに限定されるものではない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取り外し可能なメモリインターフェースによりシステムバス１２１に接続される。
【００２２】
図１に示されている上記のドライブおよび関連コンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じである場合もあれば異なる場合もあることに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７に対しては、ここで、異なる番号を割り当てて、最低でも、それが異なるコピーであることを示している。ユーザは、キーボード１６２、および通常マウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力できる。他の入力デバイス（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続することもできる。モニタ１９１またはその他の種類の表示デバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタのほかに、コンピュータはさらにスピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース１９５を介して接続することができる。
【００２３】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することも可能である。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードでもよく、通常は、パーソナルコンピュータ１１０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイス１８１だけを図１に示してある。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１とワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的なものである。
【００２４】
ＬＡＮネットワーキング環境で使用する場合は、パーソナルコンピュータ１１０はネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ  １７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は通常、モデム１７２またはインターネットなどのＷＡＮ  １７３上で通信を確立するための他の手段を備える。モデム１７２は、内蔵でも外付けでもよいが、ユーザ入力インターフェース１６０またはその他の適切なメカニズムを介してシステムバス１２１に接続できる。ネットワーク環境では、パーソナルコンピュータ１１０またはその一部に関して述べたプログラムモジュールは、リモートメモリ記憶デバイスに格納できる。例えば、図１には、リモートアプリケーションプログラム１８５がメモリデバイス１８１に置かれているように示されているが、それらに限定されるものではない。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するための他の手段を使用できることは理解されるであろう。
【００２５】
以下の説明では、特に断りのない限り、１つまたは複数のコンピュータにより実行される活動および動作の記号的表現を参照しながら本発明を説明する。したがって、そのような活動および動作は、ときにはコンピュータ実行（ｃｏｍｐｕｔｅｒ−ｅｘｅｃｕｔｅｄ）と呼ばれることもあるが、構造化された形式でデータを表現する電気的信号の、コンピュータの処理装置による操作を含むことは理解されるであろう。この操作により、データを変換するか、またはコンピュータのメモリシステム内の複数の場所に保持し、当業者であればよく理解している方法でコンピュータの動作を再構成するか、さもなければ他の何らかの形で変更する。データが保持されているデータ構造は、データの形式により定められた特定の特性を備えるメモリの物理的な場所である。しかし、本発明は前記の背景状況において説明されているが、制限する意図はなく、当業者にとっては以下で説明する各種の活動および動作がハードウェアで実装できることは周知のことであろう。
【００２６】
上で紹介したように、ピアツーピア（Ｐ２Ｐ）プロトコルが成功するかどうかは、そのプロトコルで選択されたエンティティ間に有効な接続を確立する機能にかかっている。同様に、このようなＰ２Ｐネットワーク内でのグループの形成は、この機能にかかっている。特定のユーザはアドレスの異なるさまざまな場所でさまざまな方法によりネットワークに接続できるため、一意的なアイデンティティをユーザまたはグループに割り当て、プロトコルを通じてそのアイデンティティを特定の１つまたは複数のアドレスに解決するアプローチが好ましい。本発明のアイデンティティ管理システムおよび方法が特に適用可能なこのようなＰｅｅｒ−Ｔｏ−Ｐｅｅｒ  Ｎａｍｅ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＰＮＲＰ）は、２００１年８月２９日に出願された「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」という表題の同時係属出願第０９／９５５，９２４号にこのようなグループに使用される基本的なセキュリティ基盤の説明がある。これらの出願の教示および開示も参照によりその全体が本明細書に組み込まれる。しかし、本発明のインターフェースおよび方法は特に、そのようなＰＮＲＰに適用することができ、そのようなＰＮＲＰと情報のやり取りを行うが、当業者であれば、本発明はそれらの制限を受けることはなく、Ｐ２Ｐグラフ管理機能を備えることを要求するＰ２Ｐシステムまたはプロトコルに適用することができることを認識するであろう。
【００２８】
ＰＮＲＰを説明する上記の同時係属出願で説明されているように、何らかの有用な背景を提供するために、ピア名前解決プロトコル（ＰＮＲＰ）はピアベースの名前−アドレス解決プロトコルである。ピアの資源にはピア名を付けることができる。アプリケーション側で、ピア名をＰＮＲＰに登録し他のピアに発見できるようにすることが可能である。他のアプリケーションは、ＰＮＲＰを使用して、ピア名を解決し、登録側アプリケーションの対応するＩＰアドレスおよびポートを取得することができる。ＰＮＲＰは、ピア名を探索または参照するためのメカニズムを備えていない。ピア名を配布するメカニズムを実装するには、他の手段を利用しなければならない。ピア名をアドレスに解決するには、参加ピアに協力してもらい、お互いが相手にメッセージを転送し、マッピングを処理するためのピア名の分散キャッシュを保持するようにする。登録および解決メカニズムは、初期化の場合を除き、サーバが存在するかどうかに依存しない。ＰＮＲＰインスタンスは、最初に現れたときに、データの交換相手である他の何らかのＰＮＲＰインスタンスのアドレスを見つける必要がある。他の手段が利用できない場合、よく知られているサーバを使用して、他のＰＮＲＰインスタンスのリストを取得する。
【００２９】
つまり、ＰＮＲＰを使用することで、ピアアプリケーションはピア名をエンドポイントマッピングに登録し、ピア名を解決してエンドポイントを取得することができる。このときに、何らかの定義があると適切である。ピア名は、ピア資源を識別する文字列である。ピア名を登録できるためには、アプリケーションは公開鍵／秘密鍵の組にアクセスできなければならない。この鍵の組を使用して、メッセージのいくつかに署名を入れ、改ざんを防止する。ピア名は、さらに、公開鍵から導出することができ、それにより、アイデンティティ所有権（ｉｄｅｎｔｉｔｙ  ｏｗｎｅｒｓｈｉｐ）を検証できる。エンドポイントは、１つのＩＰｖ６／ＩＰｖ４アドレス、ポート、およびプロトコルである。実際、エンドポイントのリストに単一のピア名を登録することができ、ピア名が解決されたときにそのリストが返される。ノードは、ＰＮＲＰプロトコルサービスの一インスタンスである。通常は、コンピュータ１台ごとに１つのノードがある。クラウドは、互いに到達可能なノードのネットワークである。単一のノードを複数のクラウドに接続することができる。クラウドは、ＩＰｖ６−グローバル、サイトローカル、およびリンクローカルで定義されているスコープに相当するスコープ特性を持つ。ノードは、複数のサイトローカルクラウドおよび複数のリンクローカルクラウドを持つことができる。ノード間の通信は、決して、一方のクラウドから別のクラウドへ横断しない。クラウド名を使用して、クラウドを区別する。複数のノードに１つのピア名を登録できる。ＰＮＲＰは、各登録を明確に区別する。各ピア名インスタンスに関連付けられているエンドポイントリストは異なる。１つのノード内で、そのノードが接続されている複数のクラウド上でピア名を登録することも可能である。これらの登録はそれぞれ区別される。通常、エンドポイントリストも、これらのインスタンスのそれぞれにおいて異なる。ノードは、ピア名を解決しようとするときに、選択されたクラウド上でこれを実行する。解決が成功するのは、ピア名が同じクラウド内で登録されている場合のみに限る。複数のクラウド上で同時にピア名を解決することが可能であるが、これらは独立の解決要求として処理される。
【００３０】
ＰＮＲＰサービスは、図２に例示されているように、連携する複数のモジュールからなる。サービス管理コンポーネント２００は、ＰＮＲＰサービスの開始および停止などの単純な日常的作業を処理する。ＲＰＣサーバおよびスタブ２０２は、クライアントプロセスとＰＮＲＰサービスとの間のインターフェースを提供する。これにより、公開されているインターフェース、要求に対するエントリポイントの提供、ならびにイベントおよび要求完了の通知を管理する。また、クライアントプロセスの終了からの復旧も処理する。クラウドマネージャ２０４は、特定のクライアント要求の状態を保持し、利用可能なＰＮＲＰクラウドのリストを保持する。これは、クラウドを作成し、クラウド状態の変更をクライアントに通知する役割を持つ。
【００３１】
キャッシュマネージャ２０６は、ローカルＰＮＲＰキャッシュおよびクラウド毎にローカルで登録されているＰＮＲＰ名のリストを保持する。これは、分散ＰＮＲＰキャッシュの一部である。他のコンピュータから届く解決要求に対するルックアップおよび次のホップ選択（ｌｏｏｋｕｐ  ａｎｄ  ｎｅｘｔ  ｈｏｐ  ｓｅｌｅｃｔｉｏｎ）を行う。これは、キャッシュの構造がよく保たれるように定期的に解決要求を開始することにより自キャッシュ上で保守作業を実行する。また、クラウドの分割を検出し、修復を試みる。複数の登録されたピアＩＤを保有することができ、またそれぞれをサポートするためキャッシュを構造化する。プロトコルマネージャ２０８は、有効なＰＮＲＰメッセージの作成および送信、ならびに受信したＰＮＲＰメッセージの処理を受け持つ。ＰＮＲＰプロトコルを実装するためキャッシュマネージャ２０６と連携する。最後に、メッセージトランスポート２１０が、メッセージの実際の送信および受信を処理する。これは、複数のネットワークインターフェースおよびアドレスを処理し、ローカルアドレスの集まりの変更を検出する。複数のプロトコルが必要な場合（ＩＰｖ４およびＩＰｖ６）、このコンポーネントは両方のプロトコルを処理する。
【００３２】
各ＰＮＲＰノードは、クラウド内の他のいくつかのノードに対するエンドポイントマッピングへのピア名のキャッシュを保持する。ノード間で本発明により構築されたメッセージがやり取りされ、クラウド内のノードにピア名に関する情報が配布される。そのキャッシュを適切に保持することは、各ノードの役目である。上述の出願により説明されているように、ＰＮＲＰプロトコルにより数値名前空間が定義される。各ピア名を数値に変換し、それらの数値を比較して、名前空間内での近さを判定することができる。ピア名を解決する要求がノードに届くと、目的のノードに数値的に近いノードを見つけるためにその数値とキャッシュ内の数値との比較が行われる。このようにして、解決要求がノードからノードへ渡され、各ホップでそのターゲットに次第に近づく。
【００３３】
ピア名は、上記の出願で説明されているハッシュ関数を使用してＰ２Ｐ  ＩＤと呼ばれる１２８ビット数に変換される。同じピア名からは常に、同じＰ２Ｐ  ＩＤが得られる。ピア名登録の特定のインスタンスもまた、サービスロケーション（ｓｅｒｖｉｃｅ  ｌｏｃａｔｉｏｎ）と呼ばれる１２８ビット数が設定される。これら２つを合わせて、ＰＮＲＰ  ＩＤと呼ばれる２５６ビット数が作られる。ＰＮＲＰ  ＩＤのサービスロケーション部分により、ピア名登録の特定のインスタンスがネットワーク内で一意的なものとなる。
【００３４】
アプリケーション側で、ピア名をＰＮＲＰに登録することができる。ＰＮＲＰ  ＩＤは名前から作成され、他のノードに登録を知らせるメッセージが送信される。複数のノード上で同じピア名を登録できる。Ｐ２Ｐ  ＩＤは、各ノード上で同じであるが、ＰＮＲＰ  ＩＤは各ノードに対して一意的でなければならない。アプリケーションは、ピア名をアドレスに解決することを要求できる。Ｐ２Ｐ  ＩＤをピア名から導出し、メッセージを他のノードに送信し、このＰ２Ｐ  ＩＤが登録されているノードを特定する。Ｐ２Ｐ  ＩＤがアドレスに解決されると、認証されたピアアドレス（ＣＰＡ）が返される。このＣＰＡは、ターゲットのＰＮＲＰ  ＩＤ、現在のＩＰアドレス、公開鍵、および多数の他のフィールドのサービスロケーション部分を含む。ＣＰＡに署名を入れて改ざんを防止する。
【００３５】
所与のＰ２Ｐ  ＩＤを多数の異なるノードにより登録することができる。ＰＮＲＰでは、「ｓｅｒｖｉｃｅ  ｌｏｃａｔｉｏｎ」サフィックスを使用して、それぞれの登録されているインスタンスが一意的なＰＮＲＰ  ＩＤを持つようにしている。「ｓｅｒｖｉｃｅ  ｌｏｃａｔｉｏｎ」は、一意的なネットワークサービスエンドポイントに対応する１２８ビットの数値である。この値は、ＩＰｖ６アドレス、ポート、プロトコル、および公開鍵の一部を組み合わせて作成される。サービスロケーションは、ＰＮＲＰクライアント側で、隠ぺいされている（ｏｐａｑｕｅ）と考えなければならない。サービスロケーションには２つの重要な特性がある。サービスロケーションにより、いつでも、ピア名の一意的なインスタンスが識別される。２つのサービスロケーションを比較した場合に、それぞれに対する共通のプレフィックスの長さはネットワーク近接度（ｎｅｔｗｏｒｋ  ｐｒｏｘｉｍｉｔｙ）の妥当な尺度である。同じ４ビットで始まる２つのサービスロケーションは、通常、同じ３ビットで始まる２つのサービスロケーションからそれほど隔たっていない。これらの利点は、グローバルスコープのネイティブユニキャストＩＰｖ６アドレスにしかあてはまらない。
【００３６】
ＰＮＲＰ  ＩＤの作成および登録は、ＰＮＲＰサービスの一部にすぎない。ＰＮＲＰサービスの実行は、４段階に分けることができる。第１は、ＰＮＲＰクラウド発見である。新しいノードは、加入したい加入先クラウド内に既存のノードを見つけなければならない。クラウドには、グローバルＰＮＲＰクラウド、サイトローカル（エンタープライズ）クラウド（ｓｉｔｅ  ｌｏｃａｌ  （ｅｎｔｅｒｐｒｉｓｅ）  ｃｌｏｕｄ）、またはリンクローカルクラウドがある。第２段階は、ＰＮＲＰクラウドの加入である。新しいノードは、既存のノードを見つけた後、ＳＹＮＣＨＲＯＮＩＺＥプロシージャを実行して、既存のノードの最上位キャッシュレベルの一部を取得する。単一のキャッシュレベルの部分集合には、クラウドへの参加を開始する新しいノードに対する情報が十分にある。第３段階では、クラウドへの能動的参加を考える。初期化が完了した後、ノードはＰＮＲＰ  ＩＤ登録および解決に参加することができる。この段階では、ピアはさらに、定期的キャッシュ保守も実行する。最終段階は、ピアがクラウドを抜けることに関係する。ノードは、ローカルで登録されているＰＮＲＰ  ＩＤの登録を解除してから終了する。
【００３７】
本発明のＰＮＲＰプロトコルは、ＰＮＲＰのさまざまな機能を実現するため、１０種類の異なるメッセージを含む。メッセージには、高いレベルで、ＣＰＡへのターゲットＰＮＲＰ  ＩＤの解決を要求するために使用されるＲＥＳＯＬＶＥメッセージが含まれる。ＲＥＳＰＯＮＳＥメッセージは、完了したＲＥＳＯＬＶＥ要求の結果として使用される。ＦＬＯＯＤメッセージには、受信側（レシーバ）のＰＮＲＰキャッシュ向けのＣＰＡが含まれる。ＳＯＬＩＣＩＴメッセージは、最上位レベルのキャッシュに対しＡＤＶＥＲＴＩＳＥを実行するようＰＮＲＰノードに依頼する場合に使用する。ＡＤＶＥＲＴＩＳＥメッセージは、ノードの最上位レベルのキャッシュ内のＣＰＡに対するＰＮＲＰ  ＩＤのリストを含む。ＲＥＱＵＥＳＴメッセージは、ＡＤＶＥＲＴＩＳＥされたＣＰＡの部分集合をフラッディングする（ｆｌｏｏｄ  ａ  ｓｕｂｓｅｔ  ｏｆ  ＡＤＶＥＲＴＩＳＥ’ｄ  ＣＰＡｓ）ようにノードに要求するために使用される。ＩＮＱＵＩＲＥメッセージは、特定のＰＮＲＰ  ＩＤがそのノードに登録されているかどうかをノードに問い合わせる場合に使用される。ＡＵＴＨＯＲＩＴＹメッセージは、ＰＮＲＰ  ＩＤのローカル登録を確認し、任意選択によりそのＩＤに対するＣＰＡの妥当性を確認するのを補助する認証連鎖（ｃｅｒｔｉｆｉｃａｔｅ  ｃｈａｉｎ）を供給する場合に使用される。ＡＣＫメッセージは、いくつかのメッセージを受信したこと、および／または正常に処理したことについて肯定応答する場合に使用される。最後に、ＲＥＰＡＩＲメッセージは、分割されている可能性のあるクラウドのマージを試みる場合に使用される。
【００３８】
ノードは、本発明のメッセージが使用されるＰＮＲＰ内の６つの基本的なタイプのトランザクションを開始することができる。これらのトランザクションには、クラウド発見、同期、解決、フラッディング（ｆｌｏｏｄｉｎｇ）、アイデンティティ妥当性確認、および修復（ｒｅｐａｉｒｉｎｇ）がある。これらのトランザクションはメッセージおよび本発明のメッセージ構造に関係するので、上記の出願で詳細が説明されているこれらのトランザクションの基本を理解するために、これらの簡単な説明を行う。
【００３９】
クラウド発見トランザクションにより、ピアはピアクラウドを発見することができる。好ましい実施形態では、各ノードはいくつかのクラウドに加入できる。加入できるクラウドの集合がどのようなものかは、ノードが持つネットワーク接続性によって決まる。ノードコンピュータに複数のインターフェースアダプタがある場合、複数のリンクローカルクラウドに加入できる。ノードがＩＰｖ６をサポートするサイトの一部であれば、そのノードはサイトローカルクラウドにアクセスできる。ノードが複数のこのようなサイトに（たぶん、ＶＰＮを介して）接続されている場合、そのノードは複数のサイトローカルクラウドにアクセスできる。ノードがインターネットに接続されている場合、そのノードはグローバルクラウドにアクセスできる。
【００４０】
ノードは、アクセス先のクラウドへの加入または非加入を選択できる。アプリケーションが最初にクラウド上でピア名を登録すること、またはクラウド上でピア名を解決することを要求した場合、ノードはクラウドにまだ加入していなければ加入しなければならない。クラウドに加入するには、同じクラウド内の少なくとも１つの他のノードを特定（ｌｏｃａｔｅ）しようと試みなければならない。別のノードを見つけられない場合、それはクラウド内の最初のノードであると想定し、他のノードが後で加入するのを待つことになる。
【００４１】
ＰＮＲＰノードがクラウドに加入する毎に、クラウド発見を実行して、別のノードを見つけなければならない。ＰＮＲＰの実装によりそのキャッシュが健全ではなく、さらに多くのキャッシュエントリを取得する必要があると判定される場合に、後からクラウド発見を実行することもできる。最初のキャッシュ発見の試みがうまく行かない場合、後でさらに試みることもできる。クラウド発見は、以下の手順で実行される。まず、ピアが永続的キャッシュから発見を実行する。このような手順では、ピアはまず永続的キャッシュをチェックする。キャッシュが永続的でなかった場合、ピアは後述の供給されたノードアドレスにより発見を試みなければならない。キャッシュエントリが永続的であった場合、すべてのキャッシュエントリについて、ピアは、期限切れになっていないＣＰＡ、次いで存続期間の長いＣＰＡ、次いで期限が最新であるＣＰＡと優先順位を決めることにより、優先度を計算する。その後、ピアは、選択されたノードとの同期処理を、選択されたノードの１つがいくつかのキャッシュエントリを与えるまで、順番に試みる。
【００４２】
上記のように、永続的キャッシュがない場合、ピアは供給されたノードアドレスにより発見を実行しようとする。この手順で、ピアは、管理構成で接続先のピアの集まりを指定しているかどうかをチェックする。指定していない場合、ピアは後述のマルチキャスト発見を試みる。指定している場合、ピアは、指定されたエンドポイント毎に、同期処理を、その選択されたノードの１つがいくつかのキャッシュエントリを与えるまで、順番に試みる。
【００４３】
マルチキャスト発見では、Ｓｉｍｐｌｅ  Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ（ＳＳＤＰ）が利用可能であれば、ピアは、所望のクラウド内のＰＮＲＰサービスインスタンスについてＳＳＤＰ  ＭＳＥＡＲＣＨを発行する。ＳＳＤＰ検索メッセージで使用する検索ターゲット文字列は、「ｕｒｎ：Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  Ｐｅｅｒ  Ｎａｍｅ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ：＜ｍａｊｏｒ＞：＜Ｐｒｏｔｏｃｏｌ＞：＜Ｓｃｏｐｅ＞」である。ただし、＜ｍａｊｏｒ＞はバージョンを表す番号、＜Ｐｒｏｔｏｃｏｌ＞は「ＩＰＶ６」、＜Ｓｃｏｐｅ＞は「Ｇｌｏｂａｌ」、「ＳｉｔｅＬｏｃａｌ」、または「ＬｉｎｋＬｏｃａｌ」のうちの１つである。検索は、時間内に応答が得られるようにあらかじめ発行することができる。ＳＳＤＰが利用できない場合、ピアは、上記の他の発見プロトコルを試みることができる。利用できるものがない場合、ピアは、後述のディレクトリネームサーバ（ＤＮＳ）発見を試みなければならない。しかし、応答が受信された場合、応答は試みる対象のノードのリストに入れられる。応答が短時間のうちに利用できない場合、ノードは他の発見プロトコルを試みてもよい。この期間は、実装で決定することができる。その後、ピアは、選択されたノードとの同期処理を、選択されたノードの１つがいくつかのキャッシュエントリを与えるまで、順番に試みる。
【００４４】
ＤＮＳ発見では、ピアは、シードサーバ（ｓｅｅｄ  ｓｅｒｖｅｒ）のよく知られている名前についてＤＮＳクエリを発行する。グローバルクラウドに対するこの名前は、例えば、ＳＥＥＤ．ＰＮＲＰ．ＮＥＴなどとなる。成功した場合、ピアは後述の同期処理を実行できる。しかし、このときまでにクラウド発見が成功しなかった場合、ＰＮＲＰは、クラウドの他のメンバを発見できないようにクラウド状態を設定し、それがクラウド内の第１のノードであると想定する。後で、再び同期処理を試みることができる。
【００４５】
同期をとることで、ノードは別のノードのキャッシュから一組のＣＰＡを取得することができる。同期処理は、クラウド発見後に実行される。これは、クラウド発見により返された一組のノードからランダムに選択された単一のノードにより実行される。ある種の攻撃を緩和するために同期処理が行われる。また、有効期限が過ぎたためクラウドのキャッシュが空になった場合にも同期処理が行われるが、ほんのたまにしか行われない。同期処理を開始する前に、ノードは、少なくとも１つのローカルで登録されているＣＰＡを備えていることを確認しなければならない。ピア名がすでに登録されていなければ、ノードはクラウド内に自分自身のノードＩＤを生成することができる。同期処理では、ＳＯＬＩＣＩＴ、ＡＤＶＥＲＴＩＳＥ、ＲＥＱＵＥＳＴ、ＦＬＯＯＤ、およびＡＣＫなどの本発明の５種類のメッセージが伴う。
【００４６】
図３は、同期処理のための単純なメッセージ交換を例示している。この図３では、ノードＡ２１２はノードＢ２１４との同期処理を開始すると仮定する。このような状況で、ノード間のメッセージの流れは、図３に例示されているとおりに進む。特に、ＳＯＬＩＣＩＴメッセージ２１６は、クラウド発見時に選択されたノード２１４にＰＮＲＰ  ＩＤのリストを要求する。このＳＯＬＩＣＩＴメッセージ２１６は、表１で説明されているように入力される。
【００４７】
【表１】
0004786882.tif 000002
【００４８】
ノードは、ハッシュされたＮｏｎｃｅを生成するために使用されるＮｏｎｃｅ値を追跡する。タイマーは、この状態だけでなく、リトライカウントにも関連付けられている。送信されたＳＯＬＩＣＩＴ  ２１６に応答してＡＤＶＥＲＴＩＳＥメッセージ２１８が受信されなかった場合、ＳＯＬＩＣＩＴ  ２１６が再送される。リトライカウントを超えた場合、その状態は解放され、トランザクションは終了する。
【００４９】
ＳＯＬＩＣＩＴ  ２１６を受信したノード２１４は、ＡＤＶＥＲＴＩＳＥメッセージ２１８で応答する。ＡＤＶＥＲＴＩＳＥ  ２１８はＰＮＲＰ  ＩＤの配列を含む。ノード２１４は最初に、スロットリングという経験則を適用し、同期処理トランザクションに加わる意志があるかどうかを判別する。ビジー状態であれば、ＰＮＲＰ  ＩＤが配列内にないＡＤＶＥＲＴＩＳＥメッセージ２１８で応答する。ビジー状態でなければ、キャッシュから適切に配分された一組のＰＮＲＰ  ＩＤを選択する。これは、最上位レベルのキャッシュエントリを使用するか、またはランダム選択により実行することも可能である。キャッシュ内に十分なエントリがない場合、ノード２１４は自分のローカルで登録されているＩＤも含まなければならない。ＡＤＶＥＲＴＩＳＥメッセージ２１８は、ＳＯＬＩＣＩＴメッセージ２１６からのハッシュされたＮｏｎｃｅを含む。ＡＤＶＥＲＴＩＳＥ  ２１８は、ＳＯＬＩＣＩＴ  ２１６の肯定応答であると考えられる。
【００５０】
ＰＮＲＰ  ＩＤの配列が空でなかった場合、ノード２１４はハッシュされたＮｏｎｃｅ値を持つＡＤＶＥＲＴＩＳＥ  ２１８が送信された状態も保つ。この状態は、ビットマップ内の１ビットとすることができる。タイマーはこの状態に関連付けられ、したがって一致するメッセージを１５秒以内に受信しないと、トランザクションは異常終了し、この状態は解放される。ノード２１４は、ＳＯＬＩＣＩＴメッセージ２１６からソースＣＰＡをキャッシュに追加することもできる。ＡＤＶＥＲＴＩＳＥメッセージ２１８は、表２に示されているように占有される。
【００５１】
【表２】
0004786882.tif 000003
【００５２】
ノード２１２は、ＡＤＶＥＲＴＩＳＥ  ２１８を受信すると、まず、対応するＳＯＬＩＣＩＴ  ２１６を送信したことを確認する。ノード２１２は、送信していなければ、メッセージを削除する。ＡＤＶＥＲＴＩＳＥ  ２１８は、ＳＯＬＩＣＩＴ  ２１６の肯定応答として処理される。ＡＤＶＥＲＴＩＳＥ  ２１８内のＰＮＲＰ  ＩＤの配列が空の場合、トランザクションは完了である。空でなければ、ノード２１２はＡＤＶＥＲＴＩＳＥ  ２１８内のＰＮＲＰ  ＩＤの配列を参照して、キャッシュに含めたいものを選択する。ノード２１２は、選択されたＰＮＲＰ  ＩＤの配列を含む、ＲＥＱＵＥＳＴメッセージ２２０を送信する。ＲＥＱＵＥＳＴメッセージ２２０の中に、ノード２１２は、ＳＯＬＩＣＩＴメッセージ２１６のハッシュされたＮｏｎｃｅを作成するために使用されるオリジナルのＮｏｎｃｅ値を入れる。ＲＥＱＵＥＳＴメッセージ２２０は、表３に示されているように入力される。
【００５３】
【表３】
0004786882.tif 000004
【００５４】
ＲＥＱＵＥＳＴメッセージ２２０がノードＢ  ２１４に送られると、ＡＣＫ  ２２２で応答して、受信したことを示し、再送を避ける。適切なタイミングでＡＣＫ  ２２２が受信されない場合、ノードＡ  ２１２はＲＥＱＵＥＳＴを再送する。ＲＥＱＵＥＳＴに対するＡＣＫを受信することなくすべての再送が尽きてしまった場合、トランザクションは失敗し、終了する。
【００５５】
トランザクションが成功した場合、つまり、ノード２１２がノード２１４からＡＣＫ  ２２２を受信した場合、ノード２１４はＮｏｎｃｅが有効であることを確認する。そのために、受信したＮｏｎｃｅをハッシュし、それが先に保存した状態と一致するかチェックする。一致しない場合には、それ以上処理を行わない。有効であれば、キャッシュ内にまだ置いてある配列内のＰＮＲＰ  ＩＤ毎に、ＦＬＯＯＤメッセージ２２４１、２２４２、．．．２２４Ｎを送信する。ＦＬＯＯＤメッセージ２２４は、ＰＮＲＰ  ＩＤに対するＣＰＡを含む。ＦＬＯＯＤメッセージ２２４は同期していないことに注意されたい。つまり、ＦＬＯＯＤ（ＩＤ＝１）２２４１は、ＦＬＯＯＤ（ＩＤ＝２）２２４が送信される前に肯定応答される必要はない。ピア２１２がＦＬＯＯＤ  ２２４を受信した後、ＦＬＯＯＤメッセージ２２４の通常処理が行われる。これは、ＡＣＫ  ２２６の送信およびＣＰＡの妥当性の確認を含む。
【００５６】
探索側ノード２１２は、選択されたＩＤの個数が十分に大きくなければこの手順を繰り返すことを決定できる。この場合、異なる同期相手のノードを使用して、異なるＩＤリストを取得する必要がある。
【００５７】
ＲＥＳＯＬＶＥメッセージを送信することにより、ノード側で解決プロセスを開始する。ＰＮＲＰ  ＩＤを登録する一部として、またはキャッシュ保守の一部として、またはクラウド分割を検出するため、アプリケーション側でピア名をアドレスに解決することを要求しているのでＲＥＳＯＬＶＥが開始される場合がある。ＲＥＳＯＬＶＥメッセージは、解決処理をチューニングし、解決を試みるため訪れるノードの数に制限を課し、ＩＤ照合の精度を導くいくつかのフラグおよびコードを含む。これは所望のターゲットＰＮＲＰ  ＩＤを指定する。ホップ毎に、次のホップのＩＤだけでなく、これまでに見つかった最もよく一致するＣＰＡが挿入される。さらに、ホップからホップへのＲＥＳＯＬＶＥメッセージの経路を追跡するため、訪れた先のノードエンドポイントの配列を含む。ＲＥＳＯＬＶＥの発信元（オリジネータ）は自分自身をその経路内の第１のエントリとして追加する。解決トランザクションにより、ＰＮＲＰ  ＩＤは認証ピアアドレスに解決される。ＣＰＡ所有者のみが、権限を得てそのＣＰＡの解決要求を履行できる。キャッシュされたＣＰＡは、ＲＥＳＯＬＶＥ要求の経路選択の際の参考としてしか使用できない。これらは、ＲＥＳＯＬＶＥまたはＲＥＳＰＯＮＳＥの「最良一致」フィールドの設定に使用できない。
【００５８】
ＲＥＳＯＬＶＥメッセージは、ターゲットＰＮＲＰ  ＩＤのホストとなるノードに到達したときに、または訪れた先のノードの数がＲＥＳＯＬＶＥで設定されているＭａｘ  Ｈｏｐｓに等しいときに、または経路内の任意のノードがもはやＲＥＳＯＬＶＥをより適切なノードに転送することができなくなったときに、終了する。終了に際し、ＲＥＳＯＬＶＥから選択された内容が新しいＲＥＳＰＯＮＳＥメッセージ内に転送され、このメッセージはＲＥＳＯＬＶＥイニシエータに送り返される。ＲＥＳＰＯＮＳＥは、ＲＥＳＯＬＶＥからの「最良一致」ＣＰＡだけでなく、訪れた先のノードのリストも含む。ＲＥＳＰＯＮＳＥがＲＥＳＯＬＶＥ発信元に到達すると、発信元は「最良一致」ＣＰＡのＰＮＲＰ  ＩＤとターゲットとを比較することによりターゲットＣＰＡを見つけたかどうかを容易に確認できる。
【００５９】
ＲＥＳＯＬＶＥ／ＲＥＳＰＯＮＳＥトランザクションの３ノード例が図４に示されている。この簡略化した例では、ノードＡ  ２２８は、ノードＢ  ２３０経由でノードＴ  ２３２を解決しようと試みている。ＡＣＫのほかに解決トランザクションに関わる３つのメッセージ、つまりＲＥＳＯＬＶＥ、ＲＥＳＰＯＮＳＥ、およびＡＵＴＨＯＲＩＴＹがある。解決が完了した後、後述のように、ノードＡ  ２２８はノードＴ  ２３２にＩＮＱＵＩＲＥメッセージを直接送信することができる。
【００６０】
ＲＥＳＯＬＶＥメッセージについては、３つのケースが考察され、そのうち最初の２つが図４に示されている。これら３つのケースでは、ノードＡ  ２２８でＲＥＳＯＬＶＥ  ２３４を開始し、ノードＡ  ２２８から別のノードＢ  ２３０へＲＥＳＯＬＶＥ  ２３６を転送し、ノードからＲＥＳＯＬＶＥを送り返されている（図４には示されていない）。これらのシナリオのそれぞれについて順番に説明する。
【００６１】
ノードＡ  ２２８でＲＥＳＯＬＶＥを開始することについて最初に説明する。図４に例示されているように、ノードＡ  ２２８は何らかの理由からＲＥＳＯＬＶＥを開始する。理由としては、アプリケーション解決要求、登録広告（ｒｅｇｉｓｔｒａｔｉｏｎ  ａｄｖｅｒｔｉｓｅｍｅｎｔ）、キャッシュ幅保守（ｃａｃｈｅ  ｂｒｅａｄｔｈ  ｍａｉｎｔｅｎａｎｃｅ）、またはクラウド分割検出（ｃｌｏｕｄ  ｓｐｌｉｔ  ｄｅｔｅｃｔｉｏｎ）などがある。イニシエータ２２８は、オペレーションコードも指定し、これにより、ＲＥＳＯＬＶＥの条件はローカルで登録されているＩＤにより満たされることが可能かどうかを示す。それが可能であれば、ノードＡ  ２２８はローカルで登録されているＩＤの集合に一致がないかスキャンして調べる。一致が見つかれば、ＲＥＳＯＬＶＥは、一致するＩＤを持つノードＡ  ２２８自体の中で完了する。ローカルで登録されているＩＤが条件に合致していない場合、またはローカルＩＤのどれも一致していない場合、ＲＥＳＯＬＶＥメッセージ２３４が作成され、表４に示されているフィールドを備える。その後、このＲＥＳＯＬＶＥメッセージ２３４は、後述のように、他の何らかのノード２３０に転送され、処理される。
【００６２】
【表４】
0004786882.tif 000005
【００６３】
ノードＡ  ２２８がＲＥＳＯＬＶＥ  ２３４を別のノードＢ  ２３０に転送したい場合またはその必要がある場合、この次ノードを最初に選択しなければならない。次のホップを選択するために、ノードＡ  ２２８は、アドレスがすでに経路リストに載っているもの以外のターゲットＩＤ（ノードＴ  ２３２）に最も近いＰＮＲＰ  ＩＤおよびＡの最も近いローカルで登録されているＩＤよりもターゲットＩＤに近くないＰＮＲＰ  ＩＤを持つ３つのキャッシュされたＣＰＡのリストＬを作成する。ターゲットＩＤがリストＬに含まれている場合、そのエントリが次ホップとして選択される。含まれていない場合、リストＬが空でなければ、１つのエントリがランダムに選択される。つまり、ノードＡ  ２２８は、このノードよりもターゲットに近い新しいいくつかのノードを見つけ、ＲＥＳＯＬＶＥメッセージ２３４の転送先としてそのうちの１つを選択する。
【００６４】
ノードＡ  ２２８が次のホップを選択できる場合、ノードＡ  ２２８は適切なエントリを「受信済みビットマップ」内に挿入する。ノードＡ  ２２８は自分自身を経路リストに追加し、選択された次ホップに対するその最良のアドレスを選択し、エントリにＡｃｃｅｐｔｅｄのマークを付ける。ノードＡ  ２２８は、ＮｅｘｔＨｏｐを選択された転送先の予想ＰＮＲＰ  ＩＤに設定し、ＲＥＳＯＬＶＥメッセージ２３４をノードＢ  ２３０に転送する。ＲＥＳＯＬＶＥメッセージ２３４が正常に送信された場合、送信側ノード２２８では、ＡＵＴＨＯＲＩＴＹメッセージ２３８の形で肯定応答を受信することを期待する。ＡＵＴＨＯＲＩＴＹ  ２３８が受信された場合、ノード２２８はＲＥＳＯＬＶＥ  ２３４に対するコンテキストを保持し、タイムアウト値に達するまでＲＥＳＰＯＮＳＥ  ２４０メッセージが返されるのを待つ。一定時間後、ＡＵＴＨＯＲＩＴＹ  ２３８が受信されない場合、ＲＥＳＯＬＶＥ  ２３４が再送される。ＮｅｘｔＨｏｐが無効であるとみなされるまでに、合計Ｎ回試みられる。好ましい実施形態では、Ｎ＝３である。リトライカウントを超えた場合、ローカルキャッシュからＮｅｘｔＨｏｐ  ＣＰＡが除去され、エントリが失敗したホップとして経路リストに加えられる。ホップカウントを超えない場合、ローカルキャッシュから次のＮｅｘｔＨｏｐが選択され、処理が繰り返される。経路リスト内のエントリの数がＭａｘＨｏｐｓ以上の場合、応答コードをＲＥＳＵＬＴ＿ＭＡＸ＿ＨＯＰ＿ＬＩＭＩＴ＿ＨＩＴとするＲＥＳＰＯＮＳＥメッセージが生成され、Ａｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリへ送られる。
【００６５】
ノードが次のホップを見つけられなかった場合、ターゲットＩＤが最低キャッシュレベルにあるべきかチェックする。そうであれば、ノードはターゲットＩＤが存在していないのではないかと疑う。ノードは、既存の経路リスト内のエントリをチェックし、Ｓｕｓｐｉｃｉｏｕｓのマークが付けられているエントリを数える。このカウントが閾値を超えている場合、応答コードをＲＥＳＵＬＴ＿ＴＯＯ＿ＭＡＮＹ＿ＭＩＳＳＥＳとするＲＥＳＰＯＮＳＥメッセージが生成され、Ａｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリへ送られる。ノードが次のホップを見つけられなかったが、Ｓｕｓｐｉｃｉｏｕｓカウントを超えていない場合、ノードはＲＥＳＯＬＶＥをＡｃｃｅｐｔｅｄのマークが付けられている経路リスト内の最後のノードに送り返す。ノードはまず、自分自身を経路リストに追加し、転送先ノードに対するその最良のアドレスを選択し、エントリにＲｅｊｅｃｔｅｄのマークを付ける。これはＮｅｘｔＨｏｐを０に設定し、ＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰフラグをセットして、バックトラッキングを指示する。ターゲットＩＤがノードの最低キャッシュレベルになければならない場合、ターゲットＩＤが存在していないのではないかと疑う。この場合、ノードはさらに、経路リストのエントリにＳｕｓｐｉｃｉｏｕｓのマークを付ける。ノードが次のホップを見つけられず、経路リスト内にノードがない（自分自身のほかに）場合、それはＲＥＳＯＬＶＥメッセージの発信元である。この場合、結果が呼び出し側に返され、解決できなかったことを示し、応答コードはＲＥＳＵＬＴ＿ＮＯ＿ＢＥＴＴＥＲ＿ＰＡＴＨ＿ＦＯＵＮＤである。呼び出し側で、ＢｅｓｔＭａｔｃｈ  ＣＰＡが利用できるようになる。
【００６６】
ノードＢ  ２３０は、ターゲットＰＮＲＰ  ＩＤ、ＢｅｓｔＭａｔｃｈ  ＣＰＡ、Ｎｅｘｔ  Ｈｏｐ  ＰＮＲＰ  ＩＤ、およびＲＥＳＯＬＶＥを処理したすべてのノードのアドレスを記述した経路リストを含むＲＥＳＯＬＶＥメッセージ２３４を受信する。フラグフィールドにＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰが設定されておらず、ＢｅｓｔＭａｔｃｈ  ＣＰＡにＣＰＡがあるか、または空である可能性がある場合、ノードＢ  ２３０はそのローカル処理負荷をチェックする。負荷が高すぎて、新しいＲＥＳＯＬＶＥ要求を処理できない場合、フラグフィールドが「ＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹ」に設定されているＡＵＴＨＯＲＩＴＹ  ２３８で応答し、処理は完了する。ＡＵＴＨＯＲＩＴＹ受信側は、拒絶ノードのエンドポイントを経路配列に追加し、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を行う必要がある。
【００６７】
受信ノード２３０は、経路配列がＡｃｃｅｐｔｅｄのマークが付けられている少なくとも１つのアドレスを含むこと、および最後のそのようなアドレスがメッセージの送信元（ソース）と同じであることをチェックする。そうでなければ、それ以上処理は行われない。受信ノードは、受信した要求に含まれるパラメータもチェックする。いくつかのパラメータが有効な範囲内にない場合、フラグフィールドが「ＡＦ＿ＩＮＶＡＬＩＤ＿ＲＥＱＵＥＳＴ」に設定されているＡＵＴＨＯＲＩＴＹメッセージで応答し、処理は完了する。無効なパラメータの一例として、ＭａｘＨｏｐｓが大きすぎる場合を挙げることができる。ＡＵＴＨＯＲＩＴＹ受信側は、拒絶ノードのエンドポイントを経路配列に追加し、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を行う必要がある。
【００６８】
受信ノード（例えばノードＢ  ２３０）は、ＮｅｘｔＨｏｐ  ＩＤがローカルで登録されているかチェックする。シードサーバではこのテストをスキップすることができる。これが失敗した場合、フラグフィールドが「ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤ」に設定されているＡＵＴＨＯＲＩＴＹで応答し、処理は完了する。ＡＵＴＨＯＲＩＴＹ受信側は、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を担う。ＡＵＴＨＯＲＩＴＹ受信側はまた、ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤが受信されたときにＡＵＴＨＯＲＩＴＹ送信側（センダ）のＰＮＲＰ  ＩＤをキャッシュから除去しなければならない。ＢｅｓｔＭａｔｃｈ  ＣＰＡがメッセージに含まれている場合、ノードは、可能な限り、ＢｅｓｔＭａｔｃｈの妥当性を確認する。ＣＰＡが有効でない場合、ノードはメッセージからＢｅｓｔＭａｔｃｈ  ＣＰＡを除去する。ＢｅｓｔＭａｔｃｈ  ＣＰＡが有効な場合、ノードは通常の規則に従って、ＣＰＡをキャッシュに追加するかどうかを決定する。
【００６９】
またノードは、経路リスト内にそのノードに対するエントリがあるかどうかもチェックする。もしあれば、これはバックトラックされたＲＥＳＯＬＶＥでないので、ループがある。するとノードは、フラグフィールドが「ＡＦ＿ＲＥＪＥＣＴ＿ＬＯＯＰ」に設定されているＡＵＴＨＯＲＩＴＹで応答し、処理は完了する。ＡＵＴＨＯＲＩＴＹ受信側は、拒絶ノードのエンドポイントを経路配列に追加し、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を行うことを担う。
【００７０】
前のチェックがすべて通った場合、ノードＢ  ２３０はＡＵＴＨＯＲＩＴＹ  ２３８を送信して、ＲＥＳＯＬＶＥメッセージ２３４の肯定応答とする。ＲＥＳＯＬＶＥフラグＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮがセットされていた場合、ＮｅｘｔＨｏｐの認証連鎖がＡＵＴＨＯＲＩＴＹ  ２３８に含まれる。次のホップのＰＮＲＰ  ＩＤに対応するピア名のクラシファイア（Ｃｌａｓｓｉｆｉｅｒ）文字列部分はＡＵＴＨＯＲＩＴＹメッセージに含まれる。
【００７１】
ノードＢ  ２３０は、現在のＢｅｓｔＭａｔｃｈよりも正確に一致しているローカルで登録されているＣＰＡがあるかどうかチェックする。あれば、ＢｅｓｔＭａｔｃｈをそれで置き換える。ノードはまた、ＯｐＣｏｄｅ、Ｐｒｅｃｉｓｉｏｎ、およびＴａｒｇｅｔＩＤに基づき、ＲＥＳＯＬＶＥ基準を満たすローカルで登録されているＣＰＡがあるかどうかもチェックする。一致があれば、または経路リスト内のエントリの個数＞＝ＭａｘＨｏｐｓであれば、ノードは現在のＢｅｓｔＭａｔｃｈを持つＲＥＳＰＯＮＳＥメッセージを作成する。ＲＥＳＯＬＶＥメッセージの経路は、ＲＥＳＰＯＮＳＥメッセージの経路にコピーされる。ノードは、ＲｅｓｐｏｎｓｅＣｏｄｅを設定して、ＲＥＳＵＬＴ＿ＦＯＵＮＤ＿ＭＡＴＣＨまたはＲＥＳＵＬＴ＿ＭＡＸ＿ＨＯＰ＿ＬＩＭＩＴ＿ＨＩＴのいずれかを示す。その後、ノードは、経路リストからアドレスを除去するだけでなく、Ｒｅｊｅｃｔｅｄのマークが付けられている後続のエントリも除去し、ＲＥＳＰＯＮＳＥをＡｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリに送信する。
【００７２】
ノードＢ  ２３０は、ＲＥＳＰＯＮＳＥを送信しなかった場合（図４に示されている）、次のノードＴ  ２３２にＲＥＳＯＬＶＥメッセージ２３６を転送しようと試みる。この転送は、上述の手順に従って行われる。つまり、ノードＴ  ２３２は、最初、ＡＵＴＨＯＲＩＴＹメッセージ２４２で応答する。次に、上述のチェックを実行し、ターゲットと一致していることを判別してから、それ自身をＢｅｓｔＭａｔｃｈとして識別するＲＥＰＯＮＳＥメッセージ２４４でノードＢ  ２３０に応答する。ＲＥＳＰＯＮＳＥメッセージ２４４に応答して、ノードＢ  ２３０はＡＣＫメッセージ２４６を送り返す。その後、ノードＢ  ２３０は経路リストをチェックし、ＲＥＳＰＯＮＳＥメッセージ２４０をノードＡ  ２２８に転送し、ＡＣＫメッセージ２４８で応答する。
【００７３】
上記のように、ノードは、さらに、バックトラックされたＲＥＳＯＬＶＥも処理できなければならない。ノードは、ＲＥＳＯＬＶＥメッセージＲを受信するときに、Ｔａｒｇｅｔ  ＩＤ  ＰＮＲＰ  ＩＤ、ＢｅｓｔＭａｔｃｈ  ＣＰＡ、ＮｅｘｔＨｏｐ  ＰＮＲＰ  ＩＤ、およびＲＥＳＯＬＶＥを処理したすべてのノードのアドレスが記載されている経路リストを含む。バックトラックされたＲＥＳＯＬＶＥについては、フラグフィールドにＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰが設定される。このノードは、まず、「受信済みビットマップ」をチェックして、それがすでにこのＲＥＳＯＬＶＥを転送していることを確認する。ビットがセットされていない場合、メッセージは削除される。次に、ノードは経路リストをチェックして、そのアドレスが経路リスト上にあること、および経路リスト内でＡｃｃｅｐｔｅｄのマークが付けられている最上位のエントリであることを確認する。そうでなければ、メッセージを削除する。メッセージが削除されない場合、ノードはＡＵＴＨＯＲＩＴＹを送信側に送り返し、そのメッセージの肯定応答（ＡＣＫ）とする。これは、認証連鎖を含まない。
【００７４】
経路リスト内のエントリの個数＞＝ＭａｘＨｏｐｓであれば、ノードは現在のＢｅｓｔＭａｔｃｈを持つＲＥＳＰＯＮＳＥメッセージＳを作成する。ＲＥＳＯＬＶＥメッセージＲの経路は、Ｓの経路にコピーされる。ノードは、応答コードを設定し、Ｍａｘ  Ｈｏｐｓを超えたことを示す。その後、ノードは、経路リストからアドレスを除去し、ＲＥＳＰＯＮＳＥをＡｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリに送り返す。ノードは、ＲＥＳＰＯＮＳＥを送信しなかった場合、ＲＥＳＯＬＶＥを次のホップに転送しようとする。この転送は上述の手順に従うが、ただし、いくつか例外があり、ａ）「ノードＢ  ２３０は、現在のＢｅｓｔＭａｔｃｈよりも正確に一致しているローカルで登録されているＣＰＡがあるかどうかチェックする。あれば、ＢｅｓｔＭａｔｃｈをそれで置き換える。」は適用されず、ｂ）現在のノードがＲＥＳＯＬＶＥトランザクションの発信元であり、理由がＲＥＡＳＯＮ＿ＲＥＰＡＩＲ＿ＤＥＴＥＣＴＩＯＮであれば、処理は完了である。
【００７５】
上で簡単に説明したように、ノードは、ＲＥＳＰＯＮＳＥメッセージ２４４、２４０を受信するときに、ＴａｒｇｅｔＩＤ  ＰＮＲＰ  ＩＤ、ＢｅｓｔＭａｔｃｈ  ＣＰＡ、およびＲＥＳＯＬＶＥを処理したすべてのノードのアドレスが記載されている経路リストを含む。また、受信ノードは、「受信済みビットマップ」をチェックして、それがすでにこのＲＥＳＰＯＮＳＥ２４０、２４４と一致するＲＥＳＯＬＶＥ  ２３４、２３６を送信していることを確認する。ビットがセットされていない場合、メッセージは削除される。また、受信ノードは経路リストをチェックして、そのアドレスが経路リスト上の最後のアドレス（一番最近）であること、およびＡｃｃｅｐｔｅｄのマークが付けられていることを確認する。そうでなければ、メッセージを削除する。メッセージが削除されない場合、この受信ノードはＡＣＫ  ２４６、２４８を送信し、受信したことについて肯定応答する。ノードは、できる限りＢｅｓｔＭａｔｃｈ  ＣＰＡの妥当性を確認し、キャッシュに追加する。ＣＰＡをキャッシュに追加する場合、さらにメッセージ交換が必要になると思われる一組の規則が適用され、ＰはＢｅｓｔＭａｔｃｈ  ＣＰＡの妥当性を確認することができる。これについては、上記の出願で説明されている。
【００７６】
次に、ノードは自動的に経路リストから除去される。ノードは、Ａｃｃｅｐｔｅｄのマークが付けられているエントリに出会うか、リストが尽きるまで、Ｒｅｊｅｃｔｅｄのマークが付けられている前のエントリも除去する。Ａｃｃｅｐｔｅｄのマークが付けられているエントリが見つかると、ノードはＲＥＳＰＯＮＳＥをこのノードに転送する。ＲＥＳＰＯＮＳＥが転送されたノードがＡＣＫで応答しない場合、ノードはＲＥＳＰＯＮＳＥを最大Ｎ回まで再送する。再送がタイムアウトになった場合、ノードは経路リストから失敗した転送先ノードを除去し、この段落で説明したＲＥＳＰＯＮＳＥ処理を再試行する。経路リスト内にエントリがなくなれば、そのノードがオリジナルのＲＥＳＯＬＶＥ  ２３４の発信元である。ノード２２８は、その要求の発信元であったことを確認する。発信していなければ、ＲＥＳＰＯＮＳＥは削除される。応答コードが成功を示している場合、ノード２２８はＢｅｓｔＭａｔｃｈ  ＣＰＡの送信元に対しアイデンティティ妥当性確認チェックを実行する。そのためには、ＩＮＱＵＩＲＥメッセージ２５０をターゲットノード２３２に送信し、返されたＡＵＴＨＯＲＩＴＹメッセージ２５２を確認する必要がある。アイデンティティ妥当性確認が失敗した場合、応答コードをＩＤＥＮＴＩＴＹ＿ＦＡＩＬＵＲＥに変更する。結果を呼び出し側に返す。
【００７７】
ＡＵＴＨＯＲＩＴＹメッセージは、送信側によってフラグメント化される場合がある。ＡＵＴＨＯＲＩＴＹメッセージを処理する前にすべてのフラグメントを受信したことを確認するのは受信側に任される。妥当な時間内にフラグメントが受信されない場合、リトライカウントを超えるまで、オリジナルのメッセージ（ＩＮＱＵＩＲＥまたはＲＥＳＯＬＶＥ）を再送しなければならない。ＡＵＴＨＯＲＩＴＹメッセージフラグにＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮがセットされている場合、ノードはＶａｌｉｄａｔｅＩＤで指定されているＰＮＲＰ  ＩＤに対するキャッシュされたＣＰＡに連鎖妥当性確認オペレーションを実行する必要がある。この連鎖をチェックして、その中のすべての認証が有効であること、およびその連鎖の根と葉との関係が有効であることを確認しなければならない。この連鎖の根に対する公開鍵のハッシュをＣＰＡのピア名のオーソリティと比較して、一致していることを確認しなければならない。この連鎖の葉に対する公開鍵をＣＰＡの署名に使用する鍵と突き合わせて比較し、一致していることを確認しなければならない。最後に、Ｐ２Ｐ  ＩＤをチェックして、Ｐ２Ｐ  ＩＤを作成するための規則に従って、オーソリティおよびクラシファイアのハッシュであるか調べなければならない。上記のチェックが失敗した場合、ＣＰＡをキャッシュから除去し、ＲＥＳＯＬＶＥメッセージ経路リストにＡＵＴＨＯＲＩＴＹメッセージを送ったノードのアドレスを追加し、エントリにＲｅｊｅｃｔｅｄのマークを付けることによりＲＥＳＯＬＶＥメッセージを修正しなければならない。
【００７８】
ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤがセットされている場合、ＣＰＡをキャッシュから除去しなければならない。ＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮがセットされていないが、ＶａｌｉｄａｔｅＩＤ  ＰＮＲＰ  ＩＤに対応するＣＰＡは認証連鎖の妥当性確認を必要とする場合、ＣＰＡをキャッシュから除去し、ＲＥＳＯＬＶＥメッセージ経路リストにＡＵＴＨＯＲＩＴＹメッセージを送ったノードのアドレスを追加し、エントリにＲｅｊｅｃｔｅｄのマークを付けることによりＲＥＳＯＬＶＥメッセージを修正しなければならない。
【００７９】
ＶａｌｉｄａｔｅＩＤ  ＰＮＲＰ  ＩＤに対応するＣＰＡの妥当性確認が行われている場合、完全に妥当性確認が行われているというマークを付けなければならない。ＡＵＴＨＯＲＩＴＹメッセージからクラシファイア文字列を抽出して、ＣＰＡとともに保持する。ＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹ、ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤ、ＡＦ＿ＲＥＪＥＣＴ＿ＬＯＯＰ、およびＡＦ＿ＩＮＶＡＬＩＤ＿ＲＥＱＵＥＳＴがすべてクリアであれば、ＲＥＳＯＬＶＥは処理できるものとして受理され、ＡＵＴＨＯＲＩＴＹ処理が実行される。
【００８０】
いくつかの場合において、ＲＥＳＯＬＶＥメッセージを受信したノードは、転送に関して受理しないことを選択できるが、それでもＮｅｘｔ  Ｈｏｐの推奨を送信ノードに送る。この場合、ノードは推奨された参照エンドポイント（Ｒｅｆｅｒｒａｌ  Ｅｎｄｐｏｉｎｔ）および参照ＰＮＲＰ  ＩＤをＡＵＴＨＯＲＩＴＹメッセージで返す。この場合、ＡＵＴＨＯＲＩＴＹフラグの値にＡＦ＿ＲＥＤＩＲＥＣＴが含まれていなければならない。ＡＦ＿ＲＥＤＩＲＥＣＴとともにＡＵＴＨＯＲＩＴＹを受信するノードは、ＲＥＳＯＬＶＥメッセージを送信するために参照エンドポイントを使用するかしないかを選択することができる。いずれかの場合に、ＡＵＴＨＯＲＩＴＹで応答したノードが経路リストに追加される。ノードが参照エンドポイントを使用すべきなのは、ＲＥＳＯＬＶＥの発信元であるノードが発信してクラウド分割を検出し、ＲＥＳＯＬＶＥを理由ＲＥＡＳＯＮ＿ＲＥＰＡＩＲとともにＰＮＲＰシードサーバに送信している場合のみである。他の場合には、ノードは参照エンドポイントを無視しなければならない。
【００８１】
ＰＮＲＰは、有向フラッディング（ｄｉｒｅｃｔｅｄ  ｆｌｏｏｄｉｎｇ）を使用して、ノード間でＣＰＡキャッシュエントリを伝搬する。いくつかの場合に、フラッディングが使用される。ＲＥＱＵＥＳＴメッセージに応答して同期をとる際に、要求されたＣＰＡは、ＲＥＱＵＥＳＴを送信したピアにフラッディングされる。ＲＥＱＵＥＳＴメッセージは、ＳＯＬＩＣＩＴメッセージが受け付けられ、ＡＤＶＥＲＴＩＳＥメッセージが送信された後でないと受け付けられない。ＣＰＡがキャッシュの最低レベルに追加されると必ず、追加されたＣＰＡはローカル登録ＩＤに一番近いｎ個のピアにフラッディングされる。値ｎは、チューニングすることができるが、値４が好ましい。ＣＰＡを追加する理由がＦＬＯＯＤの受信であれば、ＣＰＡは、アドレスが受信したＦＬＯＯＤのフラッデッドリスト（Ｆｌｏｏｄｅｄ  Ｌｉｓｔ）に入っているノードにフラッディングすべきではない。十分な空きがあれば、受信フラッデッドリスト内のアドレスを新しいＦＬＯＯＤメッセージのフラッデッドリストにコピーしなければならない。ＣＰＡ取り消しを含むＦＬＯＯＤの受信後ＣＰＡがキャッシュの最低レベルから除去されると必ず、取り消されたＣＰＡはローカル登録ＩＤに一番近いｎ個のピアにフラッディングされる。またも、値ｎは、チューニングすることができるが、値４が好ましい。ＣＰＡは、アドレスが受信したＦＬＯＯＤのフラッデッドリストに入っているノードにフラッディングすべきではない。十分な空きがあれば、受信フラッデッドリスト内のアドレスを新しいＦＬＯＯＤメッセージのフラッデッドリストにコピーしなければならない。最後に、新しいピアに対してＦＬＯＯＤが受信され、ＣＰＡがキャッシュの最低レベルに追加されると、ローカルノードのＩＤとともにその新しいピアにＦＬＯＯＤメッセージが送信される。ＦＬＯＯＤの送信元が新しいピアであれば、例外が生じる。
【００８２】
ＰＮＲＰは、永続的な近隣関係を作らない。最も緩やかな意味では、ＣＰＡキャッシュ内でＣＰＡにより表されるすべてのノードは、近隣ノードとみなすことができる。しかし、ＣＰＡのキャッシュへの追加および除去は、ＣＰＡ発行者に必ずしも通知せずに行われる。ノードのキャッシュ内にピアのＣＰＡを置いても、近隣ノードがそのノードのＣＰＡをキャッシュに置くとは限らない。この関係は非対称である。しかし、上述の最後のＦＬＯＯＤ条件では、互いに近いＩＤに対し対称性を実現しようとする。
【００８３】
そのＦＬＯＯＤに対し他のアクションを実行する前に、ＡＣＫですべてのＵＤＰ  ＦＬＯＯＤメッセージについて肯定応答する。ＦＬＯＯＤの送信側は、ＦＬＯＯＤが送信されたある期間の状態を保持する。ＡＣＫを受信すると、その状態は解放される。一定期間ＡＣＫが受信されないと、ＦＬＯＯＤが再送され、タイマーがリセットされる。ＦＬＯＯＤは、所定の回数まで再試行されるが、３回が好ましい。最後の再試行の後にＡＣＫが受信されないと、その状態は解放される。さらに、ＦＬＯＯＤの送信先が送信側のキャッシュ内にあった場合、これ以降未応答ノードへのメッセージの送信を試みないようキャッシュエントリが除去される。
【００８４】
ノードがＦＬＯＯＤメッセージを受信すると、まず最初にＡＣＫを送信してＦＬＯＯＤメッセージについて肯定応答することによりメッセージが処理される。ＶａｌｉｄａｔｅＩＤが存在しており、ローカルで登録されていない場合、フラグフィールドは「ＫＦ＿ＮＡＣＫ」に設定される。次に、ＦＬＯＯＤメッセージの妥当性確認が行われる。これは、ＣＰＡ署名および内容に対するローカルでの確認を含む。ＣＰＡの妥当性確認が行われた場合、ＣＰＡをキャッシュに追加するかどうかが決定される。ＣＰＡがローカルの同じノード上で登録されているＰＮＲＰ  ＩＤに対するものであれば、キャッシュに追加する必要はない。ＣＰＡだけではＣＰＡを署名するために使用されるアイデンティティを確認できず、またＣＰＡがキャッシュビューの２つの低いレベルのうちの１つに追加される場合、後述のようにアイデンティティ妥当性確認を実行する必要がある。妥当性確認が失敗した場合、ノードはＦＬＯＯＤメッセージを削除する。成功した場合、ノードはＦＬＯＯＤを処理し続ける。ＣＰＡがすでに期限切れになっている場合、ノードはＦＬＯＯＤを削除する。ＣＰＡが取り消しＣＰＡの場合、キャッシュに対応するＣＰＡがあれば、ノードはそれをキャッシュから除去する。見つかった場合、ノードはＦＬＯＯＤメッセージを送信することにより取り消しを他の近隣ノードに送る。
【００８５】
ＣＰＡが取り消しＣＰＡでない場合、ノードはキャッシュを更新する。一致するＣＰＡがすでにキャッシュ内にある場合、ノードは新しいＣＰＡデータでキャッシュエントリを更新する。これが新しいエントリであれば、ノードは新しいエントリを作成し、キャッシュへの追加を試みる。別のエントリを除去して入れる余地を作る必要がある場合にはエントリを追加できないが、信頼度レベルが高い、または近接性測定基準が優れているため既存のエントリは新しいエントリよりも好ましい。エントリが最低キャッシュレベルに属している場合は、追加しなければならない。ＣＰＡが最低キャッシュレベルに属している場合、キャッシュに追加できない場合であっても、いくつかの近隣ノードに転送しなければならない。同期中にＦＬＯＯＤを受信した場合、すべての発見されたＣＰＡはすでに他のノードに知られていると想定されるため、ＦＬＯＯＤメッセージの転送が抑制される。ＦＬＯＯＤを転送する必要がある場合、ローカルで登録されているＩＤに最も近いｎ個のＰＮＲＰ  ＩＤの集まりが選択される。新しいＣＰＡ、およびｎ個の近隣ノードを記述したフラッデッドリスト、さらにそれに加えて受信されたＦＬＯＯＤメッセージ内の受信フラッデッドリストの内容とともに、ＦＬＯＯＤメッセージがそれぞれのＩＤに送信される。
【００８６】
アイデンティティ妥当性確認は、ＣＰＡの妥当性を確認する場合に使用される脅威緩和デバイス（ｔｈｒｅａｔ  ｍｉｔｉｇａｔｉｏｎ  ｄｅｖｉｃｅ）である。これは２つの目的を有する。第１に、アイデンティティ妥当性確認により、ＣＰＡで指定されたＰＮＲＰノードがローカルで登録されているそのＣＰＡからのＰＮＲＰ  ＩＤを持つことが保証される。第２に、セキュリティ保護されたＰＮＲＰ  ＩＤに対して、アイデンティティ妥当性確認により、ＰＮＲＰ  ＩＤのオーソリティと暗号により実証可能な関係のある鍵を使用して、ＣＰＡが署名されていることが保証される。アイデンティティ妥当性確認でこれら２つの目標を達成する詳細については、上記の係属中の出願において説明されている。
【００８７】
２つの異なる時期に、アイデンティティ妥当性確認チェックが実行される。第１に、アイデンティティ妥当性確認は、ＣＰＡを最低の２つのキャッシュレベルに追加する場合に実行される。最低の２つのキャッシュレベルにおけるＣＰＡが有効であることは、ＰＮＲＰでＰＮＲＰ  ＩＤを解決するために重要である。ＣＰＡをこれら２つのレベルのいずれかに追加する前にアイデンティティ妥当性確認を実行すると、複数の攻撃が緩和される。この場合、ＣＰＡは最大、例えば３０秒間リスト内に保持され、ＡＵＴＨＯＲＩＴＹメッセージが届くのを待つ。第２に、アイデンティティ妥当性確認は、ＲＥＳＯＬＶＥのときにチャンスがあれば実行される。ＰＮＲＰキャッシュの回転率は高い。したがって、ほとんどキャッシュエントリは、そもそも使用される前にキャッシュ内で上書きされてしまう。ＰＮＲＰは、実際に使用するまでほとんどのＣＰＡの妥当性を確認しない。ＣＰＡを使用して、ＲＥＳＯＬＶＥ経路の選択を行う場合、ＰＮＲＰはアイデンティティ妥当性確認をＲＥＳＯＬＶＥメッセージと抱き合わせの形で実行する。ＲＥＳＯＬＶＥには、「次のホップ」ＩＤが含まれ、これは、ＩＮＱＵＩＲＥメッセージの「ターゲットＩＤ」と同じように処理される。ＲＥＳＯＬＶＥに対しＡＵＴＨＯＲＩＴＹメッセージにより肯定応答されるが、ＩＮＱＵＩＲＥに対し期待されているのと同じである。チャンスがあれば実行するアイデンティティ妥当性確認が失敗した場合、ＲＥＳＯＬＶＥの受信側は、送信側でそうであると信じている受信側ではない。したがって、ＲＥＳＯＬＶＥに対してはどこか他の経路が選択され、無効なＣＰＡがキャッシュから除去される。
【００８８】
この妥当性確認を例示するため、ＰがＰＮＲＰ  ＩＤ「Ｔ」に対するアイデンティティ妥当性確認を要求するノードであると仮定する。Ｎは、アイデンティティ妥当性確認要求を受信するノードである。Ｐは、ターゲットＩＤ＝ＴのＩＮＱＵＩＲＥメッセージ、または次のホップ＝ＴのＲＥＳＯＬＶＥメッセージのいずれかを生成する（そしてＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰは設定されない）。Ｎは、ローカルで登録されているＰＮＲＰ  ＩＤのリストをチェックする。Ｔがそのリスト内になければ、ＮはＡＵＴＨＯＲＩＴＹメッセージで応答し、ＩＤ  Ｔがローカルで登録されていないことを示す。受信されたメッセージがＲＥＳＯＬＶＥであった場合、Ｐがどこか他への転送を処理するため、ＲＥＳＯＬＶＥは破棄される。ＴがＮでＰＮＲＰ  ＩＤのリスト内にある場合、ＮはＡＵＴＨＯＲＩＴＹメッセージを構築し、ターゲットＩＤをＴに設定する。ＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮフラグがセットされていた場合、ＮはＰＮＲＰ  ＩＤ  Ｔに対するオーソリティにＣＰＡを署名するために使用される鍵に関係する認証連鎖（もしあれば）を取り出す。認証連鎖は、ＡＵＴＨＯＲＩＴＹメッセージの中に挿入される。ピア名のクラシファイア部分も、ＡＵＴＨＯＲＩＴＹメッセージに追加される。
【００８９】
ＮはＰへＡＵＴＨＯＲＩＴＹメッセージを送信する。ＡＵＴＨＯＲＩＴＹメッセージが１２１６バイトよりも長い場合、メッセージは１２１６バイト以下の複数のフラグメントに分割され、各フラグメントが送信される。Ｔがセキュリティ保護されていないＩＤの場合、またはＣＰＡがすでに妥当性確認されていた場合（ＲＥＳＯＬＶＥを送信しＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮをクリアした）、処理は完了する。Ｐは、鍵を署名するＣＰＡとＰＮＲＰ  ＩＤ  Ｔを生成するために使用されるオーソリティとの関係の妥当性を確認する。妥当性確認が失敗した場合、ＣＰＡは破棄される。妥当性確認が失敗し、開始メッセージがＲＥＳＯＬＶＥであった場合、ＰはどこかほかへＲＥＳＯＬＶＥを転送する。
【００９０】
上記の出願で説明されているように、また上で簡単に説明したように、ＰＮＲＰクラウドは分割可能である。これは２通りの方法で行える。第１に、クラウドは、独立に開始することができ、マージする必要がある。第２に、クラウドは、一体として開始されている可能性があるが、クラウドの一部断片はクラウドの残りから分離されている可能性がある。可能な分割をブリッジするために、クラウドはシードサーバを指定していると仮定する。これらは、ＤＮＳを介してブートストラップするために使用するのと同じサーバである。クラウド内に複数のシードサーバがある場合、シードサーバ同士が定期的に連絡を取り合い、キャッシュでＩＤを交換するようにしなければならない。これは、同期処理を使用して実行できる。孤立した島を作ることが回避される。
【００９１】
クラウド内のノードは、定期的にシードサーバをポーリングし、ノードが主クラウドから孤立していないかテストし、必要ならばマージして戻すことを試みる。ノードが分割のテストを行う頻度は、クラウドのサイズの推定値に反比例する。これは、分割が頻繁に生じすぎないようにするテストである。最近クラウドに加入したノードは、クラウドのサイズを推定できると仮定する前に、そのキャッシュに初期値として値が入るまで一定期間待たなければならない。
【００９２】
クラウドのマージを使用可能にするには、ＰＮＲＰ  ＲＥＰＡＩＲメッセージを使用する。ＲＥＰＡＩＲは、ＰＮＲＰ  ＩＤ、ノードのＩＰアドレス、および修復レベル（Ｒｅｐａｉｒ  Ｌｅｖｅｌ）番号を含む。キャッシュレベルには、最上位レベルである０から始まる番号が付けられ（最大番号範囲）、それ以降のレベルには１ずつ高くなる番号が付けられる（小さな範囲）。分割が最初に検出されたら、修復レベル値を０に初期化する。ノードが分割コードのテストを実行すると決定した場合、ノードは内部で、ＩＰアドレス、ローカルで登録されているＰＮＲＰ  ＩＤ、およびレベル０として知られているシードサーバのアドレスを使用して、ＲＥＰＡＩＲを生成する。これはこのＲＥＰＡＩＲ自体を処理する。
【００９３】
ＲＥＰＡＩＲが処理されるときに、ノードは分割のテストを実行する。まず、ＲＥＰＡＩＲメッセージ内のＩＤに最も近いローカルで登録されているＩＤを見つける。次に、このＩＤ＋１に対するＲＥＳＯＬＶＥをＲＥＰＡＩＲメッセージで指定されているＩＰアドレスに送信する。このＲＥＳＯＬＶＥには、修復の理由コード（Ｒｅａｓｏｎ  Ｃｏｄｅ  ｏｆ  Ｒｅｐａｉｒｉｎｇ）がなければならない。これが知られているノードに解決する場合、分割はない。これが新しいノードに解決する場合、分割が疑われる。発見された新しいノードが最下位キャッシュレベル（番号は最高）にあれば、フラッディングをいつものように実行する。修復の理由コードがＦＬＯＯＤメッセージに設定される。同様に、ＲＥＳＯＬＶＥを受け取るノードが送信元ＩＤを最低キャッシュレベルに入れた場合、そのノードはエントリを送信元へフラッディングする。すべてこのフラッディングで、新しいクラウドと複数のＩＤの交換が行われる。フラッディングを介して発見されたすべての新しいノードは、このようにして追跡される。
【００９４】
発見された新しいノードがすでに知られているノードよりも近く、キャッシュエントリが受信修復レベルにある場合、ノードは修復レベルでＲＥＰＡＩＲメッセージをキャッシュ内のエントリに送る。ＲＥＰＡＩＲが送信される毎に、ノードは新しく発見されたノードＩＤとＩＰアドレスの１つを選択し、修復レベル＋１で渡す。発見された新しいノードがすでに知られているノードよりも遠い場合、ノードはＲＥＰＡＩＲを新しいノードに送信し、ローカルキャッシュからのあるＩＤおよびアドレスならびに受信修復レベルを渡す。ＲＥＰＡＩＲメッセージを受信する各ノードも同じようにして処理する。
【００９５】
明らかに、ＰＮＲＰプロトコルは１０個のメッセージタイプからなる。各メッセージは、ＰＮＲＰヘッダから始まり、その後に、そのメッセージタイプに固有のフィールドが続く。オーバーヘッド（フィールド記述など）は、各メッセージフィールドテーブルの「長さ」欄で別々に計算される。以下の説明では、これらのメッセージすべてにより共有される一般的メッセージデータ構造について説明し、その後、本発明のプロトコルに含まれる１０個のメッセージのそれぞれに対するメッセージデータ構造について詳述する。この説明の後に、本発明のメッセージを構築するために使用されるフィールドデータ構造のそれぞれについて説明する。
【００９６】
図５に例示されているのは、本発明のＰＮＲＰの１０個のメッセージを構築するために使用される基本メッセージデータ構造２６０を説明するデータ構造例の図である。これからわかるように、メッセージデータ構造２６０は、多数のフィールド２６２１−Ｎを含む。好ましい実施形態では、第１のフィールド２６２１はＰＮＲＰヘッダ用に予約されている。メッセージ２６０を構築するために使用される個々のフィールド２６２１−Ｎのそれぞれに対するフィールドデータ構造２６４は、型コンポーネント２６６、長さコンポーネント２６８、およびフィールドデータ構造２６４の実際の内容またはペイロード２７０を含む。長さコンポーネント２６８は、フィールド全体２６４の長さ２７２として計算される。このようにして、プロトコルは完全に拡張可能である。
【００９７】
本発明のデータ構造に従って、ＲＥＳＯＬＶＥメッセージを構築する。図６の簡略化したデータ構造図からわかるように、ＲＥＳＯＬＶＥメッセージ２８０は、多数のフィールド２８２〜２９２から構築される。また、本発明のフィールドデータ構造に従って、さまざまなフィールドを構築する。例えば、ＰＮＲＰ＿ＨＥＡＤＥＲフィールド２８２は、フィールドデータ構造２９４を含む。このデータ構造２９４の構成要素は、型（フィールドＩＤ２９６）、長さ２９８からなる。このＰＮＲＰ＿ＨＥＡＤＥＲデータ構造２９４の内容は、プロトコルコンポーネント３００、メジャーバージョンコンポーネント３０２、マイナーバージョンコンポーネント３０４、メッセージタイプコンポーネント３０６、およびメッセージＩＤコンポーネント３０８を含む。同様に、ＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤフィールド２８８は、フィールドデータ構造３１０を含む。他のすべてのフィールドデータ構造と同様、ＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤデータ構造３１０は型コンポーネント（フィールドＩＤ  ３１２）および長さコンポーネント３１４から始まる。このフィールドデータ構造の内容は、Ｐ２Ｐ  ＩＤコンポーネント３１６およびサービスロケーションコンポーネント３１８を含む。異なるフィールドはそれぞれ、図５に例示されているのと同様にして構築されるが、それぞれの説明は以下で行う。
【００９８】
明らかなように、また以下で例示するように、このＲＥＳＯＬＶＥメッセージは解決するターゲットＰＮＲＰ  ＩＤ、ＲＥＳＯＬＶＥ発信元のＣＰＡ、「最良一致」のＣＰＡ、およびＲＥＳＯＬＶＥを処理したノードのリストを含む。ＲＥＳＯＬＶＥは、「フラグ」フィールドを含む。Ｒｅｓｏｌｖｅ＿ＣｏｎｔｒｏｌｓフィールドのＦｌａｇｓサブフィールドに対し２つのフラグ、つまり、受信側がＡＵＴＨＯＲＩＴＹ応答で認証連鎖（もし存在すれば）を送信することを要求するＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮ−０ｘ０００１とＲＥＳＯＬＶＥのバックトラッキング経路上で使用されるＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰ−０ｘ０００４とが定義される。ノードがＲＥＳＯＬＶＥをバックトラッキングの一部として受信している場合、送信側はこのノードのＰＮＲＰ  ＩＤを知らない。「次のホップ」フィールドは０に設定され、ＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰはセットされて、ＡＵＴＨＯＲＩＴＹはＲＥＳＯＬＶＥに対する「ａｃｋ」としてのみ使用されることを示す。上述のように、ＲＥＳＯＬＶＥ受信は、ＡＵＴＨＯＲＩＴＹメッセージにより肯定応答される。ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは、本発明の好ましい実施では５に設定される。本発明の教示により構築されたＲＥＳＯＬＶＥメッセージのデータ構造の詳細を表５に提示した。
【００９９】
【表５】
0004786882.tif 000006
【０１００】
この表５で、Ｐは符号化されたＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められる。Ａは、フラグ付き配列内のエントリの個数である。したがって、Ｍａｘ  Ｈｏｐ値を超えてはならない。
【０１０１】
ＲＥＳＰＯＮＳＥは、ＲＥＳＯＬＶＥが、ターゲットＰＮＲＰ  ＩＤを所有するノードに到達したとき、またはフラグ付き経路サイズがＲＥＳＯＬＶＥ  Ｍａｘ  Ｈｏｐｓに等しいときに、生成される。ＲＥＳＰＯＮＳＥが生成されると、対応するＲＥＳＯＬＶＥフラグ付き経路からのすべてのエントリがＲＥＳＰＯＮＳＥ経路にコピーされる。ＲＥＳＰＯＮＳＥメッセージは、それぞれの適切なネットワークエンドポイントがＲＥＳＰＯＮＳＥを処理し、それがＲＥＳＯＬＶＥ発信元に返されるまで、経路リスト内で「ａｃｃｅｐｔ」のマークを付けられているすべてのアドレスを下から上まで通って送られる。上述のように、ＲＥＳＰＯＮＳＥ受信は、ＡＣＫメッセージにより肯定応答される。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは６に設定される。本発明の教示により構築されたＲＥＳＰＯＮＳＥメッセージのデータ構造の詳細を表６に提示した。
【０１０２】
【表６】
0004786882.tif 000007
【０１０３】
この表６で、Ｐは符号化された送信元ＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められる。Ｂは、エンドポイント配列内のエントリの個数である。
【０１０４】
ＳＯＬＩＣＩＴメッセージは、キャッシュから送信側へエントリをＡＤＶＥＲＴＩＳＥするよう受信側に要求するメッセージである。送信側は、受信側がキャッシュに追加できるＣＰＡを含む。ＨａｓｈｅｄＮｏｎｃｅは、ＡＤＶＥＲＴＩＳＥメッセージで返さなければならない。ＳＯＬＩＣＩＴ受信は、ＡＤＶＥＲＴＩＳＥメッセージにより肯定応答される。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは１に設定される。本発明の教示により構築されたＳＯＬＩＣＩＴメッセージのデータ構造の詳細を表７に提示した。この表で、Ｐは符号化された送信元ＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められる。
【０１０５】
【表７】
0004786882.tif 000008
【０１０６】
ＳＯＬＩＣＩＴへの応答としてＡＤＶＥＲＴＩＳＥメッセージが生成される。ＡＤＶＥＲＴＩＳＥにより、広告者のキャッシュ内からＰＮＲＰ  ＩＤのうちのいくつかのリストが表示される。これにより、ＡＤＶＥＲＴＩＳＥ受信側は、キャッシュに初期値を入力することを選択的にＣＰＡに要求することができる。ＡＤＶＥＲＴＩＳＥ受信は、ＳＯＬＩＣＩＴの肯定応答として働く。ＡＤＶＥＲＴＩＳＥの肯定応答は生成されない。ＳＯＬＩＣＩＴの肯定応答として機能しないＡＤＶＥＲＴＩＳＥは、何も通知せずに黙って破棄されるべきである。ＨａｓｈｅｄＮｏｎｃｅ値は、ＳＯＬＩＣＩＴメッセージで受信した値と同じでなければならない。ＡＤＶＥＲＴＩＳＥを受信したノードは、ＨａｓｈｅｄＮｏｎｃｅが有効であることを確認できなければならない。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは２に設定される。本発明の教示により構築されたＡＤＶＥＲＴＩＳＥメッセージのデータ構造の詳細を表８に提示した。この表で、ＡはＩＤ配列内のエントリの個数である。
【０１０７】
【表８】
0004786882.tif 000009
【０１０８】
ＲＥＱＵＥＳＴメッセージは、ＡＤＶＥＲＴＩＳＥされたＣＰＡの部分集合をＦＬＯＯＤするよう広告者に要求する場合に使用する。Ｎｏｎｃｅをハッシュして、オリジナルのＳＯＬＩＣＩＴで受信したＨａｓｈｅｄＮｏｎｃｅと比較しなければならない。ＩＤ配列には、送信側が、ＣＰＡを取得できるように送信側にフラッディングして戻したいＰＮＲＰ  ＩＤが含まれる。ＲＥＱＵＥＳＴ受信は、ＡＣＫメッセージにより肯定応答される。本発明の好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは３に設定される。本発明の教示により構築されたＲＥＱＵＥＳＴメッセージのデータ構造の詳細を表９に提示した。この表で、ＡはＩＤ配列内のエントリの個数である。
【０１０９】
【表９】
0004786882.tif 000010
【０１１０】
ＦＬＯＯＤメッセージは、ＰＮＲＰによって使用され、ピアを選択するためキャッシュされているＣＰＡを伝搬する。ＦＬＯＯＤは、新しいＣＰＡを最低キャッシュレベルに追加するとき、または最低キャッシュレベルの始めのほうのバージョンで取り消されたＣＰＡを処理するときに、ＲＥＱＵＥＳＴメッセージに応答して開始される。ＦＬＯＯＤは、冗長ＦＬＯＯＤの発生の防止を補助するための「フラッデッドリスト」と呼ばれるアドレスのリストを含む。フラッデッドリストには、送信側のアドレス、送信側が直接ＦＬＯＯＤを送信しようとするすべての送信先、およびすでにＦＬＯＯＤを受信したことを送信側が知っている他のＰＮＲＰノードのアドレスが含まれる。「フラッデッドリスト」には、最大数のエントリが含まれる。リストが満杯になった場合、ＦＩＦＯ方式でエントリが置き換えられる。このときに、ＦＬＯＯＤ受信側は離れている近隣ノードよりも「そばにある」近隣ノードにそのＦＬＯＯＤを伝搬する可能性が高いと想定する。ＦＬＯＯＤ受信は、ＡＣＫメッセージにより肯定応答される。ＩＤ妥当性確認は任意選択のフィールドである。存在する場合、指定されたＰＮＲＰ  ＩＤを持つＣＰＡがローカルでキャッシュされていれば受信側はＡＣＫで応答し、存在しない場合、ローカルでキャッシュされていなければＮＡＣＫで応答する。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは４に設定される。本発明の教示により構築されたＦＬＯＯＤメッセージのデータ構造の詳細を表１０に提示した。この表で、Ｐは符号化されたＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められ、Ａは配列内のエントリの個数である。
【０１１１】
【表１０】
0004786882.tif 000011
【０１１２】
ＰＮＲＰノードは、ＩＮＱＵＩＲＥメッセージを使用して、選択ＣＰＡに対しアイデンティティ妥当性確認を実行してから、ローカルキャッシュに入力する。アイデンティティ妥当性確認によりＣＰＡがまだ発信元ノードで有効であることを確認し、そのＣＰＡを登録するために発信元ノードのオーソリティの妥当性確認を補助する情報を要求する。「フラグ」フィールドに対して１つのフラグ、つまりＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮが定義されるが、このフラグは認証連鎖（存在する場合）をＡＵＴＨＯＲＩＴＹ応答で送信するよう受信側に要求するフラグである。ＩＮＱＵＩＲＥ受信は、ＰＮＲＰ  ＩＤがローカルで登録されている場合に、ＡＵＴＨＯＲＩＴＹメッセージにより肯定応答される。そうでなければ、ＩＮＱＵＩＲＥメッセージは黙って無視される。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは７に設定される。本発明の教示により構築されたＩＮＱＵＩＲＥメッセージのデータ構造の詳細を表１１に提示した。この表から明らかなように、ＦＬＡＧＳ＿ＦＩＥＬＤの後にさらに２バイトあり、次のフィールドはＤＷＯＲＤ境界に置かれる。
【０１１３】
【表１１】
0004786882.tif 000012
【０１１４】
ＡＵＴＨＯＲＩＴＹメッセージは、ＰＮＲＰ  ＩＤがローカルノードにまだ登録されていることを確認するかまたは否認するために使用され、任意選択により、ＡＵＴＨＯＲＩＴＹ受信側がターゲットＩＤに対応するＣＰＡを登録するノードの権利の妥当性確認を行えるようにする認証連鎖を提供する。「フラグ」フィールドに対して定義されているフラグは、指定された「妥当性確認」ＰＮＲＰ  ＩＤがこのホストに登録されていないことを示す、ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤ−０ｘ０００１、使用されていないＡＦ＿ＩＮＶＡＬＩＤ＿ＳＯＵＲＣＥ−０ｘ０００２、これもまた使用されていないＡＦ＿ＩＮＶＡＬＩＤ＿ＢＥＳＴ＿ＭＡＴＣＨ−０ｘ０００４、ＲＥＳＯＬＶＥに対する応答でのみ有効であり、ホストがビジー状態であるためＲＥＳＯＬＶＥを受け付けられず、送信側は処理のため別のところに転送しなければならないことを示すＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹ−０ｘ０００８、使用されていないＡＦ＿ＲＥＪＥＣＴ＿ＤＥＡＤＥＮＤ−０ｘ００１０、ノードがすでにＲＥＳＯＬＶＥメッセージを処理しており、ここに送信すべきではなかったことを示すＡＦ＿ＲＥＪＥＣＴ＿ＬＯＯＰ−０ｘ００２０、デバッグにのみ使用されるＡＦ＿ＴＲＡＣＩＮＧ＿ＯＮ−０ｘ００４０、ノードがＲＥＳＯＬＶＥメッセージを転送していないが、ＡＵＴＨＯＲＩＴＹメッセージ内に参照アドレスを含めていることを示すＡＦ＿ＲＥＤＩＲＥＣＴ−０ｘ００８０、ＭａｘＨｏｐｓが大きすぎると発生する可能性のあるＲＥＳＯＬＶＥメッセージの妥当性確認失敗を示すＡＦ＿ＩＮＶＡＬＩＤ＿ＲＥＱＵＥＳＴ−０ｘ０１００、およびＶａｌｉｄａｔｅ  ＰＮＲＰ  ＩＤとＣＰＡの署名に使用される公開鍵との関係の妥当性確認を可能にする認証連鎖が含まれることを示すＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮ−０ｘ８０００である。
【０１１５】
Ｖａｌｉｄａｔｅ  ＰＮＲＰ  ＩＤは、ＡＵＴＨＯＲＩＴＹが送信されるＩＤを有する。認証連鎖は任意選択である。ＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮフラグは、それが存在しているかいないかを示す。参照エンドポイントも任意選択である。このフィールドは、ＲＥＳＯＬＶＥメッセージを転送できないが、ＲＥＳＯＬＶＥを送信できた別の送信先ノードを認識しているノードにより使用される。エンドポイントは、ＲＥＳＯＬＶＥの送信先であるピアノードのＩＰｖ６アドレスおよびポートを含む。現在、このフィールドは、ノードがシードサーバを介してクラウド分割を検出しようとしているときを除いて無視される。クラシファイアフィールドは、ＰＮＲＰ  ＩＤを作成するために使用されるピア名の一部である実際のクラシファイア文字列を含む。ＡＵＴＨＯＲＩＴＹ受信は、明示的に肯定応答されない。ＡＵＴＨＯＲＩＴＹは、ＩＮＱＵＩＲＥまたはＲＥＳＯＬＶＥメッセージに対する肯定応答／応答としてのみ送信される。ＡＵＴＨＯＲＩＴＹは、このコンテキストから受信される場合は、破棄されなければならない。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは８に設定される。本発明の教示により構築されたＡＵＴＨＯＲＩＴＹメッセージのデータ構造の詳細を表１２に提示した。この表で、Ｃは符号化された認証連鎖の長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められ、Ｓはクラシファイア文字列の長さ（バイト）である。
【０１１６】
【表１２】
0004786882.tif 000013
【０１１７】
ＡＵＴＨＯＲＩＴＹメッセージは、認証連鎖およびクラシファイア文字列を含むため、非常に長い場合がある。ネットワークを介した伝送を円滑にするため、送信時に複数のフラグメントに明示的に分割できる。受信側は、メッセージを処理する前にフラグメントをまとめることができなければならない。メッセージが分割される場合、ヘッダフィールドおよび肯定応答されたヘッダフィールドはそれぞれのフラグメントの中で繰り返される。各フラグメントはさらに、分割コントロール（Ｓｐｒｉｔ  Ｃｏｎｔｒｏｌ）フィールドも含む。各フラグメントにおいて、分割コントロールフィールド内のオフセット値が変更され、フラグメントのオフセットが反映される。分割コントロール内のサイズ値は、メッセージ全体のサイズからヘッダ、肯定応答されたヘッダ、および分割コントロールフィールドのサイズを引いた値である。最後を除く各フラグメントは、同じサイズでなければならない。メッセージが分割されない場合、分割コントロールフィールドは任意選択である。
【０１１８】
ＡＣＫメッセージはＰＮＲＰによって使用されるが、ＰＮＲＰは要求／応答プロトコルだからである。いくつかの状況では、応答の代わりにＡＣＫを使用することでプロトコルが簡素化される。ＡＣＫは、ＲＥＱＵＥＳＴ、ＲＥＳＰＯＮＳＥ、およびＦＬＯＯＤメッセージを受信した後常に送信される。他のメッセージは、適切な応答メッセージタイプにより肯定応答される。ＡＣＫは、ＡＣＫとして働くが、妥当性確認ＩＤがセットされているＦＬＯＯＤの場合には、フラグフィールドをＫＦ＿ＮＡＣＫ＝１に設定することによりＮＡＣＫとして働く。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは９に設定される。本発明の教示により構築されたＡＣＫメッセージのデータ構造の詳細を表１３に提示した。
【０１１９】
【表１３】
0004786882.tif 000014
【０１２０】
ＲＥＰＡＩＲメッセージが使用されるのは、場合によって、ＰＮＲＰクラウドに分割が生じる可能性があるためである。このメッセージを使用して、分割のテストを実行し、必要ならばＲＥＰＡＩＲを開始する。ＲＥＰＡＩＲでは、ＲＥＰＡＩＲを他のキャッシュレベルに伝搬するよう他のノードに要求する。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは１０に設定される。本発明の教示により構築されたＲＥＰＡＩＲメッセージのデータ構造の詳細を表１４に提示した。この表から明らかなように、ＣＡＣＨＥ＿ＬＥＶＥＬの後にさらに２バイトあり、次のフィールドはＤＷＯＲＤ境界に置かれる。
【０１２１】
【表１４】
0004786882.tif 000015
【０１２２】
これまでメッセージおよびそのデータ構造について説明してきたが、今度は、そのメッセージを構築するために使用するメッセージ要素に注目する。以下では、ＰＮＲＰメッセージで送信される構造体のバイトコードを詳述する。断りのない限り、数値はすべてネットワークバイト順で送信され、送信前にテキストはすべてＵＴＦ−８で符号化される。これらのメッセージ要素は、説明したばかりのメッセージのビルディングブロックである。基本メッセージ要素はフィールド記述である。各フィールド要素は、メッセージ内の４バイト境界で始まる必要がある。つまり、フィールド間にはギャップがありうるということである。
【０１２３】
ＭＥＳＳＡＧＥ＿ＦＩＥＬＤ要素は、将来ＰＮＲＰを容易に拡張できるようにするため使用されるフィールド記述である。メッセージ内のデータの集合毎に、フィールドの型を示す１６ビットの「フィールドＩＤ」とフィールドに対する１６ビットバイトカウントが用意される。本発明の教示により構築されたＭＥＳＳＡＧＥ＿ＦＩＥＬＤ要素のデータ構造の詳細を表１５に提示した。
【０１２４】
【表１５】
0004786882.tif 000016
【０１２５】
ＰＮＲＰ＿ＨＥＡＤＥＲ−型０ｘ００１０は、すべてのＰＲＮＰメッセージの先頭に使用される。プロトコル＋バージョンは４バイト識別子であり、受信したメッセージが本当にＰＮＲＰを対象としたものかどうかを判別するのに使用される。本発明の教示により構築されたＰＮＲＰ＿ＨＥＡＤＥＲ要素のデータ構造の詳細を表１６に提示した。
【０１２６】
【表１６】
0004786882.tif 000017
【０１２７】
ＰＮＲＰ＿ＨＥＡＤＥＲのメッセージＩＤを使用することで、ノードは、ノードが送信したメッセージに対する応答であると主張する受信メッセージが実際にそのような応答であることを確認できる。例えば、ノードがＲＥＳＯＬＶＥメッセージを別のノードに送信すると仮定する。この第１のノードは、図４に示されているように、引き換えにＡＵＴＨＯＲＩＴＹメッセージを受信することを予期する。しかし、オリジナルのＲＥＳＯＬＶＥに対する応答を追跡またはトレースしないと、受信したＡＵＴＨＯＲＩＴＹメッセージが正当なものである、あるいはクラウド内の悪意あるノードによるスプーフィングであるという保証はない。ＲＥＳＯＬＶＥメッセージにメッセージＩＤを含めることにより、ＡＵＴＨＯＲＩＴＹメッセージを生成するノードは、後述のＰＮＲＰ＿ＨＥＡＤＥＲ＿ＡＣＫＥＤフィールドに、応答の中のこのメッセージＩＤを含めることができる。
【０１２８】
ＰＮＲＰ＿ＨＥＡＤＥＲ＿ＡＣＫＥＤ−型０ｘ００１８は、ＰＮＲＰメッセージヘッダ全体であり、肯定応答されるメッセージを識別する場合に使用される。本発明の教示により構築されたＰＮＲＰ＿ＨＥＡＤＥＲ＿ＡＣＫＥＤ要素のデータ構造の詳細を表１７に提示した。
【０１２９】
【表１７】
0004786882.tif 000018
【０１３０】
ＩＰＶ６＿ＥＮＤＰＯＩＮＴ−型０ｘ００２１要素が使用されるのは、ＰＮＲＰがＩＰｖ６クラウド内で動作するように指定されているためである。この構造体により、ＩＰｖ６ネットワークエンドポイントを指定する。進行中のＲＥＳＯＬＶＥに対しノードが使用できるかどうかを示すために使用されるフラグもある。経路フラグは、アドレスに宛てて送信されたＲＥＳＯＬＶＥが受理されたか、拒絶されたかを示す場合に使用される。さらに、そのアドレスがそばの近隣ノードのものであった場合、ノードはそのすべてのそばの近隣ノードを知っていなければならないので、疑わしいフラグがセットされる。ＡｄｄｒｅｓｓＲｅｍｏｖｅｄインジケータはデバッグ時に使用され、エントリに除去のマークを付けるだけであり、実際には除去しない。これらのインジケータは次のとおりである。
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＡＣＣＥＰＴＥＤ−０ｘ０１
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＲＥＪＥＣＴＥＤ−０ｘ０２
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＵＮＲＥＡＣＨＡＢＬＥ−０ｘ０４
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＬＯＯＰ−０ｘ０８
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ−ＴＯＯ＿ＢＵＳＹ−０ｘ１０
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＢＡＤ＿ＶＡＬＩＤＡＴＥ＿ＩＤ−０ｘ２０
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＲＥＭＯＶＥＤ−０ｘ８０
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＳＵＳＰＥＣＴ＿ＵＮＲＥＧＩＳＴＥＲＥＤ＿ＩＤ−０ｘ４０。本発明の教示により構築されたＩＰＶ６＿ＥＮＤＰＯＩＮＴ要素のデータ構造の詳細を表１８に提示した。
【０１３１】
【表１８】
0004786882.tif 000019
【０１３２】
ＰＮＲＰ＿ＩＤ−型０ｘ００３０要素は、１２８ビットｐ２ｐ  ＩＤと１２８ビットサービスロケーションとを連結したものである。本発明の教示により構築されたＰＮＲＰ＿ＩＤ要素のデータ構造の詳細を表１９に提示した。
【０１３３】
【表１９】
0004786882.tif 000020
【０１３４】
ＴＡＲＧＥＴ＿ＰＮＲＰ＿ＩＤ−型０ｘ００３８は、ＲＥＳＯＬＶＥ要求またはその対応するＲＥＳＰＯＮＳＥのターゲットＩＤである。本発明の教示により構築されたＴＡＲＧＥＴ＿ＰＮＲＰ＿ＩＤ要素のデータ構造の詳細を表２０に提示した。
【０１３５】
【表２０】
0004786882.tif 000021
【０１３６】
ＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤ−型０ｘ００３９は、妥当性確認およびオーソリティが要求されるＰＮＲＰ  ＩＤである。本発明の教示により構築されたＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤ要素のデータ構造の詳細を表２１に提示した。
【０１３７】
【表２１】
0004786882.tif 000022
【０１３８】
ＦＬＡＧＳ＿ＦＩＥＬＤ−型０ｘ００４０を使用すると、コンテキスト固有の目的のために使用されるビットフィールドであるフラグを識別できる。本発明の教示により構築されたＦＬＡＧＳ＿ＦＩＥＬＤ要素のデータ構造の詳細を表２２に提示した。
【０１３９】
【表２２】
0004786882.tif 000023
【０１４０】
ＲＥＳＯＬＶＥ＿ＣＯＮＴＲＯＬＳ−型０ｘ００４１フィールドには、ＲＥＳＯＬＶＥまたはＲＥＳＰＯＮＳＥを処理する際に使用する情報が含まれる。ＲＥＳＯＬＶＥがバックトラッキングしているか、またはＡＵＴＨＯＲＩＴＹメッセージが要求されているかを示す場合にフラグを使用する。含まれるフラグは
ＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴ＿ＨＯＰ−０ｘ０００１、
ＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮ−０ｘ０００４、
デバッグ専用のＲＦ＿ＤＯＮＴ＿ＲＥＭＯＶＥ＿ＰＡＴＨ＿ＥＮＴＲＩＥＳ−０ｘ０００８、およびデバッグ専用のＲＦ＿ＴＲＡＣＩＮＧ＿ＯＮ−０ｘ００１０である。Ｍａｘ  Ｈｏｐｓにより、ＲＥＳＯＬＶＥ完了前のホップの個数を制限する。オペレーションコードは、照合の実行方法を記述する。一致（Ｍａｔｃｈｅｓ）は、任意のコードに対して最上位１２８ビット（Ｐ２Ｐ  ＩＤ）のみであることができるか、またはＮＥＡＲＥＳＴコードについてもサービスロケーションを考慮することができる。またオペレーションコードを使用することで、照合においてＲＥＳＯＬＶＥの発信元と同じノード上で登録されているＩＤを考慮すべきか決定する。オペレーションコードには以下のものを含む。
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＮＯＮＥ−０、
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＡＮＹ＿ＰＥＥＲＮＡＭＥ−１、
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＮＥＡＲＥＳＴ＿ＰＥＥＲＮＡＭＥ−２、
ＳＥＡＲＣＨ−ＯＰＣＯＤＥ＿ＮＥＡＲＥＳＴ６４＿ＰＥＥＲＮＡＭＥ−４、
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＵＰＰＥＲ＿ＢＩＴＳ−８。Ｐｒｅｃｉｓｉｏｎにより、実際のビット数と一致する精度がＩＤ上で設定される。この値は、オペレーションコードが
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＵＰＰＥＲ＿ＢＩＴＳの場合に使用される。
【０１４１】
理由（Ｒｅａｓｏｎ）を使用して、ＲＥＳＯＬＶＥが送信されたのは修復プロセスの一部としてなのか、キャッシュの保守のためなのか、登録の一部としてなのか、またはアプリケーション要求のためなのかを示す。理由には、ＲＥＡＳＯＮ＿ＡＰＰ＿ＲＥＱＵＥＳＴ−０、ＲＥＡＳＯＮ＿ＲＥＧＩＳＴＲＡＴＩＯＮ−１、ＲＥＡＳＯＮ＿ＣＡＣＨＥ＿ＭＡＩＮＴＥＮＡＮＣＥ−２、ＲＥＡＳＯＮ＿ＲＥＰＡＩＲ＿ＤＥＴＥＣＴＩＯＮ−３、ＲＥＡＳＯＮ＿ＳＹＮＣ＿ＲＥＱＵＥＳＴ−４、ＲＥＡＳＯＮ＿ＣＰＡ＿ＶＩＡ＿ＲＥＳＯＬＶＥ−５、ＲＥＡＳＯＮ＿ＣＰＡ＿ＶＩＡ＿ＦＬＯＯＤ−６、ＲＥＡＳＯＮ＿ＲＥＰＡＩＲ−７、およびＲＥＡＳＯＮ＿ＣＰＡ＿ＶＩＡ＿ＢＡＣＫ＿ＦＬＯＯＤ−８がある。
【０１４２】
結果コードは、なぜＲＥＳＯＬＶＥが完了し、ＲＥＳＰＯＮＳＥに変換されたかを示す。これは、ホップカウントを超えて成功したかまたは失敗したか、適切な経路が見つからなかったか、または近隣ノードが多すぎてターゲットを見つけるのに失敗したかを示すこともできる。これらの結果コードには、ＲＥＳＵＬＴ＿ＮＯＮＥ−０、ＲＥＳＵＬＴ＿ＦＯＵＮＤ＿ＭＡＴＣＨ−１、ＲＥＳＵＬＴ＿ＭＡＸ＿ＨＯＰ＿ＬＩＭＩＴ＿ＨＩＴ−２、ＲＥＳＵＬＴ＿ＮＯ＿ＢＥＴＴＥＲ＿ＰＡＴＨ＿ＦＯＵＮＤ−３、およびＲＥＳＵＬＴ＿ＴＯＯ＿ＭＡＮＹ＿ＭＩＳＳＥＳ−４がある。要求の発信元はトランザクションＩＤを使用して、ＲＥＳＰＯＮＳＥの相関を求める。ＲＥＳＯＬＶＥ発信元は、Ｔｒａｎｓ  ＩＤ値を設定し、ＲＥＳＰＯＮＳＥを開始するノードは、ＲＥＳＰＯＮＳＥメッセージで値をそのまま返す。中間ノードで、この値を変えてはならない。本発明の教示により構築されたＲＥＳＯＬＶＥ＿ＣＯＮＴＲＯＬＳ要素のデータ構造の詳細を表２３に提示した。
【０１４３】
【表２３】
0004786882.tif 000024
【０１４４】
ＣＡＣＨＥ＿ＬＥＶＥＬ−型０ｘ００４２要素は、ＲＥＰＡＩＲを実行するときに使用するキャッシュレベルを記述する。これは、分割キャッシュの修復を実行する際に使用される。本発明の教示により構築されたＣＡＣＨＥ＿ＬＥＶＥＬ要素のデータ構造の詳細を表２４に提示した。
【０１４５】
【表２４】
0004786882.tif 000025
【０１４６】
ＦＬＯＯＤ＿ＣＯＮＴＲＯＬＳ−型０ｘ００４３要素には、ＦＬＯＯＤを処理する際に使用する情報が含まれる。ＦＬＯＯＤが送信された理由が唯一使用されるコードである。本発明の教示により構築されたＦＬＯＯＤ＿ＣＯＮＴＲＯＬＳ要素のデータ構造の詳細を表２５に提示した。
【０１４７】
【表２５】
0004786882.tif 000026
【０１４８】
ＣＰＡ＿ＳＯＵＲＣＥ−型０ｘ００５８は、ＳＯＬＩＣＩＴメッセージ内の送信元ＣＰＡとして使用されるＣＰＡである。ＣＰＡは、ネットワーク送信用に符号化される。本発明の教示により構築されたＣＰＡ＿ＳＯＵＲＣＥ要素のデータ構造の詳細を表２６に提示した。
【０１４９】
【表２６】
0004786882.tif 000027
【０１５０】
ＣＰＡ＿ＢＥＳＴ＿ＭＡＴＣＨ−型０ｘ００５９要素は、ＲＥＳＯＬＶＥまたはＲＥＳＰＯＮＳＥにおける「最良一致」として使用されるＣＰＡである。ＣＰＡは、ネットワーク送信用に符号化される。本発明の教示により構築されたＣＰＡ＿ＢＥＳＴ＿ＭＡＴＣＨ要素のデータ構造の詳細を表２７に提示した。
【０１５１】
【表２７】
0004786882.tif 000028
【０１５２】
ＰＮＲＰ＿ＩＤ＿ＡＲＲＡＹ−型０ｘ００６０要素は、配列内に格納されているＡＤＶＥＲＴＩＳＥおよびＲＥＱＵＥＳＴメッセージのＰＮＲＰ  ＩＤを含む。配列サイズを含む、このデータについては後述する。本発明の教示により構築されたＰＮＲＰ＿ＩＤ＿ＡＲＲＡＹ要素のデータ構造の詳細を表２８に提示した。
【０１５３】
【表２８】
0004786882.tif 000029
【０１５４】
ＩＰＶ６＿ＥＮＤＰＯＩＮＴ＿ＡＲＲＡＹ−型０ｘ００７１は、すでに訪れたすべてのノードの配列である。フラッディングされたメッセージはさまざまなノードを訪れる。すでに訪れたノードまたは送信先となったノードはそれぞれ、この配列に入れられる。配列サイズを含むデータについては後述する。本発明の教示により構築されたＩＰＶ６＿ＥＮＤＰＯＩＮＴ＿ＡＲＲＡＹ要素のデータ構造の詳細を表２９に提示した。
【０１５５】
【表２９】
0004786882.tif 000030
【０１５６】
ＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＡＤＤＲＥＳＳ−型０ｘ００７２要素は、ＲＥＳＯＬＶＥを送信するための代替アドレスを指定するために特に使用されるＩＰｖ６エンドポイントである。このフィールドは、ノード側ではＲＥＳＯＬＶＥを転送したくないが、他の何らかのノードが試みることができるアドレスを指定したい場合に、ＡＵＴＨＯＲＩＴＹメッセージ内で使用される。本発明の教示により構築されたＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＡＤＤＲＥＳＳ要素のデータ構造の詳細を表３０に提示した。
【０１５７】
【表３０】
0004786882.tif 000031
【０１５８】
ＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＩＤ−型０ｘ００７３要素は、参照に使用されているＰＮＲＰ  ＩＤを示すためにＩＰｖ６＿Ｒｅｆｅｒｒａｌ＿Ａｄｄｒｅｓｓとともに使用される。本発明の教示により構築されたＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＩＤ要素のデータ構造の詳細を表３１に提示した。
【０１５９】
【表３１】
0004786882.tif 000032
【０１６０】
ＣｅｒｔＣｈａｉｎ（ＣＥＲＴ＿ＣＨＡＩＮ）−型０ｘ００８０要素は、Ｗｉｎｄｏｗｓ（登録商標）ＣＡＰＩ  ＡＰＩを使用して作成される。最初に、この連鎖を構成する認証をＣＡＰＩメモリ内認証ストア（ＣＡＰＩ  ｉｎ−ｍｅｍｏｒｙ  ｃｅｒｔ  ｓｔｏｒｅ）に入れ、その後、ＰＫＣＳ７符号化認証ストア（ＰＫＣＳ７  ｅｎｃｏｄｅｄ  ｃｅｒｔ  ｓｔｏｒｅ）としてエクスポートする。このエクスポートされたストアは、修正されることなく送信される。
【０１６１】
ＷＣＨＡＲ−型０ｘ００８４要素は、単一のＵＮＩＣＯＤＥ文字を保持するため定義される。クラシファイアなど、ＵＮＩＣＯＤＥ配列フィールドの一部としてのみ使用される。
【０１６２】
ＣＬＡＳＳＩＦＩＥＲ−型０ｘ００８５要素は、ピア名の基盤として使用されたＵＮＩＣＯＤＥクラシファイア文字列である。これは、ＷＣＨＡＲ要素の配列として符号化される。本発明の教示により構築されたＣＬＡＳＳＩＦＩＥＲ要素のデータ構造の詳細を表３２に提示した。
【０１６３】
【表３２】
0004786882.tif 000033
【０１６４】
ＨＡＳＨＥＤ＿ＮＯＮＣＥ−型０ｘ００９２要素は、ＡＤＶＥＲＴＩＳＥメッセージに含まれる暗号化されたＮｏｎｃｅ値である。受信側は、Ｎｏｎｃｅを解読する鍵を持っていることが考えられる。本発明の教示により構築されたＨＡＳＨＥＤ＿ＮＯＮＣＥ要素のデータ構造の詳細を表３３に提示した。
【０１６５】
【表３３】
0004786882.tif 000034
【０１６６】
ＮＯＮＣＥ−型０ｘ００９３要素は、ＲＥＱＵＥＳＴメッセージに含まれる解読されたＮｏｎｃｅ値である。受信側は、解読されたＮｏｎｃｅが暗号化の前に送信された値と一致することを確認することが期待される。本発明の教示により構築されたＮＯＮＣＥ要素のデータ構造の詳細を表３４に提示した。
【０１６７】
【表３４】
0004786882.tif 000035
【０１６８】
ＳＰＬＩＴ＿ＣＯＮＴＲＯＬＳ−型０ｘ００９８要素は、長いメッセージが、単一メッセージではなく、一連のフラグメントとして送信されるときに使用される。各フラグメントには分割コントロールフィールドが含まれており、これにより受信側はメッセージを構築することができる。本発明の教示により構築されたＳＰＬＩＴ＿ＣＯＮＴＲＯＬＳ要素のデータ構造の詳細を表３５に提示した。
【０１６９】
【表３５】
0004786882.tif 000036
【０１７０】
ＰＮＲＰ＿ＴＲＡＣＥ−型０ｘ００９９要素は、ＲＥＳＯＬＶＥメッセージとＲＥＳＰＯＮＳＥメッセージとの間でホップからホップへ伝達できるデータを保持するためデバッグ時に使用される。トレースするデータを格納するために使用される。最終バージョンのプロトコルではサポートされない場合がある。
【０１７１】
本発明のさまざまな実施形態の前記説明は、図の説明と解説を目的として提示した。この説明は網羅的であることを意図しておらず、また本発明を開示した実施形態だけに限る意図もない。上記の教示に照らして、数多くの修正またはバリエーションが可能である。説明した実施形態は、本発明の原理とその実際の応用を最もよく理解できるように選択され、説明されており、したがって、当業者であれば、さまざまな実施形態において、考察されている特定の用途に適したさまざまな修正を加えることにより本発明を利用できるであろう。このようなすべての修正およびバリエーションは、公正で、合法的で、公平な権利を有する範囲において解釈したときに特許請求の範囲により規定されている本発明の範囲に収まる。
【図面の簡単な説明】
【０１７２】
【図１】本発明が属するコンピュータシステム例の概要を例示するブロック図である。
【図２】ピアツーピア名前解決プロトコル（ＰＮＲＰ）の機能要素を例示する簡略化したブロック図である。
【図３】本発明の一態様を例示するプロトコルメッセージの流れ図である。
【図４】本発明の別の態様を例示するプロトコルメッセージの流れ図である。
【図５】本発明のメッセージを構築することができる本発明の拡張可能なデータ構造モデルを例示するデータ構造図である。
【図６】本発明のメッセージ例の構築を例示する簡略化したデータ構造図である。
【符号の説明】
【０１７３】
１００  コンピューティングシステム環境
１１０  コンピュータ
１２０  処理ユニット
１２１  システムバス
１３０  システムメモリ
１３１  ＲＯＭ
１３２  ＲＡＭ
１３３  基本入出力システム
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  プログラムモジュール
１３７  プログラムデータ
１４１  ハードディスクドライブ
１４４  オペレーティングシステム
１４５  アプリケーションプログラム
１４６  プログラムモジュール
１４７  プログラムデータ
１５１  磁気ディスクドライブ
１５２  取り外し可能な不揮発性磁気ディスク
１５５  光ディスクドライブ
１５６  取り外し可能な不揮発性光ディスク
１６０  ユーザ入力インターフェース
１６１  ポインティングデバイス
１６２  キーボード
１７０  アダプタ
１７１  ローカルエリアネットワーク（ＬＡＮ）
１７３  ワイドエリアネットワーク（ＷＡＮ）
１８０  リモートコンピュータ
１８１  メモリ記憶デバイス
１８５  リモートアプリケーションプログラム
１９０  ビデオインターフェース
１９１  モニタ
１９５  出力周辺インターフェース
１９６  プリンタ
１９７  スピーカ
２００  サービス管理コンポーネント
２０２  ＲＰＣサーバおよびスタブ
２０６  キャッシュマネージャ
２０８  プロトコルマネージャ
２１２  ノードＡ
２１４  ノードＢ
２１６  ＳＯＬＩＣＩＴメッセージ
２１８  ＡＤＶＥＲＴＩＳＥメッセージ
２２０  ＲＥＱＵＥＳＴメッセージ
２２２  ＡＣＫ
２２４  ＦＬＯＯＤメッセージ
２２６  ＡＣＫ
２２８  ノードＡ
２３０  ノードＢ
２３２  ノードＴ
２３４  ＲＥＳＯＬＶＥメッセージ
２３６  ＲＥＳＯＬＶＥメッセージ
２３８  ＡＵＴＨＯＲＩＴＹ
２４２  ＡＵＴＨＯＲＩＴＹメッセージ
２４４  ＲＥＰＯＮＳＥメッセージ
２４６  ＡＣＫ
２６０  基本メッセージデータ構造
２６２  フィールド
２６４  フィールドデータ構造
２６６  型コンポーネント
２６８  長さコンポーネント
２７０  実際の内容またはペイロード
２７２  長さ
２８０  ＲＥＳＯＬＶＥメッセージ
２９４  ＰＮＲＰ＿ＨＥＡＤＥＲデータ構造
２９６  フィールドＩＤ
２９８  長さ
３００  プロトコルコンポーネント
３０２  メジャーバージョンコンポーネント
３０４  マイナーバージョンコンポーネント
３０６  メッセージタイプコンポーネント
３０８  メッセージＩＤコンポーネント
３１０  フィールドデータ構造
３１２  フィールドＩＤ
３１４  長さコンポーネント
３１６  Ｐ２Ｐ  ＩＤコンポーネント
３１８  サービスロケーションコンポーネント
【図１】
0004786882.tif 000037
【図２】
0004786882.tif 000038
【図３】
0004786882.tif 000039
【図４】
0004786882.tif 000040
【図５】
0004786882.tif 000041
【図６】
0004786882.tif 000042