JP2005004777A

JP2005004777A - ピアツーピア名前解決ワイヤプロトコルで使用するデータ構造を格納したコンピュータ可読媒体

Info

Publication number: JP2005004777A
Application number: JP2004176212A
Authority: JP
Inventors: John L Miller; エル．ミラージョン; Henry Rawas; ラワスヘンリー; Radu Simionescu; シミオネスキュラドゥ; Brian Lieuallen; リューアレンブライアン
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-06-13
Filing date: 2004-06-14
Publication date: 2005-01-06
Anticipated expiration: 2024-06-14
Also published as: JP4786882B2; CN1574840A; HK1071252A1; EP1487180B1; EP1487180A2; MY140075A; TWI379548B; KR20040107420A; US7533184B2; TWI339518B; TW200843412A; KR101021360B1; AU2004202255B8; CA2465997C; TW200503475A; CN1574840B; ZA200403431B; RU2385488C2; RU2004117797A; MXPA04005718A

Abstract

【課題】ピアツーピア名前解決プロトコルにおけるメッセージの拡張可能データ構造を提示する。
【解決手段】このメッセージデータ構造では、多数のフィールドを使用し、それぞれメッセージ要素を含む。第１のフィールドは、プロトコル情報を含み、メッセージのタイプを識別するメッセージヘッダであるのが好ましい。各メッセージ要素は、多数のフィールドを含む。これらのメッセージ要素フィールドは、タイプフィールド、長さフィールド、およびメッセージ要素の内容またはペイロードを含む。一実施形態では、ピアツーピア名前解決プロトコル（ＰＮＲＰ）を正常に動作させるため、ＲＥＳＯＬＶＥ、ＲＥＳＰＯＮＳＥ、ＳＯＬＩＣＩＴ、ＡＤＶＥＲＴＩＳＥ、ＲＥＱＵＥＳＴ、ＦＬＯＯＤ、ＩＮＱＵＩＲＥ、ＡＵＴＨＯＲＩＴＹ、ＡＣＫ、およびＲＥＰＡＩＲメッセージなど少なくとも１０個のメッセージが形成される。
【選択図】図６

Description

本発明は、一般に、ピアツーピア基盤（ｐｅｅｒ−ｔｏ−ｐｅｅｒｉｎｆｒａｓｔｒｕｃｔｕｒｅ）における通信プロトコルに関するものであり、より具体的には、ピアツーピアグラフ（ｐｅｅｒ−ｔｏ−ｐｅｅｒｇｒａｐｈ）において構造化された通信（ｓｔｒｕｃｔｕｒｅｄｃｏｍｍｕｎｉｃａｔｉｏｎ）を可能にするメッセージ形式データ構造（ｍｅｓｓａｇｅｆｏｒｍａｔｄａｔａｓｔｒｕｃｔｕｒｅｓ）に関するものである。

インターネット上のさまざまな通信技術を使用することで、共通の関心を持つユーザ同士が、共同で作業をしたり、ファイルを共有したり、互いにチャットしたり、オーディオおよびビデオのマルチキャストをプレゼンテーションおよびグループ会合に利用したり、多人数参加型ゲームに参加したりすることが可能になる。しかし、現在は、インターネット上のほとんどの通信は、サーバ中心の環境で行われており、したがって、すべての通信は、個人がそのような通信への加入および参加のため接続できる大規模な中央サーバへ流れるか、またはそのようなサーバを通して流れる。

ピアツーピア技術が再び登場したことで、現在のインターネット通信のサーバ中心モデルはたちまち取って代わられようとしている。実際、ピアツーピア技術を利用すれば、ユーザは、サーバベースのインターネット通信の制約を受けることなく、サーバレス環境で互いにコンタクトを取りあうことができる。ピアツーピアベースのシステムでは、ネットワーク内のピア同士の間で直接通信が行われるため、ユーザの匿名性とプライバシーを保持することができる。しかし、ピアツーピアネットワーク内では、個々の通信およびファイル共有は比較的適切に機能するが、ピアツーピア環境での情報の確立、発見、結合、維持、および共有はうまく機能しない。

ピアツーピア通信、および実際には、あらゆる種類の通信が、選択されたエンティティまたはノード同士の間で有効な接続を確立できるかどうかに依存しているのである。これらのエンティティまたはノードは、ピアツーピアネットワーク内に形成されているピア同士（例えば、ユーザまたはマシン）またはグループである。ノード間の接続はピアツーピアグラフを形成し、これにより通信および情報をノードに渡したり、ノード同士の間でやり取りすることができる。しかし、例えば、エンティティがネットワーク内を移動する、トポロジが変更される、アドレスリースを更新できない、グループ機能または目的が変更されたなどの理由により、変更可能な１つまたは複数のアドレスがエンティティに設定される場合がある。したがって、このようなアドレス指定問題に対する古典的なアーキテクチャ面での解決策では、それぞれのエンティティに安定した名前を付け、接続が必要になったときにこの名前を現在のアドレスに「解決」する。翻訳を処理するためのこのような名前は非常に強固なものでなければならず、また更新を簡単にかつ迅速に行えるようなものでなければならない。

こうした接続しようとする試みにより、エンティティのアドレスが見つかる可能性を高めるために、エンティティは、多くのピアツーピアプロトコルを使用して、さまざまなメカニズムを通じて個別またはグループのアドレスを公開することができる。またいくつかのプロトコルでは、クライアントはネットワーク内の他のクライアントからの要求の処理を通じて他のエンティティのアドレスに関する情報を取得することができる。実際、このようなアドレス情報の取得は、堅牢なグラフを保持することによりこれらのピアツーピアネットワークが正常に動作することを可能にする。つまり、ネットワーク内の他のピアおよびグループに関する情報が適切であればあるほど（つまり、グラフが堅牢であるほど）、特定の資源または記録の探索が収束する可能性が高まる。

サーバ中心環境の場合のように、ピアツーピアグラフを完全オープンにすることで、インターネットによるグラフ内のファイル探索および共有を可能にできる。しかし、ピアツーピアネットワークは分散ユーザまたはピアのグラフとして形成されるため、ネットワーク内のすべてのピアが共有されている情報を認識するようになる前に、一方のピアから別方のピアへ通信およびデータ（記録）を受け渡す必要がある。このような経路選択方式をとるシステムとして、ＵｓｅｎｅｔとＯＳＰＦがある。しかし、内在する制限を持つこのような現在のシステムは、これまでピアツーピア技術の全面的な発展を妨げている制約を抱えている。さらに、現在、ピアツーピアネットワークは適切なグラフ管理機能を欠いており、メンバの１つがグループを抜けたときにグラフがたまに「分断」または分割される可能性がある。このような場合、グラフの一方の側からの情報は、ピアの一方の離脱により分割が生じたときにその分割の他方の側にあるピアメンバにもはや渡すことはできなくなる。他の欠点として、このような分割を検出するための適切なメカニズムが存在しないという点が挙げられる。

技術に存在する機能に関する問題に加えて、ネットワークトラフィックの量もまた、クラウド（ｃｌｏｕｄ）に参加しているピアを容易に圧倒してしまうほどである。メッセージのサイズおよび構造により、ピアがメッセージを迅速に処理する機能を込み入ったものとし、したがって、クラウドの規模が大きくなるにつれ通信の遅延や通信内容の脱落が生じる。

したがって、技術の中に存在する上記の問題および他の問題に対処するピアツーピアのメッセージングプロトコルおよびデータ構造が本技術では必要である。

本出願で開示されている本発明の概念は、ピアツーピアの名前解決プロトコルで使用するのに適しているメッセージの拡張可能なデータ構造を伴う。このメッセージデータ構造では、メッセージデータフィールドを使用して、ＰＮＲＰに役立つさまざまなメッセージを構築する。メッセージデータフィールドはそれぞれ、メッセージ要素を含む。第１のフィールドは、プロトコル情報を含み、メッセージのタイプを識別するメッセージヘッダ要素であるのが好ましい。

メッセージ自体の場合と同様、それぞれのメッセージ要素には多数のメッセージ要素のデータフィールドが含まれる。これらのメッセージ要素フィールドは、タイプフィールド、長さフィールド、およびメッセージ要素の内容またはペイロードを含む。タイプフィールドは、メッセージ要素のタイプを指定する識別子を含む。長さフィールドは、フィールドタイプおよび長さフィールドを含む、メッセージ要素の長さを識別する。

一実施形態では、ＰｅｅｒＴｏＰｅｅｒＮａｍｅＲｅｓｏｌｕｔｉｏｎＰｒｏｔｏｃｏｌ（ＰＮＲＰ）を正常に動作させるため、少なくとも１０個のメッセージが形成される。これらの１０個のメッセージは、ＲＥＳＯＬＶＥメッセージ、ＲＥＳＰＯＮＳＥメッセージ、ＳＯＬＩＣＩＴメッセージ、ＡＤＶＥＲＴＩＳＥメッセージ、ＲＥＱＵＥＳＴメッセージ、ＦＬＯＯＤメッセージ、ＩＮＱＵＩＲＥメッセージ、ＡＵＴＨＯＲＩＴＹメッセージ、ＡＣＫメッセージ、ＲＥＰＡＩＲメッセージを含む。これらのメッセージは、好ましい実施形態に存在する２２個の異なるメッセージ要素から構築される。

本明細書に組み込まれ、その一部となっている付属の図面は、本発明のいくつかの態様を示しており、説明とあわせて、本発明の原理の説明に使用される。

本発明は、いくつかの好ましい実施形態に関して説明するが、それらの実施形態に限る意図はない。それどころか、特許請求の範囲で定義されている本発明の精神と範囲内に収まるすべての代替、変形、および等価物を対象とすることを目的とする。

図面では類似の参照番号は類似の要素を指しており、本発明は適当なコンピューティング環境で実装されているものとして説明されている。必須ではないが、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的状況において本発明を説明する。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、当業者であれば、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステム構成でも実施できることを理解するであろう。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶デバイスに置くことができる。

図１は、本発明を実装するのに適しているコンピューティングシステム環境１００の一実施例の図である。コンピューティングシステム環境１００は、適当なコンピューティング環境の一例にすぎず、本発明の用途または機能性の範囲に関する制限を示唆する意図はない。オペレーティング環境例１００に示されているいずれか１つのコンポーネントまたはその組み合わせに関係する依存関係または要求条件がコンピューティング環境１００にあるものと解釈すべきでない。

本発明は、他の数多くの汎用または専用コンピューティングシステム環境または構成で動作する。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド型またはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスのいずれかを含む分散コンピューティング環境などがあるが、それらに限定されるものではない。

本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況において説明することができる。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶デバイスなどのローカルとリモートの両方のコンピュータ記憶媒体内に配置できる。

図１では、本発明を実装するシステム例は、コンピュータ１１０の形態をとる汎用コンピューティングデバイスを備える。コンピュータ１１０が備えるコンポーネントとしては、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを備えるさまざまなシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１などがあるが、それらに限定されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺機器バス、および各種バスアーキテクチャを使用するローカルバスを含む数種類のバス構造のどれでもよい。例えば、このようなアーキテクチャとしては、ＩｎｄｕｓｔｒｙＳｔａｎｄａｒｄＡｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、ＭｉｃｒｏＣｈａｎｎｅｌＡｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＥｎｈａｎｃｅｄＩＳＡ（ＥＩＳＡ）バス、ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓＳｔａｎｄａｒｄｓＡｓｓｏｃｉａｔｅ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがあるが、それらに限定されるものではない。

コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスできる媒体であればどのような媒体でもよく、揮発性および不揮発性媒体、取り外し可能および固定媒体を含む。例えば、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができるが、それらに限定されるものではない。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および固定媒体を含む。コンピュータ記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）もしくはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶デバイス、または目的の情報を格納するために使用することができコンピュータ１１０によりアクセスできるその他の媒体があるが、それらに限定されるものではない。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波またはその他のトランスポートメカニズムなどの被変調データ信号によるその他のデータを実現し、さらに情報配信媒体を含む。「被変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体があるが、それらに限定されるものではない。上記のいずれの組み合わせもコンピュータ可読媒体の範囲に含まれるべきである。

システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は通常、ＲＯＭ１３１内に格納される。通常、ＲＡＭ１３２には、処理ユニット１２０に直接アクセス可能な、かつ／または処理ユニット１２０により現在操作されているデータおよび／またはプログラムモジュールが含まれている。例えば、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０は、その他の取り外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図１は、固定の不揮発性磁気媒体の読み出しまたは書き込みを行うハードディスクドライブ１４１、取り外し可能な不揮発性磁気ディスク１５２の読み出しまたは書き込みを行う磁気ディスクドライブ１５１、およびＣＤＲＯＭまたはその他の光媒体などの取り外し可能な不揮発性光ディスク１５６の読み出しまたは書き込みを行う光ディスクドライブ１５５を示している。オペレーティング環境例で使用できる他の取り外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体としては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがあるが、それらに限定されるものではない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取り外し可能なメモリインターフェースによりシステムバス１２１に接続される。

図１に示されている上記のドライブおよび関連コンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じである場合もあれば異なる場合もあることに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７に対しては、ここで、異なる番号を割り当てて、最低でも、それが異なるコピーであることを示している。ユーザは、キーボード１６２、および通常マウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力できる。他の入力デバイス（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続することもできる。モニタ１９１またはその他の種類の表示デバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタのほかに、コンピュータはさらにスピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することも可能である。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードでもよく、通常は、パーソナルコンピュータ１１０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイス１８１だけを図１に示してある。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１とワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的なものである。

ＬＡＮネットワーキング環境で使用する場合は、パーソナルコンピュータ１１０はネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は通常、モデム１７２またはインターネットなどのＷＡＮ１７３上で通信を確立するための他の手段を備える。モデム１７２は、内蔵でも外付けでもよいが、ユーザ入力インターフェース１６０またはその他の適切なメカニズムを介してシステムバス１２１に接続できる。ネットワーク環境では、パーソナルコンピュータ１１０またはその一部に関して述べたプログラムモジュールは、リモートメモリ記憶デバイスに格納できる。例えば、図１には、リモートアプリケーションプログラム１８５がメモリデバイス１８１に置かれているように示されているが、それらに限定されるものではない。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するための他の手段を使用できることは理解されるであろう。

以下の説明では、特に断りのない限り、１つまたは複数のコンピュータにより実行される活動および動作の記号的表現を参照しながら本発明を説明する。したがって、そのような活動および動作は、ときにはコンピュータ実行（ｃｏｍｐｕｔｅｒ−ｅｘｅｃｕｔｅｄ）と呼ばれることもあるが、構造化された形式でデータを表現する電気的信号の、コンピュータの処理装置による操作を含むことは理解されるであろう。この操作により、データを変換するか、またはコンピュータのメモリシステム内の複数の場所に保持し、当業者であればよく理解している方法でコンピュータの動作を再構成するか、さもなければ他の何らかの形で変更する。データが保持されているデータ構造は、データの形式により定められた特定の特性を備えるメモリの物理的な場所である。しかし、本発明は前記の背景状況において説明されているが、制限する意図はなく、当業者にとっては以下で説明する各種の活動および動作がハードウェアで実装できることは周知のことであろう。

上で紹介したように、ピアツーピア（Ｐ２Ｐ）プロトコルが成功するかどうかは、そのプロトコルで選択されたエンティティ間に有効な接続を確立する機能にかかっている。同様に、このようなＰ２Ｐネットワーク内でのグループの形成は、この機能にかかっている。特定のユーザはアドレスの異なるさまざまな場所でさまざまな方法によりネットワークに接続できるため、一意的なアイデンティティをユーザまたはグループに割り当て、プロトコルを通じてそのアイデンティティを特定の１つまたは複数のアドレスに解決するアプローチが好ましい。本発明のアイデンティティ管理システムおよび方法が特に適用可能なこのようなＰｅｅｒ−Ｔｏ−ＰｅｅｒＮａｍｅＲｅｓｏｌｕｔｉｏｎＰｒｏｔｏｃｏｌ（ＰＮＲＰ）は、２００１年８月２９日に出願された「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」という表題の同時係属出願第０９／９５５，９２４号にこのようなグループに使用される基本的なセキュリティ基盤の説明がある。これらの出願の教示および開示も参照によりその全体が本明細書に組み込まれる。しかし、本発明のインターフェースおよび方法は特に、そのようなＰＮＲＰに適用することができ、そのようなＰＮＲＰと情報のやり取りを行うが、当業者であれば、本発明はそれらの制限を受けることはなく、Ｐ２Ｐグラフ管理機能を備えることを要求するＰ２Ｐシステムまたはプロトコルに適用することができることを認識するであろう。

ＰＮＲＰを説明する上記の同時係属出願で説明されているように、何らかの有用な背景を提供するために、ピア名前解決プロトコル（ＰＮＲＰ）はピアベースの名前−アドレス解決プロトコルである。ピアの資源にはピア名を付けることができる。アプリケーション側で、ピア名をＰＮＲＰに登録し他のピアに発見できるようにすることが可能である。他のアプリケーションは、ＰＮＲＰを使用して、ピア名を解決し、登録側アプリケーションの対応するＩＰアドレスおよびポートを取得することができる。ＰＮＲＰは、ピア名を探索または参照するためのメカニズムを備えていない。ピア名を配布するメカニズムを実装するには、他の手段を利用しなければならない。ピア名をアドレスに解決するには、参加ピアに協力してもらい、お互いが相手にメッセージを転送し、マッピングを処理するためのピア名の分散キャッシュを保持するようにする。登録および解決メカニズムは、初期化の場合を除き、サーバが存在するかどうかに依存しない。ＰＮＲＰインスタンスは、最初に現れたときに、データの交換相手である他の何らかのＰＮＲＰインスタンスのアドレスを見つける必要がある。他の手段が利用できない場合、よく知られているサーバを使用して、他のＰＮＲＰインスタンスのリストを取得する。

つまり、ＰＮＲＰを使用することで、ピアアプリケーションはピア名をエンドポイントマッピングに登録し、ピア名を解決してエンドポイントを取得することができる。このときに、何らかの定義があると適切である。ピア名は、ピア資源を識別する文字列である。ピア名を登録できるためには、アプリケーションは公開鍵／秘密鍵の組にアクセスできなければならない。この鍵の組を使用して、メッセージのいくつかに署名を入れ、改ざんを防止する。ピア名は、さらに、公開鍵から導出することができ、それにより、アイデンティティ所有権（ｉｄｅｎｔｉｔｙｏｗｎｅｒｓｈｉｐ）を検証できる。エンドポイントは、１つのＩＰｖ６／ＩＰｖ４アドレス、ポート、およびプロトコルである。実際、エンドポイントのリストに単一のピア名を登録することができ、ピア名が解決されたときにそのリストが返される。ノードは、ＰＮＲＰプロトコルサービスの一インスタンスである。通常は、コンピュータ１台ごとに１つのノードがある。クラウドは、互いに到達可能なノードのネットワークである。単一のノードを複数のクラウドに接続することができる。クラウドは、ＩＰｖ６−グローバル、サイトローカル、およびリンクローカルで定義されているスコープに相当するスコープ特性を持つ。ノードは、複数のサイトローカルクラウドおよび複数のリンクローカルクラウドを持つことができる。ノード間の通信は、決して、一方のクラウドから別のクラウドへ横断しない。クラウド名を使用して、クラウドを区別する。複数のノードに１つのピア名を登録できる。ＰＮＲＰは、各登録を明確に区別する。各ピア名インスタンスに関連付けられているエンドポイントリストは異なる。１つのノード内で、そのノードが接続されている複数のクラウド上でピア名を登録することも可能である。これらの登録はそれぞれ区別される。通常、エンドポイントリストも、これらのインスタンスのそれぞれにおいて異なる。ノードは、ピア名を解決しようとするときに、選択されたクラウド上でこれを実行する。解決が成功するのは、ピア名が同じクラウド内で登録されている場合のみに限る。複数のクラウド上で同時にピア名を解決することが可能であるが、これらは独立の解決要求として処理される。

ＰＮＲＰサービスは、図２に例示されているように、連携する複数のモジュールからなる。サービス管理コンポーネント２００は、ＰＮＲＰサービスの開始および停止などの単純な日常的作業を処理する。ＲＰＣサーバおよびスタブ２０２は、クライアントプロセスとＰＮＲＰサービスとの間のインターフェースを提供する。これにより、公開されているインターフェース、要求に対するエントリポイントの提供、ならびにイベントおよび要求完了の通知を管理する。また、クライアントプロセスの終了からの復旧も処理する。クラウドマネージャ２０４は、特定のクライアント要求の状態を保持し、利用可能なＰＮＲＰクラウドのリストを保持する。これは、クラウドを作成し、クラウド状態の変更をクライアントに通知する役割を持つ。

キャッシュマネージャ２０６は、ローカルＰＮＲＰキャッシュおよびクラウド毎にローカルで登録されているＰＮＲＰ名のリストを保持する。これは、分散ＰＮＲＰキャッシュの一部である。他のコンピュータから届く解決要求に対するルックアップおよび次のホップ選択（ｌｏｏｋｕｐａｎｄｎｅｘｔｈｏｐｓｅｌｅｃｔｉｏｎ）を行う。これは、キャッシュの構造がよく保たれるように定期的に解決要求を開始することにより自キャッシュ上で保守作業を実行する。また、クラウドの分割を検出し、修復を試みる。複数の登録されたピアＩＤを保有することができ、またそれぞれをサポートするためキャッシュを構造化する。プロトコルマネージャ２０８は、有効なＰＮＲＰメッセージの作成および送信、ならびに受信したＰＮＲＰメッセージの処理を受け持つ。ＰＮＲＰプロトコルを実装するためキャッシュマネージャ２０６と連携する。最後に、メッセージトランスポート２１０が、メッセージの実際の送信および受信を処理する。これは、複数のネットワークインターフェースおよびアドレスを処理し、ローカルアドレスの集まりの変更を検出する。複数のプロトコルが必要な場合（ＩＰｖ４およびＩＰｖ６）、このコンポーネントは両方のプロトコルを処理する。

各ＰＮＲＰノードは、クラウド内の他のいくつかのノードに対するエンドポイントマッピングへのピア名のキャッシュを保持する。ノード間で本発明により構築されたメッセージがやり取りされ、クラウド内のノードにピア名に関する情報が配布される。そのキャッシュを適切に保持することは、各ノードの役目である。上述の出願により説明されているように、ＰＮＲＰプロトコルにより数値名前空間が定義される。各ピア名を数値に変換し、それらの数値を比較して、名前空間内での近さを判定することができる。ピア名を解決する要求がノードに届くと、目的のノードに数値的に近いノードを見つけるためにその数値とキャッシュ内の数値との比較が行われる。このようにして、解決要求がノードからノードへ渡され、各ホップでそのターゲットに次第に近づく。

ピア名は、上記の出願で説明されているハッシュ関数を使用してＰ２ＰＩＤと呼ばれる１２８ビット数に変換される。同じピア名からは常に、同じＰ２ＰＩＤが得られる。ピア名登録の特定のインスタンスもまた、サービスロケーション（ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ）と呼ばれる１２８ビット数が設定される。これら２つを合わせて、ＰＮＲＰＩＤと呼ばれる２５６ビット数が作られる。ＰＮＲＰＩＤのサービスロケーション部分により、ピア名登録の特定のインスタンスがネットワーク内で一意的なものとなる。

アプリケーション側で、ピア名をＰＮＲＰに登録することができる。ＰＮＲＰＩＤは名前から作成され、他のノードに登録を知らせるメッセージが送信される。複数のノード上で同じピア名を登録できる。Ｐ２ＰＩＤは、各ノード上で同じであるが、ＰＮＲＰＩＤは各ノードに対して一意的でなければならない。アプリケーションは、ピア名をアドレスに解決することを要求できる。Ｐ２ＰＩＤをピア名から導出し、メッセージを他のノードに送信し、このＰ２ＰＩＤが登録されているノードを特定する。Ｐ２ＰＩＤがアドレスに解決されると、認証されたピアアドレス（ＣＰＡ）が返される。このＣＰＡは、ターゲットのＰＮＲＰＩＤ、現在のＩＰアドレス、公開鍵、および多数の他のフィールドのサービスロケーション部分を含む。ＣＰＡに署名を入れて改ざんを防止する。

所与のＰ２ＰＩＤを多数の異なるノードにより登録することができる。ＰＮＲＰでは、「ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ」サフィックスを使用して、それぞれの登録されているインスタンスが一意的なＰＮＲＰＩＤを持つようにしている。「ｓｅｒｖｉｃｅｌｏｃａｔｉｏｎ」は、一意的なネットワークサービスエンドポイントに対応する１２８ビットの数値である。この値は、ＩＰｖ６アドレス、ポート、プロトコル、および公開鍵の一部を組み合わせて作成される。サービスロケーションは、ＰＮＲＰクライアント側で、隠ぺいされている（ｏｐａｑｕｅ）と考えなければならない。サービスロケーションには２つの重要な特性がある。サービスロケーションにより、いつでも、ピア名の一意的なインスタンスが識別される。２つのサービスロケーションを比較した場合に、それぞれに対する共通のプレフィックスの長さはネットワーク近接度（ｎｅｔｗｏｒｋｐｒｏｘｉｍｉｔｙ）の妥当な尺度である。同じ４ビットで始まる２つのサービスロケーションは、通常、同じ３ビットで始まる２つのサービスロケーションからそれほど隔たっていない。これらの利点は、グローバルスコープのネイティブユニキャストＩＰｖ６アドレスにしかあてはまらない。

ＰＮＲＰＩＤの作成および登録は、ＰＮＲＰサービスの一部にすぎない。ＰＮＲＰサービスの実行は、４段階に分けることができる。第１は、ＰＮＲＰクラウド発見である。新しいノードは、加入したい加入先クラウド内に既存のノードを見つけなければならない。クラウドには、グローバルＰＮＲＰクラウド、サイトローカル（エンタープライズ）クラウド（ｓｉｔｅｌｏｃａｌ（ｅｎｔｅｒｐｒｉｓｅ）ｃｌｏｕｄ）、またはリンクローカルクラウドがある。第２段階は、ＰＮＲＰクラウドの加入である。新しいノードは、既存のノードを見つけた後、ＳＹＮＣＨＲＯＮＩＺＥプロシージャを実行して、既存のノードの最上位キャッシュレベルの一部を取得する。単一のキャッシュレベルの部分集合には、クラウドへの参加を開始する新しいノードに対する情報が十分にある。第３段階では、クラウドへの能動的参加を考える。初期化が完了した後、ノードはＰＮＲＰＩＤ登録および解決に参加することができる。この段階では、ピアはさらに、定期的キャッシュ保守も実行する。最終段階は、ピアがクラウドを抜けることに関係する。ノードは、ローカルで登録されているＰＮＲＰＩＤの登録を解除してから終了する。

本発明のＰＮＲＰプロトコルは、ＰＮＲＰのさまざまな機能を実現するため、１０種類の異なるメッセージを含む。メッセージには、高いレベルで、ＣＰＡへのターゲットＰＮＲＰＩＤの解決を要求するために使用されるＲＥＳＯＬＶＥメッセージが含まれる。ＲＥＳＰＯＮＳＥメッセージは、完了したＲＥＳＯＬＶＥ要求の結果として使用される。ＦＬＯＯＤメッセージには、受信側（レシーバ）のＰＮＲＰキャッシュ向けのＣＰＡが含まれる。ＳＯＬＩＣＩＴメッセージは、最上位レベルのキャッシュに対しＡＤＶＥＲＴＩＳＥを実行するようＰＮＲＰノードに依頼する場合に使用する。ＡＤＶＥＲＴＩＳＥメッセージは、ノードの最上位レベルのキャッシュ内のＣＰＡに対するＰＮＲＰＩＤのリストを含む。ＲＥＱＵＥＳＴメッセージは、ＡＤＶＥＲＴＩＳＥされたＣＰＡの部分集合をフラッディングする（ｆｌｏｏｄａｓｕｂｓｅｔｏｆＡＤＶＥＲＴＩＳＥ’ｄＣＰＡｓ）ようにノードに要求するために使用される。ＩＮＱＵＩＲＥメッセージは、特定のＰＮＲＰＩＤがそのノードに登録されているかどうかをノードに問い合わせる場合に使用される。ＡＵＴＨＯＲＩＴＹメッセージは、ＰＮＲＰＩＤのローカル登録を確認し、任意選択によりそのＩＤに対するＣＰＡの妥当性を確認するのを補助する認証連鎖（ｃｅｒｔｉｆｉｃａｔｅｃｈａｉｎ）を供給する場合に使用される。ＡＣＫメッセージは、いくつかのメッセージを受信したこと、および／または正常に処理したことについて肯定応答する場合に使用される。最後に、ＲＥＰＡＩＲメッセージは、分割されている可能性のあるクラウドのマージを試みる場合に使用される。

ノードは、本発明のメッセージが使用されるＰＮＲＰ内の６つの基本的なタイプのトランザクションを開始することができる。これらのトランザクションには、クラウド発見、同期、解決、フラッディング（ｆｌｏｏｄｉｎｇ）、アイデンティティ妥当性確認、および修復（ｒｅｐａｉｒｉｎｇ）がある。これらのトランザクションはメッセージおよび本発明のメッセージ構造に関係するので、上記の出願で詳細が説明されているこれらのトランザクションの基本を理解するために、これらの簡単な説明を行う。

クラウド発見トランザクションにより、ピアはピアクラウドを発見することができる。好ましい実施形態では、各ノードはいくつかのクラウドに加入できる。加入できるクラウドの集合がどのようなものかは、ノードが持つネットワーク接続性によって決まる。ノードコンピュータに複数のインターフェースアダプタがある場合、複数のリンクローカルクラウドに加入できる。ノードがＩＰｖ６をサポートするサイトの一部であれば、そのノードはサイトローカルクラウドにアクセスできる。ノードが複数のこのようなサイトに（たぶん、ＶＰＮを介して）接続されている場合、そのノードは複数のサイトローカルクラウドにアクセスできる。ノードがインターネットに接続されている場合、そのノードはグローバルクラウドにアクセスできる。

ノードは、アクセス先のクラウドへの加入または非加入を選択できる。アプリケーションが最初にクラウド上でピア名を登録すること、またはクラウド上でピア名を解決することを要求した場合、ノードはクラウドにまだ加入していなければ加入しなければならない。クラウドに加入するには、同じクラウド内の少なくとも１つの他のノードを特定（ｌｏｃａｔｅ）しようと試みなければならない。別のノードを見つけられない場合、それはクラウド内の最初のノードであると想定し、他のノードが後で加入するのを待つことになる。

ＰＮＲＰノードがクラウドに加入する毎に、クラウド発見を実行して、別のノードを見つけなければならない。ＰＮＲＰの実装によりそのキャッシュが健全ではなく、さらに多くのキャッシュエントリを取得する必要があると判定される場合に、後からクラウド発見を実行することもできる。最初のキャッシュ発見の試みがうまく行かない場合、後でさらに試みることもできる。クラウド発見は、以下の手順で実行される。まず、ピアが永続的キャッシュから発見を実行する。このような手順では、ピアはまず永続的キャッシュをチェックする。キャッシュが永続的でなかった場合、ピアは後述の供給されたノードアドレスにより発見を試みなければならない。キャッシュエントリが永続的であった場合、すべてのキャッシュエントリについて、ピアは、期限切れになっていないＣＰＡ、次いで存続期間の長いＣＰＡ、次いで期限が最新であるＣＰＡと優先順位を決めることにより、優先度を計算する。その後、ピアは、選択されたノードとの同期処理を、選択されたノードの１つがいくつかのキャッシュエントリを与えるまで、順番に試みる。

上記のように、永続的キャッシュがない場合、ピアは供給されたノードアドレスにより発見を実行しようとする。この手順で、ピアは、管理構成で接続先のピアの集まりを指定しているかどうかをチェックする。指定していない場合、ピアは後述のマルチキャスト発見を試みる。指定している場合、ピアは、指定されたエンドポイント毎に、同期処理を、その選択されたノードの１つがいくつかのキャッシュエントリを与えるまで、順番に試みる。

マルチキャスト発見では、ＳｉｍｐｌｅＳｅｒｖｉｃｅＤｉｓｃｏｖｅｒｙＰｒｏｔｏｃｏｌ（ＳＳＤＰ）が利用可能であれば、ピアは、所望のクラウド内のＰＮＲＰサービスインスタンスについてＳＳＤＰＭＳＥＡＲＣＨを発行する。ＳＳＤＰ検索メッセージで使用する検索ターゲット文字列は、「ｕｒｎ：ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）ＰｅｅｒＮａｍｅＲｅｓｏｌｕｔｉｏｎＰｒｏｔｏｃｏｌ：＜ｍａｊｏｒ＞：＜Ｐｒｏｔｏｃｏｌ＞：＜Ｓｃｏｐｅ＞」である。ただし、＜ｍａｊｏｒ＞はバージョンを表す番号、＜Ｐｒｏｔｏｃｏｌ＞は「ＩＰＶ６」、＜Ｓｃｏｐｅ＞は「Ｇｌｏｂａｌ」、「ＳｉｔｅＬｏｃａｌ」、または「ＬｉｎｋＬｏｃａｌ」のうちの１つである。検索は、時間内に応答が得られるようにあらかじめ発行することができる。ＳＳＤＰが利用できない場合、ピアは、上記の他の発見プロトコルを試みることができる。利用できるものがない場合、ピアは、後述のディレクトリネームサーバ（ＤＮＳ）発見を試みなければならない。しかし、応答が受信された場合、応答は試みる対象のノードのリストに入れられる。応答が短時間のうちに利用できない場合、ノードは他の発見プロトコルを試みてもよい。この期間は、実装で決定することができる。その後、ピアは、選択されたノードとの同期処理を、選択されたノードの１つがいくつかのキャッシュエントリを与えるまで、順番に試みる。

ＤＮＳ発見では、ピアは、シードサーバ（ｓｅｅｄｓｅｒｖｅｒ）のよく知られている名前についてＤＮＳクエリを発行する。グローバルクラウドに対するこの名前は、例えば、ＳＥＥＤ．ＰＮＲＰ．ＮＥＴなどとなる。成功した場合、ピアは後述の同期処理を実行できる。しかし、このときまでにクラウド発見が成功しなかった場合、ＰＮＲＰは、クラウドの他のメンバを発見できないようにクラウド状態を設定し、それがクラウド内の第１のノードであると想定する。後で、再び同期処理を試みることができる。

同期をとることで、ノードは別のノードのキャッシュから一組のＣＰＡを取得することができる。同期処理は、クラウド発見後に実行される。これは、クラウド発見により返された一組のノードからランダムに選択された単一のノードにより実行される。ある種の攻撃を緩和するために同期処理が行われる。また、有効期限が過ぎたためクラウドのキャッシュが空になった場合にも同期処理が行われるが、ほんのたまにしか行われない。同期処理を開始する前に、ノードは、少なくとも１つのローカルで登録されているＣＰＡを備えていることを確認しなければならない。ピア名がすでに登録されていなければ、ノードはクラウド内に自分自身のノードＩＤを生成することができる。同期処理では、ＳＯＬＩＣＩＴ、ＡＤＶＥＲＴＩＳＥ、ＲＥＱＵＥＳＴ、ＦＬＯＯＤ、およびＡＣＫなどの本発明の５種類のメッセージが伴う。

図３は、同期処理のための単純なメッセージ交換を例示している。この図３では、ノードＡ２１２はノードＢ２１４との同期処理を開始すると仮定する。このような状況で、ノード間のメッセージの流れは、図３に例示されているとおりに進む。特に、ＳＯＬＩＣＩＴメッセージ２１６は、クラウド発見時に選択されたノード２１４にＰＮＲＰＩＤのリストを要求する。このＳＯＬＩＣＩＴメッセージ２１６は、表１で説明されているように入力される。

ノードは、ハッシュされたＮｏｎｃｅを生成するために使用されるＮｏｎｃｅ値を追跡する。タイマーは、この状態だけでなく、リトライカウントにも関連付けられている。送信されたＳＯＬＩＣＩＴ２１６に応答してＡＤＶＥＲＴＩＳＥメッセージ２１８が受信されなかった場合、ＳＯＬＩＣＩＴ２１６が再送される。リトライカウントを超えた場合、その状態は解放され、トランザクションは終了する。

ＳＯＬＩＣＩＴ２１６を受信したノード２１４は、ＡＤＶＥＲＴＩＳＥメッセージ２１８で応答する。ＡＤＶＥＲＴＩＳＥ２１８はＰＮＲＰＩＤの配列を含む。ノード２１４は最初に、スロットリングという経験則を適用し、同期処理トランザクションに加わる意志があるかどうかを判別する。ビジー状態であれば、ＰＮＲＰＩＤが配列内にないＡＤＶＥＲＴＩＳＥメッセージ２１８で応答する。ビジー状態でなければ、キャッシュから適切に配分された一組のＰＮＲＰＩＤを選択する。これは、最上位レベルのキャッシュエントリを使用するか、またはランダム選択により実行することも可能である。キャッシュ内に十分なエントリがない場合、ノード２１４は自分のローカルで登録されているＩＤも含まなければならない。ＡＤＶＥＲＴＩＳＥメッセージ２１８は、ＳＯＬＩＣＩＴメッセージ２１６からのハッシュされたＮｏｎｃｅを含む。ＡＤＶＥＲＴＩＳＥ２１８は、ＳＯＬＩＣＩＴ２１６の肯定応答であると考えられる。

ＰＮＲＰＩＤの配列が空でなかった場合、ノード２１４はハッシュされたＮｏｎｃｅ値を持つＡＤＶＥＲＴＩＳＥ２１８が送信された状態も保つ。この状態は、ビットマップ内の１ビットとすることができる。タイマーはこの状態に関連付けられ、したがって一致するメッセージを１５秒以内に受信しないと、トランザクションは異常終了し、この状態は解放される。ノード２１４は、ＳＯＬＩＣＩＴメッセージ２１６からソースＣＰＡをキャッシュに追加することもできる。ＡＤＶＥＲＴＩＳＥメッセージ２１８は、表２に示されているように占有される。

ノード２１２は、ＡＤＶＥＲＴＩＳＥ２１８を受信すると、まず、対応するＳＯＬＩＣＩＴ２１６を送信したことを確認する。ノード２１２は、送信していなければ、メッセージを削除する。ＡＤＶＥＲＴＩＳＥ２１８は、ＳＯＬＩＣＩＴ２１６の肯定応答として処理される。ＡＤＶＥＲＴＩＳＥ２１８内のＰＮＲＰＩＤの配列が空の場合、トランザクションは完了である。空でなければ、ノード２１２はＡＤＶＥＲＴＩＳＥ２１８内のＰＮＲＰＩＤの配列を参照して、キャッシュに含めたいものを選択する。ノード２１２は、選択されたＰＮＲＰＩＤの配列を含む、ＲＥＱＵＥＳＴメッセージ２２０を送信する。ＲＥＱＵＥＳＴメッセージ２２０の中に、ノード２１２は、ＳＯＬＩＣＩＴメッセージ２１６のハッシュされたＮｏｎｃｅを作成するために使用されるオリジナルのＮｏｎｃｅ値を入れる。ＲＥＱＵＥＳＴメッセージ２２０は、表３に示されているように入力される。

ＲＥＱＵＥＳＴメッセージ２２０がノードＢ２１４に送られると、ＡＣＫ２２２で応答して、受信したことを示し、再送を避ける。適切なタイミングでＡＣＫ２２２が受信されない場合、ノードＡ２１２はＲＥＱＵＥＳＴを再送する。ＲＥＱＵＥＳＴに対するＡＣＫを受信することなくすべての再送が尽きてしまった場合、トランザクションは失敗し、終了する。

トランザクションが成功した場合、つまり、ノード２１２がノード２１４からＡＣＫ２２２を受信した場合、ノード２１４はＮｏｎｃｅが有効であることを確認する。そのために、受信したＮｏｎｃｅをハッシュし、それが先に保存した状態と一致するかチェックする。一致しない場合には、それ以上処理を行わない。有効であれば、キャッシュ内にまだ置いてある配列内のＰＮＲＰＩＤ毎に、ＦＬＯＯＤメッセージ２２４_１、２２４_２、．．．２２４_Ｎを送信する。ＦＬＯＯＤメッセージ２２４は、ＰＮＲＰＩＤに対するＣＰＡを含む。ＦＬＯＯＤメッセージ２２４は同期していないことに注意されたい。つまり、ＦＬＯＯＤ（ＩＤ＝１）２２４_１は、ＦＬＯＯＤ（ＩＤ＝２）２２４が送信される前に肯定応答される必要はない。ピア２１２がＦＬＯＯＤ２２４を受信した後、ＦＬＯＯＤメッセージ２２４の通常処理が行われる。これは、ＡＣＫ２２６の送信およびＣＰＡの妥当性の確認を含む。

探索側ノード２１２は、選択されたＩＤの個数が十分に大きくなければこの手順を繰り返すことを決定できる。この場合、異なる同期相手のノードを使用して、異なるＩＤリストを取得する必要がある。

ＲＥＳＯＬＶＥメッセージを送信することにより、ノード側で解決プロセスを開始する。ＰＮＲＰＩＤを登録する一部として、またはキャッシュ保守の一部として、またはクラウド分割を検出するため、アプリケーション側でピア名をアドレスに解決することを要求しているのでＲＥＳＯＬＶＥが開始される場合がある。ＲＥＳＯＬＶＥメッセージは、解決処理をチューニングし、解決を試みるため訪れるノードの数に制限を課し、ＩＤ照合の精度を導くいくつかのフラグおよびコードを含む。これは所望のターゲットＰＮＲＰＩＤを指定する。ホップ毎に、次のホップのＩＤだけでなく、これまでに見つかった最もよく一致するＣＰＡが挿入される。さらに、ホップからホップへのＲＥＳＯＬＶＥメッセージの経路を追跡するため、訪れた先のノードエンドポイントの配列を含む。ＲＥＳＯＬＶＥの発信元（オリジネータ）は自分自身をその経路内の第１のエントリとして追加する。解決トランザクションにより、ＰＮＲＰＩＤは認証ピアアドレスに解決される。ＣＰＡ所有者のみが、権限を得てそのＣＰＡの解決要求を履行できる。キャッシュされたＣＰＡは、ＲＥＳＯＬＶＥ要求の経路選択の際の参考としてしか使用できない。これらは、ＲＥＳＯＬＶＥまたはＲＥＳＰＯＮＳＥの「最良一致」フィールドの設定に使用できない。

ＲＥＳＯＬＶＥメッセージは、ターゲットＰＮＲＰＩＤのホストとなるノードに到達したときに、または訪れた先のノードの数がＲＥＳＯＬＶＥで設定されているＭａｘＨｏｐｓに等しいときに、または経路内の任意のノードがもはやＲＥＳＯＬＶＥをより適切なノードに転送することができなくなったときに、終了する。終了に際し、ＲＥＳＯＬＶＥから選択された内容が新しいＲＥＳＰＯＮＳＥメッセージ内に転送され、このメッセージはＲＥＳＯＬＶＥイニシエータに送り返される。ＲＥＳＰＯＮＳＥは、ＲＥＳＯＬＶＥからの「最良一致」ＣＰＡだけでなく、訪れた先のノードのリストも含む。ＲＥＳＰＯＮＳＥがＲＥＳＯＬＶＥ発信元に到達すると、発信元は「最良一致」ＣＰＡのＰＮＲＰＩＤとターゲットとを比較することによりターゲットＣＰＡを見つけたかどうかを容易に確認できる。

ＲＥＳＯＬＶＥ／ＲＥＳＰＯＮＳＥトランザクションの３ノード例が図４に示されている。この簡略化した例では、ノードＡ２２８は、ノードＢ２３０経由でノードＴ２３２を解決しようと試みている。ＡＣＫのほかに解決トランザクションに関わる３つのメッセージ、つまりＲＥＳＯＬＶＥ、ＲＥＳＰＯＮＳＥ、およびＡＵＴＨＯＲＩＴＹがある。解決が完了した後、後述のように、ノードＡ２２８はノードＴ２３２にＩＮＱＵＩＲＥメッセージを直接送信することができる。

ＲＥＳＯＬＶＥメッセージについては、３つのケースが考察され、そのうち最初の２つが図４に示されている。これら３つのケースでは、ノードＡ２２８でＲＥＳＯＬＶＥ２３４を開始し、ノードＡ２２８から別のノードＢ２３０へＲＥＳＯＬＶＥ２３６を転送し、ノードからＲＥＳＯＬＶＥを送り返されている（図４には示されていない）。これらのシナリオのそれぞれについて順番に説明する。

ノードＡ２２８でＲＥＳＯＬＶＥを開始することについて最初に説明する。図４に例示されているように、ノードＡ２２８は何らかの理由からＲＥＳＯＬＶＥを開始する。理由としては、アプリケーション解決要求、登録広告（ｒｅｇｉｓｔｒａｔｉｏｎａｄｖｅｒｔｉｓｅｍｅｎｔ）、キャッシュ幅保守（ｃａｃｈｅｂｒｅａｄｔｈｍａｉｎｔｅｎａｎｃｅ）、またはクラウド分割検出（ｃｌｏｕｄｓｐｌｉｔｄｅｔｅｃｔｉｏｎ）などがある。イニシエータ２２８は、オペレーションコードも指定し、これにより、ＲＥＳＯＬＶＥの条件はローカルで登録されているＩＤにより満たされることが可能かどうかを示す。それが可能であれば、ノードＡ２２８はローカルで登録されているＩＤの集合に一致がないかスキャンして調べる。一致が見つかれば、ＲＥＳＯＬＶＥは、一致するＩＤを持つノードＡ２２８自体の中で完了する。ローカルで登録されているＩＤが条件に合致していない場合、またはローカルＩＤのどれも一致していない場合、ＲＥＳＯＬＶＥメッセージ２３４が作成され、表４に示されているフィールドを備える。その後、このＲＥＳＯＬＶＥメッセージ２３４は、後述のように、他の何らかのノード２３０に転送され、処理される。

ノードＡ２２８がＲＥＳＯＬＶＥ２３４を別のノードＢ２３０に転送したい場合またはその必要がある場合、この次ノードを最初に選択しなければならない。次のホップを選択するために、ノードＡ２２８は、アドレスがすでに経路リストに載っているもの以外のターゲットＩＤ（ノードＴ２３２）に最も近いＰＮＲＰＩＤおよびＡの最も近いローカルで登録されているＩＤよりもターゲットＩＤに近くないＰＮＲＰＩＤを持つ３つのキャッシュされたＣＰＡのリストＬを作成する。ターゲットＩＤがリストＬに含まれている場合、そのエントリが次ホップとして選択される。含まれていない場合、リストＬが空でなければ、１つのエントリがランダムに選択される。つまり、ノードＡ２２８は、このノードよりもターゲットに近い新しいいくつかのノードを見つけ、ＲＥＳＯＬＶＥメッセージ２３４の転送先としてそのうちの１つを選択する。

ノードＡ２２８が次のホップを選択できる場合、ノードＡ２２８は適切なエントリを「受信済みビットマップ」内に挿入する。ノードＡ２２８は自分自身を経路リストに追加し、選択された次ホップに対するその最良のアドレスを選択し、エントリにＡｃｃｅｐｔｅｄのマークを付ける。ノードＡ２２８は、ＮｅｘｔＨｏｐを選択された転送先の予想ＰＮＲＰＩＤに設定し、ＲＥＳＯＬＶＥメッセージ２３４をノードＢ２３０に転送する。ＲＥＳＯＬＶＥメッセージ２３４が正常に送信された場合、送信側ノード２２８では、ＡＵＴＨＯＲＩＴＹメッセージ２３８の形で肯定応答を受信することを期待する。ＡＵＴＨＯＲＩＴＹ２３８が受信された場合、ノード２２８はＲＥＳＯＬＶＥ２３４に対するコンテキストを保持し、タイムアウト値に達するまでＲＥＳＰＯＮＳＥ２４０メッセージが返されるのを待つ。一定時間後、ＡＵＴＨＯＲＩＴＹ２３８が受信されない場合、ＲＥＳＯＬＶＥ２３４が再送される。ＮｅｘｔＨｏｐが無効であるとみなされるまでに、合計Ｎ回試みられる。好ましい実施形態では、Ｎ＝３である。リトライカウントを超えた場合、ローカルキャッシュからＮｅｘｔＨｏｐＣＰＡが除去され、エントリが失敗したホップとして経路リストに加えられる。ホップカウントを超えない場合、ローカルキャッシュから次のＮｅｘｔＨｏｐが選択され、処理が繰り返される。経路リスト内のエントリの数がＭａｘＨｏｐｓ以上の場合、応答コードをＲＥＳＵＬＴ＿ＭＡＸ＿ＨＯＰ＿ＬＩＭＩＴ＿ＨＩＴとするＲＥＳＰＯＮＳＥメッセージが生成され、Ａｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリへ送られる。

ノードが次のホップを見つけられなかった場合、ターゲットＩＤが最低キャッシュレベルにあるべきかチェックする。そうであれば、ノードはターゲットＩＤが存在していないのではないかと疑う。ノードは、既存の経路リスト内のエントリをチェックし、Ｓｕｓｐｉｃｉｏｕｓのマークが付けられているエントリを数える。このカウントが閾値を超えている場合、応答コードをＲＥＳＵＬＴ＿ＴＯＯ＿ＭＡＮＹ＿ＭＩＳＳＥＳとするＲＥＳＰＯＮＳＥメッセージが生成され、Ａｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリへ送られる。ノードが次のホップを見つけられなかったが、Ｓｕｓｐｉｃｉｏｕｓカウントを超えていない場合、ノードはＲＥＳＯＬＶＥをＡｃｃｅｐｔｅｄのマークが付けられている経路リスト内の最後のノードに送り返す。ノードはまず、自分自身を経路リストに追加し、転送先ノードに対するその最良のアドレスを選択し、エントリにＲｅｊｅｃｔｅｄのマークを付ける。これはＮｅｘｔＨｏｐを０に設定し、ＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰフラグをセットして、バックトラッキングを指示する。ターゲットＩＤがノードの最低キャッシュレベルになければならない場合、ターゲットＩＤが存在していないのではないかと疑う。この場合、ノードはさらに、経路リストのエントリにＳｕｓｐｉｃｉｏｕｓのマークを付ける。ノードが次のホップを見つけられず、経路リスト内にノードがない（自分自身のほかに）場合、それはＲＥＳＯＬＶＥメッセージの発信元である。この場合、結果が呼び出し側に返され、解決できなかったことを示し、応答コードはＲＥＳＵＬＴ＿ＮＯ＿ＢＥＴＴＥＲ＿ＰＡＴＨ＿ＦＯＵＮＤである。呼び出し側で、ＢｅｓｔＭａｔｃｈＣＰＡが利用できるようになる。

ノードＢ２３０は、ターゲットＰＮＲＰＩＤ、ＢｅｓｔＭａｔｃｈＣＰＡ、ＮｅｘｔＨｏｐＰＮＲＰＩＤ、およびＲＥＳＯＬＶＥを処理したすべてのノードのアドレスを記述した経路リストを含むＲＥＳＯＬＶＥメッセージ２３４を受信する。フラグフィールドにＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰが設定されておらず、ＢｅｓｔＭａｔｃｈＣＰＡにＣＰＡがあるか、または空である可能性がある場合、ノードＢ２３０はそのローカル処理負荷をチェックする。負荷が高すぎて、新しいＲＥＳＯＬＶＥ要求を処理できない場合、フラグフィールドが「ＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹ」に設定されているＡＵＴＨＯＲＩＴＹ２３８で応答し、処理は完了する。ＡＵＴＨＯＲＩＴＹ受信側は、拒絶ノードのエンドポイントを経路配列に追加し、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を行う必要がある。

受信ノード２３０は、経路配列がＡｃｃｅｐｔｅｄのマークが付けられている少なくとも１つのアドレスを含むこと、および最後のそのようなアドレスがメッセージの送信元（ソース）と同じであることをチェックする。そうでなければ、それ以上処理は行われない。受信ノードは、受信した要求に含まれるパラメータもチェックする。いくつかのパラメータが有効な範囲内にない場合、フラグフィールドが「ＡＦ＿ＩＮＶＡＬＩＤ＿ＲＥＱＵＥＳＴ」に設定されているＡＵＴＨＯＲＩＴＹメッセージで応答し、処理は完了する。無効なパラメータの一例として、ＭａｘＨｏｐｓが大きすぎる場合を挙げることができる。ＡＵＴＨＯＲＩＴＹ受信側は、拒絶ノードのエンドポイントを経路配列に追加し、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を行う必要がある。

受信ノード（例えばノードＢ２３０）は、ＮｅｘｔＨｏｐＩＤがローカルで登録されているかチェックする。シードサーバではこのテストをスキップすることができる。これが失敗した場合、フラグフィールドが「ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤ」に設定されているＡＵＴＨＯＲＩＴＹで応答し、処理は完了する。ＡＵＴＨＯＲＩＴＹ受信側は、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を担う。ＡＵＴＨＯＲＩＴＹ受信側はまた、ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤが受信されたときにＡＵＴＨＯＲＩＴＹ送信側（センダ）のＰＮＲＰＩＤをキャッシュから除去しなければならない。ＢｅｓｔＭａｔｃｈＣＰＡがメッセージに含まれている場合、ノードは、可能な限り、ＢｅｓｔＭａｔｃｈの妥当性を確認する。ＣＰＡが有効でない場合、ノードはメッセージからＢｅｓｔＭａｔｃｈＣＰＡを除去する。ＢｅｓｔＭａｔｃｈＣＰＡが有効な場合、ノードは通常の規則に従って、ＣＰＡをキャッシュに追加するかどうかを決定する。

またノードは、経路リスト内にそのノードに対するエントリがあるかどうかもチェックする。もしあれば、これはバックトラックされたＲＥＳＯＬＶＥでないので、ループがある。するとノードは、フラグフィールドが「ＡＦ＿ＲＥＪＥＣＴ＿ＬＯＯＰ」に設定されているＡＵＴＨＯＲＩＴＹで応答し、処理は完了する。ＡＵＴＨＯＲＩＴＹ受信側は、拒絶ノードのエンドポイントを経路配列に追加し、ＲＥＳＯＬＶＥ要求に対する他のどこかへの経路再選択を行うことを担う。

前のチェックがすべて通った場合、ノードＢ２３０はＡＵＴＨＯＲＩＴＹ２３８を送信して、ＲＥＳＯＬＶＥメッセージ２３４の肯定応答とする。ＲＥＳＯＬＶＥフラグＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮがセットされていた場合、ＮｅｘｔＨｏｐの認証連鎖がＡＵＴＨＯＲＩＴＹ２３８に含まれる。次のホップのＰＮＲＰＩＤに対応するピア名のクラシファイア（Ｃｌａｓｓｉｆｉｅｒ）文字列部分はＡＵＴＨＯＲＩＴＹメッセージに含まれる。

ノードＢ２３０は、現在のＢｅｓｔＭａｔｃｈよりも正確に一致しているローカルで登録されているＣＰＡがあるかどうかチェックする。あれば、ＢｅｓｔＭａｔｃｈをそれで置き換える。ノードはまた、ＯｐＣｏｄｅ、Ｐｒｅｃｉｓｉｏｎ、およびＴａｒｇｅｔＩＤに基づき、ＲＥＳＯＬＶＥ基準を満たすローカルで登録されているＣＰＡがあるかどうかもチェックする。一致があれば、または経路リスト内のエントリの個数＞＝ＭａｘＨｏｐｓであれば、ノードは現在のＢｅｓｔＭａｔｃｈを持つＲＥＳＰＯＮＳＥメッセージを作成する。ＲＥＳＯＬＶＥメッセージの経路は、ＲＥＳＰＯＮＳＥメッセージの経路にコピーされる。ノードは、ＲｅｓｐｏｎｓｅＣｏｄｅを設定して、ＲＥＳＵＬＴ＿ＦＯＵＮＤ＿ＭＡＴＣＨまたはＲＥＳＵＬＴ＿ＭＡＸ＿ＨＯＰ＿ＬＩＭＩＴ＿ＨＩＴのいずれかを示す。その後、ノードは、経路リストからアドレスを除去するだけでなく、Ｒｅｊｅｃｔｅｄのマークが付けられている後続のエントリも除去し、ＲＥＳＰＯＮＳＥをＡｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリに送信する。

ノードＢ２３０は、ＲＥＳＰＯＮＳＥを送信しなかった場合（図４に示されている）、次のノードＴ２３２にＲＥＳＯＬＶＥメッセージ２３６を転送しようと試みる。この転送は、上述の手順に従って行われる。つまり、ノードＴ２３２は、最初、ＡＵＴＨＯＲＩＴＹメッセージ２４２で応答する。次に、上述のチェックを実行し、ターゲットと一致していることを判別してから、それ自身をＢｅｓｔＭａｔｃｈとして識別するＲＥＰＯＮＳＥメッセージ２４４でノードＢ２３０に応答する。ＲＥＳＰＯＮＳＥメッセージ２４４に応答して、ノードＢ２３０はＡＣＫメッセージ２４６を送り返す。その後、ノードＢ２３０は経路リストをチェックし、ＲＥＳＰＯＮＳＥメッセージ２４０をノードＡ２２８に転送し、ＡＣＫメッセージ２４８で応答する。

上記のように、ノードは、さらに、バックトラックされたＲＥＳＯＬＶＥも処理できなければならない。ノードは、ＲＥＳＯＬＶＥメッセージＲを受信するときに、ＴａｒｇｅｔＩＤＰＮＲＰＩＤ、ＢｅｓｔＭａｔｃｈＣＰＡ、ＮｅｘｔＨｏｐＰＮＲＰＩＤ、およびＲＥＳＯＬＶＥを処理したすべてのノードのアドレスが記載されている経路リストを含む。バックトラックされたＲＥＳＯＬＶＥについては、フラグフィールドにＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰが設定される。このノードは、まず、「受信済みビットマップ」をチェックして、それがすでにこのＲＥＳＯＬＶＥを転送していることを確認する。ビットがセットされていない場合、メッセージは削除される。次に、ノードは経路リストをチェックして、そのアドレスが経路リスト上にあること、および経路リスト内でＡｃｃｅｐｔｅｄのマークが付けられている最上位のエントリであることを確認する。そうでなければ、メッセージを削除する。メッセージが削除されない場合、ノードはＡＵＴＨＯＲＩＴＹを送信側に送り返し、そのメッセージの肯定応答（ＡＣＫ）とする。これは、認証連鎖を含まない。

経路リスト内のエントリの個数＞＝ＭａｘＨｏｐｓであれば、ノードは現在のＢｅｓｔＭａｔｃｈを持つＲＥＳＰＯＮＳＥメッセージＳを作成する。ＲＥＳＯＬＶＥメッセージＲの経路は、Ｓの経路にコピーされる。ノードは、応答コードを設定し、ＭａｘＨｏｐｓを超えたことを示す。その後、ノードは、経路リストからアドレスを除去し、ＲＥＳＰＯＮＳＥをＡｃｃｅｐｔｅｄのマークが付けられている経路リスト内の一番最近のエントリに送り返す。ノードは、ＲＥＳＰＯＮＳＥを送信しなかった場合、ＲＥＳＯＬＶＥを次のホップに転送しようとする。この転送は上述の手順に従うが、ただし、いくつか例外があり、ａ）「ノードＢ２３０は、現在のＢｅｓｔＭａｔｃｈよりも正確に一致しているローカルで登録されているＣＰＡがあるかどうかチェックする。あれば、ＢｅｓｔＭａｔｃｈをそれで置き換える。」は適用されず、ｂ）現在のノードがＲＥＳＯＬＶＥトランザクションの発信元であり、理由がＲＥＡＳＯＮ＿ＲＥＰＡＩＲ＿ＤＥＴＥＣＴＩＯＮであれば、処理は完了である。

上で簡単に説明したように、ノードは、ＲＥＳＰＯＮＳＥメッセージ２４４、２４０を受信するときに、ＴａｒｇｅｔＩＤＰＮＲＰＩＤ、ＢｅｓｔＭａｔｃｈＣＰＡ、およびＲＥＳＯＬＶＥを処理したすべてのノードのアドレスが記載されている経路リストを含む。また、受信ノードは、「受信済みビットマップ」をチェックして、それがすでにこのＲＥＳＰＯＮＳＥ２４０、２４４と一致するＲＥＳＯＬＶＥ２３４、２３６を送信していることを確認する。ビットがセットされていない場合、メッセージは削除される。また、受信ノードは経路リストをチェックして、そのアドレスが経路リスト上の最後のアドレス（一番最近）であること、およびＡｃｃｅｐｔｅｄのマークが付けられていることを確認する。そうでなければ、メッセージを削除する。メッセージが削除されない場合、この受信ノードはＡＣＫ２４６、２４８を送信し、受信したことについて肯定応答する。ノードは、できる限りＢｅｓｔＭａｔｃｈＣＰＡの妥当性を確認し、キャッシュに追加する。ＣＰＡをキャッシュに追加する場合、さらにメッセージ交換が必要になると思われる一組の規則が適用され、ＰはＢｅｓｔＭａｔｃｈＣＰＡの妥当性を確認することができる。これについては、上記の出願で説明されている。

次に、ノードは自動的に経路リストから除去される。ノードは、Ａｃｃｅｐｔｅｄのマークが付けられているエントリに出会うか、リストが尽きるまで、Ｒｅｊｅｃｔｅｄのマークが付けられている前のエントリも除去する。Ａｃｃｅｐｔｅｄのマークが付けられているエントリが見つかると、ノードはＲＥＳＰＯＮＳＥをこのノードに転送する。ＲＥＳＰＯＮＳＥが転送されたノードがＡＣＫで応答しない場合、ノードはＲＥＳＰＯＮＳＥを最大Ｎ回まで再送する。再送がタイムアウトになった場合、ノードは経路リストから失敗した転送先ノードを除去し、この段落で説明したＲＥＳＰＯＮＳＥ処理を再試行する。経路リスト内にエントリがなくなれば、そのノードがオリジナルのＲＥＳＯＬＶＥ２３４の発信元である。ノード２２８は、その要求の発信元であったことを確認する。発信していなければ、ＲＥＳＰＯＮＳＥは削除される。応答コードが成功を示している場合、ノード２２８はＢｅｓｔＭａｔｃｈＣＰＡの送信元に対しアイデンティティ妥当性確認チェックを実行する。そのためには、ＩＮＱＵＩＲＥメッセージ２５０をターゲットノード２３２に送信し、返されたＡＵＴＨＯＲＩＴＹメッセージ２５２を確認する必要がある。アイデンティティ妥当性確認が失敗した場合、応答コードをＩＤＥＮＴＩＴＹ＿ＦＡＩＬＵＲＥに変更する。結果を呼び出し側に返す。

ＡＵＴＨＯＲＩＴＹメッセージは、送信側によってフラグメント化される場合がある。ＡＵＴＨＯＲＩＴＹメッセージを処理する前にすべてのフラグメントを受信したことを確認するのは受信側に任される。妥当な時間内にフラグメントが受信されない場合、リトライカウントを超えるまで、オリジナルのメッセージ（ＩＮＱＵＩＲＥまたはＲＥＳＯＬＶＥ）を再送しなければならない。ＡＵＴＨＯＲＩＴＹメッセージフラグにＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮがセットされている場合、ノードはＶａｌｉｄａｔｅＩＤで指定されているＰＮＲＰＩＤに対するキャッシュされたＣＰＡに連鎖妥当性確認オペレーションを実行する必要がある。この連鎖をチェックして、その中のすべての認証が有効であること、およびその連鎖の根と葉との関係が有効であることを確認しなければならない。この連鎖の根に対する公開鍵のハッシュをＣＰＡのピア名のオーソリティと比較して、一致していることを確認しなければならない。この連鎖の葉に対する公開鍵をＣＰＡの署名に使用する鍵と突き合わせて比較し、一致していることを確認しなければならない。最後に、Ｐ２ＰＩＤをチェックして、Ｐ２ＰＩＤを作成するための規則に従って、オーソリティおよびクラシファイアのハッシュであるか調べなければならない。上記のチェックが失敗した場合、ＣＰＡをキャッシュから除去し、ＲＥＳＯＬＶＥメッセージ経路リストにＡＵＴＨＯＲＩＴＹメッセージを送ったノードのアドレスを追加し、エントリにＲｅｊｅｃｔｅｄのマークを付けることによりＲＥＳＯＬＶＥメッセージを修正しなければならない。

ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤがセットされている場合、ＣＰＡをキャッシュから除去しなければならない。ＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮがセットされていないが、ＶａｌｉｄａｔｅＩＤＰＮＲＰＩＤに対応するＣＰＡは認証連鎖の妥当性確認を必要とする場合、ＣＰＡをキャッシュから除去し、ＲＥＳＯＬＶＥメッセージ経路リストにＡＵＴＨＯＲＩＴＹメッセージを送ったノードのアドレスを追加し、エントリにＲｅｊｅｃｔｅｄのマークを付けることによりＲＥＳＯＬＶＥメッセージを修正しなければならない。

ＶａｌｉｄａｔｅＩＤＰＮＲＰＩＤに対応するＣＰＡの妥当性確認が行われている場合、完全に妥当性確認が行われているというマークを付けなければならない。ＡＵＴＨＯＲＩＴＹメッセージからクラシファイア文字列を抽出して、ＣＰＡとともに保持する。ＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹ、ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤ、ＡＦ＿ＲＥＪＥＣＴ＿ＬＯＯＰ、およびＡＦ＿ＩＮＶＡＬＩＤ＿ＲＥＱＵＥＳＴがすべてクリアであれば、ＲＥＳＯＬＶＥは処理できるものとして受理され、ＡＵＴＨＯＲＩＴＹ処理が実行される。

いくつかの場合において、ＲＥＳＯＬＶＥメッセージを受信したノードは、転送に関して受理しないことを選択できるが、それでもＮｅｘｔＨｏｐの推奨を送信ノードに送る。この場合、ノードは推奨された参照エンドポイント（ＲｅｆｅｒｒａｌＥｎｄｐｏｉｎｔ）および参照ＰＮＲＰＩＤをＡＵＴＨＯＲＩＴＹメッセージで返す。この場合、ＡＵＴＨＯＲＩＴＹフラグの値にＡＦ＿ＲＥＤＩＲＥＣＴが含まれていなければならない。ＡＦ＿ＲＥＤＩＲＥＣＴとともにＡＵＴＨＯＲＩＴＹを受信するノードは、ＲＥＳＯＬＶＥメッセージを送信するために参照エンドポイントを使用するかしないかを選択することができる。いずれかの場合に、ＡＵＴＨＯＲＩＴＹで応答したノードが経路リストに追加される。ノードが参照エンドポイントを使用すべきなのは、ＲＥＳＯＬＶＥの発信元であるノードが発信してクラウド分割を検出し、ＲＥＳＯＬＶＥを理由ＲＥＡＳＯＮ＿ＲＥＰＡＩＲとともにＰＮＲＰシードサーバに送信している場合のみである。他の場合には、ノードは参照エンドポイントを無視しなければならない。

ＰＮＲＰは、有向フラッディング（ｄｉｒｅｃｔｅｄｆｌｏｏｄｉｎｇ）を使用して、ノード間でＣＰＡキャッシュエントリを伝搬する。いくつかの場合に、フラッディングが使用される。ＲＥＱＵＥＳＴメッセージに応答して同期をとる際に、要求されたＣＰＡは、ＲＥＱＵＥＳＴを送信したピアにフラッディングされる。ＲＥＱＵＥＳＴメッセージは、ＳＯＬＩＣＩＴメッセージが受け付けられ、ＡＤＶＥＲＴＩＳＥメッセージが送信された後でないと受け付けられない。ＣＰＡがキャッシュの最低レベルに追加されると必ず、追加されたＣＰＡはローカル登録ＩＤに一番近いｎ個のピアにフラッディングされる。値ｎは、チューニングすることができるが、値４が好ましい。ＣＰＡを追加する理由がＦＬＯＯＤの受信であれば、ＣＰＡは、アドレスが受信したＦＬＯＯＤのフラッデッドリスト（ＦｌｏｏｄｅｄＬｉｓｔ）に入っているノードにフラッディングすべきではない。十分な空きがあれば、受信フラッデッドリスト内のアドレスを新しいＦＬＯＯＤメッセージのフラッデッドリストにコピーしなければならない。ＣＰＡ取り消しを含むＦＬＯＯＤの受信後ＣＰＡがキャッシュの最低レベルから除去されると必ず、取り消されたＣＰＡはローカル登録ＩＤに一番近いｎ個のピアにフラッディングされる。またも、値ｎは、チューニングすることができるが、値４が好ましい。ＣＰＡは、アドレスが受信したＦＬＯＯＤのフラッデッドリストに入っているノードにフラッディングすべきではない。十分な空きがあれば、受信フラッデッドリスト内のアドレスを新しいＦＬＯＯＤメッセージのフラッデッドリストにコピーしなければならない。最後に、新しいピアに対してＦＬＯＯＤが受信され、ＣＰＡがキャッシュの最低レベルに追加されると、ローカルノードのＩＤとともにその新しいピアにＦＬＯＯＤメッセージが送信される。ＦＬＯＯＤの送信元が新しいピアであれば、例外が生じる。

ＰＮＲＰは、永続的な近隣関係を作らない。最も緩やかな意味では、ＣＰＡキャッシュ内でＣＰＡにより表されるすべてのノードは、近隣ノードとみなすことができる。しかし、ＣＰＡのキャッシュへの追加および除去は、ＣＰＡ発行者に必ずしも通知せずに行われる。ノードのキャッシュ内にピアのＣＰＡを置いても、近隣ノードがそのノードのＣＰＡをキャッシュに置くとは限らない。この関係は非対称である。しかし、上述の最後のＦＬＯＯＤ条件では、互いに近いＩＤに対し対称性を実現しようとする。

そのＦＬＯＯＤに対し他のアクションを実行する前に、ＡＣＫですべてのＵＤＰＦＬＯＯＤメッセージについて肯定応答する。ＦＬＯＯＤの送信側は、ＦＬＯＯＤが送信されたある期間の状態を保持する。ＡＣＫを受信すると、その状態は解放される。一定期間ＡＣＫが受信されないと、ＦＬＯＯＤが再送され、タイマーがリセットされる。ＦＬＯＯＤは、所定の回数まで再試行されるが、３回が好ましい。最後の再試行の後にＡＣＫが受信されないと、その状態は解放される。さらに、ＦＬＯＯＤの送信先が送信側のキャッシュ内にあった場合、これ以降未応答ノードへのメッセージの送信を試みないようキャッシュエントリが除去される。

ノードがＦＬＯＯＤメッセージを受信すると、まず最初にＡＣＫを送信してＦＬＯＯＤメッセージについて肯定応答することによりメッセージが処理される。ＶａｌｉｄａｔｅＩＤが存在しており、ローカルで登録されていない場合、フラグフィールドは「ＫＦ＿ＮＡＣＫ」に設定される。次に、ＦＬＯＯＤメッセージの妥当性確認が行われる。これは、ＣＰＡ署名および内容に対するローカルでの確認を含む。ＣＰＡの妥当性確認が行われた場合、ＣＰＡをキャッシュに追加するかどうかが決定される。ＣＰＡがローカルの同じノード上で登録されているＰＮＲＰＩＤに対するものであれば、キャッシュに追加する必要はない。ＣＰＡだけではＣＰＡを署名するために使用されるアイデンティティを確認できず、またＣＰＡがキャッシュビューの２つの低いレベルのうちの１つに追加される場合、後述のようにアイデンティティ妥当性確認を実行する必要がある。妥当性確認が失敗した場合、ノードはＦＬＯＯＤメッセージを削除する。成功した場合、ノードはＦＬＯＯＤを処理し続ける。ＣＰＡがすでに期限切れになっている場合、ノードはＦＬＯＯＤを削除する。ＣＰＡが取り消しＣＰＡの場合、キャッシュに対応するＣＰＡがあれば、ノードはそれをキャッシュから除去する。見つかった場合、ノードはＦＬＯＯＤメッセージを送信することにより取り消しを他の近隣ノードに送る。

ＣＰＡが取り消しＣＰＡでない場合、ノードはキャッシュを更新する。一致するＣＰＡがすでにキャッシュ内にある場合、ノードは新しいＣＰＡデータでキャッシュエントリを更新する。これが新しいエントリであれば、ノードは新しいエントリを作成し、キャッシュへの追加を試みる。別のエントリを除去して入れる余地を作る必要がある場合にはエントリを追加できないが、信頼度レベルが高い、または近接性測定基準が優れているため既存のエントリは新しいエントリよりも好ましい。エントリが最低キャッシュレベルに属している場合は、追加しなければならない。ＣＰＡが最低キャッシュレベルに属している場合、キャッシュに追加できない場合であっても、いくつかの近隣ノードに転送しなければならない。同期中にＦＬＯＯＤを受信した場合、すべての発見されたＣＰＡはすでに他のノードに知られていると想定されるため、ＦＬＯＯＤメッセージの転送が抑制される。ＦＬＯＯＤを転送する必要がある場合、ローカルで登録されているＩＤに最も近いｎ個のＰＮＲＰＩＤの集まりが選択される。新しいＣＰＡ、およびｎ個の近隣ノードを記述したフラッデッドリスト、さらにそれに加えて受信されたＦＬＯＯＤメッセージ内の受信フラッデッドリストの内容とともに、ＦＬＯＯＤメッセージがそれぞれのＩＤに送信される。

アイデンティティ妥当性確認は、ＣＰＡの妥当性を確認する場合に使用される脅威緩和デバイス（ｔｈｒｅａｔｍｉｔｉｇａｔｉｏｎｄｅｖｉｃｅ）である。これは２つの目的を有する。第１に、アイデンティティ妥当性確認により、ＣＰＡで指定されたＰＮＲＰノードがローカルで登録されているそのＣＰＡからのＰＮＲＰＩＤを持つことが保証される。第２に、セキュリティ保護されたＰＮＲＰＩＤに対して、アイデンティティ妥当性確認により、ＰＮＲＰＩＤのオーソリティと暗号により実証可能な関係のある鍵を使用して、ＣＰＡが署名されていることが保証される。アイデンティティ妥当性確認でこれら２つの目標を達成する詳細については、上記の係属中の出願において説明されている。

２つの異なる時期に、アイデンティティ妥当性確認チェックが実行される。第１に、アイデンティティ妥当性確認は、ＣＰＡを最低の２つのキャッシュレベルに追加する場合に実行される。最低の２つのキャッシュレベルにおけるＣＰＡが有効であることは、ＰＮＲＰでＰＮＲＰＩＤを解決するために重要である。ＣＰＡをこれら２つのレベルのいずれかに追加する前にアイデンティティ妥当性確認を実行すると、複数の攻撃が緩和される。この場合、ＣＰＡは最大、例えば３０秒間リスト内に保持され、ＡＵＴＨＯＲＩＴＹメッセージが届くのを待つ。第２に、アイデンティティ妥当性確認は、ＲＥＳＯＬＶＥのときにチャンスがあれば実行される。ＰＮＲＰキャッシュの回転率は高い。したがって、ほとんどキャッシュエントリは、そもそも使用される前にキャッシュ内で上書きされてしまう。ＰＮＲＰは、実際に使用するまでほとんどのＣＰＡの妥当性を確認しない。ＣＰＡを使用して、ＲＥＳＯＬＶＥ経路の選択を行う場合、ＰＮＲＰはアイデンティティ妥当性確認をＲＥＳＯＬＶＥメッセージと抱き合わせの形で実行する。ＲＥＳＯＬＶＥには、「次のホップ」ＩＤが含まれ、これは、ＩＮＱＵＩＲＥメッセージの「ターゲットＩＤ」と同じように処理される。ＲＥＳＯＬＶＥに対しＡＵＴＨＯＲＩＴＹメッセージにより肯定応答されるが、ＩＮＱＵＩＲＥに対し期待されているのと同じである。チャンスがあれば実行するアイデンティティ妥当性確認が失敗した場合、ＲＥＳＯＬＶＥの受信側は、送信側でそうであると信じている受信側ではない。したがって、ＲＥＳＯＬＶＥに対してはどこか他の経路が選択され、無効なＣＰＡがキャッシュから除去される。

この妥当性確認を例示するため、ＰがＰＮＲＰＩＤ「Ｔ」に対するアイデンティティ妥当性確認を要求するノードであると仮定する。Ｎは、アイデンティティ妥当性確認要求を受信するノードである。Ｐは、ターゲットＩＤ＝ＴのＩＮＱＵＩＲＥメッセージ、または次のホップ＝ＴのＲＥＳＯＬＶＥメッセージのいずれかを生成する（そしてＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰは設定されない）。Ｎは、ローカルで登録されているＰＮＲＰＩＤのリストをチェックする。Ｔがそのリスト内になければ、ＮはＡＵＴＨＯＲＩＴＹメッセージで応答し、ＩＤＴがローカルで登録されていないことを示す。受信されたメッセージがＲＥＳＯＬＶＥであった場合、Ｐがどこか他への転送を処理するため、ＲＥＳＯＬＶＥは破棄される。ＴがＮでＰＮＲＰＩＤのリスト内にある場合、ＮはＡＵＴＨＯＲＩＴＹメッセージを構築し、ターゲットＩＤをＴに設定する。ＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮフラグがセットされていた場合、ＮはＰＮＲＰＩＤＴに対するオーソリティにＣＰＡを署名するために使用される鍵に関係する認証連鎖（もしあれば）を取り出す。認証連鎖は、ＡＵＴＨＯＲＩＴＹメッセージの中に挿入される。ピア名のクラシファイア部分も、ＡＵＴＨＯＲＩＴＹメッセージに追加される。

ＮはＰへＡＵＴＨＯＲＩＴＹメッセージを送信する。ＡＵＴＨＯＲＩＴＹメッセージが１２１６バイトよりも長い場合、メッセージは１２１６バイト以下の複数のフラグメントに分割され、各フラグメントが送信される。Ｔがセキュリティ保護されていないＩＤの場合、またはＣＰＡがすでに妥当性確認されていた場合（ＲＥＳＯＬＶＥを送信しＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮをクリアした）、処理は完了する。Ｐは、鍵を署名するＣＰＡとＰＮＲＰＩＤＴを生成するために使用されるオーソリティとの関係の妥当性を確認する。妥当性確認が失敗した場合、ＣＰＡは破棄される。妥当性確認が失敗し、開始メッセージがＲＥＳＯＬＶＥであった場合、ＰはどこかほかへＲＥＳＯＬＶＥを転送する。

上記の出願で説明されているように、また上で簡単に説明したように、ＰＮＲＰクラウドは分割可能である。これは２通りの方法で行える。第１に、クラウドは、独立に開始することができ、マージする必要がある。第２に、クラウドは、一体として開始されている可能性があるが、クラウドの一部断片はクラウドの残りから分離されている可能性がある。可能な分割をブリッジするために、クラウドはシードサーバを指定していると仮定する。これらは、ＤＮＳを介してブートストラップするために使用するのと同じサーバである。クラウド内に複数のシードサーバがある場合、シードサーバ同士が定期的に連絡を取り合い、キャッシュでＩＤを交換するようにしなければならない。これは、同期処理を使用して実行できる。孤立した島を作ることが回避される。

クラウド内のノードは、定期的にシードサーバをポーリングし、ノードが主クラウドから孤立していないかテストし、必要ならばマージして戻すことを試みる。ノードが分割のテストを行う頻度は、クラウドのサイズの推定値に反比例する。これは、分割が頻繁に生じすぎないようにするテストである。最近クラウドに加入したノードは、クラウドのサイズを推定できると仮定する前に、そのキャッシュに初期値として値が入るまで一定期間待たなければならない。

クラウドのマージを使用可能にするには、ＰＮＲＰＲＥＰＡＩＲメッセージを使用する。ＲＥＰＡＩＲは、ＰＮＲＰＩＤ、ノードのＩＰアドレス、および修復レベル（ＲｅｐａｉｒＬｅｖｅｌ）番号を含む。キャッシュレベルには、最上位レベルである０から始まる番号が付けられ（最大番号範囲）、それ以降のレベルには１ずつ高くなる番号が付けられる（小さな範囲）。分割が最初に検出されたら、修復レベル値を０に初期化する。ノードが分割コードのテストを実行すると決定した場合、ノードは内部で、ＩＰアドレス、ローカルで登録されているＰＮＲＰＩＤ、およびレベル０として知られているシードサーバのアドレスを使用して、ＲＥＰＡＩＲを生成する。これはこのＲＥＰＡＩＲ自体を処理する。

ＲＥＰＡＩＲが処理されるときに、ノードは分割のテストを実行する。まず、ＲＥＰＡＩＲメッセージ内のＩＤに最も近いローカルで登録されているＩＤを見つける。次に、このＩＤ＋１に対するＲＥＳＯＬＶＥをＲＥＰＡＩＲメッセージで指定されているＩＰアドレスに送信する。このＲＥＳＯＬＶＥには、修復の理由コード（ＲｅａｓｏｎＣｏｄｅｏｆＲｅｐａｉｒｉｎｇ）がなければならない。これが知られているノードに解決する場合、分割はない。これが新しいノードに解決する場合、分割が疑われる。発見された新しいノードが最下位キャッシュレベル（番号は最高）にあれば、フラッディングをいつものように実行する。修復の理由コードがＦＬＯＯＤメッセージに設定される。同様に、ＲＥＳＯＬＶＥを受け取るノードが送信元ＩＤを最低キャッシュレベルに入れた場合、そのノードはエントリを送信元へフラッディングする。すべてこのフラッディングで、新しいクラウドと複数のＩＤの交換が行われる。フラッディングを介して発見されたすべての新しいノードは、このようにして追跡される。

発見された新しいノードがすでに知られているノードよりも近く、キャッシュエントリが受信修復レベルにある場合、ノードは修復レベルでＲＥＰＡＩＲメッセージをキャッシュ内のエントリに送る。ＲＥＰＡＩＲが送信される毎に、ノードは新しく発見されたノードＩＤとＩＰアドレスの１つを選択し、修復レベル＋１で渡す。発見された新しいノードがすでに知られているノードよりも遠い場合、ノードはＲＥＰＡＩＲを新しいノードに送信し、ローカルキャッシュからのあるＩＤおよびアドレスならびに受信修復レベルを渡す。ＲＥＰＡＩＲメッセージを受信する各ノードも同じようにして処理する。

明らかに、ＰＮＲＰプロトコルは１０個のメッセージタイプからなる。各メッセージは、ＰＮＲＰヘッダから始まり、その後に、そのメッセージタイプに固有のフィールドが続く。オーバーヘッド（フィールド記述など）は、各メッセージフィールドテーブルの「長さ」欄で別々に計算される。以下の説明では、これらのメッセージすべてにより共有される一般的メッセージデータ構造について説明し、その後、本発明のプロトコルに含まれる１０個のメッセージのそれぞれに対するメッセージデータ構造について詳述する。この説明の後に、本発明のメッセージを構築するために使用されるフィールドデータ構造のそれぞれについて説明する。

図５に例示されているのは、本発明のＰＮＲＰの１０個のメッセージを構築するために使用される基本メッセージデータ構造２６０を説明するデータ構造例の図である。これからわかるように、メッセージデータ構造２６０は、多数のフィールド２６２_１−Ｎを含む。好ましい実施形態では、第１のフィールド２６２_１はＰＮＲＰヘッダ用に予約されている。メッセージ２６０を構築するために使用される個々のフィールド２６２_１−Ｎのそれぞれに対するフィールドデータ構造２６４は、型コンポーネント２６６、長さコンポーネント２６８、およびフィールドデータ構造２６４の実際の内容またはペイロード２７０を含む。長さコンポーネント２６８は、フィールド全体２６４の長さ２７２として計算される。このようにして、プロトコルは完全に拡張可能である。

本発明のデータ構造に従って、ＲＥＳＯＬＶＥメッセージを構築する。図６の簡略化したデータ構造図からわかるように、ＲＥＳＯＬＶＥメッセージ２８０は、多数のフィールド２８２〜２９２から構築される。また、本発明のフィールドデータ構造に従って、さまざまなフィールドを構築する。例えば、ＰＮＲＰ＿ＨＥＡＤＥＲフィールド２８２は、フィールドデータ構造２９４を含む。このデータ構造２９４の構成要素は、型（フィールドＩＤ２９６）、長さ２９８からなる。このＰＮＲＰ＿ＨＥＡＤＥＲデータ構造２９４の内容は、プロトコルコンポーネント３００、メジャーバージョンコンポーネント３０２、マイナーバージョンコンポーネント３０４、メッセージタイプコンポーネント３０６、およびメッセージＩＤコンポーネント３０８を含む。同様に、ＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤフィールド２８８は、フィールドデータ構造３１０を含む。他のすべてのフィールドデータ構造と同様、ＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤデータ構造３１０は型コンポーネント（フィールドＩＤ３１２）および長さコンポーネント３１４から始まる。このフィールドデータ構造の内容は、Ｐ２ＰＩＤコンポーネント３１６およびサービスロケーションコンポーネント３１８を含む。異なるフィールドはそれぞれ、図５に例示されているのと同様にして構築されるが、それぞれの説明は以下で行う。

明らかなように、また以下で例示するように、このＲＥＳＯＬＶＥメッセージは解決するターゲットＰＮＲＰＩＤ、ＲＥＳＯＬＶＥ発信元のＣＰＡ、「最良一致」のＣＰＡ、およびＲＥＳＯＬＶＥを処理したノードのリストを含む。ＲＥＳＯＬＶＥは、「フラグ」フィールドを含む。Ｒｅｓｏｌｖｅ＿ＣｏｎｔｒｏｌｓフィールドのＦｌａｇｓサブフィールドに対し２つのフラグ、つまり、受信側がＡＵＴＨＯＲＩＴＹ応答で認証連鎖（もし存在すれば）を送信することを要求するＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮ−０ｘ０００１とＲＥＳＯＬＶＥのバックトラッキング経路上で使用されるＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰ−０ｘ０００４とが定義される。ノードがＲＥＳＯＬＶＥをバックトラッキングの一部として受信している場合、送信側はこのノードのＰＮＲＰＩＤを知らない。「次のホップ」フィールドは０に設定され、ＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴＨＯＰはセットされて、ＡＵＴＨＯＲＩＴＹはＲＥＳＯＬＶＥに対する「ａｃｋ」としてのみ使用されることを示す。上述のように、ＲＥＳＯＬＶＥ受信は、ＡＵＴＨＯＲＩＴＹメッセージにより肯定応答される。ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは、本発明の好ましい実施では５に設定される。本発明の教示により構築されたＲＥＳＯＬＶＥメッセージのデータ構造の詳細を表５に提示した。

この表５で、Ｐは符号化されたＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められる。Ａは、フラグ付き配列内のエントリの個数である。したがって、ＭａｘＨｏｐ値を超えてはならない。

ＲＥＳＰＯＮＳＥは、ＲＥＳＯＬＶＥが、ターゲットＰＮＲＰＩＤを所有するノードに到達したとき、またはフラグ付き経路サイズがＲＥＳＯＬＶＥＭａｘＨｏｐｓに等しいときに、生成される。ＲＥＳＰＯＮＳＥが生成されると、対応するＲＥＳＯＬＶＥフラグ付き経路からのすべてのエントリがＲＥＳＰＯＮＳＥ経路にコピーされる。ＲＥＳＰＯＮＳＥメッセージは、それぞれの適切なネットワークエンドポイントがＲＥＳＰＯＮＳＥを処理し、それがＲＥＳＯＬＶＥ発信元に返されるまで、経路リスト内で「ａｃｃｅｐｔ」のマークを付けられているすべてのアドレスを下から上まで通って送られる。上述のように、ＲＥＳＰＯＮＳＥ受信は、ＡＣＫメッセージにより肯定応答される。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは６に設定される。本発明の教示により構築されたＲＥＳＰＯＮＳＥメッセージのデータ構造の詳細を表６に提示した。

この表６で、Ｐは符号化された送信元ＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められる。Ｂは、エンドポイント配列内のエントリの個数である。

ＳＯＬＩＣＩＴメッセージは、キャッシュから送信側へエントリをＡＤＶＥＲＴＩＳＥするよう受信側に要求するメッセージである。送信側は、受信側がキャッシュに追加できるＣＰＡを含む。ＨａｓｈｅｄＮｏｎｃｅは、ＡＤＶＥＲＴＩＳＥメッセージで返さなければならない。ＳＯＬＩＣＩＴ受信は、ＡＤＶＥＲＴＩＳＥメッセージにより肯定応答される。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは１に設定される。本発明の教示により構築されたＳＯＬＩＣＩＴメッセージのデータ構造の詳細を表７に提示した。この表で、Ｐは符号化された送信元ＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められる。

ＳＯＬＩＣＩＴへの応答としてＡＤＶＥＲＴＩＳＥメッセージが生成される。ＡＤＶＥＲＴＩＳＥにより、広告者のキャッシュ内からＰＮＲＰＩＤのうちのいくつかのリストが表示される。これにより、ＡＤＶＥＲＴＩＳＥ受信側は、キャッシュに初期値を入力することを選択的にＣＰＡに要求することができる。ＡＤＶＥＲＴＩＳＥ受信は、ＳＯＬＩＣＩＴの肯定応答として働く。ＡＤＶＥＲＴＩＳＥの肯定応答は生成されない。ＳＯＬＩＣＩＴの肯定応答として機能しないＡＤＶＥＲＴＩＳＥは、何も通知せずに黙って破棄されるべきである。ＨａｓｈｅｄＮｏｎｃｅ値は、ＳＯＬＩＣＩＴメッセージで受信した値と同じでなければならない。ＡＤＶＥＲＴＩＳＥを受信したノードは、ＨａｓｈｅｄＮｏｎｃｅが有効であることを確認できなければならない。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは２に設定される。本発明の教示により構築されたＡＤＶＥＲＴＩＳＥメッセージのデータ構造の詳細を表８に提示した。この表で、ＡはＩＤ配列内のエントリの個数である。

ＲＥＱＵＥＳＴメッセージは、ＡＤＶＥＲＴＩＳＥされたＣＰＡの部分集合をＦＬＯＯＤするよう広告者に要求する場合に使用する。Ｎｏｎｃｅをハッシュして、オリジナルのＳＯＬＩＣＩＴで受信したＨａｓｈｅｄＮｏｎｃｅと比較しなければならない。ＩＤ配列には、送信側が、ＣＰＡを取得できるように送信側にフラッディングして戻したいＰＮＲＰＩＤが含まれる。ＲＥＱＵＥＳＴ受信は、ＡＣＫメッセージにより肯定応答される。本発明の好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは３に設定される。本発明の教示により構築されたＲＥＱＵＥＳＴメッセージのデータ構造の詳細を表９に提示した。この表で、ＡはＩＤ配列内のエントリの個数である。

ＦＬＯＯＤメッセージは、ＰＮＲＰによって使用され、ピアを選択するためキャッシュされているＣＰＡを伝搬する。ＦＬＯＯＤは、新しいＣＰＡを最低キャッシュレベルに追加するとき、または最低キャッシュレベルの始めのほうのバージョンで取り消されたＣＰＡを処理するときに、ＲＥＱＵＥＳＴメッセージに応答して開始される。ＦＬＯＯＤは、冗長ＦＬＯＯＤの発生の防止を補助するための「フラッデッドリスト」と呼ばれるアドレスのリストを含む。フラッデッドリストには、送信側のアドレス、送信側が直接ＦＬＯＯＤを送信しようとするすべての送信先、およびすでにＦＬＯＯＤを受信したことを送信側が知っている他のＰＮＲＰノードのアドレスが含まれる。「フラッデッドリスト」には、最大数のエントリが含まれる。リストが満杯になった場合、ＦＩＦＯ方式でエントリが置き換えられる。このときに、ＦＬＯＯＤ受信側は離れている近隣ノードよりも「そばにある」近隣ノードにそのＦＬＯＯＤを伝搬する可能性が高いと想定する。ＦＬＯＯＤ受信は、ＡＣＫメッセージにより肯定応答される。ＩＤ妥当性確認は任意選択のフィールドである。存在する場合、指定されたＰＮＲＰＩＤを持つＣＰＡがローカルでキャッシュされていれば受信側はＡＣＫで応答し、存在しない場合、ローカルでキャッシュされていなければＮＡＣＫで応答する。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは４に設定される。本発明の教示により構築されたＦＬＯＯＤメッセージのデータ構造の詳細を表１０に提示した。この表で、Ｐは符号化されたＣＰＡの長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められ、Ａは配列内のエントリの個数である。

ＰＮＲＰノードは、ＩＮＱＵＩＲＥメッセージを使用して、選択ＣＰＡに対しアイデンティティ妥当性確認を実行してから、ローカルキャッシュに入力する。アイデンティティ妥当性確認によりＣＰＡがまだ発信元ノードで有効であることを確認し、そのＣＰＡを登録するために発信元ノードのオーソリティの妥当性確認を補助する情報を要求する。「フラグ」フィールドに対して１つのフラグ、つまりＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮが定義されるが、このフラグは認証連鎖（存在する場合）をＡＵＴＨＯＲＩＴＹ応答で送信するよう受信側に要求するフラグである。ＩＮＱＵＩＲＥ受信は、ＰＮＲＰＩＤがローカルで登録されている場合に、ＡＵＴＨＯＲＩＴＹメッセージにより肯定応答される。そうでなければ、ＩＮＱＵＩＲＥメッセージは黙って無視される。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは７に設定される。本発明の教示により構築されたＩＮＱＵＩＲＥメッセージのデータ構造の詳細を表１１に提示した。この表から明らかなように、ＦＬＡＧＳ＿ＦＩＥＬＤの後にさらに２バイトあり、次のフィールドはＤＷＯＲＤ境界に置かれる。

ＡＵＴＨＯＲＩＴＹメッセージは、ＰＮＲＰＩＤがローカルノードにまだ登録されていることを確認するかまたは否認するために使用され、任意選択により、ＡＵＴＨＯＲＩＴＹ受信側がターゲットＩＤに対応するＣＰＡを登録するノードの権利の妥当性確認を行えるようにする認証連鎖を提供する。「フラグ」フィールドに対して定義されているフラグは、指定された「妥当性確認」ＰＮＲＰＩＤがこのホストに登録されていないことを示す、ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤ−０ｘ０００１、使用されていないＡＦ＿ＩＮＶＡＬＩＤ＿ＳＯＵＲＣＥ−０ｘ０００２、これもまた使用されていないＡＦ＿ＩＮＶＡＬＩＤ＿ＢＥＳＴ＿ＭＡＴＣＨ−０ｘ０００４、ＲＥＳＯＬＶＥに対する応答でのみ有効であり、ホストがビジー状態であるためＲＥＳＯＬＶＥを受け付けられず、送信側は処理のため別のところに転送しなければならないことを示すＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹ−０ｘ０００８、使用されていないＡＦ＿ＲＥＪＥＣＴ＿ＤＥＡＤＥＮＤ−０ｘ００１０、ノードがすでにＲＥＳＯＬＶＥメッセージを処理しており、ここに送信すべきではなかったことを示すＡＦ＿ＲＥＪＥＣＴ＿ＬＯＯＰ−０ｘ００２０、デバッグにのみ使用されるＡＦ＿ＴＲＡＣＩＮＧ＿ＯＮ−０ｘ００４０、ノードがＲＥＳＯＬＶＥメッセージを転送していないが、ＡＵＴＨＯＲＩＴＹメッセージ内に参照アドレスを含めていることを示すＡＦ＿ＲＥＤＩＲＥＣＴ−０ｘ００８０、ＭａｘＨｏｐｓが大きすぎると発生する可能性のあるＲＥＳＯＬＶＥメッセージの妥当性確認失敗を示すＡＦ＿ＩＮＶＡＬＩＤ＿ＲＥＱＵＥＳＴ−０ｘ０１００、およびＶａｌｉｄａｔｅＰＮＲＰＩＤとＣＰＡの署名に使用される公開鍵との関係の妥当性確認を可能にする認証連鎖が含まれることを示すＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮ−０ｘ８０００である。

ＶａｌｉｄａｔｅＰＮＲＰＩＤは、ＡＵＴＨＯＲＩＴＹが送信されるＩＤを有する。認証連鎖は任意選択である。ＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮフラグは、それが存在しているかいないかを示す。参照エンドポイントも任意選択である。このフィールドは、ＲＥＳＯＬＶＥメッセージを転送できないが、ＲＥＳＯＬＶＥを送信できた別の送信先ノードを認識しているノードにより使用される。エンドポイントは、ＲＥＳＯＬＶＥの送信先であるピアノードのＩＰｖ６アドレスおよびポートを含む。現在、このフィールドは、ノードがシードサーバを介してクラウド分割を検出しようとしているときを除いて無視される。クラシファイアフィールドは、ＰＮＲＰＩＤを作成するために使用されるピア名の一部である実際のクラシファイア文字列を含む。ＡＵＴＨＯＲＩＴＹ受信は、明示的に肯定応答されない。ＡＵＴＨＯＲＩＴＹは、ＩＮＱＵＩＲＥまたはＲＥＳＯＬＶＥメッセージに対する肯定応答／応答としてのみ送信される。ＡＵＴＨＯＲＩＴＹは、このコンテキストから受信される場合は、破棄されなければならない。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは８に設定される。本発明の教示により構築されたＡＵＴＨＯＲＩＴＹメッセージのデータ構造の詳細を表１２に提示した。この表で、Ｃは符号化された認証連鎖の長さ（バイト）であり、最近ＤＷＯＲＤ境界に丸められ、Ｓはクラシファイア文字列の長さ（バイト）である。

ＡＵＴＨＯＲＩＴＹメッセージは、認証連鎖およびクラシファイア文字列を含むため、非常に長い場合がある。ネットワークを介した伝送を円滑にするため、送信時に複数のフラグメントに明示的に分割できる。受信側は、メッセージを処理する前にフラグメントをまとめることができなければならない。メッセージが分割される場合、ヘッダフィールドおよび肯定応答されたヘッダフィールドはそれぞれのフラグメントの中で繰り返される。各フラグメントはさらに、分割コントロール（ＳｐｒｉｔＣｏｎｔｒｏｌ）フィールドも含む。各フラグメントにおいて、分割コントロールフィールド内のオフセット値が変更され、フラグメントのオフセットが反映される。分割コントロール内のサイズ値は、メッセージ全体のサイズからヘッダ、肯定応答されたヘッダ、および分割コントロールフィールドのサイズを引いた値である。最後を除く各フラグメントは、同じサイズでなければならない。メッセージが分割されない場合、分割コントロールフィールドは任意選択である。

ＡＣＫメッセージはＰＮＲＰによって使用されるが、ＰＮＲＰは要求／応答プロトコルだからである。いくつかの状況では、応答の代わりにＡＣＫを使用することでプロトコルが簡素化される。ＡＣＫは、ＲＥＱＵＥＳＴ、ＲＥＳＰＯＮＳＥ、およびＦＬＯＯＤメッセージを受信した後常に送信される。他のメッセージは、適切な応答メッセージタイプにより肯定応答される。ＡＣＫは、ＡＣＫとして働くが、妥当性確認ＩＤがセットされているＦＬＯＯＤの場合には、フラグフィールドをＫＦ＿ＮＡＣＫ＝１に設定することによりＮＡＣＫとして働く。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは９に設定される。本発明の教示により構築されたＡＣＫメッセージのデータ構造の詳細を表１３に提示した。

ＲＥＰＡＩＲメッセージが使用されるのは、場合によって、ＰＮＲＰクラウドに分割が生じる可能性があるためである。このメッセージを使用して、分割のテストを実行し、必要ならばＲＥＰＡＩＲを開始する。ＲＥＰＡＩＲでは、ＲＥＰＡＩＲを他のキャッシュレベルに伝搬するよう他のノードに要求する。好ましい実施形態では、ヘッダ内のＭｅｓｓａｇｅＴｙｐｅは１０に設定される。本発明の教示により構築されたＲＥＰＡＩＲメッセージのデータ構造の詳細を表１４に提示した。この表から明らかなように、ＣＡＣＨＥ＿ＬＥＶＥＬの後にさらに２バイトあり、次のフィールドはＤＷＯＲＤ境界に置かれる。

これまでメッセージおよびそのデータ構造について説明してきたが、今度は、そのメッセージを構築するために使用するメッセージ要素に注目する。以下では、ＰＮＲＰメッセージで送信される構造体のバイトコードを詳述する。断りのない限り、数値はすべてネットワークバイト順で送信され、送信前にテキストはすべてＵＴＦ−８で符号化される。これらのメッセージ要素は、説明したばかりのメッセージのビルディングブロックである。基本メッセージ要素はフィールド記述である。各フィールド要素は、メッセージ内の４バイト境界で始まる必要がある。つまり、フィールド間にはギャップがありうるということである。

ＭＥＳＳＡＧＥ＿ＦＩＥＬＤ要素は、将来ＰＮＲＰを容易に拡張できるようにするため使用されるフィールド記述である。メッセージ内のデータの集合毎に、フィールドの型を示す１６ビットの「フィールドＩＤ」とフィールドに対する１６ビットバイトカウントが用意される。本発明の教示により構築されたＭＥＳＳＡＧＥ＿ＦＩＥＬＤ要素のデータ構造の詳細を表１５に提示した。

ＰＮＲＰ＿ＨＥＡＤＥＲ−型０ｘ００１０は、すべてのＰＲＮＰメッセージの先頭に使用される。プロトコル＋バージョンは４バイト識別子であり、受信したメッセージが本当にＰＮＲＰを対象としたものかどうかを判別するのに使用される。本発明の教示により構築されたＰＮＲＰ＿ＨＥＡＤＥＲ要素のデータ構造の詳細を表１６に提示した。

ＰＮＲＰ＿ＨＥＡＤＥＲのメッセージＩＤを使用することで、ノードは、ノードが送信したメッセージに対する応答であると主張する受信メッセージが実際にそのような応答であることを確認できる。例えば、ノードがＲＥＳＯＬＶＥメッセージを別のノードに送信すると仮定する。この第１のノードは、図４に示されているように、引き換えにＡＵＴＨＯＲＩＴＹメッセージを受信することを予期する。しかし、オリジナルのＲＥＳＯＬＶＥに対する応答を追跡またはトレースしないと、受信したＡＵＴＨＯＲＩＴＹメッセージが正当なものである、あるいはクラウド内の悪意あるノードによるスプーフィングであるという保証はない。ＲＥＳＯＬＶＥメッセージにメッセージＩＤを含めることにより、ＡＵＴＨＯＲＩＴＹメッセージを生成するノードは、後述のＰＮＲＰ＿ＨＥＡＤＥＲ＿ＡＣＫＥＤフィールドに、応答の中のこのメッセージＩＤを含めることができる。

ＰＮＲＰ＿ＨＥＡＤＥＲ＿ＡＣＫＥＤ−型０ｘ００１８は、ＰＮＲＰメッセージヘッダ全体であり、肯定応答されるメッセージを識別する場合に使用される。本発明の教示により構築されたＰＮＲＰ＿ＨＥＡＤＥＲ＿ＡＣＫＥＤ要素のデータ構造の詳細を表１７に提示した。

ＩＰＶ６＿ＥＮＤＰＯＩＮＴ−型０ｘ００２１要素が使用されるのは、ＰＮＲＰがＩＰｖ６クラウド内で動作するように指定されているためである。この構造体により、ＩＰｖ６ネットワークエンドポイントを指定する。進行中のＲＥＳＯＬＶＥに対しノードが使用できるかどうかを示すために使用されるフラグもある。経路フラグは、アドレスに宛てて送信されたＲＥＳＯＬＶＥが受理されたか、拒絶されたかを示す場合に使用される。さらに、そのアドレスがそばの近隣ノードのものであった場合、ノードはそのすべてのそばの近隣ノードを知っていなければならないので、疑わしいフラグがセットされる。ＡｄｄｒｅｓｓＲｅｍｏｖｅｄインジケータはデバッグ時に使用され、エントリに除去のマークを付けるだけであり、実際には除去しない。これらのインジケータは次のとおりである。
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＡＣＣＥＰＴＥＤ−０ｘ０１
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＲＥＪＥＣＴＥＤ−０ｘ０２
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＵＮＲＥＡＣＨＡＢＬＥ−０ｘ０４
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＬＯＯＰ−０ｘ０８
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ−ＴＯＯ＿ＢＵＳＹ−０ｘ１０
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＢＡＤ＿ＶＡＬＩＤＡＴＥ＿ＩＤ−０ｘ２０
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＡＤＤＲＥＳＳ＿ＲＥＭＯＶＥＤ−０ｘ８０
ＰＮＲＰ＿ＦＬＡＧＧＥＤ＿ＳＵＳＰＥＣＴ＿ＵＮＲＥＧＩＳＴＥＲＥＤ＿ＩＤ−０ｘ４０。本発明の教示により構築されたＩＰＶ６＿ＥＮＤＰＯＩＮＴ要素のデータ構造の詳細を表１８に提示した。

ＰＮＲＰ＿ＩＤ−型０ｘ００３０要素は、１２８ビットｐ２ｐＩＤと１２８ビットサービスロケーションとを連結したものである。本発明の教示により構築されたＰＮＲＰ＿ＩＤ要素のデータ構造の詳細を表１９に提示した。

ＴＡＲＧＥＴ＿ＰＮＲＰ＿ＩＤ−型０ｘ００３８は、ＲＥＳＯＬＶＥ要求またはその対応するＲＥＳＰＯＮＳＥのターゲットＩＤである。本発明の教示により構築されたＴＡＲＧＥＴ＿ＰＮＲＰ＿ＩＤ要素のデータ構造の詳細を表２０に提示した。

ＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤ−型０ｘ００３９は、妥当性確認およびオーソリティが要求されるＰＮＲＰＩＤである。本発明の教示により構築されたＶＡＬＩＤＡＴＥ＿ＰＮＲＰ＿ＩＤ要素のデータ構造の詳細を表２１に提示した。

ＦＬＡＧＳ＿ＦＩＥＬＤ−型０ｘ００４０を使用すると、コンテキスト固有の目的のために使用されるビットフィールドであるフラグを識別できる。本発明の教示により構築されたＦＬＡＧＳ＿ＦＩＥＬＤ要素のデータ構造の詳細を表２２に提示した。

ＲＥＳＯＬＶＥ＿ＣＯＮＴＲＯＬＳ−型０ｘ００４１フィールドには、ＲＥＳＯＬＶＥまたはＲＥＳＰＯＮＳＥを処理する際に使用する情報が含まれる。ＲＥＳＯＬＶＥがバックトラッキングしているか、またはＡＵＴＨＯＲＩＴＹメッセージが要求されているかを示す場合にフラグを使用する。含まれるフラグは
ＲＦ＿ＩＧＮＯＲＥ＿ＮＥＸＴ＿ＨＯＰ−０ｘ０００１、
ＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮ−０ｘ０００４、
デバッグ専用のＲＦ＿ＤＯＮＴ＿ＲＥＭＯＶＥ＿ＰＡＴＨ＿ＥＮＴＲＩＥＳ−０ｘ０００８、およびデバッグ専用のＲＦ＿ＴＲＡＣＩＮＧ＿ＯＮ−０ｘ００１０である。ＭａｘＨｏｐｓにより、ＲＥＳＯＬＶＥ完了前のホップの個数を制限する。オペレーションコードは、照合の実行方法を記述する。一致（Ｍａｔｃｈｅｓ）は、任意のコードに対して最上位１２８ビット（Ｐ２ＰＩＤ）のみであることができるか、またはＮＥＡＲＥＳＴコードについてもサービスロケーションを考慮することができる。またオペレーションコードを使用することで、照合においてＲＥＳＯＬＶＥの発信元と同じノード上で登録されているＩＤを考慮すべきか決定する。オペレーションコードには以下のものを含む。
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＮＯＮＥ−０、
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＡＮＹ＿ＰＥＥＲＮＡＭＥ−１、
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＮＥＡＲＥＳＴ＿ＰＥＥＲＮＡＭＥ−２、
ＳＥＡＲＣＨ−ＯＰＣＯＤＥ＿ＮＥＡＲＥＳＴ６４＿ＰＥＥＲＮＡＭＥ−４、
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＵＰＰＥＲ＿ＢＩＴＳ−８。Ｐｒｅｃｉｓｉｏｎにより、実際のビット数と一致する精度がＩＤ上で設定される。この値は、オペレーションコードが
ＳＥＡＲＣＨ＿ＯＰＣＯＤＥ＿ＵＰＰＥＲ＿ＢＩＴＳの場合に使用される。

理由（Ｒｅａｓｏｎ）を使用して、ＲＥＳＯＬＶＥが送信されたのは修復プロセスの一部としてなのか、キャッシュの保守のためなのか、登録の一部としてなのか、またはアプリケーション要求のためなのかを示す。理由には、ＲＥＡＳＯＮ＿ＡＰＰ＿ＲＥＱＵＥＳＴ−０、ＲＥＡＳＯＮ＿ＲＥＧＩＳＴＲＡＴＩＯＮ−１、ＲＥＡＳＯＮ＿ＣＡＣＨＥ＿ＭＡＩＮＴＥＮＡＮＣＥ−２、ＲＥＡＳＯＮ＿ＲＥＰＡＩＲ＿ＤＥＴＥＣＴＩＯＮ−３、ＲＥＡＳＯＮ＿ＳＹＮＣ＿ＲＥＱＵＥＳＴ−４、ＲＥＡＳＯＮ＿ＣＰＡ＿ＶＩＡ＿ＲＥＳＯＬＶＥ−５、ＲＥＡＳＯＮ＿ＣＰＡ＿ＶＩＡ＿ＦＬＯＯＤ−６、ＲＥＡＳＯＮ＿ＲＥＰＡＩＲ−７、およびＲＥＡＳＯＮ＿ＣＰＡ＿ＶＩＡ＿ＢＡＣＫ＿ＦＬＯＯＤ−８がある。

結果コードは、なぜＲＥＳＯＬＶＥが完了し、ＲＥＳＰＯＮＳＥに変換されたかを示す。これは、ホップカウントを超えて成功したかまたは失敗したか、適切な経路が見つからなかったか、または近隣ノードが多すぎてターゲットを見つけるのに失敗したかを示すこともできる。これらの結果コードには、ＲＥＳＵＬＴ＿ＮＯＮＥ−０、ＲＥＳＵＬＴ＿ＦＯＵＮＤ＿ＭＡＴＣＨ−１、ＲＥＳＵＬＴ＿ＭＡＸ＿ＨＯＰ＿ＬＩＭＩＴ＿ＨＩＴ−２、ＲＥＳＵＬＴ＿ＮＯ＿ＢＥＴＴＥＲ＿ＰＡＴＨ＿ＦＯＵＮＤ−３、およびＲＥＳＵＬＴ＿ＴＯＯ＿ＭＡＮＹ＿ＭＩＳＳＥＳ−４がある。要求の発信元はトランザクションＩＤを使用して、ＲＥＳＰＯＮＳＥの相関を求める。ＲＥＳＯＬＶＥ発信元は、ＴｒａｎｓＩＤ値を設定し、ＲＥＳＰＯＮＳＥを開始するノードは、ＲＥＳＰＯＮＳＥメッセージで値をそのまま返す。中間ノードで、この値を変えてはならない。本発明の教示により構築されたＲＥＳＯＬＶＥ＿ＣＯＮＴＲＯＬＳ要素のデータ構造の詳細を表２３に提示した。

ＣＡＣＨＥ＿ＬＥＶＥＬ−型０ｘ００４２要素は、ＲＥＰＡＩＲを実行するときに使用するキャッシュレベルを記述する。これは、分割キャッシュの修復を実行する際に使用される。本発明の教示により構築されたＣＡＣＨＥ＿ＬＥＶＥＬ要素のデータ構造の詳細を表２４に提示した。

ＦＬＯＯＤ＿ＣＯＮＴＲＯＬＳ−型０ｘ００４３要素には、ＦＬＯＯＤを処理する際に使用する情報が含まれる。ＦＬＯＯＤが送信された理由が唯一使用されるコードである。本発明の教示により構築されたＦＬＯＯＤ＿ＣＯＮＴＲＯＬＳ要素のデータ構造の詳細を表２５に提示した。

ＣＰＡ＿ＳＯＵＲＣＥ−型０ｘ００５８は、ＳＯＬＩＣＩＴメッセージ内の送信元ＣＰＡとして使用されるＣＰＡである。ＣＰＡは、ネットワーク送信用に符号化される。本発明の教示により構築されたＣＰＡ＿ＳＯＵＲＣＥ要素のデータ構造の詳細を表２６に提示した。

ＣＰＡ＿ＢＥＳＴ＿ＭＡＴＣＨ−型０ｘ００５９要素は、ＲＥＳＯＬＶＥまたはＲＥＳＰＯＮＳＥにおける「最良一致」として使用されるＣＰＡである。ＣＰＡは、ネットワーク送信用に符号化される。本発明の教示により構築されたＣＰＡ＿ＢＥＳＴ＿ＭＡＴＣＨ要素のデータ構造の詳細を表２７に提示した。

ＰＮＲＰ＿ＩＤ＿ＡＲＲＡＹ−型０ｘ００６０要素は、配列内に格納されているＡＤＶＥＲＴＩＳＥおよびＲＥＱＵＥＳＴメッセージのＰＮＲＰＩＤを含む。配列サイズを含む、このデータについては後述する。本発明の教示により構築されたＰＮＲＰ＿ＩＤ＿ＡＲＲＡＹ要素のデータ構造の詳細を表２８に提示した。

ＩＰＶ６＿ＥＮＤＰＯＩＮＴ＿ＡＲＲＡＹ−型０ｘ００７１は、すでに訪れたすべてのノードの配列である。フラッディングされたメッセージはさまざまなノードを訪れる。すでに訪れたノードまたは送信先となったノードはそれぞれ、この配列に入れられる。配列サイズを含むデータについては後述する。本発明の教示により構築されたＩＰＶ６＿ＥＮＤＰＯＩＮＴ＿ＡＲＲＡＹ要素のデータ構造の詳細を表２９に提示した。

ＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＡＤＤＲＥＳＳ−型０ｘ００７２要素は、ＲＥＳＯＬＶＥを送信するための代替アドレスを指定するために特に使用されるＩＰｖ６エンドポイントである。このフィールドは、ノード側ではＲＥＳＯＬＶＥを転送したくないが、他の何らかのノードが試みることができるアドレスを指定したい場合に、ＡＵＴＨＯＲＩＴＹメッセージ内で使用される。本発明の教示により構築されたＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＡＤＤＲＥＳＳ要素のデータ構造の詳細を表３０に提示した。

ＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＩＤ−型０ｘ００７３要素は、参照に使用されているＰＮＲＰＩＤを示すためにＩＰｖ６＿Ｒｅｆｅｒｒａｌ＿Ａｄｄｒｅｓｓとともに使用される。本発明の教示により構築されたＩＰＶ６＿ＲＥＦＥＲＲＡＬ＿ＩＤ要素のデータ構造の詳細を表３１に提示した。

ＣｅｒｔＣｈａｉｎ（ＣＥＲＴ＿ＣＨＡＩＮ）−型０ｘ００８０要素は、Ｗｉｎｄｏｗｓ（登録商標）ＣＡＰＩＡＰＩを使用して作成される。最初に、この連鎖を構成する認証をＣＡＰＩメモリ内認証ストア（ＣＡＰＩｉｎ−ｍｅｍｏｒｙｃｅｒｔｓｔｏｒｅ）に入れ、その後、ＰＫＣＳ７符号化認証ストア（ＰＫＣＳ７ｅｎｃｏｄｅｄｃｅｒｔｓｔｏｒｅ）としてエクスポートする。このエクスポートされたストアは、修正されることなく送信される。

ＷＣＨＡＲ−型０ｘ００８４要素は、単一のＵＮＩＣＯＤＥ文字を保持するため定義される。クラシファイアなど、ＵＮＩＣＯＤＥ配列フィールドの一部としてのみ使用される。

ＣＬＡＳＳＩＦＩＥＲ−型０ｘ００８５要素は、ピア名の基盤として使用されたＵＮＩＣＯＤＥクラシファイア文字列である。これは、ＷＣＨＡＲ要素の配列として符号化される。本発明の教示により構築されたＣＬＡＳＳＩＦＩＥＲ要素のデータ構造の詳細を表３２に提示した。

ＨＡＳＨＥＤ＿ＮＯＮＣＥ−型０ｘ００９２要素は、ＡＤＶＥＲＴＩＳＥメッセージに含まれる暗号化されたＮｏｎｃｅ値である。受信側は、Ｎｏｎｃｅを解読する鍵を持っていることが考えられる。本発明の教示により構築されたＨＡＳＨＥＤ＿ＮＯＮＣＥ要素のデータ構造の詳細を表３３に提示した。

ＮＯＮＣＥ−型０ｘ００９３要素は、ＲＥＱＵＥＳＴメッセージに含まれる解読されたＮｏｎｃｅ値である。受信側は、解読されたＮｏｎｃｅが暗号化の前に送信された値と一致することを確認することが期待される。本発明の教示により構築されたＮＯＮＣＥ要素のデータ構造の詳細を表３４に提示した。

ＳＰＬＩＴ＿ＣＯＮＴＲＯＬＳ−型０ｘ００９８要素は、長いメッセージが、単一メッセージではなく、一連のフラグメントとして送信されるときに使用される。各フラグメントには分割コントロールフィールドが含まれており、これにより受信側はメッセージを構築することができる。本発明の教示により構築されたＳＰＬＩＴ＿ＣＯＮＴＲＯＬＳ要素のデータ構造の詳細を表３５に提示した。

ＰＮＲＰ＿ＴＲＡＣＥ−型０ｘ００９９要素は、ＲＥＳＯＬＶＥメッセージとＲＥＳＰＯＮＳＥメッセージとの間でホップからホップへ伝達できるデータを保持するためデバッグ時に使用される。トレースするデータを格納するために使用される。最終バージョンのプロトコルではサポートされない場合がある。

本発明のさまざまな実施形態の前記説明は、図の説明と解説を目的として提示した。この説明は網羅的であることを意図しておらず、また本発明を開示した実施形態だけに限る意図もない。上記の教示に照らして、数多くの修正またはバリエーションが可能である。説明した実施形態は、本発明の原理とその実際の応用を最もよく理解できるように選択され、説明されており、したがって、当業者であれば、さまざまな実施形態において、考察されている特定の用途に適したさまざまな修正を加えることにより本発明を利用できるであろう。このようなすべての修正およびバリエーションは、公正で、合法的で、公平な権利を有する範囲において解釈したときに特許請求の範囲により規定されている本発明の範囲に収まる。

本発明が属するコンピュータシステム例の概要を例示するブロック図である。ピアツーピア名前解決プロトコル（ＰＮＲＰ）の機能要素を例示する簡略化したブロック図である。本発明の一態様を例示するプロトコルメッセージの流れ図である。本発明の別の態様を例示するプロトコルメッセージの流れ図である。本発明のメッセージを構築することができる本発明の拡張可能なデータ構造モデルを例示するデータ構造図である。本発明のメッセージ例の構築を例示する簡略化したデータ構造図である。

符号の説明

１００コンピューティングシステム環境
１１０コンピュータ
１２０処理ユニット
１２１システムバス
１３０システムメモリ
１３１ＲＯＭ
１３２ＲＡＭ
１３３基本入出力システム
１３４オペレーティングシステム
１３５アプリケーションプログラム
１３６プログラムモジュール
１３７プログラムデータ
１４１ハードディスクドライブ
１４４オペレーティングシステム
１４５アプリケーションプログラム
１４６プログラムモジュール
１４７プログラムデータ
１５１磁気ディスクドライブ
１５２取り外し可能な不揮発性磁気ディスク
１５５光ディスクドライブ
１５６取り外し可能な不揮発性光ディスク
１６０ユーザ入力インターフェース
１６１ポインティングデバイス
１６２キーボード
１７０アダプタ
１７１ローカルエリアネットワーク（ＬＡＮ）
１７３ワイドエリアネットワーク（ＷＡＮ）
１８０リモートコンピュータ
１８１メモリ記憶デバイス
１８５リモートアプリケーションプログラム
１９０ビデオインターフェース
１９１モニタ
１９５出力周辺インターフェース
１９６プリンタ
１９７スピーカ
２００サービス管理コンポーネント
２０２ＲＰＣサーバおよびスタブ
２０６キャッシュマネージャ
２０８プロトコルマネージャ
２１２ノードＡ
２１４ノードＢ
２１６ＳＯＬＩＣＩＴメッセージ
２１８ＡＤＶＥＲＴＩＳＥメッセージ
２２０ＲＥＱＵＥＳＴメッセージ
２２２ＡＣＫ
２２４ＦＬＯＯＤメッセージ
２２６ＡＣＫ
２２８ノードＡ
２３０ノードＢ
２３２ノードＴ
２３４ＲＥＳＯＬＶＥメッセージ
２３６ＲＥＳＯＬＶＥメッセージ
２３８ＡＵＴＨＯＲＩＴＹ
２４２ＡＵＴＨＯＲＩＴＹメッセージ
２４４ＲＥＰＯＮＳＥメッセージ
２４６ＡＣＫ
２６０基本メッセージデータ構造
２６２フィールド
２６４フィールドデータ構造
２６６型コンポーネント
２６８長さコンポーネント
２７０実際の内容またはペイロード
２７２長さ
２８０ＲＥＳＯＬＶＥメッセージ
２９４ＰＮＲＰ＿ＨＥＡＤＥＲデータ構造
２９６フィールドＩＤ
２９８長さ
３００プロトコルコンポーネント
３０２メジャーバージョンコンポーネント
３０４マイナーバージョンコンポーネント
３０６メッセージタイプコンポーネント
３０８メッセージＩＤコンポーネント
３１０フィールドデータ構造
３１２フィールドＩＤ
３１４長さコンポーネント
３１６Ｐ２ＰＩＤコンポーネント
３１８サービスロケーションコンポーネント

Claims

ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するデータ構造を格納したコンピュータ可読媒体であって、
第１のメッセージ要素が格納されている第１のメッセージフィールドと、
第２のメッセージ要素が格納されている少なくとも第２のメッセージフィールドとを備え、
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とするコンピュータ可読媒体。
メッセージ要素がそれぞれ格納されている複数のメッセージフィールドをさらに備えることを特徴とする請求項１に記載のコンピュータ可読媒体。
前記第１のメッセージフィールドに格納されている第１のメッセージ要素は、ヘッダメッセージ要素を含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードは、メッセージタイプをＲＥＳＯＬＶＥ、ＲＥＳＰＯＮＳＥ、ＳＯＬＩＣＩＴ、ＡＤＶＥＲＴＩＳＥ、ＲＥＱＵＥＳＴ、ＦＬＯＯＤ、ＩＮＱＵＩＲＥ、ＡＵＴＨＯＲＩＴＹ、ＡＣＫ、およびＲＥＰＡＩＲメッセージのうちの１つであると識別する情報を含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＲＥＳＯＬＶＥメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素は解決コントロールメッセージ要素を含み、前記ＲＥＳＯＬＶＥは、ＰＮＲＰターゲット識別メッセージ要素を含む第３のメッセージフィールド、妥当性確認ＰＮＲＰ識別メッセージ要素を含む第４のメッセージフィールド、認証ピアアドレス（ＣＰＡ）最良一致メッセージ要素を含む第５のメッセージフィールド、ＩＰＶ６エンドポイント配列メッセージ要素を含む第６のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記解決コントロールメッセージ要素の前記ペイロードは、コンテキスト固有のフラグのビットフィールド、ＲＥＳＯＬＶＥメッセージが訪れることができるノードの最大数、解決オペレーションを制御するオペレーションコード、一致する精度有効ビット数、ＲＥＳＯＬＶＥを開始する理由を説明する理由コード、応答を返す理由を説明する結果コード、およびトランザクション識別値を含むことを特徴とする請求項５に記載のコンピュータ可読媒体。
前記ターゲットＰＮＲＰ識別メッセージ要素の前記ペイロードは、ターゲットピアのピア名および広告されたサービスアドレスから導かれるサービスロケーションのハッシュを含むことを特徴とする請求項５に記載のコンピュータ可読媒体。
前記妥当性確認ＰＮＲＰ識別メッセージ要素の前記ペイロードは、妥当性確認およびオーソリティが要求されたノードのピア名ならびに妥当性確認およびオーソリティが要求されたノードの広告されたサービスアドレスから導かれるサービスロケーションのハッシュを含むことを特徴とする請求項５に記載のコンピュータ可読媒体。
前記ＣＰＡ最良一致メッセージ要素の前記ペイロードは符号化されたＣＰＡを含むことを特徴とする請求項５に記載のコンピュータ可読媒体。
前記ＩＰＶ６エンドポイント配列メッセージ要素の前記ペイロードは、配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびすでに訪れたかまたはＲＥＳＰＯＮＳＥメッセージの送信先の各ノードのアドレスの配列を含むことを特徴とする請求項５に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＲＥＳＰＯＮＳＥメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素は解決コントロールメッセージ要素を含み、前記ＲＥＳＰＯＮＳＥメッセージは、解決コントロールメッセージ要素を含む第３のメッセージフィールド、ターゲットＰＮＲＰＩＤメッセージ要素を含む第４のメッセージフィールド、ＣＰＡ最良一致メッセージ要素を含む第５のメッセージフィールド、ＩＰＶ６エンドポイント配列メッセージ要素をさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記解決コントロールメッセージ要素の前記ペイロードは、コンテキスト固有のフラグのビットフィールド、ＲＥＳＯＬＶＥメッセージが訪れることができるノードの最大数、解決オペレーションを制御するオペレーションコード、一致する精度有効ビット数、ＲＥＳＯＬＶＥを開始する理由を説明する理由コード、応答を返す理由を説明する結果コード、およびトランザクション識別値を含むことを特徴とする請求項１１に記載のコンピュータ可読媒体。
前記ターゲットＰＮＲＰ識別メッセージ要素の前記ペイロードは、ターゲットピアのピア名および広告されたサービスアドレスから導かれるサービスロケーションのハッシュを含むことを特徴とする請求項１１に記載のコンピュータ可読媒体。
前記ＣＰＡ最良一致メッセージ要素の前記ペイロードは符号化されたＣＰＡを含むことを特徴とする請求項１１に記載のコンピュータ可読媒体。
前記ＩＰＶ６エンドポイント配列メッセージ要素の前記ペイロードは、配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびすでに訪れたかまたはＲＥＳＰＯＮＳＥメッセージの送信先の各ノードのアドレスの配列を含むことを特徴とする請求項１１に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＳＯＬＩＣＩＴメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はＣＰＡ送信元メッセージ要素を含み、前記ＳＯＬＩＣＩＴメッセージは、ハッシュされたｎｏｎｃｅメッセージ要素を含む第３のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記ＣＰＡ送信元メッセージ要素の前記ペイロードは符号化された送信元ＣＰＡを含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
前記ハッシュされたｎｏｎｃｅメッセージ要素の前記ペイロードは符号化されたｎｏｎｃｅ値を含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＡＤＶＥＲＴＩＳＥメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はＰＮＲＰヘッダ肯定応答メッセージ要素を含み、前記ＡＤＶＥＲＴＩＳＥメッセージは、ＰＮＲＰＩＤ配列メッセージ要素を含む第３のメッセージフィールド、およびハッシュされたｎｏｎｃｅメッセージ要素を含む第４のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記ＰＮＲＰヘッダ肯定応答メッセージ要素の前記ペイロードは肯定応答されているメッセージのメッセージ識別を含むことを特徴とする請求項１９に記載のコンピュータ可読媒体。
前記ＰＮＲＰＩＤ配列メッセージ要素の前記ペイロードは、ＰＮＲＰＩＤ配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびＰＮＲＰＩＤの配列を含むことを特徴とする請求項１９に記載のコンピュータ可読媒体。
前記ハッシュされたｎｏｎｃｅメッセージ要素の前記ペイロードは符号化されたｎｏｎｃｅ値を含むことを特徴とする請求項１９に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＲＥＱＵＥＳＴメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はｎｏｎｃｅメッセージ要素を含み、前記ＲＥＱＵＥＳＴメッセージは、ＰＮＲＰＩＤ配列メッセージ要素を含む第３のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記ｎｏｎｃｅメッセージ要素の前記ペイロードは暗号解読されたｎｏｎｃｅ値を含むことを特徴とする請求項２３に記載のコンピュータ可読媒体。
前記ＰＮＲＰＩＤ配列メッセージ要素の前記ペイロードは、ＰＮＲＰＩＤ配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびＰＮＲＰＩＤの配列を含むことを特徴とする請求項２３に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＦＬＯＯＤメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はフラッドコントロールメッセージ要素を含み、前記ＦＬＯＯＤメッセージは、ＣＰＡ最良一致メッセージ要素を含む第３のメッセージフィールド、およびＩＰＶ６エンドポイント配列メッセージ要素を含む第４のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記フラッドコントロールメッセージ要素の前記ペイロードはコンテキスト固有のフラグに対するビットフィールドおよびＦＬＯＯＤメッセージを開始する理由を説明する理由コードを含むことを特徴とする請求項２６に記載のコンピュータ可読媒体。
前記ＣＰＡ最良一致メッセージ要素の前記ペイロードは符号化されたＣＰＡを含むことを特徴とする請求項２６に記載のコンピュータ可読媒体。
前記ＩＰＶ６エンドポイント配列メッセージ要素の前記ペイロードは、配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびすでに訪れたかまたはＲＥＳＰＯＮＳＥメッセージの送信先の各ノードのアドレスの配列を含むことを特徴とする請求項２６に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＩＮＱＵＩＲＥメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はフラグフィールドメッセージ要素を含み、前記ＩＮＱＵＩＲＥメッセージは、妥当性確認ＰＮＲＰ識別メッセージ要素を含む第３のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記フラグフィールドメッセージ要素の前記ペイロードはコンテキスト固有のフラグのビットフィールドを含むことを特徴とする請求項３０に記載のコンピュータ可読媒体。
前記妥当性確認ＰＮＲＰ識別メッセージ要素の前記ペイロードは、妥当性確認およびオーソリティが要求されたノードのピア名ならびに妥当性確認およびオーソリティが要求されたノードの広告されたサービスアドレスから導かれたサービスロケーションのハッシュを含むことを特徴とする請求項３０に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＡＵＴＨＯＲＩＴＹメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はＰＮＲＰヘッダ肯定応答メッセージ要素を含み、前記ＡＵＴＨＯＲＩＴＹメッセージは、分割コントロールメッセージ要素を含む第３のメッセージフィールド、フラグフィールドメッセージ要素を含む第４のメッセージフィールド、妥当性確認ＰＮＲＰＩＤメッセージ要素を含む第５のメッセージフィールド、認証連鎖メッセージ要素を含む第６のメッセージフィールド、ＩＰＶ６参照アドレスメッセージ要素を含む第７のメッセージフィールド、ＩＰＶ６参照識別メッセージ要素を含む第８のメッセージフィールド、およびクラシファイアメッセージ要素を含む第９のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記ＰＮＲＰヘッダ肯定応答メッセージ要素の前記ペイロードは肯定応答されているメッセージのメッセージ識別を含むことを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記分割コントロールメッセージ要素の前記ペイロードはフラグメント化のサイズおよび前記フラグメント化のオフセットの情報を含むことを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記フラグフィールドメッセージ要素の前記ペイロードはコンテキスト固有のフラグのビットフィールドを含むことを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記妥当性確認ＰＮＲＰ識別メッセージ要素の前記ペイロードは、妥当性確認およびオーソリティが要求されたノードのピア名ならびに妥当性確認およびオーソリティが要求されたノードの広告されたサービスアドレスから導かれたサービスロケーションのハッシュを含むことを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記認証連鎖メッセージ要素の前記ペイロードはＰＫＣＳ７符号化認証ストアを含むことを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記ＩＰＶ６参照アドレスメッセージ要素の前記ペイロードはノードエンドポイントの経路フラグ、ＩＰプロトコル番号、ＩＰＶ６ポート、および代替ノードのアドレスとしてのＩＰＶ６アドレスを含むことを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記ＩＰＶ６参照識別メッセージ要素の前記ペイロードは、参照先のノードに対するピア名およびサービスロケーションのハッシュを含むことを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記クラシファイアメッセージ要素の前記ペイロードは、ピア名の基盤として使用されたＵｎｉｃｏｄｅのクラシファイア文字列を含み、前記文字列はアドレス配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびＵｎｉｃｏｄｅ文字の配列を含むＷＣＨＡＲ要素の配列として符号化されることを特徴とする請求項３３に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＡＣＫメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はＰＮＲＰヘッダ肯定応答メッセージ要素を含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記ＰＮＲＰヘッダ肯定応答メッセージ要素の前記ペイロードは肯定応答されているメッセージのメッセージ識別を含むことを特徴とする請求項４２に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードはメッセージタイプをＲＥＰＡＩＲメッセージであると識別する情報を含み、前記第２のフィールドに格納されている前記第２のメッセージ要素はターゲットＰＮＲＰ識別メッセージ要素を含み、前記ＲＥＰＡＩＲメッセージは、キャッシュレベルメッセージ要素を含む第３のメッセージフィールド、およびＩＰＶ６エンドポイントメッセージ要素を含む第４のメッセージフィールドをさらに含むことを特徴とする請求項３に記載のコンピュータ可読媒体。
前記ターゲットＰＮＲＰ識別メッセージ要素の前記ペイロードは、ターゲットピアのピア名および広告されたサービスアドレスから導かれるサービスロケーションのハッシュを含むことを特徴とする請求項４４に記載のコンピュータ可読媒体。
前記キャッシュレベルメッセージ要素の前記ペイロードは修復を実行するときに使用するキャッシュレベルを識別するキャッシュレベル番号を含むことを特徴とする請求項４４に記載のコンピュータ可読媒体。
前記ヘッダメッセージ要素の前記ペイロードは、特定のメッセージへの応答を追跡できるようにする前記特定のメッセージを識別する情報をさらに含むことを特徴とする請求項４に記載のコンピュータ可読媒体。
前記長さフィールドは、前記フィールド識別フィールドの長さ、前記長さフィールド、およびペイロードを含む、前記メッセージ要素の長さを識別する情報を含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＲＥＳＯＬＶＥメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
解決コントロールメッセージ要素を有する第２のメッセージフィールドと、
ＰＮＲＰターゲット識別メッセージ要素を有する第３のメッセージフィールドと、
妥当性確認ＰＮＲＰ識別メッセージ要素を有する第４のメッセージフィールドと、
認証ピアアドレス（ＣＰＡ）最良一致メッセージ要素を有する第５のメッセージフィールドと、
ＩＰＶ６エンドポイント配列メッセージ要素を有する第６のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項４９に記載のコンピュータ可読媒体。
前記解決コントロールメッセージ要素の前記ペイロードは、コンテキスト固有のフラグのビットフィールド、ＲＥＳＯＬＶＥメッセージが訪れることができるノードの最大数、解決オペレーションを制御するオペレーションコード、一致する精度有効ビット数、ＲＥＳＯＬＶＥを開始する理由を説明する理由コード、応答を返す理由を説明する結果コード、およびトランザクション識別値を含むことを特徴とする請求項５０に記載のコンピュータ可読媒体。
前記ターゲットＰＮＲＰ識別メッセージ要素の前記ペイロードは、ターゲットピアのピア名および広告されたサービスアドレスから導かれるサービスロケーションのハッシュを含むことを特徴とする請求項５０に記載のコンピュータ可読媒体。
前記妥当性確認ＰＮＲＰ識別メッセージ要素の前記ペイロードは、妥当性確認およびオーソリティが要求されたノードのピア名ならびに妥当性確認およびオーソリティが要求されたノードの広告されたサービスアドレスから導かれたサービスロケーションのハッシュを含むことを特徴とする請求項５０に記載のコンピュータ可読媒体。
前記ＣＰＡ最良一致メッセージ要素の前記ペイロードは符号化されたＣＰＡを含むことを特徴とする請求項５０に記載のコンピュータ可読媒体。
前記ＩＰＶ６エンドポイント配列メッセージ要素の前記ペイロードは、配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびすでに訪れたかまたはＲＥＳＰＯＮＳＥメッセージの送信先の各ノードのアドレスの配列を含むことを特徴とする請求項５０に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＲＥＳＰＯＮＳＥメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
解決コントロールメッセージ要素を有する第２のメッセージフィールドと、
解決コントロールメッセージ要素を有する第３のメッセージフィールドと、
ターゲットＰＮＲＰＩＤメッセージ要素を有する第４のメッセージフィールドと、
認証ピアアドレス（ＣＰＡ）最良一致メッセージ要素を有する第５のメッセージフィールドと、
ＩＰＶ６エンドポイント配列メッセージ要素を有する第６のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項５６に記載のコンピュータ可読媒体。
前記解決コントロールメッセージ要素の前記ペイロードは、コンテキスト固有のフラグのビットフィールド、ＲＥＳＯＬＶＥメッセージが訪れることができるノードの最大数、解決オペレーションを制御するオペレーションコード、一致する精度有効ビット数、ＲＥＳＯＬＶＥを開始する理由を説明する理由コード、応答を返す理由を説明する結果コード、およびトランザクション識別値を含むことを特徴とする請求項５７に記載のコンピュータ可読媒体。
前記ターゲットＰＮＲＰ識別メッセージ要素の前記ペイロードは、ターゲットピアのピア名および広告されたサービスアドレスから導かれるサービスロケーションのハッシュを含むことを特徴とする請求項５７に記載のコンピュータ可読媒体。
前記ＣＰＡ最良一致メッセージ要素の前記ペイロードは符号化されたＣＰＡを含むことを特徴とする請求項５７に記載のコンピュータ可読媒体。
前記ＩＰＶ６エンドポイント配列メッセージ要素の前記ペイロードは、配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびすでに訪れたかまたはＲＥＳＰＯＮＳＥメッセージの送信先の各ノードのアドレスの配列を含むことを特徴とする請求項５７に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＳＯＬＩＣＩＴメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
ＣＰＡ送信元メッセージ要素を有する第２のメッセージフィールドと、
ハッシュされたｎｏｎｃｅメッセージ要素を有する第３のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項６２に記載のコンピュータ可読媒体。
前記ＣＰＡ送信元メッセージ要素の前記ペイロードは符号化された送信元ＣＰＡを含むことを特徴とする請求項６３に記載のコンピュータ可読媒体。
前記ハッシュされたｎｏｎｃｅメッセージ要素の前記ペイロードは符号化されたｎｏｎｃｅ値を含むことを特徴とする請求項６３に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＡＤＶＥＲＴＩＳＥメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
ＰＮＲＰヘッダ肯定応答メッセージ要素を有する第２のメッセージフィールドと、
ＰＮＲＰＩＤ配列メッセージ要素を有する第３のメッセージフィールドと、
ハッシュされたｎｏｎｃｅメッセージ要素を有する第４のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項６６に記載のコンピュータ可読媒体。
前記ＰＮＲＰヘッダ肯定応答メッセージ要素の前記ペイロードは肯定応答されているメッセージのメッセージ識別を含むことを特徴とする請求項６７に記載のコンピュータ可読媒体。
前記ＰＮＲＰＩＤ配列メッセージ要素の前記ペイロードは、ＰＮＲＰＩＤ配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびＰＮＲＰＩＤの配列を含むことを特徴とする請求項６７に記載のコンピュータ可読媒体。
前記ハッシュされたｎｏｎｃｅメッセージ要素の前記ペイロードは符号化されたｎｏｎｃｅ値を含むことを特徴とする請求項６７に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＲＥＱＵＥＳＴメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
ｎｏｎｃｅメッセージ要素を有する第２のメッセージフィールドと、
ＰＮＲＰＩＤ配列メッセージ要素を有する第３のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項７１に記載のコンピュータ可読媒体。
前記ｎｏｎｃｅメッセージ要素の前記ペイロードは暗号解読されたｎｏｎｃｅ値を含むことを特徴とする請求項７２に記載のコンピュータ可読媒体。
前記ＰＮＲＰＩＤ配列メッセージ要素の前記ペイロードは、ＰＮＲＰＩＤ配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびＰＮＲＰＩＤの配列を含むことを特徴とする請求項７２に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＦＬＯＯＤメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
フラッドコントロールメッセージ要素を有する第２のメッセージフィールドと、
ＣＰＡ最良一致メッセージ要素を有する第３のメッセージフィールドと、
ＩＰＶ６エンドポイント配列メッセージ要素を有する第４のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項７５に記載のコンピュータ可読媒体。
前記フラッドコントロールメッセージ要素の前記ペイロードはコンテキスト固有のフラグに対するビットフィールドおよびＦＬＯＯＤメッセージを開始する理由を説明する理由コードを含むことを特徴とする請求項７６に記載のコンピュータ可読媒体。
前記ＣＰＡ最良一致メッセージ要素の前記ペイロードは符号化されたＣＰＡを含むことを特徴とする請求項７６に記載のコンピュータ可読媒体。
前記ＩＰＶ６エンドポイント配列メッセージ要素の前記ペイロードは、配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびすでに訪れたかまたはＲＥＳＰＯＮＳＥメッセージの送信先の各ノードのアドレスの配列を含むことを特徴とする請求項７６に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＩＮＱＵＩＲＥメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
フラグフィールドメッセージ要素を有する第２のメッセージフィールドと、
妥当性確認ＰＮＲＰ識別メッセージ要素を有する第３のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項８０に記載のコンピュータ可読媒体。
前記フラグフィールドメッセージ要素の前記ペイロードはコンテキスト固有のフラグのビットフィールドを含むことを特徴とする請求項８１に記載のコンピュータ可読媒体。
前記妥当性確認ＰＮＲＰ識別メッセージ要素の前記ペイロードは、妥当性確認およびオーソリティが要求されたノードのピア名ならびに妥当性確認およびオーソリティが要求されたノードの広告されたサービスアドレスから導かれたサービスロケーションのハッシュを含むことを特徴とする請求項８１に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＲＥＳＯＬＶＥメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
ＰＮＲＰヘッダ肯定応答メッセージ要素を有する第２のメッセージフィールドと、
分割コントロールメッセージ要素を有する第３のメッセージフィールドと、
フラグフィールドメッセージ要素を有する第４のメッセージフィールドと、
妥当性確認ＰＮＲＰＩＤメッセージ要素を有する第５のメッセージフィールドと、
認証連鎖メッセージ要素を有する第６のメッセージフィールドと、
ＩＰＶ６参照アドレスメッセージ要素を有する第７のメッセージフィールドと、
ＩＰＶ６参照識別メッセージ要素を有する第８のメッセージフィールドと、
クラシファイアメッセージ要素を有する第９のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項８４に記載のコンピュータ可読媒体。
前記ＰＮＲＰヘッダ肯定応答メッセージ要素の前記ペイロードは肯定応答されているメッセージのメッセージ識別を含むことを特徴とする請求項８５に記載のコンピュータ可読媒体。
前記分割コントロールメッセージ要素の前記ペイロードはフラグメント化のサイズおよび前記フラグメント化のオフセットの情報を含むことを特徴とする請求項８５に記載のコンピュータ可読媒体。
前記フラグフィールドメッセージ要素の前記ペイロードはコンテキスト固有のフラグのビットフィールドを含むことを特徴とする請求項８５に記載のコンピュータ可読媒体。
前記妥当性確認ＰＮＲＰ識別メッセージ要素の前記ペイロードは、妥当性確認およびオーソリティが要求されたノードのピア名ならびに妥当性確認およびオーソリティが要求されたノードの広告されたサービスアドレスから導かれたサービスロケーションのハッシュを含むことを特徴とする請求項８５に記載のコンピュータ可読媒体。
前記認証連鎖メッセージ要素の前記ペイロードはＰＫＣＳ７符号化認証ストアを含むことを特徴とする請求項８５に記載のコンピュータ可読媒体。
前記ＩＰＶ６参照アドレスメッセージ要素の前記ペイロードはノードエンドポイントの経路フラグ、ＩＰプロトコル番号、ＩＰＶ６ポート、および代替ノードのアドレスとしてのＩＰＶ６アドレスを含むことを特徴とする請求項８５に記載のコンピュータ可読媒体。
前記ＩＰＶ６参照識別メッセージ要素の前記ペイロードは、参照先のノードに対するピア名およびサービスロケーションのハッシュを含むことを特徴とする請求項８５に記載のコンピュータ可読媒体。
前記クラシファイアメッセージ要素の前記ペイロードは、ピア名の基盤として使用されたＵｎｉｃｏｄｅのクラシファイア文字列を含み、前記文字列はアドレス配列内のエントリの個数、前記配列の全長、それぞれの配列エントリの型の識別子、各配列要素の長さ、およびＵｎｉｃｏｄｅ文字の配列を含むＷＣＨＡＲ要素の配列として符号化されることを特徴とする請求項８５に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＡＣＫメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
ＰＮＲＰヘッダ肯定応答メッセージ要素を有する第２のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項９４に記載のコンピュータ可読媒体。
前記ＰＮＲＰヘッダ肯定応答メッセージ要素の前記ペイロードは肯定応答されているメッセージのメッセージ識別を含むことを特徴とする請求項９５に記載のコンピュータ可読媒体。
ピアツーピア名前解決プロトコル（ＰＮＲＰ）で使用するＲＥＰＡＩＲメッセージデータ構造を格納したコンピュータ可読媒体であって、
ＰＮＲＰヘッダメッセージ要素を有する第１のメッセージフィールドと、
ターゲットＰＮＲＰ識別メッセージ要素を有する第２のメッセージフィールドと、
キャッシュレベルメッセージ要素を有する第３のメッセージフィールドと、
ＩＰＶ６エンドポイントメッセージ要素を有する第４のメッセージフィールドとを含むことを特徴とするコンピュータ可読媒体。
各メッセージ要素はフィールド識別フィールド、長さフィールド、およびペイロードを含むメッセージ要素データ構造を含むことを特徴とする請求項９７に記載のコンピュータ可読媒体。
前記ターゲットＰＮＲＰ識別メッセージ要素の前記ペイロードは、ターゲットピアのピア名および広告されたサービスアドレスから導かれるサービスロケーションのハッシュを含むことを特徴とする請求項９８に記載のコンピュータ可読媒体。
前記キャッシュレベルメッセージ要素の前記ペイロードは修復を実行するときに使用するキャッシュレベルを識別するキャッシュレベル番号を含むことを特徴とする請求項９８に記載のコンピュータ可読媒体。