(57)【要約】【課題】ピアツーピアメッセージングアプリケーションを構築するためのＡＰＩを提供する。【解決手段】方法およびシステムは、サービス指向フレームワーク、特にサービス指向メッセージングシステムの上に実装するためのマルチキャストプログラミングモデルをサポートするためのＡＰＩセットである。【選択図】図１
2006294009.tif 000002
【特許請求の範囲】
【請求項１】
ピアネットワーキングプロトコルの実装を有するピアネットワーキングプロトコルを介して相互運用するコンピューティング装置のネットワークの一部になるように構成されたピアネットワーキング対応コンピュータにおける、１組の装置サービスを実施するソフトウェアプログラムのアプリケーションプログラミングインタフェースであって、
前記ピアネットワーク上の他のコンピューティング装置に広告するサービスの最大数の要求を処理するステップと、
メッセージが前記ピアネットワーク上の追加のコンピューティング装置に伝搬されるべきかどうかを判定する旨の要求を処理するステップと、
前記ピアネットワーク上のコンピューティング装置との連絡に使用されるポート番号の要求を処理するステップと、
前記ピアネットワーク上のコンピューティング装置との連絡に使用されるトランスポート方法の要求を処理するステップと、
使用すべきリゾルバに関する要求を処理するステップと
を備えることを特徴とするアプリケーションプログラミングインタフェース。
【請求項２】
前記リゾルバはｐｎｒｐを使用してメッシュＩＤをネットワークアドレスに変換することを特徴とする請求項１に記載のアプリケーションプログラミングインタフェース。
【請求項３】
前記ピアネットワーク上の他のコンピューティング装置に広告する前記サービスの最大数の設定を許可するステップをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラミングインタフェース。
【請求項４】
メッセージが前記ピアネットワーク上の追加のコンピューティング装置に伝搬されるべきであるかどうかを判定するフィルタの設定を許可するステップをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラミングインタフェース。
【請求項５】
前記ピアネットワーク上のコンピューティング装置との連絡に使用される前記ポート番号の設定を許可するステップをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラミングインタフェース。
【請求項６】
前記ピアネットワーク上のコンピューティング装置との連絡に使用される前記トランスポート方法の設定を許可するステップをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラミングインタフェース。
【請求項７】
使用すべき前記リゾルバの設定を許可するステップをさらに備えることを特徴とする請求項１に記載のアプリケーションプログラミングインタフェース。
【請求項８】
１組の装置サービスを実施するソフトウェアプログラムのアプリケーションプログラミングインタフェースを提供する、ピアネットワーキングプロトコルの実装を有するピアネットワーキングプロトコルを介して相互運用するコンピューティング装置のネットワークの一部になるように構成されたピアネットワーキング対応コンピュータで使用するためのコンピュータ実行可能命令を有するコンピュータ読み取り可能な記録媒体であって、
前記ピアネットワーク上の他のコンピューティング装置に広告するサービスの最大数の要求を処理するコンピュータ実行可能命令と、
メッセージが前記ピアネットワーク上の追加のコンピューティング装置に伝搬されるべきかどうかを判定する旨の要求を処理するコンピュータ実行可能命令と、
前記ピアネットワーク上のコンピューティング装置との連絡に使用されるポート番号の要求を処理するコンピュータ実行可能命令と、
前記ピアネットワーク上のコンピューティング装置との連絡に使用されるトランスポート方法の要求を処理するコンピュータ実行可能命令と、
どのリゾルバを使用するかに関する要求を処理するコンピュータ実行可能命令と
を備えたことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項９】
前記リゾルバはｐｎｒｐを使用してメッシュＩＤをネットワークアドレスに変換することを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１０】
前記ピアネットワーク上の他のコンピューティング装置に広告する前記サービスの最大数の設定を許可するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１１】
メッセージが前記ピアネットワーク上の追加のコンピューティング装置に伝搬されるべきであるかどうかを判定するフィルタの設定を許可するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１２】
前記ピアネットワーク上のコンピューティング装置との連絡に使用される前記ポート番号の設定を許可するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１３】
前記ピアネットワーク上のコンピューティング装置との連絡に使用される前記トランスポート方法の設定を許可するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１４】
前記使用すべきリゾルバの設定を許可するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項８に記載のコンピュータ読み取り可能な記録媒体。
【請求項１５】
ビデオ画像を生成することができる表示ユニットと、
入力装置と、
前記表示ユニットおよび前記入力装置に動作可能に結合され、プロセッサ、および前記プロセッサに動作可能に結合されるメモリを含む処理装置と、
ネットワークおよび前記処理装置に接続されているネットワークインタフェースとを備え、
前記処理装置は、ピアネットワーキングプロトコルの実装を有するピアネットワーキングプロトコルを介して相互運用するコンピューティング装置のネットワークの一部になるように構成されるピアネットワーキング対応コンピュータにおいて、
前記ピアネットワーク上の他のコンピューティング装置に広告するサービスの最大数の要求を処理するステップと、
メッセージが前記ピアネットワーク上の追加のコンピューティング装置に伝搬されるべきかどうかを判定する旨の要求を処理するステップと、
前記ピアネットワーク上のコンピューティング装置との連絡に使用されるポート番号の要求を処理するステップと、
前記ピアネットワーク上のコンピューティング装置との連絡に使用されるトランスポート方法の要求を処理するステップと、
ｐｎｒｐを使用してメッシュＩＤをネットワークアドレスに変換する、使用すべきリゾルバに関する要求を処理するステップと、
を含む１組の装置サービスを実施するソフトウェアプログラムのアプリケーションプログラミングインタフェースを提供するようにプログラミングされている
ことを特徴とするコンピューティング装置。
【請求項１６】
前記ピアネットワーク上の他のコンピューティング装置に広告する前記サービスの最大数の設定を許可するようプログラミングされている処理装置をさらに備えたことを特徴とする請求項１５に記載のコンピューティング装置。
【請求項１７】
メッセージが前記ピアネットワーク上の追加のコンピューティング装置に伝搬されるべきであるかどうかを判定するフィルタの設定を許可するようプログラミングされている処理装置をさらに備えたことを特徴とする請求項１５に記載のコンピューティング装置。
【請求項１８】
前記ピアネットワーク上のコンピューティング装置との連絡に使用される前記ポート番号の設定を許可するようプログラミングされている処理装置をさらに備えたことを特徴とする請求項１５に記載のコンピューティング装置。
【請求項１９】
前記ピアネットワーク上のコンピューティング装置との連絡に使用される前記トランスポート方法の設定を許可するようプログラミングされている処理装置をさらに備えたことを特徴とする請求項１５に記載のコンピューティング装置。
【請求項２０】
前記使用すべきリゾルバの設定を許可するようプログラミングされている処理装置をさらに備えたことを特徴とする請求項１５に記載のコンピューティング装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピアツーピアメッセージングアプリケーションを構築するためのＡＰＩに関する。
【背景技術】
【０００２】
インターネットにおけるグループ通信技術によって、共通の興味を有するユーザは、提携し、ファイルを共有し、チャットし合い、プレゼンテーションおよびグループ会議のために音声およびビデオをマルチキャストし、マルチプレーヤゲームに加わることができる。実際に、随時グループを形成できるということは、共通の興味を有するユーザが一般のインターネット人口から分離され得る仮想領域またはグループに集まることができるようにするのにかなりの利点を示すため、そのように趣味の合う個人の間における提携の際に有用な討論が容易になる。しかし、現在、ほとんどのグループ通信および形成は、個人がグループに加わり、参加するために接続する大きい中央サーバに、または中央サーバを介してすべての通信が流れる、サーバ中心の環境で行われる。
【０００３】
ピアツーピア技術によって、ユーザは、サーバベースのインターネット通信の制約とは無関係に、サーバなしの環境で互いに連絡することができる。通信はネットワーク内のピア間で直接行われるため、ピアツーピアベースのシステムでは、ユーザの匿名性およびプライバシを維持することができる。しかし、個人の通信およびファイルの共有は、ピアツーピアネットワークにおいて比較的うまく確立されるが、グループのピアツーピア環境における確立、発見、参加、維持、および情報の共有は、うまく確立されない。しかし、個人は、サーバ中心環境におけるこうしたグループ技術によって提供される恩恵に慣れてきた。
【０００４】
いくつかの文献に上述のような従来の技術に関連した技術内容が開示されている（例えば、特許文献１、２参照）。
【０００５】
【特許文献１】米国特許出願公開第２００４／０１１１４３９号明細書
【特許文献２】米国特許出願公開第２００５／０００４９１６号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
【０００７】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、通信を容易に効率よく実施することができる、ピアツーピアメッセージングアプリケーションを構築するためのＡＰＩを提供することにある。
【課題を解決するための手段】
【０００８】
方法およびシステムは、サービス指向フレームワーク、特にサービス指向メッセージングシステムの上に実装するためのマルチキャストプログラミングモデルをサポートするためのＡＰＩセットである。これは、ＩＰマルチキャストインフラストラクチャの必要なしにアプリケーション層マルチキャスト機能を提供する。システムによって、サービス指向アプリケーションは、マルチキャスト通信を容易に、効率よく実施することができる。さらに、マルチキャスト方法およびシステムは、マルチキャストプロセスを向上させ得るピアツーピアアプリケーションのメッシュ技術を作成し、維持する管理プロセスを提供する。これらのプロセスの一部には、チャネルの監視および配信サービス、フラッディングおよびフィルタリングサービス、広告サービス、接続メンテナンスサービス、ドメイン間のインターネット全体のメッシュ機能（cross domain Internet wide mesh capability）、およびサーバなしのピア解決サービスなどがある。
【発明を実施するための最良の形態】
【０００９】
以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。
【００１０】
以下の本文では、異なる多数の実施形態の詳細な説明を示しているが、説明の法的範囲は、特許請求の範囲の用語によって定義されることを理解されたい。考え得るすべての実施形態を記述するのは現実的ではなく、そうでないとしても不可能であるため、詳細な説明は、例示的なものにすぎないと解釈されるべきであり、考え得るすべての実施形態を記述してはいない。現在の技術または本特許の出願日以降に開発された技術を使用して多数の代替実施形態を実施することができ、それらは依然として特許請求の範囲内に含まれる。
【００１１】
また、「本明細書で使用される場合、「  」という用語は、本明細書では〜を意味するよう定義される」という文章または同様の文章を使用して本特許において用語が明示的に定義されていない限り、その一般のまたは普通の意味を越えて明示的または暗黙的にその用語の意味を制限する意図はなく、こうした用語は、（特許請求の範囲の言語以外の）本特許の任意のセクションにおける任意の記述に基づく範囲に限定されると解釈されるべきではないことも理解されたい。特許請求の範囲に記載されている任意の用語が本特許で単一の意味と一致するように言及される限り、これは単に読者を混乱させないようにするために、明瞭にするためにしたことにすぎず、こうしたクレーム用語は、暗黙的にまたは別の方法で、その単一の意味に限定されることを意図するものではない。最後に、クレーム要素が「手段」という単語および機能を任意の構造の記述なしに述べることによって定義されていない限り、任意のクレーム要素の範囲は、米国特許法第１１２条第６段落の適用に基づくものと解釈されるものではない。
【００１２】
図１は、本実施形態の方法および装置のブロックのシステムを実施することができる適したコンピューティングシステム環境１００の一例を示している。コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、特許請求の範囲の方法および装置の使用または機能の範囲に関する限定を示唆するものではない。また、コンピューティング環境１００を、動作環境１００の例に示した構成要素のいずれか１つの構成要素、または構成要素の組合せに関連する任意の依存性または必要条件を有しているものと解釈すべきではない。
【００１３】
本実施形態の方法および装置のブロックは、他の多くの汎用または専用コンピューティングシステム環境または構成で動作可能である。本実施形態の方法または装置との使用に適した周知のコンピューティングシステム、環境、および／または構成の例には、それだけには限定されないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記の任意のシステムまたは装置を含む分散コンピューティング環境などがある。
【００１４】
本実施形態の方法および装置のブロックは、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。また、本方法および装置は、タスクが通信ネットワークによってリンクされているリモート処理装置によって実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートのコンピュータ記憶媒体に置くことができる。
【００１５】
図１を参照すると、本実施形態の方法および装置のブロックを実施するシステムの例は、汎用コンピューティング装置をコンピュータ１１０の形で含んでいる。コンピュータ１１０の構成要素は、それだけには限定されないが、プロセッサ１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素をプロセッサ１２０に結合するシステムバス１２１を含み得る。システムバス１２１は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。こうしたアーキテクチャには、それだけには限定されないが一例として、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子装置規格化協会（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られている周辺部品相互接続（ＰＣＩ）バスなどがある。
【００１６】
コンピュータ１１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる使用可能な任意の媒体とすることができ、揮発性および不揮発性媒体、リムーバブルおよびノンリムーバブル媒体を含む。コンピュータ可読媒体は、それだけには限定されないが一例として、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性および不揮発性のリムーバブルおよびノンリムーバブル媒体がある。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または所望の情報の格納に使用でき、コンピュータ１１０からアクセスできる他の任意の媒体などがある。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の移送機構などの変調されたデータ信号に組み込む。これには任意の情報配送媒体がある。「変調されたデータ信号」という用語は、信号に情報を符号化するように１つまたは複数のその特性が設定または変更された信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された接続などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体がある。また、上記のどんな組合せでもコンピュータ可読媒体の範囲内に含まれるものとする。
【００１７】
システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、例えば起動中など、コンピュータ１１０内の要素間での情報の転送を助ける基本ルーチンを含み、一般にＲＯＭ１３１に格納されている。ＲＡＭ１３２は一般に、プロセッサ１２０から直接アクセス可能な、および／またはプロセッサ１２０が現在処理しているデータおよび／またはプログラムモジュールを含む。図１は、それだけには限定されないが一例として、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。
【００１８】
コンピュータ１１０は、他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体を含んでいてもよい。一例にすぎないが、図１は、ノンリムーバブル不揮発性磁気媒体から読み取り、あるいはそこに書き込むハードディスクドライブ１４０、リムーバブル不揮発性磁気ディスク１５２から読み取り、あるいはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光媒体など、リムーバブル不揮発性光ディスク１５６から読み取り、あるいはそこに書き込む光ディスクドライブ１５５を示している。動作環境の例で使用できる他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ１４１は一般に、インタフェース１４０などのノンリムーバブルメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インタフェース１５０などのリムーバブルメモリインタフェースによってシステムバス１２１に接続される。
【００１９】
上述し、図１に示したドライブおよびその関連のコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ１１０の他のデータの記憶域を提供する。図１では例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は少なくとも異なるコピーであることを示すために、ここではそれらに異なる番号を付している。ユーザは、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティング装置１６１などの入力装置を介してコマンドおよび情報をコンピュータ２０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらおよび他の入力装置は、しばしばシステムバスに結合されているユーザ入力インタフェース１６０を介してプロセッサ１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインタフェースおよびバス構造で接続してもよい。モニタ１９１または他のタイプの表示装置もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、出力周辺インタフェース１９０を介して接続できるスピーカ１９７、プリンタ１９６などの他の周辺出力装置を含むこともできる。
【００２０】
コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にコンピュータ１１０に関連して上述した多くまたはすべての要素を含むが、図１にはメモリ記憶装置１８１のみを示している。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含んでいてもよい。こうしたネットワーキング環境は、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。
【００２１】
ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は一般に、モデム１７２、またはインターネットなどＷＡＮ１７３を介して通信を確立する他の手段を含む。モデム１７２は、内蔵のものでも外付けのものでもよく、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク式環境では、コンピュータ１１０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図１は、それだけには限定されないが一例として、リモートアプリケーションプログラム１８５をメモリ装置１８１上に存在するものとして示している。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。
【００２２】
図２は、特許請求の範囲の方法およびシステムの一態様を説明するために使用される、国際標準化機構（「ＩＳＯ」）によって開発された開放型システム間相互接続（「ＯＳＩ」）モデルを示している。ＯＳＩとは、通信ネットワークにおける任意の２点間でメッセージがどのように送信されるかについての標準的な説明である。
【００２３】
ＯＳＩモデルによれば、通信ネットワークにおける２つの端点間の通信のプロセスはいくつかの層に分けられ、各層はそれ自体の組の特別な関連の機能を追加する。通信するコンピュータは、これら７つの層の機能を備え得る。ユーザ間で所与のメッセージを通信する際、そのコンピュータにおいて、一端で各層を通過し、層を下降するデータの流れがあり、他端では、メッセージが到着すると、受信側コンピュータにおいて層を上昇し、最終的にエンドユーザまたはプログラムに到達するもう１つのデータの流れがある。これら７つの層の機能を提供する実際のプログラミングおよびハードウェアは、通常、コンピュータオペレーティングシステム、アプリケーション、伝送制御プロトコル（「ＴＣＰ」）／インターネットプロトコル（「ＩＰ」）または代替のトランスポートおよびネットワークプロトコル、および信号をコンピュータに接続されているラインのうちの１本に置くことができるようにするソフトウェアおよびハードウェアの組合せである。
【００２４】
ＯＳＩは、通信を７つの層に分ける。層は２つのグループに分けられる。上位層２０９は、ユーザとの間でのメッセージのやり取りが行われるたびに使用され、下位層２０８は、任意のメッセージがホストコンピュータを通過するときに使用される。このコンピュータ向けのメッセージは、上位層２０９に移動する。他のあるホスト向けのメッセージは、上位層には上がらず、別のホストに転送される。７つの層について、次のように簡単に説明する。
【００２５】
物理層２０１は、機械的構成要素およびコネクタなどインタフェースの物理的な特徴、バイナリ値を表す電圧レベルなどの電気的態様、および物理リンクを設定し、維持し、停止させるなどの機能的態様を定義する。データ通信用のよく知られている物理層インタフェースは、シリアルインタフェース、パラレルインタフェース、およびＥｔｈｅｒｎｅｔ（登録商標）やトークンリングなどのＬＡＮシステムの物理的仕様を含む。
【００２６】
データリンク層２０２は、２つのシステム間の物理接続を介して情報を送受信するための規則を定義する。データリンクは、一般にネットワークセグメント（インターネットワークではない）およびポイントツーポイントリンクである。データは、基礎を成す物理ネットワークを介してトランスポートするためにいくつかのフレームにまとめられる。受信されたデータの肯定応答など、いくつかの信頼性の機能を使用することができる。
【００２７】
ネットワーク層２０３は、複数のネットワークを介してデータを配信するインターネットワーキングサービスを提供する。インターネットワークアドレッシング方式は、各ネットワークおよび各ノードに一意のアドレスを割り当てる。ネットワーク層は、複数のデータリンク接続をサポートする。インターネットプロトコルスイーツでは、ＩＰは、ネットワーク層インターネットワーキングプロトコルである。
【００２８】
トランスポート層２０４は、エンドツーエンド通信サービスを提供し、データがこれらのエンドシステム間で確実に配信されることを確実にする。両方のエンドシステムは、接続を確立し、ネットワークを介したパケットの配信の追跡のためのダイアログに参加する。また、プロトコルは、パケットの流れを規制してゆっくりの受信機に対応し、リンクの中断が生じた場合、送信が完全には停止しないことを確実にする。伝送制御プロトコル（「ＴＣＰ」）は、トランスポート層プロトコルとすることができる。
【００２９】
セッション層２０５は、会話技術またはダイアログを使用することによってシステム間での情報の交換を調整する。ダイアログは、常に必要であるとは限らないが、一部のアプリケーションは、接続が一時的に失われた場合に、データの送信をどこから再起動させるかを知る方法を必要としたり、または１データセットの終端および新しいデータセットの先頭を示す定期的なダイアログを必要としたりする場合がある。
【００３０】
プレゼンテーション層２０６は、ユーザがワークステーション上で稼動させるオペレーティングシステムおよびアプリケーションの一部であるプロトコルを含む。情報は、この層で表示または印刷するようにフォーマットされる。データ内のコードは解釈され、データの暗号化および変換もこの層で処理される。
【００３１】
アプリケーション層２０７は、基礎を成すネットワークサービスにアクセスするための定義済み手続きを提供する。アプリケーション層は、ユーザアプリケーションの範囲を定義するために使用される。
【００３２】
マルチキャスト技術は、ＯＳＩモデルのより低いレベル２０８、すなわちトランスポート／ネットワーキング層用に開発されているが、本実施形態のシステムは、ＯＳＩモデルのより高いレベル２０９でマルチキャストを実施するために、アプリケーションレベルプログラミングモデルを提供することに焦点を置いている。したがって、本実施形態の方法およびシステムを使用して、開発者は、ＩＰマルチキャストインフラストラクチャを必要することなく、マルチキャスト機能を実施することができる。さらに、本実施形態のシステムは、後述するサービス指向プログラミングモデルを向上させることができる。
【００３３】
サービス指向フレームワークおよびプログラミングモデル  
サービス指向は、主にサービス指向フレームワークが「アプリケーション」をどのように定義するかという点で、オブジェクト指向と異なり得る。オブジェクト指向開発は、独立したクラスライブラリから構築されたアプリケーションに焦点を置き、サービス指向開発は、１組の自律的なサービスから構築されたシステムに焦点を置く。サービスは、単にメッセージ交換を介して対話するプログラムであり得る。しかし、既存の分散オブジェクト技術とは異なり、サービスは、明確なＸＭＬインタフェースを介してのみそのクライアントと対話することができる。サービス範囲を超えて全部のクラス、メソッド、および呼出を渡すなどの挙動は許可されない。したがって、アプリケーション開発者およびシステムインテグレータは、統合されるソフトウェアの基礎を成すオブジェクトモデル、型システム、およびプロトコルの特定の知識を必要としない。
【００３４】
分散オブジェクトシステムの場合のように、直接のオブジェクトの起動を介して異なるアプリケーションを統合する代わりに、アプリケーションは、他のアプリケーションが使用できる１組の「サービス」を公開し得る。サービスフレームワークを使用するアプリケーションは、動的に取得できる標準ベースのプロトコルおよびポリシー定義を使用してそのサービスを公開し得る。接続されたシステムを構成するアプリケーションのこの結合解除は、より簡単な統合、時間の経過による変化にシステムを対応させる際のさらなる柔軟性を可能にし、また、より信頼性のある動作を可能にし得る。
【００３５】
既存のサービス指向プログラミングモデルは、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）など、既存の上位ＯＳＩレベルメッセージングサービスを実施し得る。ＳＯＡＰは、メッセージのスキーマを提供する上位レベルＯＳＩサービスとして動作し得る。図３に、ＳＯＡＰプロトコルを使用するメッセージングシステムの考え得る一実施形態を示している。示したメッセージングアーキテクチャ（以下、「メッセージバス」と呼ぶ）は、ＳＯＡＰノードの開発およびメンテナンスを簡単にするためにアプリケーションプログラミングインタフェース（「ＡＰＩ」）として表示され得る。本実施形態のシステムおよび方法は、基本的な上位メッセージ処理を提供する任意のサービス指向モデル上で実施することができるが、実証の目的で、図３に示したメッセージバスを使用して本実施形態の方法およびシステムについて説明する。
【００３６】
図３に示すように、メッセージバスネットワーキング層３０１およびトランスポート３０２は、存在している一般のトランスポート層／ネットワーキング層プロトコルのいずれかから成る。ＴＣＰ／ＩＰは、普及しているトランスポート層／ネットワーキング層プロトコルであり、有効にされたＩＰマルチキャストである必要はなく、これが本実施形態のアプリケーションレベルのマルチキャストシステムを使用する利点である。トランスポート層は、ＩＰソケット、名前付きパイプ、またはデータを通信することができる任意の機構など、ネットワーキング機構をカプセル化することができる。メッセージバストランスポート３０３は、メッセージをデータリンクおよび物理層を介してワイヤで伝えるように、実際のバイトに変換することができる。
【００３７】
プレゼンテーション／セッション層３０４に上がり、ポートオブジェクト３０５は、メッセージのための構成可能な論理的コンジット（conduit）を表す。各ポートオブジェクト３０５は、論理メッセージを実際のネットワーク通信に変換するためにポートが使用するトランスポートの集まり３０３を有する。ポートは、１対のパイプラインオブジェクト、つまり送信パイプライン３０６および受信パイプライン３０７として内部に実装される。各パイプラインは、パイプラインに沿って進むメッセージを調べ、処理することができる、ポート拡張を構成するプラグ可能なメッセージハンドラ（図示せず）をサポートすることができる。メッセージバスを使用するアプリケーションにおける一般のノードは、単一のポートオブジェクトのみを例示し得るが、複数作成することが可能である。以下の説明では、ユーザがこの説明を概念化するのを助けることを図ってポートについて言及するが、ポートの使用が現代のメッセージバスアーキテクチャで必要ない場合もある。
【００３８】
アプリケーション層３０９で、アプリケーションコード３１０は、チャネルオブジェクト３０８を介してメッセージをポートオブジェクトに送信する。チャネルオブジェクトには様々な実施形態があり、送信チャネルと受信チャネルの２組に絞り込むことができる。単一のチャネルクラスは、送信チャネルおよび受信チャネルの両方を実装することもできる。
【００３９】
メッセージバスは、様々なメッセージ交換パターンを可能にするために、様々なチャネル実装をサポートし得る。例えば、一方向データグラム型メッセージ（ｏｎｅ−ｗａｙ  ｄａｔａｇｒａｍ−ｓｔｙｌｅ  ｍｅｓｓａｇｅ）のための単一のチャネルは、単に最後の受信側を表しているにすぎない場合がある。一方、より複雑なチャネルは、アプリケーションの実行にわたって相関双方向メッセージング（ｃｏｒｒｅｌａｔｅｄ  ｔｗｏ  ｗａｙ  ｍｅｓｓａｇｉｎｇ）、高信頼性メッセージング、またはメッセージの耐久性をサポートし得る。チャネルは、アプリケーションコードによって作成されたメッセージオブジェクトがインフラストラクチャコード（ＩＰなど）に渡される最初のポイントであり、アプリケーションコードの観点から見れば、チャネルは、メッセージバスアーキテクチャにおける拡張性の最初のポイントである。
【００４０】
メッセージバスフレームワークを使用してメッセージを送受信する一般のプロセスは以下の通りである。 
１．メッセージオブジェクトは最初の送信側によって作成される。 
２．メッセージは、メッセージオブジェクトへの参照をチャネルに渡すことによって送信される。 
３．チャネルはメッセージを、チャネルが関連付けられているポートオブジェクトに渡す。 
４．ポートはメッセージを、メッセージがパイプラインに登録されている各メッセージハンドラによって連続的に処理されるポートの送信パイプラインに投入する。 
５．メッセージが送信パイプラインの端部に到達すると、ポートはメッセージ参照を、ポートに登録されているトランスポートオブジェクトに渡す。トランスポートオブジェクトは、メッセージの次ホップのアドレスに基づいて選択される。 
６．トランスポート層は、メッセージを一連のバイトにフォーマットし、バイトをネットワークに推し進める。
【００４１】
この時点で、メッセージは、ＳＯＡＰノードを離れ、ネットワークの雲（cloud）に入っている。メッセージは、この行程で次のＳＯＡＰノードに到達するまで、もはやメッセージバスまたはＳＯＡＰの対象ではない。代わりに、メッセージは、ＴＣＰ／ＩＰやＨＴＴＰなどのネットワーキングプロトコルを通過する一連のバイトであり得る。
【００４２】
ある時点で、メッセージのバイトが、ＳＯＡＰノードであるネットワーク上のリスニングノード（ｌｉｓｔｅｎｉｎｇ  ｎｏｄｅ）に到達する。以下は、リスニングノードで行われ得る。 
１．トランスポートで導出されたオブジェクトは、メモリ内にメッセージオブジェクトを作成するための一連のバイトを受信する。メッセージヘッダーは、メモリに完全に読み取られるが、メッセージコンテンツは、それが必要になるまで、トランスポート、および場合によってはワイヤ上に留まる。 
２．次いでトランスポートは、メッセージ参照を、トランスポートオブジェクトが登録されているポートの受信パイプラインに渡す。 
３．メッセージは、受信パイプラインに登録されている各メッセージハンドラによって連続的に処理される。メッセージハンドラが選択すると、受信パイプラインからメッセージを引き出し、メッセージハンドラに関連付けられているチャネルにそれを渡す。 
４．メッセージがポート上の受信パイプラインの端部に到達すると、ポートは、メッセージを、ポートのメイン受信チャネルに登録されているアプリケーション定義済みメッセージハンドラに渡す。 
５．アプリケーションコードにはメッセージオブジェクトへの参照があり、アプリケーションコードによるオブジェクトの使用は所望次第である。一般に、メッセージのアクションヘッダーがチェックされ、メッセージコンテンツが処理される。 
６．アプリケーションコードがメッセージを終了した場合、メッセージバスは、メッセージコンテンツ内に残されている読み取られていない任意のバイトを読み取り除去することによってトランスポートを一掃し、メッセージオブジェクトは、ガーベッジコレクションに残される。 
７．メッセージが最初の送信側から最後の受信側までの途中でＳＯＡＰ仲介者を通過した場合、仲介者も、上記で概説したように、受信ステップおよび送信ステップを使用してメッセージを処理する。仲介者は、単一のメッセージの送信側および受信側となるノードである。ＳＯＡＰルータは、仲介者の一般的な例である。
【００４３】
図４は、メッセージが２つの仲介者４０３、４０４を通って最初の送信側４０１から最後の受信側４０２まで通るパスを示している。図では、最初の送信側４０１によって送信パイプライン４０５のみが使用されており、最後の受信側によって受信パイプライン４０６のみが使用されている。一方、仲介者４０３、４０４では、メッセージの処理に、送信パイプライン４０７、４０８、および受信パイプライン４０９、４１０が使用されている。最初の送信側および最後の受信側の役割は、応答メッセージの行程で交換されることに留意されたい。
【００４４】
メッセージバスフレームワークは、サービス指向フレームワークを使用してサービスを実施する基本的な機構を提供するが、マルチキャスト機能を有効にするための用意はない。本実施形態の方法およびシステムは、こうしたサービス指向メッセージバスアーキテクチャに基づくものであり、マルチキャスト機能をそのアプリケーションに追加するために、サービス指向モデルの上に構築する機能を開発者に提供する。
【００４５】
マルチキャストメッシュシステム  
特許請求したシステムおよび方法は、メッシュとして知られる特定のマルチキャストトポロジを実施し得る。図５は、考え得るメッシュトポロジを示している。一般に、マルチキャストグループの１つのメンバーをノード５０１と呼び、そのグループをメッシュ５００と考えることができ、５０９などの通信チャネルを使用して互いに相互接続される１組のノード５０１〜５０８によって表す。メッシュ内の各ノード５０１〜５０８は、伝搬プロセスを介してメッシュ内の他のノード１つ１つにメッセージを伝えることができ、１つのノード、例えばノード５０１によって送信された各メッセージは、近隣のノード５０２〜５０５に渡され、各ノードがメッセージを受信するまで、引き続きメッセージをそれぞれの近隣ノードに渡す。ノードは、複数の接続を有するとき、メッセージを受信し、それに接続されている各チャネルに沿って送信するメッセージのコピーを作成することができる。伝搬の方向は、一般に、メッセージの送信側から流れ出て、物理的な洪水に似ているため、マルチキャストを使用したメッセージの伝搬は、一般にフラッディングと呼ばれる。マルチキャストメッシュ内の各ノードは、ネットワーク上にフラッディングされた任意のメッセージを受信することができ、またそれについて詳しい。すなわち、１つのノードがフラッディングされたメッセージを介して知っていることは、メッシュ内のすべてのノードが知っている。したがって、メッセージをフラッディングし続けるべきであるときに関して妥当なサイズまたはルールのメッシュを有することは有益であり得る。
【００４６】
サービス指向メッセージングシステムを使用したマルチキャストメッシュの実施形態  
図６は、本実施形態のマルチキャストメッシュシステムの一般の一実施形態を示している。この実施形態において、ピアノード６０１は、メッシュ６０２に接続されているノードである。メッシュは、メッセージまたはポイントツーポイントデータストリームの形式でデータを伝搬する目的で、ノードの結合されたネットワークを形成するために、近隣のチャネル６０７〜６１１によって複連結された１組の名前付きのピアノード６０１〜６０５とすることができる。メッシュは、近隣ノードへの接続に基づいて構築され、メッシュ内の近隣ノードは、通信リンク１つ分離れた（通信チャネルを介して直接接続されている）ピアノードである。
【００４７】
ピアノードは、メッシュ６０２に結合されているアプリケーション６１２のインスタンスと関連付けることができる。ピアチャネル６１３、６１４は、メッシュのピアノード６０１を介したアプリケーション６１２または（サービス指向語での）サービスとメッシュ６０２との間の通信のためのピアノードに固有のチャネルと考えることができる。アプリケーションはノードを作成することができるが、ノードはアプリケーションを作成することはできない。アプリケーションは、複数のノードを作成することができ、各ノードは、複数のサービスをホストすることができる。例えば、チャットアプリケーションを検討する。チャットアプリケーションは、ＣｈａｔＭｅｓｈと呼ばれるメッシュ内にノードを作成することができる。チャットアプリケーションは、異なる２つのサービス、ＶｉｄｅｏＳｅｒｖｉｃｅおよびＴｅｘｔＳｅｒｖｉｃｅを作成することができる。送信された任意のテキストメッセージは、ＴｅｘｔＳｅｒｖｉｃｅに配信され、送信された任意のビデオメッセージは、ＶｉｄｅｏＳｅｒｖｉｃｅに配信され得る。
【００４８】
最初にメッシュに接続すると、ピアノード６０１は、すでにメッシュに接続されている例えば６０３などの別のピアノードに接続することができる。接続側ピアノード６０１は、メッシュに接続されている近隣ノード６０３のアドレスを判定し、近隣ノードにメッシュに参加する要求を送信することができる。メッシュに接続した後、新しいピアノード６０１は、メッシュ内の６０４、６０５など追加の近隣ノードへの接続６０８、６１０を作成することができる。
【００４９】
メッシュの目的は、すべてのメッシュノードにメッセージのフラッディングのための論理トポロジを作成することであり得る。フラッディングに最適なトポロジを自動的に達成するために、メッシュは、署名および１組のコンタクトノード（ｃｏｎｔａｃｔ  ｎｏｄｅ）を維持し、フラッディングされた重複メッセージを評価して、どの近隣ノードがより効率的かを判定することができる。メッシュがフラッディングに最適なトポロジに収束するように、時間が経つにつれて接続が作成され、削除される。
【００５０】
あるノードは、メッシュから切断されると、メッシュ内に、メッシュ分割（ｍｅｓｈ  ｐａｒｔｉｔｉｏｎ）として知られる切れ目を潜在的に作成する可能性がある。ピアノードは、メッシュ署名（後述）およびメッシュのコンタクト情報を使用して、グラフ分割を検出し、修復する。
【００５１】
ピアチャネル６１３、６１４は、アプリケーション６１２とピアノード６０１との間で送受信する通信チャネルであり得る。これらは、アプリケーションにとって、ＩＰ有効マルチキャストインフラストラクチャを必要とすることなく、マルチキャストチャネルとして見える可能性がある。各ピアチャネル６１３、６１４をピアノード６０１に関連付けることができる。ピアノード６０１は、メッシュアルゴリズム（最適化、分割検出、および修復など）を実施し、メッシュ全体にわたってメッセージをフラッディングする責任を負う。各ピアノードは、ノードサービスと呼ばれるそれ自体のサービスを提供し、ノードサービスは、信頼できるメッセージバスチャネルを使用して１組の近隣ノードサービスと対話する。このノードサービスは、サービスフレームワークの上で実施され、例えばＴＣＰおよびＨＴＴＰトランスポートを介して信頼できるチャネルを使用する。
【００５２】
ピアチャネル上に送信されたメッセージは、メッシュ内の別のノードによって提供される特定のサービスに向けられる。メッシュ内の各ノードは、メッシュ上に送信された各メッセージのコピーを受信することができる。ノードは、メッセージを受信すると、メッセージの目的のサービスを実施する任意の関連するピアチャネルにそれを配信する。メッシュ内の各ノードにメッセージを伝搬するために、発信側ノードは、その近隣ノードのそれぞれにメッセージを送信することができる。これらの近隣ノードは、メッセージをその近隣ノードに渡し、以下同様に行われる。実際のフラッディングアルゴリズムについては後述する。
【００５３】
アプリケーションメッセージは、例えば、アプリケーションメッセージまたは内部メッセージを、ノードの近隣ノードにアドレス指定された別の外部メッセージにカプセル化することによって、１つの近隣ピアノード６０１から別のノード６０２にトンネリングされる。新しい外部メッセージは、近隣ノードごとに作成することができる。このように、その宛先サービスアドレスを含む元のメッセージは、ノード間で変更されないままである。すべてのノードは、他のすべてのノードから到達可能であり得る。これが真ではない（例えばノードがトラバースできないファイアウォールの後ろにあるなど）限り、メッシュの復元力は低下する。
【００５４】
オブジェクトモデルの実施形態  
図７は、本実施形態のシステムの一実施形態を実施するオブジェクトを示している。本実施形態のマルチキャストシステムのオブジェクトは、ＰｅｅｒＣｈａｎｎｅｌ  Ｆａｃｔｏｒｙ７０１、ＰｅｅｒＣｈａｎｎｅｌ７０２、ＰｅｅｒＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ７０３、ＰｅｅｒＬｉｓｔｅｎｅｒ７０４、ＰｅｅｒＮｏｄｅ７０５、Ｓｙｎｃｈｒｏｎｉｚｅｒ７０６、Ｍａｉｎｔａｉｎｅｒ７０７、Ｃｏｎｎｅｃｔｏｒ７０８、Ｆｌｏｏｄｅｒ７０９、ＮｅｉｇｈｂｏｒＭａｎａｇｅｒ７１０、およびＮｅｉｇｈｂｏｒ７１１から成り得る。論理的に、上述した論理ピアノードは、ＰｅｅｒＮｏｄｅ７０５、Ｓｙｎｃｈｒｏｎｉｚｅｒ７０６、Ｃｏｎｎｅｃｔｏｒ７０８、Ｍａｉｎｔａｉｎｅｒ７０７、Ｆｌｏｏｄｅｒ７０９、およびＮｅｉｇｈｂｏｒＭａｎａｇｅｒ７１０から成るオブジェクトの組として実装され得る。
【００５５】
ＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙ７０１は、ＰｅｅｒＣｈａｎｎｅｌｓ７０２を生成する責任を負う。ＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙ７０１は、それが作成したアクティブチャネルの集まりも維持し得る。ＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙ７０１は、ＰｅｅｒＮｏｄｅ７０５に直接は関連付けられておらず、それらを調べるか、必要に応じて作成する。
【００５６】
ＰｅｅｒＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ７０３は、ＰｅｅｒＬｉｓｔｅｎｅｒ７０４を生成する責任を負う。ＰｅｅｒＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ７０３は、アクティブリスナを管理し、リスナが生成したアクティブチャネルの集まりを維持する。ＰｅｅｒＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ７０３は、ちょうど１つのＰｅｅｒＮｏｄｅ７０５と関連付けられる。
【００５７】
ＰｅｅｒＮｏｄｅ７０５は、メッシュ内の１つのノードを表し、その関連の構成を含む。ＰｅｅｒＮｏｄｅ７０５は、ノードを実装するすべての内部構成要素の所有者であり得る。また、このクラスは、既存のノードを調べる静的メソッドを含んでいてもよい。
【００５８】
Ｎｅｉｇｈｂｏｒ７１１は、基礎を成す近隣チャネルを含み、チャネルの状態を追跡することができる。Ｎｅｉｇｈｂｏｒは、近隣ノードと通信するメソッドを公開することができる。
【００５９】
ＮｅｉｇｈｂｏｒＭａｎａｇｅｒ７１０は、Ｎｅｉｇｈｂｏｒ７１１の集まりを含んでいてもよい。ＮｅｉｇｈｂｏｒＭａｎａｇｅｒ７１０は、すべてのＮｅｉｇｈｂｏｒ７１１（例えばＭｅｓｓａｇｅＡｖａｉｌａｂｌｅ）の集合体であるイベントを公開することができる。このオブジェクトは、ピアノードサービスの実施を提供することができる。
【００６０】
Ｃｏｎｎｅｃｔｏｒ７０８オブジェクトは、送信および受信接続メッセージ（ＣＯＮＮＥＣＴ、ＷＥＬＣＯＭＥ、ＲＥＦＵＳＥ、ＤＩＳＣＯＮＮＥＣＴ）を処理することができる。
【００６１】
Ｍａｉｎｔａｉｎｅｒ７０７オブジェクトは、メッシュメンテナンスアルゴリズムを実施することができる。Ｍａｉｎｔａｉｎｅｒ７０７は、メッシュ署名、既知のメッシュノードの集まり、および現在のメッシュのコンタクトノードの集まりを含んでいてもよい。
【００６２】
Ｆｌｏｏｄｅｒ７０９は、フラッディングロジックを実施することができる。Ｆｌｏｏｄｅｒは、最近見たメッセージのテーブルを含んでいてもよい。
【００６３】
Ｓｙｎｃｈｒｏｎｉｚｅｒ７０６は、近隣チャネルを介して軽量コンタクト／署名同期プロトコルを調整することができる。
【００６４】
メッシュ構造  
メッシュは、名前、またはメッシュＩＤによって識別することができる。メッシュＩＤは、ＩＰアドレス（１２３．１２．１２３．１２など）に解決され得る有効なホスト名（ｓｏｃｃｅｒｐａｌｓなど）である。メッシュ上のサービスのアドレスは、ＵＲＩ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒ）によって指定することができ、ピアチャネルスキーマプレフィックス（ｎｅｔ．ｐ２ｐ：／／）、メッシュＩＤ、パス、およびサービス名（ｎｅｔ．ｐ２ｐ：／／ｓｏｃｃｅｒｐａｌｓ／ｐａｔｈ／ｓｅｒｖｉｃｅなど）を使用して指定される。ＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓ構造は、メッシュ内のサービスの参照に使用され、一部には、少なくとも１つのＵＲＩから成る。
【００６５】
図８は、本実施形態のオブジェトモデルの実施形態を使用してメッシュを作成するプロセスを示している（以下の説明は、ＰｅｅｒＮｏｄｅ、ＰｅｅｒＣｈａｎｎｅｌなど、上記に列挙した名前を使用して上述したように本実施形態のシステムのオブジェクトを参照する）。
【００６６】
一般に、サービスまたはクライアントがメッシュと通信することを望むときはいつでも、そのサービスまたはクライアントは、メッシュのＰｅｅｒＮｏｄｅを介して通信することが必要である。特に、サービスは、ＰｅｅｒＬｉｓｔｅｎｅｒＦａｃｔｏｒｙに関連付け、クライアントは、ＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙに関連付けることができる。このプロセスは、アプリケーションがまず８０１でＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙを作成し、８０２で開くステップを伴う。ＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙは、アプリケーション内のオブジェクトとしてインスタンス化され、したがって、そのアプリケーションと関連付けられる。次に、８０３で、ＣｒｅａｔｅＣｈａｎｎｅｌと呼ばれるメソッドをＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙ上で呼び出すことによって、ＰｅｅｒＣｈａｎｎｅｌが作成される。ＰｅｅｒＣｈａｎｎｅｌは、次いで８０４で、関連のＰｅｅｒＮｏｄｅがあるかどうかを確認する。関連のＰｅｅｒＮｏｄｅがある場合、ＰｅｅｒＣｈａｎｎｅｌは、８０５でそのＰｅｅｒＮｏｄｅに接続し、ＰｅｅｒＣｈａｎｎｅｌを開き、８０６でメッセージの送受信を開始する。そうでない場合、既存のＰｅｅｒＮｏｄｅがない場合、ＰｅｅｒＣｈａｎｎｅｌは、８０７で新しいＰｅｅｒＮｏｄｅを作成し、８０８でＰｅｅｒＮｏｄｅを開き（例えばＰｅｅｒＣｈａｎｎｅｌ上でＯＰＥＮ関数を呼び出し、ＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓに渡すことによって）、８０９で新しいＰｅｅｒＮｏｄｅを開く。
【００６７】
新しいＰｅｅｒＮｏｄｅを開く際、ＰｅｅｒＮｏｄｅは、名前解決サービスを提供する責任を負うＲｅｓｏｌｖｅｒオブジェクトを呼び出すことができる。ＲｅｇｉｓｔｅｒＭｅｓｈＩＤ、ＵｎｒｅｇｉｓｔｅｒＭｅｓｈＩＤなどを含めて多数のＲｅｓｏｌｖｅｒメソッドがある。Ｒｅｓｏｌｖｅｒメソッドは、カスタムな名前解決サービスを実施したり、「ＰＮＲＰ」（Ｐｅｅｒ  Ｎａｍｅ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）などのメッセージバス提供解決サービスを使用したりすることができる。新しく作成されたＰｅｅｒＮｏｄｅは、Ｒｅｓｏｌｖｅｒを呼び出して、内部実装のために、８１０各で、ＰｅｅｒＮｏｄｅによって一意に提供されたサービスであるノードサービスを登録することができる。このノードサービスは、新しいＰｅｅｒＮｏｄｅの作成を開始した、または既存のＰｅｅｒＮｏｄｅへの接続を開始したアプリケーションサービスとは異なり得る。Ｒｅｓｏｌｖｅｒに登録することによって、他のノードは、そのノードサービスの参照を介して、新しく作成されたＰｅｅｒＮｏｄｅへの参照を取得することができる。
【００６８】
そのノードサービスを登録することに加えて、８１１で、ＰｅｅｒＮｏｄｅは、メッシュ内の他のノードについてＲｅｓｏｌｖｅｒに対してクエリを行うことができる。ノードは、リゾルバのＲｅｓｏｌｖｅＭｅｓｈＩｄメソッドを呼び出すことなしに（他のノードのうちの１つがこのノードへの接続を開始しない限り）メッシュ内に他のノードがあるかどうかわからない場合がある。他のノードがない場合、ＰｅｅｒＮｏｄｅは、ＰｅｅｒＣｈａｎｎｅｌに指示を発し、ＰｅｅｒＣｈａｎｎｅｌはアプリケーションに警告を発する。他のノードがある場合、ＰｅｅｒＮｏｄｅは、そのＭａｉｎｔａｉｎｅｒオブジェクトを呼び出して、メッシュＩＤをリモートノードサービスのＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓに解決することができる。ＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓが取得されると、８１１で、ＮｅｉｇｈｂｏｒＭａｎａｇｅｒを使用して、ＮｅｉｇｈｂｏｒＮｏｄｅへのＮｅｉｇｈｂｏｒＣｈａｎｎｅｌを作成することができる。ＮｅｉｇｈｂｏｒＣｈａｎｎｅｌが作成されると、８１２で、ＣＯＮＮＥＣＴメッセージを送信することによって接続が試行される。ＷＥＬＣＯＭＥメッセージが受信されると、ＰｅｅｒＮｏｄｅは、開かれ、オンラインとなり、同期プロセスが開始する。ＲＥＦＵＳＥメッセージが受信されると、ＰｅｅｒＮｏｄｅは、追加の接続を試行することができる。ＰｅｅｒＮｏｄｅが他の任意のノードを検出しない、またはそれに接続しない場合、ＰｅｅｒＮｏｄｅは、８１２でそれ自体をオフライン状態に設定し、そうでない場合、ＰｅｅｒＮｏｄｅは、８１３でオンラインとなり、８１４でメッセージの送受信を行う。
【００６９】
一般に、上記のプロセスは、初期チャネル作成ブロックを除いて、ＰｅｅｒＬｉｓｔｅｎｅｒプロセスについても同様であり得る。そのサービスを対象とするメッセージによって要求された後、メッシュとの通信のみに関与するサービスを扱うとき、サービスは、ＰｅｅｒＣｈａｎｎｅｌＦａｃｔｏｒｙの代わりにＰｅｅｒＬｉｓｔｅｎｅｒＦａｃｔｏｒｙを作成し、開くことができる。次いで、ＰｅｅｒＣｈａｎｎｅｌは、ＰｅｅｒＬｉｓｔｅｎｅｒＦａｃｔｏｒｙを作成するために使用することができる。第１のメッセージがフィルタ基準に一致するＰｅｅｒＮｏｄｅによって受信されると、ＰｅｅｒＬｉｓｔｅｎｅｒは、ＰｅｅｒＣｈａｎｎｅｌを生成することができる。ＰｅｅｒＣｈａｎｎｅｌが作成されると、上述したプロセスと同様に双方向通信が行われる。しかし、ＰｅｅｒＬｉｓｔｅｎｅｒは、フィルタ基準に一致するメッセージについてのみアプリケーションに通知するように、メッセージフィルタで構成することもできる。
【００７０】
アプリケーションは、メッセージをフラッディングしたいとき、そのＰｅｅｒＣｈａｎｎｅｌを介してＰｅｅｒＮｏｄｅと通信することができる。ピアチャネルは、メッセージがそれに使用可能であるときはいつでも、アプリケーションに通知することができる。あるいは、実装がＰｅｅｒＬｉｓｔｅｎｅｒを使用する場合、ＰｅｅｒＬｉｓｔｅｎｅｒは、ＰｅｅｒＣｈａｎｎｅｌを生成し、アプリケーションに、それのためにメッセージが受信されたことを通知することができる。ＰｅｅｒＣｈａｎｎｅｌが作成されると、アプリケーションは、それを受信し、処理することができる。
【００７１】
各ＰｅｅｒＮｏｄｅは、単一の関連のＮｅｉｇｈｂｏｒＭａｎａｇｅｒを有し得る。ＮｅｉｇｈｂｏｒＭａｎａｇｅｒは、配信および受信の役割に限定されていてもよく、そのすぐ隣のすべての近隣ノード、すなわちそれに直接接続されているＰｅｅｒＮｏｄｅのリストを維持したり、それに向けられるメッセージを収集し、あるＰｅｅｒＮｏｄｅに属するＰｅｅｒＣｈａｎｎｅｌからメッセージを送信したりする仕事が課せられてもよい。
【００７２】
Ｎｅｉｇｈｂｏｒが接続要求を受信する  
図９は、近隣接続を処理するシナリオを示している。９０１で、第１のノードが第２のノードへの接続を開始すると、第２のノードのＮｅｉｇｈｂｏｒＭａｎａｇｅｒは、通知され、９０２で、リモートの第１のノードを追跡するためにＮｅｉｇｈｂｏｒオブジェクトを作成することができる。９０３で、ＮｅｉｇｈｂｏｒＭａｎａｇｅｒは、第２の近隣ノードを表すそのＰｅｅｒＮｏｄｅに通知し、第２の近隣ノードは、Ｃｏｎｎｅｃｔｏｒに通知する。第１のノードのＣｏｎｎｅｃｔｏｒは、ＣＯＮＮＥＣＴメッセージを送信することによって、Ｃｏｎｎｅｃｔプロトコルを第２のノードから開始する。次いで応答側Ｃｏｎｎｅｃｔｏｒは、次のステップに従って応答を開始側ノードに送信することができる。
【００７３】
近隣ノードの現在の数が最大値（下記のメッシュメンテナンスセクションで詳述）以上である場合、９０５で、ＲＥＦＵＳＥメッセージが、近隣ノードおよび／または他の既知のノードの選抜リストとともに近隣ノードに戻されてもよく、９０６でチャネルが閉じる。そうでない場合、９０７で、ＷＥＬＣＯＭＥメッセージが、近隣ノードおよび／または既知のノードの候補リストとともに送信され得る。
【００７４】
チャネルが上記のプロセスによって閉じられていない場合、ノードは、９０８で、各ノード上に広告されているサービスを含み得るＡＤＶＥＲＴＩＳＥメッセージを交換することができる。
【００７５】
ノードの同期化  
近隣ノードがメッシュ上の別のノードに接続すると、すべてのノードがメッシュの同じビューを確実に共有するために、メッシュの現在の状態を同期する必要がある。この状態は、メッシュのコンタクトノードのリストを、メッシュ署名（後述する内部メッシュメンテナンス機能に使用される）とともに含む。
【００７６】
Ｐｅｅｒ  Ｓｙｎｃｈｒｏｎｉｚｅｒは、１対の隣接するノード間の同期プロトコルを稼働させる責任を負うＰｅｅｒＮｏｄｅの構成要素とすることができる。同期プロセスは、図１０に示した以下のステップを伴い得る。ブロック１０００で、近隣ノードが接続済み状態に移行すると、開始側Ｓｙｎｃｈｒｏｎｉｚｅｒは、ＳｙｎｃＲｅｑｕｅｓｔメッセージを送信することによって同期プロセスを開始する。ＳｙｎｃＲｅｑｕｅｓｔメッセージは、Ｍａｉｎｔａｉｎｅｒのコンタクトノードキャッシュ内のコンタクトノードの要約リストおよび署名を含み得る。各コンタクトノードの要約は、コンタクトノードのノードＩＤおよびコンタクトノードのバージョン番号を含み得る。新しいノードの場合、このリストは空である場合がある。
【００７７】
ブロック１００５で、ＳｙｎｃＲｅｑｕｅｓｔメッセージを受信すると、応答側Ｓｙｎｃｈｒｏｎｉｚｅｒは、Ｍａｉｎｔａｉｎｅｒに要約のリストを渡すことができる。Ｍａｉｎｔａｉｎｅｒは、メッシュメンテナンスアルゴリズムを実施し、メッシュ署名、既知のメッシュノードの集まり、および現在のメッシュのコンタクトノードの集まりを含み得る。ブロック１０１０で、Ｍａｉｎｔａｉｎｅｒは、次に要約リストをそのコンタクトノードキャッシュの内容と比較することができる。ブロック１０１５で、Ｍａｉｎｔａｉｎｅｒは、そのキャッシュには存在し、要約リストから欠けているコンタクトノード（すなわちそれらを有していない開始側ノード）のリストを構築し、要約リスト内のものより新しいコンタクトノードを追加する。ブロック１０２０で、更新された要約が作成される。応答側のキャッシュから欠けている任意のコンタクトノードが追加された、または応答側がより古いバージョンを有している場合、Ｍａｉｎｔａｉｎｅｒは、それらを新しい更新済み要約リストに追加することができる。ブロック１０２５で、コンタクトノードリスト、署名、および新しい要約リストは、Ｓｙｎｃｈｒｏｎｉｚｅｒに戻され得る。
【００７８】
ブロック１０３０で、Ｍａｉｎｔａｉｎｅｒによって戻された要約リストが空ではない場合、制御はブロック１０３５に移り、応答側Ｓｙｎｃｈｒｏｎｉｚｅｒは、この要約リストおよび署名を含むそれ自体のＳｙｎｃＲｅｑｕｅｓｔメッセージを送信する。ブロック１０４０で、Ｓｙｎｃｈｒｏｎｉｚｅｒは、コンタクトノードを含む一連のＳｙｎｃＤａｔａメッセージを送信することができる。最後のコンタクトノードチャンクおよび署名は、ＳｙｎｃＥｎｄメッセージで送信することができる。ブロック１０３０で、Ｍａｉｎｔａｉｎｅｒによって戻された要約リストが空の場合、Ｓｙｃｈｒｏｎｉｚｅｒは、それ自体のＳｙｎｃＲｅｑｕｅｓｔを送信せず、制御がブロック１０４０に移動し得る。
【００７９】
ブロック１０４３で、開始側で、開始側がそれ自体のＳｙｎｃＲｅｑｕｅｓｔを送信したかどうかの判定が行われる。開始側がＳｙｎｃＲｅｑｕｅｓｔを送信しなかった場合、ブロック１０４５で、すべてのＳｙｎｃＤａｔａおよびＳｙｎｃＥｎｄメッセージが送信されると、同期プロセスの終端が合図される。開始側がそれ自体のＳｙｎｃＲｅｑｕｅｓｔを送信した場合、ブロック１０５０で、ＳｙｎｃＥｎｄメッセージが受信されると、同期プロセスが終了する。
【００８０】
ブロック１０５５で、応答側で、応答側がそれ自体のＳｙｎｃＲｅｑｕｅｓｔを送信したかどうかの判定が行われる。応答側がＳｙｎｃＲｅｑｕｅｓｔを送信しなかった場合、ブロック１０６０で、すべてのＳｙｎｃＤａｔａおよびＳｙｎｃＥｎｄメッセージが送信されると、同期プロセスの終端が合図される。応答側がそれ自体のＳｙｎｃＲｅｑｕｅｓｔを送信した場合、ブロック１０６５で、ＳｙｎｃＥｎｄメッセージが受信されると、同期プロセスが終了する。
【００８１】
図１１は、開始側が新しいノードである１対の近隣ノード間での様々な同期関連のメッセージの交換を示している。図１２は、メッシュ内の１対の既存のノード間の同期プロセスを示している。図１３は、開始側の既存のノードと新しいノードとの間の同期プロセスを示している。
【００８２】
メッセージの送信／フラッディング  
図１４は、メッセージのフラッディングのシナリオを示している。アプリケーションは、１４０１でメッセージを送信したいとき、１４０２でＰｅｅｒＣｈａｎｎｅｌメソッドの送信メソッドを呼び出し、１４０３で、ＰｅｅｒＣｈａｎｎｅｌはＰｅｅｒＮｏｄｅを呼び出し、１４０４で、ＰｅｅｒＮｏｄｅは、Ｆｌｏｏｄｅｒを呼び出してメッセージを送信する。１４０５で、内部メッセージのＩＤがＦｌｏｏｄｅｒのメッセージテーブルに追加され、１４０６で、Ｆｌｏｏｄｅｒは、内部メッセージを外部トンネリングメッセージにカプセル化し、１４０７で、メッセージをすべての近隣ノードにトンネリングメッセージとして送信する。外部トンネリングメッセージは、内部アプリケーションメッセージへの変更なしに、近隣チャネルでの通信のためにのみ使用される。トンネリングは、内部ピアノード構成要素のみによって処理し、配信するために内部メッセージの保全性を維持すると同時に、近隣チャネルによって処理するためにカプセル化ヘッダーおよび配信機構を提供するために行ってもよい。これは、２つの経路間のトランスポート機構を効果的に分離し得る。
【００８３】
メッセージの受信  
図１５は、メッセージの受信のシナリオを示している。１５０１で、ＰｅｅｒＮｏｄｅに関連付けられているＮｅｉｇｈｂｏｒＣｈａｎｎｅｌ上でメッセージが受信されると、１５０２で、ＮｅｉｇｈｂｏｒＭａｎａｇｅｒはＰｅｅｒＮｏｄｅに通知し、１５０３で、ＰｅｅｒＮｏｄｅはそのＦｌｏｏｄｅｒを呼び出して、そのタイプに従ってメッセージを処理する。
【００８４】
フラッディングされたすべてのメッセージについて、１５０４で、内部メッセージが外部トンネリングメッセージから抽出される。１５０５で、ＰｅｅｒＮｏｄｅは、Ｆｌｏｏｄｅｒを呼び出して、以前内部メッセージを見たかどうかを判定することができる。見た場合、メッセージは閉じられ、１５０６で処理が完了する。内部メッセージがメッシュを介した伝搬を完了していない（すなわちメッセージがさらにフラッディングされるべきである）場合、さらに処理が行われる。
【００８５】
１５０７で、その内部メッセージがメッシュ機能を処理するための内部メッセージである場合、１５０８で、ＰｅｅｒＮｏｄｅは、メッセージをその適切な内部ノードオブジェクト（Ｍａｉｎｔａｉｎｅｒなど）に転送することができる。これらの構成要素は、以下でさらに説明するようにメッセージを処理する。署名メッセージについて、１５０９で、Ｍａｉｎｔａｉｎｅｒは、メッセージがそれ以上のフラッディングを停止すべきであると判定することができ、その時点でメッセージは閉じられ、１５０６で処理が完了する。そうでない場合、１５１６で、内部メッセージのＩＤは、Ｆｌｏｏｄｅｒのメッセージテーブルに追加され、１５１７で、内部メッセージは、Ｆｌｏｏｄｅｒによって別の外部トンネリングメッセージに再カプセル化され、元のメッセージが受信された近隣チャネルを除くすべての近隣チャネルに送信される。
【００８６】
１５１０で、内部メッセージがアプリケーションメッセージである場合、１５１１で、ＰｅｅｒＮｏｄｅは、メッセージの宛先サービスに関連付けられているチャネルオブジェクト（例えばＰｅｅｒＣｈａｎｎｅｌやＰｅｅｒＬｉｓｔｅｎｅｒ）を検索する。一致するＰｅｅｒＣｈａｎｎｅｌが検出されると、１５１２で、メッセージは、ＰｅｅｒＣｈａｎｎｅｌに関連付けられているアプリケーション／サービスに送信される。そうでない場合、一致するＰｅｅｒＬｉｓｔｅｎｅｒが検出されると、ＡｃｃｅｐｔＣｈａｎｎｅｌまたはＢｅｇｉｎＡｃｃｅｐｔＣｈａｎｎｅｌを呼び出すことによって、１５１３で、アプリケーション／サービスに対する新しいＰｅｅｒＣｈａｎｎｅｌが作成され、メッセージが対応するアプリケーションに送信される。
【００８７】
１５１０で、内部メッセージがアプリケーションメッセージではない場合、１５１６で、内部メッセージのＩＤは、Ｆｌｏｏｄｅｒのメッセージテーブルに追加され、１５１７で、内部メッセージは、Ｆｌｏｏｄｅｒによって別の外部トンネリングメッセージに再カプセル化され、元のメッセージが受信された近隣チャネルを除くすべての近隣チャネルに送信される。１５１４、１５１５で、追加のフラッディングプルーニングロジック（ｆｌｏｏｄ  ｐｒｕｎｉｎｇ  ｌｏｇｉｃ）もまた、このプロセスで実施することができる。例えば、１５１４で、一部のアプリケーションは、Ｆｌｏｏｄｅｒに関連付けられている伝搬フィルタインタフェースオブジェクト（ＩＰｅｅｒＭｅｓｓａｇｅＰｒｏｐａｇａｔｉｏｎＦｉｌｔｅｒインタフェースと呼ばれる）を実施して、メッセージをこれ以上フラッディングすべきかどうかを判定することができる。フラッディングフィルタインタフェースがこれ以上のフラッディングはないと判断した場合、１５１５でプロセスが完了する。
【００８８】
メッシュの一部分を閉じる  
以下は、メッシュの一部分を分解または閉じる際に行われるイベントである。
【００８９】
開始された近接チャネルの切断：近隣チャネルは、手際よく切断する場合、ＤＩＳＣＯＮＮＥＣＴメッセージを送信する。メッセージは、その近隣チャネルを閉じるＣｏｎｎｅｃｔｏｒによって処理される。近隣チャネルが閉じると（急なまたは正式な切断処理を介して）、ＮｅｉｇｈｂｏｒＭａｎａｇｅｒは、他の内部ノード構成要素に通知することができる。Ｍａｉｎｔａｉｎｅｒは、メッシュメンテナンスアルゴリズム（後述）を実行することによってこのイベントを処理することができる。ＰｅｅｒＮｏｄｅは、リモートノードによって広告されているサービスがもはや利用可能ではないことをアプリケーションに通知することによって、このイベントを処理する。これが唯一の近隣接続である場合、現在ノードはオフラインでもよい。
【００９０】
開始されたＰｅｅｒＮｏｄｅの切断：ピアノードが閉じつつあるため、またはＭａｉｎｔａｉｎｅｒが接続をプルーニングすることを選択したために近隣接続が（ＰｅｅｒＮｏｄｅによって）ローカルに切断される。近隣接続が閉じつつあるとき、ローカル構成要素に通知される。Ｃｏｎｎｅｃｔｏｒは、ＤＩＳＣＯＮＮＥＣＴメッセージを近隣接続に送信することによってこのイベントを処理する。Ｎｅｉｇｈｂｏｒが閉じると、アプリケーションは、リモートノードの広告されているサービスがもはや利用できないことを通知される。
【００９１】
ＰｅｅｒＣｈａｎｎｅｌを閉じる：チャネルが閉じられると、所有しているファクトリのチャネルの集まりからそのチャネルが取り除かれ、関連のＰｅｅｒＮｏｄｅへの参照が開放される。
【００９２】
サービスの広告  
本実施形態のメッシュシステムの１つの利点は、アプリケーションがメッシュを使用して、次いでアプリケーションが消費できるサービスを探すことができることである。メッシュ上の様々なノードによって提供されるサービスへのアクセスを可能にするために、アプリケーションは、まず、その近隣ノードに関する情報を取り出す必要がある。特に、アプリケーションは、その近隣ノードに広告されたサービスを列挙することができなければならない。
【００９３】
近隣ノードへのローカルサービスを広告するために、アプリケーションは、ローカルアプリケーションサービスのＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓを指定するＰｅｅｒＮｏｄｅのＡｄｄＡｄｖｅｒｔｉｓｅｄＡｄｄｒｅｓｓｅｓ関数を呼び出すことができる。これは、Ｍａｉｎｔａｉｎｅｒに、このサービスをその現在広告されているリストに追加させ、ＡＤＶＥＲＴＩＳＥメッセージを、更新された広告済みサービスリストを含む近隣ノードに送信させる。同様に、アプリケーションは、ＰｅｅｒＮｏｄｅのＲｅｍｏｖｅＡｄｖｅｒｔｉｓｅｄＡｄｄｒｅｓｓｅｓ関数を呼び出すことによってサービスの広告を解除することができる。
【００９４】
アプリケーションがそのサービスアドレスを広告している場合、この情報は、ノードによってキャッシュされ、近隣ノードに送信される。この情報を受信すると、イベントが行われる。このイベントは、アプリケーションに、近隣ノードＩＤおよびそのノードにおいて広告されているすべてのＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓｅｓを提供することができる。
【００９５】
アプリケーションのサービスのアドレスを広告することによって、アプリケーションは、近隣のアプリケーションサービスへのチャネルを直接開くことができ、それによってプライベート通信チャネルが有効になる。メッセージを（メッシュ全体に送信するのではなく）１つの近隣ノードに送信するには、アプリケーションは、近隣ノードにおいて広告されているサービスのリストを取り出し、どのサービスに送信するかを判定する必要がある。このサービスのリストを検出するために、アプリケーションは、広告されているサービスを取り出すためのＰｅｅｒＮｏｄｅの関数を呼び出すことができる。この関数は、ＧｅｔＮｅｉｇｈｂｏｒＡｄｖｅｒｔｉｓｅｄＡｄｄｒｅｓｓｅｓと呼ばれ、キャッシュされているサービス情報を収集する。メソッドは、ＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓの集まりを、近隣ノードＩＤとともに近隣ノード上に広告されているサービスに戻す。
【００９６】
アプリケーションは、これらのＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓのうちの１つを選択し、基礎を成すメッセージバスのチャネル（ＰｅｅｒＣｈａｎｎｅｌではなく、ｈｔｔｐ、ｔｃｐなど）を使用して、サービスへのチャネルを作成することができる。アプリケーションは、このチャネルを使用して、近隣のサービスと直接通信（メッシュ外）することができる。
【００９７】
メッシュメンテナンス 
図１６は、本実施形態の一実施形態におけるメッシュメンテナンスプロセスを示す図である。メッシュ接続は、ｃＩｄｅａｌＮｅｉｇｈｂｏｒｓ、ｃＭａｘＮｅｉｇｈｂｏｒｓ、ｃＭｉｎＮｅｉｇｈｂｏｒｓと呼ばれる３つのパラメータによって判定することができる。１６０１で、ノードは、接続されている近隣ノード数のカウントを維持することができる。ノードは、常に、他のノードへのｃＩｄｅａｌＮｅｉｇｈｂｏｒｓ接続をほぼ維持しようと試みる。１６０２で、ノードは、現在ｃＭａｘＮｅｉｇｈｂｏｒｓを持っている場合、新しい発信側接続を確立せず、または新しい受信側接続を受け付けず、１６０３で、ＲＥＦＵＳＥメッセージを、それに接続しようと試みている任意のノードに送信する。１６０４で、接続数が常にｃＭｉｎＮｅｉｇｈｂｏｒｓを下回る場合、ノードは、より多くの接続を確立しようと試みることができる。１６０５、１６０６で、ノードが待ち状態のチャネル要求をＷＥＬＣＯＭで処理したり、１６０７で、ノードが（ＷＥＬＣＯＭＥ、ＲＥＦＵＳＥ、およびＤＩＳＣＯＮＮＥＣＴメッセージを介して）その近隣ノードによってそれに伝えられた既知のノードのリストを使用したりすることができる。このリストが不十分である場合、（例えば上述したように新しいチャネルを開くことによって）メッシュＩＤを新しいノードに解決するよう試行することができる。
【００９８】
ｃＩｄｅａｌＮｅｉｇｈｂｏｒｓ、ｃＭａｘＮｅｉｇｈｂｏｒｓ、およびｃＭｉｎＮｅｉｇｈｂｏｒｓの値は、メッシュサイズおよびメッシュトラフィックを含む様々な要因に依存し得る。唯一の接続が失われた場合、ｃＭｉｎＮｅｉｇｈｂｏｒｓ値が１では、完全な分離を引き起こし得るため、ｃＭｉｎＮｅｉｇｈｂｏｒｓが少なくとも２の任意のメッシュに適し得る。ｃＭａｘＮｅｉｇｈｂｏｒｓ値が高いことは、他のノードの代わりに特定のノードが非常に不釣り合いな量のフラッディングを行っていることを意味し得る。ｃＭｉｎＮｅｉｇｈｂｏｒｓとｃＭａｘＮｅｉｇｂｏｒｓとの間のｃＩｄｅａｌＮｅｉｇｈｂｏｒｓ値は、最低限のオーバーヘッドで、適切な冗長性に基づき得る。
【００９９】
メッシュ内の各ノードは、できるだけ最も有用な接続の組を維持することを試行することができる。この場合、接続の有用さは、（いずれかの方向に）それで送信され、まだ見られていないメッセージ量によって判定することができる。１６０８で、定期的に、ノードは、ｃＩｄｅａｌＮｅｉｇｈｂｏｒｓより多い数を有している場合、１６０９で、最も有用ではない接続を切断することができる。
【０１００】
各ノードはノードＩＤを有しており、これはランダムな６４ビット数である。メッシュは署名を有しており、これは、メッシュ内に存在する最も低いノードＩＤとして計算することができる。計算は、最も低いノードＩＤを有するノードに、そのＩＤを署名として発行させることによって行われる。しかし、ノードは、最も低いＩＤを有することを直接には知らない場合があるため、すべてのノードが各自のＩＤを発行しようと試みる場合がある。ノードは、メッシュ署名がすでにそのＩＤより低い場合、発行しない。また、各ノードは、発行前に指数的にそのノードＩＤに比例し得るバックオフ期間を有しており、それによって誤った署名発行数を低減するのを助ける。
【０１０１】
メッシュは、それを見たときにメッシュの署名を定期的に発行する責任を負う１組のコンタクトノードを有している。１６１０で、メッシュ署名のノードのビューとコンタクトノードが発行するビューとが一致しないたびに、ノードは、メッシュが分割されたことがわかり、ランダムなバックオフ期間の後、１６１１で、一致していないコンタクトノードのうちの１つに再接続しようと試みることができる。この手順は分割を検出しないという可能性がわずかにある。これを軽減するために、コンタクトノードは、定期的に、メッシュＩＤを新しい（ランダムの）ノードに解決し、接続を形成することを試みることができる。
【０１０２】
ＡＰＩ  
図１７は、本実施形態による方法を示している。方法１７００は、ピアネットワーキングプロトコルの実装を有するピアネットワーキングプロトコルを介して相互運用するコンピューティング装置のネットワークの一部になるように構成されたピアネットワーキング対応コンピュータで使用することができる。
【０１０３】
ピアツーピアプロトコルの成功は、選択されたエンティティ間の有効な接続を確立するプロトコルの能力に依存し得る。同様に、こうしたピアツーピアネットワークにおけるグループの形成は、この能力に依存する。しかし、本発明の方法は特定のピアツーピアプロトコルに限定されないことを当業者は以下の教示から理解されよう。
【０１０４】
方法１７００を、１組の装置サービスを実施するソフトウェアプログラムのアプリケーションプログラミングインタフェースに組み込むことができる。この方法は、上述したように、ピアリスナを設定するピアリスニングファクトリの一部およびピアチャネルを設定するピアチャネルファクトリの一部分とすることができる。ブロック１７１０で、方法は、ピアネットワーク上の他のコンピューティング装置に広告するサービスの最大数の要求を満たす（serve）。デフォルトの値は、例えば２５とすることができる。サービスは、コンピュータプログラムやユーザのコンピュータ経験であると考えることができる。過度の広告がネットワークを不必要に塞ぐ可能性があるため、あるグループのメンバーは、グループ内のすべてのコンピューティング装置から利用可能なすべてのサービスについて知る必要はない場合がある。広告されるサービスの数は、任意としたり、限られたネットワークトラフィックを有する小さいグループにおいてより多くのサービスが広告され、より多くのネットワークトラフィックを有する大きいネットワークにおいてより少ないサービスが広告されるなど決まった方式を基にしたりすることができる。さらに、広告できるサービスの数を設定してもよい。数は、ネットワークの別のメンバーによって、またはネットワークの管理メンバーによって設定されてもよい。コンピュータコード実装のサンプルは以下の通りである。 
public int MaxAdvertisedAddressesPerNeighbor { get; set; }
【０１０５】
ブロック１７２０で、メッセージがピアネットワーク上の追加のコンピューティング装置に伝搬されるべきかどうかを判定する旨の要求を満たすことができる。判定は、どのメッセージをネットワーク上の他のコンピューティング装置に渡すべきかについてのフィルタとも考えられる。フィルタは、メッセージが以前受信されているか、受信側コンピュータが認識する目的の受信側をメッセージが有するか、ネットワークトラフィックが高いか、メッセージが最近のものか、古いかなど、無制限の数の設定を有し得る。デフォルト値は、すべてのメッセージが転送されることを意味するフィルタなしとすることができる。また、フィルタを設定してもよい。例えば、受信側に知られているコンピュータ装置がオフラインになり、その既知のコンピュータ装置のためのメッセージが受信されると、フィルタは、メッセージを転送しないように設定することができる。コンピュータコード実装のサンプルは以下の通りである。 
public IPeerMessagePropagationFilter MessagePropagationFilter { get; set; }
【０１０６】
ブロック１７３０で、ピアネットワーク上のコンピューティング装置との連絡に使用されるポート番号の要求を満たすことができる。ポートを使用してネットワークにメッセージを伝え、ネットワーク上の様々なコンピューティング装置は、異なるポートを使用することができる。ブロック１７４０は、コンピューティング装置がネットワーク上の他のメンバーとの間でメッセージを送受信するために使用しているポートを提供することができる。デフォルトは、基礎を成すトランスポート（すなわちＴＣＰ、ＨＴＴＰ）がポートを選択することとすることができる。さらに、ネットワークと通信するために使用されるコンピューティング装置のポートを設定することができる。ポートは、ネットワークの別のメンバーによって、またはネットワークの管理メンバーによって設定されてもよい。コンピュータコード実装のサンプルは以下の通りである。 
public Nullable<int> NeighborServicePort { get; set; }
【０１０７】
ブロック１７４０で、ピアネットワーク上のコンピューティング装置との連絡に使用されるトランスポート方法の要求を満たすことができる。ＨＴＴＰまたはＴＣＰなど、様々なトランスポート方法が使用可能である。さらに、コンピューティング装置のトランスポート方法を設定することができる。トランスポート方法は、ネットワークの別のメンバーによって、またはネットワークの管理メンバーによって設定されてもよい。コンピュータコード実装のサンプルは以下の通りである。 
public Transport NeighborServiceTransport { get; set; }
【０１０８】
ブロック１７５０で、どのリゾルバを使用するかに関する要求を満たすことができる。特定のユーザは、異なるアドレスを有する様々な場所で様々な方法でネットワークと接続できるため、一意の識別がユーザまたはグループに割り当てられる。次いでこのアドレスは、識別がプロトコルを介して特定のアドレスに結合されるように解決される必要がある。こうしたピアツーピア名前解決プロトコルは、「ＰＮＲＰ」（Ｐｅｅｒ  Ｎａｍｅ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）である。例えば、リゾルバは、ＰＮＲＰを使用してネットワークアドレスをメッシュＩＤに変換することができる。しかし、本発明の方法は、特定のピアツーピアプロトコルに限定されず、同等に他のプロトコルに適用することができることを当業者は理解されよう。さらに、コンピューティング装置によって使用されるリゾルバを設定することができる。リゾルバは、ネットワークの別のメンバーによって、またはネットワークの管理メンバーによって設定されてもよい。コンピュータコード実装のサンプルは以下の通りである。 
public IPeerResolver Resolver { get; set; }
【０１０９】
上記の説明から、本実施形態の方法およびシステムは、サービス試行アプリケーションフレームワークを使用するアプリケーション開発者が、ピアノードオブジェクトを使用して、マルチキャスト機能を容易かつ便利に統合できるようにすることができる。このフレームワークを使用して、マルチキャスト機能を有するサービスを、ＴＣＰ／ＩＰや他の基礎を成す低レベルの通信プロトコルに関する心配なく作成することができる。というのは、ピアノードオブジェクトは、どんな使用可能なプロトコルでも使用してメッセージングを管理するからである。このシステムの利点は、インターネット全体にわたるメッシュを作成することができることであるのに対して、マルチキャストＩＰは、動作するために（「Ｍｂｏｎｅ」など）インターネットのいくつかのマルチキャストＩＰ対応セグメントを必要とする。また、本実施形態のシステムは、ＩＰマルチキャストソリューションが提供しない、フィルタインタフェースを使用してメッセージのフローが知的に制御される（例えばメッセージの抑制は、メッシュをより効率的かつ安全にするのに有用である）アプリケーションベースのフィルタリング機構も提供する。
【０１１０】
さらに、本実施形態のシステムは、サービス指向フレームワークの上に構築されるため、アプリケーション開発者は、最初からマルチキャストソリューションのプログラミングに関心を持つ必要がなく、どのマルチキャスト機能をサービスの一部分として実装したいかについてのみ心配すればよい。ピアノードオブジェクトモデルは、開発者がマルチキャスト対応サービスの開発に専念することができるように、基礎のトインフラストラクチャを提供する。また、所望のＡＰＩは、プログラミングを容易にする。
【０１１１】
上記の本文では、異なる多数の実施形態の詳細な説明を示しているが、特許の範囲は、特許請求の範囲の用語によって定義されることを理解されたい。考え得るすべての実施形態を記述するのは現実的ではなく、そうでないとしても不可能であるため、詳細な説明は、例示的なものにすぎないと解釈されるべきであり、考え得るすべての実施形態を記述してはいない。現在の技術または本特許の出願日以降に開発された技術を使用して多数の代替実施形態を実施することができ、それらは依然として特許請求の範囲内に含まれる。
【０１１２】
したがって、本特許請求の範囲の意図および範囲から逸脱することなく、本明細書に記載し、示した教示および構造において多くの変更および改変を加えることができる。したがって、本明細書に記載した方法および装置は、例示に過ぎず、特許請求の範囲を制限しないことを理解されたい。
【図面の簡単な説明】
【０１１３】
【図１】本実施形態の動作し得るコンピュータシステムを示すブロック図である。
【図２】オープンシステム相互接続モデルを示す図である。
【図３】本実施形態のシステムをその上に構築することができる、考え得るサービス指向メッセージングシステムを示す図である。
【図４】図３のメッセージングシステムを使用したメッセージ通信を示す図である。
【図５】マルチキャストメッシュトポロジを示す図である。
【図６】本実施形態のシステムの論理メッシュ実施形態を示す図である。
【図７】本実施形態の一実施形態におけるメッシュの実施に使用する一般のオブジェクトモデルを示す図である。
【図８】本実施形態の一実施形態においてメッシュを作成する一般のフローチャートを示す図である。
【図９】本実施形態の一実施形態における近隣接続プロセスを示す図である。
【図１０】本実施形態の一実施形態におけるシンクロナイザプロセスを示す図である。
【図１１】開始側が新しいノードである１対の近隣ノード間での様々な同期関連のメッセージの交換を示す図である。
【図１２】メッシュ内の１対の既存のノード間の同期プロセスを示す図である。
【図１３】開始側の既存のノードと新しいノードとの間の同期プロセスを示す図である。
【図１４】本実施形態の一実施形態における一般のフラッディングプロセスを示す図である。
【図１５】本実施形態の一実施形態におけるメッセージ処理プロセスを示す図である。
【図１６】本実施形態の一実施形態におけるメッシュ管理プロセスを示す図である。
【図１７】本実施形態による方法を示すフローチャートである。
【符号の説明】
【０１１４】
１００  コンピューティングシステム環境
１１０  コンピュータ
１２０  プロセッサ
１２１  システムバス
１３０  システムメモリ
１３１  ＲＯＭ
１３２  ＲＡＭ
１３３  ＢＩＯＳ
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  他のプログラムモジュール
１３７  プログラムデータ
１７１  ＬＡＮ
１７３  ＷＡＮ
１８０  リモートコンピュータ
１８５  リモートアプリケーションプログラム
【図１】
2006294009.tif 000003
【図２】
2006294009.tif 000004
【図３】
2006294009.tif 000005
【図４】
2006294009.tif 000006
【図５】
2006294009.tif 000007
【図６】
2006294009.tif 000008
【図７】
2006294009.tif 000009
【図８】
2006294009.tif 000010
【図９】
2006294009.tif 000011
【図１０】
2006294009.tif 000012
【図１１】
2006294009.tif 000013
【図１２】
2006294009.tif 000014
【図１３】
2006294009.tif 000015
【図１４】
2006294009.tif 000016
【図１５】
2006294009.tif 000017
【図１６】
2006294009.tif 000018
【図１７】
2006294009.tif 000019
【外国語明細書】
2006294009000001.pdf