JPH09511115A

JPH09511115A - スケーラブル分散計算環境

Info

Publication number: JPH09511115A
Application number: JP8508817A
Authority: JP
Inventors: グレガーソン，ダニエル，ピー．; ファーレル，デイヴィッド，アール．; ガイトンド，サニル，エス．; アフヤ，ラチンダー，ピー．; ラマクリシュナン，クリシ; シャフィック，ムハンマド; ワリス，イアン，エフ．
Original assignee: ピアロジックインコーポレイテッド
Priority date: 1994-08-19
Filing date: 1995-08-18
Publication date: 1997-11-04
Also published as: US5612957A; EP0776502A2; CN1159858A; AU3944995A; US5793968A; US5526358A; CA2197324A1; WO1996007257A3; US5778185A; WO1996007257A2; US5699351A; BR9508731A

Abstract

(57)【要約】本発明は分散計算システムに関し、さらに詳しくは、同種または異種いずれかで有り得る単一ネットワーク上または相互接続ネットワーク上の独立した演算ノード間の通信を容易にするスケーラブル分散計算環境のアーキテクチャおよび実装に関する。本発明は、任意の個数の同一の（意味的に等価な）インスタンスすなわちカーネルなどから構成され論理木を形成するダイナミック、対称、分散、リアルタイム、ピア・ツー・ピア・システムである。カーネルはネットワークの自己設定および自己維持的論理ビューにより実行時に統一的で一定の動作を示す。それぞれのカーネルは、関連する１つ以上の資源を有するネットワーク・ノードに常駐する。カーネルはリアルタイムで互いに動的に位置づけして事実上無制限の数の独立して実行するカーネルをサポートする階層構造を形成し保持する。本システムはトランスポート・プロトコルの数や組合せまた基本となる物理的トポロジーの混合と無関係にネットワークの論理ビューとユーザが開発したプログラム資源を維持する。本システムの通信サービスは、動的コンテクスト・ブリッジを使用して共通のトランスポート・プロトコル・スタックを共用し得ない末端ノード間で通信し、これによって異なるスタック上に存在するアプリケーションが自動的また透過的に相互に通信できるようになる。

Description

【発明の詳細な説明】スケーラブル分散計算環境発明の背景本発明は分散計算システムに関し、さらに詳しくは、同種(homogeneous)または異種(heterogeneous)いずれかで有り得る単一ネットワーク上または相互接続ネットワーク上の独立した演算ノード間の通信を容易にするスケーラブル分散計算環境のアーキテクチャおよび実装に関する。今日のビジネス環境では、合併(mergers)や買収(acquisitions)、多国籍化のダイナミクスや、顧客(customers)、供給各社、金融機関とのリアルタイム通信の必要性から企業構造がますます再構成されつつある。さらに、情報をすぐにアクセスできるようにすることやその情報を迅速に操作する必要性が競合利益を作り出し維持していく上で必須になっている。そのため、企業データやこのデータを操作するコンピュータ・プログラムが抜本的に新しい方針で、すなわち集中型 (centralized)でモノリシック(monolithic)な方法の代わりに分散的に開発される必要がある。分散コンピューティングでは、プログラムやデータはこれらと相互作用するユーザにできる限り近くで処理できるように論理的に位置付けられる。理論的にはこれによって企業は通信オーバヘッドを減少し、また各個人、グループ、部門の計算資源の使用量の少ない処理能力を開発することで高信頼性かつ高効率的に運用できる。多数の計算機に作業負荷を分散することで、任意の個人や作業グループまたは目的に併せて情報処理資源を最適化できる。このアプローチがデータや処理の分散や複製をさせシステムに対する要求が増加しても性能および信頼性がいっそう簡単に維持できるようになる。増加する粒度(granularity)やスケーラビリティ(scalability)の特徴もソフトウェアの再利用性に関する重要な利益を提供する、すなわち同じコンポーネントが幾つかの異なったアプリケーションで使用でき、開発および保守の時間と経費を減少できる。こうした要求があるため、企業全体に渡る仮想コンピューティングへ向かう動きが見られ、ネットワークの資源全体がユーザのデスクトップ・コンピュータまたは端末にローカルに存在しているようにユーザから見えることになる。従来のモノリシックで集中型の企業情報処理モデルは細粒度的(finegrained)分散アプローチに従っている。仮想的、動的な企業コンピューティングの転換はローカル計算資源（プログラム・エレメントおよびデータ）が仮想ネットワークで継目なく(seamlessly)相互にリンクされた分散アーキテクチャを用いてミッション・クリティカル・コア・システム(mission critical core systems)を実装する必要がある。しかし今日の企業情報システムでは、個々のアプリケーションは相互運用しない異種環境内に存在するのが典型的である。互換性のないシステムを接続しつつ増加する一方の多数の異なるオペレーティングシステムと広い地域に渡ってネットワーク・プロトコルを維持していく作業にビジネスは直面している。企業の合併や買収がまた発生する傾向にあり、導入済みの異種ネットワークを単一の企業全体に渡るネットワークに統合する必要性が一度ならず何度も必要になる。さらに、企業が地球規模になり情報システムを多数の時間帯に渡って機能させる必要が発生するので、システムが「時間独立(time-independent)」であるようにする必要がある。その上、企業自体が動的に変化するので、業務運用をサポートする情報システムも同様に変化することになる。つまり、企業のコンピューティング環境は「オープン」にする必要がある、すなわち十分な柔軟性を備えて新しい標準に容易に移行しつつ一貫性を維持し既存の「古い(legacy)」システムならびにデータへもアクセスできる必要がある。古いシステムはネットワーク化した資源の追跡のために静的テーブルの使用に依存することが多い。このようなシステムは動的な回復をサポートしておらず、このようなテーブルを頻繁に変化する環境で維持するために必要とされる極めて大きなオーバヘッドのため、企業全体での展開へと容易に拡張することはできない。既存のシステムでは、ネットワークへ接続したひとつの資源が別の資源の存在を発見するために、両者が活動化(alive)している必要がある。ネットワークへ接続された資源の総数が増大すると、時間独立の資源発見のためのメカニズムを備え新しい資源が利用できるようになるとこれに併せてネットワークが自動的に作成されるようになることが重要になる。既存のシステムは、何らかのノード、例えば計算機、エリア、グループ、ドメイン、ネットワーク等で仮定できる固定の数の役割または階層レベルしか利用できないことでも制限されている。この制限は異なる階層構造を有する２つまたはそれ以上の既存のネットワークを買収または統合する場合に顕著な問題となって現れる。さらに、従来技術のシステムでは、あるノードが複数の役割を果すと仮定した場合に、これらの役割の間の関連性があらかじめ規定される。つまり、レベル１で（例えば計算機）とレベル３（例えばグループ・マネジャ）とで機能するためには、ノードはレベル２の機能（例えばエリア・マネジャ）も仮定する必要がある。この制限がシステムの性能および回復を大幅に悪化させることがある。頑丈で、効率的な企業全体に渡るコンピューティング環境、例えばリアルタイム・メッセージング、メッセージ・キューイング、リモート手続き呼出し、プロセス間通信、ブロードキャスト／発行(publish)および登録(subscribe)などを確立することに関連した問題に対処しようとする従来の試みは部分的に最良の解決方法しか示していない。真の分散コンピューティングではピア・ツー・ピア通信をあらかじめ想定していることから（マスター処理の傷害はスレーブ処理の傷害に必ず波及するため）、クライアント・サーバに基づいた企業コンピューティング目標を実現するアプローチは必ずしも最適な解決方法を示してはいない。静的テーブルを使用する既存のピア・ツー・ピア・システム(peer-to-peer systems) では、動的な回復が行なえず、スケーラビリティと保守に重大な問題を呈している。発明の要約本発明は、動的、対称型、分散、リアルタイム、ピア・ツー・ピア・システムであって互いに論理木を構成する任意の個数の同一の（意味的に等価な）インスタンス、すなわちカーネルから構成される。カーネルはネットワークの自己設定および自己維持論理ビューによってランタイムに統一的かつ一貫した動作(b ehavior)を示す。各カーネルは１つ以上の資源が関連するネットワーク・ノードに存在する。カーネルはリアルタイムで互いを動的に位置づけて(locate)、独立して動作する事実上個数制限のないカーネルをサポートする階層構造を形成し維持する。本システムはネットワークおよびユーザが開発したプログラム資源の論理ビューをトランスポート・プロトコルの個数と組み合わせや基本となる物理トポロジーの混合とは無関係に維持する。本システムの通信サービスは動的コンテキスト・ブリッジを使用して共通のトランスポート・プロトコル・スタックを共用できない端末ノード間で通信することにより、異なるスタックに存在するアプリケーションどうしが自動的かつ透過的に通信できる。本システムは、音声、サウンド、静止画および動画、大量のファイル転送、従来のトランザクション処理、および「グループウェア」等のアプリケーションで必要とされるような多対多カンファレンス(any-to-any conferencing)を含む全てのディジタル通信の形態をサポートするように設計されている。本システムはまたＩＳＤＮ、Ｘ．２５、ＴＣＰ／ＩＰ、ＳＮＡ、ＡＰＰＣ、ＡＴＭ等を含むあらゆる種類のネットワーク・プロトコルおよび媒体上で動作するように設計される。全ての場合において、本システムは基本となる媒体の理論伝送容量すなわち帯域幅に対し高い比率、典型的には６０ないし９５％を配信する。新しい資源がネットワークに結合する（または再結合する）と、各ノードに存在するカーネルとそのノードに接続しているそれぞれの資源が、自動的にまたすぐに本システムを使用する全てのアプリケーションでアクセス可能になる。使用される管理階層（例えばエリア・マネジャ、ドメイン・マネジャ、ネットワーク・マネジャ等）の内部の何らかのノードに想定される役割(role)は恣意的、すなわちいずれのノードも階層内の１つまたは複数の役割を想定でき、ひとつの役割を想定することでいずれかの他の役割の想定を必要とすることもなくまた排除することもない。さらに、役割がネットワークの要件に基づいて、すなわち１つ以上のノードがネットワークに参入または離脱すると動的に変化する。つまり個々のカーネルどうしが互いに動的に位置づけあい、ネットワーク階層を管理する上で関連するノードにより果たされる役割を、これらの物理的ロケーションと無関係に取り決める。さらに、いずれかのノードに仮定される可能な役割またはレベルの個数は無制限で、ネットワーク環境の特定の要件に基づいて選択することができる。図面の簡単な説明本発明の上記のおよびその他の特徴および利点は、添付の図面シートとの関連において好適実施例についての以下の詳細な説明を参照することによってさらに良くまたさらに完全に理解されよう。図面において、図１は本発明による分散コンピューティング・システムを示す図である。図２は図１のシステムにおけるノードのひとつの詳細ブロック図である。図３は本発明によるカーネルの構造を示すブロック図である。図４は本発明のＰＩＰＥＳ論理ネットワーク（ＰＬＮ）の流れ図である。図５は本発明による子ログイン手続きの流れ図である。図６は本発明による親ログイン手続きの流れ図である。図７は本発明による異なるノード間のログイン通信を示す図である。図８は本発明によるロール・コール(roll call)手続きの流れ図である。図９は本発明による異なるノード間のロール・コール(roll call)通信を示す図である。図１０は本発明による子のモニタ手続きの流れ図である。図１１は本発明による親のモニタ手続きの流れ図である。図１２は本発明による異なるノード間の「心拍(heartbeats)」モニタ通信を示す図である。図１３は本発明による選出処理(election process)の流れ図である。図１４は本発明による異なるノード間での選出通信を示す図である。図１５は本発明によるログアウト処理の流れ図である。図１６は本発明による異なるノード間でのログアウト通信を示す図である。図１７は本発明の資源に関する活動を示す図である。図１８は本発明による「資源追加(Add Resource)」処理の流れ図である。図１９は本発明の「資源検索(Find Resource)」処理の流れ図である。図２０は本発明のエリア・マネジャ・ノードでの「資源検索」処理の流れ図である。図２１はエリア・マネジャより上のレベルでの本発明による「資源検索」処理の流れ図である。図２２は本発明のエリア・マネジャ・ノードでの「持続性検索(Persistent Fi nd)」処理の流れ図である。図２３はエリア・マネジャより上のレベルでの本発明による「持続性検索(Per sistent Find)」処理の流れ図である。図２４は本発明のエリア・マネジャ・ノードでの「クリーン持続性検索(Clean Persistent Find)」処理の流れ図である。図２５はエリア・マネジャより上のレベルでの本発明による「クリーン持続性検索(Clean Persistent Find)」処理の流れ図である。図２６はエリア・マネジャがダウンする際の本発明による「資源回復(Resourc e Recovery)」処理の流れ図である。図２７は別の管理ノードがダウンする際の本発明による「資源回復(Resource Recovery）」処理の流れ図である。図２８は本発明による「資源削除(Remove Resource)」処理の流れ図である。図２９Ａは本発明のコンテキスト・ブリッジのコンポーネントを示す。図２９Ｂは異なるプロトコル間での通信のためのコンテクスト・ブリッジの使用を示す例である。図３０は本発明によるコンテクスト・ブリッジによるルーティング処理を示す流れ図である。図３１は本発明による「ルート発見(Route Discovery)」処理の流れ図である。図３２は本発明による「ルート検証(Route Validation)」処理の流れ図である。図３３は本発明による「ルート・アドバタイズメント(Route Advertisement) 」処理の流れ図である。図３４は本発明のＰＩＰＥＳ論理ネットワークでのレベル数変更において実行されるステップを示す流れ図である。発明の詳細な説明図１は本発明による分散計算システム１００を示す。本発明の譲受人によるシステム１００の実施はＰＩＰＥＳプラットホーム（ＰＩＰＥＳ）と呼ばれる。システム１００において、２つのノード、ノード１（ブロック１として図示してある）とノード２（ブロック１４として図示してある）が物理ネットワーク接続（線２７で図示してある）を経由して通信する。ネットワーク２７に接続されるノード数は２つに限定されないことが当業者には明らかなはずである。ノードの構造は実質的に同一である。そのため、ノードの１つだけ、例えばノード１だけを詳細に説明する。３つのアプリケーション、ＡＰＰＡ（ブロック２として図示してある）、ＡＰＰＢ（ブロック３として図示してある）、ＡＰＰＣ（ブロック４として図示してある）がノード１で実行されている。これらのアプリケーションはＰＩＰＥＳ上で実行するようにアプリケーション・デベロッパにより書かれるのが典型的である。ＰＩＰＥＳソフトウェアはＡＰＰＡ〜Ｃと通信するためのＰＩＰＥＳプリケーション・プログラマ・インタフェース（ＰＡＰＩ）（ブロック６として図示してある）を含む。ＰＡＰＩ６はノード１で実行されている１つのＰＩＰＥＳカーネル（ブロック９として図示してある）にプロセス間通信（Interprocess Communication：ＩＰＣ）ファンクション・コール（ブロック７として図示してある）によりメッセージを送信する。カーネル９はトランスポート(transport)デバイス・ドライバＴＤ₁（ブロック１１として図示してある）、ＴＤ₂（ブロック１２として図示してある）、ＴＤ₃（ブロック１３として図示してある）を介してネットワーク２７上でメッセージを送受信する。同様に、ノード２は３つのアプリケーション、ＡＰＰＸ（ブロック１５として図示してある）、ＡＰＰＹ（ブロック１６として図示してある）、ＡＰＰＺ（ブロック１７として図示してある）がそこで実行しており、ＰＡＰＩ（ブロック１８として図示してある）およびＩＰＣ（ブロック１９として図示してある）を介してノード２で実行している１つのＰＩＰＥＳカーネル（ブロック２１として図示してある）と通信する。ノード２は３種類の異なるネットワーク・プロトコルをサポートしており、３つのトランスポート・ドライバＴＤ₃（ブロック２４として図示してある）、ＴＤ₄（ブロック２５として図示してある）、ＴＤ₅ （ブロック２６として図示してある）を含む。例えば、ノード１のＡＰＰＡがノード２のＡＰＰＺと通信する必要がある場合、メッセージはＡＰＰＡからＰＡＰＩ６、ＩＰＣ７、カーネル９を経由して伝えられる。カーネル９はそれ自身のトランスポート・ドライバＴＤ₃を使用してネットワーク２７上でノード２のトランスポート・ドライバＴＤ３へメッセージを送信する。メッセージはノード２でカーネル２１、ＩＰＣ１９、ＰＡＰＩ１８、そして最終的にＡＰＰＺへ渡される。ＰＩＰＥＳはこれのコンポーネント部品全部で使用される汎用サービス(gener ic service)も提供している。ネットワーク管理サービス(Network Management S ervices)（ブロック１０およびブロック２０として図示してある）はＰＩＰＥＳネットワーク管理エージェント(Network Management Agent)へのアクセスを提供してカーネルのネットワーク・レベルおよびシステム・レベルのカウンタ、属性、統計をモニタする。汎用サービス（ブロック８および２２として図示してある）はカーネル９および２１からオペレーティング・システム・サービスへの、ハッシュ、Ｂツリー、アドレス操作、バッファ管理、キュー管理、ロギング、タイマ、タスク・スケジューリング等を含む共通インタフェースを提供する。システム依存サービス(System Dependent Services)（ブロック５および２３として図示してある）はオペレーティング・システム、プラットホーム、環境、およびノードへの転送に特有のサービスを提供する。これらのサービスは汎用サービス（ブロック８および２２として図示してある）で使用されて、任意のオペレーティング・システムまたはプラットホーム環境での汎用サービスを実現する。図２はシステム１００のノード１内部のＰＩＰＥＳ内部アーキテクチャのさらに詳細なブロック図を示す。ＰＩＰＥＳアーキテクチャは３つの異なる層に分割される：インタフェース層(Interface Layer)（ブロック２８として図示してある）、カーネル層(Kernel Layer)（ブロック２９として図示してある）、トランスポート層(Transport Layer)（ブロック３０として図示してある）の３つである。インタフェース層２８はＰＡＰＩ６経由でＰＩＰＥＳ環境にアクセスするアプリケーションからの問い合わせとアプリケーションへの応答を取り扱う。インタフェース層２８はカーネル９にアクセスするそれぞれのアプリケーション（例えばＡＰＰＡ〜Ｃ）にリンクされるライブラリとして実現する。カーネル層２９はＰＩＰＥＳにアクセスするアプリケーションへプログラム資源ならびに通信管理サービスを提供し、トランスポート・プロトコル・スタックを共用していない端末ノード間の通信を行なえるようにする。トランスポート層３０はノード１でサポートされるネットワーク・プロトコルのためのトランスポート・デバイス・ドライバ１１，１２，１３から構成される。それぞれのトランスポート・ドライバはカーネル９から別のベンダが提供するネットワーク・トランスポート・プロトコル例えばＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、またはＤＬＣなどへのアクセスを提供する。トランスポート層３０は任意のトランスポー卜方式のために任意のプラットホームに発行されるトランスポート専用ＡＰＩの全てを取り扱う。図３はカーネル９の内部アーキテクチャを示す。カーネル９は図２のＰＡＰＩ６へのインタフェースであるＡＰＩインタフェース（ブロック３１として図示してある）を含む。ＡＰＩインタフェース３１はインタフェース層２８からの要求を取り扱いこれらの要求への応答を返す。ＡＰＩインタフェース３１はアプリケーションのプライオリティを認識して、このプライオリティに基づいてアプリケーションのメッセージをキューに入れる。ＡＰＩインタフェース３１はリソース層（ブロック３２として図示してある）からの応答とセッション・サービス（ブロック３５として図示してある）からの応答も取り扱い、適切なアプリケーションへこれらの応答をルート(route)する。リソース層(Resource Layer)３２はＰＩＰＥＳ論理ネットワーク（ＰＬＮ）層内部のアプリケーション資源を登録し、ＰＩＰＥＳ内部の他のＰＡＰＩ資源を検索する能力を提供し、ネットワーク内部で資源の登録取消しを取り扱う。さらに、リソース層３２はＰＬＮ３３にまだ登録されていないリソースの位置づけを行なえるようにする「持続性検索」能力を実現する。ＰＬＮ３３はＰＩＰＥＳ内部のノードの論理的、階層的関連性の知識を維持して動的管理のフレームワークを執行する。ＰＬＮ３３はマネジャの選出、物理ネットワークの障害の結果として管理階層の透過的再構築(transparent reestabli shment)を取り扱う。ＰＬＮ３３はネットワーク内部のノードの状態をモニタするために使用する「心拍」メッセージのシステムを使用してネットワーク障害を識別する。この層は要求を取り扱いさらにリソース層３２や肯定応答データグラム・サービス(Acknowledged Data gram Service：ＡＫＤＧ、ブロック３４として図示してある）への応答を返す。ＡＫＤＧ３４はユーザに対して障害時再送信による最善のデータグラム・サービスを提供する。ＡＫＤＧ３４は無接続(connectionless)メッセージング・サービス（ＣＬＭＳ）３６とセッション・サービス(Session Services)３５によるメッセージの送受信を取り扱う。セッション・サービス３５はユーザのためのセッションを割り当て、管理し、また割り当て解除する。セッション管理はユーザから送信されたデータを順番に送受信し、セッションの安全な使用を保証し、接続指向メッセージング・サービス(Connection Oriented Messaging Service：ＣＯＭＳ)ストリーム・プロトコルに対するメッセージの意味を維持する。セッション・サービス３５はＰＡＰＩアプリケーションが保有するセッションに対してＰＡＰＩアプリケーション・メッセージをマルチキャストする。セッション・サービス３５はＣＯＭＳ３７と相互作用してＡＫＤＧ３４およびＡＰＩインタフェース３１からの要求を満たす。ＣＬＭＳ３６は配信(delivery)の保証なしにデータを転送する。またこれはコンテクスト・ブリッジ層(Context Bridge Layer)３８と相互作用してＡＫＤＧ３４からの要求を満たす。ＣＯＭＳ３７はセッション・サービス３５が開いた接続を管理する。ＣＯＭＳ３７はユーザ向けメッセージのフラグメンテーション(fragmentation)およびリアセンブリ(reassembly)を含む高性能データ転送を提供する。ＣＯＭＳ３７は接続終点(connection endpoints)間のホップ(hop)の最大メッセージ・サイズに基づいてメッセージ・サイズを変更する。コンテクスト・ブリッジ層３８は多数のネットワーク・トランスポートに対して動的トランスポート・プロトコル・マッピングを行ない、端末間(end-to-end) プロトコルがことなる場合でもデータ転送が行なえるようにすることでＰＡＰＩアプリケーションを基盤となるネットワークから切り離す。トランスポート・ドライバ・インタフェース（ブロック３９として図示してある）はトランスポート専用ドライバとＣＬＭＳ３６およびＣＯＭＳ３７層との間の通信を取り扱う。このインタフェースは全てのトランスポート・ドライバのための汎用共通コードを含む。ＰＬＮ層ＰＬＮ３３はカーネルを実行する一組の計算機にシステム・アドミニストレータが割り当てた階層構造である。これらのカーネルはランタイム時に統合されて任意の階層レベルを管理する動的に選出されたマネジャと共に階層ネットワークを構成する。ＰＬＮネーム・スペースは５つの異なるレベルに分割される：ノーマル、エリア、グループ、ドメイン、ネットワークの５つである。スタートアップ時に全てのカーネルはノーマル優先権(normal privileges)を有する。これはネットワークでの設定に依存する管理上の役割とすでに引受けている多数の役割としてのリアルタイムの考慮を想定している。つまり、管理機能はメンバ・カーネルの間で均等に分散されるようになり、良好な機能と高速な回復を提供する。レベル数は５に制限されるものではなく、システム内で後述のようにどのようなレベル数でも実現できることを理解すべきである。ＰＬＮ３３において、ネットワーク・マネジャ(Network Manager)とエリア・マネジャ(Area Manager)との間の各種マネジャ（例えばドメイン・マネジャやグループ・マネジャ）が行なう主な役割は基本的に同じで、親や子との通信を維持することと、リソース層３２トラフィックをルートすることである。これらの機能に加えて、ネットワーク・マネジャとエリア・マネジャとの間の全てのマネジャ（例えばドメインまたはグループ）も図２２および図２３との関連で後述するように持続性検索ソース・キャッシング・サービス(source caching serv ices)も提供する。エリア・マネジャは、前述の機能に加えて、これの子がアドバタイズし、エリア・マネジャのネーム・スペース内のカーネル全部を含む、資源のキャッシング・サービスを提供する。よってエリア・マネジャは、階層内の他の全ての役割より前にエリア・マネジャの役割を満足させることで基礎から構築されるＰＬＮ３３の順序だった機能に必須である。図４に示してあるように、ＰＬＮ構築および維持のアルゴリズムは５つの主な処理を含む：ログイン（ブロック１００として図示してある）、ロール・コール (Role Call：ブロック２００として図示してある）、モニタ（ブロック３００として図示してある）、選出（ブロック４００として図示してある）、ログアウト（ブロック５００として図示してある）。本明細書では、以下の述語を適当な抽象化ができるように使用する：ＰＬＮ３３のレベル数はMinLevelとMaxLevelで定義される。通常の優先権を有するカーネルはMinLevelに設定され、マネジャではない。一方で、ネットワーク・マネジャであるカーネルはMaxLevelに設定されネットワーク・ルートになる可能性がある。設定パラメータMaxStatusはカーネルがマネジャとなり得る最高レベルの上限を設定する。レベルｎにあるカーネルは、レベルｎより上で２つのカーネルが同じ名前を有するとすればレベルｎ＋１にある親(parent)カーネルの子(child)であるという。ログイン図５および図６はＰＬＮ３３の子および親ノードで実行されるログイン手続きを示している。ログインは子カーネルが親カーネルを位置づけ登録する処理である。図７はノードＮ７のカーネル（円３７として図示してありカーネルＮ７と呼ばれる）がネットワークに入るためのログイン処理を実行するログイン処理の仮定的な実行の間にカーネル間で渡されるメッセージを示している。カーネルがログイン処理を実行して親カーネルを位置づけてネットワークに入る。子カーネルは最初に待ち期間(wait period)（ステップ１０１）に入り、ここでは子カーネルがネットワーク上の他のログイン・ブロードキャストを聴取(l isten for)する（ステップ１０２）。ログイン・ブロードキャストを待ち期間の間に受信した場合（ステップ１０３）、子カーネルはメッセージを読み取る。メッセージ内の情報は子が親とその兄弟の識別を確認するのに十分なものである。メッセージ発信側が兄弟であれば（ステップ１０４）子カーネルはログイン待ち期間の間隔を変更し（ステップ１０５）、ログイン・ブロードキャストがネットワークに氾濫しないようにする。メッセージ発信側が親の場合（ステップ１０６）、子カーネルはログイン要求を親に送信し（ステップ１０７）、肯定応答を待つ。ログイン・ブロードキャストが受信されない場合、子カーネルは待ち期間の終了までログイン・ブロードキャストを聴取し続ける（ステップ１０８）。待ち期間の終りで、子カーネルはログイン・ブロードキャストをネットワークに送信する（ステップ１０９）。図７において、カーネルＮ７はノードＮ１のカーネル（円３１で表してありカーネルＮ１と呼ぶ）、ノードＮ２のカーネル（円３２で表してありカーネルＮ２と呼ぶ）、ノードＮ３のカーネル（円３３で表してありカーネルＮ３と呼ぶ）、ノード４のカーネル（円３４で表してありカーネルＮ４と呼ぶ）、ノードＮ５のカーネル（円３５で表してありカーネルＮ５と呼ぶ）、ノードＮ６のカーネル（円３６で表してありカーネルＮ６と呼ぶ）にログイン・ブロードキャスト・メッセージを送信することによりＰＩＰＥＳネットワークへのログインを試みる。子カーネルはログイン肯定応答を受信するまで指定された時間だけ待つ（ステップ１１０）。全てのカーネルはネットワーク上のログイン・ブロードキャスト・メッセージを聴取する（ステップ１１６）。ログイン・ブロードキャストが受信されると（ステップ１１７）、親カーネルはそのメッセージを送信したカーネルが自分の子であるかどうかを判定する（ステップ１１８）。発信側カーネルが子ではない場合、親はログイン・ブロードキャストを聴取し続ける（ステップ１１６）。しかし、発信側カーネルが子である場合には、親はこのカーネルが重複した子かどうかをチェックする（ステップ１１９）。これが重複した子である場合，親は重複している子に対して役割の衝突(role conflict)を通知する（ステップ１２０）。そうではない場合、親はログイン肯定応答を子カーネルに送信する（ステップ１２１）。図７において、親カーネルＮ４はカーネルＮ７のログイン・ブロードキャスト・メッセージａを受信し、カーネルＮ７への線ｂで表されるログイン肯定応答メッセージを送信する。ログイン肯定応答が受信されると（ステップ１１０）、子カーネルはログイン肯定応答を送信した第１の親カーネルにログイン確認(confirmation)を送信する（ステップ１１４）。子カーネルはそれ以外のログイン肯定応答を受信したとしても無視する。ログイン確認を親に送信した後、子カーネルは新しい親とモニター処理を開始する（ステップ１１５）。親カーネルがログイン確認を受信すると（ステップ１２２）、親カーネルは子を登録し（ステップ１２３）、新しい子とのモニタ処理を開始する（ステップ１２４）。親カーネルがログイン確認を子から受信しない場合（ステップ１２２）、親カーネルはログイン・ブロードキャストを聴取し続ける（ステップ１１６）。図７において、親カーネルＮ４のログイン肯定応答ｂを受信した後、子カーネルＮ７はカーネルＮ４へ線ｃで表してあるログイン確認メッセージを送信し親カーネルＮ４とモニタ処理を開始する。どの親カーネルも子に対してログイン肯定応答を送信しない場合、子カーネルはリトライ域値(retry threshold)が超過されるまで（ステップ１１１）ログイン処理を再開する（ステップ１０１）。リトライ域値が超過された場合、子はMa xStatus設定をチェックする（ステップ１１２）。子のMaxStatusがMinLevelより大きい場合、子はロール・コール(Role Call)処理を開始して自分自身の親の役割(role)を引受ける。それ以外の場合には、子カーネルはまたログイン待ち期間に入る（ステップ１０１）。ロール・コールロール・コール(Role call)はカーネルがネットワークにネーム・スペース階層の空き(vacancy)を見つけ出すように問い合わせる手続きである。この手続きはMinLevelよりMaxStatusが大きく設定された全てのカーネルで実行される。ロール・コール手続きはスタートアップ時とそれ以降で管理上の空きが存在する場合にカーネルが起動する。ロール・コール・アルゴリズムはロール・コール処理に同時に参加するカーネル個数が最小となるように設計してあり、ネットワーク全体のブロードキャストを低減すると同時に同じ空きに対する潜在的な競合相手との衝突を減少する。ロール・コール手続きは図８に図示してある。ロール・コールに参加しようとするカーネルは強制的に待ち期間に入る（ステップ２０１）。待ち期間はカーネルがアクティブ・コンテクスト・ブリッジかどうかまたカーネルの現在の状態をカーネルがすでに引受けた役割個数の関数である。ランダム待ち間隔も等式に加算される。待ち期間の間、カーネルは他のカーネルからのロール・コール・ブロードキャストを聴取する（ステップ２０２）。ロール・コール・ブロードキャストを階層の同じレベルで受信した場合（ステップ２０３）、カーネルはロール・コール手続きを放棄する（ステップ２０４）。ロール・コール・ブロードキャストを受信しなかった場合、カーネルは待ち期間の終了まで（ステップ２０５）ロール・コール・ブロードキャストを聴取し続ける（ステップ２０２）。待ち期間の終りで、カーネルはネットワーク上に自分自身のロール・コール・ブロードキャストを送信する（ステップ２０６）。ブロードキャスト・メッセージはロール・コールが要求している階層のレベルを含む。ロール・コール・ブロードキャストの送信後、カーネルはタイマーを起動し（ステップ２０７）、ネットワーク上のロール・コール・メッセージを聴取する（ステップ２０８）。ロール・コールが要求されているネームスペースのマネジャであるカーネルは、２地点間(point-to-poin t)ロール・コール肯定応答メッセージで応答する。ロール・コールを開始したカーネルが肯定応答を受信した場合（ステップ２０９）、カーネルはロール・コール手続きを放棄する（ステップ２０４）。ロール・コールを開始したカーネルがかわりに階層の同じレベルで別のロール・コール・ブロードキャストを受信した場合（ステップ２１０）、カーネルはメッセージを読み取る。メッセージ発信側が高いクレデンシャル(credential)を有している場合（ステップ２１１）には、カーネルはロール・コール手続きを放棄する（ステップ２０４）。特定のカーネルのクレデンシャル(credential)は、カーネルがアクティブ・コンテクスト・ブリッジかどうかまたカーネルの現在の状態についてすでにカーネルが想定した役割個数の関数である。タイムアウト期間の終了時に（ステップ２１２）、カーネルはロール・コールを要求した空いている管理上の役割を引受ける。図９はロール・コール手続きの例を示す。円４４で表してあるカーネルＮ４は、物理的接続の問題のためネットワークから分離される。円４７で表されるカーネルＮ７は、これの親カーネルＮ４とのモニタ処理の結果として（詳細に以下で説明する）カーネルＮ４が存在しないことを検出する。カーネルＮ７は強制待ち期間に入りネットワーク上のロール・コール・ブロードキャストのトラフィックを聴取する。円４５で表されるカーネルＮ５がカーネルＮ７より前にロール・コール処理を開始した場合、カーネルＮ７は破線ｉで表されるロール・コール・ブロードキャスト・メッセージを受信後にロール・コールをアボート(abort)する。しかし、カーネルＮ７がロール・コールを最初に開始したと仮定すると、カーネルＮ７は破線ｈで表されるブロードキャスト・メッセージをロール・コール・待ち期間の終了時に送信する。カーネルＮ７がすでに自分自身のロール・コール・ブロードキャスト・メッセージを送信した後でカーネルＮ５が自分自身のロール・コール・ブロードキャスト・メッセージを送信した場合、カーネルＮ７は自分のクレデンシャルをカーネルＮ５のクレデンシャルと比較する。カーネルＮ５のクレデンシャルの方が高い場合、カーネルＮ７はロール・コールを放棄し、カーネルＮ５はカーネルＮ４の消失により空きのままになっている管理上の役割を引受ける。カーネルＮ７のクレデンシャルの方が高い場合、カーネルＮ５はロール・コールを放棄しカーネルＮ７はタイムアウト期間の終了時にカーネルＮ４の空いた管理上の役割を引受ける。カーネルＮ４がネットワーク上に再出現しカーネルＮ５のブロードキャスト・メッセージｉまたはカーネルＮ７のブロードキャスト・メッセージｈを受信した場合、カーネルＮ４はカーネルＮ５へ線ｊでまたはカーネルＮ７へ線ｋで表される肯定応答メッセージを送信する。カーネルＮ４がネットワーク上に再出現しなかった場合、カーネルＮ５とカーネルＮ７はこれらのロール・コール処理を継続する。モニタ図１０および図１１は子と親が相互の追跡に使用するモニタ処理を示す。親は、自分自身の「心拍」タイマーを子どもの全部のうちで最も遅い心拍間隔に設定する。親はまず心拍タイマーをモニタ処理の開始時にリセットし（ステップ３１２）、子どもからの心拍メッセージを聴取する（ステップ３１３）。親とのモニタ処理に参加する子は第１に親へ心拍メッセージを送信し（ステップ３０１）肯定応答を待つ。心拍メッセージが親に受信されると（ステップ３１４）、親は子に心拍肯定応答を送信し（ステップ３１５）、子のリスト内に子が含まれているかをチェックする（ステップ３１６）。肯定応答メッセージは子どもの間で心拍間隔を離散させる心拍オフセット値を含む。子が心拍肯定応答を受信すると（ステップ３０２）、子は心拍間隔を変更し（ステップ３０６）待ち期間に入る（ステップ３０７）。子が心拍肯定応答を受信しない場合、親に別の心拍メッセージを送信する（ステップ３０３）。このときに心拍肯定応答が受信されると（ステップ３０４）、子は心拍間隔を変更し（ステップ３０６）待ち期間に入る（ステップ３０７）。子がまだ心拍肯定応答を受信していない場合、孤児になったものと解釈してログイン処理を開始する（ステップ３０５）。親の心拍タイマーの期限に達すると（ステップ３１７）、親は欠けた(missing )心拍メッセージについて子どものリストをチェックする（ステップ３１８）。親が欠けた心拍を検出すると、親は欠けた子に心拍メッセージを送信する（ステップ３１９）。親が欠けた子からの心拍肯定応答を受信しない場合、親は子の登録を取り消す（ステップ３２１）。待ち期間の間に（ステップ３０７）、子は親からの心拍メッセージを聴取する（ステップ３０８）。心拍メッセージを子が受信した場合（ステップ３０９）、子は親に心拍肯定応答を送信し（ステップ３１０）、心拍間隔を変更し（ステップ３０６）、再び待ち期間に入る（ステップ３０７）。待ち期間の終了時に（ステップ３１１）、子は再びモニタ処理を開始する（ステップ３０１）。図１２はモニタ処理の間に親と子との間で渡される定期的チェックイン・メッセージ、または「心拍」を示す。図１２において、カーネルＮ３とＮ４（それぞれ円５３、円５４で表してある）はカーネルＮ２（円５２で表される）の子である。カーネルＮ２はさらにカーネルＮ１（円５１で表される）の子である。メッセージｄ₁からｄ₃は子から親への心拍メッセージを表し、メッセージｅ₁からｅ₃ は親から子への心拍肯定応答を表す。メッセージｆ₁からｆ₃は親から子への心拍メッセージを表し、メッセージｇ₁からｇ₃は子から親への心拍肯定応答を表す。選出ＰＩＰＥＳカーネルは分散選出(distributed Election)（図１３）に従事して役割の衝突が発生した時の勝者を決定する。ネットワークのフラグメンテーションを発生させる基盤となる物理接続での問題が存在する時に、同じネームスペース上で２つまたはそれ以上のマネジャが管理上の責任を主張することがある。ネームスペースでの衝突は前述のようにロール・コールまたはログイン・ブロードキャストのどちらかにより最初に検出される。カーネルがネームスペースの衝突を検出すると、カーネルから本人(principals)に通知し、本人が選出処理を実行する。新規参加者(participants)はすでに始まっている選出に参入できる。選出は完全に分散しているので、それぞれのカーネルは別々に選出を処理して結果に達する。カーネルが役割の衝突を検出するか衝突を通知された場合、カーネルは選出タイマーを起動し選出データベースを開いて選出処理を開始する（ステップ４０１）。カーネルはこれまでに分かっている選出参加者を保存し、選出要求をそれぞれに送信する（ステップ４０２）。このメッセージは選出に参加している既知の全てのカーネルから構成される。カーネルは次にネットワーク上の選出トラフィックを聴取する（ステップ４０３）。カーネルが既知の参加者のリストを含む選出応答を受信すると（ステップ４０４）、カーネルは新規選出参加者をデータベース内に保存しそれぞれに選出要求を送信する（ステップ４０２）。別の選出要求を受信すると（ステップ４０５）、カーネルは発信側に選出応答を送信し（ステップ４０６）、選出データベースを更新し、新規参加者に選出要求を送信する（ステップ４０２）。選出タイマーの期限が切れると（ステップ４０７）、カーネルは選出データベースに問い合わせて勝者を決定する（ステップ４０８）。選出の勝者は参加カーネルがアクティブなコンテクスト・ブリッジかどうかまたそれぞれのカーネルの現在の状態についてそれぞれの参加カーネルがすでに引受けた役割の個数に依存する。カーネルが選出の勝者の場合（ステップ４０９）、カーネルは全ての選出参加者に選出結果メッセージを送信する（ステップ４１０）。カーネルが選出に負けた場合、カーネルはマネジャとしての地位を明け渡し（ステップ４１１）子ども全部に新しい親を通知する。選出の全ての参加者は選出結果を検証し最終的に選出データベースを閉じる（ステップ４１２）。図１４は選出処理の例を示す。カーネルＡとＢ（それぞれ円６１と６２で表される）が独立に役割の衝突を検出したと仮定する。カーネルＡは選出要求メッセージ（矢印１）をカーネルＢに送信する。このメッセージはカーネルＡに知られている参加者から構成され、この時点ではカーネルＡとＢである。カーネルＢがこのメッセージを受信すると、カーネルＢはカーネルＡに選出応答メッセージ（矢印ｍ）を送信する。後に、カーネルＣがカーネルＢとの役割衝突を検出する。カーネルＣは選出要求メッセージ（矢印ｎ）をカーネルＢに送信する。カーネルＢは新規に参入したカーネルＣについて選出データベースを更新し選出応答メッセージ（矢印ｏ）をカーネルＣに戻す。このメッセージはこの時点でカーネルＢに知られている選出参加者を含み、言い替えればカーネルＡ、Ｂ、Ｃである。カーネルＣがこのメッセージを受信すると、新規競争者(contestant)カーネルＡを検出し、その選出データベースを更新し、選出要求メッセージ（矢印ｐ）をカーネルＡに送信する。この時点で、カーネルＡは（これの観点から）新規競争者に気がつき、カーネルＣのクレデンシャルでデータベースを更新し、カーネルＣの要求に応答する（矢印ｑ）。同様に、カーネルＤがカーネルＡだけが気がついている選出に参入する場合、すぐにカーネルＢとＣに気がつくことになる。ログアウトログアウト（図１５および図１６）はカーネルが親からの登録を抹消する手続きである。ログアウトはカーネルのシャットダウン論理の一部として、または階層の特定レベルのマネジャを明け渡す結果として開始される。子カーネル（図１６のカーネルＮ２として表される）は図１６でカーネルＮ１として図示した親にログアウト要求（矢印ｘで表される）を送信する（ステップ５０１）。親が子からログアウト要求を受信すると（ステップ５０６）、子にログアウト肯定応答（図１６で矢印ｙとして図示してある）を送信し（ステップ５０７）子の登録を取り消す（ステップ５０８）。子がマネジャの場合（ステップ５０３）、子はメッセージ（図１６でメッセージｚ₁からｚ₃で表してある）を送信して、子の全部に（すなわち図１６のカーネルＮ３、Ｎ４、Ｎ５）もはや親ではないことを通知する（ステップ５０４）。さらに、親カーネルは子について実行する選出処理の勝者を指名することによって子の中から後継者を指名する（ステップ５０５）。リソース層リソース層（図３のブロック３２）はＰＩＰＥＳネットワーク階層全体に分散した資源を全て管理する責任を有する。資源はネットワーク上の他のノードで実行される他のＰＩＰＥＳアプリケーションで利用可能なＰＩＰＥＳアプリケーションの機能的サブセットである。ＰＩＰＥＳ資源は良く定義されたサービス要素として考えることができ、１つ以上の要素は、全体として考えた場合に組み合わされて完全なサービスを形成する。図１７はＰＩＰＥＳにおける資源のライフサイクルを示している。資源は資源追加処理(Add Resource Process)によりネットワークに入る（ブロック６００）。資源により提供されるサービスを使用するためには、アプリケーションは資源検索処理(Find Resource Process：ブロック７００）を実行してＰＩＰＥＳアドレス空間内のロケーションを決定する必要がある。例えば、検索問い合わせ(Fin d Query)を実行して利用可能な資源のアドレスを取得した後、アプリケーションがセッション・サービス３５による資源でセッションを確立しようと試みることができる。アプリケーションが検索問い合わせを実行する時点で資源が利用可能ではない場合には、そのアプリケーションは持続性検索問い合わせ(Persistent Find Que ry)を代わりに実行することができ、探索基準(search criteria)に適合する資源が資源追加処理でネットワークに入って来るとすぐに、アプリケーションに資源の利用可能性を通知する。この場合、ＰＩＰＥＳ内のエリア・マネジャは保留(p ending)持続性検索問い合わせのキャッシュを維持しておき、こうした問い合わせにすぐに応答できるようにする。エリア・マネジャが物理ネットワークの障害によりＰＩＰＥＳ階層の残りの部分から切断された場合、回復メカニズム（ブロック８００）を用い、切断されたマネジャの責任範囲を代行する新規のエリア・マネジャで持続性検索キャッシュを再生成する。ネットワーク上のライフタイムの間、資源はネットワーク上のアプリケーションにサービスを提供することができる。資源を所有するアプリケーションがネットワークからその資源を削除する場合、リソース層は資源削除処理(Remove Reso urce Process：ブロック９００）を実行する。資源追加処理図１８はアプリケーションの資源をＰＬＮ３３に導入するために使用される資源追加処理(Add Resource Process)を示す。資源が生ずるノードは最初にローカル・リソース・データベースをチェックして同じ名前の資源がすでに存在していないかどうかを判定する（ステップ６０１）。このような資源が存在する場合、発信側ノードはユーザ・アプリケーションヘERRORを返す（ステップ６０２）。資源が存在しない場合、発信側ノードはその資源のエントリをローカル・データベースに追加する（ステップ６０３）。資源はこれの持続性検索問い合わせキャッシュをチェックして、そのノードで実行しているアプリケーションが資源を待っているかどうかを調べる（ステップ６０４）。新規資源が持続性検索キャッシュ内の探索基準のいずれかに適合する場合には、発信側ノードが持続性検索問い合わせを開始した発信側ユーザのアプリケーションに新規資源の属性を送信する。発信側ノードは新規資源が探索基準に適合した持続性検索問い合わせをキャッシュから削除する（ステップ６０６）。新規に削除された持続性検索問い合わせの範囲が計算機レベルより大きい場合（ステップ６０７）、発信側ノードはクリーン持続性検索問い合わせをその親ノードに送信する（ステップ６０８）。持続性検索処理の終了時に、またはどの持続性検索問い合わせも新規資源に一致しなかった場合、発信側ノードが親のエリア・マネジャへ資源追加要求を送信する（ステップ６０９）。エリア・マネジャがこれの子どもの１つから資源追加要求を受信すると（ステップ６１０）、エリア・マネジャは自分自身の分離した資源キャッシュに資源を追加する（ステップ６１１）。エリア・マネジャは自分自身の持続性検索キャッシュをチェックして、新規資源がキャッシュ内の問い合わせの基準のいずれかに適合するかどうかを判定する（ステップ６１２）。適合する場合、エリア・マネジャは持続性検索問い合わせを発信したノードに資源の属性を送信し（ステップ６１３）、持続性検索キャッシュから問い合わせを削除する（ステップ６１４）。その問い合わせの範囲がエリア・レベルより大きい場合（ステップ６１５）、エリア・マネジャはクリーン持続性検索問い合わせを親のグループ・マネジャに送信する（ステップ６１６）。資源検索処理ＰＬＮ３３内部で資源を探索するアプリケーションは、ＰＩＰＥＳカーネルへ送信する検索問い合わせ(Find Query)について３つの異なるオプションの１つを指定できる：検索、次検索(Finde Next)、または永続検索の３つである。検索問い合わせはローカル計算機で資源の探索(searching)を開始し、計算機レベルで資源が見付からなかった場合にはエリア・レベルに移行する。エリア・レベルで資源が見付からなかった場合には、探索(search)はグループ・レベルで継続され、さらにＰＩＰＥＳネットワーク階層まで同様に継続する。資源が特定のレベルで見付かった場合には、その資源の属性が資源を要求しているアプリケーションに送信される。アプリケーションが後に次検索問い合わせ(Find Next Query)を発行する場合、探索はＰＩＰＥＳ階層内で直前の探索が終了した場所から継続される。ユーザが持続性検索問い合わせを発行すると、発信側ノードはこれを通常の検索問い合わせに変換して、他の検索問い合わせと同様にネットワークに伝えられる。いずれかの資源がユーザに返される場合、検索問い合わせはネットワーク内で持続されない。しかし資源がＰＩＰＥＳ階層内に見付からない場合には、持続性検索問い合わせがエリア・マネジャの持続性検索キャッシュにおけるＰＩＰＥＳ階層内に保存される。図１９は発信側ノードで実行される資源検索処理を示す。検索または持続性検索問い合わせが開始されると、発信側ノードはバッファとして用いられて問い合わせの探索基準を満たす資源属性を保存している資源キャッシュをクリアする（ステップ７０１）。検索問い合わせが問い合わせの発信側で完全に調整されるため、また中間ノードのいずれにも状態が維持されないため、それぞれの問い合わせデータ・パケットは十分な情報を搬送して中間ノード(intermediate node)が探索を処理できるようにする必要がある。幾つかの情報の最も重要な部分は、ネットワーク内部での発信側ノードのロケーション、発信側ノードが所望する一致 (matches)の最大数(MaxMatches)、発信側ノードへ返された一致の現在の数(Curr Matches)、探索の範囲(Scope)、探索が最後に行なわれたレベル(Level)、およびそのレベルでの最後の探索の状態(Level Status)である。探索が検索問い合わせで始まるか持続性検索問い合わせで始まる場合、発信側ノードはこれらの変数の幾つかを初期化して計算機レベルで探索を開始する（ステップ７０２）。次検索問い合わせは直前の探索が終了した場所から次の探索を開始するように設計されているので、次検索問い合わせは発信側ノードにこの初期化ステップをスキップさせる。発信側ノードはCurrMatchesをMaxMatchesと比較して問い合わせた一致の最大数をすでにユーザが受信したかどうかを決定する（ステップ７０３）。CurrMatc hesがMaxMatchesと等しくない場合（CurrMatchesはMaxMatchesを越えられない）、発信側ノードは資源をチェックしてさらに何らかの資源がユーザに返すのに利用可能かを調べる（ステップ７０４）。分散型検索問い合わせが２つ以上の資源を発信側ノードに返したとしても、発信側ノードが資源をユーザへ１つずつしか返さないため、ローカル・キャッシュ内に資源が残ることがある。ローカル・キャッシュ内に資源が残っている場合、発信側ノードは最初の資源をユーザに返す（ステップ７０５）。資源キャッシュが空の場合、発信側ノードはLevel Status をチェックして最後の探索が終了した所を判定する（ステップ７０７）。そのレベルに利用可能な資源が残っていない場合にはLevel StatusがＥＯＦ（すなわち検索の終り）に設定される。Level StatusがＥＯＦの場合、発信側ノードはCurr Levelをインクリメントして階層の次のレベルで探索を継続する（ステップ７１０）。Level StatusがＥＯＦではない場合、発信側ノードはCurrLevelをチェックして、分散検索を開始する前にローカル計算機での探索を開始すべきかどうかを判定する（ステップ７０８）。CurrLevelがMachineに設定されている場合、発信側ノードはローカル・リソース・データベースを探索してローカル資源が探索基準に適合するかどうかを調べる（ステップ７０９）。ローカル資源が利用可能な場合、発信側ノードはMaxMatchesまで資源属性を問い合わせの資源キャッシュにコピーし、発見してキャッシュへコピーした一致の個数にCurrMatchesを設定する。発信側ノードは資源を要求したユーザへキャッシュから第１の資源を返す（ステップ７０５）。ローカル資源が見付からない場合、発信側ノードはLevel StatusをＥＯＦに設定し（ステップ７１１）、次にCurrLevelをインクリメントして次のレベルで探索を継続する（ステップ７０７）。 CurrLevelがMaxLevelを越える（ステップ７１２）かまたはScopeを越える場合（ステップ７１６）には、探索は完全にＰＩＰＥＳ階層全体で実行されたか本来の問い合わせの範囲を超過している。つまり、これらの条件のいずれかに一致した場合、探索は完了する。一致しない場合、発信側ノードは親であるエリア・マネジャに検索問い合わせを送信し、分散検索を開始する（ステップ７１３）。資源の属性が応答として返された場合（ステップ７１４）、発信側ノードは資源の属性を問い合わせの資源キャッシュにコピーし（ステップ７１８）ユーザに第１番目を返す（ステップ７１７）。検索が成功せずに終了した場合、発信側ノードはCurrMatchesを調べて何らかの資源がユーザに返されたかを調べる（ステップ７１５）。CurrMatchesがゼロより大きい場合、ユーザは資源の全部を受信しており、発信側ノードはユーザにＥＯＦを返す（ステップ７２３）。CurrMatche sがゼロの場合、また資源がネットワーク上で見付からなかった場合、発信側ノードはユーザが指定していれば持続性検索問い合わせを分配する（ステップ７１９）。これはノードで保留されている持続性検索問い合わせのリストに問い合わせを追加して持続性検索問い合わせの発生源を追跡する。ローカル計算機に存在する資源が問い合わせの探索基準に一致するかも知れない場合には（ステップ７２１）、発信側ノードは持続性検索キャッシュに問い合わせを追加し（ステップ７２２）、これを用いて探索基準を追跡しこれらの基準に適合する資源がＰＩＰＥＳ追加されるとすぐに返せるようにする。問い合わせの範囲が計算機レベルより大きい場合（ステップ７２４）、持続性検索問い合わせをエリア・マネジャへ送信する（ステップ７２５）。図２０および図２１はリソース層がＰＬＮ３３全体に検索問い合わせをルートする方法を示す。図２０はエリア・マネジャのレベルで実行される処理を示す。エリア・マネジャが検索問い合わせを受信すると（ステップ７２６）、エリア・マネジャはCurrLevelをチェックして探索が要求されたレベルを決定する（ステップ７２７）。CurrLevelがエリアより小さい場合（ステップ７２８）エリア・マネジャは検索問い合わせを送信したノードにエラーを返すが、これはエラーマネジャが問い合わせを誤って受信したためである（ステップ７２９）。CurrLeve lがエリアより大きい場合（ステップ７２８）、エリア・マネジャは子どもの１つから検索問い合わせを受信したのであれば（ステップ７３１）親に検索問い合わせを転送する（ステップ７３２）。したがって、エリア・マネジャはちょうど検索問い合わせを渡すことになるが、これは、探索が階層のより上のレベルで継続するべきだからである。探索がこのレベルで継続するとしても、エリア・マネジャは探索基準を分析してこのエリア内の資源が基準を満たすかどうかを決定する（ステップ７３０）。そうでない場合には、エリア・マネジャは検索問い合わせを送信側へ返す（ステップ７３８）。さらに、CurrMatchesがMaxMatc hesとすでに等しい場合（ステップ７３３）エリア・マネジャはまた検索問い合わせを送信側へ返す（ステップ７３８）。それ以外の場合、エリア・マネジャはリソース・データベースを探索して発信側ノードから見える一致を探す（ステップ７３４）。資源をＰＩＰＥＳに追加するユーザはどのアプリケーションがＰＩＰＥＳ内部でサービスまたは「可視性(visibility)」を利用できるか指定できる。見える一致が見付かった場合、最大のMaxMatches資源の属性が検索問い合わせにコピーされる（ステップ７３５）。MaxMatchesより多くの資源が見付かった場合（ステップ７３７）、エリア・マネジャはLevel StatusをOKに設定して（ステップ７３９）検索が次回次検索問い合わせを発行した時にこのレベルで継続されるようにする。それ以外では、エリア・マネジャはLevel StatusをＥＯＦに設定し、このレベルで利用可能な資源がこれ以上ないことを発信側ノードに通知する（ステップ７３６）。最後に、エリア・マネジャは検索問い合わせを送信側に返す（ステップ７３８）。ＰＬＮ階層（図２１）内部でエリア・マネジャより高い管理レベルでの検索問い合わせ処理はエリア・マネジャ・レベルの処理と同様だが、計算機とエリア・マネジャだけが資源データベースを保有することから探索が行なわれない点が異なっている。図２１のステップ７４０からステップ７４７までは図２０のステップ７２６からステップ７３３までと同じである。それぞれの場合で、探索をこのレベルまたはもっと高次のレベルで継続すべきかをノードが判定する。この場合、このレベルでの探索は検索問い合わせを次にマネジャの子どものそれぞれに転送することからなる。子どもがどれも検索問い合わせを見られなかった場合（ステップ７４８）マネジャは検索問い合わせを次の子に送信する（ステップ７４９）。これ以上子どもがなくなると、マネジャはLevel StatusをＥＯＦに設定して（ステップ７５１）検索問い合わせを送信側に返す（ステップ７５０）。図２２と図２３はネットワーク全体での持続性検索問い合わせを追加する処理を示し、図２４と図２５はネットワークから持続性検索問い合わせを削除するために使用する同様の「クリーンアップ(clean-up)」処理を示す。図２２では、エリア・マネジャ・ノードがＰＬＮ３３上で受信した持続性検索問い合わせを処理する（ステップ７５２）。第１に、エリア・マネジャが子どもの１つから問い合わせを受信した場合（ステップ７５３）、エリア・マネジャは問い合わせを保留永続検索のソース・リストに追加する（ステップ７５４）。このエリアの資源が持続性検索問い合わせの探索基準を満たし得ない場合（ステップ７５５）、エリア・マネジャは問い合わせを永続検索キャッシュに追加する。問い合わせのScop e（範囲）がエリア・レベルより大きい場合（ステップ７５７）エリア・マネジャは持続性検索問い合わせを親に送信する（ステップ７５８）。同様に、図２３では、エリアより高いレベルでマネジャが持続性検索問い合わせを受信する（ステップ７５９）。送信側がマネジャの子どもの１つの場合（ステップ７６０）、マネジャは問い合わせを保留永続検索のソースリストに追加する（ステップ７６１）。このレベルが問い合わせにおいて指定された探索基準内の場合、マネジャは問い合わせを子どもに転送する（その問い合わせを送信した子をできるだけ除く）（ステップ７６３）。問い合わせの範囲がこのレベルより大きい場合（ステップ７６４）マネジャは持続性検索問い合わせを親に送信する（ステップ７６５）。図２４と図２５には同様の処理が示してあるが、この処理が持続性検索問い合わせを、そのノードの保留永続検索のソース・リストから削除し（ステップ７６８、７７５）エリア・マネジャの永続検索キャッシュから削除する（ステップ７７０）ことによって「クリーンアップ」する。持続性検索回復処理分散型持続性検索問い合わせについて重要な情報がエリア・マネジャ・ノードの保持されることと、もっと限局した範囲で他の管理ノードに保持されるため、これらのノードの１つがクラッシュした場合またはＰＬＮ階層の他の部分から切断される場合に回復処理を行なわなければならない。図２６および図２７は、エリア・マネジャ（図２６）または別の管理ノード（図２７）がダウンする時に回復を提供するために使用する処理を表している。計算機が、選出処理で選択した新しい親エリア・マネジャにログインした時、子計算機は保留永続検索のソースリストを新しい親に送信する（ステップ８００）。新しいエリア・マネジャはこのリストを受信し（ステップ８０１）、子から受信した情報を用いて自分自身の保留永続検索のソースリストを更新する（ステップ８０２）。新しいエリア・マネジャはキャッシュ補充要求を親に送信する（ステップ８０３）。他のマネジャは要求を受信し（ステップ８０５）これをマネジャの保留永続検索ソースリスト内の子ども全部に送信する（ステップ８０６）。送信側がマネジャの子である場合（ステップ８０７）マネジャはＰＬＮ階層を遡り親へ要求を送信する（ステップ８０８）。最終的に、ＰＬＮ３３内の他のエリア・マネジャはキャッシュ補充要求を受信し（ステップ８０９）、新しいエリア・マネジャが永続検索キャッシュ内に問い合わせを有していれば（ステップ８１０）、受信側エリア・マネジャが新しいエリア・マネジャに永続検索キャッシュから一致する問い合わせを返送する（ステップ８１１）。新しいエリア・マネジャはＰＬＮ３３内の他のエリア・マネジャからの返信で自分自身の持続性検索キャッシュを更新する（ステップ８０４）。図２７はエリア・マネジャ以外のマネジャがダウンする場合に存在する状況を示す。新しいマネジャの子どもが保留永続検索のソースリストを新しいマネジャに送信する（ステップ８１２）。新しいマネジャはこれらのリストを受信し（ステップ８１３）子どもから送信された情報で保留永続検索のリストを更新する（ステップ８１４）。問い合わせのいずれかがこのレベルより高いレベルを範囲とする場合（ステップ８１５）には、問い合わせはＰＬＮ階層を遡り新しいマネジャの親へ送信される（ステップ８１６）。新しいマネジャの親は新しい子から取得した情報を用いて自分の保留永続検索のソースリストを検証する（ステップ８１７）。資源削除処理ＰＬＮ階層からアプリケーションが資源を引き上げる場合、リソース層３３は図２８に図示した資源削除処理(Remove Resource Process)を実行する。資源が生ずるノードは資源データベースに資源が存在するかを調べる（ステップ９０１）。資源が存在する場合、発信ノードはデータベースから資源を削除し（ステップ９０３）資源削除要求を親のエリア・マネジャへ送信する（ステップ９０４）。それ以外の場合、発信ノードはユーザへエラーを返す（ステップ９０２）。エリア・マネジャは資源削除要求を受信し（ステップ９０５）エリア・マネジャ資源キャッシュから資源を削除する（ステップ９０６）。コンテクスト・ブリッジ層図２９Ａはコンテクスト・ブリッジ層３８のコンポーネントを示す。コンテクスト・ブリッジ層の主な機能はルーティング処理(Routing process)（ブロック１０００）で、これは送信元ノード(source node)から宛先(destination)ノードへプロトコル・データユニット（ＰＤＵ）をルートすることである。送信元ノードと宛先ノードはルータブル・プロトコル(routable protocol)」を共用できる。ルータブル・プロトコルは、宛先アドレスだけから作られる宛先に到達させるためＰＤＵをどこに送信すべきかについて決定できるようなプロトコルであると定義される。送信元ノードはＰＤＵをルータブル・プロトコルに単に転送し、ルータブル・プロトコルそれ自体が宛先アドレスを解析してどのようにＰＤＵを宛先へ届けるか決定する。すなわち、ＰＤＵを送信元から宛先へ転送するために使用する中間ノードでは知識が必要とされない。ＰＩＰＥＳ内部では、ＴＣＰ／ＩＰとＳＮＡがルータブル・プロトコルで、ＩＰＸ、ＮｅｔＢＩＯＳ、およびＤＬＣは非ルータブル・プロトコルである。送信元ノードと宛先ノードが非ルータブル・プロトコルを共用する場合、または送信元ノードと宛先ノードが何のプロトコルも共用していない場合、中間ノードは送信元ノードと宛先ノードを「橋渡しする(bridge)」必要がある。この場合、ルーティング処理はルーティング情報データベース（ＲＩＤＢ：ブロック１４００として図示してある）を用いて送信元から宛先へＰＤＵをどのようにルートするか決定する。ＲＩＤＢはＰＤＵを非ルータブル・プロトコルにルートするかまたは送信元ノードがサポートしていないプロトコルにルートするために必要とされる情報を含む。ＲＩＤＢは２つのキャッシュを含む：送信元ルーティング・キャッシュ（ブロック１４０１）は非ルータブル・プロトコルに使用し、次ホップ(next-hop)・ルーティング・キャッシュ（ブロック１４０２）は非類似のプロトコルのブリッジに用いる。送信元ルーティング・キャッシュはルート発見処理（ブロック１１００）によってポピュレート(populate)しルート検証処理（ブロック１２００）で検証される。次ホップ・ルーティングキャッシュはルート・アドバタイズメント処理（ブロック１３００）でポピュレートする。図２９Ｂは本発明のコンテクスト・ブリッジが有利に使用できるシステム１６００を示している。コンテクスト・ブリッジは国際標準化機構（ＩＳＯ）基準モデルで定義されているように、異なるレベルのプロトコルを用いるノードで生成されたパケットのルートに用いることができる。例えば、システム１６００は２つのノード１６１０、１６３０を含み、これらはＳＮＡ（ＡＰＰＣ）とＤＬＣプロトコルをそれぞれ使用している。これら２つのプロトコルは異なるＩＳＯレベルにある。ＳＮＡはプレゼンテーション・レベルにあり、一方ＤＬＣはデータ・リンク・レベルにある。ノード１６１０からノード１６３０へネットワーク１６４０を経由してパケットをルートするには、ＳＮＡ（ＡＰＰＣ）とＤＬＣプロトコルをブリッジできるコンテクスト・ブリッジを含むノード１６２０を用いる必要がある。つまり、ノード１６１０が生成したパケットは最初に経路１６４２を介してノード１６２０へルートされ、ここから次に経路１６４３を介してノード１６３０へルートされる。同様に、ノード１６１０で生成したメッセージを、ＵＤＰプロトコル（ＩＳＯトランスポート・レベル）を使用するノード１６５０へルートすることが所望の場合、ＳＮＡとＵＤＰプロトコルをブリッジできるコンテクスト・ブリッジを含むノード１６６０を使用する必要がある。つまり、ノード１６１０で生成したパケットは経路１６４５を介して最初にノード１６６０へルートされ、次にここから経路１６４６を介してノード１６５０へルートされる。ルーティング処理図３０はコンテクスト・ブリッジ・ルーティング処理の流れ図を示す。送信元ノードのコンテクスト・ブリッジ層が任意の宛先ノードへ送信しようとするＰＤＵを受信すると、送信元ノードは宛先アドレスを調べて宛先がルータブル・プロトコルを使用しているかどうかを判定する（ステップ１００１）。宛先がルータブル・プロトコルを有する場合、送信元ノードは宛先と同じルータブル・プロトコルをサポートしているか否かを判定する（ステップ１００２）。送信元と宛先が同じルータブル・プロトコルを共用している場合、送信元は共用しているルータブル・プロトコル用のトランスポート・ドライバを使用して宛先へＰＤＵを送信する（ステップ１００３）。送信元と宛先が同じルータブル・プロトコルを共用していない場合、送信元は宛先へのルートについてＲＩＤＢ次ホップ・ルーティング・キャッシュを探索する（ステップ１００４）。送信元ノードはＲＩＤＢにルートが存在するか調べる（ステップ１００６）。ルートが見つかると、送信元はＲＩＤＢに見つかったルートで指定される中間ノードへＰＤＵを送信する（ステップ１００７）。ルートが見つからない場合、送信元は宛先に到達できないことを表すエラーを返す（ステップ１００９）。宛先が非ルータブル・プロトコルを有する場合、送信元は宛先へのルートについてＲＩＤＢ送信元ルーティング・キャッシュを探索する（ステップ１００５）。送信元ノードは次にＲＩＤＢにルートが存在するかどうかを調べる（ステップ１００８）。ルートが見つかった場合、送信元はＲＩＤＢにおいて見つかったルートにより指定された中間ノードへＰＤＵを送信する（ステップ１００７）。ルートが見つからなかった場合、送信元はルート発見処理(Route Discovery Proce ss)を実行して宛先へのルートを見つけようとする（ステップ１０１１）。送信元ノードは次にルート発見処理でルートが見つかったかどうかを確認する（ステップ１０１２）。ルートがルート発見処理で見つかった場合、送信元ノードはＲＩＤＢ送信元ルーティング・キャッシュを更新し（ステップ１０１０）、ルートで指定された中間ノードへＰＤＵを送信する（ステップ１００７）。ルートが見つからなかった場合、送信元ノードは宛先に到達できないことを表すエラーを返す（ステップ１００９）。ルート発見処理図３１はＲＩＤＢ送信元ルーティング・キャッシュを個別の宛先への送信元ルートで更新するために使用するルート発見処理を示す。非ルータブル・プロトコルを有する宛先へのルートを発見しなければならない時に、送信元ノードはルート発見処理を開始する。第１に、送信元ノードはルート発見パケットを情報を有しているアクティブ・コンテクスト・ブリッジの全部に送信する（ステップ１１０１）。ノードが２つ以上のプロトコルをサポートしている場合そのノードはアクティブ・コンテクスト・ブリッジであり、ノードはそのノードで見つかったプロトコルの間のブリッジとして機能する。ネットワーク内のノード全部がルート・アドバタイズメント処理によってアクティブ・コンテクスト・ブリッジを捜し出す。送信元ノードのルート発見パケットを受信するコンテクスト・ブリッジは第１にこれが返信パケット(reply packet)かどうかを判定する（ステップ１１０７）。これが返信パケットの場合、中間ノードは返信パケットに指定されているルートを用いて送信元ノードヘパケットを送り返す（ステップ１１１２）。これが返信パケットではない場合、ルート発見パケットを受信するノードはパケットに自分自身のアドレスを挿入する（ステップ１１０８）。ノードは次にパケットの意図した宛先かどうかを調べる（ステップ１１０９）。ノードがパケットの意図した宛先の場合、終端ノードはパケットの形式をREPLYに変更し（ステップ１１１１）、ルート発見パケットに指定されているルートを用いて送信元にパケットを送り返す（ステップ１１１２）。受信ノードが宛先ではない場合、パケットを初めに受信したコンテクスト・ブリッジを除き、中間ノードはこれが接続されている全てのコンテクスト・ブリッジへパケットを転送する（ステップ１１１０）。送信元ノードは待機して返信を受信したか調べる（ステップ１１０２）。返信が指定された時間間隔内に受信されない場合、送信元は宛先が到達不可能であるとのエラーを返す（ステップ１１０３）。返信を受信した場合、送信元ノードは宛先への有効なルートがすでに存在するか調べる（ステップ１１０４）。すでに有効なルートが存在する場合、送信元は返信パケットを破棄する（ステップ１１０５）。それ以外の場合、送信元ノードは返信パケットに指定されたルートでＲＩＤＢソース・ルーティング・キャッシュを更新する（ステップ１１０６）。ルート検証処理図３２はＲＩＤＢソース・ルーティング・キャッシュに含まれるルートの妥当性(validity)を調べるために用いるルート検証処理(route validation process) を示す。送信元ノードは有効(valid)とマークされていないＲＩＤＢソース・ルーティング・キャッシュ内の宛先ノード全部にルート検証パケットを送信する（ステップ１２０１）。送信元はタイマーをセットし（ステップ１２０２）検証応答(validation reply)を聴取する（ステップ１２０３）。端末ノードもルート検証パケットを聴取し（ステップ１２０９）、検証パケットを受信したか調べる（ステップ１２１０）。検証パケットが指定した時間間隔内で受信されない場合、端末ノードはルート検証パケットの聴取を継続する（ステップ１２０９）。検証パケットを受信した場合、端末ノードはルート検証パケット内に指定されているルートを検証し（ステップ１２１１）パケットを送信元に返送する（ステップ１２１２）。送信元ノードは検証応答が受信されたかどうかを調べる（ステップ１２０４）。検証応答を受信した場合、送信元ノードは宛先へのソース・ルートをＲＩＤＢソース・ルーティング・キャッシュ内で有効としてマークする（ステップ１２０５）。検証応答を受信しない場合、送信元ノードはタイマーを調べる（ステップ１２０６）。タイマー期限を過ぎていない場合、送信元ノードは検証応答を聴取し続ける（ステップ１２０３）。タイマー期限を過ぎた場合、送信元ノードはリトライ域値を越えていなければ（ステップ１２０７）タイマーをリセットする（ステップ１２０２）。リトライ域値を越えた場合送信元ノードはＲＩＤＢソース・ルーティング・キャッシュから無効なソース・ルートを削除する（ステップ１２０８）。ルート・アドバタイズメント処理図３３は全てのアクティブ・コンテクスト・ブリッジと端末ノードで間欠的に実行される処理であるルート・アドバタイズメント処理(Route Advertisement P rocess)を示す。それぞれのコンテクスト・ブリッジはルートアドバタイズメントパケット（ＲＡＰ）として周知のブロードキャスト・メッセージを定期的に送信し（ステップ１３０１）、それぞれの端末ノードはＲＡＰブロードキャストを聴取する（ステップ１３０５）。ＲＡＰは次のような情報を含むのが望ましい：コンテクスト・ブリッジで取り扱い可能なプロトコル、および必要とされるホップ数。全てのコンテクスト・ブリッジと端末ノードはＲＡＰブロードキャストを受信するまで待つ（ステップ１３０２，１３０６）。ＲＡＰブロードキャストを受信した場合、ブロードキャストを受信したノードは、ＲＡＰブロードキャストをＲＩＤＢ次ホップ・ルーティング・キャッシュと比較してルーティング情報に変化があるかどうかを調べる（ステップ１３０３，１３０７）。変更が必要な場合、受信ノードはＲＩＤＢ次ホップ・ルーティング・キャッシュを更新する（ステップ１３０４，１３０８）。無制限のレベル本発明の好適実施例において、ＰＬＮ階層のレベル数は制限がない。図３４はシステム１００のデベロッパ（システム・デベロッパ）、アプリケーション・デベロッパ、およびエンドユーザが省略値のレベル数（例えば５）より大きなレベル数を実装するために取るのが好適なステップを示している。何らかの実施の最大レベル数は、ＰＩＰＥＳカーネルとＰＡＰＩライブラリ・コードをコンパイルする時点で設定する。ＰＩＰＥＳの大きな柔軟性と階層内の大きなレベル数を有するのが所望の場合、ＰＩＰＥＳカーネルとＰＡＰＩライブラリをカスタマイズする必要がある。システム・デベロッパはソフトウェアのヘッダ・ファイル内にハードコード(h ard-coded)されているMinLevelとMaxLevelパラメータを変更する（ステップ１５０１）。ＰＡＰＩライブラリ（ステップ１５０２）とＰＩＰＥＳカーネル（ステップ１５０３）は再コンパイルされ、新しいＰＡＰＩライブラリとＰＩＰＥＳカーネルがアプリケーション・デベロッパに配布される（ステップ１５０４）。アプリケーション・デベロッパはシステム・デベロッパからこれらのコンポーネントを受け取り（ステップ１５０５）、自分自身のＰＩＰＥＳアプリケーションに必要な何らかの変更を加える（ステップ１５０６）。アプリケーション・デベロッパは自分のＰＩＰＥＳアプリケーションを新しいＰＡＰＩライブラリで再コンパイルし（ステップ１５０７）、新しいＰＩＰＥＳアプリケーションとＰＩＰＥＳカーネルをエンドユーザへ配布する（ステップ１５０８）。エンドユーザはアプリケーション・デベロッパからこれらのコンポーネントを受け取り（ステップ１５０９）ＰＬＮのノード全部にこれらを導入する（ステップ１５１０）。ＰＩＰＥＳ設定に必要な何らかの変更を加えたのち（ステップ１５１１）、エンドユーザはＰＩＰＥＳカーネル（ステップ１５１２）とＰＩＰＥＳアプリケーション（ステップ１５１３）をロードすることによってシステムを最終的にリスタートさせる。この時点で、エンドユーザはＰＬＮ階層に所望するレベル数を実現できる。本発明は現時点で好適実施例と考えられるものについて説明したが、添付の請求項は開示した実施例に制限されるべきものではなく、むしろ逆に、本発明の新規な特徴および利点のいずれかを含む変更、変形、および等価な構成を包含することを意図していることは理解されるべきである。

【手続補正書】特許法第１８４条の８【提出日】１９９６年１１月１日【補正内容】（原文明細書第１５頁）子カーネルは最初に待ち期間(wait period)（ステップ１０１）に入り、ここでは子カーネルがネットワーク上の他のログイン・ブロードキャストを聴取(liste n for)する（ステップ１０２）。ログイン・ブロードキャストを待ち期間の間に受信した場合（ステップ１０３）、子カーネルはメッセージを読み取る。メッセージ内の情報は子が親とその兄弟の識別を確認するのに十分なものである。メッセージ発信側が兄弟であれば（ステップ１０４）子カーネルはログイン待ち期間の間隔を変更し（ステップ１０５）、ログイン・ブロードキャストがネットワークに氾濫しないようにする。メッセージ発信側が親の場合（ステップ１０６）、子カーネルはログイン要求を親に送信し（ステップ１０７）、肯定応答を待つ。ログイン・ブロードキャストが受信されない場合、子カーネルは待ち期間の終了までログイン・ブロードキャストを聴取し続ける（ステップ１０８）。待ち期間の終りで、子カーネルはログイン・ブロードキャストをネットワークに送信する（ステップ１０９）。図７において、カーネルＮ７はノードＮ１のカーネル（円４１で表してありカーネルＮ１と呼ぶ）、ノードＮ２のカーネル（円４２で表してありカーネルＮ２と呼ぶ）、ノードＮ３のカーネル（円４３で表してありカーネルＮ３と呼ぶ）、ノード４のカーネル（円４４で表してありカーネルＮ４と呼ぶ）、ノードＮ５のカーネル（円４５で表してありカーネルＮ５と呼ぶ）、ノードＮ６のカーネル（円４６で表してありカーネルＮ６と呼ぶ）にログイン・ブロードキャスト・メッセージを送信することによりＰＩＰＥＳネットワークへのログインを試みる。子カーネルはログイン肯定応答を受信するまで指定された時間だけ待つ（ステップ１１０）。全てのカーネルはネットワーク上のログイン・ブロードキャスト・メッセージを聴取する（ステップ１１６）。ログイン・ブロードキャストが受信されると（ステップ１１７）、親カーネルはそのメッセージを送信したカーネルが自分の子であるかどうかを判定する（ステップ１１８）。発信側カーネルが子ではない場合、親はログイン・ブロードキャストを聴取し続ける（ステップ１１６）。しかし、発信側カーネルが子である場合には、親はこのカーネルが重複した子かどうかをチェックする（ステップ１１９）。これが重複した子である場合，親は重複している子に対して役割の衝突(role conflict)を通知する（ステップ１２０）。（原文明細書第１８頁）ロール・コールを開始したカーネルが肯定応答を受信した場合（ステップ２０９）、カーネルはロール・コール手続きを放棄する（ステップ２０４）。ロール・コールを開始したカーネルがかわりに階層の同じレベルで別のロール・コール・ブロードキャストを受信した場合（ステップ２１０）、カーネルはメッセージを読み取る。メッセージ発信側が高いクレデンシャル(credential)を有している場合（ステップ２１１）には、カーネルはロール・コール手続きを放棄する（ステップ２０４）。特定のカーネルのクレデンシャル(credential)は、カーネルがアクティブ・コンテクスト・ブリッジかどうかまたカーネルの現在の状態についてすでにカーネルが想定した役割個数の関数である。タイムアウト期間の終了時に（ステップ２１２）、カーネルはロール・コールを要求した空いている管理上の役割を引受ける。図９はロール・コール手続きの例を示す。円５４で表してあるカーネルＮ４は、物理的接続の問題のためネットワークから分離される。円５７で表されるカーネルＮ７は、これの親カーネルＮ４とのモニタ処理の結果として（詳細に以下で説明する）カーネルＮ４が存在しないことを検出する。カーネルＮ７は強制待ち期間に入りネットワーク上のロール・コール・ブロードキャストのトラフィックを聴取する。円５５で表されるカーネルＮ５がカーネルＮ７より前にロール・コール処理を開始した場合、カーネルＮ７は破線ｉで表されるロール・コール・ブロードキャスト・メッセージを受信後にロール・コールをアボート(abort)する。しかし、カーネルＮ７がロール・コールを最初に開始したと仮定すると、カーネルＮ７は破線ｈで表されるブロードキャスト・メッセージをロール・コール・待ち期間の終了時に送信する。カーネルＮ７がすでに自分自身のロール・コール・ブロードキャスト・メッセージを送信した後でカーネルＮ５が自分自身のロール・コール・ブロードキャスト・メッセージを送信した場合、カーネルＮ７は自分のクレデンシャルをカーネルＮ５のクレデンシャルと比較する。カーネルＮ５のクレデンシャルの方が高い場合、カーネルＮ７はロール・コールを放棄し、カーネルＮ５はカーネルＮ４の消失により空きのままになっている管理上の役割を引受ける。カーネルＮ７のクレデンシャルの方が高い場合、カーネルＮ５はロール・コールを放棄しカーネルＮ７はタイムアウト期間の終了時にカーネルＮ４の空いた管理上の役割を引受ける。（原文明細書第２０頁〜第２１頁）親の心拍タイマーの期限に達すると（ステップ３１７）、親は欠けた(missing )心拍メッセージについて子どものリストをチェックする（ステップ３１８）。親が欠けた心拍を検出すると、親は欠けた子に心拍メッセージを送信する（ステップ３１９）。親が欠けた子からの心拍肯定応答を受信しない場合、親は子の登録を取り消す（ステップ３２１）。待ち期間の間に（ステップ３０７）、子は親からの心拍メッセージを聴取する（ステップ３０８）。心拍メッセージを子が受信した場合（ステップ３０９）、子は親に心拍肯定応答を送信し（ステップ３１０）、心拍間隔を変更し（ステップ３０６）、再び待ち期間に入る（ステップ３０７）。待ち期間の終了時に（ステップ３１１）、子は再びモニタ処理を開始する（ステップ３０１）。図１２はモニタ処理の間に親と子との間で渡される定期的チェックイン・メッセージ、または「心拍」を示す。図１２において、カーネルＮ３とＮ４（それぞれ円６３、円６４で表してある）はカーネルＮ２（円６２で表される）の子である。カーネルＮ２はさらにカーネルＮ１（円６１で表される）の子である。メッセージｄ₁からｄ₃は子から親への心拍メッセージを表し、メッセージｅ₁からｅ₃ は親から子への心拍肯定応答を表す。メッセージｆ₁からｆ₃は親から子への心拍メッセージを表し、メッセージｇ₁からｇ₃は子から親への心拍肯定応答を表す。選出ＰＩＰＥＳカーネルは分散選出(distributed Election)（図１３）に従事して役割の衝突が発生した時の勝者を決定する。ネットワークのフラグメンテーションを発生させる基盤となる物理接続での問題が存在する時に、同じネームスペース上で２つまたはそれ以上のマネジャが管理上の責任を主張することがある。ネームスペースでの衝突は前述のようにロール・コールまたはログイン・ブロードキャストのどちらかにより最初に検出される。カーネルがネームスペースの衝突を検出すると、カーネルから本人(principals)に通知し、本人が選出処理を実行する。新規参加者(participants)はすでに始まっている選出に参入できる。選出は完全に分散しているので、それぞれのカーネルは別々に選出を処理して結果に達する。カーネルが役割の衝突を検出するか衝突を通知された場合、カーネルは選出タイマーを起動し選出データベースを開いて選出処理を開始する（ステップ４０１）。カーネルはこれまでに分かっている選出参加者を保存し、選出要求をそれぞれに送信する（ステップ４０２）。このメッセージは選出に参加している既知の全てのカーネルから構成される。カーネルは次にネットワーク上の選出トラフィックを聴取する（ステップ４０３）。カーネルが既知の参加者のリストを含む選出応答を受信すると（ステップ４０４）、カーネルは新規選出参加者をデータベース内に保存しそれぞれに選出要求を送信する（ステップ４０２）。別の選出要求を受信すると（ステップ４０５）、カーネルは発信側に選出応答を送信し（ステップ４０６）、選出データベースを更新し、新規参加者に選出要求を送信する（ステップ４０２）。選出タイマーの期限が切れると（ステップ４０７）、カーネルは選出データベースに問い合わせて勝者を決定する（ステップ４０８）。選出の勝者は参加カーネルがアクティブなコンテクスト・ブリッジかどうかまたそれぞれのカーネルの現在の状態についてそれぞれの参加カーネルがすでに引受けた役割の個数に依存する。カーネルが選出の勝者の場合（ステップ４０９）、カーネルは全ての選出参加者に選出結果メッセージを送信する（ステップ４１０）。カーネルが選出に負けた場合、カーネルはマネジャとしての地位を明け渡し（ステップ４１１）子ども全部に新しい親を通知する。選出の全ての参加者は選出結果を検証し最終的に選出データベースを閉じる（ステップ４１２）。図１４は選出処理の例を示す。カーネルＡとＢ（それぞれ円７１と７２で表される）が独立に役割の衝突を検出したと仮定する。カーネルＡは選出要求メッセージ（矢印１）をカーネルＢに送信する。（原文請求の範囲第３９頁）請求の範囲１．複数のノードを含むネットワークのノードにおけるソフトウェア・コンポーネントを独立して実行するための方法において、該方法は、前記ネットワーク内の前記ノードの役割の論理階層を生成するステップであって、いずれかのノードが１つまたは複数の役割を引受け、該引受けは他のいずれかの役割の引受けを必要とすることまたは排除することがなく、前記階層は３つ以上のレベルを有するステップと、前記ネットワークの設定における変更がある時に前記ノードの前記役割を調停し、前記階層の最低レベルにあるノードは前記階層の最高レベルの役割を引受けるステップとを備えたことを特徴とする方法。２．請求項１に記載の方法において、管理的な役割を有するノードがネットワークから離脱しかつ残りのノードの少なくとも１つはどのノードが前記管理的な役割を引受けるかを決定する調停処理に参加し、前記調停ステップはさらに、それぞれの参加ノードにより実行されるものであって、前記管理的な役割の引受けにおける前記参加ノードの注目を示すメッセージをブロードキャストするステップと、前記ブロードキャスト・ステップに続けて、前記ネットワーク上のメッセージを聴取するステップと、前記管理的な役割を引受けるのに別のノードがより適していることを示す前記ネットワーク上のメッセージが存在しない場合前記管理的な役割を引受けるステップとを備えたことを特徴とする方法。３．請求項１に記載の方法において、それぞれの参加ノードにより実行されるステップは、前記ブロードキャスト・ステップより先に、指定した時間間隔について他の参加ノードにより送信されたメッセージを聴取するステップと、前記管理的な役割を引受けるのにより適した少なくとも１つの参加ノードが存在することを前記メッセージが示している時、前記処理をやめるステップとをさらに備えたことを特徴とする方法。（原文請求の範囲第４１頁〜第４４頁）７．請求項１に記載の方法において、前記ノードの１つが親ノードであり、前記方法は前記ネットワークに参入する際に子を登録するステップをさらに備えたことを特徴とする方法。８．請求項７に記載の方法において、前記登録ステップは、参入ノードにより送信されたメッセージを聴取するステップと、子ノードまたは重複した子ノードによりメッセージの１つが送信されたかどうかを判定するステップと、重複した子ノードが検出された場合、前記重複した子の役割に役割の衝突を通知するステップと、子ノードが検出された場合、前記子ノードに肯定応答メッセージを送信するステップとをさらに備えたことを特徴とする方法。９．請求項１に記載の方法において、前記ノードの１つが親であり前記残りのノードの１つが子であり、前記方法は前記親および前記子の状態をモニタするステップをさらに備えたことを特徴とする方法。１０．請求項９に記載の方法において、前記モニタするステップは、指定された時間間隔で前記親と前記子との間で状態メッセージを交換するステップと、所定の時間期間以内に前記親からの状態メッセージを前記子が受信しない時新しい親ノードを探索するステップとをさらに備えたことを特徴とする方法。１１．請求項９に記載の方法において、所定の時間期間以内に前記子からの状態メッセージを前記親が受信しない時前記子の登録を取消すステップをさらに備えたことを特徴とする方法。１２．請求項１に記載の方法において、前記論理階層は任意のレベル数からなることを特徴とする方法。１３．請求項１２に記載の方法において、前記レベル数が変更可能なことを特徴とする方法。１４．請求項１に記載の方法において、前記ネットワーク内における前記ノードの役割は前記ネットワークの要件を条件として変更可能であることを特徴とする方法。１５．資源に対する要求を満たすための方法において、該要求はディジタル・ネットワークにおける複数のノードを相互接続するスケーラブル・システム内のノードによりなされるものであり、前記複数のノードの少なくとも１つのノードは１つ以上の資源が関連し、それぞれの資源は他のノードで該資源が利用可能なアクティブ状態および該資源が利用可能でないインアクティブ状態とを有するものであり、前記方法は、前記要求された資源が利用可能でない場合前記要求を記憶するステップと、前記インアクティブ状態から前記アクティブ状態に切り換えることによって利用可能になった資源を自動的に識別するステップと、前記要求を行ったノードに対して、利用可能になった前記資源が前記要求された資源であれば、前記要求された資源が利用可能になったことを自動的に通知するステップとを備えたことを特徴とする方法。１６．請求項１５に記載の方法において、前記複数のノードの少なくとも１つは資源についての要求を記憶するためのキャッシュを含み、前記要求を記憶するステップは前記キャッシュに前記要求を記憶するステップを備えたことを特徴とする方法。１７．請求項１６に記載の方法において、前記要求された資源が利用可能になり前記要求を満たした時に前記キャッシュから前記要求を削除するステップをさらに備えたことを特徴とする方法。１８．請求項１５に記載の方法において、前記複数のノードは少なくとも２つのレベルに構成されており、かつ第１のレベルのノードは第２のレベルのノードに存在する前記資源に関する情報を含むことを特徴とする方法。１９．請求項１８に記載の方法において、前記第１のレベルの少なくとも１つのノードは資源についての要求を記憶するためのキャッシュを含み、前記要求を記憶するステップは前記キャッシュに前記要求を記憶するステップを備えたことを特徴とする方法。２０．請求項１９に記載の方法において、前記要求された資源が利用可能になり前記要求を満たした時に前記キャッシュから前記要求を削除するステップをさらに備えたことを特徴とする方法。２１．請求項１８に記載の方法において、前記第１のレベルは親レベルでありかつ前記第２のレベルは子レベルであり、前記親レベルの各ノードは前記子レベルの１つ以上のノードに関連し、かつ前記子レベルの各ノードは前記親レベルの１つのノードに関連することを特徴とする方法。２２．異なるレベルで異なる通信プロトコルを有するノードの間でパケットをルートすることのできるコンテクスト・ブリッジにおけるルーティング経路を決定するための方法において、前記コンテクスト・ブリッジは複数のノードを含む異質なネットワーク内の多数のコンテクスト・ブリッジの１つであり、前記方法は、コンテクスト・ブリッジのリストおよび前記リスト内の各コンテクスト・ブリッジが取り扱う前記通信プロトコルを設定するステップと、他のコンテクスト・ブリッジにより定期的にブロードキャストされ、ブロードキャストするコンテクスト・ブリッジが取り扱う前記通信プロトコルを受信者に通知するルーティング情報パケットを聴取するステップと、前記受信したルーティング情報パケットに含まれる前記情報を用いて前記リストを更新するステップとを備えたことを特徴とする方法。２３．送信元ノードから宛先ノードへ少なくとも１つのコンテクスト・ブリッジを使用してパケットをルートするための方法において、各ノードはルーティング・プロトコルを有し、前記コンテクスト・ブリッジは複数のノードを含む異質ネットワークの多数のコンテクスト・ブリッジの１つであり、前記方法は、前記送信元ノードでパケットを受信するステップと、前記パケットの前記宛先ノードはルータブル・プロトコルを有するかどうかを判定するステップと、前記宛先がルータブル・プロトコルを有していない場合、１つ以上のコンテクスト・ブリッジを発見するためのルート発見パケットを送信して前記送信元から前記宛先ノードへ前記パケットをルートするステップと、前記１つ以上の発見したコンテクスト・ブリッジを経由して前記宛先へ前記パケットをルートするステップと、前記宛先がルータブル・プロトコルを有する場合、前記ルータブル・プロトコルを用いて前記送信元から前記宛先へ前記パケットをルートするステップとを備えたことを特徴とする方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者ガイトンド，サニル，エス. アメリカ合衆国 94015 カリフォルニア州デイリーシティーキャンパスドライブ 850 ナンバー 213 (72)発明者アフヤ，ラチンダー，ピー. アメリカ合衆国 94015 カリフォルニア州デイリーシティーキャンパスドライブ 870 (72)発明者ラマクリシュナン，クリシアメリカ合衆国 94587 カリフォルニア州ユニオンシティークリスティーンドライブ 32529 (72)発明者シャフィック，ムハンマドアメリカ合衆国 94018 カリフォルニア州エルグラナダポートラアヴェニュ 430 (72)発明者ワリス，イアン，エフ. アメリカ合衆国 95014 カリフォルニア州クパチーノサウスブラネイアヴェニュ 10430 【要約の続き】通のトランスポート・プロトコル・スタックを共用し得ない末端ノード間で通信し、これによって異なるスタック上に存在するアプリケーションが自動的また透過的に相互に通信できるようになる。

Claims

【特許請求の範囲】１．複数のノードを含むネットワークのノードにおけるソフトウェア・コンポーネントを独立して実行するための方法において、該方法は、前記ネットワーク内の前記ノードの役割の論理階層を生成するステップであって、いずれかのノードが１つまたは複数の役割を引受け、該引受けは他のいずれかの役割の引受けを必要とすることまたは排除することがないステップと、前記ネットワークの設定における変更がある時に前記ノードの前記役割を調停するステップとを備えたことを特徴とする方法。２．請求項１に記載の方法において、管理的な役割を有するノードがネットワークから離脱しかつ残りのノードの少なくとも１つはどのノードが前記管理的な役割を引受けるかを決定する調停処理に参加し、前記調停ステップはさらに、前記参加ノードにより実行されるものであって、前記管理的な役割の引受けにおける前記参加ノードの注目を示すメッセージをブロードキャストするステップと、前記ブロードキャスト・ステップに続けて、前記ネットワーク上のメッセージを聴取するステップと、前記管理的な役割を引受けるのに別のノードがより適していることを示す前記ネットワーク上のメッセージが存在しない場合前記管理的な役割を引受けるステップとを備えたことを特徴とする方法。３．請求項１に記載の方法において、前記参加ノードにより実行されるステップは、前記ブロードキャスト・ステップより先に、指定した時間間隔について他の参加ノードにより送信されたメッセージを聴取するステップと、前記管理的な役割を引受けるのにより適した少なくとも１つの参加ノードが存在することを前記メッセージが示している時、前記処理をやめるステップとをさらに備えたことを特徴とする方法。４．請求項１に記載の方法において、少なくとも２つの衝突ノードが同じ前記管理的役割を主張して前記衝突ノードの少なくとも一方が前記管理的役割を引受けるノードを決定する処理に参加し、前記調停ステップはさらに、それぞれの参加ノードにより実行されるステップであって、前記処理に参加する全ての既知のノードの名称を含むデータベースを設定するステップと、前記データベースに含まれるノードへ選出メッセージを送信するステップであって、前記選出メッセージは前記送信ノードに既知の前記参加ノードに関連する情報を含むステップと、他の参加ノードから選出メッセージを受信するステップと、前記受信した選出メッセージに含まれる前記情報を用いて前記データベースを更新するステップと、前記更新したデータベースに含まれる情報に基づいて、前記管理的役割を前記参加ノードのどの１つが引受けるか、決定するステップとを備えたことを特徴とする方法。５．請求項１に記載の方法において、前記ノードの１つが親ノードであり、前記方法はノードが前記ネットワークに参入した時に親ノードを探索するステップをさらに備えたことを特徴とする方法。６．請求項５に記載の方法において、前記探索ステップはさらに、前記参入ノードにより実行されるステップであって、指定した時間間隔についてメッセージを聴取するステップと、メッセージを受信した場合、前記受信メッセージに基づいて前記参入ノードの親を決定するステップと、前記指定した時間間隔が経過した後で親が見つからない場合、親を探索するためのメッセージをブロードキャストするステップとブロードキャストされたメッセージへの応答を聴取して該応答のいずれか１つが親から発信されたものかどうかを決定するステップと、応答を受信しない時自分自身の親としての役割を引受けるステップとを備えたことを特徴とする方法。７．請求項１に記載の方法において、前記ノードの１つが親ノードであり、前記方法は前記ネットワークに参入する際に子を登録するステップをさらに備えたことを特徴とする方法。８．請求項７に記載の方法において、前記登録ステップは、参入ノードにより送信されるメッセージを聴取するステップと、子ノードまたは重複した子ノードによりメッセージの１つが送信されたかどうかを判定するステップと、重複した子ノードが検出された場合、前記重複した子の役割に役割の衝突を通知するステップと、子ノードが検出された場合、前記子ノードに肯定応答メッセージを送信するステップとをさらに備えたことを特徴とする方法。９．請求項１に記載の方法において、前記ノードの１つが親であり前記残りのノードの１つが子であり、前記方法は前記親および前記子の状態をモニタするステップをさらに備えたことを特徴とする方法。１０．請求項９に記載の方法において、前記モニタするステップは、指定された時間間隔で前記親と前記子との間で状態メッセージを交換するステップと、所定の時間期間以内に前記親からの状態メッセージを前記子が受信しない時新しい親ノードを探索するステップとをさらに備えたことを特徴とする方法。１１．請求項９に記載の方法において、所定の時間期間以内に前記子からの状態メッセージを前記親が受信しない時前記子の登録を取消すステップをさらに備えたことを特徴とする方法。１２．請求項１に記載の方法において、前記論理階層は任意のレベル数からなることを特徴とする方法。１３．請求項１２に記載の方法において、前記レベル数が変更可能なことを特徴とする方法。１４．請求項１に記載の方法において、前記ネットワーク内における前記ノードの役割は前記ネットワークの要件を条件として変更可能であることを特徴とする方法。１５．ディジタル・ネットワークにおける複数のノードを相互接続するスケーラブル・システム内のノードにより要求された資源を検索するための方法において、それぞれのノードは１つ以上の資源が関連し、それぞれの資源は他のノードで利用可能なアクティブ状態および利用可能でないインアクティブ状態とを有するものであり、前記方法は、前記インアクティブ状態から前記アクティブ状態に切り換えることによって前記ネットワークに加わる資源を自動的に識別するステップと、前記要求した側に前記要求された資源が利用可能になったことを自動的に通知するステップとを備えたことを特徴とする方法。１６．請求項１５に記載の方法において、前記複数のノードの少なくとも１つは資源についての要求のリストを記憶するためのキャッシュを含み、前記方法は前記キャッシュに資源についての要求を記憶するステップをさらに備えたことを特徴とする方法。１７．請求項１６に記載の方法において、資源がアクティブになり前記要求を満たした時に前記キャッシュから要求を削除するステップをさらに備えたことを特徴とする方法。１８．請求項１５に記載の方法において、前記複数のノードは少なくとも２つのレベルに構成されており、かつ第１のレベルのノードは第２のレベルのノードに存在する前記資源に関する情報を含むことを特徴とする方法。１９．請求項１８に記載の方法において、前記第１のレベルの複数のノードは資源についての要求のリストを記憶するためのキャッシュを含み、前記方法は前記キャッシュ内に資源についての要求を記憶するステップをさらに備えたことを特徴とする方法。２０．請求項１９に記載の方法において、資源がアクティブになり前記要求を満たした時に前記キャッシュから要求を削除するステップをさらに備えたことを特徴とする方法。２１．請求項１８に記載の方法において、前記第１のレベルは親レベルでありかつ前記第２のレベルは子レベルであり、前記親レベルの各ノードは前記子レベルの１つ以上のノードに関連し、かつ前記子レベルの各ノードは前記親レベルの１つのノードに関連することを特徴とする方法。２２．異なるレベルで異なる通信プロトコルを有するノードの間でパケットをルートすることのできるコンテクスト・ブリッジにおけるルーティング経路を決定するための方法において、前記コンテクスト・ブリッジは複数のノードを含む異質なネットワーク内の多数のコンテクスト・ブリッジの１つであり、前記方法は、コンテクスト・ブリッジのリストおよび前記リスト内の各コンテクスト・ブリッジが取り扱う前記通信プロトコルを設定するステップと、他のコンテクスト・ブリッジにより定期的にブロードキャストされ、ブロードキャストするコンテクスト・ブリッジが取り扱う前記通信プロトコル受信者に通知するルーティング情報パケットを聴取するステップと、前記受信したルーティング情報パケットに含まれる前記情報を用いて前記データベースを更新するステップとを備えたことを特徴とする方法。２３．送信元ノードから宛先ノードへコンテクスト・ブリッジを使用してパケットをルートするための方法において、前記送信元ノードのルーティング・プロトコルは前記宛先ノードのルーティング・プロトコルと異なるレベルにあり、前記コンテクスト・ブリッジは複数のノードを含む異質ネットワークの多数のコンテクスト・ブリッジの１つであり、前記方法は、前記宛先ノードはルータブル・プロトコルを有するかどうかを判定するステップと、前記宛先がルータブル・プロトコルを有していない場合、前記送信元から前記宛先へ前記コンテクスト・ブリッジのアドレスを含むソース・ルートを使用して前記パケットをルートするステップであって、前記アドレスは前記送信元がルート発見パケットを送信し前記宛先が前記発見パケットに応答することにより発見されるものと、前記宛先がルータブル・プロトコルを有する場合ルータブル・プロトコルを含む少なくとも１つのコンテクスト・ブリッジを経由して前記パケットをルートするステップとを備えたことを特徴とする方法。