(57)【要約】  本発明は、ネットワークアーキテクチャを提供する。一実施形態は、リンクによって相互接続された複数のノードを含む。各ノードは、他のノードについての知識をデータベース内に保持することができる。データベースは、ネットワーク内の他のノードと、そうした他のノードに到るための最良ネクストステップである隣接ノードを指示する、それら他のノードの各々についての「最良ネクストステップ」とからなる一覧表を含む。ネットワークのある特定のノードが一覧内に存在しない場合、最良ネクストステップは、データベース内で最も多く識別される最良ネクストステップであると仮定される。そのようなネットワークは「コア」を形成し、その場合、ネットワーク内の任意のノードは、ネットワーク内の他の任意のノードを、最初にコアにおいて当該他のノードを探し出すことによって、見出すことができる。ノードが一度コアを介して互いを発見すると、それらのノード間の最も望ましい経路によって、より最適な経路がネットワーク内に形成される。
2007523546.tif 000002
【特許請求の範囲】
【請求項１】
自己組織化ネットワークであって、
複数のノードと、
前記ノードのうちの隣接ノードを相互接続する複数のリンクとを含み、
前記ノードの各々が、前記ノードの第１の区分内に存在する前記ノードの各々についての情報を保持するように動作可能であり、前記情報が、
前記第１の区分内にある別のノードを示す第１の識別情報と、
第１の識別情報ごとに、前記第１の識別情報に対応する前記別のノードに到達するための望ましいステップである隣接ノードを表す第２の識別情報とを含み、
前記ノードの各々が、前記第１の区分内に含まれない第２の区分内にある前記ノードについての情報を求めるリクエストを送信するための望ましいステップである隣接ノードを表す第３の識別情報を保持するように動作可能な、自己組織化ネットワーク。
【請求項２】
前記第３の識別情報は、前記隣接ノードのうちのどれが、前記第２の識別情報の各々に最も頻繁に出現するかに基づいて決定される請求項１に記載のネットワーク。
【請求項３】
前記ノードの各々は、その隣接ノードと前記情報を交換するように動作可能な請求項１または２に記載のネットワーク。
【請求項４】
各リンクは、前記ノードのうちの２つの間の任意の経路が１組の累積サービス特性を有するように、１組のサービス特性を有する請求項１から３のいずれかに記載のネットワーク。
【請求項５】
前記情報は前記累積セットを含み、前記第２の識別情報に関連する前記望ましいステップは、前記経路のどれが望ましい１組の累積サービス特性を有するかに基づく請求項４に記載のネットワーク。
【請求項６】
前記サービス特性は、帯域幅、待ち時間、およびビット誤り率のうちの少なくとも１つを含む請求項４または５に記載のネットワーク。
【請求項７】
前記ノードは、コンピュータ、電話、センサ、携帯情報端末のうちの少なくとも１つである請求項１から６のいずれかに記載のネットワーク。
【請求項８】
前記リンクは、有線接続および無線接続のうちの少なくとも一方に基づく、請求項１から７のいずれかに記載のネットワーク。
【請求項９】
互いが前記第２の区分内にある前記ノードを発見するための望ましいステップであると決定した隣接ノードの間に、ネットワークコアが形成される請求項１から８のいずれかに記載のネットワーク。
【請求項１０】
前記ノードの各々は、それ自身についての情報を保持するために、前記コアとそれ自身の間にある他のノードに、命令を送り届けるように動作可能な請求項９に記載のネットワーク。
【請求項１１】
前記情報は、前記第１の識別情報の各々について、前記第１の識別情報に関連する前記ノードに向う標識付けされたデータストリームへの距離を表す値を含む請求項１０に記載のネットワーク。
【請求項１２】
前記第１の識別情報に関連するノードは、前記距離に従って増大する昇順でランク付けされ、前記命令は前記ランクに従ってそれらのノードに送り届けられる請求項１１に記載のネットワーク。
【請求項１３】
複数のリンクによって相互接続された少なくとも２０００のノードを含む、自己組織化ネットワーク。
【請求項１４】
複数のリンクによって相互接続された少なくとも５０００のノードを含む、自己組織化ネットワーク。
【請求項１５】
複数のリンクによって相互接続された少なくとも１００００のノードを含む、自己組織化ネットワーク。
【請求項１６】
複数のリンクによって相互接続された少なくとも１０００００のノードを含む、自己組織化ネットワーク。
【請求項１７】
複数の他のノードと、前記ノードのうちの隣接ノードを相互接続する複数のリンクとを有する自己組織化ネットワークで使用されるノードであって、
前記他のノードのすべてのうちの第１の区分内に存在する前記他のノードの各々についての情報を保持するように動作可能なコンピューティング装置を含み、前記情報は、
前記第１の区分内にある別のノードを示す第１の識別情報と、
前記第１の識別情報ごとに、前記第１の識別情報に対応する別のノードに到達するための望ましいステップである隣接ノードを表す第２の識別情報とを含み、
前記コンピューティング装置がさらに、前記第１の区分内に含まれない第２の区分内にある前記ノードについての情報を求めるリクエストを送信するための望ましいステップである隣接ノードを表す第３の識別情報を保持するように動作可能であるノード。
【請求項１８】
複数の他のノードと、前記ノードのうちの隣接ノードを相互接続する複数のリンクとを有する自己組織化ネットワークの一部を形成するノード上で実行される１組のプログラム命令を保存するためのコンピュータ可読媒体であって、前記プログラム命令は、前記ノード内のコンピューティング装置に、前記他のノードのすべてのうちの第１の区分内に存在する前記他のノードの各々についての情報を保持させるためのものであり、前記情報は、
前記第１の区分内にある別のノードを示す第１の識別情報と、
前記第１の識別情報ごとに、前記第１の識別情報に対応する前記別のノードに到達するための望ましいステップである隣接ノードを表す第２の識別情報とを含み、
前記プログラム命令がさらに、前記コンピューティング装置に、前記第１の区分内に含まれない第２の区分内にある前記ノードについての情報を求めるリクエストを送信するための望ましいステップである隣接ノードを表す第３の識別情報を保持させるためのものであるコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００４年２月１６日に出願されたカナダ国特許出願第２４５７９０９号、２００４年２月１７日に出願された米国仮特許出願第６０／５４４３４１号、２００４年４月２０日に出願されたカナダ国特許出願第２４６４２７４号、２００４年５月１７日に出願されたカナダ国特許出願第２４６７０６３号、２００４年６月２２日に出願されたカナダ国特許出願第２４７１９２９号、２００４年８月１６日に出願されたカナダ国特許出願第２４７６９２８号、および２００４年９月２０日に出願されたカナダ国特許出願第２４７９４８５号に基づく優先権を主張し、上記のすべての文献の内容は、参照により本明細書に組み込まれる。
【０００２】
本発明は一般に、互いに通信を行う電子装置、電気通信装置、およびコンピューティング装置に関し、より詳細には、それらのためのネットワークアーキテクチャに関する。
【背景技術】
【０００３】
ネットワーク接続された装置は、現在、我々の社会の基礎構造の極めて重要な側面である。公衆交換電話網（「ＰＳＴＮ」）は、おそらく、人々の対話の仕方を変化させた、電気通信装置からなるユビキタスネットワークの最初の例であろう。現在、移動電話ネットワーク、インターネット、ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、ボイスオーバインターネットプロトコル（「ＶＯＩＰ」）ネットワークが広く配備され、成長を続けている。
【０００４】
言い古されたことだが、これらの各装置は、ネットワーキング機能を果たすために互いに到達できる必要がある。ＰＳＴＮでは、国コード、市外局番、市内局番などを含む電話番号体系が利用される。少なくとも北米では、電話機の爆発的増加が、標準的な１０桁の数字体系を拡張した。インターネットでは、インターネットプロトコルバージョン４（「ＩＰＶ４」）が、インターネット上の地点を識別するためのインターネットプロトコル（「ＩＰ」）アドレスの体系を広め、その結果、ネットワーク接続された各装置は、インターネット上でその装置を到達可能にするアドレスを有する。少なくとも部分的には、ＩＰＶ４アドレスフィールドの長さに限界があるため、ＩＰアドレスは、僅かな地理的関係をそれらの物理的ロケーションに対してもち得るに過ぎない。その結果、インターネット全体にわたって、ルータおよびルーティングテーブルがはなはだしく膨れ上がり、トラフィックルーティングの複雑さを増やし、ネットワーク待ち時間を長くしている。ＩＰＶ６は、可能性を秘めた問題緩和アドレスを提供するが、ＩＰＶ６へのアップグレードは、なかなか進展しないことが予想される。
【０００５】
非常に一般的な言い方をすると、多くの従来技術のネットワークアーキテクチャは、ルーティング装置に依存して、ネットワーク全域の装置のアドレスおよびロケーションを保持している。そのようなルーティング装置は、本質的に、適切な経路に沿ってトラフィックをルーティングする交通整理係である。そのようなアーキテクチャは、ネットワークが大きくなるにつれて、動作が鈍くなり、扱いが不便になる。
【０００６】
様々な「ルータレス」ネットワークアーキテクチャが提案された。これらのアーキテクチャのいくつかは、ピアツーピアネットワークと呼ばれ、その他のものは、アドホックネットワークと呼ばれる。いずれにしても、これら従来技術のアーキテクチャは、やはり拡張性および／またはその他の制限などの難点をもつ傾向にある。ネットワークアーキテクチャを改良するための１つの試みが、アドホックオンデマンド距離ベクトル（「ＡＯＤＶ：Ａｄ  Ｈｏｃ  Ｏｎ  Ｄｅｍａｎｄ  Ｄｉｓｔａｎｃｅ  Ｖｅｃｔｏｒ」）である。ＡＯＤＶは、新規コネクションの確立または切断コネクションの修復を行うのにブロードキャストフラッディングを使用するリアクティブ型プロトコルである。ＡＯＤＶは、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５６１．ｔｘｔから得られるインターネットエンジニアリングタスクフォース（「ＩＥＴＦ」）文書で詳細に説明されている。ＡＯＤＶは、ノードをアドホックネットワークに容易に組織できるという利点を有するが、ＡＯＤＶが有する問題の１つは、最大ネットワークサイズが著しく制限されることである。
【０００７】
ネットワークアーキテクチャを改良するための別の試みは、「宛先シーケンス距離ベクトル」（「ＤＳＤＶ：Ｄｅｓｔｉｎａｔｉｏｎ  Ｓｅｑｕｅｎｃｅｄ  Ｄｉｓｔａｎｃｅ  Ｖｅｃｔｏｒ」）である。ＤＳＤＶは、ネットワーク内のすべてのノードへの経路およびすべてのノードからの経路を生成および保持するのに更新情報の連続的フラッディングを使用するプロアクティブ型プロトコルである。ＤＳＤＶについての詳細な説明は、ｈｔｔｐ：／／ｃｉｔｅｓｅｅｒ．ｉｓｔ．ｐｓｕ．ｅｄｕ／ｃａｃｈｅ／ｐａｐｅｒｓ／ｃｓ／２２５８／ｈｔｔｐ：ｚＳｚｚＳｚｗｗｗ．ｓｒｖｌｏｃ．ｏｒｇｚＳｚｃｈａｒｌｉｅｐｚＳｚｔｘｔｚＳｚｓｉｇｃｏｍｍ９４ｚＳｚｐａｐｅｒ．ｐｄｆ／ｐｅｒｋｉｎｓ９４ｈｉｇｈｌｙ．ｐｄｆ、またはｈｔｔｐ：／／ｃｉｔｅｓｅｅｒ．ｉｓｔ．ｐｓｕ．ｅｄｕ／ｐｅｒｋｉｎｓ９４ｈｉｇｈｌｙ．ｈｔｍｌで見出される。ＤＳＤＶは、ループのないルーティングを提供するという利点を有するが、小規模ネットワークでしか機能しないという難点を有する。大規模ネットワークでは、制御トラフィックが、利用可能な帯域をたやすく超過してしまう。
【０００８】
ネットワークアーキテクチャを改良するための別の試みは、「最適化リンク状態ルーティング」（「ＯＬＳＲ：Ｏｐｔｉｍｉｚｅｄ  Ｌｉｎｋ  Ｓｔａｔｅ  Ｒｏｕｔｉｎｇ」）である。ＯＬＳＲは、ネットワークトポロジについての知識を構築しようと試みるプロアクティブ型プロトコルである。ＯＬＳＲについての詳細な説明は、下記のＩＥＴＦ草案ｈｔｔｐ：／／ｈｉｐｅｒｃｏｍ．ｉｎｒｉａ．ｆｒ／ｏｌｓｒ／ｄｒａｆｔ−ｉｅｔｆ−ｍａｎｅｔ−ｏｌｓｒ−１１．ｔｘｔに見出すことができる。ＯＬＳＲは、より効率的なリンク状態プロトコルであるという利点を有するが、依然としてより大規模なネットワークをサポートすることができない。
【０００９】
ネットワークアーキテクチャを改良するための別の試みは、「最短経路ファーストオープン」（「ＯＳＰＦ：Ｏｐｅｎ  Ｓｈｏｒｔｅｓｔ  Ｐａｔｈ  Ｆｉｒｓｔ」）である。ＯＳＰＦは、いくつかのインターネットコアルータによって使用されるプロアクティブ型リンク状態プロトコルである。ＯＳＰＦについての詳細な説明は、下記のＩＥＴＦ草案ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１２４７．ｔｘｔに見出すことができる。ＯＳＰＦは、コアインターネットルータが障害を迂回することを可能にするが、サポートできるネットワークのサイズに限界がある。
【００１０】
ＡＯＤＶ、ＤＳＤＶ、ＯＬＳＲ、およびＯＳＰＦの間の相違にも関わらず、これらはすべて、例えば、数百ノードを超える拡張が困難であることなど、いくつかの同じ問題を共有している。この制限が生じるのは、ネットワークが大きくなるにつれて、必要な制御トラフィック量がはるかに急速に増加するためである。必要な制御トラフィック量は、速やかに、ネットワーク容量を超過してしまう。
【００１１】
一般に、従来技術のネットワークアーキテクチャは、良好な拡張性を提供せず、また低容量装置がより大規模なネットワークと十分に対話できるようにする能力を提供せず、移動環境では、従来技術のアーキテクチャは、シームレスな移動性を常に提供するとは限らない。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、上で確認された従来技術の難点のうちの少なくとも１つを除去または緩和する、ネットワーキングのための新規なシステムおよび方法を提供することである。
【課題を解決するための手段】
【００１３】
本発明の第１の態様は、複数のノードと、前記ノードのうちの隣接ノードを相互接続する複数のリンクとを含むネットワークを提供する。前記ノードの各々は、前記ノードの第１の区分内に存在する前記ノードの各々についての情報を保持するように動作可能である。前記情報は、前記第１の区分内にある別のノードを示す第１の識別情報と、第１の識別情報ごとに、前記第１の識別情報に対応する前記別のノードに到達するための望ましいステップである隣接ノードを表す第２の識別情報とを含む。前記ノードの各々は、前記第１の区分内に含まれない前記ノードの第２の区分内にある前記ノードを発見するための望ましいステップである隣接ノードを決定するように動作可能である。
【００１４】
第１の態様の特定の実施において、前記決定は、前記隣接ノードのうちのどれが第２の識別情報の各々に最も頻繁に出現するかに基づく。
【００１５】
第１の態様の特定の実施において、前記ノードの各々は、その隣接ノードと前記情報を交換するように動作可能である。
【００１６】
第１の態様の特定の実施において、各リンクは、前記ノードのうちの２つの間の任意の経路が１組の累積サービス特性を有するように１組のサービス特性を有し、その場合、前記望ましいステップが、前記経路のどれが望ましい１組の累積サービス特性を有するかに基づく。
【００１７】
第１の態様の特定の実施において、前記サービス特性は、帯域幅、待ち時間、およびビット誤り率のうちの少なくとも１つを含む。
【００１８】
第１の態様の特定の実施において、前記ノードは、コンピュータ、電話、センサ、携帯情報端末のうちの少なくとも１つである。
【００１９】
第１の態様の特定の実施において、前記リンクは、有線接続および無線接続のうちの少なくとも一方に基づく。
【００２０】
第１の態様の特定の実施において、互いが前記第２の区分内にある前記ノードに到達するための望ましいステップであると決定した隣接ノードの間に、ネットワークコアが形成される。
【００２１】
第１の態様の特定の実施において、各ノードは、そのノードについての情報を保持するために、前記コアとそのノードの間にある他のノードに命令するように動作可能である。
【００２２】
第１の態様の特定の実施において、各ノードは、前記第２の区分内にある前記ノードについての情報を要求するように動作可能であり、各ノードは、前記コアとそのノードの間にある前記他のノードに前記要求を行うように動作可能である。
【００２３】
従来技術にまさる本発明の１つの利点は、本明細書で教示されるネットワークアーキテクチャが、大規模な自己組織化ネットワークを可能にすることである。ある実施形態でこの特徴が可能になるのは、実際には、ネットワーク内の非常に僅かなノードしか、ネットワーク全体についての知識をもつ必要がないからである。ネットワーク内のすべてのノードは、集団でネットワーク全体についての知識をもち、他のノードを認識していないが、そのような他のノードを見つける必要があるノードには、関連する知識を有するネットワーク内の他のノードからそのような知識を求めることによって、それらの他のノードを見つける手段が提供される。上記およびその他の理由のため、本発明は、従来技術の自己組織化ネットワークアーキテクチャに比べ、かなり大規模な自己組織化ネットワークを可能にする、新規な自己組織化ネットワークアーキテクチャである。したがって、本発明の第２の態様は、複数のリンクによって相互接続された少なくとも２０００のノードを含む自己組織化ネットワークを提供する。本発明の第３の態様は、複数のリンクによって相互接続された少なくとも５０００のノードを含む自己組織化ネットワークを提供する。本発明の第４の態様は、複数のリンクによって相互接続された少なくとも１００００のノードを含む自己組織化ネットワークを提供する。本発明の第５の態様は、複数のリンクによって相互接続された少なくとも１０００００のノードを含む自己組織化ネットワークを提供する。
【００２４】
本発明が今から、添付の図面を参照しながら単なる例によって説明される。
【発明を実施するための最良の形態】
【００２５】
ここで図１を参照すると、本発明の一実施形態によるネットワークが、全体として３０で示されている。ネットワーク３０は、複数のノードＮ１、Ｎ２、およびＮ３を含む。ノードＮ１、Ｎ２、およびＮ３は、一括してノードＮと呼ばれ、また総称的にノードＮと呼ばれる。この命名法は、本明細書で説明されるその他の要素に対しても使用される。
【００２６】
ノードＮ１は、第１の物理リンクＬ１を介してノードＮ２に接続される。ノードＮ２は、第２のリンクＬ２を介してノードＮ３に接続される。ノードＮ１はノードＮ２の隣接ノードであり、同様に、ノードＮ２はノードＮ１の隣接ノードであるが、これは、両ノードがリンクＬ１によって接続されているからである。さらに、ノードＮ３はノードＮ２の隣接ノードであり、同様に、ノードＮ２はノードＮ３の隣接ノードであるが、これは、両ノードがリンクＬ２によって接続されているからである。したがって、本明細書では、「隣接ノード」という用語（および文脈に応じたその変形）は、単一のリンクＬによって別のノードＮに接続されているノードＮを指示するのに使用される。
【００２７】
各ノードＮは、それぞれのリンクＬを介して別のノードＮと通信を行うように動作可能な、任意のタイプのコンピューティング装置である。任意のタイプのコンピューティング装置には、パーソナルコンピュータ（「ＰＣ」）、ラップトップコンピュータ、携帯情報端末（「ＰＤＡ」）、ボイスオーバインターネットプロトコル（「ＶＯＩＰ」）地上通信線電話、セルラ電話、スマートセンサなど、またはそれらの組合せが企図されている。各ノードＮは、異なるタイプのコンピューティング装置であることができる。
【００２８】
各リンクＬは、ＯＣ３、Ｔ１、符号分割多元接続（「ＣＤＭＡ」）、直交周波数多元接続（「ＯＦＤＭ」）、移動通信用グローバルシステム（「ＧＳＭ」）、グローバルパケット中継サービス（「ＧＰＲＳ」）、Ｅｔｈｅｒｎｅｔ、８０２．１１およびその変形、Ｂｌｕｅｔｏｏｔｈなどを含むが、これらに限定されない任意のタイプの通信リンク、またはそれらの組合せもしくは混成に基づいており、有線または無線とすることができる。
【００２９】
特定のノードＮを実施するのに使用されるコンピューティング装置のタイプ、およびそれらの間のリンクＬのタイプは、詳細に限定されず、一般的に言って、各ノードＮは、任意の隣接ノードＮと、それらの間のそれぞれのリンクＬを介して、接続および通信を行うように動作可能であることをここで理解されたい。
【００３０】
各ノードＮは、ネットワーク３０内のその他のノードＮのうちの少なくともいくつかについての知識を保持するように構成されたネットワーク情報データベースＤを保持する。各データベースＤは、その個々のノードＮに関連するコンピューティング環境において、揮発性ストレージ（例えば、ランダムアクセスメモリ（「ＲＡＭ」））および／もしくは不揮発性ストレージ（例えば、ハードディスクドライブ）内に、または揮発性ストレージもしくは不揮発性ストレージの組合せ内に保持される。データベースＤは、ネットワーク３０内の他のノードＮを見つけるために各ノードＮによって使用され、その結果、そのノードＮは見つけた他のノードＮにトラフィックを送信できるようになり、かつ／またはそれらの他のノードＮについての知識を共有するために各ノードＮによって使用される。
【００３１】
各データベースＤが、その個々のノードＮの中に配置された参照符号Ｄで指示される楕円として図１に示されており、ノードＮがそれ自身のデータベースＤを保持していることを表している。より詳細には、データベースＤ１がノードＮ１の中に示され、データベースＤ２がノードＮ２の中に示され、データベースＤ３がノードＮ３の中に示されている。各データベースＤの構造を定義するサイズ、複雑さ、およびその他のオーバヘッドメトリックは、そのデータベースＤが、その個々のノードＮで利用可能な全コンピューティング資源の一部だけを占有するように選択される。したがって、データベースＤの構造は、必ずではないが一般に、ノードＮのコンピューティング資源のかなりの部分が、そのノードＮの通常のコンピューティングタスクを実行するために空けておかれるように選択される。そのようなオーバヘッドメトリックについてのさらなる詳細は、以下でより詳しく説明される。
【００３２】
しかし、図１の例示的なネットワーク３０では、すべてのノードＮが、実質的に等しいコンピューティング資源を有し、すべてのリンクＬが、実質的に同じサービス特性を有することが仮定されている。（本明細書でリンクＬに適用される「サービス特性」という用語は、リンクＬの品質を評価するのに使用できる、帯域幅、待ち時間、ビット誤り率などを含む任意の知られたサービス品質（「ＱＯＳ」）を含む。１つのリンクを介してトラフィックを伝送するのにかかる金銭的コストは、別のリンクを介してトラフィックを伝送するための金銭的コストと異なる場合があるので、サービス特性は、価格付けも含むことができる）。したがって、各データベースＤは、実質的に同じ構造を有することが仮定されており、そのような構造の一例が、表Ｉに示されている。
【表１】
2007523546.tif 000003
【００３３】
一般的に言って、各データベースＤは、そのデータベースＤを保持しているノードＮの他に、ネットワーク３０内のノードＮのうちの少なくともいくつか（「他のノードＮ」）からなる一覧を提供する。各データベースＤはまた、それらの他のノードＮを、ネットワーク３０内におけるそれらの重要さに従ってランク付ける。重要さを反映するメトリックは、そのような他のノードＮの近接度、および／または他のノードＮのどれがネットワーク３０内のトラフィックのどれだけの割合を分担して伝送するか、および／または別のノードＮに向うデータフローに対するノードＮの近接度を含むが、これらに限定されない。当業者にはその他のメトリックも思い浮かぶであろう。それらのいくつかは、以下でより詳しく説明される。各データベースＤはまた、それらの他のノードＮと、それぞれの他のノードＮに到達するための最良ネクストステップを表す隣接ノードＮを識別する。
【００３４】
表Ｉをより詳しく説明すると、表Ｉの列１の「ランク」は、データベースＤの各行の値が、そのデータベースＤ内に保持されている他のノードＮの数に基づいて増加する数を示す。
【００３５】
表Ｉの列２の「ノード名」は、特定の他のノードＮを識別する。そのようなノード名は、任意の知られたまたは将来のネットワークアドレッシング方式に基づくことができる。知られたノードアドレッシング方式の例には、電話番号、または媒体アクセス制御（「ＭＡＣ」）アドレス、またはインターネットプロトコル（「ＩＰ」）アドレスが含まれる。そのようなアドレッシング方式は、ネットワーク３０および／またはその中のノードＮの設計に影響を及ぼすその他の要因に従って選択されることができる。しかし、注目すべきことに、本発明のアドレッシング方式では、例えば、地理的ロケーションに対応する市外局番を有する電話番号などの他のアドレッシング方式で見られるように、各ノードＮの名前がネットワークにおけるそのノードＮのロケーションを反映することを必要としない。本明細書における実施形態の説明を簡略にするため、ノード名は、図面における参照符号に従って識別される。例えば、列２の下のノード名エントリが「Ｎ１」を示す場合、ノードＮ１が識別されている。
【００３６】
表Ｉの列３の「最良隣接ノード」は、列２に名前が示された他のノードＮに到達するための全体的経路における最良ネクストステップを、隣接ノードＮのうちのどれが提供するかを示す。［この実施形態では、「最良隣接ノード」という用語が使用されるが、この用語は、本発明のすべての実施形態について、限定的な意味で解釈されるべきではなく、「最良隣接ノード」またはさもなければ望ましい隣接ノードを決定するための任意の望ましい基準が選択され得る］。したがって、列３は常に隣接ノードＮを識別するが、列２は隣接ノードＮを指示する必要はない。列３のエントリは、実際には、列２で使用されるのと同じアドレッシング方式に従う隣接ノードＮの名前である必要はなく、その特定の隣接ノードＮを示す任意の標識とすることができることを理解されたい。しかし、本明細書における実施形態の説明を簡略にするため、列３のエントリは、実際には、隣接ノードＮの名前を反映する。
【００３７】
ネットワーク３０が初期化されるとき（例えば、すべてのノードＮが各々、図１に示されたトポロジに従って互いに接続されるとき）、各データベースＤの内容は、各データベースＤがそのデータベースＤを所有する特定のノードＮを識別する「ヌル」エントリを含む以外は空である。したがって、表ＩＩは、ノードＮ１を識別する「ヌル」エントリが、最初にデータベースＤ１にどのように入力されるかを示している。
【表２】
2007523546.tif 000004
【００３８】
表ＩＩをより詳しく説明すると、表ＩＩの列１の行０のエントリには、ヌルエントリの「０」が与えられており、データベースＤ１のこの情報が、そのデータベースＤ１を所有する当該のノードＮ１についてのものであることを示している。表ＩＩの列２の行０のエントリは、名前によってノードＮ１を識別する「Ｎ１」である。表ＩＩの列３の行０のエントリは、表ＩＩのこのエントリはデータベースＤ１の所有ノードに関するものなので、最良隣接ノードに当てはまるものがないことを示す「Ｎ／Ａ」である。
【００３９】
同様に、表ＩＩＩは、ノードＮ２を識別する「ヌル」エントリが、最初にデータベースＤ２にどのように入力されるかを示している。
【表３】
2007523546.tif 000005
【００４０】
同様に、表ＩＶは、ノードＮ３を識別する「ヌル」エントリが、最初にデータベースＤ３にどのように入力されるかを示している。
【表４】
2007523546.tif 000006
【００４１】
各データベースＤの残りを入力し、それらの内容を保持するため、各ノードＮのマイクロプロセッサは、１組のプログラミング命令を実行する。それらの命令は、各ノードＮで実質的に同じである。ここで図２を参照すると、本発明の一実施形態に従ってネットワーク知識を保持するための方法を表すフローチャートが、全体として２００で示されている。各データベースＤの内容を入力し、保持するため、方法２００は、各ノードＮのマイクロプロセッサ上で実行される１組のプログラミング命令として実装されることができる。方法の説明を分かりやすくするため、方法２００は、システム３０の各ノードＮ上で実行され、そのノードＮに対応するデータベースＤを保持すると仮定される。したがって、方法２００の以下の説明は、システム３０とその様々な構成要素についてのさらなる理解をもたらす。（しかし、システム３０および／または方法２００は、変更されることができ、図２に示された通りの順序で実行される必要はなく、システム３０および／または方法２００は、本明細書で説明された通りそのままに働く必要はなく、そのような変更は本発明の範囲内にあることを理解されたい）。
【００４２】
したがって、方法２００の説明を始める前に、各ノードＮのデータベースＤは、表ＩＩ、ＩＩＩ、およびＩＶに従って入力されているに過ぎず、各ノードＮは、起動されており、図１に示されたリンクＬの構造に従って互いに物理的に接続されていることが仮定される。
【００４３】
方法２００は最初にステップ２１０で開始され、隣接ノードの存在が判定される。一般的に言って、ステップ２１０で、各ノードＮは、新規の隣接ノードＮがあるかどうか、または既存の隣接ノードＮがそのノードＮとの接続を打ち切ったかどうかを判定する。したがって、ステップ２１０が最初にノードＮ１によって実行されるとき、ノードＮ１は、ノードＮ２の存在およびリンクＬ１の解消を問い合わせるため、リンクＬ１を介してノードＮ２に初期化メッセージを送出する。そのような初期化メッセージは、リンクＬ１を実施するのに使用されるプロトコルのタイプに応じた任意の既知の手段に従って実行されることができる。
【００４４】
同様に、ステップ２１０は、ノードＮ２によっても実行され、したがって、ノードＮ２は、ノードＮ１の存在を問い合わせるため、リンクＬ１を介してノードＮ１にネットワーク初期化信号を送出する。さらに、ノードＮ２は、ノードＮ３の存在を問い合わせるため、リンクＬ２を介してノードＮ３にネットワーク初期化信号を送出する。
【００４５】
最後に、ステップ２１０は、ノードＮ３によっても実行され、したがって、ノードＮ３は、ノードＮ２の存在を問い合わせるため、リンクＬ２を介してノードＮ２にネットワーク初期化信号を送出する。
【００４６】
ここで図３を参照すると、各ノードＮによるステップ２１０のこの初期実行が、上述の説明に従って送信される複数の初期化メッセージＩＭを示すことによって表されている。具体的には、初期化メッセージＩＭ１−２が、ノードＮ１からノードＮ２に送信され、初期化メッセージＩＭ３−２が、ノードＮ３からノードＮ２に送信され、初期化メッセージＩＭ２−３が、ノードＮ２からノードＮ３に送信され、初期化メッセージＩＭ２−１が、ノードＮ２からノードＮ１に送信されている。この実施形態では、初期化メッセージＩＭを簡略化し、またノードＮのノード知識がすべてのノードＮにとって実質的に同じ方法で広まることを可能にするため、初期化メッセージＩＭは、ノード知識を交換しない。ノードＮの処理およびメモリ特性はネットワーク知識を保持するノードの能力に関係するので、この初期化メッセージＩＭは、そうした特性を含むことができる。そのような処理およびメモリ特性は、ネットワーク知識を保持するために専用されるノードＮのメモリなどを含むことができる。しかし、この実施形態では、ノード名Ｎ自体は、初期化メッセージＩＭの部分として交換されない。
【００４７】
初期化メッセージＩＭを使用して隣接ノードを見つけた結果として、各ノードＮは今では、その隣接ノードＮを認識しており、したがって、隣接データベースＤを利用して、その個々のデータベースＤの入力および保持を開始する位置についている。
【００４８】
したがって、再び図２を参照すると、方法２００は、ステップ２１０からステップ２２０に進み、ステップ２２０で、ネットワーク知識が、ステップ２１０で識別された隣接ノードＮの間で交換される。各ノードＮは今では、ネットワーク３０についてのより多くの知識を獲得するため、隣接データベースＤを利用することができる。
【００４９】
ここで図４を参照すると、各ノードＮによるステップ２２０の初期実行が、１組の双方向知識交換メッセージＫＥＭを示すことによって表されている。ノードＮ１とノードＮ２の間の知識交換は、知識交換ＫＥＭメッセージ１−２として示され、ノードＮ２とノードＮ３の間の知識交換は、知識交換メッセージＫＥＭ２−３として示されている。
【００５０】
再び図２を参照すると、その後、方法２００は、ステップ２２０からステップ２３０に進み、ステップ２３０で、ローカル知識が、ステップ２２０での情報交換の結果として更新される。メッセージＫＥＭを交換した結果として、データベースＤ１、Ｄ２、およびＤ３は、表Ｖ、ＶＩ、ＶＩＩにそれぞれ示されるように、隣接ノードＮについての情報を反映するように更新されることができる。したがって、表Ｖは、データベースＤ１が、ノードＮ１によるステップ２３０の初期実行の後、どのように入力されているかを示している。
【表５】
2007523546.tif 000007
【００５１】
表Ｖをより詳しく説明すると、行０は表ＩＩのものと同じままである。しかし、今は行１が入力されており、ノードＮ１が今ではノードＮ２という名前のノードの知識を有しており、ノードＮ２がノードＮ２への到達を可能にする最良隣接ノードであることを示している。
【００５２】
したがって、同様に、表ＶＩは、データベースＤ２が、ノードＮ２によるステップ２３０の初期実行の後、どのように入力されているかを示している。
【表６】
2007523546.tif 000008
【００５３】
表ＶＩをより詳しく説明すると、行０は表ＩＩＩのものと同じままである。しかし、今は行１が入力されており、ノードＮ２が今ではノードＮ１という名前のノードの知識を有しており、ノードＮ１がノードＮ１への到達を可能にする最良隣接ノードであることを示している。さらに、今は行２が入力されており、ノードＮ２が今ではノードＮ３という名前のノードの知識を有しており、ノードＮ３がノードＮ３への到達を可能にする最良隣接ノードであることを示している。ノードＮ１にはランク「１」が与えられ、ノードＮ３にはランク「２」が与えられていることに留意されたい。この例では、どちらをより高くランク付けるかを実際に選択するためのメトリックは存在しないので、そのようなランキングは、純粋に便宜的に付けられたものである。しかし、より複雑な根拠によって付けられるランキングが、以下でより詳しく説明される。
【００５４】
したがって、同様に、表ＶＩＩは、データベースＤ３が、ノードＮ３によるステップ２３０の初期実行の後、どのように入力されているかを示している。
【表７】
2007523546.tif 000009
【００５５】
表ＶＩＩをより詳しく説明すると、行０は表ＩＶのものと同じままである。しかし、今は行１が入力されており、ノードＮ３が今ではノードＮ２という名前のノードの知識を有しており、ノードＮ２がノードＮ２への到達を可能にする最良隣接ノードであることを示している。
【００５６】
表Ｖ、ＶＩ、およびＶＩＩの内容は、図５の点線によって表された知識経路Ｋとして示されている。知識経路Ｋ１−２は、表Ｖの行１に対応し、ノードＮ１がノードＮ２の知識を有していることを示し、知識経路Ｋ２−１は、表ＶＩの行１に対応し、ノードＮ２がノードＮ１の知識を有していることを示し、同様に、知識経路Ｋ２−３は、表ＶＩの行２に対応し、ノードＮ２がノードＮ３の知識を有していることを示し、知識経路Ｋ３−２は、表ＶＩＩの行１に対応し、ノードＮ３がノードＮ２の知識を有していることを示している。
【００５７】
発信ノードＮと宛先ノードＮの間に知識経路が存在する場合、発信ノードＮで生成され、宛先ノードＮに宛てられたペイロードトラフィックは、今では実際に、知識経路Ｋに従ってノードＮに送り届けられることができる。ペイロードトラフィックのそのような送達は、発信ノードＮのデータベースＤの列２に宛先ノードＮについてのネットワーク知識が入力されている限り、列３に示された最良隣接ルーティングを介して実施されることができる。
【００５８】
（本明細書では、「ペイロードトラフィック」または「ペイロード」とは、発信ノードＮ上で実行されるアプリケーションによって生成され、宛先ノードＮに宛てられた任意のデータのことを言う。例えば、ノードＮがコンピュータである場合、ペイロードトラフィックとして、ｅメール、ウェブページ、アプリケーションファイル、プリンタファイル、オーディオファイル、ビデオファイルなどを挙げることができる。ノードＮが電話である場合、ペイロードトラフィックとして、音声伝送を挙げることができる。当業者には、その他のタイプのペイロードデータも思い浮かぶであろう）。
【００５９】
より具体的には、ノードＮ１とノードＮ２は、互いの知識を有しているので、今ではペイロードトラフィックを交換することができる。ノードＮ２とノードＮ３も、互いの知識を有しているので、ペイロードトラフィックを交換することができる。しかし、この時点では、ノードＮ１とノードＮ３は、互いの知識を有していないので、ペイロードトラフィックを交換することができない。
【００６０】
方法２００は、ここまでで１回完全に実行されたので、次にステップ２３０からステップ２１０に復帰し、新たに２回目を開始する。再びステップ２１０に戻り、隣接ノードの存在が判定される。方法２００の２回目の例示的サイクルの間、新規のノードＮはネットワーク３０に追加されず、既存のノードＮは削除されないことが仮定される。したがって、変化は生じていないので、ステップ２１０では何も行われず、方法２００は、ステップ２１０からステップ２２０に進む。
【００６１】
この例を続け、再び図２を参照すると、方法２００は、再びステップ２１０からステップ２２０に進み、ステップ２２０で、追加のネットワーク知識が隣接ノードＮの間で交換される。もう一度、各ノードＮは、ネットワーク３０についてのより多くの知識を獲得するため、隣接データベースＤを利用することができる。
【００６２】
ここで図６を参照すると、各ノードＮによるステップ２２０の２回目の実行が、もう一度、双方向知識交換メッセージＫＥＭによって表されている。ノードＮ１とノードＮ２の間の知識交換は、知識交換ＫＥＭメッセージ１−２として示され、ノードＮ２とノードＮ３の間の知識交換は、知識交換メッセージＫＥＭ２−３として示されている。
【００６３】
再び図２を参照すると、その後、方法２００は、ステップ２２０からステップ２３０への２回目の進行を行い、ステップ２３０で、ローカル知識が、ステップ２２０での情報交換の結果として更新される。メッセージＫＥＭを交換した結果として、データベースＤ１、Ｄ２、およびＤ３は、表ＶＩＩＩ、ＩＸ、Ｘにそれぞれ示されるように、隣接ノードＮについての情報を反映するように更新されることができる。表ＶＩＩＩは、ノードＮ１によるステップ２３０の２回目の実行の後、データベースＤ１がどのように入力されているかを示している。
【表８】
2007523546.tif 000010
【００６４】
表ＶＩＩＩをより詳しく説明すると、行０および行１は表Ｖのものと同じままである。しかし、今は行２が入力されており、ノードＮ１が今ではノードＮ３という名前のノードの知識を有しており、ノードＮ２がノードＮ３への到達を可能にする最良隣接ノードであることを示している。
【００６５】
同様に、表ＩＸは、ノードＮ２によるステップ２３０の２回目の実行の後、データベースＤ２がどのように入力されているかを示している。
【表９】
2007523546.tif 000011
【００６６】
表ＩＸをより詳しく説明すると、行０、行１、および行２は表ＶＩのものと同じままであるが、それは、ノードＮ２には、隣接ノードＮとメッセージを交換することによって認識するようになった新しいノードＮがネットワーク３０内に存在しないからである。
【００６７】
同様に、表Ｘは、ノードＮ３によるステップ２３０の２回目の実行の後、データベースＤ３がどのように入力されているかを示している。
【表１０】
2007523546.tif 000012
【００６８】
表Ｘをより詳しく説明すると、行０および行１は表ＶＩＩのものと同じままである。しかし、今は行２が入力されており、ノードＮ３が今ではノードＮ１という名前のノードの知識を有しており、ノードＮ２がノードＮ１への到達を可能にする最良隣接ノードであることを示している。
【００６９】
表ＶＩＩＩ、ＩＸ、およびＸの内容は、図７の点線によって表された知識経路Ｋとして示されている。図７では（先に図５で示されたように）、知識経路Ｋ１−２は、ノードＮ１がノードＮ２の知識を有していることを示し、知識経路Ｋ２−１は、ノードＮ２がノードＮ１の知識を有していることを示し、同様に、知識経路Ｋ２−３は、ノードＮ２がノードＮ３の知識を有していることを示し、知識経路Ｋ３−２は、ノードＮ３がノードＮ２の知識を有していることを示している。しかし、図７は、今は２つの追加の知識経路も含んでおり、知識経路Ｋ１−３は、ノードＮ１が今ではノードＮ３の知識を有していることを示し、同様に、知識経路Ｋ３−１は、ノードＮ３が今ではノードＮ１の知識を有していることを示している。
【００７０】
発信ノードＮと宛先ノードＮの間に知識経路が存在する場合、発信ノードＮで生成され、宛先ノードＮに宛てられたペイロードトラフィックは、今では実際に、知識経路Ｋに従ってノードＮに送り届けられることができる。ペイロードトラフィックのそのような送達は、発信ノードＮのデータベースＤの列２に宛先ノードＮについてのネットワーク知識が入力されている限り、列３に示された最良隣接ルーティングを介して実施されることができる。したがって、より具体的には、すべてのノードＮが互いの知識を有しているため、今ではすべてのノードＮがペイロードトラフィックを交換することができる。特に留意すべきことに、方法２００のこの実行の後、ノードＮ１とノードＮ３は、両ノードの間のステップとしてノードＮ２を介して、互いにペイロードトラフィックを送信することができる。
【００７１】
方法２００は、ここまでで２回完全に実行されたので、次にステップ２３０からステップ２１０に復帰し、新たな回を開始する。方法２００の３回目の例示的なサイクルの実行の前に、図８に示されるように、リンクＬ２の障害が原因で、ノードＮ３がネットワーク３０から除去されることが仮定される。再びステップ２１０に戻り、隣接ノードの存在が判定される。この３回目では、初期化メッセージＩＭの交換の間に、ノードＮ２とノードＮ３は、もはや互いに隣接ノードではないと決定する。ステップ２２０で、ステップ２１０で存在が確認された隣接ノードに基づく隣接ノードとの間で知識が交換される。最後に、ステップ２３０で、ローカル知識が、交換に基づいて更新される。
【００７２】
ステップ２３０の後、図８に示されるように、その結果は、データベースＤ１については同じままであり、表ＶＩＩＩに示された内容を保持しているが、これは、ノードＮ３の喪失がデータベースＤ１に伝播するには、方法２００のサイクルが不十分にしか行われていないためである。しかし、データベースＤ２は、今では表ＸＩに従って更新されている。
【表１１】
2007523546.tif 000013
【００７３】
データベースＤ３も、表ＩＶに示される初期データを反映するように更新される。これは図８に示されており、既存のノードＮは除去されない。したがって、変化は生じていないので、ステップ２１０では何も行われず、方法２００は、ステップ２１０からステップ２２０に進む。
【００７４】
方法２００のこの３回目の実行の後のデータベースＤの内容は、図８に示された知識経路Ｋに反映される。
【００７５】
方法２００の４回目の実行の間、ノードＮ３の喪失がついにノードＮ１に伝播し、その結果、知識経路Ｋは図９に示されたものになる。
【００７６】
（当業者は、上記の説明は、説明を目的とした簡略化された説明であり、実施された場合、自明なループを導入する原因となり得ることを認めるであろう。これに対処するため、「ポイズンリバース」を導入して、ノードが除去されたときにどのようなネットワークにも導入される自明なループを取り除くことができる。ポイズンリバースは、以下でより詳しく説明される。ループの導入をさらに低減するため、ノード知識が広まるときには遅延を導入し、一方、ノード知識の削除は「ゼロ」遅延で（例えば、実質的に即時に）実施することができる。最後に、（以下でより詳しく説明される）データフローからの距離がある限界に達した場合、ノードは、その特定のノードについての知識を、それがまだそのノードについての有効な知識ではあっても、削除することを隣接ノードに通知する。ノード除去についてのより詳細な説明は、以下でさらに提供される）。
【００７７】
本明細書の教示は、ネットワーク３０よりも複雑さの大きいネットワークに適用可能であることをここで理解されたい。例えば、ここで図１０を参照すると、本発明の別の実施形態による僅かにより複雑なネットワークが、全体として３０ａで示されている。ネットワーク３０ａは、ネットワーク３０と実質的に同じ要素を含み、同様の要素には、接尾辞「ａ」が付される以外は同様の参照符号が与えられている。より具体的には、ネットワーク３０ａは、より多くのノードＮａおよびリンクＬａを含むが、それらのノードＮａおよびリンクＬａの基本構造は、システム３０のそれらの対応物と実質的に同じである。しかし、説明を簡略にするため、ネットワーク３０ａは、データベースＤａの内容を示す具体的な表を伴わずに示されている。
【００７８】
ネットワーク３０ａは、ネットワーク３０の個々の対応ノードＮ１、Ｎ２、およびＮ３と同様に、リンクＬ１ａおよびＬ２ａを介して接続されるノードＮ１ａ、Ｎ２ａ、およびＮ３ａを含む。この例では、ネットワーク３０ａは、方法２００の完全な実行を２回行っており、したがって、データベースＤａは、図７のネットワーク３０について示されたものと同じ状態であることが最初に仮定される。しかし、ネットワーク３０とは対照的に、ネットワーク３０ａは、最初は他のどのノードＮａにも接続されていない第４のノードＮ４ａを含むことも仮定される。
【００７９】
ここで図１１を参照すると、ノードＮ４ａは、ノードＮ４ａとノードＮ２ａの間に張られるリンクＬ３ａと、ノードＮ４ａとノードＮ３ａの間に張られるリンクＬ４ａとを形成することによって、ネットワーク３０ａの残りの部分に参加することを仮定している。方法２００が、各ノードＮａによって十分な回数繰り返し実行された後、（図１１に示されるように）追加の知識経路Ｋが、表ＸＩＩにまとめられたようなデータベースＤａの更新内容に従って形成される。
【表１２】
2007523546.tif 000014
【００８０】
発信ノードＮａで生成され、宛先ノードＮａに宛てられたペイロードトラフィックは、今では実際に、知識経路Ｋａに従って送り届けられることができる。例えば、ノードＮ４ａがノードＮ１ａにペイロードトラフィックを送信することを望んでいると仮定する。表ＸＩＩの情報を使用すると、トラフィックは、ノードＮ４ａからノードＮ２ａを介してノードＮ１ａにルーティングされることが理解できる。このトラフィック経路Ｐは、図１２に示されており、図１２では、図１１と同じ状態でネットワーク３０ａを示しているが、トラフィック経路Ｐがより明瞭に見えるように、知識経路Ｋａは消されている。
【００８１】
この時点で、様々なノードは他のノードに異なる経路を介して到達することができるが、ある好ましい経路が識別されていることが理解できる。これらの実施形態では、これまでのところ、すべてのリンクＬおよびＬａは実質的に同じサービス特性を有すると仮定しているので、そのような好ましい経路が選択された。例えば、表ＸＩＩに対応する図１１および図１２では、ノードＮ４ａは、ノードＮ２ａを介してノードＮ１ａに到達する。これは、表ＸＩＩの行４の列１２に反映されており、ノードＮ２ａは、ノードＮ４ａからノードＮ１ａに到達するための最良ネクストステップとして反映されている。しかし、表ＸＩＩに示された例ではあまり好ましくはないが、ノードＮ４ａからノードＮ３ａおよびノードＮ２ａを介した後にノードＮ１ａに最終的に送り届けられる経路に沿って、ペイロードトラフィックが送り届けられることも物理的には可能であり、この経路は、リンクＬ３ａが存在しない場合に使用される経路である。
【００８２】
しかし、別の実施形態では、各リンクのサービス特性は、異なることができ、各ノードのデータベースは、ペイロードトラフィックをルーティングすべき最良ネクストステップとして最良隣接ノードを選択するときに、そのようなサービス特性の知識を加味する。例えば、ここで図１３を参照すると、本発明の別の実施形態による別のネットワークが、全体として３０ｂで示されている。ネットワーク３０ｂは、ネットワーク３０ａと実質的に同じであり、同様の要素には、接尾辞「ｂ」が付される以外は同様の参照符号が与えられている。より具体的には、ネットワーク３０ｂは、リンクＬｂを含み、それらはネットワーク３０ａのリンクＬａと同じ経路を辿る。また、ネットワーク３０ｂは、４つのノードＮｂを含み、それらはネットワーク３０ａのノードＮａと実質的に同じである。しかし、ネットワーク３０ｂでは、各リンクＬｂは異なるサービス特性を有しており、ネットワーク３０ａでは、各リンクＬａは同じサービス特性を有している。表ＸＩＩＩは、各リンクＬｂの例示的なサービス特性の組を示している。
【表１３】
2007523546.tif 000015
【００８３】
表ＸＩＩＩをより詳しく説明すると、列１は、問題とする特定のリンクＬｂを識別する。列２は、同じ行で識別されているリンクＬｂの帯域幅を識別する。列３は、特定のリンクＬｂを介してトラフィックを伝送するための金銭的コストをキロバイト当たり何セントかで指定する。（表ＸＩＩＩは、ビット誤り率、待ち時間など、望ましいその他の任意のサービス特性も含むことができることをここで理解されたい）。したがって、各リンクＬｂについての情報は、各データベースＤｂの一部となることができ、ノード知識がネットワーク３０ｂを介して伝播されるのとほぼ同じ方法で、方法２００または適切なその変形を使用して、ネットワーク３０ｂを介して伝播されることができる。
【００８４】
各ノードＮｂに対応するデータベースＤｂは、それらが直接接続されている各リンクＬｂの詳細について知っている。例えば、ノードＮ４ｂは、表ＸＩＩＩに示されるようなリンクＬ３ｂおよびＬ４ｂについての詳細を知っている。さらに、ノードＮ３ｂは、リンクＬ４ｂおよびＬ２ｂについての詳細を知っている。この実施形態では、各ノードＮｂは、それ自身と、ノードＮｂに直接接続するために有するリンクＬｂとについて知っているに過ぎない。しかし、各ノードＮｂは、全体的なネットワークトポロジについての何かを知る必要はない。
【００８５】
しかし、経路の一方の端のデータベースが経路の他方の端のノードについての知識をもつと、経路のそれぞれの端の各ノードＮｂに対応する各ノードＮｂのデータベースＤｂは、その経路を定義するリンクＬｂに関連する累積サービス特性について知る。したがって、ノードＮ４ｂがノードＮ１ｂについて一度知ると、ノードＮ４ｂは、ノードＮ４ｂとノードＮ１ｂの間のすべてのリンクＬｂの累積サービス特性（したがって、累積「コスト」）についても知る。
【００８６】
したがって、特定のノードＮｂが特定のリンクＬｂの特性についての情報を一度もつと、そのノードＮｂは、トラフィックをルーティングすべき最良ネクストステップとして「最良隣接ノード」を決定するために、そのような情報を使用することができる。例えば、表ＸＩＩＩでは、リンクＬ３ｂの帯域幅はたった０．５メガビット／秒であり、一方、リンクＬ４ｂおよびリンクＬ２ｂの帯域幅は共に１０メガビット／秒であることが理解できる。したがって、ノードＮ４ｂからノードＮ２ｂに送信されるペイロードトラフィックは、リンクＬ３ｂを介して直接送信されるよりも、ノードＮ３ｂを介して送信されるほうがはるかに高速にノードＮ２ｂに送り届けられる。
【００８７】
したがって、表ＸＩＩＩを使用すると、ノードＮ４ｂは、ペイロードトラフィックの送達速度が優先事項であるならば、ノードＮ３ｂがノードＮ２ｂおよびノードＮ１ｂに到達するための最良ネクストステップであると決定することができる。したがって、表ＸＩＶは、ノードＮ４ｂがそのような決定を行った場合、データベースＤｂの一部がどのようになるかを示している（表ＸＩＩＩの情報は表ＸＩＶに示されないと仮定する）。
【表１４】
2007523546.tif 000016
【００８８】
さらに、図１３は、表ＸＩＶに示されたデータベースＤ４ｂの内容に基づいた、ノードＮ４ｂからノードＮ１ｂに宛てて発信されるトラフィックについてのペイロードトラフィックの経路Ｐｂを示している。図１３では、経路Ｐｂは、リンクＬ３ｂを介して進むのではなく、代わりにリンクＬ４ｂおよびリンクＬ２ｂを介して進む。トラフィックをルーティングすべき最良隣接ノードを決定するとき、複雑な多数の基準が利用され得ることをここで理解されたい。したがって、表ＸＩＶは、帯域幅、コスト、ビット誤り率などについてリンクＬｂのサービス特性を最適化するように入力されることができる。
【００８９】
もちろん、最良隣接ノードが金銭的最低コストを有する最良ネクストステップに基づいて選択され、帯域幅をまったく無視する場合、表ＸＩＶは変化する。再び表ＸＩＩＩを参照すると、この場合、リンクＬ３ｂはリンクＬ４ｂよりも金銭的に低コストなので、ノードＮ４ｂは、ノードＮ２ｂおよびノードＮ１ｂに到達するための最良ネクストステップとしてノードＮ２ｂを選択し、したがって、データベースＤ４ｂは、表ＸＩＩのデータベースＤ４ａと同じになる。
【００９０】
最良ネクストステップは、各リンクを評価する１組の複雑な基準に基づくことができ、例えば、リンクＬｂの全体的格付けは、表ＸＩＩＩの列２と列３を組み合わせて決定され、帯域幅と金銭的コストの両方の組合せであるサービス特性の格付けを特定のリンクに提供することができることをここで明らかにされたい。
【００９１】
本明細書の教示は、ネットワーク３０、３０ａ、および３０ｂよりも複雑なネットワークにも適用可能であることが再び強調されるべきである。例えば、ここで図１４を参照すると、本発明の別の実施形態によるより複雑なネットワークが、全体として３０ｃで示されている。ネットワーク３０ｃは、ネットワーク３０、３０ａ、および３０ｂと同じタイプの要素を含み、同様の要素には、接尾辞「ｃ」が付される以外は同様の参照符号が与えられている。留意すべきは、この実施形態では、すべてのリンクＬｃは、実質的に同じ長さと実質的に同じサービス特性を有すると仮定されるが、他の実施形態では、リンクＬｃは、リンクＬｂと同様に、異なる長さおよびサービス特性を有することができる。ネットワーク３０ｃは、より多くのノードＮｃおよびリンクＬｃを含むが、説明を簡略にするため、ネットワーク３０ｃは、データベースＤｃの内容を示す具体的な表を伴わずに示されている。
【００９２】
しかし、ネットワーク３０、３０ａ、および３０ｂとは対照的に、ネットワーク３０ｃでは、個々のデータベースＤｃによって消費される各ノードＮｃのメモリ資源に上限を設けるため、データベースＤｃは限られた数の行しかもたないことが仮定される。したがって、このネットワーク３０ｃでは、各ノードは、ネットワーク３０ｃ全体についての知識を保持せず、ネットワーク３０ｃの一部だけの知識を保持する。（ネットワーク全体の知識が、与えられたノードのコンピューティング資源全体を非現実的なほど大きく消費するような規模のネットワークに本明細書の教示が適用される場合、実際にそのような構成が現在では好ましい）。説明を分かりやすくするため、各データベースＤｃは、１１行の情報を保存できることが仮定される。第１行は、表ＩＩに関連して先に説明されたヌル行であり、そのデータベースＤｃが属するノードＮｃを識別する。残りの９行は、データベースＤｃが、ネットワーク３０ｃ内のその他の９個のノードＮｃについての知識を保持することを可能にする。
【００９３】
各ノードＮｃは同じ記憶容量をもつ必要はなく、そのような容量は固定される必要もなく、特定のノードＮｃでの需要が変化したのに応じて、自動的または手動により動的に割り当てられることができるが、説明の目的で、ネットワーク３０ｃ内のノードＮｃは、他のノード９個を限度として構成されることに留意されたい。
【００９４】
各ノードＮｃのデータベースＤｃは、「コア」という概念を保持する。特定のノードＮｃが特定のデータベースＤｃに含まれていない場合、そちらに進めばその与えられたノードＮｃを見つけることができるデフォルト経路を、コアが表す。図１４に示されるように、ネットワーク３０ｃは、リンクＬ６ｃに沿って存在するコアＣｃを含み、その詳細が以下でより詳しく説明される。一般に、コアＣｃを定義するデータベースＤｃがネットワーク３０ｃ内のあらゆるノードＮｃについての知識を有するよう保証するのに十分なだけ、少なくともコアＣｃを含むデータベースＤｃの集約記憶容量があるように保証することが現在では好ましい。したがって、ネットワーク３０ｃのアーキテクチャに基づいたネットワークのサイズは、コアＣｃを定義する２つのノードＮｃの集約記憶容量で間に合うサイズである。したがって、この例では、データベースＤ６ｃおよびＤ９ｃ各々の９つの行がネットワーク３０ｃ内のあらゆるノードＮｃについての知識を保持するのに十分なように、ノードＮ６ｃとノードＮ９ｃは集団で十分な容量を有する。
【００９５】
したがって、各ノードＮｃは、方法２００を実行するとき、そのノードＮｃが保存するより多くの他のノードＮｃの「消息を聞く」。したがって、各ノードＮｃは、そのデータベースＤｃ内に他のノードＮｃについての知識を保持するために、ネットワーク３０ｃ内の他のノードＮｃから９つを選択する優先順位付け動作を実行するようにも動作可能である。そのような優先順位付け動作は、他のノードＮｃのどれが最も近いか、他のノードＮｃのどれが最も大量のトラフィックを伝送するか、そのノードは一般に他のノードＮｃのどれにペイロードトラフィックを送信するかなどや、当業者に思い浮かぶであろうその他の基準など、任意の１つもしくは複数の優先順位付け基準またはそれらの組合せに基づくことができる。したがって、そのような優先順位付け基準は、重要性の順位における各ノードＮｃの「ランク」を提供し、それによって、データベースＤｃに入力される順位、およびノード知識がネットワーク内の他のノードＮｃに送信されるべき順位を定める。
【００９６】
この例では、各ノードＮｃのための優先順位付け基準は、以下の知識を保持するため順序付けてそのデータベースＤｃに入力するためのものであると仮定される。
（ａ）そのノードＮｃに最も近い他のノードＮｃ（「近接ノードＮｃ」）。近接ノードＮｃは、近接性の順序でランク付けされる。
（ｂ）発信または宛先ノードＮｃのためにペイロードトラフィックを受け渡すため、ノードＮｃがそれらについての知識をもたなければならない発信または宛先ノードＮｃ（「発信または宛先ノードＮｃ」）。発信または宛先ノードＮｃは、それらのために伝送されるペイロードトラフィック量に従ってランク付けされ、近接ノードより優先される。
（ｃ）そのノードＮｃがペイロードトラフィックをそれとの間で送信または受信する他のノードＮｃ（「ペイロードトラフィックノードＮｃ」）。ペイロードトラフィックノードＮｃは、別のペイロードトラフィックと比べたあるペイロードトラフィックの重要性に従ってランク付けされ、すべての近接ノードより優先され、最大で半分の発信または宛先ノードＮｃより優先される。ペイロードトラフィックの重要性は、トラフィック量またはトラフィック速度などに基づくことができる。
（ｄ）方法２００の特定のサイクル中における最大９個までの他のノードＮｃ。
【００９７】
上述の優先順位付け基準は本発明を説明する目的で簡略化されていることを繰り返しておくべきであろう。別の現在より好ましい実施形態では、ノードは、以下の場合を除いて、標識付けされたデータストリーム値に基づくそれらの距離によって順位付けられる。
１．このノードが、この宛先ノードのための高速伝播経路（「ＨＳＰＰ」、以下でより詳しく説明される）の経路内にあり、この直接接続ノードが、
コアへの経路内にあり、ＨＳＰＰが通知ＨＳＰＰである場合、
このＨＳＰＰについて我々に伝えたノードの１つであり、ＨＳＰＰが要求ＨＳＰＰである場合。
２．このノードが、この宛先ノードに向うデータストリーム内として標識付けされている場合。
ノードは、データストリーム内として標識付けされている場合、それをデータストリーム内として標識付けしていないその直接接続ノードには、０のデータストリームに基づく距離（本明細書ではストリームに基づく距離または「ＤＦＳ」とも呼ばれる）を伝える。ノードは、それをデータストリーム内として標識付けしている直接接続ノードには、宛先ノードへのリンクのサービス特性に関連するリンクコスト（「ＬＣ」）に等しいＤＦＳを伝える。これは、以下でより詳しく説明される。
【００９８】
ネットワーク３０ｃ内のコアＣｃの形成が今から説明される。ネットワーク３０ｃでは、図１４に示されるように、ノードＮ２ｃからＮ１３ｃがリンクＬ１ｃからＬ１１ｃによって接続されていることが最初に仮定される。ノードＮ１ｃおよびノードＮ１４ｃは、ネットワーク３０ｃの残りの部分に最初は接続されていないことも仮定される。
【００９９】
最初はどのノードＮｃも別のノードＮｃにペイロードトラフィックを送信しようと試みておらず、方法２００がノードＮ２ｃからＮ１３ｃの各々によって実行されて、それらの個々のデータベースＤｃが上で説明された優先順位付け基準に従って入力されていることも仮定される。図１５は、閉じられた破線の図として示され、本明細書で知識経路ブロックＫ２ｃ−ｘｃと呼ばれる、データベースＤ２ｃに入力される他のノードＮｃを示している。知識経路ブロックＫ２ｃ−ｘｃは、ノードＮ２ｃが認識している他のノードＮｃのすべて、すなわち、ノードＮ３ｃ〜Ｎ１０ｃ、およびノードＮ１２ｃを取り囲む。図１６は、閉じられた破線の図として示され、本明細書で知識経路ブロックＫ６ｃ−ｘｃと呼ばれる、データベースＤ６ｃに入力される他のノードＮｃを示している。知識経路ブロックＫ６ｃ−ｘｃは、ノードＮ６ｃが認識している他のノードＮｃのすべて、すなわち、ノードＮ２ｃ〜Ｎ５ｃ、ノードＮ７ｃ〜Ｎ１０ｃ、およびノードＮ１２ｃを取り囲む。図には示されていないが、当業者であれば、この例のこの時点におけるその他のデータベースＤｃの内容も理解されよう。
【０１００】
ここで、ノードＮ２ｃ〜Ｎ７ｃのいずれかとノードＮ８ｃ〜Ｎ１３ｃのいずれかの間のペイロードトラフィックは、リンクＬ６ｃを通過する必要があることに言及しておくのも有益である。したがって、このネットワークでは、リンクＬ６ｃが、この例のこの時点におけるネットワーク３０ｃの「コア」を表す。図１４では、コアは、リンクＬ６ｃを取り囲む楕円として示されており、Ｃｃで指示されている。リンクＬ６ｃが特にネットワーク３０ｃのコアＣｃであるという事実は、各データベースＤｃで明白に保持される必要はない。むしろ、各データベースＤｃは、コアＣｃに到達するための最良ネクストステップである隣接ノードを示す「最良隣接ノード」を決定する。コアＣｃに到達するための「最良隣接ノード」は、データベースＤｃを検査して、データベースＤｃで明白に保持されている他のノードに到達するための「最良隣接ノード」としてどの隣接ノードＮｃが最も頻繁に参照されたかを見出すことによって決定されることができる。どの隣接ノードＮｃも最良隣接ノードとして最も頻繁には出現しない場合、最高ランクを付けられた他のノードに関連する行１に出現する最良隣接ノードが、コアに到達するための最良隣接ノードとして選択されることができる。２つの隣接ノードＮｃが、コアに到達するための最良隣接ノードとして互いを指示し合うとき、コアが形成される。
【０１０１】
（このコア決定方法を先の例に適用すると、表ＸＩＩおよび図１１において、ノードＮ１ａにとってネットワーク３０ａのコアへの最良隣接ノードはノードＮ２ａとなり、ノードＮ２ａにとってネットワーク３０ａのコアへの最良隣接ノードはノードＮ３ａとなり、ノードＮ３ａにとってネットワーク３０ａのコアへの最良隣接ノードはノードＮ２ａとなり、ノードＮ４ａにとってネットワーク３０ａのコアへの最良隣接ノードはノードＮ２ａとなることを思い出されたい。ノードＮ２ａはノードＮ３ａを指示し、ノードＮ３ａはノードＮ２ａを指示しているので、リンクＬ２ａがネットワーク３０ａの「コア」である。）
【０１０２】
ネットワーク３０ｃなどのネットワークが最初に初期化されるとき、方法２００が十分な回数実行されて、データベースＤｃに入力が行われ、データベースＤｃが実質的に安定な状態を保持するようになるまで、複数のコアが形成されることをここで明らかにされたい。また、ノードＮｃが追加もしくは削除されると、またはリンクＬｃが追加もしくは削除されると（かつ／またはネットワークの全体的な状態に影響を与えるその他の要因が変化すると）、コアＣｃの位置は変化することができ、かつ／または複数のコアが形成され得る。
【０１０３】
図１４〜図１６に示された例に基づきながら、ここで図１７を参照すると、２つの新しいリンクがネットワーク３０ｃに追加されることが仮定されている。具体的には、リンクＬ１２ｃが、今ではノードＮ１ｃおよびＮ２ｃに加わり、リンクＬ１３ｃが、今ではノードＮ１３ｃおよびＮ１４ｃに加わっている。方法２００がノードＮ１ｃおよびＮ１４ｃによって実行され、残りのノードＮｃによって再実行されても、ネットワーク３０ｃのこの特定の構成では、リンクＬ６ｃにあるコアＣｃの場所は最終的に変化しない。しかし、各データベースＤｃの内容は、上述された優先順位付け基準に従って変化することもある。例えば、ノードＮ２ｃは、ノードＮ１ｃをデータベースＤ２ｃに追加し、ノードＮ１２ｃをデータベースＤ２ｃから削除する。
【０１０４】
また留意すべきことに、ノードＮ１ｃは、データベースＤ１ｃにノードＮ２ｃ〜Ｎ１０ｃについての知識を入力し、ノードＮ１４ｃは、データベースＤ１４ｃにノードＮ５ｃ〜Ｎ１３ｃについての知識を入力する。したがって、ノードＮ１ｃとノードＮ１４ｃは、互いについての知識をもたない。ここで、ノードＮ１ｃが、ノードＮ１４ｃにペイロードトラフィックを送信することを望んでいると仮定する。
【０１０５】
ノードＮ１ｃは、ノードＮ１４ｃについての知識をもたないので、この時点で、そのような知識を獲得するために、図１８に示される方法８００を実行することができる。ステップ８１０から開始して、発信ノードＮ１ｃは、宛先ノードＮ１４ｃにペイロードトラフィックを送信するよう求めるリクエストを受け取る。そのようなリクエストは、発信ノードＮ１ｃに関連するコンピューティング環境上で動作する別のアプリケーションから来ることができる。
【０１０６】
（余談だが、本明細書のさらなる教示からより明白になるように、この方法全体をより話し言葉風に翻訳すると、隣接ノードに送信されるリクエストは、「あなたに私の宛先ノード用の経路情報が見えるなら、どこにペイロードデータを送信すべきか適切な選択を私が行えるように、その情報について教えていただけませんか」という形をとることができる。ノードは、送信すべきペイロードをもっているのに、それを送信すべき場所が分からない場合、（タイムアウトが設定されているなら）ペイロードがタイムアウトになるか、またはその他のパケットのためにその領域が必要になるか、または直接接続ノードへのルーティングを可能にする経路更新を教えられるかするまで、そのペイロードをもち続ける。）
【０１０７】
次にステップ８２０で、ペイロードトラフィックが宛てられた宛先ノードがローカルデータベースＤｃ内に見つかるかどうかの判定が行われる。この例では、データベースＤ１ｃは宛先ノードＮ１４ｃについての情報を含まず、そのため、この判定の結果は「Ｎｏ」であり、方法８００はステップ８２０からステップ８３０に進むことを思い出されたい。（しかし、宛先ノードがデータベースＤ１ｃに存在する場合は、ステップ８３０で、ペイロードトラフィックは、データベースで識別された最良隣接ノードを介して、図１２のネットワーク３０ａまたは図１３のネットワーク３０ｂに関連して説明されたのとほぼ同じ方法で送信されることができる。）
【０１０８】
次にステップ８３０で、宛先ノードＮ１４ｃについての知識を求めて、コアに対して問合せが送信される。そのような問合せは、問合せが宛先ノードＮ１４ｃについての知識をもったノードＮｃに到達するまで、コアＣｃに到るための「最良隣接ノード」の経路に沿って、各最良隣接ノードによって、コアＣｃに向って受け渡されていく。したがって、各ノードＮｃは、問合せを受信し、それ自身のデータベースＤｃを検査し、宛先ノードＮ１４ｃについての知識をもつ場合は、そのような知識を発信ノードＮ１ｃにこれまでの経路を逆向きに送信する。問合せを受信したノードＮｃが宛先ノードＮ１４ｃについての知識をもたない場合、ノードＮｃは、問合せが宛先ノードＮ１４ｃについての知識をもつノードＮｃに到達するまで、コアＣｃに到るための最良隣接ノードである隣接ノードに問合せを受け渡していく。この例では、上で定められた優先順位付け基準によれば、ノードＮ９ｃがノードＮ１４ｃについての知識をもっているので、ノードＮ１ｃからの問合せは、ノードＮ２ｃからノードＮ３ｃ、ノードＮ６ｃ、そして最後にノードＮ９ｃに到るための経路を辿る。したがって、ノードＮ１４ｃについての知識は、逆向きにノードＮ６ｃ、ノードＮ３ｃ、ノードＮ２ｃを介して最終的にノードＮ１ｃに受け渡され、ノードＮ６ｃ、Ｎ３ｃ、Ｎ２ｃは各々、ノードＮ１ｃのためにペイロードトラフィックを送ることができるように、それら個々のデータベースＤｃに、ノードＮ１４ｃについての知識の記録を保持する。
【０１０９】
次にステップ８４０で、ステップ８３０で生成された問合せに対するレスポンスが、最終的に発信ノードＮｃによって受信される。したがって、この例では、ノードＮ１ｃが、ノードＮ９ｃからのノードＮ１４ｃについての知識を受信し、ステップ８５０で、ノードＮ１ｃは、ノードＮ１４ｃについての知識でそのデータベースＤ１ｃを更新する。その後、方法８００は、ステップ８５０からステップ８３０に進み、ペイロードトラフィックが、ノードＮ１ｃからノードＮ１４ｃに、図１２のネットワーク３０ａまたは図１３のネットワーク３０ｂに関連して説明されたのとほぼ同じ方法で送信されることができる。
【０１１０】
図１７に示された例に基づきながら、ここで図１９を参照すると、３つの新しいリンクがネットワーク３０ｃに追加されることが仮定されている。具体的には、リンクＬ１４ｃが、ノードＮ１２ｃとノードＮ８ｃに加わり、リンクＬ１５ｃが、ノードＮ８ｃとノードＮ５ｃの間に加わり、リンクＬ１６ｃが、ノードＮ５ｃとノードＮ２ｃの間に加わっている。各ノードＮｃは、これらの新しいリンクＬｃについての知識を吸収するために、方法２００を複数回実行する。そのような知識は、ネットワーク３０ｃ全体に伝播し、最終的に、ノードＮ１ｃからノードＮ１４ｃへのペイロードトラフィックの経路は、ノードＮ２ｃ、Ｎ５ｃ、Ｎ８ｃ、Ｎ１２ｃ、およびＮ１３ｃを介して進行する。
【０１１１】
ノードＮ１ｃおよびＮ１４ｃが互いについての知識を獲得する前に、リンクＬ１４ｃ、Ｌ１５ｃ、およびＬ１６ｃが存在していた場合、ノードＮ１ｃは、図１７および図１８に関連して説明されたように、最初にコアＣｃを介してノードＮ１４ｃについての知識を獲得し、その後、最適経路（すなわち、最良隣接ノードを介した最小ホップ数をもつ経路）が、図１９に示された例に収束することをここで理解されたい。
【０１１２】
方法８００は、発信ノードによって知られていない宛先ノードＮｃについての知識をコアＣｃから「プルする（ｐｕｌｌ）」ことに関するが、新しい宛先ノードＮｃがネットワーク３０ｃに加わる場合、そのノードＮｃは、それ自身についての知識をコアＣｃのノードに「プッシュする（ｐｕｓｈ）」こともでき、その結果、方法８００が実行されたときに、発信ノードＮｃは、新しい宛先ノードＮｃについての情報をコアＣｃにおいて確実に見出すことができる。図１４に与えられた例では、コアＣｃのノードＮ９ｃがノードＮ１４ｃについての知識を獲得することを自動的に保証する実行基準によって、そのような知識の「プッシュ」は必要とされなかった。しかし、ネットワーク３０ｃのその他の構成では、コアＣｃにおけるノードＮｃについての知識の「プッシュ」が望ましいこともある。
【０１１３】
本発明の様々な特徴および構成要素の特定の組合せだけが本明細書で説明されたが、開示された特徴および構成要素の所望の一部分、および／またはこれらの特徴および構成要素の代替的な組合せが、必要に応じて利用され得ることは、当業者には明らかであろう。例えば、上述の説明は、各ノードＮ（およびその変形）による方法２００の実質的な同期実行を企図しているが、そのような同期実行は必ずしも必要ではなく、説明を簡略化するために使用されたに過ぎないことを理解されたい。
【０１１４】
別の変形として、各ノードＮ（およびその変形）は、隣接ノードＮ（およびその変形）がデータベースＤに保存される最良隣接ノードとして選択されないとしても、隣接ノードＮ（およびその変形）によってノードＮ（およびその変形）に送信されたすべての情報の独立した記録を保持することもできる。これは、最良隣接ノードが削除された場合、ノードＮが、方法２００を再実行することなく、残りの隣接ノードＮから次の最良隣接ノードを選択することを可能にし、さもなければ、他の残りのすべての隣接ノードからの更新情報を待たなければならない。
【０１１５】
したがって、本発明は、ネットワーキングのための新規なシステム、方法、および装置を提供する。
【０１１６】
本発明のさらに別の実施形態が企図され、これらの実施形態のいくつか再検討は、本発明のさらなる理解をもたらす。以下に示される実施形態では、いくつかの用語または概念が、これまでのセクションのものとはいくぶん異なることがある。そのような相違は、これまでの実施形態に対する代替および／または補足と考えられたい。
【０１１７】
一般に、本発明のネットワークアーキテクチャは、ネットワーク内の個々のノードが、それらの動作を調整し、その結果、それらの動作の総和が、ネットワーク内のノード間の通信を可能にすることを可能にする。
【０１１８】
無線環境ネットワークで使用される既存のアドホックネットワークの主な制限は、数百ノードを超えて規模を拡張する能力であるが、本発明のネットワークアーキテクチャおよび関連方法は、従来技術の拡張性問題を少なくとも緩和し、ある状況ではそれらを克服する。
【０１１９】
したがって、例示的な実施形態が、理解を明瞭にするために以下に示される。これらの例は、数、他の業者のソフトウェア、またはその他の詳細について具体的な言及がなされる場合でも、本明細書で説明される方法およびシステムの一般性を限定することを意図していない。２以上の合体された概念が、別々に実施可能であり、または別々に役立ち得る場合、そのように明示的に説明されていなくても、当業者にはそれが理解できるであろう。代替実施形態は、具体的に述べられていない限り、相互に排他的であると見なされるべきではない。
【０１２０】
以下の実施形態では、以下の用語が使用される。
【０１２１】
ノード
ネットワーク内の各ノードは、リンクを介して１つまたは複数の他のノードに直接接続される。ノードは、コンピュータ、ネットワークアダプタ、スイッチ、無線アクセスポイントとすることができ、またはメモリを含み、データ処理能力を備える任意の装置とすることができる。しかし、ノードの形態は特に限定されない。
【０１２２】
リンク
リンクは、情報を伝送することが可能な、２つのノード間のコネクションである。２つのノード間のリンクは、一緒に「結合」されたいくつかの異なるリンクとすることができる。リンクは、（ワイヤなど）物理的とすることができ、（ボックス、小型装置、液体などの）実際の物理的品目、コンピュータバス、無線、マイクロ波、光、量子相互作用、音響などとすることができる。リンクは、一連の様々なタイプの別個のリンクとすることができる。しかし、リンクの形態は特に限定されない。
【０１２３】
リンクコストの計算
「リンクコスト」は、２以上のリンク間の比較を可能にする値である。この文書では、「リンクコスト」が低いほど、より良いリンクであるとする。これは標準的なアプローチであり、当業者であれば可能な変形を知っているであろう。
【０１２４】
リンクコストは、リンクの品質を記述するのに使用される値である。リンクのリンクコストは、
１．回線品質
２．動作可能時間
３．リンク整合性
４．待ち時間
５．帯域幅
６．信号対雑音比
７．ノードの残存バッテリ電力
に基づくことができる（ただし、それらに限定されない）。
【０１２５】
リンクコストは、それが基づく要因が変化するにつれ、時間とともに変化することができる。
【０１２６】
当業者であれば、リンクコストを割り当てること、または動的発見メカニズムを作成することができよう。
【０１２７】
リンクコストの割り当ては、ネットワーク全体にわたって一貫性のあることが推奨される。例えば、ネットワークの異なる部分の２つの同一のリンクは、同じまたは類似したリンクコストを有するべきである。
【０１２８】
パイプ（ｐｉｐｅ）のリンクコストは、その品質に対してほぼ直接的な関係を有することが推奨される。例えば、１Ｍビットのパイプは、１０Ｍビットのパイプの１０倍のリンクコストを有する。これらのリンクコストは、ダイクストラ的アルゴリズムを使用して、ネットワークを介した最良経路を見つけるのに使用される。
【０１２９】
代替実施形態は、リンクコスト全体の（例えば）１％を超えない僅かなランダム量だけ、計算されたリンクコストをランダムに変化させることを含む。
【０１３０】
ノード名
ネットワーク内の各ノードは一意名を有する。
【０１３１】
この一意名は、
１．ノードによって生成されることができる。
２．ノードの起動前に割り当てられることができる。
３．ＤＨＣＰ（動的ホスト構成プロトコル）サーバに結果的に類似した方法で、ノードによって中央ロケーションに要求されることができる。ノードがこの説明されたネットワークを使用して中央ロケーションに名前を要求する場合、ノードは最初、ランダムな一意名を選び、その名前を使用して中央ロケーションに名前を要求する。
【０１３２】
ノードは、その名前を永続的に保持することができ、または起動時もしくは所望の任意の時点で新しい名前を生成することができる。ノードＡは、ノードＢの名前を知っていれば、ノードＢにメッセージを送信することができる。
【０１３３】
ノードは、いくつかの異なるノードをエミュレートするために複数の名前を有することができる。例えば、ノードは、「プリントサーバ」および「ファイルサーバ」という２つの名前を有することができる。
【０１３４】
ノードは、それに対して確立された新しいコネクションごとに、新しい名前を生成することができる。
【０１３５】
ポートはメッセージの宛先として説明されるが、これらの例におけるポートの使用は、本発明をポートの使用にのみ限定することを意図していない。当業者であれば、メッセージの宛先として使用され得るその他のメカニズムを知っていよう。例えば、ノードは、コネクションごとに、一意名を生成することができる。
【０１３６】
通常、ノードは一意名を有するべきである。代替実施形態は、ノードが、ネットワーク内の１つまたは複数の別のノードと名前を共有することを可能にする。このことは後ほど詳しく説明される。
【０１３７】
ノードが有する名前の数、ノードがどれほどの頻度で名前を追加もしくは削除するか、何という名前か、ノードが選択した１つまたは複数の名前について誰かに知らせるかに関して、発明者らによって暗示される制限は存在しない。
【０１３８】
この文書では明瞭さのため、各ノードは、それに関連する一意名を１つだけ有すると仮定する。このことが本発明の範囲を限定すると見なされるべきではない。ノードは、ネットワーク内の１つまたは複数の他のノードと同じ名前を共有することができる。
【０１３９】
ノード間のコネクションを確立する
リンクが２つのノード間に確立されることができ、これらのノードがリンクを確立することを望む場合、ノードは、そのコネクションを確立するため、いくつかの情報を交換する必要がある。この情報は、バージョン番号などを含むことができる。
【０１４０】
代替実施形態は、「タイブレーカ」番号の交換を含むことができ、タイブレーカ番号は、その番号以外は等しいリンクの間で、ノードが選択を行うことを可能にする。すべての直接接続ノードに同じタイブレーカ値が与えられることが推奨される。ある他のノードからの等価のタイブレーカ番号をすでに見たことがあるとノードＡがノードＢに伝えた場合、ノードＢは、新しいタイブレーカ番号を選び、その番号をすべての直接接続ノードに送信する必要がある。このプロセスは図２０に示されている。
【０１４１】
新しいタイブレーカ番号を求めるリクエストは、（例えば）以下のようにすることができる。
struct sRequestNewTieBreaker [
// This structure is empty, if the node sees this message it will
// generate a new tie breaker value and tell all its directly connected
// nodes this new value
]
【０１４２】
代替実施形態は、このノードがそれについて知ることを望むノードの最大数を含むことができる。例えば、ノードＡが限界のあるメモリを有する場合、ノードＡは、最大でＸ個の異なるノードについてノードＡに教えるようノードＢに伝える。
【０１４３】
代替実施形態は、コネクションを確立するのに使用されたリンクのリンクコストの交換を含むことができる。リンクコストがネットワークの動作中に変化した場合、ノードは、リンクの他端の直接接続ノードに、リンクコストが変化した旨のメッセージを送信することができる。リンクコストが交換される場合、ノードは同じリンクコストに同意することができ、または異なるリンクコストをそれまで通り選択して、非対称コネクションを示すこともできる。
【０１４４】
これまでの３つの代替実施形態がすべて含まれる場合、交換されるメッセージは、（例えば）以下のようになる。
struct sIntroMessage [
// the number used to break ties
int                            uiTieBreakerNumber;
// the maximum number of destination nodes
// this node wants to know about.
int                            uiNodeCapacityCount;
// the link cost for the connection between these two nodes
float                          fLinkCost;
]
【０１４５】
図２１は、初期化プロセスのフローチャートである。
【０１４６】
コネクションは、メッセージを順番に誤りなく送り届けることができると仮定される。これが可能でない場合、コネクションは「障害」として扱われると仮定される。
【０１４７】
ノード知識の拡散
ノードＡは、ノードＢにメッセージを送信するためには、ノードＢに到達するための最良ネクストステップである直接接続ノードまたはリンクばかりでなく、ノードＢの名前も知る必要がある。
【０１４８】
ノードＡまたはノードＢは、別のノードからメッセージを送信されることを望む場合、それらの名前を少なくとも１つの直接接続ノードに伝えなければならない。
【０１４９】
ノードは、別のノードへのリンクを確立すると、ノード情報を送信し始めることができる。ノード情報は、ノードの名前と、そのノードに到達するための累積リンクコストを含む。ネットワークが起動されたばかりのとき、ノードはそれ自身を除いて他のノードの名前については何も知らず、したがって、そのノードが知っているノード（それ自身）に対する初期累積リンクコストは０である。
【０１５０】
ノードは、リンクＬから別のノードＡについての知識を受信すると、リンクＬのリンクコストをノードＡについて告げられた累積リンクコストに追加し、リンクＬに関連するその情報をデータベースＤに保存する。コネクションＬから受信されたノードＡについてのリンクコストは、このノードによってデータベースＤから参照される場合、それに追加されたそのリンクＬのリンクコストを暗黙的に含んでいる。
【０１５１】
各ノードは、それが各リンクから受信した情報を保存する。ノードは、リンクの他端のノードの名前を知る必要はない。ノードがする必要があるのは、リンクの他端のノードがそれに送信している知識を記録することだけである。ノードは、それが隣接ノードから受信したすべてのノード更新を保存する。
【０１５２】
ノードＮは、あるリンクからノードＢについての知識を受信すると、その累積リンクコストを他のリンクから受信したノードＢについての累積リンクコストと比較する。ノードＮは、ノードＢに流れるメッセージのためのその「最良隣接ノード」として、最低累積リンクコストをもつリンクを選択する。ノードＮは、直接接続ノードにノードＢについての更新を送信するとき、ノードの名前とその直接接続ノードから受信した最低累積リンクコストをそれらに伝える。
【０１５３】
累積リンクコストは加法的である。図２２はこの加法的特性を示している。
【０１５４】
このプロセスは、ノードについての知識がネットワーク全体に広がり、各ノードが１つのリンクを最低累積リンクコストを有するとして選択するまで続けられる。
【０１５５】
このプロセスは、ネットワークを通る最短経路を見つけるためのダイクストラのアルゴリズム、またはベルマンフォードアルゴリズムと非常に類似している。当業者であれば、そのような手法および同様の結果を生じる変形について知っていよう。
【０１５６】
図２３〜図２６は、ネットワークを通るノード知識のフローを示している。すべてのリンクは、コスト１を有すると仮定される。これは、単なる例であると見なされ、決して本発明の一般性を限定することを意図していない。例えば、リンクは異なるリンクコストを有することができ、ノードの数およびそれらの具体的な相互接続は、無限に変化させることができる。
【０１５７】
いかなる時点でも、ノードは、ネットワークトポロジの全域的視野を構築する必要はない。ノードは、直接接続ノードがそれに伝えたノード知識について知っているだけである。このタイプのネットワークは、当業者によって距離ベクトルネットワークと比較されることができる。
【０１５８】
代替実施形態は、（先に説明された）タイブレーカ番号を使用して、最低累積リンクコストをもつ２以上のリンクの間で選択を行うことができる。
【０１５９】
ノード知識を広めるメッセージの構造体は、（例えば）以下のようになる。
struct sNodeKnowledge [
Name                NameOfTheNode;
Float               fCumulativeLinkCost;
]
【０１６０】
ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔは、その特定の名前を有するノード上では０に設定されるべきである。
【０１６１】
代替実施形態は、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔをその特定の名前を有するノード上で非０に設定することができる。これは、宛先ノードの本当のロケーションを偽装するのに使用されることができる。ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔをその特定の名前を有するノード上で非０（例えば、５０）に設定しても、ネットワークの収束には影響しない。
【０１６２】
リンクコスト変更
リンクコストが変化した場合、ノードは、新リンクコストと旧リンクコストの差をとり、その差をそのリンクから受信されたすべてのノード情報の累積リンクコストに加える必要がある。
【０１６３】
以下に示すのは、そのリンクコストを変更したリンクから受信された各ノード更新に対して、累積リンクコストがどのように調整され得るかを示す例示的な擬似コードである。
CumualtiveLinkCost = CumualtiveLinkCost + (NewLinkCost-
OldLinkCost);
If (CumualtiveLinkCost > INFINITY) CumualtiveLinkCost = INFINITY;
【０１６４】
この変更に基づいて、ノードは、その「最良隣接ノード」の選択を再評価する。ノードは、ある特定の宛先ノードに対する最低累積リンクコストを変更したすべてのノードについて、その隣接ノードに伝える必要がある。
【０１６５】
例えば、宛先ノードＡに対する「最良隣接ノード」として選択されていないリンクのリンクコストが変化し、変化後も依然として、そのリンクが宛先ノードＡに対する「最良隣接ノード」として選択されないならば、ノードＡについての累積リンクコストは同じままであり、更新が直接接続ノードに送信される必要はない。
【０１６６】
リンク削除（リンクが削除される場合）
これは、そのリンクのリンクコストが無限大に向うのと同じであると見なされ得る。
【０１６７】
このリンクを「最良隣接ノード」として使用していた各宛先ノードに関して、次の「非無限大の」代替最良隣接ノードが選択される。そのような代替最良隣接ノードが存在しない場合、「最良隣接ノード」は選択されることができず、すべての直接接続ノードは、それらのノードについて無限大の累積リンクコストを告げられる。
【０１６８】
「最良隣接ノード」が選択されない場合、それらのノードを宛先とするメッセージは、送信されることができない。
【０１６９】
大規模ネットワーク
相互接続速度およびノード能力に大きなばらつきがある大規模ネットワークでは、数百万のノードが存在するとしても、ネットワーク内で任意の与えられたノードが任意の他のノードに接続できることを保証するため、異なる技法が利用される必要がある。
【０１７０】
本発明に特有の方法を使用すると、宛先ノードについての知識はネットワーク中に速やかに広まる。大規模ネットワークにおける問題は３点ある。
１．すべての宛先ノードについてあらゆるノードに知らせておくのに必要とされる帯域幅は、データのために帯域幅が残らないほど増大する。
２．データが流れるよう保証するため、宛先ノード更新を抑制する帯域幅を使用すると、宛先ノード更新の伝播速度が大きく低下する。
３．ネットワーク内のあらゆるノードについて知るのに十分なメモリをもたないノードは、ネットワーク内のあらゆるノードには接続できず、ネットワーク内のあらゆるノードに接続するのに十分な資源をもつノードの能力も制限することがある。
【０１７１】
ネットワークの「コア」または中心という考え方を導入することによって、解決策が見出される。
【０１７２】
ネットワークのコアは、平均的なノードよりも大量のメモリおよび帯域幅を有することがほとんどであり、たいていの場合、トポロジ的に中央に配置される。
【０１７３】
この新しいネットワークシステムは、ネットワークトポロジについての知識、またはそれに直接接続されたノード以外のネットワーク内の他のノードについての知識を何も有していないので、ノードは、ネットワークのコアがどこにあるのか近似的に知ることができるに過ぎない。
【０１７４】
これは、どのリンクが大多数の宛先ノードのための「最良隣接ノード」であるかを検査することによって達成されることができる。直接接続リンクは、最低累積リンクコストを有しているので、宛先ノードのための「最良隣接ノード」として選択される。最低リンクコストは一般に、最終的な宛先ノードに最も近いリンクによって提供される。あるリンクが、他のどのリンクと比べてもより多くの宛先ノードのための「最良隣接ノード」として使用される場合、このリンクが、コアまたはネットワークの中心に向うステップと見なされる。
【０１７５】
一代替実施形態は、何らかの他のノードまたはビーコン（ｂｅａｃｏｎ）に到るための最良ネクストステップについて決定し、これをその「コアに到るための最良ネクストステップ」として使用するノードとすることができる。
【０１７６】
一代替実施形態は、要因のある組合せを使用して、何がその「コアに到るための最良ネクストステップ」であるかを決定するノードとすることができる。これらの要因は、以下のいずれかの要因の組合せとすることができる（ただし、それらに限定されない）。
１．ある目標ビーコンを見出した無線方向
２．ＧＰＳ位置座標、およびある場所に到るための最良ネクストステップ
３．１つまたは複数の特殊マーカノード
４．その他の外部的に測定可能な何らか要因
【０１７７】
ノードは、ネットワークの中心がどこにあるかを知っている必要はなく、ネットワークの中心に到るための最良ネクストステップだけを知っていればよい。
【０１７８】
コアは、２つのノードが互いをコアに到るための最良ネクストステップとして選択した場合として定義されることができる。コアについて何も特別なことはなく、コアを形成する２つのノードは、ネットワーク内の他の任意のノードが動作するように動作する。
【０１７９】
どれが最も多くの宛先ノードのための「最良隣接ノード」として選択されたかについて、１組の直接接続ノードの間に同点のものが存在する場合、（初期化時に渡された）「タイブレーカ」値が最も高い直接接続ノードが、コアに到るための最良ネクストステップとして選択される。このメカニズムは、非自明なネットワーク内に（ノードＡ−＞ノードＢ−＞ノードＡのタイプのループを除いて）ループが存在しないことを保証する。このタイブレーカを用いる実施形態が使用されない場合、ランダムな選択が行われ得る。
【０１８０】
ノードの「コアに到るための最良ネクストステップ」を使用するというこのアイデアは階層を形成する。この階層は、特定のノード知識を階層内でツリーの頂点まで押し上げるのに使用されることができる。（後ほど説明される）ＨＳＰＰは、この階層を利用して、ノード知識をこの階層内で押し上げる（または引き下げる）。
【０１８１】
図５４は、各ノードがコアに到るための最良ネクストステップとして直接接続ノードを選択したネットワークの一例である。ネットワークは、その後、生成された階層の性質をより良く示すように再構成される。ネットワークトポロジが変化すると、形成された階層も変化する。
【０１８２】
孤立コアを検出する
一代替実施形態は、「孤立コア」の検出を助ける。
【０１８３】
コアは、互いをコアに到るための最良ネクストステップとして選択した２つの直接接続ノードとして定義される。図２７はこの一例を示している。
【０１８４】
ノードは、「コアに到るための最良ネクストステップ」として直接接続ノードを選択すると、その直接接続ノードにその選択について伝える。これは、他のノードがそれらのコアとして使用しないコアをノードが生成したとき、ノードがそれを検出することを可能にする。
【０１８５】
渡されるメッセージは、以下のようにすることができる。
struct sCoreMessage [
bool                bIsNextStepToCore;
]
【０１８６】
コアが生成された場合、コアを形成する両方のノード（この例ではノードＡとノードＢ）は、それらが直接接続ノードをいくつ有しているかを知るために調査を行う。直接接続ノードが２以上存在する場合、両ノードは、他のすべての直接接続ノードを検査する。
【０１８７】
このノードをコアに到るための最良ネクストステップとして選択した唯一の直接接続ノードが、コアが生成される原因となったノードである場合、このノードは、次善の選択肢を選択して、コアに到るための最良ネクストステップにする。
【０１８８】
これは、本当のコアへの知識の流れを阻害し得るコアを排除することを助けることができる。
【０１８９】
コアに到るための最良ネクストステップを選択する例示的な代替方法
これまで説明された手法は、直接接続ノードに、その直接接続ノードを「最良隣接ノード」として選択した各宛先ノード１つにつき得点「１」を割り当てることを含んでいた。最高カウント（または孤立コアの場合は２番目の高カウント）をもつノードが、コアに到るための最良ネクストステップである。
【０１９０】
実施形態が複数の「最良隣接ノード」を使用する場合（後ほど説明されるマルチパスなどの場合）、各宛先ノードのために選択される各「最良隣接ノード」は、適切な得点を割り当てられることができる。代替として、（マルチパスの場合）最良待ち時間を有する「最良隣接ノード」だけが、得点を割り当てられることができる。
【０１９１】
各直接接続ノードに、それを最善の選択肢として選択した各宛先ノード１つにつき得点１を割り当てる代わりに、その他の値を使用することができる。
【０１９２】
例えば、ｌｏｇ（ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔ  ＋１）＊５００を、割り当てられる得点とすることができる。他のメトリックも使用することができる。このメトリックは、より遠く離れた宛先ノードにより大きな重みを与えるという利点を有する。類似したコネクションおよびノードを有する稠密な網目では、このタイプのメトリックは、より集中化されたコアが形成されることをより良く助けることができる。
【０１９３】
より遠く離れた宛先ノードにより大きな重みを与えるというアイデアを拡張するのに使用され得る別の可能な実施形態は、すべての宛先ノードをそのリンクコストによって順序付け、最も遠く離れたｘ％（例えば５０％）だけを使用して、コアに到るための最良ネクストステップを決定することである。
【０１９４】
別の実施形態は、各ノードに割り当てられた加重値を使用することができる。この重みは、名前を生成したノードによって割り当てられることができる。例えば、この加重値がノード更新の構造体に追加される場合、それは以下のようである。
struct sNodeKnowledge [
Name                 NameOfTheNode;
Float                fCumulativeLinkCost;
Int                  nWeight;
]
【０１９５】
（ｓＮｏｄｅＫｎｏｗｌｅｄｇｅ構造体の中にある）ｎＷｅｉｇｈｔ値は、より強力なノードの近くにコアが形成されるのを助けるために使用されることができる。例えば、割り当てられる得点は、１０＾ｎＷｅｉｇｈｔ（１０は一例）によって乗じられることができる。これは、それらが数百万の非常に非力なノードに取り囲まれているとしても、１つまたは２つの大きなノードの近くにコアが形成されることを助ける。
【０１９６】
ｎＷｅｉｇｈｔ値は、ネットワーク内のすべてのノードに対して一貫した方式で割り当てられるべきである。ノードのタイプ別の可能なｎＷｅｉｇｈｔ値は以下のようである。
【表１５】
2007523546.tif 000017
【０１９７】
これらの重み値は提案に過ぎず、当業者であれば、自らの応用例にとって適切な値を割り当てることができよう。
【０１９８】
非対称リンクコストを有するネットワークにおけるコアに到るためのネクストステップ
これは、コアに到るための最良ネクストステップを選択するための一代替実施形態である。
【０１９９】
リンクが非対称コストを与えられている場合、例えば、ノードＡとノードＢに加わったリンクＬが、ＡからＢに向うときはコスト１０をもち、ＢからＡに向うときはコスト２０をもつ場合、一代替実施形態は、ネットワーク内の単一の場所にコアが形成されるのを助けるのに役立つ。
【０２００】
先の一実施形態では、ノードは、特定のリンクのリンクコストについて同意し、この共有リンクコストに基づいた「最良隣接ノード」選択を使用した。
【０２０１】
「最良隣接ノード」を決定するのに非対称リンクコストが使用される場合、対称リンクコストの使用が、コアに到るためのネクストステップを選択するために使用されることができる。対称リンクコストの使用は、コアが実際に形成されるよう保証することを助けることができる。
【０２０２】
ノードは、知っている各ノードについて、どのリンクがそのノードに到達するための最良ネクストステップであるかを決定する。ノードは、この最良ネクストステップを、累積リンクコストとおそらくはタイブレーカ番号に基づいて選択する。その後、この「最良隣接ノード」は、それに割り当てられたその他の得点と合計される得点を与えられる。最も大きな得点をもつ「最良隣接ノード」が、コアに到るための最良ネクストステップとして選択される。
【０２０３】
この代替実施形態では、ノードは、それが結合されているノードと、リンクの代替コストについて同意を交わす。この代替リンクコストは、両方のノードにとって同じである。この代替リンクコストは、累積リンクコストを調整するために使用される。「最良隣接ノード」の選択は、この代替累積リンクコストを用いて行われる。この「最良隣接ノード」は、実際のノードに到るための最良ネクストステップとして選択される「最良隣接ノード」でなとしても、コアに到るための最良ネクストステップとして選択される結果をうむ得点を割り当てられる。
【０２０４】
以下の式は、代替累積リンクコストがどのように計算され得るかを示している。
AltemativeCumulativeLinkCost = ActualCumulativeLinkCost + (AlternativeLinkCost-ActualLinkCost)
【０２０５】
高速伝播経路（「ＨＳＰＰ」）
ネットワークのコアにないノードは、ネットワークのコアにあるノードと同じほど大量のメモリを一般に有さず、それらがノードＮについての知識を有しているときにはじめて、他のノードがノードＮに接続することが可能になるノードＮについての知識を失うことがある。これらのノードが知識を失った場合、ネットワーク内の他のノードは、そのノードＮに接続することができない。
【０２０６】
同様に、ノードＱとのコネクションを確立することを求めているノードは、同じ問題に直面する。ノードが探しているノードＱについての知識は、ノードに十分な速さで到達せず、またはノードＱもしくはそれに接続を試みているノードが低容量ノードによって取り囲まれている場合、おそらくまったく到達しない。
【０２０７】
１つの手法は、「コアに到るための最良ネクストステップ」に関する各ノードの選択によって生成される暗黙の階層を使用することである。ノード知識は、この階層をコアへと押し上げられ、押し下げられる。これは、ネットワークの中心へのおよび中心からのノード知識の効率的な転送を可能にする。
【０２０８】
ノード知識は、本明細書で高速伝播経路（「ＨＳＰＰ：Ｈｉｇｈ  Ｓｐｅｅｄ  Ｐｒｏｐａｇａｔｉｏｎ  Ｐａｔｈ」）と呼ばれる方法を使用して、プッシュ（ｐｕｓｈ）／プル（ｐｕｌｌ）されることができる。ＨＳＰＰは、ノードとコアの間の１つまたは複数の標識付けされた経路と考えられ得る。その経路は、一度設定されると、それを生成したノードが削除されるまで保持される。
【０２０９】
２つのタイプのＨＳＰＰが存在する。第１のものは、通知ＨＳＰＰである。通知ＨＳＰＰは、特定のノードについての知識をコアに向ってプルする。ＨＳＰＰが通過するノードは、ＨＳＰＰに関連するノードについての知識を失うことは許されない。すべてのノードは、自身についての知識をコアへと送るために、通知ＨＳＰＰを生成する。
【０２１０】
要求ＨＳＰＰは、ノードが別のノードについての知識を探しているときにだけ生成される。要求ＨＳＰＰは、コアに向って知識をプルする代わりに、それを生成したノードに向って知識をプルする点を除いて、通知ＨＳＰＰと同じ方法で動作する。
【０２１１】
（ＨＳＰＰについての文脈では、「プッシュ」および「プル」という用語は、説明の目的で役立つが、実際にはＨＳＰＰは、ノードデータベース内のあるノードの「ランク」を、そのノードについての知識が他のノードについての知識より先に送信されるように改善するので、いくぶん不自然な用語と考えられ得ることは、当業者であれば理解されよう。）
【０２１２】
ＨＳＰＰは、各ノードのコアに到るための最良ネクストステップを使用して、コアに向って進む。各ノードの「コアに到るための最良ネクストステップ」は、暗黙の階層を生成する。
【０２１３】
ＨＳＰＰは、ユーザメッセージ自体のための経路ではなく、むしろ問題とする１つまたは複数のノードについての知識を保持し、その１つまたは複数のノードについての知識をＨＳＰＰに沿って速やかに送信するよう経路上のノードに強制する。ＨＳＰＰはまた、ＨＳＰＰに関連するノード名についての更新の優先順位を上げる。これは、この暗黙の階層の頂点に向って速やかに経路更新を送信するという結果を有する。
【０２１４】
ＨＳＰＰは、ユーザデータメッセージがどこを流れるかを指定しない。ＨＳＰＰは、コアに到るための少なくとも１つの経路が常に存在することを保証し、ノードが他の各ノードへの初期コネクションを形成するのを助けるためだけに存在する。初期コネクションが一度形成された後では、ノードはもはやＨＳＰＰを使用する必要はない。
【０２１５】
ＨＳＰＰは、１つのノード名に属するものとして、または１つのノード名に関連付けられたものとして参照されることができる。これは、ＨＳＰＰが関連付けられ得るノードの数またはタイプを決して制限しない。この実施形態では、ＨＳＰＰの名前は通常、ＨＳＰＰがコアにプッシュ／コアからプルしているノードの名前である。
【０２１６】
ＨＳＰＰは、特定のノード名またはノード名のクラス／グループに結び付けられる。ノードは、特定の宛先ノードのためのＨＳＰＰをホストする場合、そのＨＳＰＰによって参照されるノードについてのノード知識を即座に処理し、送信する。
【０２１７】
この場合のノード知識は、（例えば）ｓＮｏｄｅＫｎｏｗｌｅｄｇｅの更新と考えられ得る。
【０２１８】
一代替実施形態は、その処理を下記の場合に制限することができる。
１．宛先ノードについての初期知識
２．宛先ノードのｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔが無限大になる場合
３．宛先ノードのｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔが無限大から何らかの他の値に移る場合
【０２１９】
これによって、ＨＳＰＰ内のノードのどれか１つがＨＳＰＰによって参照される１つまたは複数のノードを「見る」ことができるならば、ＨＳＰＰ内のすべてのノードがＨＳＰＰによって参照されるノードについて常に知っていることを保証することができる。
【０２２０】
ノード知識は、ＨＳＰＰには含まれない。ＨＳＰＰは、特定の１つまたは複数のノードについての知識に対して非常に高い優先順位を有する経路を設定するだけである。これは、ＨＳＰＰによって参照されるそれらのノードのノード更新が即座に送信されることを意味する。
【０２２１】
ＨＳＰＰは一般に、双方向経路であると見なされる。
【０２２２】
代替実施形態は、２つのタイプのＨＳＰＰを有することができる。１つのタイプは、コアに向ってノードについての知識をプッシュする。このタイプのＨＳＰＰは、通知ＨＳＰＰと呼ばれることができる。第２のものは、ＨＳＰＰを生成したノードに向ってノードについての知識をプルする。このタイプのＨＳＰＰは、要求ＨＳＰＰと呼ばれることができる。
【０２２３】
ノードは、最初にネットワークに接続されるとき、そのノード名に基づいてＨＳＰＰを生成することができる。このＨＳＰＰは、この新たに生成されたノードについての知識をネットワークのコアに向ってプッシュする。このノードによって生成されたＨＳＰＰは、ノードに寿命がある間は、またはノードがＨＳＰＰを保持することを望む限りは保持されることができる。ノードが切断された場合、またはノードがＨＳＰＰをもはや保持しないと決定した場合、ＨＳＰＰは削除される。一代替実施形態は、このＨＳＰＰを双方向ＨＳＰＰの代わりに「プッシュＨＳＰＰ」にすることができる。
【０２２４】
ノードは、別のノードＮに接続しようと試みる場合、そのノードＮを参照するＨＳＰＰを生成する。このＨＳＰＰは、コアへと進み、ノードＮについての知識を、ＨＳＰＰを生成し、ノードＮに接続することを望んでいるノードにプルするのを助ける。一代替実施形態は、このＨＳＰＰを双方向ＨＳＰＰの代わりに「プルＨＳＰＰ」にすることができる。
【０２２５】
ノードは、（たぶんノードＮへのコネクションがもはや必要でなくなったため）ＨＳＰＰを保持することをもはや望まない場合、「ｂＡｃｔｉｖｅ」＝ｆａｌｓｅとしたＨＳＰＰ更新を、ｂＡｃｔｉｖｅ＝ｔｒｕｅとした最初のＨＳＰＰを送信したすべての直接接続ノードに送信することができる。これは、ＨＳＰＰを生成したノードによってだけ実行されるべきである。
【０２２６】
代替実施形態は、より高速な再接続を容易にするため、コネクションが切断された後もしばらくの間は、要求ＨＳＰＰを生成したノードによって要求ＨＳＰＰが保持されることを可能にすることができる。
【０２２７】
両方のタイプのＨＳＰＰが、コアへと進む。ノードについての知識をコアに送信するＨＳＰＰは、ノードに寿命がある間、保持されることができる。要求ＨＳＰＰは、コネクションに寿命がある間、おそらく保持される。
【０２２８】
一代替実施形態は、ＨＳＰＰを生成したノードに、そのＨＳＰＰを、ネットワークのコアに到るための最良ネクストステップだけではなく、すべての直接接続ノードに送信させる。この実施形態は、移動（moving）および移行（shifting）の間、ネットワークがより堅牢になることを可能にする。
【０２２９】
一代替実施形態は、ノードがある直接接続ノードに、その直接接続ノードによって要求された最大ノードより多くのＨＳＰＰを送信しないよう確認することを含む。
【０２３０】
ＨＳＰＰは、ユーザデータメッセージがどこを流れるべきかを指定せず、ノード間または１つのノードとコアの間に（おそらく非最適）コネクションを確立するのを助けるだけである。
【０２３１】
ＨＳＰＰは、コアに到達する前にノード知識と遭遇したとしても、コアへと進む。代替実施形態は、ＨＳＰＰがコアに到達する前に、ＨＳＰＰを停止させることができる。
【０２３２】
ＨＳＰＰはどのように確立され保持されるか
ノードは、ＨＳＰＰについて伝えられると、そのＨＳＰＰの記憶を失うよう命じられるまで、またはノードとそのＨＳＰＰについてそれに伝えたノードとの間のコネクションが切断されるまで、そのＨＳＰＰのことを記憶する。
【０２３３】
伝えられることを望むノードの数をノードが制限する一実施形態では、そのノードは、与えられただけのＨＳＰＰを保存する。ノードは、直接接続ノードに、その直接接続ノードが要求した最大宛先ノード数より多くのＨＳＰＰを送信すべきではない。
【０２３４】
あるシステムでは、ノード上で利用可能なメモリの量は、十分なメモリが存在し、どれだけ多くのＨＳＰＰがノードを通過しても、ノードはそれらすべてを保存できると仮定できるほどある。この仮定は満たされる可能性が非常に高いが、それは、ノード上のＨＳＰＰの数は、このノードがコアにどれだけ近いかにおおよそ関連し、ノードは通常、大きな容量としたがっておそらく大量のメモリをもたない限りコアに近くないからである。
ＵＲ＝最終受信器ノード
ＵＳ＝最終送信器ノード
【０２３５】
ＨＳＰＰは以下の形式をとる。
struct sHSPP [
// The name of the node could be replaced with a number
// (discussed later). It may also represent a class of nodes
// or node name.
sNodeName nnName;
// a boolean to tell the node if the HSPP is being
// activated or removed.
bool                              bActive;
// a boolean to decide if this a UR (or US generated HSPP)
bool                              bURGenerated;
];
【０２３６】
これらの説明では、ＨＳＰＰ  Ｈは、ｂＡｃｔｉｖｅまたはｂＵＲＧｅｎｅｒａｔｅｄ（より一般にＨＳＰＰタイプ）が何であるかに関わらず、ＨＳＰＰ  Ｈと呼ばれると見なされる。ＨＳＰＰ  Ｈは、それが表すノード名からその名前を得る。
【０２３７】
一代替実施形態は、ＨＳＰＰ  Ｈの名前が、それが参照する１つ（または複数の）ノード名に結合されていない場合とすることができる。この実施形態におけるＨＳＰＰ構造体は、（例えば）以下のようであることができる。
struct sAlternateHSPP [
// a unique name to represent this HSPP 
sHSPPName  HSPPName;
//The name of the node could be replaced with a number
// (discussed later). It may also represent a class of nodes
// or node name.
sNodeName  nnName;
// a boolean to tell the node if the HSPP is being
// activated or removed.
bool                              bActive; ,
// a boolean to decide if this a UR (or US generated HSPP)
bool                              bURGenerated;
];
【０２３８】
以下の説明は、ＨＳＰＰがどのように働くのかを説明するために、（ｓＡｌｔｅｍａｔｅＨＳＰＰではなく）ｓＨＳＰＰを使用する。このことがこの方法の一般性を限定すると見なされるべきではない。
【０２３９】
ＵＲ生成のＨＳＰＰも、「通知ＨＳＰＰ」と呼ばれることができ、ＵＳ生成のＨＳＰＰも、「要求ＨＳＰＰ」と呼ばれることができる。
【０２４０】
ＨＳＰＰの経路が変更または切断されたとしても、ＨＳＰＰが自身にループバックしないことが重要である。このことは、ネットワークのコアに到るためのネクストステップが生成されるプロセスによって保証されるべきである。
【０２４１】
ノードは、アクティブＨＳＰＰ  Ｈ（ｂＡｃｔｉｖｅ＝ｔｒｕｅ）を、それにアクティブＨＳＰＰ  Ｈを送信したノードに決して送信すべきではない。ノードは、それに（構造体のｂＡｃｔｉｖｅがｔｒｕｅに設定された）ＨＳＰＰ  Ｈを保持するよう命じた直接接続ノードの数を記録する。この数が０まで低下した場合、ノードは、アクティブＨＳＰＰ  Ｈ（ｂＡｃｔｉｖｅ＝ｔｒｕｅ）を送信されたその直接接続ノードに、非アクティブＨＳＰＰ  Ｈ（ｂＡｃｔｉｖｅ＝ｆａｌｓｅ）を伝える。
【０２４２】
概略的レベルでは、ＨＳＰＰは、コアに到るための非ループ経路を見つけ、コアに到達すると、延びるのを停止する。このようになるのは、コアを形成する２つのノードが、コアに到るための最良ネクストステップとして互いを選択するためである。アクティブＨＳＰＰは、すでにそれにアクティブＨＳＰＰを送信したノードに送信されないので、ＨＳＰＰは、２つのノードのコアのうちの１つのノードだけによって送信される。
【０２４３】
ＨＳＰＰ経路が切断された場合、切断箇所からコアまでのＨＳＰＰは削除される。ＨＳＰＰが削除されるのは、それにアクティブＨＳＰＰを伝えた唯一のノードが削除されるからである。これは、切断箇所からコア側のノードを促して、それがアクティブＨＳＰＰ  Ｈを伝えたノードに対して非アクティブＨＳＰＰ  Ｈを伝えさせる。大部分の場合、このプロセスは、そのアクティブＨＳＰＰを削除しながら、コアに向って順々に進んでいく。
【０２４４】
ＨＳＰＰは、各ノードのコアに到るための最良ネクストステップを使用してコアに向って進む。
【０２４５】
ＵＲによって生成されるＨＳＰＰの目的は、ＵＲとコアの間の経路を常に保持し、その結果、システム内のすべてのノードが、ＵＳ生成のＨＳＰＰ（要求ＨＳＰＰ）をコアに送信することによって、ＵＲを見つけることができるようにすることである。
【０２４６】
ノードＮは、直接接続ノードのいずれかからアクティブＨＳＰＰ  Ｈを受信した場合、コアに到るための最良ネクストステップとして選択された１つ（または複数）のノードに、コアに到るための最良ネクストステップとして選択されたその１つ（または複数）のノードはノードＮにアクティブＨＳＰＰ  Ｈを送信していないと仮定して、アクティブＨＳＰＰ  Ｈを転送する。
【０２４７】
複数のアクティブＨＳＰＰ  Ｈが同じノードに到着した場合、そのノードは、到着ＨＳＰＰのいずれかがｔｒｕｅとして標識付けされたｂＵＲＧｅｎｅｒａｔｅｄを有するならば、ｔｒｕｅとして標識付けされたｂＵＲＧｅｎｅｒａｔｅｄをもつＨＳＰＰを転送する。
【０２４８】
コアに到るための最良ネクストステップとして選択された直接接続ノードがノードＡからノードＢに変わった場合、（「次のコアに到るための最良ステップ」がまだこのノードに同じ名前のアクティブＨＳＰＰを送信していないと仮定して）ノードＡに送信されたすべてのＨＳＰＰは、代わりにノードＢに送信される。ノードＡに送信されたそれらのＨＳＰＰは、ノードＡに送信される「ｂＡｃｔｉｖｅ」値がｆａｌｓｅに設定されたＨＳＰＰ更新を有し、ノードＢに送信されるＨＳＰＰは、「ｂＡｃｔｉｖｅ」値がｔｒｕｅに設定される。
【０２４９】
一代替実施形態は、ノードＡがＨＳＰＰを生成した場合、ノードＡがすべての直接接続ノードにＨＳＰＰを送信すべきとする。これは、このノードが素早く移動しているとしても、その知識が常にコアにまたはコアから送られることを保証する。
【０２５０】
ノードＡが別のノードＢへのコネクションを確立する場合、ノードＡは、（要求ＨＳＰＰと呼ばれる）ＨＳＰＰを使用して、ノードＢについての経路情報をそれ自身へとプルすることができる。このＨＳＰＰも、すべての直接接続ノードに送信されるべきである。
【０２５１】
一代替実施形態は、データを双方向に動かす１つのタイプのＨＳＰＰだけを有する。このタイプのＨＳＰＰは、プッシュ／通知ＨＳＰＰとプル／要求ＨＳＰＰの両方に取って代わることができる。この実施形態では、そのｂＵＲＧｅｎｅｒａｔｅｄパラメータは省略される。
【０２５２】
ＨＳＰＰは、継続的に再送信される必要はない。ＨＳＰＰが静的なネットワーク内に一度確立されると、追加のＨＳＰＰメッセージは送信される必要がない。このことは当業者には明らかであろう。
【０２５３】
各ノードは、それにどの直接接続ノードがどのＨＳＰＰについて伝えたかを記憶し、ノードは一般に、それがどのＨＳＰＰについて直接接続ノードに伝えたかも記憶する。
【０２５４】
代替ＨＳＰＰタイプ
この代替実施形態は、低帯域幅環境においてコネクションを維持するのを助けることができる。
【０２５５】
先の実施形態では、以下の２つのタイプのＨＳＰＰが存在した。
１．通知ＨＳＰＰ
２．要求ＨＳＰＰ
【０２５６】
この実施形態では、「優先通知ＨＳＰＰ」と呼ばれる新しいタイプのＨＳＰＰを導入する。
【０２５７】
「優先通知ＨＳＰＰ」は、それがすべての「通知ＨＳＰＰ」より先に送信される点を除いて、「通知ＨＳＰＰ」と同じである。このことは後ほど説明される。
【０２５８】
例えば、ノードが別のノードと通信しようと試みる場合、または別のノードがそれと通信しようと試みていることを知った場合、ノードは、その通知ＨＳＰＰを優先通知ＨＳＰＰに変更することができる。
【０２５９】
以下の表は、ノードが特定の宛先ノードに関して受信したＨＳＰＰのタイプが与えられた場合に、ノードがどのタイプのＨＳＰＰをコアに到るためのその最良ネクストステップに送信するかを説明している。
【表１６】
2007523546.tif 000018
【０２６０】
「優先通知ＨＳＰＰ」を含むエントリを無視するならば、上記の表はまた、その他の実施形態が、コアに到るための最良ネクストステップにどのＨＳＰＰタイプを送信すべきかについてどのように決定するかを説明している。
【０２６１】
ＨＳＰＰ構造体は、以下のように修正されることができる。
struct sHSPP [
// The name of the node could be replaced with a number
// (discussed previously)
sNodeName       nnName;
// a boolean to tell the node if the HSPP is being
// activated or removed,
bool                              bActive;
// the HSPP Type (for ex: Request HSPP, Notify HSPP,
// Priority Notify HSPP)
int                          nHSPPType;
];
【０２６２】
送信されるＨＳＰＰを順序付ける
一代替実施形態は、ＨＳＰＰが送信される順序を調整する。
【０２６３】
ノードは、ＨＳＰＰを受信すると、送信する前にそれを順序付ける必要がある。これは、より重要なＨＳＰＰが最初に送信されることを保証する。
【０２６４】
「優先通知ＨＳＰＰ」の実施形態が使用されない場合、ＨＳＰＰが送信されるべき順序は以下のようである。
１．要求ＨＳＰＰ
２．通知ＨＳＰＰ
【０２６５】
「優先通知ＨＳＰＰ」の実施形態が使用される場合、順序は以下のようである。
１．要求ＨＳＰＰおよび優先通知ＨＳＰＰ
２．通知ＨＳＰＰ
【０２６６】
単純ループを削除する
この代替実施形態は、単純ループが形成されるのを阻止するために使用されることができる。
【０２６７】
当業者であれば、「ポイズンリバース」の変形を認めるであろう。
【０２６８】
ノードＡは、ノードＮに向うメッセージのための「最良隣接ノード」としてノードＢを選択した場合、ノードＢにそれが選択されたことを伝える。
【０２６９】
例えば、ノードＡは、ノードＢに以下のようなメッセージを送信することができる。
struct sIsBestNeighbour[
Name          NodeName;
Boolean       bIsBestNeighbour;
]
【０２７０】
ノードＡがノードＢにそれがノードＮに向うメッセージのための「最良隣接ノード」であることを伝えた場合、ノードＢは、ノードＮに向うメッセージのための「最良隣接ノード」としてノードＡを選択することはできない。ノードＮに向うメッセージのためにノードＢが行える唯一の可能な選択がノードＡである場合、ノードＢは、「最良隣接ノード」を選択せず、ノードＮへのその累積リンクコストを無限大に設定する。
【０２７１】
データストリーム内としてノードを標識付ける
この代替実施形態は、データストリーム内にあるノードを標識付けるために使用されることができる。
【０２７２】
この実施形態では、ノードは、「データストリーム内」として標識付けられた場合だけ、「データストリーム内」と見なされる。ノードは、データストリーム内として標識付けられなくても、ペイロードパケットを転送することができる。ノードは、ペイロードパケットを転送しているが、データストリーム内として標識付けられていない場合、「データストリーム内」とは見なされない。
【０２７３】
ノードＡは、ネットワーク内の別のノードＮへのデータコネクションを確立しようと試みる場合、ノードＡがノードＮへのその「最良隣接ノード」として選択したノードＢに、ノードＢがノードＮのための「最良隣接ノード」であり、ノードＢがノードＮに向うデータストリーム内にあることを伝える。
【０２７４】
ノードＢは、それが「最良隣接ノード」であることをノードＢに伝えた直接接続ノードによって、ノードＢがデータストリーム内にあることを伝えられた場合、ノードＢがノードＮのための「最良隣接ノード」として選択した直接接続ノードＣに、ノードＣがデータストリーム内にあることを伝える。
【０２７５】
例えば、このメッセージの構造体は、以下のようにすることができる。
struct sInTheDataStream [
Name            NodeName;
Boolean         bIsInTheDataStream;
]
【０２７６】
ノードＢは、ノードＮに向うメッセージに関してデータストリーム内として標識付けられた場合、ノードＢがノードＮに到るための最良ネクストステップとして選択したノードに、それがデータストリーム内にあることを伝える。ノードＢがデータストリーム内としてもはや標識付けられなくなるのは、以下の理由からである。
１．ノードＢにそれがデータストリーム内にあることを伝えた１つ（または複数）の直接接続ノードが切断されたため。
２．ノードＢにそれがデータストリーム内にあることを伝えた１つ（または複数）の直接接続ノードがすべて、ノードＢにそれがもはやデータストリーム内にないことを伝えたため。
【０２７７】
その後、ノードＢは、その「最良隣接ノード」Ｃに、それがもはやデータストリーム内にないことを伝える。
【０２７８】
ノードは、このフラグによってだけ、データストリーム内にあるとして標識付けられる。ノードは、データストリーム内として標識付けられなくても、ペイロードパケットを転送することができる。
【０２７９】
ストリームに基づくリンクコスト
「ストリームに基づくリンクコスト」という用語は、本明細書では「フローに基づくホップコスト」と呼ばれることもある。
【０２８０】
この代替実施形態は、ネットワーク内でノード更新を順序付けるのに使用されることができる。この順序付けは、データフローを保持し収束させるための更新を他の更新より先に送信することによって、ネットワークがはるかに効率的になることを可能にする。
【０２８１】
ノード知識を受け渡すのに使用されるｓＮｏｄｅＫｎｏｗｌｅｄｇｅ構造体は、（例えば）以下のように修正されることができる。
struct sNodeKnowledge [
Name          NameOfTheNode;
Float         fCumulativeLinkCost;
Float         fCumulativeLinkCostFromStream;
]
【０２８２】
ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍは、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔと同じ方法でインクリメントされる。しかし、ノードは、特定のノードに向うデータストリーム内にある場合、その直接接続ノードに更新を送信する前に、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍを０にリセットする。
【０２８３】
ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔが０に初期化されたように、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍも０に初期化される。
【０２８４】
一代替実施形態は、ユーザデータメッセージがそのノードを通過するなど、その他の理由でも同様にｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍをリセットさせる。当業者であれば、そのような変形を理解されよう。
【０２８５】
低帯域幅環境で役立つ一代替実施形態は、ノードが別のノードとユーザデータを交換していない場合、ノードにｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍを非０値に設定させるものである。ノードは、別のノードと通信を行っている場合、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍを０に設定する。一代替実施形態はやはり、非０のｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍを、このノードが確立したリンクに関するリンクコストの最小、最大、平均（など）の倍数に設定する。
【０２８６】
ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔが無限大になった場合、最後の非無限大のｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ値を保持する。これは、無限大更新を直接接続ノードにいつ送信すべきかを命じるために使用される。
【０２８７】
ストリームに基づく代替リンクコスト
この実施形態は、ネットワークがノード知識を削除するのを助ける上でより役立つ点を除いて、先の実施形態と同様である。
【０２８８】
先の実施形態では、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍは、データストリーム内にあるとして標識付けられたノードに出会ったときに、０にリセットされた。この実施形態は、どのタイプの更新が送信されるかを変更する。
【０２８９】
宛先ノードＥを生成したノードＡ（これはノードＡによって使用されるノード名Ｅを生成したノードＡとしても説明され得る）は、それがノードＥに向うデータストリーム内にあることを、直接接続ノードＢによって伝えられた場合、その直接接続ノードＢに、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ＝ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔとするノードＥのためのノード更新を伝える。大部分の場合、この更新はこれらの値の両方を０に設定するが、それはノードＡが名前Ｅを生成したためである。
【０２９０】
ノードＡにそれがデータストリーム内にあることを告げなかったその他のすべてのノードは、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ！＝ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔを伝えられる。例えば、
fCumulativeLinkCostFromStream = fCumulativeLinkCost + 0.1f;
【０２９１】
ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔは、通常は０であるので、これらの直接接続ノードは、０．１のｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍと、０のｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔとを伝えられる。０．１は単なる代表例と見なされたい。
【０２９２】
宛先ノード名を生成したノードではないノード（この例ではノードＡ以外の任意のノード）が、「データストリーム内」として標識付けられ、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ＝ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔである場合、そのノードは、それを「データストリーム内」として標識付けなかったすべてのその直接接続ノードに、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ＝０とするノードＥのための更新を伝える。ノードは、それをデータストリーム内として標識付けたノードに対しては、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ＝ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔとするノードＥのための更新を伝える。
【０２９３】
この実施形態のどの時点でも、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔが、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍに合わせて調整されることはない。常にｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍが、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔに対して調整される。
【０２９４】
ノード更新の順序付け
大規模ネットワークでは、送信すべき大量のノード更新が存在し得る。この代替実施形態は、更新をそれらがどれほど重要かによって順序付けることを可能にする。
【０２９５】
この代替実施形態は、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍが使用されること、およびＨＳＰＰが使用されることを仮定する。それらの一方だけが使用される場合、使用されない実施形態が提供する順序付けは無視されたい。
【０２９６】
システム内のすべてのノードは、選択された「最良隣接ノード」によってそれに送信されたｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ値によって順序付けられる（コネクションのリンクコストが直接接続ノードによって送信された値に追加される）。この順序付けリストは、（Ｊａｖａの例では）ＴｒｅｅＭａｐの形をとることができる。
【０２９７】
先の実施形態が使用される場合、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔ＝ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍであり、かつノードがデータストリーム内として標識付けられているとき、それは、０のｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍを有するかのように、ＴｒｅｅＭａｐに追加されるべきである。
【０２９８】
宛先ノード経路に対する更新が直接接続ノードに送信される必要がある場合、この宛先ノードは、直接接続ノードごとに保持されているＴｒｅｅＭａｐ内に配置される。ＴｒｅｅＭａｐは、項目を昇順キー順にそこから削除することを可能にするデータ構造である。これは、より重要な更新が、あまり重要でない更新より先に、直接接続ノードに送信されることを可能にする。
【０２９９】
このＴｒｅｅＭａｐ内に配置された宛先ノードは、以下の場合を除いて、それらのｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ値によって順序付けられる。
１．このノードが、この宛先ノードのためのＨＳＰＰの経路内にあり、この直接接続ノードが、
ａ．コアへの経路内にあり、ＨＳＰＰは通知ＨＳＰＰであるか、またはただ１つのタイプのＨＳＰＰしかない場合、
ｂ．このＨＳＰＰについて我々に伝えたノードの１つであり、ＨＳＰＰは要求ＨＳＰＰであるか、またはただ１つのタイプのＨＳＰＰしかない場合。
２．このノードが、この宛先ノードに向うデータストリーム内にある場合
(bIsInTheDataStream = true and fCumulativeLinkCost =
fCumulativeLinkCostFromStream)
【０３００】
宛先ノードがこれら２つのグループの一方に属する場合、その項目は、直接接続ノードごとに保持される順序付けられた更新リストの先頭に配置される。このプロセスの擬似コードの代表例は、以下のようである。
float fTempCumLinkCostFStream = GetCumLinkCostFStream (NodeToUpdate);
if (NodeToUpdate for this connection belongs to group l or 2)
fTempCumLinkCostFStream = 0;
while (CurrrentConnection.OrderedUpdateTreeMap contains
fTempCumLinkCostFStream as a key)
[
Incrementf FempCumLinkCostFStream by a small amount
]
Add pair (fTempCumLinkCostFStream, NodeToUpdate) to
CurrrentConnection.OrderedUpdateTreeMap;
【０３０１】
その後、宛先ノード経路更新が、この順序で送信される。宛先更新が処理されると、宛先ノードは、この順序付けられたリスト（ＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎ．ＯｒｄｅｒｅｄＵｐｄａｔｅＴｒｅｅＭａｐ）から削除される。この順序付けは、より重要な更新があまり重要でない更新より先に送信されることを保証する。
【０３０２】
ｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍも、どの宛先ノード更新が送信されるべきかを決定するために、コネクションごとに使用されるべきである。例えば、以下のようなｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍ値を有する５つの宛先ノードが存在するとする。
１．２０２    −宛先ノードＤ
１．３４１    −宛先ノードＦ
３．９８１    −宛先ノードＧ
８．１９２    −宛先ノードＢ
９．０８４    −宛先ノードＭ
【０３０３】
直接接続ノードは、それに送信される宛先ノードを最大４つ要求する。このノードは、このリストの最初の４つだけを送信する（ノードは、宛先ノードＭのための更新を送信しない）。
【０３０４】
宛先ノードＧがそのｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍを３．９８１から１２．２３１に変更した場合、新しいリストは、以下のようになる。
１．２０２    −宛先ノードＤ
１．３４１    −宛先ノードＦ
８．１９２    −宛先ノードＢ
９．０８４    −宛先ノードＭ
１２．２３１  −宛先ノードＧ
【０３０５】
この更新に応答して、このノードは、宛先ノードＧと宛先ノードＭの両方の更新をスケジュールする。（ＨＳＰＰまたはデータストリームを仮定しない）ＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎ．ＯｒｄｅｒｅｄＵｐｄａｔｅＴｒｅｅＭａｐ内の順序付けられたペアは、以下のようである。
位置１  −（９．０８４，Ｍ）
位置２  −（１２．２３１，Ｇ）
【０３０６】
このノードは、その後、ノードＧのための無限大更新を送信する。このノードは、その後、ノードＭのための遅延送信をスケジュールする（「遅延送信」を参照）。
【０３０７】
無限大宛先ノード更新は、この情報を渡すのに必要とされるメッセージが、無限大更新を獲得するノードのために送信されることを確実にする。この例は、いくつかの異なる実施形態を含み、使用されないものについては、当業者は関連項目を省略することができる。
a. fCumulativeLinkCost              = INFINITY
b. fCumulativeLinkCostFromStream    = INFINITY
c. bIsBestNeighbour                 = FALSE
d. bIsInDataStream                  = FALSE
【０３０８】
宛先ノードＭのための更新が送信されると、それは非無限大になる。
【０３０９】
遅延送信
この代替実施形態は、ノードがネットワークから削除された場合に、ノード知識がネットワークから削除されることを助ける。
【０３１０】
ノード知識がネットワークから削除されないと、適切な階層およびコアがトラブルに見舞われる。
【０３１１】
これが宛先ノード更新が直接接続ノードに送信される最初である場合、またはこの直接接続ノードに送信された最後の更新が無限大のｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔを有する場合、更新は遅延させられるべきである。
【０３１２】
例えば、コネクションが１０ｍｓの待ち時間を有する場合、更新は、（待ち時間＋１）×２ｍｓ、またはこの例では２２ｍｓだけ遅延させられるべきである。この待ち時間は、制御パケット更新の間の遅延の倍数も超えるべきである（「伝播特性」を参照）。
【０３１３】
当業者であれば、各自の応用例にとって良好な遅延値を実験して見出すことができよう。
【０３１４】
以下のいずれかの条件が満たされる場合は、例外である。
１．このノードが、この宛先ノードのためのＨＳＰＰの経路内にあり、この直接接続ノードが、
ａ．コアへの経路内にあり、ＨＳＰＰは通知ＨＳＰＰであるか、またはただ１つのタイプのＨＳＰＰしかない場合、
ｂ．このＨＳＰＰについて我々に伝えたノードの１つであり、ＨＳＰＰは要求ＨＳＰＰであるか、またはただ１つのタイプのＨＳＰＰしかない場合。
２．このノードが、この宛先ノードに向うデータストリーム内にある場合。
(bIsInTheDataStream = true and fCumulativeLinkCost =
fCumulativeLinkCostFromStream)
【０３１５】
（ＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎ．ＯｒｄｅｒｅｄＵｐｄａｔｅＴｒｅｅＭａｐ内に配置されることによって）無限大更新が送信されるようスケジュールはされたが、（遅延させられているため）非無限大更新が送信されるようスケジュールされるまで送信されない場合、無限大が最初に送信されなければならず、その後、非無限大更新は、送信される前に再び遅延させられるべきである。
【０３１６】
宛先ノードを無限大から非無限大に循環させる
この代替実施形態は、ノードがネットワークから削除された場合に、ノード知識がネットワークから削除されることを助ける。
【０３１７】
ノードＡについての以下の基準のいずれかが満たされる場合、更新が直接接続ノードＮに送信される。
１．ノードに送信され得るノード更新の数を制限する代替実施形態が使用され、
直接接続ノードＮが、この宛先ノードＡのための非無限大更新を送信するが、ノードＡの新しいｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍ値（上を参照）が、Ｘ個（Ｘは直接接続ノードＮが伝えられることを要求したノードの最大数）の他のノードのｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍ値より大きいという基準。
２．ノードＡのｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍが、この直接接続ノードＮに送信されたどの他のノードのｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍより大きくなるという基準。
【０３１８】
このノードは、この宛先ノードＡのための無限大更新を、直接接続ノードＮに送信する。その後、適切な遅延（遅延送信を参照）の後、このノードは、このノードＡが依然として基準１を満たしている場合を除いて、この宛先ノードのための非無限大更新を、直接接続ノードに送信する。
【０３１９】
これは、不良経路データをネットワークから削除し、自動的にループを削除することを助けるのに使用される手法の一部である。
【０３２０】
無限大更新は、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔ値が無限大に設定される更新である（より完全な定義については上を参照）。
【０３２１】
宛先ノードが先の基準を満たすときに、無限大更新を（しばらく後に同じ宛先ノードのための非無限大更新を）送信するよう決定するのが、推奨される手法である。遅延非無限大更新がその後に続く、無限大更新をトリガする代替手法は、
１．ｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍが、一定の期間のうちに、ある比率または量だけ増加したとき、例えば、ｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍが、５秒以内にコネクションコストの１０倍より多く増加した場合に行うもの、
２．順序付けされたリスト内でこの宛先ノードの位置が、Ｘ秒のうちに、リスト内で（例えば）位置１００個分より多く移動するか、または（例えば）１０％より大きく移動したときに行うものである（ただし、これらに限定されない）。
【０３２２】
当業者であれば、無限大／非無限大送信をトリガするための、ｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍの適切な増加と、適切なタイミング値とを決定することができよう。
【０３２３】
一代替実施形態は、ｆＴｅｍｐＣｕｍＬｉｎｋＣｏｓｔＦＳｔｒｅａｍの代わりに、ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍを使用することができる。
【０３２４】
これまで未知だった宛先ノードがリストの先頭に出現した場合、直接接続ノードは以前に非無限大更新を伝えられていないので、無限大は送信される必要がない。しかし、直接接続ノードにこの宛先ノードについて伝えることは、遅延させられるべきである。
【０３２５】
この遅延送信は、以下の条件のいずれかが満たされる場合は、行う必要がない。
１．このノードが、この宛先ノードのためのＨＳＰＰの経路内にあり、この直接接続ノードが、
ｃ．コアへの経路内にあり、ＨＳＰＰは通知ＨＳＰＰであるか、またはただ１つのタイプのＨＳＰＰしかない場合、
ｄ．このＨＳＰＰについて我々に伝えたノードの１つであり、ＨＳＰＰは要求ＨＳＰＰであるか、またはただ１つのタイプのＨＳＰＰしかない場合。
２．このノードが、この宛先ノードに向うデータストリーム内にある場合。
(bIsInTheDataStream = true and fCumulativeLinkCost =
fCumulativeLinkCostFromStream)
【０３２６】
エンドユーザソフトウェア
このネットワークシステムおよび方法は、大部分のその他のネットワークプロトコルをエミュレートするために、またはまったく新しいネットワークプロトコルの基礎として、使用されることができる。
【０３２７】
それは、その他のプロトコルの「ルーティング中枢部」の代替として働くこともできる。
【０３２８】
本明細書では、エミュレートされ得るプロトコルの一例として、ＴＣＰ／ＩＰが使用される。一例としてのＴＣＰ／ＩＰの使用には、本発明の応用例をＴＣＰ／ＩＰに限定する意図はない。
【０３２９】
ＴＣＰ／ＩＰでは、ノードは、起動されたとき、その存在をネットワークに知らせない。知らせる必要がないのは、ノードの名前（ＩＰアドレス）が、ノードのロケーションを決定するからである。本発明では、ノードは、その存在をネットワークに知られることを必要とし、自身への保証された経路をネットワークに提供する必要がある。このことは、別の場所ではるかに詳しく説明される。
【０３３０】
エンドユーザソフトウェア（「ＥＵＳ」）は、コネクションを確立することを望む場合、ＴＣＰ／ＩＰと非常に類似した方法でそれを行うことができる。ＴＣＰ／ＩＰでは、接続コードは、以下のものと類似している。
SOCKET sNewSocket = Connect(IP Address, port);
【０３３１】
本発明では、「ＩＰアドレス」は、グローバル一意識別子（「ＧＵＩＤ」）で置き換えられる。
SOCKET sNewSocket = Connect(GUID,port).
【０３３２】
実際、ＩＰアドレスが一意であることが保証され得るならば、ＩＰアドレスは、ＧＵＩＤとして機能して、この新しいネットワーク発明による既存のＴＣＰ／ＩＰネットワークスタックのシームレスな置き換えを提供することができる。
【０３３３】
一意ＩＰアドレスを保証する１つの方法は、各ノードにランダムＧＵＩＤを生成させ、その後、それを使用させて、ＧＵＩＤとして使用され得る一意ＩＰアドレスを要求するための通信をＤＨＣＰ（動的ホスト構成プロトコル）ライクなサーバと行わせることである。ノードは、その後、最初のＧＵＩＤ名を廃棄し、このＩＰアドレスだけをＧＵＩＤとして使用する。この文脈でＩＰアドレスを使用することは、ＩＰアドレスが必ずしもネットワーク階層におけるノード位置を反映する必要がないことを意味する。
【０３３４】
宛先ノードへのコネクションが一度要求されると、ネットワークは、（そのような経路が存在すれば）宛先への経路を決定し、最適経路が見出されるまで、継続的に経路を改善する。
【０３３５】
受信側は、接続ノードのＩＰアドレスを決定するための要求が、代わりにＧＵＩＤを生成する点を除いて（またはＩＰアドレスが、ＧＵＩＤとして使用されるアドレスである点を除いて）、ＴＣＰ／ＩＰと同じようである。
【０３３６】
この手法は、ネットワークを介するルーティングを提供し、当業者であれば、異なるフロー制御手法が異なるネットワークにおいてどのようにより良く機能し得るかを理解することができよう。例えば、無線ネットワークは、着信データ速度が発信コネクション速度を超えたときにパケットを喪失しない手法を必要とすることがある。
【０３３７】
図２８は、このルーティング方法がＴＣＰ／ＩＰ実施例に適合された一例である。
【０３３８】
この新しいルーティング手法がエンドユーザアプリケーション用のＴＣＰ／ＩＰライクなインターフェースを可能にすることを、当業者であれば理解されよう。これは、このルーティング手法をどれか特定のインターフェース（例えばＴＣＰ／ＩＰ）またはアプリケーションに限定することを意図していない一例である。
【０３３９】
ネットワークを介して２つのノードを接続する
以下に示すのは、このネットワーク内の２つのノードを接続するのに使用され得る１つの手法の一例である。この例は（本明細書内のすべての例と同様に）、本特許の範囲を限定することを意図していない。当業者であれば、多くの変形を知っていよう。
【０３４０】
ＨＳＰＰを使用する代替実施形態が使用されない場合、ＨＳＰＰについての部分を無視されたい。
【０３４１】
ノードＡは、ノードＢとのコネクションを確立することを望む場合、最初にすべての直接接続ノードに（先に説明された）要求ＨＳＰＰを送出する。この要求ＨＳＰＰは、ノードＢについての経路情報をノードＡに取り込み、保持する。この要求ＨＳＰＰは、ノードＡがノードＢについての知識をすでに有していても、送出される。
【０３４２】
「優先通知ＨＳＰＰ」を使用する代替実施形態が使用される場合、ノードＡは、その通知ＨＳＰＰを優先通知ＨＳＰＰに変更することができ、すべての直接接続ノードに通知することができる。これは、低帯域幅の移動環境における接続性を助けることができるが、それは、通信中のノードが、通信中でないノードより先に、その情報を広めることを可能にするからである。
【０３４３】
このＨＳＰＰは、コアに到達する前にノード経路知識に遭遇したとしても、コアまで進む。
【０３４４】
ノードＡは、ノードＢに到るための非無限大の最良ネクストステップを一度有すると、ノードＢの特定ポートに向けて「接続要求メッセージ」を送出する。このリクエストは、ノードＢに向うメッセージにとっての「最良隣接ノード」として選択された直接接続ノードに送信される。
【０３４５】
「データストリームを標識付ける」実施形態が使用される場合、ノードＡは、「最良隣接ノード」として選択されたその直接接続ノードに、それがノードＢに向うデータストリーム内にあることを伝える。
【０３４６】
ポートの使用は単なる例であって、本発明の範囲を限定することを意図していない。可能な代替は、特に着信コネクションのための新しいノード名とすることができる。当業者であれば、変形を知っていよう。
【０３４７】
ノードＡは、ｓＣｏｎｎｅｃｔｉｏｎＡｃｃｅｐｔメッセージが受信されるか、または受信されずにタイムアウトが発生するまで（例えば１２０秒）、このメッセージをＸ秒（例えば１５秒）おきに送信し続ける。接続要求メッセージは、ノードＡのＧＵＩＤと、接続応答メッセージを送信すべきポートを含むことができる。接続要求メッセージは、ノードＢがノードＡからの重複リクエストを検出して無視できるようにするために使用されるｎＵｎｉｑｕｅＲｅｑｕｅｓｔＩＤも含むことができる。
【０３４８】
接続要求メッセージは、（例えば）以下のようになる。
struct sConnectionRequest [
// the name of node A, could be replaced with a number
// for reduced overhead.
sNodeName                     nnNameA;
// Which port on node A to reply to
int                           nSystemDataPort;
// Which port to send end user messages to on node A
int                           nUserDataPort;
// a unique request id that node B can use to
// decide which duplicate requests to ignore
int                           nUniqueRequestID;
]
【０３４９】
ノードＢは、ノードＡから「接続要求」メッセージを受信すると、ノードＡのための要求ＨＳＰＰを生成し、それをすべての直接接続ノードに送信する。これは、ノードＡについての経路情報をノードＢに取り込み、保持する。
【０３５０】
「優先通知ＨＳＰＰ」を使用する代替実施形態が使用される場合、ノードＢは、その通知ＨＳＰＰを優先通知ＨＳＰＰに変更することができ、すべての直接接続ノードに通知することができる。これは、低帯域幅の移動環境における接続性を助けることができる。
【０３５１】
「データストリーム内」の代替実施形態が使用される場合、ノードＢは、ノードＡに到るためのその最良ネクストステップがどこであるかが分かるまで待ち、その後、ノードＡへの経路を「データストリーム内」として標識付ける。
【０３５２】
ノードＢは、その後、ノードＡの指定ポート（ｓＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ．ｎＳｙｓｔｅｍＤａｔａＰｏｒｔ）にｓＣｏｎｎｅｃｔｉｏｎＡｃｃｅｐｔメッセージを送信する。このメッセージは、以下のようである。
struct sConnectionAccept [
// the name of node B
sNodeName nnNameB;
// the port for user data on node B
int                              nUserDataPortB;
// the unique request ID provided by A in the
// sConnectionRequest message
int                              nUniqueRequestID;
]
【０３５３】
ｓＣｏｎｎｅｃｔｉｏｎＡｃｃｅｐｔメッセージは、ノードＡがｓＣｏｎｎｅｃｔｉｏｎＣｏｎｆｉｒｍｅｄメッセージを送信し、それがノードＢによって受信されるか、またはタイムアウトが発生するまで、送信される。
【０３５４】
ｓＣｏｎｎｅｃｔｉｏｎＣｏｎｆｉｒｍｅｄメッセージは、以下のようである。
struct sConnectionConfirmed [
// the name of node A, could be replaced with a number
// for reduced overhead.
sNodeNarne                    nnNameA;
// the unique request ID provided by A in the
// sConnectionRequest message
int                           nUniqueRequestID;
]
【０３５５】
処理中にタイムアウトが発生した場合、接続は失敗したと見なされ、廃棄される。両方のノードが生成した要求ＨＳＰＰは削除され、「データストリーム内」フラグは（追加されていたならば）削除される。
【０３５６】
コネクションが一度確立されると、両方のノードは、ユーザデータメッセージを互いのそれぞれのポートに送信することができる。これらのメッセージは、その後、（ＴＣＰ／ＩＰの場合）ソケットを介してエンドユーザソフトウェアに転送される。
【０３５７】
一代替実施形態は、コネクションが確立されることを必要とせず、宛先ノードへの経路が発見されたら、ＥＵＳメッセージ／ペイロードをただ送信する。
【０３５８】
ノード名最適化およびメッセージ
この代替実施形態は、メッセージおよび名前の受け渡しを最適化するために使用されることができる。
【０３５９】
あらゆるノード更新およびＥＵＳメッセージ／ペイロードパケットは、それらが参照する宛先ノードを識別する方法を有する必要がある。ノード名およびＧＵＩＤは、簡単に長くなる傾向にあり、あらゆるメッセージおよびノード更新と一緒に送信するのは非効率的である。ノードは、長い名前を表す番号を使用することによって、これらの送信をより効率的にすることができる。
【０３６０】
例えば、ノードＡは、「ＴＨＩＳＩＳＡＬＯＮＧＮＯＤＥＮＡＭＥ．ＧＵＩＤ」という名前の宛先ノードについてノードＢに伝えたいと望む場合、最初に、
1 = 'THISISALONGNODENAME.GUID'
とノードＢに伝えることができる。
【０３６１】
このための構造体は、（例えば）以下のようにすることができる。
struct sCreateQNameMapping [
// size of the name for the node
int                             nNameSize;
// name of the node
char                            cNodeName[Size];
// the number that will represent this node name
int                             nMappedNumber;
];
【０３６２】
その後、ノードＡは、宛先ノード更新またはメッセージを送信したいと望むたびに、長いノード名を送信する代わりに、そのノード名を表す番号（ｓＣｒｅａｔｅＱＮａｍｅＭａｐｐｉｎｇ．ｎＭａｐｐｅｄＮｕｍｂｅｒ）を送信することができる。ノードＡは、「ＴＨＩＳＩＳＡＬＯＮＧＮＯＤＥＮＡＭＥ．ＧＵＩＤ」と呼ばれる宛先ノードについてノードＢに伝えたいと望むことはもはやないと決定を下した場合、そのマッピングについての記憶を消すようにノードＢに命じることができる。
【０３６３】
その構造体は、以下のようである。
struct sRemoveQNameMapping [
int                        nMappedNumber;
];
【０３６４】
各ノードは、どの名前がどの数にマッピングされるかについて、それ独自の内部マッピングを保持する。各ノードは、直接接続ノードからの名前を、それ独自の命名体系に変換することができるように、変換表を保持する。例えば、ノードＡは、
1 = 'THISISALONGNODENAME.GUID'
を使用することができ、ノードＢは、
632 = 'THISISALONGNODENAME.GUID'
を使用する。
【０３６５】
したがって、ノードＢは、ノードＡの番号付与体系を、ノードＢにとって理解できる番号付与体系に変換することを可能にするマッピングを有する。この例では、以下のようになる。
ノードＡ      ノードＢ
１            ６３２
．．．        ．．．
．．．        ．．．
【０３６６】
この番号付与体系の使用はまた、メッセージがどの宛先ノードに宛られたものかに関してメッセージに容易にタグを付けることを可能にする。例えば、システムは、１００バイトのメッセージを有するとき、メッセージが送信される宛先ノード名を格納するための４バイトを先頭に確保し、その後にメッセージが続くようにする。こうすると、全体メッセージサイズは１０４バイトになる。この構造体の一例は、メッセージのサイズも含む。
struct sMessage [
// the number that maps to the name of the node where
// this message is being sent to
int                             uiNodeID;
// the size of the payload packet
int                             uiMsgSize;
// the actual payload packet
char                            cMsg[uiMsgSize];
]
【０３６７】
このメッセージがノードによって受信されると、そのノードは、その変換表を参照し、宛先マッピング番号をそれ独自のマッピング番号に変換する。ノードは、その後、このマッピング番号を使用して、このノードがペイロードパケットの宛先であるかどうか、またはこのペイロードパケットを別の直接接続ノードに送信する必要があるかどうかを決定することができる。
【０３６８】
これらのクイック宛先番号は、当業者によってＴＣＰ／ＩＰヘッダに配置されることができる。
【０３６９】
名前マッピングをいつ削除すべきか
この代替実施形態は、もはや必要ではない名前マッピングを削除するのを助けるために使用される。
【０３７０】
宛先ノードが無限大のｆＣｕｒｎｕｌａｔｉｖｅＬｉｎｋＣｏｓｔをＸｍｓ（例えば５０００ｍｓ）より長く継続的にもち続け、この更新をすべての直接接続ノードに送信した場合、このノードは、この宛先ノードについての知識を削除する。
【０３７１】
最初、このノードは、この宛先ノードに関連するすべてのメモリを解放し、直接接続ノードによってそれに提供された更新を解除する。このノードは、その宛先ノードに送信するのを待っているメッセージも削除する。
【０３７２】
次に、このノードは、この宛先ノードについての番号−＞名前マッピングを記憶から消すよう、その直接接続ノードに命じる。
【０３７３】
すべての直接接続ノードが、このノードもこの宛先ノードについてのそれらの番号−＞名前マッピングを記憶から消すことができることをこのノードに伝えた場合、このノードは、それ独自の番号−＞名前マッピングを削除することができる。
【０３７４】
この段階で、この宛先ノードに関連するメモリはもはや存在しない。
【０３７５】
ノードは、新しい番号を使用する前に、記憶から消された内部ノード番号を再利用するよう試みるべきである。
【０３７６】
より簡単な高速ルーティング
この代替実施形態は、パケットのルーティングを高速化するために使用される。
【０３７７】
最適化として、どの直接接続ノードがメッセージを受信するかを示す別の列を名前マッピング表に追加する。
【０３７８】
したがって、ノードＢは、ノードＡの番号付与体系を、ノードＢにとって理解できる番号付与体系に変換することを可能にするマッピングを有する。この例では、以下のようになる。
ノードＡ      ノードＢ      メッセージが送信される直接接続ノード
１            ６３２        ７
．．．        ．．．
．．．        ．．．
【０３７９】
これは、ルーティングプロセス全体が、１つの配列検索となることを可能にする。ノードＡが宛先ノード１を有するメッセージをノードＢに送信する場合、ルーティングプロセスは、以下のようになる。
１．ノードＢが問題のマッピングへのポインタを生成する。
sMapping *pMap = &NodeMapping[pMessage->uiNodelD];
２．ノードＢが名前を変換する。
pMessage->uiNodeID = pMap->uiNodeBName;
３．その後、メッセージを指定された直接接続ノードに転送する。
RouteMessage(pMessage,pMap->uiDirectlyConnectedNodeID);
【０３８０】
この方式が正しく機能するには、ノードは、それがメッセージを転送するどの直接接続ノードを変更するかを決めた場合、すべての直接接続ノードについてのこれらのルーティング表を更新する必要がある。
【０３８１】
直接接続ノードが内部コード番号を再利用し、これらのノードが知っている宛先ノードの数が、これらのノード番号を保存するために利用可能なメモリ量より少ない場合、ノードは、メッセージを送信するために配列検索を使用することができる。
【０３８２】
これは、Ｏ（１）メッセージルーティングをノードに提供する（上記を参照）。直接接続ノードによって提供されるノード番号が、検索配列のために利用可能なメモリのサイズを超えた場合（しかし、全ノード数は依然としてメモリに適合する場合）、ノードは、配列検索の使用からハッシュマップ検索の使用に移行することができる。
【０３８３】
より複雑な高速ルーティング
この代替実施形態は、Ｏ（１）ルーティングが使用され得るよう保証することを助け、ハッシュマップの使用を回避する。
【０３８４】
ノードが常に高速Ｏ（１）配列検索ルーティングを実行できるよう保証するため、ノードは、各直接接続ノードに一意のノード番号−名前マッピングを提供することができる。これは、直接接続ノードが、メッセージルーティングを実行するためにハッシュテーブルの使用に頼る必要がないよう保証する（上記を参照）。
【０３８５】
直接接続ノードのためのこれらの一意の番号−名前マッピングを生成するとき、このノードは、すべての可能な番号を確実に再利用するようにする。
【０３８６】
これらの番号を再利用することによって、マッピングで使用される最高数が、その直接接続ノードによって要求される宛先ノード更新の最大数を決して大きく超えないよう保証する。
【０３８７】
コネクションごとに、ノードは整数配列を生成する必要があり、そのオフセットは、ノード自体の内部ノードＩＤに対応し、そのオフセットに保存される番号は、その直接接続ノードのために使用される一意の番号−＞名前マッピングである。
【０３８８】
高速ルーティングは、その場合、以下のようになる（上記を参照）。
１．ノードＢが問題のマッピングへのポインタを生成する。
sMapping *pMap = &NodeMapping[pMessage->uiNodeID];
２．ノードＢが名前を変換する。
pMessage->uiNodeID = pMap->uiNodeBName;
３．その後、メッセージを指定された直接接続ノードに転送する。
RouteMessage(pMessage,pMap->uiDirectlyConnectedNodeID;
４．送信の前に、名前が最後にもう一度変更される。
pMessage->uiNodeID = UniqueNameMapping[uiConnectionID][pMessage-
>uiNodeID];
【０３８９】
ＵｎｉｑｕｅＮａｍｅＭａｐｐｉｎｇは２次元配列であり、第１のパラメータは、コネクションＩＤであり、第２のパラメータは、そのコネクションＩＤを有するコネクションのための、一意の番号−名前マッピングで使用される番号である。
【０３９０】
各直接接続ノードのための番号−名前マッピングで使用される番号を再利用するには、使用されるマッピングの最大番号と同じサイズの配列を必要とする。配列はスタックとして扱われ、再利用される番号がこのスタックに配置される。スタックへのオフセットは、再利用される次の番号をどこに配置するか、再利用される番号をどこから取り出すかをこのノードに教える。
【０３９１】
直接接続ノードが、このノードによって知られている宛先ノードの総数より大きい宛先ノードの最大番号を要求した場合、一意マッピング方式は、その直接接続ノードに対しては必要とされない。
【０３９２】
この状況が変化した場合、マッピングは当業者によって容易に生成されることができる。
【０３９３】
ユーザデータパケットをいつ送信するか
ユーザデータパケットは、利用可能な経路が存在するときならいつでも、送信されることができる。代替実施形態は、あるクラスのノードが最初に送信されるユーザデータパケットを有する、ＱＯＳを可能にすることができる。当業者であれば、変形を知っていよう。
【０３９４】
即座に利用可能な経路が存在しない場合、ペイロードパケットは、有効な経路が出現するのを期待して、しばらくの間、保持されることができる。
【０３９５】
活動時間（ＴＴＬ）方式も、当業者によって実施されることができる。（ＴＣＰ／ＩＰなどのプロトコルのように）ホップを使用する代わりに、ＴＴＬは、ペイロードパケットを生成したノードによって計算される宛先ノードのためのｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔ値の倍数とすることができる。各ノードは、その後、パケットが受信されたリンクのリンクコストをＴＴＬから減算する。ＴＴＬが０を下回った場合、パケットは削除されることができる。当業者であれば、（ＴＣＰ／ＩＰでのように）ホップ数を使用する代わりにリンクコストを使用した標準的なＴＴＬ方式として、これを認識するであろう。
【０３９６】
より重要なノードがより遠くに広まることを可能にする
この代替実施形態は、いくつかのノードがネットワーク中でより遠くかつ／またはより速く広まることを可能にする。
【０３９７】
この実施形態が良好に機能するためには、ネットワーク内の（すべてではないにしても）大部分のノードが、同じ規則に従うことを必要とする。
【０３９８】
より重要として標識付けされたクラスのノードに対しては、リンクコストの一部だけが、それらのｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔおよび／または  ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍ値に加算される。例えば、ノードＤがより重要なノードのクラスに属し、リンクＮの通常のリンクコストが１０である場合、ノードＤのための更新については、（例えば）５またはリンクコストの半分だけが、そのｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔおよび／または  ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔＦｒｏｍＳｔｒｅａｍに加算される。
【０３９９】
ノードがどれだけ重要かは、
１．（先に説明された）その規模
２．ノードの名前に基づいた恣意的な方式
３．ノード更新構造体に追加されるまたは存在する別の値または値の組合せ
に結び付けることができる。
【０４００】
輻輳またはエネルギー消耗ノード
この代替実施形態は、過度に輻輳したノードまたはバッテリ消耗状態で動作中のノードから、ネットワークトラフィックを引き離すことを助けることができる。
【０４０１】
ノードは、エネルギー消耗状態で動作している場合、または輻輳を経験している場合、そのリンクコストを引き上げることができる。これは、問題を経験しているこのノードからトラフィックを引き離すことを助ける。
【０４０２】
ノードがそのリンク値をゆっくり変化させ、変化の間待機することは役に立つ。これは、不安定なネットワーク振動を回避することを助ける。
【０４０３】
ノードが輻輳の緩和を経験した場合、またはそのバッテリ状態が改善した場合、ノードはそのリンクコストを通常値までゆっくり低下させるべきである。
【０４０４】
当業者であれば、振動問題について、またこれらの問題に対処する方式について知っていよう。
【０４０５】
名前を共有するノード
この代替実施形態は、ノードが名前を共有することを可能にする。
【０４０６】
（例えば）ウェブサーバの場合、単一サーバが提供するよりも多くの帯域幅および接続性を提供することが重要になり得る。
【０４０７】
２以上のノードが同じ名前を使用する場合、その名前を有するノードに接続しようと試みるノードは、（ｆＣｕｍｕｌａｔｉｖｅＬｉｎｋＣｏｓｔに基づいて）最も近いノードに接続する。
【０４０８】
リクエストがステートレスである場合（例えば、ウェブサイトのメインページを要求する場合）、どのノードにリクエストが転送されても、同じ結果が返されるので、ノードはリクエストを即座に送信することができる。
【０４０９】
ノードは、ステートフルなコネクションを要求する場合、最初にその名前を有する最も近いノードに接続する。その最も近いノードは、その後、状態を必要とするコネクションを確立するのに使用され得るその一意名を返す。
【０４１０】
例えば、先に説明されたｓＣｏｎｎｅｃｔｉｏｎＡｃｃｅｐｔ構造体では、返されるノードの名前（ｓＣｏｎｎｅｅｔｉｏｎＡｃｃｅｐｔ．ｎｎＮａｍｅＢ）は、ノードの一意名とすることができる。
【０４１１】
伝播優先順
より大規模なネットワークでは、制御メッセージのための帯域制限が使用される必要がある。
【０４１２】
「制御」帯域幅の総計は、すべてのデータのために利用可能な最大帯域幅の何パーセントかに制限されるべきである。
【０４１３】
例えば、最小サイズを４Ｋとし、各グループに対して最大帯域幅の５％を指定することができる。単純な１０ＭＢ／ｓのコネクションでは、これは、４Ｋの情報パケットを
＝４０９６／（１０ＭＢ／ｓ×０．０５）
＝０．０８１９ｓ
ごとに送信することを意味する。
【０４１４】
そのため、このコネクションでは、制御パケットを０．０８１９ｓおきに、または毎秒約１２回送信することができる。
【０４１５】
パーセンテージおよび送信されるブロックサイズは例であり、当業者によって各自のアプリケーション要件をより良く満たすように変更されることができる。
【０４１６】
帯域制限メッセージ
これらのメッセージは、制御メッセージが適合するブロックのサイズに適合するように、一緒に連結されるべきである。
【０４１７】
制御メッセージが宛先ノード名をそのクイック参照番号によって参照し、直接接続ノードがその番号を知らない場合、クイック参照（番号−＞名前マッピング）が、メッセージに先立って行われるべきである。
【０４１８】
経路更新に割り当てられる制御帯域幅の量とＨＳＰＰ更新に割り当てられる制御帯域幅の量との間には食い違いがあるべきである。例えば、制御帯域幅の７５％が経路更新に割り当てられることができ、残りの２５％がＨＳＰＰ更新に割り当てられることができる。当業者であれば、各自の実施により適するように、これらの数を変更することができよう。
【０４１９】
複数経路ネットワーク
本明細書のこのセクションは、エンドユーザデータのための複数経路が２つの通信ノード間に形成されることを可能にする一実施形態について説明する。この実施形態はまた、輻輳を回避するために経路を移動および交代することを可能にする。
【０４２０】
この実施形態は、ノードおよび待ち行列のアイデアを使用する。待ち行列は、（本文書の先のセクションで使用されたノード名のように）メッセージの宛先として使用される。本明細書のこのセクションにおける用語は、これまでのものとは少し異なっていることもあるが、当業者であれば、どの用語が同等であるか見分けることができよう。
【０４２１】
本文書のこのセクションで提供されるどのような定義または概念も、本文書の先行する部分における定義または概念の意味を無効化または変更すると見なされるべきではない。
【０４２２】
当業者であれば、可能な変形について知っていよう。
【０４２３】
このネットワークは、ネットワークの大域的知識を所有するどのようなエージェントにも依存しない。
【０４２４】
ネットワークの構成要素は、ノードおよび待ち行列である。
【０４２５】
このネットワークは、いくつかの原則に従う。
一般原則
１．ネットワークは単純な概念を使用する。
２．意思決定および知識は局所的に保たれ、大域的知識の必要性を回避する。
３．システムのサイズもしくはトポロジ、ノード容量、または構造柔軟性にどのような制限も存在しない。
【０４２６】
これらの原則は、ネットワークの設計を左右する。これらの原則の働きは、後で詳しく説明される。
個別原則
１．ノードは、選択された宛先としてそれが指定した直接接続ノードにだけメッセージを送信する。
２．ノードは、そのノード上の待ち行列内のデータの待ち時間が、選択された宛先の待ち時間からすべての選択された宛先の最小待ち時間を減算した時間より大きい場合、その選択された宛先にだけメッセージを送信する。
３．データストリーム内に現在ないノードは、唯一の選択された宛先を有する。データストリーム内にあるノードは、複数の選択された宛先を有する。
４．より良い選択された宛先を探す場合、データストリーム内にないノードは、受動的ループ検査を使用し、データストリーム内にあるノードは、能動的ループ検査を使用する。
５．コネクションは、ＴＣＰ／ＩＰ方式で確立され、保持される。
６．大規模ネットワーク内のノードは、ネットワークのコアにおいて知識を探す。
データフロー原則
１．データのストリームは、フローが容量を超えた場合を除いて、それ自身の経路の待ち時間を変化させてはならない。
【０４２７】
例は理解を明瞭にするために与えられていることを繰り返しておくべきであろう。これらの例は、数、他の業者のソフトウェア、またはその他の詳細について具体的な言及がなされる場合でも、本明細書で説明される方法およびシステムの一般性を限定することを意図していない。
【０４２８】
ノード
このネットワーク内の各ノードは、１つまたは複数の他のノードに直接接続される。ノードは、コンピュータ、ネットワークアダプタ、スイッチとすることができ、またはメモリおよびデータ処理能力を含む任意の装置とすることができる。各ノードは、それが直接接続されているノードを除いて、他のノードについての知識をもたない。２つのノード間のコネクションは、一緒に「結合」されたいくつかの異なるコネクションとすることができる。コネクションは、（ワイヤなど）物理的とすることができ、（ボックス、小型装置、液体などの）実際の物理的品目、コンピュータバス、無線、マイクロ波、光、量子相互作用などとすることができる。
【０４２９】
コネクションの形態に対するどのような限定も、発明者らによって暗示されていない。
【０４３０】
図２９では、ノードＡは、ノードＢおよびノードＣに直接接続されている。ノードＣは、ノードＡだけに接続されている。ノードＢは、４つのノードに直接接続されている。
【０４３１】
「選択された宛先」は、あらゆる直接接続ノードの部分集合である。「選択された宛先」だけが、メッセージのための可能な経路と常に見なされる（後で説明される）。
【０４３２】
「選択された宛先」は、「最良隣接ノード」と等価である。この用語がこのセクションで使用されるのは、「最良隣接ノード」は実際には１つしか存在できないが、「選択された宛先」は複数存在できるため、「最良隣接ノード」だといくぶん誤解を生じることがあるからである。
【０４３３】
待ち行列およびメッセージ
エンドユーザソフトウェア（ＥＵＳ）による通信は、待ち行列を使用して実行される。待ち行列は、高信頼通信を確立し保持するのに使用されるメッセージと同様に、ＥＵＳメッセージ／ペイロードの宛先としても使用される。待ち行列の存在を知っているあらゆるノードは、同一の名前を有する対応する待ち行列を有する。この対応する待ち行列は、元の待ち行列のコピーであるが、異なるマシン上の待ち行列の内容は異なる。
【０４３４】
メッセージは、同じ名前の待ち行列を使用して、ノード間で転送される。メッセージは、それが元の待ち行列に到達するまで、転送され続ける。元の待ち行列は、メッセージの受信者であるＥＵＳまたはシステムによって実際に生成された待ち行列である。
【０４３５】
元の待ち行列を生成しなかったノードは、どのノードが元の待ち行列を生成したか知らない。
【０４３６】
システム内で生成された各待ち行列は、ＥＵＳまたはシステム割り当ての待ち行列番号およびグローバル一意識別子（ＧＵＩＤ）を含む一意のラベルが与えられる。ＧＵＩＤは、同じ名前を用いて最初に生成された待ち行列は１つしか存在しないことを保証するので重要である。例えば、
形式：EUS QueueNumber.GUID
例：  123456.af9491de5271abde526371
【０４３７】
代替実施は、特定の待ち行列を識別するのに使用されるいくつかの番号を有することができる。例えば、
形式：EUSAppID.EUS QueueNumber.GUID
例：  889192.123456.af9491de5271abde526371
【０４３８】
各ノードは、複数の待ち行列をサポートすることができる。特定の待ち行列が特定のノードに関連付けられることを必要とする要件はない。ノードは、それに伝えられたすべての待ち行列を記憶することを求められない。
【０４３９】
ノードは、ある待ち行列について知っている場合、それに接続されているノードにその待ち行列について伝える（後で詳しく説明される）。待ち行列内のメッセージの最終宛先を知っている唯一のノードは、その待ち行列を最初に生成したその最終宛先ノードだけである。ノードは、それがメッセージを受け渡したノードが、そのメッセージの最終宛先であると仮定する。
【０４４０】
いかなる時点でも、ノードは、全域的ネットワークマップを構築しようと試みず、またはそれが直接接続されているノードを除けば、全体的なネットワークの知識をもとうと試みない。唯一の知識は、待ち行列が存在すること、その待ち行列を最初に生成したノードにメッセージが到達するのにどれだけの時間がかかるか、および元のノードからの待ち時間更新がこのノードに到達するのにかかる最大時間である。
【０４４１】
待ち時間
待ち時間は、ネットワーク内でデータのための最良経路を選択する際に中心的な役割を演じる。ノードＢがそれの待ち時間がＸ秒であることをノードＡに伝える場合、ノードＡがメッセージをノードＢに受け渡すとすると、そのメッセージが最終宛先に到達し、ＥＵＳによって待ち行列から取り出されるまでにＸ秒かかるということを伝えている。
【０４４２】
ノードＢによって計算されるこの待ち時間値は、以下のようになる。
Latency = MinOverTimePeriod([Bytes In Queue]) * [Bytes/Second Send Rate] +
[Lowest Latency of All Chosen Message Destinations] +
[Service time on this queue] + [Physical Network Latency]
【０４４３】
Ｍｉｎ  Ｏｖｅｒ  Ｔｉｍｅ  Ｐｅｒｉｏｄは、この待ち行列に関連する送信および受信ノードからの５つの送信または受信のうち最小のものを実行するのにかかる時間によって決定される期間である。それはまた、３０ｍｓの最小時間（または高速システムタイマの細分度の妥当な倍数）でもある。これは、後でより詳しく説明される。
【０４４４】
Ｂｙｔｅｓ／Ｓｅｃｏｎｄ  Ｓｅｎｄ  Ｒａｔｅは、このノード上の待ち行列から流れ出るデータの速度の最良推定値である。
【０４４５】
Ｌｏｗｅｓｔ  Ｌａｔｅｎｃｙ  ｏｆ  Ａｌｌ  Ｃｈｏｓｅｎ  Ｍｅｓｓａｇｅ  Ｄｅｓｔｉｎａｔｉｏｎｓ。この待ち行列についての知識を有するすべての直接接続ノードは、その待ち行列を最初に生成したノードに待ち時間を提供する。これは、この待ち行列のための選択された宛先であるすべてのノードのうちの最低待ち時間である。
【０４４６】
Ｓｅｒｖｉｃｅ  Ｔｉｍｅ  Ｏｎ  Ｔｈｉｓ  Ｑｕｅｕｅは、この特定の待ち行列に再び戻って来る前に、ノードが、この特定の待ち行列以外の他のすべての待ち行列からデータを送信しようと試みるのにかかる時間である。
【０４４７】
図３０は、サービス時間がどのように計算され得るかを示している。
【０４４８】
待ち行列上のサービス時間の計算
直接接続ノードごとに、そのノードを選択された宛先として有し、待ち行列内に送信すべきデータを有する、待ち行列の一覧が存在する。
【０４４９】
待ち行列に公平にサービスするため、システムは、ラウンドロビン方式で、これらの待ち行列を巡回して行き、それらから「選択された宛先」にメッセージを送信する。各「選択された宛先」は、それが独自に巡回するそれ自身の待ち行列の一覧を有する。
【０４５０】
サービス品質（ＱＯＳ）が実施される場合、処理の順序は、「より重要な」待ち行列をより頻繁に処理するように変更されることができる。
【０４５１】
いくつかのタイプのノードは、異なる解像度が利用可能なシステムタイマを有する。低解像度タイマは時間を読み取るのが何倍も速いので、より低解像度のタイマを使用して、ノードの性能を高めるのが道理にかなっている。
【０４５２】
トレードオフは、待ち行列上のサービス時間を決定するためのアルゴリズムが僅かにより複雑になることである。
【０４５３】
システムは、選択された宛先のために待ち行列の一覧を巡回して行きながら、特定の待ち行列からメッセージを送信することができた回数を、その待ち行列に関連するカウンタをインクリメントすることによって記録する。システムは、メッセージをこの待ち行列からその選択された宛先に関連するネットワークアダプタに受け渡すことができた場合にだけ、このカウンタをインクリメントする。システムは、適切な待ち行列トークンが存在し、それが待ち時間試験に合格した場合にだけ、その待ち行列からメッセージを受け渡す。これら両方の概念は、後で定義される。
【０４５４】
ノードはまた、すべての待ち行列からいくつのメッセージを送信できたかも記録する。
【０４５５】
システムは、低解像度タイマの少なくとも３または４ティックの間、このラウンドロビンプロセスを繰り返し続ける。一事例として取り上げられ、本出願の一般性を引き下げることのないＷｉｎｄｏｗｓ２０００の場合、これは約４５または６０ミリ秒である。この計算の精度を高めるには、ティックの回数が増やされるべきである。
【０４５６】
ある直接接続ノードについてこの期間が経過すると、システムは、以下の統計値を記録する。
１．この直接接続ノードに送信されたメッセージの総数
２．このプロセスにかかった秒数で計った総時間
【０４５７】
各待ち行列も、その期間中にその待ち行列からその特定の選択された宛先に送信されたメッセージの数を記録する。
【０４５８】
これらの統計値は繰り返し２回分のものが保存され、１回分は現在進行中のプロセスに関し、もう１回分は最後に完了したプロセスに関する。これは、ノードが、次のサービス時間値のための新しいデータを収集しながら、その待ち行列のためのサービス時間を計算することを可能にする。
【０４５９】
この特定の選択された宛先（ＣＤ：ｃｈｏｓｅｎ  ｄｅｓｔｉｎａｔｉｏｎ）を有するこの待ち行列のためのサービス時間を計算するため、以下の式が使用される。
Service Time = ([TotalMessagesSentToCD]-
[TotalMessagesSentFromQToCD]) /
[TotalMessagesSentToCD] * [TotalTimeInSecondsForIterations]
【０４６０】
複数の選択された宛先が存在する場合は、以下の式を使用して、サービス時間を取得する。
Service Time =1/(1/[CD1Time] + 1/[CD2Time] +...))
【０４６１】
この値は、それが待ち時間計算の一部として送信される場合にだけ計算される。これは、計算上のオーバヘッドを低減する。
【０４６２】
物理ネットワーク待ち時間
これは、以下のように定義される。
平均的なメッセージサイズに近いパケットを直接接続ノードに送信し、そのパケットがその直接接続ノードによって受信されるのに必要とされる時間。
【０４６３】
この値は、従来のＴＣＰ／ＩＰネットワークの「ｐｉｎｇ」の値に非常に類似している。
【０４６４】
この物理ネットワーク待ち時間は、直接接続ノードによって提供された待ち時間を使用して計算が実行されるたびに、直接接続ノードに提供される待ち時間に追加される。例えば、物理ネットワーク待ち時間は、以下の場合に使用される。
１．どれが最低待ち時間の選択された宛先であるかを決定するとき。
２．データストリーム内にない場合（後で説明される）に受動的にループを検出するとき。
３．追加の選択された宛先を選択するとき。
【０４６５】
この値は、一連の事前定義されたパケットを直接接続ノードに送信し、時間を計ることによって、初期化されることができる。
【０４６６】
システムの動作中、この値は、実際の実行に基づいて再計算される。
【０４６７】
ネットワークカードが継続的にデータを送信していると仮定して、システムがする必要があることは、送信されたデータの量、メッセージの平均サイズ、どれだけの時間が経過したかを記録することだけである。式は以下のようになる。
Physical Network Latency
=[AverageMsgSize]/([TotalBytesSentDuringPeriod]/[ElapsedTime])
期間は、サービス時間を計算するのに使用された期間に類似するように選択されるべきである。
【０４６８】
エンドユーザソフトウェア
各マシンがＩＰアドレスおよび接続を受けるポートを有する従来のネットワークとは異なり、このシステムは、待ち行列の概念上で機能する。
【０４６９】
エンドユーザソフトウェア（ＥＵＳ）が待ち行列を生成したとき、それは特定のマシン上でポートを開くのに似ている。しかし、いくつかの相違が存在する。
１．マシンのＩＰアドレスとポート番号が必要とされるＴＣＰ／ＩＰとは異なり、待ち行列に接続するときに必要なものは、待ち行列の名前（例えば、先に説明されたようなＱｕｅｕｅＮａｍｅ．ＧＵＩＤ）だけである。待ち行列の名前は、ノード、ノードの識別子、または物理的もしくはネットワーク内のノードの場所との何らかの関係を必ずしも有する必要がない。
２．ＴＣＰ／ＩＰでは、ノードは、ネットワークに接続されるとき、その存在を公表しない。この新しいシステムの下では、ノードは、ネットワークに接続されるとき、その直接接続隣接ノードにだけそれが存在することを伝える。この情報が順々に受け渡されて行くことはない。
３．ＴＣＰ／ＩＰの下でデータを受信するためにポートが開かれるとき、このことはネットワークにブロードキャストされない。新しいシステムでは、待ち行列が生成されるとき、直前の「２」で説明されたノード自体の取り扱いとは好対照に、ネットワーク全体がこの待ち行列の存在について通知される。待ち行列の情報は、隣接ノードから隣接ノードへの通信によってのみ伝播される。
【０４７０】
これらの特徴は、個々のノードのネットワーク内の位置に関するどのような情報も有さずに、ＥＵＳが他のＥＵＳへのコネクションをもつことを可能にする。
【０４７１】
ＥＵＳ間でコネクションを確立するため、ＴＣＰ／ＩＰに類似したハンドシェイクプロトコルが使用される。
１．ノードＡ：待ち行列Ａ１を生成し、通信を開く要求を有するメッセージを待ち行列Ｂに送信する。それは待ち行列Ａ１に送信される応答を求める。リクエストは、以下のような構造を有する。
struct sConnectionRequest [
// queue Al (could be replaced with a number -
// discussed later)
sQNameType              qnReplyQueueName;
// update associated with queue Al (explained
// later) Includes Latency,UpdateLatency, etc..
sQUpdate                quQueueUpdate;
]
【０４７２】
このメッセージは、ネットワークを通って進むとき、待ち行列Ａ１の定義も携えて行く。このようにして、このメッセージが到着したとき、メッセージをノードＢから待ち行列Ａ１に動かすことができる１組のノードがすでに存在する。
【０４７３】
ノードＡがノードＢからの応答を待ち行列Ａ１の中に見出さず、ノードＡ上の待ち行列Ａ１は「データストリーム内」として標識付けされておらず（ノードＢと待ち行列Ａ１の間に実際のコネクションが存在することを表す）、ノードＡが待ち行列Ｂについての非無限大の知識を依然として有する（待ち行列Ｂが、したがってノードＢが依然として存在しており、機能していることを表す）ならば、ノードＡは、このメッセージを再送信する。
【０４７４】
ノードＡは、メッセージを１秒おきに、またははるかに長い「待ち行列Ｂの待ち時間」秒おきに再送信する。
【０４７５】
ノードＢは、当然、複数の同一のリクエストを無視する。
【０４７６】
ノードがそれに対する２つの同じリクエストを有する場合、そのノードは、これらのリクエストの１つを除いたすべてを削除する。
２．ノードＢ：「あなたがメッセージを送信するための特別の待ち行列Ｂ１を生成しました。順序の乱れたメッセージを並べ直すためのＸバイトのバッファを割り当てました」と告げるメッセージを待ち行列Ａ１に送信する。
struct sConnectionReply [
// queueB1
sQNameType  qnDestQueueForMessages;
// update associated with queue B1 (explained
// later) Includes Latency,UpdateLatency, etc..
sQUpdate    quQueueUpdate;
// buffer used to re-order incoming messages
Integer     uiMaximumOutstandingMessageBytes;
]
【０４７７】
このメッセージは、ネットワークを通って進むとき、Ｂ１の定義も携えて行く。このメカニズムの結果として、このメッセージが到着したとき、メッセージをノードＡから待ち行列Ｂ１に動かすことができる１組のノードがすでに存在する。
【０４７８】
ノードＢがノードＡからの応答を待ち行列Ｂの中に見出さず、ノードＢ上の待ち行列Ｂ１は「データストリーム内」になく、ノードＢが待ち行列Ａ１についての非無限大の知識を依然として有するならば、ノードＢは、このメッセージを再送信する。
【０４７９】
ノードＢは、メッセージを１秒おきに、またははるかに長い「待ち行列Ａ１の待ち時間」秒おきに再送信する。
【０４８０】
ノードＢは、ｓＣｏｎｆｉｒｍＣｏｎｎｅｃｔｉｏｎメッセージを受信し、待ち行列Ｂ１が「データストリーム内」として標識付けされるまで、このメッセージを再送信し続ける。
【０４８１】
ノードＢは、当然、複数の同一のｓＣｏｎｆｉｒｍＣｏｎｎｅｃｔｉｏｎ応答を無視する。
【０４８２】
ノードがそれに対する２つ以上の同じ応答を有する場合、そのノードは、これらのリクエストの１つを除いたすべてを削除する。
３．ノードＡ：ノードは、待ち行列Ａ１上でノードＢからｓＣｏｎｎｅｃｔｉｏｎＲｅｐｌｙを受信し、待ち行列Ｂ１についての知識を有したときはいつでも、コネクションが正しく確立されたことを知らせる応答を待ち行列Ｂに送信する。
struct sConfirmConnection [
// the queue being confirmed
sQNameType                          qnDestQueueForMessages;
]
【０４８３】
ノードがそれに対する２つの同じｓＣｏｎｆｉｒｍＣｏｎｎｅｃｔｉｏｎメッセージを有する場合、そのノードは、これらのメッセージの１つを除いたすべてを削除する。
【０４８４】
待ち行列定義をハンドシェイクメッセージに添付することによって、コネクションを確立するのに必要とされる時間オーバヘッドが最低限に抑えられる。それが最低限に抑えられるのは、ノードは、送信できるようになる前に、待ち行列定義がネットワークを通って伝播するのを待つ必要がないからである。
【０４８５】
ノードＡは、その後、メッセージを送信し始めることができる。ノードＡは、実行中一度に、与えられたバッファサイズより多くのバイトを有してはならない。ノードＢは、ノードＡからの受信メッセージに対する肯定応答を送信する。ノードＢは、これらの肯定応答を待ち行列Ａ１へのメッセージとして送信する。
【０４８６】
ノードおよび待ち行列の構成の一例は、図３１のようになる。
【０４８７】
送信メッセージに対する肯定応答は、一連のメッセージとして表されることができる。肯定応答は一緒に連合させられる。例えば、メッセージグループ１０〜３５と３６〜５０の肯定応答は、メッセージグループ１０〜５０の肯定応答になる。これは、複数の肯定応答が単一メッセージ内に表されることを可能にする。
【０４８８】
肯定応答メッセージの構造は、以下のようになる。
struct sAckMsg [
integer          uiFirstAckedMessageID;
integer          uiLastAckedMessageID;
]
【０４８９】
肯定応答（ＡＣＫ）は、ＴＣＰ／ＩＰと同様の方法で処理される。送信メッセージが同じ「選択された宛先」に送信されたメッセージの平均ＡＣＫ時間の倍数以内に肯定応答されない場合、そのメッセージは再送信される。
【０４９０】
メッセージは、肯定応答されるまで、ＥＵＳがそれらを生成したノード上に保存される。これは、メッセージが送信中に失われた場合、それらが再送信されることを可能にする。
【０４９１】
ネットワークが待ち行列Ａ１がもはや見えないことをノードＢに通知した場合、ノードＢは待ち行列Ｂ１をネットワークから削除し、その通信に関連するすべてのバッファを解放する。ネットワークが待ち行列Ｂ１がもはや見えないことをノードＡに通知した場合、ノードＡは待ち行列Ａ１を削除する。
【０４９２】
これが生じるのは、ノードＡとノードＢの間のすべての可能な経路が削除された場合か、またはノードの一方または両方が通信を終了することを決定した場合だけである。
【０４９３】
メッセージが（待ち行列Ａ１内の肯定応答メッセージを介して）時間内にノードＢによって肯定応答されない場合、ノードＡはそれらのメッセージを再送信する。
【０４９４】
ノードＢは、任意の時点で「並べ直し」バッファサイズを増加または削減することができ、待ち行列Ａ１へのメッセージによって新しいサイズについてノードＡに通知する。ノードＢは、個々の待ち行列に割り当てられ得るデータ量に応じてサイズを変更する。個々の待ち行列に割り当てられ得るデータ量は、以下に依存する。
１．ノードがどれだけのメモリを有するか。
２．ノードがいくつの待ち行列を記憶するか。
３．いくつのデータフローがノードを通過しているか。
４．いくつの待ち行列がこのノードに起源をもつか。
【０４９５】
このサイズ変更メッセージは、以下のようになる。
struct sResizeReOrderBuffer [
// since messages can arrive out of order,
// the version number will help the sending
// node determine the most recent
// 'ResizeReorderBuffer'.
integer                  uiVersion;
// the size of the buffer
integer                  uiNewReOrderSize;
]
【０４９６】
送信側（ノードＡ）にもバッファが存在する。そのバッファのサイズは、そのノード上で動作しているシステムソフトウェアによって制御される。それは常に、ノードＢによって提供された最大ウィンドウサイズに等しいか、またはそれよりもより小さい。
【０４９７】
データストリーム内のノード
ノードは、最終的な送信側と最終的な受信側の間を流れるデータの経路上にある場合、データストリーム内と見なされる。ノードは、それがデータストリーム内にあることを直接接続ノードがそれに伝えるので、それがデータストリーム内にあることを知る。
【０４９８】
データは、データストリーム内として標識付けされていないノードを通って流れてもよい。「データストリーム内」として標識付けされたノードだけが、データストリーム内にあると見なされる。そこを流れるデータを有するが、データストリーム内として標識付けされていないノードは、データストリーム内にないと見なされる。
【０４９９】
別のノードにそれが「データストリーム内」にあることを伝える最初のノードは、その特定の待ち行列にメッセージを送信しようとするＥＵＳが存在するノードである。例えば、ノードＢが待ち行列Ａ１にメッセージを送信することを望む場合、ノードＢが、別のノードにそれが待ち行列Ａ１に向う「データストリーム内」にあることを伝える最初のノードになる。ノードは、それらを「データストリーム内」として標識付けすることなく、待ち行列Ｂのような待ち行列に送信する。
【０５００】
特定の待ち行列に向うデータストリーム内にあるノードは、その待ち行列に関するそれの「選択された宛先」であるすべてのノードに、それらがその待ち行列に向うデータストリーム内にあることを伝える。そのノードにそれがデータストリーム内にあることを伝えたすべてのノードが、そのノードにそれがもはやデータストリーム内にないことを伝えた場合、そのノードは、そのすべての「選択された宛先」にそれらがもはやデータストリーム内にないことを伝える。
【０５０１】
基本的に、ノードは、もはやデータストリーム内にない場合、それが選択された宛先として有するすべてのノードに、それらがデータストリーム内にないことを伝える。
【０５０２】
これは２つの目的で役に立つ。第１に、それは、データストリーム内のノードが、より良い経路を見つけようと即座に試みることを可能にする。第２に、それは、データストリーム内のノードが、待ち行列についての「記憶を失わ」ないよう保証する。
【０５０３】
別のノードにそれがデータストリーム内にあることを伝えるのに使用される構造体は、以下のようである。
struct sDataStream [
// the name of the queue, this could be replace with a
// number that maps to the queue name. (discussed later)
sQName      qnName;
// true if now in the stream, false if not.
bool                    bInDataStream;
];
【０５０４】
タイプＢ１の待ち行列に向うデータストリームだけが、組み合わされたマルチパス経路を生成する能力を有する。データストリーム内にあるタイプＡ１の待ち行列は、必要ならば単一経路に制限されることができるが、それは、ＡＣＫメッセージが小さく、かつ容易に一緒に合体されるためである。タイプＢのノードは、「データストリーム内」として標識付けされることは決してない。
【０５０５】
可能な機能強化は、「データストリーム」に追加されようとしている各ノードがループを形成しないことを確認するため、それをＧＵＩＤプローブする（ＧＵＩＤプローブは後で定義される）。
【０５０６】
ノードタスク
ノードは、ＥＵＳによって生成されたメッセージを別のＥＵＳに送信するため、直接接続ノードと通信する。ノードは、別のＥＵＳと信頼性のある通信を確立し保持するために使用されるメッセージも送信する。
【０５０７】
メッセージを送信するため、ノードは、
１．どこにメッセージを送信するか、
２．いつメッセージを送信するか、
を決定しなければならない。
【０５０８】
これらの場合の各々が、以下のセクションで検討される。
【０５０９】
どこにメッセージを送信するか
ノードは、どこにメッセージを送信するかを決定するため、
１．最終的な宛先に対する最良の待ち時間を提供し、
２．「ループ」を導入せず、
３．送信容量に余裕がある
接続ノードを選択しようと試みる。
【０５１０】
初期待ち行列知識
待ち行列がＥＵＳによって生成されたとき、システムは、その待ち行列が存在することをネットワーク内のあらゆるノードに伝える方法を必要とし、あらゆるノードは、他のノードを通るその待ち行列への経路を必要とする。目標は、待ち行列に対する認識と、ループのない経路を生成することである。
【０５１１】
ＥＵＳが最初に待ち行列を生成したとき、待ち行列がその上で生成されたノードは、すべての直接接続ノードに以下のことを伝える。
１．待ち行列の名前
これは、この待ち行列に一意な名前である。独立に生成された２つの待ち行列は、決して同じ名前を有してはならない。
２．待ち時間
先に説明された。これは、メッセージがそのノードから最終的な宛先であるノードまで進むのにどれだけの時間がかかるかを表す、秒数で示された値である。
３．「容量余裕なし」ステータス
後で説明される。これは、このノードの選択された宛先の経路内のいずれかのノードが、すでに処理しているよりも多くのデータフローを処理できない場合、真となるブール値である。
４．更新待ち時間
後で説明される。これは、最終的な受信側からの待ち時間更新がこのノードに到達するのにかかる最大時間を表す、秒数で示された値である。
５．データストリームからの距離
後で説明される。データストリーム内として標識付けされたノードからこのノードがどれだけ遠いかを表す点を除いて、「更新待ち時間」と非常に類似している。これは、どの待ち行列が「より重要」であるかを決定するために使用されることができる。一代替実施は、標識付けされたデータストリームから、またはペイロードメッセージを伝送するノードからノードがどれだけ遠いかをこれに表させることができる。
【０５１２】
この更新は、以下の構造をとる。
struct sQUpdate [
// the name of the queue. Can be replaced with
// a number (discussed later)
sQName                  qnName;
// the time it would take one message to travel
// from this node to ultimate receiver and be
// consumed by the EUS
float                  fLatency;
// if true, this node is already handling as
// much data as it can send. (discussed later)
bool                  bAtCapacity;
// the maximum time a latency update will
// take to travel from the ultimate receiver
// to this node.  (discussed later)
float                  fUpdateLatency;
// calculated in a similar fashion
// to 'fUpdateLatency'. and records the distance
// from a marked data stream for this node.
float                  fLatencyFromStream';
];
【０５１３】
これがそれまで未知の待ち行列であるか、または既知の待ち行列に対する更新であるかには関係なく、同じ情報が送信されることができる。
【０５１４】
ノード更新に遅延送信およびノード更新の順序付けは、先に説明されたのと同じ手法に従うべきである。
【０５１５】
これが直接接続ノードがその待ち行列について聞いた最初である場合、直接接続ノードは、最初にそれに伝えたノードを、その待ち行列へのメッセージに関するそれの「選択された宛先として」選択する。ノードは、他のノードがそれらもＥＵＳ生成の待ち行列への経路を提供することをそれに伝えたとしても、「選択された宛先」である１つまたは複数のノードにだけＥＵＳメッセージ／ペイロードを送信する。
【０５１６】
ノードは、直接接続ノードを「選択された宛先」として選択した場合、そのノードにそれが「選択された宛先」として選択されたことを伝えなければならない。メッセージの構造は、以下のようになる。
struct sPickedAsChosenDestination [
// the name of the queue. Could be replaced with a number
// (discussed later)
sQName                  qnName;
// true if the node this message is being sent to is a
// a chosen destination for this queue.
bool                    bSelected;
];
【０５１７】
ノードは、別のノードがこのノードをその待ち行列に関する「選択された宛先」としてすでに有している場合、そのノードを「選択された宛先」として決して選択しない。両ノードが同時に互いを選択したためにこのようなことが起こった場合、それは即座に解消されることを必要とする。
【０５１８】
１つの手法は、両ノードが、選択された宛先としての互いを削除し、ランダムな時間だけ待ち、その後、互いを再選択するよう試みることである。
【０５１９】
このようにして、あらゆるノードがＥＵＳ生成の待ち行列を知っており、一連の直接接続ノードを介したＥＵＳ待ち行列への非ループ経路を有する、ネットワークが生成される。
【０５２０】
図３２は、ネットワークを伝播する待ち行列についての知識を示した一連のステップである。この図におけるノード間のリンケージおよびノードの数は例に過ぎず、実際は、任意のネットワークトポロジ内には、任意のノードからも、任意の数のノードの間にも、リンケージの無限の多様性が存在し得る。
【０５２１】
いかなる時点でも、ネットワーク内のノードは、ネットワークトポロジまたは経路についての全域的な知識を収集しようとは試みない。システムは、あらゆるノードに、ＥＵＳ生成の待ち行列の名前と直接接続ノードがＥＵＳ生成の待ち行列に与えた待ち時間とを提供する。
【０５２２】
ノードは、メッセージのための複数の可能な経路を有するとしても、その「選択された宛先」として選択した１つまたは複数のノードに沿ってだけメッセージを送信する。
【０５２３】
ノードは、その「選択された宛先」として別の直接接続ノードを選択した場合、２つのノードが互いを「選択された宛先」として選択した場合に生成され得るループを回避するために、そのノードにその選択について伝える。
【０５２４】
あらゆるノードは、それがどの待ち行列についてその直接接続ノードに伝えたかを把握し続ける。直接接続ノードが伝えられていないあらゆる新しい待ち行列は、即座に送信される（伝播優先順を参照）。できたばかりのコネクションの場合、そのコネクションの両側のノードが、それらが知っていたあらゆる待ち行列についての知識を送信する。
【０５２５】
ノードは、ネットワーク内のあらゆる待ち行列の名前、待ち時間などを保存するのに十分なメモリを含んでいない場合、重要でないと思われる待ち行列を「記憶から消す」ことができる。ノードは、このノードが標識付けされたデータストリームから最も遠い場合、それらの待ち行列を選択して記憶から消す。ノードは、このノードが標識付けされたデータストリームからどれだけ遠いかを決定するため、値「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」を使用する。
【０５２６】
一代替実施形態は、値「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」を使用して、標識付けされたデータストリームから、またはペイロードパケットを伝送するノードからの距離を表すことができる。
【０５２７】
これの唯一の副作用は、それらの待ち行列に接続できなくなることであり、宛先に関してそのノードに全面的に依存しているノードもそれらの待ち行列に接続できなくなることである。
【０５２８】
値「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」は、どの待ち行列がより重要であるかを決定することを助けるのに使用されることができる（伝播優先順を参照）。ノードが待ち行列Ａに向う標識付けされたデータストリームから１００秒であり、待ち行列Ｂに向う標識付けされたデータストリームから１秒離れている場合、このノードは標識付けされたデータストリームに最も近く、代替経路を見出すことを助ける際により多く使用され得るので、ノードは待ち行列Ｂを選択して記憶すべきである。
【０５２９】
無限大の待ち時間（後で説明される）を有する新しい待ち行列名を伝えられたノードは、その待ち行列名を無視する。
【０５３０】
待ち行列名最適化およびメッセージ
あらゆる待ち行列更新は、それがどの待ち行列を参照するかを識別する方法を有する必要がある。待ち行列名は、簡単に長くなる傾向にあり、送信するのに非効率的である。ノードは、番号を使用して長い名前を表すことによって、より効率的になることができる。
【０５３１】
例えば、ノードＡは、「ＴＨＩＳＩＳＡＬＯＮＧＱＵＥＵＥＮＡＭＥ．ＧＵＩＤ」という名前の待ち行列についてノードＢに伝えたいと望む場合、最初に、
1 = 'THISISALONGQUEUENAME.GUID'
とノードＢに伝えることができる。
【０５３２】
このための構造体は、以下のようにすることができる。
struct sCreateQNameMapping [
int                      nNameSize;
char                     cQueueName[Size];
int                      nMappedNumber;
];
【０５３３】
その後、ノードＡは、待ち行列更新を送信したいと望むたびに、長い待ち行列名を送信する代わりに、その待ち行列名を表す番号を送信することができる。ノードＡは、「ＴＨＩＳＩＳＡＬＯＮＧＱＵＥＵＥＮＡＭＥ．ＧＵＩＤ」と呼ばれる待ち行列についてノードＢに伝えたいと望むことはもはやないと決定を下した場合、そのマッピングについての記憶を消すようにノードＡに命じることができる。
【０５３４】
その構造体は、以下のようである。
struct sRemoveQNameMapping [
int                        nNameSize;
char                       cQueueName[Size];
int                        nMappedNumber;
];
【０５３５】
各ノードは、どの名前がどの番号にマッピングされるかについて、それ独自の内部マッピングを保持する。各ノードは、直接接続ノードからの名前を、それ独自の命名体系に変換することができるように、変換表を保持する。例えば、ノードＡは、
1 = 'THISISALONGQUEUENAME.GUID'
を使用することができる。
【０５３６】
ノードＢは、
632 = 'THISISALONGQUEUENAME.GUID'
を使用する。
【０５３７】
したがって、ノードＢは、ノードＡの番号付与体系を、ノードＢにとって理解できる番号付与体系に変換することを可能にするマッピングを有する。この例では、以下のようになる。
【表１７】
2007523546.tif 000019
【０５３８】
この番号付与体系の使用はまた、ノードＢからノードＡへのメッセージを、それらに向かう待ち行列に付けることができる。例えば、システムは、１００バイトのメッセージを有するとき、メッセージが属する待ち行列名を格納するための４バイトを先頭に確保し、その後にメッセージが続くようにする。こうすると、全体メッセージサイズは１０４バイトになる。この構造体の一例は、メッセージのサイズも含む。
struct sMessage [
int          uiQueueID;
int          uiMsgSize;
char         cMsg[uiMsgSize];
]
【０５３９】
このメッセージが宛先ノードによって受信されると、そのノードは、その変換表を参照し、このメッセージがどの待ち行列に配置されるべきかを決定する。
【０５４０】
削除される待ち行列への経路
元の待ち行列が生成されたノードへの経路上にあるノードが、その唯一の「選択された宛先」として使用していたノードから切断された場合、そのノードは最初、非ループの代替経路を見出そうと試みる。
【０５４１】
ノードはこれを、現在このノードに送信していないすべてのノードを調べることによって行う（すなわち、このノードを「選択された宛先」として有する）。このノードを「選択された宛先」として有するノードを選択すると、ループが生成される。
【０５４２】
このノードは、「追加経路の追加」で後で説明される「ＧＵＩＤプローブ」プロセスを使用して、残りの可能なノード内でループ調査を行うために、ＧＵＩＤプローブを使用する。
【０５４３】
すべての潜在的な代替経路がループである場合、ノードは、その待ち時間を無限大に設定し、すべての接続ノードに即座にこの新しい待ち時間について伝える。
【０５４４】
ノードは、それに無限大の待ち時間を伝えた「選択された宛先」を有する場合、そのノードにデータを送信することを即座に停止し、そのノードを「選択された宛先」から削除する。すべての「選択された宛先」が削除された場合、ノードは、それ自身の待ち時間を無限大に設定し、その直接接続ノードに即座に伝える。
【０５４５】
ノードは、待ち行列に対するその待ち時間を無限大に設定し、その直接接続ノードに伝えた後、しばらくの間（例えば１秒）待機する。この期間が終了すると、ノードは即座に、無限大の待ち時間をもたない直接接続ノードを選択された宛先として選択し、データの送信を再開する。
【０５４６】
ノードは、最初の期間が経過した後、最初の固定時間の２倍（例えば２秒）以内に、適切な新しいソースを見出さない場合、その待ち行列からのメッセージを削除し、その待ち行列についての知識を削除する。
【０５４７】
この期間は、この待ち行列が無限大になった更新をこのノードが送信するのにかかった時間の倍数に基づいている（後の伝播優先順を参照）。この値は、その後、１０またはネットワークの相互接続性に依存する適当に大きな数を乗じられる。
【０５４８】
例えば、ネットワークが非常に大きく、まばらに接続されている場合、この数は１０より大きい。稠密で良く接続されたネットワークでは、この値は１０である。
【０５４９】
ノードの待ち時間が無限大から非無限大に移動した場合、ノードは即座に、すべての直接接続ノードにその新しい待ち時間について伝える。
【０５５０】
この例では、１０個のノードを有するネットワークにおいて、ネットワークの各側で１つずつ２つのノードに直接接続されたノードの１つで、ＥＵＳが待ち行列を生成した。
【０５５１】
図３３では、ネットワーク内のあらゆるノードが、（右下の０の待ち時間を有する）ＥＵＳ生成の待ち行列をちょうど知るようになったところであり、各ノード内の数字は、上で定義されたような秒数で示された待ち時間を表す。
【０５５２】
次に図３４では、ＥＵＳ生成の待ち行列を有するノードとの間のコネクションの１つが削除される。
【０５５３】
ＥＵＳ生成の待ち行列を有するノードへのコネクションを失った直接接続ノードは、それが直接接続されたノードのどれかが、それを送信者として使用しているかどうかを知るために検査を行う。それらのすべてがそうなので、それらがループしているかどうかを決定するために、ＧＵＩＤを用いてそれらをプローブする必要はない。このノードは、その後、それ自身を無限大の待ち時間に設定する。これは図３５に示されている。
【０５５４】
このノードは即座に、その新しい待ち時間についてすべての直接接続ノードに伝える。
ノードの「選択された宛先」のすべてが無限大にあるならば、それらのノードの待ち時間も同様に無限大になる。これは図３６に示されている。
【０５５５】
この処理は、無限大に設定され得るすべてのノードが無限大に設定されるまで続く。これは図３７に示されている。
【０５５６】
この時点で、無限大に設定されたあらゆるノードは、一定の期間（例えば１秒）停止し、その後、それが見出した無限大ではない最低待ち時間の宛先を選択する。これは図３８に示されている。
【０５５７】
無限大だったノードは、非無限大になると直ちに、それに直接接続されたノードに即座に伝える。それらのノードの１つが無限大にある場合、そのノードは、それに非無限大の待ち時間を与えた最初の接続ノードを、その選択された宛先として選択する。これは図３９に示されている。
【０５５８】
この時点で、ネットワークコネクションは、ＥＵＳ生成の待ち行列に宛てられたすべてのメッセージのその待ち行列への転送を可能にするように構成され直す。
【０５５９】
待ち行列に関するノードの待ち時間が数秒より長く無限大にある場合、そのノードは最終的な受信者への他の代替経路は存在しないと仮定することができ、待ち行列内のメッセージはどれも、その待ち行列についての知識とともに削除されることができる。
【０５６０】
図４０は、上述の処理の概要を示している。
【０５６１】
「データストリーム内にない」ノードの最適経路への収束
ノードは常に、異なる選択された宛先を選択することによって、最初に生成された待ち行列へのそれらの待ち時間を低下させようと試みている。
【０５６２】
ＥＵＳメッセージを転送するために最終的な送信側と最終的な受信側の間のノード上に確立された待ち行列だけが、帯域幅を増やすための組み合わされた複数経路を使用する。最終的な送信側は、すべての「選択された宛先」にそれらがこのデータ送信経路内（「データストリーム内」）にあることを伝えることによって、この経路を標識付ける。それらの「選択された宛先」ノードの各々は、それら自身の「選択された宛先」ノードにそれらも「データストリーム内」にあることを伝える。図４２はこれを示している。
【０５６３】
特定のノードへのすべての送信側が切断された場合、もしくはそのノードにそれがもはや「データストリーム内」にないことを伝えた場合、またはそのノードにそれが「データストリーム内」にあることを伝えたノードがそのノードにそれがもはや「選択された宛先」でないことを伝えた場合、そのノードは、「データストリーム内」フラグを消去し、そのすべての選択された宛先にそれらがもはやデータストリーム内にないことを伝える。
【０５６４】
ＥＵＳメッセージの経路内に現在あるノードは、ＥＵＳを有する２つのノード間で転送する場合、新しい「選択された宛先」を選択するのに異なるメカニズムを使用する。
【０５６５】
複数の選択された宛先を有するノードは、データストリームから削除された場合、最低待ち時間を有する１つを除いて、すべての選択された宛先を削除する。ループを発見するメカニズムは１つの選択された宛先を相手にするだけになるので、これは、そのメカニズムが効果的であり続けることを可能にする。
【０５６６】
データストリーム内に現在ないノードは常に、現在の選択された宛先よりも小さい待ち時間を有するノードを選択することによって、最終的な受信側へのその待ち時間を改善しようと試みる。
【０５６７】
ノードは、異なる「選択された宛先」を選択しようとするとき、それがループを導入しないことを確認する必要がある。
【０５６８】
そのコネクションの性能を高めようとしているノードは、待ち時間に関係なく、「容量余裕なし」のノードよりも、（後で説明される）「容量余裕なし」でないノードを好む。
【０５６９】
ノードは、ＥＵＳメッセージ／ペイロードの経路内に現在ない場合、ＧＵＩＤまたはメッセージを使用して、可能な新しい選択された宛先がループかどうかを知るための検査を行うことが許されないが、それは、どのようなサイズのネットワークも、これらのメッセージによって速やかに過剰動作させられるからである。
【０５７０】
代わりに、そのようなノードは、そのノードからの周期的かつ自動的な待ち時間更新を待機し、それを現在の「選択された宛先」の待ち時間と比較することによって、潜在的な選択肢の待ち時間を見守る。
【０５７１】
潜在的な新しい宛先が、選択されたならばループを生成する状況では、明らかにより小さい待ち時間となる主な原因は、現在のノードとこの潜在的な新しいノードの間のループにおけるデータの進行時間によって導入される遅延である。
【０５７２】
例えば、現在のノードの待ち時間が毎秒１秒ずつ増加し、このノードと新しい潜在的な「選択された宛先」との間に３秒の遅延を有するループが存在する場合、新しい潜在的な「選択された宛先」は常に、現在の選択された宛先よりも３秒少ない待ち時間を有するように見える。
【０５７３】
図４３は、回避されるべき潜在的ループの別の例である。
【０５７４】
現在のノードがこの明らかに「より良い選択肢」を選択した場合、システム内にループを生成する。
【０５７５】
これは、待ち行列更新からの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」値が使用される場合である。この数は、待ち行列更新が、待ち行列を生成したノードから進むのにかかる最大時間である。この値の実際の計算は、後で説明される。
【０５７６】
先の図では、ノードＢは、ノードＦがノードＡよりも良い選択肢であるかどうかを決定しようと試みる。ノードＢは、ノードＦとノードＡの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」の差を比較する。この例では２つの値は、以下のようである。
ノードＡのfUpdateLatency: 8s
ノードＦのfUpdateLatency: 13s
【０５７７】
ノードＡは現在の選択された宛先であり、ノードＦの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」はノードＡの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」よりも高いので、ノードＢは、ノードＦが実際にメッセージを一連のノードを介してノードＢに転送するかどうかを知るために検査を行う必要がある。
【０５７８】
ノードＢは、ノードＦがより高い「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」を有するというだけで、有効な新しい「選択された宛先」としてのノードＦを即座に廃棄することはできない。このわけは、ノードＦが提供する代替経路は、最終的な宛先までの潜在的により長い経路だとしても、ノードＡによって提供される経路上の輻輳のために、より高速であり得るからである。
【０５７９】
受動的ループ試験の背景にある基本アイデアは、以下のようなものである。
・  ＡとＦの間のｆＵｐｄａｔｅＬａｔｅｎｃｙの差（この例では５秒）は、ノードＢから送信された待ち時間更新がノードＦに到達するのに最大でどれだけかかるかを表す。
・  ループが存在する場合、この期間中のノードＦからの待ち時間の最大値は、今回以前の同じ期間中のノードＡからの待ち時間の中央値よりも大きい。
【０５８０】
中央値のための全期間は、ノードＡの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」の値よりも決して長くなってはならない。例えば、ノードＡとノードＦの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」値の差が５秒であり、ノードＡの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」が８秒である場合、中央値を計算するための期間は、８秒だけである。最大値を監視する期間は５秒である。
【０５８１】
図４４はこれを示している。
【０５８２】
この技法は、ループに対してフォールスポジティブを示すことがあるが、フォールスネガティブを示すことは極めて稀にしかない。ループへの対処は、後で説明される。
【０５８３】
上述の場合に中央値を使用することは、理想的であるが、中央値を計算するには、すべての観測値を保存する必要がある。以下に示すのは、中央値を近似することができ、低い固定オーバヘッドしか必要としない、擬似コードアルゴリズムである。
float fPart1 = 0;
float fPart2 = 0;
int  nCount  = 0;
while (not done all observations) [
float fCurOb = GET_ CURRENT_OBSERVATION( )
fPart1 = fPart1 + fCurOb;
nCount = nCount + 1;
fPart2 = fPart2 + abs( fPart1 / nCount - fCurOb);
]
float fCloseToMedian = fPart1 / nCount1 - fPart2/nCount;
【０５８４】
観測期間が小さ過ぎると、それらは低解像度タイマの１回の繰り返しに切り上げられる。
【０５８５】
中央値と最大値の両方の観測期間中、ｆＵｐｄａｔｅＬａｔｅｎｃｙの値は変化し得る。２つの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」の差が増加する場合、新しい増やされた期間が使用される。より低い値は無視される。これは、「中央値」の期間が「最大値」の期間より小さい状況をもたらし得る。これは良いことである。
【０５８６】
ノードＦの「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」がノードＡより小さいか、または比較の実行中により小さくなる場合、ループはあり得ず、ノードは、さらなる遅延なしに、ノードＦを新しい選択された宛先として選択することができる。
【０５８７】
このノード上の待ち行列が「容量余裕なし」である場合、我々は、より高い待ち時間を有する「容量余裕なし」でないノードを選択するほうを好む。このノードは、適切な時間だけまだ待機して、この「容量余裕あり」ノードが容量余裕ありのままでいることを確認する。この期間中に考慮対象ノードが「容量余裕なし」に変わったとしても、より低い待ち時間を提供し、ループを導入しない場合、このノードは、そのノードを「選択された宛先」として使用することができる。
【０５８８】
このノードが現在無限大にある場合、このプロセスは使用されない（上記を参照）。
【０５８９】
「最大値」の期間中にノードＡの中央値よりも大きい待ち時間更新がノードＦから到着した場合、試験はループを指摘して終了する。ノードＢは、「最大値」の全期間が満了するのを待たない。これの例外は、このノードが「容量余裕なし」であり、考慮対象ノードが「容量余裕なし」でない場合である。
【０５９０】
データストリーム内にないノードは、その待ち行列に関する選択された宛先をただ１つ有することができるので、新しい選択された宛先を選択した場合、古い選択された宛先の使用を停止する。
【０５９１】
データストリーム内にないノードは、新しい選択された宛先に切り替えるとき、現在の選択された宛先の「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」と新しい選択された宛先の「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」の差を記録する。この値は保存され、ループの検出を助けるのに使用される（後で説明される）。
【０５９２】
容量余裕なし検査
各ノードの各待ち行列は、容量に余裕なくデータを送信または受信しているとき、それを検出するメカニズムも有する。ノード上の待ち行列は、待ち行列内のデータの待ち時間が、例えば、６回以上の時間インターバルにわたって、
ｍａｘ（［すべての選択された宛先の待ち時間］）−ｍｉｎ（［すべての選択された宛先の待ち時間］）
を超過したときに、容量に余裕がないと見なされる。時間インターバルは、送信可能なあらゆる宛先が一定の数（例えば１０）のメッセージを送信する時間、または最小である期間（例えば高速システムタイマの最小細分度の２倍）、または最大で別の期間（例えば６秒）として定義される。
【０５９３】
選択された宛先が待ち行列内の全データ量を可能な最低点にまで引き下げる機会を有するのに十分な時間が時間インターバルの間に経過することが重要である。例えば、データが毎秒１００バイトで流入しており、５秒ごとに５００バイトで流出している場合、５秒の絶対最小時間インターバルが必要とされる。
【０５９４】
図４５は、時間インターバル内の待ち行列レベルおよび最低レベルの一例である。
【０５９５】
ノードは、この期間にわたって待ち行列の待ち時間をこのレベルまで引き下げることができない場合、容量に余裕がないと見なされる。ノードがそのようにすることができない場合、ノードに流入するデータが多過ぎて、データを到着とほぼ同時にうまく送出することができない。
【０５９６】
ノードは、容量に余裕がない場合、それが接続されているすべてのノードに伝える。ノード上の待ち行列に関するすべての「選択された宛先」が「容量余裕なし」として標識付けられている場合、そのノードは、それも容量余裕なしであることを、そのすべての直接接続ノードに伝える。
【０５９７】
「容量余裕なし」更新は、通常の待ち時間更新と同時にネットワーク中を進行する。それらが通常のデータフローに取って代わることはない（先のｓＱｕｅｕｅＵｐｄａｔｅを参照）。
【０５９８】
先に説明されたように、データフロー内にないノードは、「容量余裕なし」と標識付けされた「選択された宛先」に代わる非ループの代替経路を見出そうと試みる。ノードは、データストリーム内にある場合、「選択された宛先」としての「容量余裕なし」ノードを、その「容量余裕なし」ステータスのために削除しようとは試みず、待ち時間だけに基づいてそのノードを削除することを決定する。
【０５９９】
容量に余裕がない場合に追加の経路を見出す
あまりに多くのデータが流入するために容量に余裕がないノードは、直接接続ノードを使用してすべての可能な追加経路の一覧を作成する。可能な追加経路は、以下のノードである。
１．容量に余裕があるノード
２．このノードに送信していないノード
３．ループを形成しないノード
４．問合せを行っているノード以外に待ち行列の宛先を有するノード（すなわち、ループが形成されない）
【０６００】
これらの可能な経路の各々に対し、容量余裕なしノードは、一意のＧＵＩＤを生成する。このＧＵＩＤは、各可能な経路に送信されて、ループに関して各経路を試験する。ループが検出された場合、その経路は、可能な追加経路の一覧から廃棄される。
【０６０１】
可能な経路に対応する各ＧＵＩＤは、その経路に沿って次の宛先ノードに送信される。そのノードは、そのＧＵＩＤを保存し、それが「選択された宛先」として有するすべてのノードにそのＧＵＩＤを転送する。ノードが新しいノードを宛先に選択した場合、ＧＵＩＤは、その新しいノードに渡される。ノードは、すべての「選択された宛先」にＧＵＩＤを記憶から消すよう命じることによって、そのＧＵＩＤを失効させる。ノードにＧＵＩＤを記憶するよう命じたすべてのノードが、ノードにＧＵＩＤを記憶することを止めるよう命じた場合、またはそれらがもはや宛先として選択されていないこと、もしくはそれらが切断されたことをノードに伝えた場合、ＧＵＩＤは失効させられる。
【０６０２】
図４６は、これの一例である。図４６では、容量に余裕がないノードは、それが可能な追加の選択された宛先に送信したＧＵＩＤを見出した場合、その選択が悪い選択であったことを知る。
【０６０３】
同様に、選択された経路に送信されたＧＵＩＤは、データがそれに沿ってそのノードから流れることができるすべての経路を列挙する。
【０６０４】
容量に余裕がないマシンは、それが送出したＧＵＩＤの１つが、それにデータを送信しているノードから戻って来たのを見出した場合、それがＧＵＩＤを送信したノードがループの一部を形成しており、その可能な経路が「容量余裕なし」ステータスを解消するための選択肢から除去されることを知る。ＧＵＩＤメッセージは、ＧＵＩＤ、問題の待ち行列の名前、「進行時間」、およびこのＧＵＩＤを記憶するまたは記憶から消すようノードに命じるメモから構成される。
【０６０５】
ノードは、ＧＵＩＤを記憶するまたは記憶から消すよう命じられた場合、できるだけ速やかにこのメッセージを送信する（伝播優先順を参照）。ノードは、このＧＵＩＤメッセージをすでに見出し、処理している場合、それを無視する。
【０６０６】
ＧＵＩＤメッセージは、以下のような構造をとる。
struct sGUIDProbe [
// could also be a number that represents this queue
// (discussed previously)
sQueueName  qnQueueName;
// true if the node is supposed to remember this GUID
// false if its supposed to forget it.
bool                    bRememberGUID;
// the actual GUID
char                    cGUID[constant_Guid_Size];
// how far the GUID will travel (based on fUpdateLatency)
float                   fMaximumGUIDTravelTime;
];
【０６０７】
ＧＵＩＤの進行時間は、新しい経路を探しているノードのｆＬａｔｅｎｃｙＵｐｄａｔｅと容量に余裕がある可能な新しい経路のｆＬａｔｅｎｃｙＵｐｄａｔｅの差の（例えば）３倍として設定される。ノードは、ＧＵＩＤプローブを受信するたびに、このＧＵＩＤプローブについて直接接続ノードに伝える前に、ｆＬａｔｅｎｃｙＵｐｄａｔｅ値へのその寄与分を、（この値を通常するようにｆＬａｔｅｎｃｙＵｐｄａｔｅに加算する代わりに）ｆＭａｘｉｍｕｍＧＵｌＤＴｒａｖｅｌＴｉｍｅ時間から減算する。その寄与分をｆＭａｘｉｍｕｍＧＵｌＤＴｒａｖｅｌＴｉｍｅ時間から減算した後、その値が０より小さい場合、ＧＵＩＤプローブは、どの選択された宛先にも渡されない。
【０６０８】
減算する値は、このＧＵＩＤプローブが基づいている待ち行列と同じクラスのすべての待ち行列のラウンドロビン更新のための時間に基づいている（後で説明される。「第２」の「伝播優先順」を参照）。
【０６０９】
容量に余裕がないノードは、ＧＵＩＤに、ネットワーク内を進み、ループが存在するならば「容量余裕なし」ノードにループバックする機会を与えるため、最小でその初期「ｆＭａｘｉｍｕｍＧＵｌＤＴｒａｖｅｌＴｉｍｅ」だけ待機する。その時間が経過した場合、ＧＵＩＤがノードに戻って来なかったすべての潜在的な選択が有効な選択肢と見なされる。
【０６１０】
最低待ち時間で、「容量余裕なし」でなく、非ループのノードが選択され、それが今では「選択された宛先」であることを知らせるメッセージが、そのノードに送信される。これは、２つの直接接続ノードがそれら自身を宛先として選択し、ループを形成することを防止するために行われる。
【０６１１】
２つの直接接続ノードが同時に互いを宛先として選択した場合、両ノードは、直ちにそれまでの宛先に切り替え戻し、追加の宛先を見出すプロセスを再び試みる。ＧＵＩＤメカニズムはランダムなインターバルを含むので、２つのノードが再び互いを選択する可能性は、繰り返しのたびに劇的に低下する。
【０６１２】
すべての可能な経路がループとして戻って来た場合、「容量余裕なし」ノードは、ＧＵＩＤを削除する。このノードは、しばらく後も依然として「容量余裕なし」である場合、代替経路を探すプロセスを再実行する。このノードは、ＧＵＩＤプローブの最後のラウンドで使用された最大「ｆＭａｘｉｍｕｍＧＵＩＤＴｒａｖｅｌＴｉｍｅ」の（例えば）３倍だけ待機する。
【０６１３】
ノードがデータを送信する場所としていくつかの選択肢を有するとしても、待ち行列に許された最大待ち時間は依然として、
ｍａｘ（［すべての選択された宛先の待ち時間］）−ｍｉｎ（［すべての選択された宛先の待ち時間］）
であり、そのノード上で利用可能なメモリに依存する。この新しいノードが選択されると直ちに、ノードは、その「容量余裕なし」ステータスをクリアすることができる。
【０６１４】
もう少し多くのデータが送信されることを許容するフロー制御の割当分残高が存在し得るので、この最大値は厳格な制限ではない（フロー制御を参照）。
【０６１５】
トークン更新がこのノードにデータを送信するノードに送信されるたび、最後の時間インターバルにおける現在の最小待ち時間、および「容量余裕なし」フラグも同様に送信される。これは、送信ノードが常に最良経路を選択することを可能にする現在の待ち時間データを有することを可能にする。
【０６１６】
未使用追加経路を削除する
データストリーム内にないノードは、選択された宛先を１つ有するだけなので、追加のソースを削除することはなく、代わりに１つのソースからより良いソースに切り替える（先に説明された）。
【０６１７】
データストリーム内にあるノードは、複数のデータ経路を開発する可能性を与えられた唯一のノードである（先に説明された）。
【０６１８】
データストリーム内にあるノードは、一定の期間、データを送信するために特定の「選択された宛先」を使用しない場合、この選択された宛先を選択された宛先の一覧から削除し、そのノードにそれがもはや選択された宛先ではないことを知らせる。
【０６１９】
ノードにそれがもはや選択された宛先ではないことを伝えることにより、「データストリーム内」にある別のノードもこのノードを選択された宛先として選択していない限り、「データストリーム内」フラグも削除される。
【０６２０】
未使用の選択された宛先を削除する前に待つ一定の時間は、最初にコネクションを生成するのに必要とされた時間と比べて比較的長くなければならない。選択された宛先が保持される時間は、ノードが削除されてから再び追加されるまでにどれだけの時間が経過したかに基づいて、時間とともに動的に調整されることもできる。
【０６２１】
「容量余裕なし」でない場合にいつ選択された宛先を追加／削除するかを決定する
ノードは、可能な選択肢が存在するならば、常に少なくとも１つの「選択された宛先」をもたなければならない（選択肢がなければ、その待ち時間が無限大になる）。
【０６２２】
ノードは、特定の待ち行列に関するデータストリーム内にある場合、その待ち行列がデータを転送するために使用される待ち行列であるならば、２以上の「選択された宛先」を有することができる。ＴＣＰ／ＩＰのハンドシェイク例では、これは待ち行列Ｂ１（先の図）である。
【０６２３】
ノードは、容量に余裕があり、すべての「選択された宛先」が削除するには活動的過ぎる（上記を参照）ために「選択された宛先」を削除できない場合、すべての「選択された宛先」の最高の待ち時間より小さい待ち時間を有する新しい選択された宛先を追加しようと試みる。
【０６２４】
ノードは、「容量余裕なし」でない可能な「選択された宛先」だけを選択しなければならない。
【０６２５】
ノードは、現在の「選択された宛先」をより良い選択肢で置き換えることを期待してこれを行う。これは、ノードが、全経路をより高速にすること、およびノードを通過するメッセージのためにより少ないバッファしか必要としないことを可能にする。
【０６２６】
ノードは、ＧＵＩＤプローブを用いて可能な選択肢をプローブする（上で説明された）。ＧＵＩＤプローブが失敗した（ループが検出された）場合、ノードは、次にこのコネクションの最適化を試みるとき、次に最低の待ち時間を有する別の直接接続ノードを選択する。
【０６２７】
図４７は、このプロセスを図説するフローチャートである。
【０６２８】
偶然生成されたループを解消する
標識付けされたデータストリームの部分でないノードにおいてループが偶然生成された場合、それらの待ち時間および「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」は上昇する。
【０６２９】
図４８は、データストリーム内にないノードにおいて偶然生成されたループを示している。
【０６３０】
データストリーム内にないノードにおけるループは、可能な新しい選択された宛先の待ち時間を我々が比較する方法（上記を参照）のため、稀である。
【０６３１】
我々はＧＵＩＤを使用して積極的にループを探して可能な新しい宛先をプローブするので、ごく稀にＧＵＩＤメカニズムが使用された後に経路変更が干渉を受けた結果として以外、ループはデータストリーム内に生成されない。
【０６３２】
「容量余裕なし」ノードまたは無限大になったノードを含まない単純なループは、標準的な「受動的」ループ検出メカニズムを使用して、容易に解消される。
【０６３３】
ループ内のノードは、その待ち行列の最終的な受信側への実際のコネクションをもたない待ち行列について知っているような見掛けをとる。例えば、ループが維持され、実際の最終的な受信側がネットワークを離脱した場合、このループは、この待ち行列についての知識を自己保持し続ける。
【０６３４】
この問題は、以下の場合に生じる。
１．ループ内のノードが「容量余裕なし」でなく、ループ外のノードが「容量余裕なし」である場合。
２．ループ外のノードが「無限大」にある場合。
【０６３５】
どちらの場合も、解決策は、ループの可能性が存在することを検出し、先に説明されたのと同じ方法でそれらの待ち時間を無限大に変更することである。これにより、ノードは非ループ状態に速やかに移される。
【０６３６】
データストリーム内にないノード上に我々がおり、以下のような直接接続ノードが存在する場合、
１．我々のノードがそうでないときに「容量余裕なし」の状態にあり
２．我々が有さないときに無限大の待ち時間を有する
【０６３７】
ループ試験が起動される。
【０６３８】
新しい「選択された宛先」を選択するプロセス中、ノードは、新しい「選択された宛先」と古い「選択された宛先」の「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」の差を記録する。３を乗じられた秒数で示されたこの時間は、「可能ループ時間」（ＰＬＴ：ｐｏｓｓｉｂｌｅ  ｌｏｏｐ  ｔｉｍｅ）と呼ばれる。
【０６３９】
我々のループ試験は、ＰＬＴの間の最小「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」、「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」、および「ｆＬａｔｅｎｃｙ」を記録することによって開始する。
【０６４０】
２つの連続する繰り返しにおいて、３つの記録された値（「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」、「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」、および「ｆＬａｔｅｎｃｙ」）のすべてが、前の繰り返しより小さい場合、実際にループが存在するかどうかを決定するために、ＧＵＩＤプローブが使用される。ＧＵＩＤプローブ（上記を参照）は、（例えば）ＰＬＴ×５の時間だけネットワーク中を進行するように設定される。
【０６４１】
ループが検出された場合、それを検出したノードは、「削除される待ち行列への経路」と同じ方法で無限大になる。
【０６４２】
ＧＵＩＤプローブが失敗した場合、ノードは上で説明されたループ試験に戻る。
【０６４３】
このプロセスが３回繰り返された場合、ノードはいずれにせよ「無限大」になる（「削除される待ち行列への経路」を参照）。
【０６４４】
いつメッセージを送信するか
いつメッセージを送信するかを決定する際、ノードは、送信先ノードが、
１．メッセージを保存するための領域を有するかどうか、
２．他の直接接続ノードの待ち時間およびこのノードの待ち行列内のデータ量に鑑みて、役に立つ宛先への待ち時間を提供するかどうかを決定する。
【０６４５】
役に立つ選択された宛先だけに送信する
ノードがメッセージを送信するための複数の「選択された宛先」を選択したとしても、それは、それらすべてが使用されることを意味しない。「選択された宛先」は、待ち行列内のデータの現在の待ち時間が、
［選択された宛先の待ち時間］−ｍｉｎ（［すべての選択された宛先の待ち時間］）
に等しいか、またはより大きい場合にだけ使用される。
【０６４６】
「選択された宛先」の待ち時間が、すべての「選択された宛先」の待ち時間の最小値よりｘ秒長い場合、その選択された宛先を使用する前に、ｘ秒分のデータが、そのノード上に保存される。
【０６４７】
選択された宛先が（先に説明された）現在の待ち行列の待ち時間を上回る待ち時間を有する場合、我々は、そのノードの待ち時間が指定された値を下回ったときにそのことを我々に知らせるよう求めるメッセージをそのノードに送信するオプションを有する。ノードに一定の値で更新を送信するよう求めることは、ノードに現在の待ち時間を送信させる原因ともなる。
【０６４８】
これは、受信側の待ち時間に関して送信側に知らせておくために必要とされる素早い更新の問題を解決する。
【０６４９】
待ち時間および「容量余裕なし」更新は、トークン更新（後で定義される）、およびノードとノードとの帯域幅のＸ％を超えないよう制限される継続的ストリームの両方で受け渡される。通常、この数は１〜５％である。ノードは、すべての既知の利用可能な待ち時間をラウンドロビン方式で巡回する（伝播優先順を参照）。どういう順序またはどれだけの頻度で待ち行列更新を送信するかを決定する他の方法も使用されることができ、例えば、
１．割合の変化が使用され、
２．特定のクラスの待ち行列名がより高頻度の更新のために標識付けされ、
３．データストリームの近くで待ち時間更新を増加させるため、「データストリームからの距離」カウンタが使用される。
【０６５０】
一定の期間、待ち行列メッセージが選択された宛先に送信されなかった場合、その選択された宛先は、そのノードの選択された宛先の一覧から削除される。この期間は、最初に宛先を確立するのに必要とされる全時間よりも少なくとも１桁大きい。適応的手法も使用され得る（先に説明された）。
【０６５１】
フロー制御
各ノードは、例えば、メッセージデータ、待ち時間、ＧＵＩＤ、選択された宛先など、他のノードおよび待ち行列へのコネクションに関する情報をサポートするのに使用される、様々な量のメモリ、１次ＲＡＭを有する。
【０６５２】
フロー制御のための必要情報の一例は、ノードＡはノードＢをメッセージの宛先として有するかどうかである。あまりに多くのデータでノードＢを過剰動作させることをノードＡに許さないことが重要である。
【０６５３】
フロー制御は、トークンのメカニズムを使用して動作する。ノードＢは、ノードＡがノードＢに送信可能なバイト数に対応する一定の数のトークンをノードＡに与える。ノードＡは、この数より多くのバイトを転送することは許されない。ノードＢは、利用可能なより多くの領域を有し、ノードＡが僅かなトークンしか得ていないことを認識した場合、より多くのトークンをノードＡに送信することができる。
【０６５４】
２つのレベルのフロー制御が存在する。第１のレベルは、ノード対ノードのフロー制御であり、第２のレベルは、待ち行列対待ち行列のフロー制御である。ノード対ノードのフロー制御は、ノードＡからノードＢに送信される任意のデータ（待ち行列およびシステムメッセージ）のバイト総数を制限するのに使用される。待ち行列対待ち行列のフロー制御は、同じ名前を有するノードＡの待ち行列からノードＢの待ち行列に移動するバイト数を制限するのに使用される。
【０６５５】
例えば、１０バイトの待ち行列メッセージが、ノードＡからノードＢに移動する場合、ノード対ノードのフロー制御では、１０トークンを要し、その特定の待ち行列に関する待ち行列対待ち行列のフロー制御でも、同様に１０トークンを要する。
【０６５６】
ノードＢは、最初にノードＡにトークンを与えるとき、ノードＡからのスループットを最大化するようそこから調整を始める開始時状態として、トークン残の総数を小さな数に制限する。
【０６５７】
ノードＢは、ノードＡに十分に高い「トークン残高」限界を与えていないことを、以下の２つの条件が満たされた場合に知る。
・  送信すべきより多くのメッセージがあるのに、トークンを使い尽くしてしまったので送信できないことを、ノードＡがノードＢに伝えた場合。
・  ノードＢがデータを送信すれば宛先はそれを受け入れるのに、ノードＢが「送信すべきデータなし」状態に遭遇している場合。
【０６５８】
ノードＡがより高い「トークン残高」限界を求めたが、ノードＢは「送信すべきデータなし」状態に達していない場合、ノードＢは、ノードＡの「トークン残高」限界を増やす前に、「送信すべきデータなし」状態になるのを待機する。
【０６５９】
ノードＢは、「トークン残高」限界がどうであれ、トークンを有する状態にノードＡを保つよう常に試みる。ノードＢは、それが見たメッセージのサイズをそれがノードＡに与えたトークン数から減算することによって、ノードＡが有するとノードＢが考えるトークンの数を把握している。ノードＢは、それがノードＡに割り当てた「残高限界」の５０％をノードＡが下回ったことを見出し、それがより多くのデータを受け入れることができる場合、さらなるトークンをノードＡに送信する。ノードＢは、その裁量で最大５０％ポイントまでノードＡにトークンを与えることができるが、そのポイントで動作しなければならない。
【０６６０】
さらなるトークンを割り当てると、ノードＡがデータを送信するのに利用可能なトークンの最大数に関するノードＢ側の情報に基づいた推定値にも影響がおよぶ。
【０６６１】
このトークン数は、ノードＡが有するトークン数についてのノードＢの情報に基づいた推定値に追加される場合、「トークン残高」限界を超過しない。この数は、ノードＢの待ち行列内のデータ量に応じて、より少なくすることもできる（後で説明される）。
【０６６２】
例えば、ノードＡがノードＢに送信できるようにネゴシエートしているノードＡとノードＢを考える。図４９は現在の状態を示している。
【０６６３】
ノードＢは、ノードＡに提供することを望むデフォルト割当数を生成する。次にノードＢは、その割当数（現在と最大の差）を含むメッセージをノードＡに送信する。メッセージは、最大限界が変更されるたびにインクリメントされるバージョン番号も含む。ノードＢがノードＡに送信するメッセージは、以下のようになる。
struct sQuotaUpdate [
// the version
unsigned integer                  uiVersion;
// the queue name or number (see previous)
sQNName                           qnName;
// how much additional quota is sent over
unsigned integer                  uiAdditionalQuota;
];
【０６６４】
ノードＡがより多くのデータを送信したいことを我々に伝える場合、我々が最大限界を調整するごとにノードＡが一度だけそれを行うように、我々はこれを行う。図５０は現在の状態を示している。
【０６６５】
ノードＡは、ノードＢに５バイトのメッセージを送信することを望む場合、十分な割当数を有していない。その場合、ノードＡは、「より多く送信したい」ことを伝えるメッセージをノードＢに送信する。ノードＡは、その後、現在のバージョンに一致するように「最後により多くを求めたバージョン」を設定する。これは、ノードＢが最初の要求に応じなかった場合に、ノードＡが繰り返しより多くの割当数を求めることを防止する。このメッセージは、以下のようになる。
struct sRequestMoreQuota [
// the queue name or number (see previous)
sQNName                              qnName;
];
【０６６６】
図５１はこの状態を示している。
【０６６７】
ノードＢは、その待ち行列にデータがないのに、その選択された宛先に送信できる場合、ノードＡの最大割当数限界を１００バイトに増加させる。ノードＢは、新しいバージョン番号とともに新しい割当数を送信する。図５２はこの状態を示している。
【０６６８】
ノードＡは、今では５バイトのメッセージを送信するのに十分な割当数を有している。メッセージが送信されるとき、ノードＡは、利用可能な割当数から５バイトを取り除く。メッセージがノードＢによって受信されると、ノードＢは、ノードＡが有するとそれが考える現在の割当数から５バイトを取り除く。図５３はこの状態を示している。
【０６６９】
ノードＡが割当数を使い尽くすか、送信すべきメッセージがなくなるかするまで、メッセージは流れ続けることができる。ノードＡが有するとノードＢが考える割当数が５０バイトを下回った場合、ノードＢは、即座に割当数更新を送信する。最大限界を変更しない割当数更新は、バージョンのインクリメントを引き起こさない。異なる待ち行列のための割当数更新は、一緒に行う（piggy back）ことができ、したがって、１つの割当数更新が送信される「必要がある」場合、ちょうど補充の必要がある他の割当数更新も同時に送信されることができる。これにより、１つの割当数更新を含むだけで送信される特別なメッセージの発生が少なくなる。
【０６７０】
一般に、システムメッセージも、それらの影響を小さくするため、データメッセージと一緒にピギーバックされることができる。
【０６７１】
待ち行列対待ち行列フロー制御のために「残高限界」を拡張するのと同じ手法が、ノード対ノードフロー制御にも適用される。
【０６７２】
「残高限界」はまた、小さいが一定の率（例えば毎秒１％）でシステムによって継続的に縮小される。これは、高容量環境で大きくなったが、今は低容量環境にあり、不必要に高い「残高限界」の時間経過に伴う自動補正を可能にする。この継続的縮小が「残高限界」を低くし過ぎた場合、（より多くのトークンを要求し、受信ノードが「送信すべきデータなし」状態に遭遇していれば、より多くが与えられる）先のメカニズムがそれを検出し、残高限界を再び増加させる。
【０６７３】
容量に余裕がない場合のフロー制御
送信するための割当数を他のノードに与えるとき、それらが受信ノードを「容量余裕なし」状態に移行させ、可能ならばそれをそこに留まらせるのに十分な割当数を与えられることが重要である。
【０６７４】
ノード上の待ち行列での待ち時間が、（ｍａｘ（［すべての選択された宛先の待ち時間］）−ｍｉｎ（［すべての選択された宛先の待ち時間］））を超えた場合、各着信データフローは、この最大待ち時間にわたって、それらの最大「残高限界」より多くの割当数を取得してはならない。
【０６７５】
これは、待ち行列が容量超過である間にそのソースから受信されたバイト数を記録する、受信側のフロー制御構造体に付加される「容量超過トークンカウント」変数を有することによって実施される。
【０６７６】
この数は、ノードが送信ノードにより多くの割当数を提供するようになったとき、「最大残高限界」から差し引かれる。
【０６７７】
待ち行列の待ち時間がその最大待ち時間を下回った場合、「容量超過トークンカウント」変数は０に設定される。
【０６７８】
容量超過の待ち行列からデータが取り除かれるとき、我々は、取り除かれたバイト数を取り集め、そのバイト総数をできるだけ均等に、０より大きいすべての「容量超過トークンカウント」変数から差し引く。「容量超過トークンカウント」は常に、０に等しいか、または０より大きいことが重要である。
【０６７９】
例えば、待ち行列から１２０バイトが取り除かれ、その待ち行列にデータを置いているコネクションが４つ存在し、それらの「容量超過トークンカウント」が０、１００、２０、５０である場合、我々は、バイト数（１２０）を０より大きい「容量超過トークンカウント」変数の数（３）で除算し、４０を得る。最低の「容量超過トークンカウント」変数は４０より小さい（２０）ので、我々は、その数（２０）をすべての「容量超過トークンカウント」変数から減算する。これにより、４つの変数は０、８０、０、５０となり、まだ６０バイトが残されている。我々は、このプロセスを繰り返し、残っている２つの「容量超過トークンカウント」変数から３０を減算し、０、５０、０、２０を得る。
【０６８０】
ＥＵＳ待ち行列のためのフロー制御
ＴＣＰ／ＩＰでは、ウィンドウサイズ選択は重要である。ＴＣＰ／ＩＰにおけるウィンドウサイズが小さ過ぎる場合、パフォーマンスが損なわれ、大き過ぎる場合、パフォーマンスを向上させることなく、システム資源が使い果たされる。
【０６８１】
本発明は、「送信側のみ（ｓｅｎｄ−ｓｉｄｅ  ｏｎｌｙ）」アルゴリズムを使用して、最良ウィンドウサイズへの速やかな収束を可能にする。
【０６８２】
標識付けされたデータストリームの一部であるノードは、それらが最大速度で送信できるよう保証するのに十分なデータだけをバッファする。これは、送信すべきギガバイトのデータが存在するとしても、比較的一定で小さい割合だけが、与えられた時間に送信中であることを意味する。
【０６８３】
しかし、（小さなメッセージ１つだけの代わりに）送信すべきギガバイトのデータが存在する場合、そのデータを転送するためにはるかに多くの経路が使用される。しかし、いかに多くの経路が使用されるにしても、送信中のデータの総量は、最終的な受信側によって最終的な送信側に与えられたバッファを超過しない。
【０６８４】
どのノードに送信するかを決定するのにノードが使用する主要なメトリックは待ち時間である。送信すべき１０００秒分のデータが残っている場合、宛先に対する待ち時間が１０００秒より小さいすべての経路が考慮されるべきである。非常に僅かな量のデータが存在し、それを送信するための待ち時間が１０ｍｓである場合、非常に少数の経路（および最速の１つ）がデータを転送するために使用される。
【０６８５】
これは、ノードが、最速のデータ転送を保証するために必要なだけ多数のノードまたは少数のノードを補充することを可能にする。この技法は、我々が、必要とされていない待ち時間をトレードオフすることによって、必要とされるときに暗黙のうちに帯域幅を増やすことを可能にする。
【０６８６】
送信中のデータ量は、送信ノードがその待ち行列に割り当てることができるバッファのサイズによっても制限される。送信バッファのための最良サイズは、その待ち時間が以下のようになる。
送信バッファ待ち時間＝＞Ｍａｘ（すべての選択された宛先の待ち時間）−Ｍｉｎ（すべての選択された宛先の待ち時間）
【０６８７】
これは、我々が選択された宛先一覧にノードを追加し続けることができるならば、最終的な送信側の送信バッファを拡張し続けることができることを意味する。
【０６８８】
メッセージを送信するＥＵＳを有するノードは、（フロー制御が働くのと同じ方法で）ＥＵＳが待ち行列を「容量余裕なし」に保つことができる点まで、この送信バッファが大きくなることを可能にすべきである。これは、すべての「選択された宛先」ができるだけ多く使用され得ることを保証する。
【０６８９】
最終的な受信側では、受信されたメッセージは、並べ直しバッファに配置される。ノードは順序を整えてこれらのメッセージを配置することができるので、メッセージは、ＥＵＳが処理するためにメッセージを待ち行列から取り出すのに使用する待ち行列に移される。この待ち行列取り出しバッファのサイズは、（フロー制御で説明された）ノード間の待ち行列バッファと同じ方法で設定される。
【０６９０】
ＥＵＳがメッセージを取り出すのに使用する待ち行列がその最大サイズを超過した場合、このノードは、それが「容量余裕なし」にあり、より多くの割当数を直接接続ノードに与えないことを、直接接続ノードに伝える。並べ直しバッファからの順序を整えられたメッセージは、ＥＵＳによって使用されるこの待ち行列に依然として配置されるが、このノードはこの待ち行列のための割当数を直接接続ノードにもはや与えていないので、並べ直しバッファへの着信メッセージフローは止められる。
【０６９１】
ＥＵＳが使用する待ち行列が完全に空になり、直接接続ノードがＥＵＳを有するノードにより多くのメッセージを送信することを望む場合、ＥＵＳが使用する待ち行列の最大サイズが、（フロー制御が働くのと同じ方法で）拡張される。
【０６９２】
この待ち行列のサイズは、フロー制御における待ち行列と同様に下方圧力の影響も受ける。
【０６９３】
並べ直しバッファのサイズは、ＥＵＳによって使用される待ち行列が保持できるメッセージ数（またはバイト数）には関係がない。
【０６９４】
受信ＥＵＳがメッセージの処理を完全に停止した場合、ネットワーク内のすべてのノードがその待ち行列に関して「容量余裕なし」に移行し、最終的な送信側は直ちに、ネットワークにメッセージを送り出すのに用いられる割当数をそれ以上与えられなくなる。
【０６９５】
伝播優先順
より大規模なネットワークでは、制御メッセージのための帯域制限が使用される必要がある。
【０６９６】
我々は、いくつかのタイプの制限を使用する。「制御」帯域幅の総計は、すべてのデータのために利用可能な最大帯域幅の何パーセントかに制限されるべきである。
【０６９７】
制御メッセージは、２つのグループに分割される。これらのグループは、最大帯域幅の何パーセントかに基づいて個々に帯域制限される。各直接接続ノードは、これら２つのグループのそれ独自のバージョンを有する。
【０６９８】
例えば、最小サイズを４Ｋとし、各グループに対して最大帯域幅の５％を指定することができる。単純な１０ＭＢ／ｓのコネクションでは、これは、４Ｋの情報パケットを
＝４０９６／（１０ＭＢ／ｓ×０．０５）
＝０．０８１９ｓ
ごとに送信することを意味する。
【０６９９】
そのため、このコネクションでは、各グループについて、制御パケットを０．０８１９ｓおきに、または毎秒約１２回送信することができる。
【０７００】
パーセンテージおよび送信されるブロックサイズは例であり、当業者によって各自のアプリケーション要件をより良く満たすように変更されることができる。
【０７０１】
第１の帯域制限グループ
第１の帯域制限グループは、以下のメッセージを送信する。以下のメッセージは、制御メッセージが適合するブロックサイズに適合するように一緒に連結されるべきである。
１．後続メッセージのために必要とされる待ち行列のための名前対番号マッピング
２．標準フロー制御メッセージ
３．ＧＵＩＤプローブ
４．ノードに今それが「選択された宛先」であるかどうかを通知する
５．ＨＳＰＰメッセージ
６．初期待ち行列知識／ＨＳＰＰ待ち行列の無限大へ／無限大から
７．初期待ち行列知識／非ＨＳＰＰ待ち行列の無限大へ／無限大から
【０７０２】
第２の帯域制限グループ
第２のグループは、待ち行列のための待ち時間更新を送信する。第２のグループは、待ち行列を３つのグループに分割し、これらのグループの各々を、互いに１：１：１に交互配置されるラウンドロビン方式で送信する。
【０７０３】
最初の２つのグループは、「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」の値を使用して、すべての待ち行列を順序付けることによって生成される。待ち行列が複数の選択された宛先を有する場合、最低待ち時間を有する「選択された宛先」が、どの「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」値を使用するかを決定するために使用される。
【０７０４】
待ち行列は、単一経路実施形態において先に説明されたのと同様の方式で、昇順に並べられる。待ち行列は、制限帯域幅を使用して２分の１秒でいくつの更新が送信され得るかに基づいて、２つに分割される。これは、第１のグループは頻繁に完全に更新され、残りは依然として更新はされても、頻度は低くなることを保証する。
【０７０５】
第３のグループは、このノードがデータストリーム内にある待ち行列から構成される。
【０７０６】
各待ち時間更新は、値「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」を含む。この値「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」は、３つのグループ各々の待ち行列に対して別々に計算される。この値は、グループ内のすべての項目を一度に送信するのにかかる時間として計算される。この値は、最低の「ｆＬａｔｅｎｃｙ」を有する選択された宛先の「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」に加算される。
【０７０７】
この値は、ＧＵＩＤプローブがどれだけ遠くまで進行するかを決定するときにも使用される。
【０７０８】
３つのグループの各々を送信するための時間は、現在の送信速度に基づいて継続的に更新されるべきである。
【０７０９】
待ち行列は、一度にこれらのグループの１つのメンバであることしかできない。これは重要であり、さもないと、「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」は計算が難しくなる。
【０７１０】
「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」は、データストリーム内の必ずしもすべてのノードが、それらの「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」を直接接続ノードに渡すときに、別のノードからの「ｆＬａｔｅｎｃｙＦｒｏｍＳｔｒｅａｍ」値を追加するわけではない点を除いて、「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」と同様に計算される。
【０７１１】
例えば、ノードＡがデータストリーム内にあり、特定の待ち行列が属するグループを更新するのにかかる時間が３秒である場合、ノードＡは、それがデータストリームから３秒であることをすべての直接接続ノードに伝える。代替として、ノードＡは、それがデータストリームから０秒であることをすべての直接接続ノードに伝えることもできる。
【０７１２】
待ち行列が高頻度更新から低頻度更新に移行する必要がある場合、我々は、その報告された「ｆＵｐｄａｔｅＬａｔｅｎｃｙ」待ち時間数を低頻度グループに合致するように変更するが、実際にそれを低頻度グループに移行する前に、３更新サイクルの間、高頻度グループの項目を保持する。
【０７１３】
ノードは、新しい待ち行列を知った場合、制限更新の第２のグループにおいてそれが属する３つのグループの１つの、更新すべき待ち行列の一覧の最後にその待ち行列を配置する。
【０７１４】
可能な用途
以下に示すのは、本発明が使用され得る例である。これらの例は、本発明の用途を限定する意図はない。
１．ネットワークトポロジが無制限の構造をとることを可能にする通信ネットワークで使用される。
２．移動セル電話を次の通信塔にハンドオフする必要がある現在の「セル」構造を必要としないセル電話ネットワークで使用される。
３．ホットスポットを除去し、障害ノードに対処することを助けるグリッドコンピューティング環境で使用される。
４．システム負荷管理を達成するために中央指令センタからオンまたはオフにすることができるすべての電気装置で使用可能なソフトウェアを有するユーティリティによって使用される。
５．柔軟で動的なメッセージ転送能力の欠如によって現在はアプリケーションが制限されるグリッドコンピューティング、大容量ストレージ、またはスーパーコンピューティング環境などの応用例のためのメッセージを交換するために、複数の相互接続ＣＰＵまたはコンピュータが結合されることを可能にする、コンピューティングにおいて使用される。
６．戦闘の現場にいるあらゆる兵士およびあらゆる機器が連続的に変化する地勢構造において常に通信を維持することを可能にし、除去、破壊、または追加される要素に関わりなくネットワークが継続することを可能にする軍事アプリケーションで使用される。
７．任意のグループが任意の時にそれ独自のネットワークを形成することを可能にする、より大規模なネットワークから孤立したまたはそのサブセットとしての離散ネットワークグループを形成するために使用される。
８．このソフトウェアおよび通信機能を備えた自動車がより大きな効率性もしくは安全性のためのハイウェイ対話またはハイウェイ交通管理機能を連携させることを可能にする交通管理で使用される。
９．交通の流れを管理する上でのより大きな効率性のためすべての交通信号が交通管理コンピュータおよび互いに通信することを可能にし、システムに対するどのようなソフトウェア管理も必要とせず交通信号がシステムに追加またはシステムから削除されることを可能にする交通信号の交通管理で使用される。
１０．ネットワーク内のあらゆる参加者がネットワーク全体および資源の総和へのリンケージを提供することができるので、仮想的に無制限の容量およびバックアップ資源を提供する共同体または地域のための通信ユーティリティとなることができる「マスタネットワーク」として使用される。
１１．人間の介入なく、またそれを行っている間に動作を縮小または停止することなく、ソフトウェアがマシンおよびアプリケーションを付け加えまたは取り去り、センタを管理および監視するコンピューティングセンタを管理するために使用される。
１２．このソフトウェアが発電、送電、および消費を統合するために使用され、所定の基準に基づいて決定を下し、即座に動作することによって、通常の変化および不都合な出来事に対処することができる電気エネルギーグリッド内で使用される。
１３．人間の介入なしにユーザおよびリモートサイトを動的に結合することによってリモートコンピューティングを可能にするために使用される。
１４．航空機、航空交通、および地上資源を管理し、連携させることによって航空交通制御で使用される。
１５．無線、地上線、衛星、コンピュータ、および機上システムなどの様々な通信技術を連携させ、ネットワーク接続するために使用される。
１６．交通パターン変化、経路宛先に対する追加または削除など変化する状況に対して動的に変更され得る、様々な宛先への商品の物理配送のための有効経路を生成するために使用される。
１７．特に多くの基準を含む複雑な問題に対する正確な解を見つけるために多数の連立計算を解くためのバイオコンピューティングに類似した数学的ツールとして使用される。
【０７１５】
本発明の上述の実施形態は、本発明の例として意図されており、添付の特許請求の範囲によってのみ確定される本発明の範囲から逸脱することなく、当業者によって変更および修正が施され得る。
【図面の簡単な説明】
【０７１６】
【図１】本発明の一実施形態によるネットワークの概略図である。
【図２】本発明の一実施形態によるネットワーク知識を広める方法を示したフローチャートである。
【図３】本発明の一実施形態による図２の方法の一ステップの実行を示したネットワークの概略図である。
【図４】本発明の一実施形態による図２の方法の一ステップの実行を示したネットワークの概略図である。
【図５】本発明の一実施形態による図２の方法の一ステップの実行を示したネットワークの概略図である。
【図６】本発明の一実施形態による図２の方法の一ステップの実行を示したネットワークの概略図である。
【図７】本発明の一実施形態による図２の方法の一ステップの実行を示したネットワークの概略図である。
【図８】本発明の一実施形態による図２の方法の一ステップの実行を示したネットワークの概略図である。
【図９】本発明の一実施形態による図２の方法の一ステップの実行を示したネットワークの概略図である。
【図１０】本発明の別の実施形態によるネットワークの概略図である。
【図１１】本発明の別の実施形態によるネットワークの概略図である。
【図１２】図１１のネットワークの別の概略図である。
【図１３】本発明の別の実施形態によるネットワークの概略図である。
【図１４】本発明の別の実施形態によるネットワークの概略図である。
【図１５】図１４のネットワークの別の概略図である。
【図１６】図１４のネットワークの別の概略図である。
【図１７】本発明の別の実施形態によるネットワークの概略図である。
【図１８】本発明の別の実施形態によるネットワーク知識を獲得する方法を示したフローチャートである。
【図１９】本発明の別の実施形態によるネットワークの概略図である。
【図２０】本発明の別の実施形態によるノード間でコネクションを確立するために情報を交換する方法を示したフローチャートである。
【図２１】本発明の別の実施形態によるノード間でコネクションを確立する方法の初期化プロセスを示したフローチャートである。
【図２２】本発明の別の実施形態によるノード知識を広める方法についての累積リンクコストの加法的特性を示したネットワークの概略図である。
【図２３】本発明の一実施形態によるノード知識を広める方法についてのノード知識のネットワーク内の流れを示したフローチャートである。
【図２４】本発明の一実施形態によるノード知識を広める方法についてのノード知識のネットワーク内の流れを示したフローチャートである。
【図２５】本発明の一実施形態によるノード知識を広める方法についてのノード知識のネットワーク内の流れを示したフローチャートである。
【図２６】本発明の一実施形態によるノード知識を広める方法についてのノード知識のネットワーク内の流れを示したフローチャートである。
【図２７】本発明の一実施形態による孤立コアを検出するための方法を示したネットワークの概略図である。
【図２８】本発明の一実施形態による、エミュレートされ得るプロトコルの一例としてＴＣＰ／ＩＰを使用するネットワークを介するルーティングのための方法を示したフローチャートである。
【図２９】ノードＢおよびノードＣに直接接続されたノードＡ、ノードＡだけに接続されたノードＣ、ならびに４つのノードＣに直接接続されたノードＢを示したネットワークの概略図である。
【図３０】本発明の一実施形態による待ち行列上のサービス時間がどのように計算され得るかを示したフローチャートである。
【図３１】本発明の一実施形態によるノードおよび待ち行列の構成を示したネットワークの概略図である。
【図３２】本発明の一実施形態によるネットワークを伝播する待ち行列についての知識を示す一連のステップを示した複数のフローチャートである。
【図３３】本発明の一実施形態による、ネットワークのあらゆるノードがＥＵＳ生成の待ち行列のことを知ったばかりの状態を示したネットワークの概略図である。
【図３４】ＥＵＳ生成の待ち行列を有するノードとの間の一方のコネクションが削除された図３３のネットワークの概略図である。
【図３５】ＥＵＳ生成の待ち行列を有するノードとのコネクションを失った直接接続ノードが待ち時間を無限大に設定した図３３のネットワークの概略図である。
【図３６】そのノードのすべての選択された宛先が無限大になった図３３のネットワークの概略図である。
【図３７】無限大に設定され得るすべてのノードが無限大に設定された図３３のネットワークの概略図である。
【図３８】無限大に設定されたあらゆるノードが一定の期間停止し、その後、無限大ではないそれが見出した最低待ち時間を選択した図３３のネットワークの概略図である。
【図３９】無限大だったノードが非無限大になって直ちに、それが直接接続されたノードに伝えた図３３のネットワークの概略図である。
【図４０】図３３〜図３９の概略図で概要を示された着信待ち時間更新を示したフローチャートである。
【図４１】無限大にある待ち時間を示したフローチャートである。
【図４２】最終的な送信側と最終的な受信側の間のノード上のデータストリームを示したネットワークの概略図である。
【図４３】回避されるべき潜在的ループの一例を示したネットワークの概略図である。
【図４４】ある期間にわたる待ち時間中央値を別の期間にわたる待ち時間最大値と比較したチャートを示した図である。
【図４５】待ち行列内のデータのバイト数を経時的に示し、また時間インターバル内の最小待ち行列レベルを示すグラフである。
【図４６】容量に余裕がないノードが、それが可能な追加の選択された宛先に送信したＧＵＩＤを見出したとき、その選択が悪い選択であったことを知る様子を示したネットワークの概略図である。
【図４７】「容量余裕なし」でないときに選択された宛先をいつ追加／削除するかを決定する方法を示したフローチャートである。
【図４８】データストリーム内にないノードにおいて偶然生成されたループを示したネットワークの概略図である。
【図４９】ノードＡがノードＢに送信できるようにネゴシエートするノードＡとノードＢを示したネットワークの概略図である。
【図５０】より多くのデータを送信したいことをノードＡがどのようにして通知するかを示したネットワークの概略図である。
【図５１】割当数が制限されている場合に２つのノードがどのようにしてメッセージの転送をネゴシエートすることができるかを示したネットワークの概略図である。
【図５２】割当数が制限されている場合に２つのノードがどのようにしてメッセージの転送をネゴシエートすることができるかを示したネットワークの概略図である。
【図５３】割当数が制限されている場合に２つのノードがどのようにしてメッセージの転送をネゴシエートすることができるかを示したネットワークの概略図である。
【図５４】コアに到るための各ノードの最良ネクストステップと、このプロセスが生成した階層をより良く示すために再配置された同じネットワークを示したネットワークの概略図である。
【図１】
2007523546.tif 000020
【図２】
2007523546.tif 000021
【図３】
2007523546.tif 000022
【図４】
2007523546.tif 000023
【図５】
2007523546.tif 000024
【図６】
2007523546.tif 000025
【図７】
2007523546.tif 000026
【図８】
2007523546.tif 000027
【図９】
2007523546.tif 000028
【図１０】
2007523546.tif 000029
【図１１】
2007523546.tif 000030
【図１２】
2007523546.tif 000031
【図１３】
2007523546.tif 000032
【図１４】
2007523546.tif 000033
【図１５】
2007523546.tif 000034
【図１６】
2007523546.tif 000035
【図１７】
2007523546.tif 000036
【図１８】
2007523546.tif 000037
【図１９】
2007523546.tif 000038
【図２０】
2007523546.tif 000039
【図２１】
2007523546.tif 000040
【図２２】
2007523546.tif 000041
【図２３】
2007523546.tif 000042
【図２４】
2007523546.tif 000043
【図２５】
2007523546.tif 000044
【図２６】
2007523546.tif 000045
【図２７】
2007523546.tif 000046
【図２８】
2007523546.tif 000047
【図２９】
2007523546.tif 000048
【図３０】
2007523546.tif 000049
【図３１】
2007523546.tif 000050
【図３２】
2007523546.tif 000051
【図３３】
2007523546.tif 000052
【図３４】
2007523546.tif 000053
【図３５】
2007523546.tif 000054
【図３６】
2007523546.tif 000055
【図３７】
2007523546.tif 000056
【図３８】
2007523546.tif 000057
【図３９】
2007523546.tif 000058
【図４０】
2007523546.tif 000059
【図４１】
2007523546.tif 000060
【図４２】
2007523546.tif 000061
【図４３】
2007523546.tif 000062
【図４４】
2007523546.tif 000063
【図４５】
2007523546.tif 000064
【図４６】
2007523546.tif 000065
【図４７】
2007523546.tif 000066
【図４８】
2007523546.tif 000067
【図４９】
2007523546.tif 000068
【図５０】
2007523546.tif 000069
【図５１】
2007523546.tif 000070
【図５２】
2007523546.tif 000071
【図５３】
2007523546.tif 000072
【図５４】
2007523546.tif 000073
【国際調査報告】
2007523546.tif 000074
2007523546.tif 000075
2007523546.tif 000076