JP4455772B2 - パケットメッセージング方法および装置 - Google Patents

Description

【０００１】
発明の属する技術分野
本発明は、パケットメッセージングの管理のための方法および装置に関する。本発明は、とくに小さいバンド幅リンク上での一定のクラスのパケットのメッセージングにおける最適な管理に応用される。
【０００２】
従来の技術
ソースエンティティが受信側エンティティへ通信リンク上でメッセージを送るときの多様な情況が知られている。この多様な情況の中には、ソースエンティティがそのメッセージを送る通信リンクが、受信側エンティティへ向けられるメッセージ量を運ぶにはバンド幅が不十分であるといった情況が含まれていることはよく知られている。
【０００３】
この問題に対する1つの明白な解決案は、単に、所与の時間に可能な限り多くのメッセージを送り、残りの‘オーバーフロー’メッセージを捨てることである。この解決案は、簡単であるという利点をもつが、通信リンクを効果的に利用することができない。アクティビティが突然バーストすることは、オーバーフローしたメッセージが捨てられながら、メッセージのフラッドに通じることになる。しかしながらアクティビティのバーストの後では、通信リンクはほんの僅かにロードされた状態に戻る。
【０００４】
改良された解決案では、オーバーフローメッセージのバッファリングを行う。したがってオーバーフローメッセージは、所定の時間に送られないときは、単に捨てられるのでなく、バッファに入れられ、アクティビティのバーストの後で、通信リンクがほんの僅かにロードされた状態に戻ったときに送られる。しかしながらメッセージのバッファの大きさは制限されていることは明らかであり、バッファ自体がオーバーフローすると考えられる。メッセージ間には実質的な差別がなく、全てのメッセージは等しい重要度をもつように取扱われることも明らかである。
【０００５】
異なるアプローチが一緒になって、メッセージが異なる重要度をもつと考えられるある種の環境に適用することができる。ソースエンティティと受信側エンティティとの間の通信リンク上で輻輳が発生するので、そのときは、より重要度の高いメッセージを通信リンク上で送ることができるが、より重要度の低いメッセージは上述のように、捨てられるか、またはバッファに入れられる。
【０００６】
単一のソースエンティティについてのこのようなアプローチの周知の例は、‘層構造化されたビデオコーディング’の概念である。このようなアプローチは同様に、多数の競合するソースエンティティへも応用でき、このときソースエンティティおよびそれぞれのメッセージはそれらの重要度にしたがって格（ランク）付けされる。
【０００７】
上述の情況とは若干異なる特徴をもつ問題は、むしろ、多数が競合していて、かつ重要度の等しい多数のソースエンティティの全てが同じタイプのメッセージを送るといった場合の問題である。多数のソースエンティティが、それらの情況のいくつかの観点（アスペクト、特徴点）についてのメッセージを送ることができる例である。例えば、移動するエンティティは、その位置についてのメッセージを送ることができる。同様に、センサエンティティは、周囲温度または圧力についてのメッセージを送ることができる。
【０００８】
より馴染みのある例には、(ID Software of Mesquite（TX, USA）によって製造された)‘Quake’のようなネットワーク形コンピュータゲームのものであり、いくつかのサーバコンピュータ上を走っている三次元のバーチャル環境内に動く創造物（creature）が生成されている。これらの創造物のソースエンティティの位置では、適切にサーバ(単数または複数)に接続されたクライアントコンピュータ上でホストとして働いているゲームエンティティへメッセージを送ることができる。
【０００９】
一般的に、このような周期的な状態更新メッセージを受け取るエンティティについて最も重要なことは、全てのソースエンティティから規則正しく更新を受け取ることを保証することである。多数のソースエンティティが状態更新に関するメッセージを送っているとき、一般的に、ソースエンティティのサブセットからの状態更新の全てと、残りの状態エンティティからの、もしあれば幾つかの状態更新とを受け取ることよりも、全てのソースエンティティから規則正しい状態更新を受け取ることがより重要である。いわば一般的に、全てのソースエンティティの平均の状態エラー（誤差）ではなく、ソースエンティティの最大の可能性のある状態エラーを抑制することがより重要である。
【００１０】
ここでもQuakeのようなゲームの例を使用するには、ゲームプレーヤのキャラクターが非常によく動く敵の創造物によって取り囲まれているとすると、ゲームのプレーヤのキャラクターにとってもっとも重要なことになりそうなのは、どこに関連の創造物の全てがあったか）を比較的小さなエラー（誤差）で知ることであって、創造物のサブセットが非常に小さな誤差の中であるか（どこに今創造物があるか）を知ることではなく、非常によく動く敵の創造物の残りのものの位置を比較的大きな誤差で（少し前にそれがどこにあったか）知るだけよりも重要である。
【００１１】
このような情況に対して、層構造化されたビデオコーディング方式のような簡単な階層構造を指向した方式を与えることができないことが明らかになるであろう。上述のように、このような方式では、全ての利用可能な情報は最も重要度の高いソースエンティティから要求することができ、その際には重要度の低いソースエンティティからは、もしあれば、僅かな情報を受け取ることを代償としており、これに対して、検討中の問題に関しては、各々が名目上同じ重要度をもっている全てのソースエンティティから少なくとも若干の情報が要求される。
【００１２】
発明が解決しようとする課題
したがって、本発明の第１の態様にしたがい、パケットメッセージソースであって：パケットメッセージのシーケンスの中の各パケットメッセージ内にそれぞれのパケットメッセージのペイロードを含むようにされている手段と；前記シーケンス内の各連続するパケットメッセージを優先度ラベルと、優先度ラベルの所定の巡回するシーケンスにしたがって関係付けるようにされている手段と；ただしここで前記優先度ラベルの各々は複数の優先度レベルの1つを表わしていて、また巡回するシーケンス内の各ラベルの位置は、シーケンス内の各ラベルについて、この優先度ラベルとそれ以上の高い優先度をもつシーケンス内の最も近い優先度ラベルとの間における連続するより低い優先度ラベルの数を最大化するものとし；このようなパケットメッセージを送るようにされている手段とを含むパケットメッセージソースを提供する。
【００１３】
これは、多数のこのようなパケットメッセージソースは、このようなパケットメッセージを送るが、バンド幅が制限されているために競わなけれなならず、その結果パケットが優先度ラベルにしたがって必要なときにドロップされるとき、全てのソースからの定期的な更新を表わす可能性のあるパケットメッセージを、受信側クライアントへ送ることができる限り、従来技術のように、ソースのサブセットからの全ての更新と、残りのソースからの、もしあれば、幾つかの更新とを送ることができることを保証することが好都合である。
【００１４】
加えて、パケットメッセージシステム、パケットメッセージング方法、およびパケットメッセージングシステム動作方法を提供する。
【００１５】
ここで本発明のいくつかの実施形態を添付の図面に関して例示的に記載することにする。
【００１６】
発明の実施の形態
ここで本発明の第１の実施形態を図１、２、３、および４に関連して記載することにする。図１は、本発明の第１の実施形態のアーキテクチャ（構造）を模式的な形態で示している。図４は、この第１の実施形態の機能の手続きのフローチャートを示す。
【００１７】
各々が関係付けられた状態をもっているソースエンティティの第１のグループに属する各々は、そのものの現在の状態に関する情報を含むパケットメッセージを作成して、送る。メッセージが送られる宛先のエンティティについては後で記載する。ソースエンティティは多様な形態をとることができ；このような形態の１例は、コンピュータ上のソフトウエアプロセス内でホストとして働いているエンティティである。
【００１８】
したがって図１は例示的に、ソースエンティティ100のグループが、第１のサーバコンピュータ104における第１のソフトウエアプロセス102内でホストとして働いていることを示している。
【００１９】
このようなコンピュータ104は図２に示されており、一般に、少なくとも1つの中央処理ユニット（central processing unit, CPU）202、読取り専用メモリ（read-only memory, ROM）204、ランダムアクセスメモリ（random-access memory, RAM）206、ハードディスクのような記憶デバイス208、フロッピーディスクドライブのような記憶媒体の読み取りおよび書き込み用デバイス210、並びに他のデバイスまたは通信ネットワークへ接続するための入力および出力ポート212をもつ。
【００２０】
コンピュータ104は適切なオペレーティングシステムを使用し、その周知の例にはMicrosoft Windows（商標）NT、Linux、またはUnixの１つの他の多くのバージョンである。アプリケーションプログラムは、アプリケーションプログラムを書くための多くの周知の適切な言語の何れかで書くことができ、その1つの周知の例はＣ＋＋である。このようなオペレーティングシステムおよびアプリケションプログラムは、コンピュータ104の記憶デバイス208上へロードされる。
【００２１】
本発明の実施形態にしたがって記載された機能の態様（アスペクト）は、コンピュータ104によって実行されるソフトウエアアプリケーションプログラムとして構成される。このソフトウエアアプリケーションプログラムは、適切なコンピュータの読取り可能な記憶媒体の形態で、例えばフロッピーディスク214上に記憶され、実行において、フロッピーディスクドライブ210を介して、コンピュータ104へロードすることができる。別の周知の代わりの例では、ＣＤ−ＲＯＭ（図示されていない）上にソフトウエアアプリケーションを記憶し、実行において、ＣＤ−ＲＯＭドライブ（図示されていない）を介してコンピュータ104へロードする。別の周知の例では、コンピュータ104によって実行するために、適切なネットワーク（図示されていない）上でソフトウエアアプリケーションプログラムをダウンロードする。
【００２２】
この実施形態において、コンピュータ104はソフトウエアアプリケーションプログラムをロードされており、このソフトウエアアプリケーションプログラムが実行されると、コンピュータ104はソースエンティティのホストとして動作する。
【００２３】
しばしば、このようなサーバコンピュータは２以上あることになる。したがって第２のグループのソースエンティティ100’が第２のサーバコンピュータ104'上の第２のソフトウエアプロセス102'においてホストとして働くことが図示されている。
【００２４】
上述のQuakeの例に関して、ソースエンティティは、例えば三次元のバーチャル環境に存在している創造物であり、バーチャル環境の異なる部分はサーバコンピュータ上のプロセスとして実行される。簡単な例によって、バーチャル環境の１つの部屋の中の創造物のグループは、第１のサーバコンピュータ上のプロセス内で実行されるソースエンティティによって表わされ、バーチャル環境の別の部屋の中の創造物の別のグループは、第２のサーバコンピュータにおける別のプロセス内で実行されるソースエンティティによって表わすことができる。
【００２５】
既に記載したように、各ソースエンティティ100は関係付けられた状態をもち；この例では各キャラクターはバーチャル環境内に少なくとも関係付けられた位置をもつ。したがって、各キャラクターは三次元のバーチャル環境内で動きまわり、三次元のバーチャル環境内のそれぞれの現在の位置についてのメッセージを作成して、送ることができる。
【００２６】
このようなパケットメッセージの構造の例を図３に示した。従来のように、パケットメッセージ300はヘッダ部分302およびペイロード部分304の両者をもつ。本発明の全ての実施形態においてパケットヘッダ302内の全てのフィールドが同時に要求されるわけではないことに注意すべきである。
【００２７】
パケットヘッダ302内の第１のフィールド306は、ソースエンティティの識別子の指標を含む。パケットヘッダ302内の第２のフィールド308は、意図された宛先のエンティティの識別子の指標を含む。この第1の実施形態では、1つのみの宛先に関してこのフィールドを設定する必要はない。パケットヘッダ302内の第３のフィールド310は、所与の優先度の等級において、割り当てられた優先度の指標を含む。
【００２８】
本発明にしたがって、優先度設定を識別する第３のフィールド310は次のように設定される。各個々のパケットメッセージは、各々が複数の優先度レベルの１つを表わす優先度ラベルを割り当てられている。連続するパケットは、各パケットメッセージソースによってシーケンスで生成されたと考えられており、所定の巡回するラベルのシーケンスにしたがってこれらの優先度ラベルの１つを割り当てられる。この巡回するシーケンス内の各優先度ラベルの位置は、シーケンス内の各ラベルについて、この優先度ラベルとシーケンス内のそれ以上の優先度をもつ最も近い優先度ラベルとの間において連続するより低い優先度ラベルの数を最大化することが非常に重要である。
【００２９】
したがって巡回する優先度は、パケットが優先度に基いて捨てられたとすると、観念上のシーケンス内の残りのパケットは、元のシーケンスについては可能な限り等しく空間を空けられるように変化する。２の冪であるシーケンスの長さはこの点において有益であることが分かるであろう。
【００３０】
優先度の等級が０（最低優先度）ないしｎ（最高優先度）である簡単な例について、ｎ＝７のとき、優先度における対応する適切な巡回する変化は、それぞれ０、７、２、４、１、６、３、および５において設定された優先度をもつ（時間的に等間隔の）８個のメッセージのシーケンスである。０、７、２、４、１、６、３、５のシーケンスは、連続する低い優先度をドロップしなければならないので、残りのパケットが可能な限り等しく間隔を空けられることを確実にする。例えば、パケットは、２倍のリンク容量のトラヒックロードが原因となって、８個のメッセージのこのようなシーケンスから半分のパケットをドロップしなければならないとき（したがって[],7,2,4,1,6,3,5、次に[],7,2,4,[],6,3,5、次に[],7,[],4,[],6,3,5、最後に[],7,[],4,[],6,[],5になる）、残りのパケットは依然として時間的に等間隔であり、元のシーケンスの場合のように全ての時間的な期間ではなく、各２つの時間的な期間を適切に更新することが分かる。
【００３１】
パケットヘッダ302内の第４のフィールド312は、いわゆる活動時間の指標を含む。活動時間は、所与のリンクホップ数として示されているのではなく、例えば百ミリ秒の組まで含む所与の時間期間として示されていることが、パケットネットワークでは多い。第１の実施形態では、このフィールドは設定されない。
【００３２】
パケットヘッダ302内の第５のフィールド314はペイロードのタイプを示している。ペイロードのタイプは、例えば位置の指標についてのものであってもよい。第１の実施形態では、このフィールドは設定されていない。
【００３３】
パケットのペイロード部分304はデータを保持している。この例では、一般的なペイロードは位置の指標である。
【００３４】
図４Ａに関して、第１の段階400では、ソースエンティティは、パケットのペイロード内で位置の更新を実行し、パケットヘッダの第４のフィールド内で優先度を巡回的に変化しているパケットメッセージ流を作成して送る。
【００３５】
図１を参照すると、第１および第２のサーバコンピュータ104、104'は、それぞれ第１および第２のサーバコンピュータの出力ポート106、106'をもつ。これらのそれぞれの第１および第２のサーバコンピュータの出力ポート106、106'はそれぞれの第１および第２の大きいバンド幅リンク108、108'によって通信リンクインターフェイス、すなわちリンク管理コンピュータ110へ接続される。このような大きいバンド幅リンク108、108'は、概して、例えばファーストイーサネット（Fast Ethernet）の形態をとり、例えば毎秒１００メガビットの関係するバンド幅をもつ。
【００３６】
リンク管理コンピュータ110は、図２に示したように汎用コンピュータの形態をとっていてもよい。リンク管理コンピュータ110は適切なオペレーティングシステムを使用することができ、その周知の例にはMicrosoft Windows（商標）NT、Linux、またはUnixの他の多くのバージョンの１つがある。アプリケーションプログラムは、アプリケーションプログラムを書くための多くの周知の適切な言語で書くことができ、この言語の１つの周知の例はＣ＋＋である。このようなオペレーティングシステムおよびアプリケーションプログラムは、コンピュータ110の記憶デバイス208上へロードすることができる。
【００３７】
本発明の実施形態にしたがって記載された機能は、リンク管理コンピュータ110によって実行されるソフトウエアアプリケーションプログラムとして実行することができる。このソフトウエアアプリケーションプログラムは適切なコンピュータ可読記憶媒体の形態で、例えばフロッピーディスク214上に記憶され、実行のために、フロッピーディスクドライブ210を介して、コンピュータ110へロードされる。周知の代わりの例では、ＣＤ−ＲＯＭ（図示されていない）上へソフトウエアアプリケーションを記憶し、実行のためにＣＤ−ＲＯＭドライブ（図示されていない）を介してコンピュータ110へロードする。別の周知の代わりの例では、コンピュータ110による実行のために、適切なネットワーク（図示されていない）上でソフトウエアアプリケーションプログラムをダウンロードするものである。
【００３８】
リンク管理コンピュータ110は、少なくとも１つの入力ポート112をもち、これを介してリンク管理コンピュータはソースエンティティによって送られるパケットメッセージを受け取る。この例では、２つのサーバコンピュータ104、104'において、第１および第２のリンク管理コンピュータ入力ポート112、112'が示されている。これらの第１および第２のリンク管理コンピュータの入力ポート112、112'は、ソフトウエアレベルで分けられている別々の物理ポートまたは共有の物理ポートの何れかであってもよいことが分かるであろう。
【００３９】
第２の段階402において、第１および第２のサーバコンピュータ104および104'においてホストとして働いているソースエンティティによって送られるパケットメッセージは、それぞれの第１および第２のサーバコンピュータ出力ポート106、106'、第１および第２のファーストリンク108、108'、並びに第１および第２のリンク管理コンピュータ入力ポート112、112'を介してリンク管理コンピュータ110へ送られる。それぞれのサーバコンピュータとリンク管理コンピュータとの間のリンクのバンド幅は十分に大きく、ソースエンティティによって送られるパケットメッセージは、別のダウン流の遅延と比較すると小さくて取るに足らない程度の遅れを伴い、リンク管理コンピュータへ送られる。
【００４０】
この実施形態では、リンク管理コンピュータ110はソフトウエアアプリケーションプログラムをロードしており、このソフトウエアアプリケーションプログラムが実行されると、リンク管理コンピュータはリンクマネージャプロセス114を実行する。手続きのフローチャートの適切な段階は、ソフトウエアアプリケーションプログラムを実行することによって行われる。
【００４１】
第３の段階404では、リンクマネージャプロセス114は、第１および第２のリンク管理コンピュータ入力ポート112、112'に到達するパケットメッセージを受け取る。第４の段階406では、リンクマネージャプロセス114は、受け取ったパケットのパケットヘッダ302の第４のフィールドから優先度設定を読み取る。
【００４２】
第５の段階408では、リンクマネージャプロセス114は、第１および第2のリンク管理コンピュータ入力ポート112、112'に到達したパケットメッセージを、優先度で順序付けられた簡単な分類されたライナパケットの待ち行列116へ分類する。パケットメッセージは、例えば、同じ優先度設定をもつパケットメッセージのグループの後部において待ち行列116へ分類される。代わりの例によって、同じ優先度設定をもつ簡単なシーケンス116の一部分は単に、各優先度設定において別個の待ち行列として、最適化された構成において、容易に待ち行列へ入れることができることが分かるであろう。
【００４３】
別の段階（図示されていない）において、パケットシーケンス116の長さは検査され、所定の制限された待ち行列の長さを越えて待ち行列116の長さを増すように分類されたパケットメッセージは捨てられることが分かるであろう。
【００４４】
リンク管理コンピュータ110はさらに、少なくとも1つの出力ポート118をもつ。
【００４５】
リンク管理コンピュータ110の出力ポート118は、既知のサービス品質、とくに既知のバンド幅をもつリンク120によって、例えば受信側エンティティのホストコンピュータ124の入力ポート122へ接続される。リンクマネージャプロセス114が、優先度の待ち行列116のヘッドのパケットメッセージをリンク管理コンピュータ出力ポート118へ送るとき、メッセージは通信リンク120上で受信側エンティティのホストコンピュータ124へ送られ、次にこれはメッセージを受信側エンティティ（図示されていない）へ送ることができる。
【００４６】
図４Ｂに関して、段階410では、リンクマネージャは、シーケンス116のヘッドのパケットメッセージを送るための予備の容量が低バンド幅リンク上にあるか否かを知るために試験する。予備の容量があるときは、別の段階412において、リンクマネージャプロセス114が、優先度の待ち行列116のヘッドのパケットメッセージをリンク管理コンピュータ出力ポート118へ送り、リンク120上へ出力する。予備の容量がないときは、段階410が反復される。パケットメッセージのインテリジェントな選択は、巡回する優先度方式により本発明のリンクマネージャにおいて効果的に行われ；リンクにオーバーロードすると、単にランダムなパケットメッセージの損失の戻りを生成し、したがって本発明の効果は失われる。
【００４７】
シーケンス116のヘッドにあるパケットメッセージの送信はループプロセスを含むことが分かるであろう。待ち行列のパケットメッセージの現在のヘッドが送られてしまい、待ち行列のパケットメッセージの次のヘッドを送る試みをする前まで、リンクマネージャプロセス114は待機しなければならない。これは例えば、リンクマネージャプロセスと一緒に達成できて、待ち行列116のヘッドのパケットメッセージの大きさを確認し、この大きさは次に、リンク120のバンド幅の知識と共に、待ち行列のパケットメッセージのヘッドが送信にどのくらいの時間がかかるかを計算（コンピュータ処理）するのに使用することができる。代わりの例によると、送信するパケットメッセージはバッファから送り出されられ、先行するパケットメッセージがバッファをクリアするまで、次のパケットメッセージをバッファに書き込むことはできない。
【００４８】
典型的な小さいバンド幅のリンク120は、例えば、公衆交換電話ネットワーク（Public Switched Telephone Network, PSTN）接続上の３３．６キロビット／秒のモデムリンクであるか、または１２８キロビット／秒の統合サービスディジタルネットワーク（Integrated Services Digital Network, ISDN）接続である。
【００４９】
例示的に、受信側エンティティのホストコンピュータ124は、ソースエンティティによって送られるメッセージを受け取ることを意図されたエンティティのホストとして働くプロセスを実行することができる。しかしながら、受信側エンティティのホストコンピュータの代わりに、受信側エンティティは多様な形態をとることができ、コンピュータ処理上可能な形態、例えば簡単なデータメモリの形態をとる必要はないことが分かるであろう。
【００５０】
所定の時刻にリンク管理コンピュータ110によって受け取られるパケットメッセージのトラヒックの全バンド幅が、通信リンク120の既知の小さいバンド幅よりも小さい限り、リンクマネージャプロセスの待ち行列116内に置かれた全てのパケットメッセージは、待ち行列の遅延なしにリンク120上へ送り出される。受信側エンティティは全てのソースエンティティから送られる全てのパケットメッセージを、（ネットワークの遅延のみから発生する）最低可能遅延で受け取る。
【００５１】
しかしながら、アクティブになるソースエンティティ100、100'の数が増加するのにしたがって、対応してメッセージ流の数も増加してもよい。その代わりに、ソースエンティティ100、100'自体がよりアクティブになり、状態更新メッセージの周期性に対する必要は低減することになる。何れの場合においても、パケットメッセージのトラヒック量が増加するのにしたがって、到来するパケットメッセージのトラヒックの全バンド幅が通信リンク120のバンド幅を超える地点に到達する。この地点において、受信側エンティティへ向けられた全てのパケットメッセージを同時に送る必要はない。
【００５２】
ここでリンクマネージャプロセス114は、既に記載したように、パケットメッセージを優先度に基いて順序付け、待ち行列へ入れ始める。新しいパケットメッセージは、リンク管理コンピュータ110へ到達するとき、パケットヘッダ302内に実行された優先度設定に適した待ち行列の選択肢へ分類されることになる。
【００５３】
ソースエンティティ100、100'から送り出されるパケットメッセージのシーケンスの巡回する優先順位の設定に関して再び検討することにする。上述では２倍のリンク容量で実行されるトラヒックロードをもつリンク上で送信するパケット選択の管理についての例を既に記載した。半分のパケットが、２倍のリンク容量をもつトラヒックロードのためにフォーム０、７、２、４、１、６、３、５の巡回する優先度のシーケンスをもつ８個のメッセージのシーケンスからドロップされる（したがって[],7,2,4,1,6,3,5、次に[],7,2,4,[],6,3,5、次に[],7,[],4,[],6,3,5、最後に[],7,[],4,[],6,[],5になる）とき、残りのパケットは依然として時間的に等間隔であり、元のシーケンスのように全ての時間的な期間ではなく、各２つの時間的な期間を適切に更新することが分かる。
【００５４】
したがってリンクマネージャプロセス114が優先度にしたがってパケットメッセージを待ち行列へ入れ始めるとき、上述の例に類似した巡回する順序で、より高い優先度のメッセージを送る一方で、効果的により低い優先度のメッセージをドロップする（または待ち行列へ入れる）ことを始める。このやり方では、本発明の実施形態にしたがうリンク管理コンピュータ110は、次第に輻輳を増すリンク120を伴いながら、全てのソースエンティティ100、100'から規則的な更新を送り続けることができる。もちろん、これらの更新は規則的に行われ続ける一方で、小さいバンド幅リンク120の輻輳が増加する頻度は次第に低減するが、このように次第に頻度が低減することは、サービスについてのデグラデーション（劣化）が行われている恩恵的な方法（グレースフルマナー）示す。
【００５５】
この第１の実施形態における振舞いを、比較結果が類似している図１０および１１に示した第３の実施形態の振舞いに関して次に記載する。
【００５６】
ここで本発明の第２の実施形態を、図１、２、３、５、６、７、および８に関して記載することにする。この第２の実施形態は、ソースエンティティ100、100'によって送られるパケットメッセージ300の構造およびリンクマネージャプロセス114の機能に関して第１の実施形態と異なり、したがって適切な図１、２、および３を再び参照する。図５および６は、本発明の第２の実施形態の機能について特徴となっている手続きのフローチャートを示す。ここでも手続きのフローチャートの適切な段階は、リンク管理コンピュータ110上を走行するソフトウエアアプリケーションプログラムの実行にしたがって行なわれる。
【００５７】
本発明の第２の実施形態によると、とくに図１および２に関して、ソースエンティティ100、100'は次の構造でパケットメッセージ300を送る。パケットヘッダ302内の第１のフィールド306は、送信側のソースエンティティの識別子と共に送られる。宛先エンティティを識別しているパケットヘッダ302内の第２のフィールド308は、この例では1つの宛先エンティティのみが存在するので、設定される必要はない。
【００５８】
優先度設定を識別している第３のフィールド310は、第１の実施形態のように設定される。各個々のパケットメッセージは、例えば０（最も低い優先度）ないしｎ（最も高い優先度）の等級で設定された優先度を割り当てられる。ここでも本質的に、ｎ＋１のこのようなメッセージのシーケンスは、問題となっている当ソースエンティティに割当てられた固定優先度ではなく、巡回して変化する優先度で、ソースエンティティから送り出される。巡回する優先度は、パケットが優先度に基いて捨てられるとき、シーケンス内の残りのパケットが可能な限り均等に間隔を置くように変化する。
【００５９】
ここでも、簡単な例において、ｎ＝７のとき、優先度における対応する適切な巡回する変化は、優先度をそれぞれ０、７、２、４、１、６、３、および５に設定された８個のメッセージのシーケンスである。既に示したように、０、７、２、４、１、６、３、５のシーケンスは、連続する低い優先度のパケットのメッセージがドロップされるとき、残りのパケットメッセージに、元のシーケンスについて可能な限り均等にスペースを空けることを保証する。
【００６０】
第２の実施形態において、第４のフィールド312は活動時間の期間で設定される。全てのソースエンティティが同じパケットメッセージ送信の周期性をもつ必要があるのではなく、活動時間の指標を変化させることにより、各ソースエンティティが自身の周期性を設定できることが分かるであろう。例えば、この性質の結果、所与のソースエンティティは、各２０の公称の時間期間の更新を送ることのみが必要であり、この場合に活動時間の期間を２０の公称の時間期間に設定することができる。このような２０の公称の時間期間の後で、所与のソースエントリは新しい更新を送り出し、より古い更新は捨てられる。
【００６１】
この第２の実施形態では、パケットのペイロードのタイプを示すパケットヘッダ302内の第５のフィールド314は設定されない。
【００６２】
巡回する優先度の設定をもっている、このようなパケットメッセージの流れは、既に記載したように、ソースエンティティ100、100'から送り出される。これらのパケットメッセージは、それぞれ第１および第２のサーバコンピュータ出力ポート106、106'および第１および第２のリンク108、108'を介して、リンク管理コンピュータ110へ送られる。
【００６３】
図５に関して、第1の段階500において、これらのパケットメッセージは、第１および第２のリンク管理コンピュータ出力ポート112、112'において受け取られた後で、リンクマネージャプロセス114へ送られる。
【００６４】
リンクマネージャプロセス114は、第１の実施形態において優先度が順序付けられたように、ここでも簡単なパケットメッセージの待ち行列を維持する。
【００６５】
リンクマネージャプロセス114には、周期的に測定されるローカルな時間、例えばミリ秒を維持し続けるクロック（図示されていない）が用意されている。第２の段階502において、リンクマネージャプロセス114は、それぞれのパケットヘッダ302の第４のフィールド312において設定された活動時間を読み取り、第３の段階504において、ソースエンティティによって割り当てられた活動時間のラベルへローカルなクロック時間を加えて、調整された活動時間を生成する。第４の段階506において、この調整された活動時間は、パケットヘッダ302の第４のフィールド312へ書き込まれる。
【００６６】
または、代わりの例として、パケットメッセージおよび関係する到達時間は待ち行列116内に一緒に記憶できることが分かるであろう。これは、ソースエンティティ上に設定された活動時間を書込まないという長所をもつが、待ち行列のメモリを対応して大きくすることが要求されるという欠点をもつ。
【００６７】
所与のパケットメッセージが経験する唯一の有意な遅延は、この所与のパケットメッセージが待ち行列内に保持されることによって生成されることが分かるであろう。もしここで、上述の例によって、所与のパケットメッセージが、２０の公称のユニットの活動時間の指標をもつリンクマネージャプロセス114によって受け取られ、リンクマネージャプロセスのローカル時間がｔ＝１００の公称のユニットであるとすると、パケットヘッダの第４のフィールドへ書込まれた調整された活動時間は１２０の公称のユニットとなる。このパケットメッセージが２０以上の公称のユニットの生存期間の間、待ち行列へ入れられ、この時間期間においてリンクマネージャプロセスのローカル時間がｔ＝１２０の公称のユニットであるとすると、パケットメッセージがタイムアウトとならなければならず、この理由は後で記載する。このときまでに、ソースエンティティは別のパケットメッセージを送り、リンクマネージャプロセス116はこれを受け取っている。
【００６８】
第５の段階506において、リンクマネージャプロセス114はさらに、各パケットヘッダ302の第３のフィールド310内の各優先度設定を読み取り、次に第６の段階510において、優先度設定に基いて順序付けられた簡単な待ち行列116へパケットメッセージを分類する。ここでも、パケットメッセージは、例えば、同じ優先度設定をもつパケットメッセージのグループの後ろの待ち行列116へ分類される。既に記載したように、代わりの例として、同じ優先度設定をもつ簡単な待ち行列116の一部分を個別に待ち行列へ入てもよい。
【００６９】
図６に示したプロセスは、図５に示したプロセスと並行して実行されることが分かる。
【００７０】
図６に関して、第１の段階600において、各新しいパケットメッセージが、待ち行列116のヘッドへ移動して、リンク120へ送るとき、リンクマネージャプロセス114は再び、待ち行列116のヘッドにおいてパケットメッセージのパケットヘッダ302の第４のフィールド312から調整された活動時間のラベルを読み取る。
【００７１】
第２の段階602において、リンクマネージャ114は、この調整された活動時間とリンクマネージャプロセスのローカル時間とを比較する。第３の段階604において、リンクマネージャプロセスのローカル時間がパケットメッセージの調節された活動時間を経過してしまったとすると、パケットメッセージはタイムアウトであるとみなされなければならず、リンクマネージャプロセス114によって捨てられる。しかしながらリンクマネージャプロセスのローカル時間がパケットメッセージの調整された活動時間を経過していなかったときは、パケットメッセージは割り当てられた活動時間以上に長くは待ち行列へ入れられず、次に第４の段階606において、リンク上を、リンク管理コンピュータ118の出力ポートを介して、クライアント120における受信側エンティティへ送られる。リンクマネージャプロセス114は再び、第１の実施形態のときと同様に、これを行う際に、優先度の待ち行列116のヘッドにおいてパケットメッセージを送る容量についてリンク120を試験する。
【００７２】
小さいバンド幅のリンクで使用されるバンド幅を最適に使用するために、ヘッダ圧縮段階（図示されていない）を行なうことが分かるであろう。パケットメッセージが小さいバンド幅のリンク120上を送られる、例えば優先度設定が取除かれるために、ヘッダ302の一部分は最早必要なくなる。
【００７３】
第１の実施形態に関して言うと、リンク管理コンピュータ110によって受け取られるパケットメッセージトラヒックの瞬間的な全バンド幅が通信リンク120の既知の（小さい）バンド幅よりも小さい限りは、リンクマネージャプロセスの待ち行列116内に置かれた全てのパケットメッセージは待ち合わせ遅延（queuing delay）なしにリンク上へ送り出される。受信側エンティティ124は全てのソースエンティティ100、100'から送られた全てのパケットメッセージを受け取る。しかしながら、再び第１の実施形態に関して、パケットメッセージのトラヒック量が増加するときに、到来するパケットメッセージのトラヒックの全バンド幅が通信リンク120のバンド幅を超える地点に到達する。この地点において、受信側エンティティへ向けられた全てのパケットメッセージを同時に送り出すことは最早できない。
【００７４】
本発明の第２の実施形態は、全トラヒックのバンド幅が、小さいバンド幅のリンクの容量を越えるときにサービスの最適のグレースフルデグラデーションを送り出すことができる巡回する優先度設定に関して、本発明の第１の実施形態の全ての長所を備えている。しかしながら本発明の第２の実施形態は、第１の実施形態における振舞いに関して、これから記載するように、さらに別の長所を備えている。
【００７５】
各メッセージに対する活動時間の割当ては、誤りのあるメッセージの再順序付けを次のように避けることができる。
【００７６】
第１の位置パケットメッセージは、０の優先度設定で公称ｔ＝０において所与のソースエンティティから送られる。第２のパケットメッセージは、７の優先度設定で公称ｔ＝１で送られる。第３のパケットメッセージは、２の優先度設定で公称ｔ＝２において送られる。小さいバンド幅のリンク120上での輻輳度によって、第１のパケットメッセージが、０の最低優先度設定で、それが受け取られたときにリンクマネージャプロセス114によってリンク上を送られないときは、代わりに待ち行列へ入れられる。第２および第３のパケットメッセージの受信の際に、それぞれ７および２の優先度設定で、リンクマネージャプロセス114は第２および第３のパケットメッセージを、小さいバンド幅リンク120上を受信側エンティティのホストコンピュータへ真っ直ぐに送る。小さいバンド幅のリンク120上の輻輳は緩和され、第１のパケットメッセージが制限された活動時間をそれと関係付けなかったときは、リンクマネージャプロセス114は小さいバンド幅リンク上で第１のメッセージを受信側のホストコンピュータへ送る。
【００７７】
リンクマネージャプロセス114がこのように実行されると、実際にはクライアントによって受け取られる最新の位置更新メッセージは、クライアントによって既に受け取られた第２および第３のメッセージによって送られる位置の更新の前に１または２の時間期間から日付けを入れられることになる。その代わりに、メッセージに対する活動時間の設定により、メッセージが小さいバンド幅リンク120上を送られる前に、リンクマネージャプロセスの待ち行列116からメッセージを捨てる。
【００７８】
上述のように、パケットは伝送される前に、待ち行列へ入れられることによって、最長の遅延、実際には唯一の有意な遅延を、経験することが分かるであろう。活動時間のラベルは、上述のようにパケットメッセージを誤って再び順序付けることを防ぐ長所とは別に、さらに待ち行列メモリの管理をより全体的に補助する。パケットメッセージの待ち行列116は、例えば、待ち行列116が一定の所定の長さに到達したときは一掃（スイープ）される。さもなければタイムアウトパケットメッセージによって占められたメモリスペースを空けてもよい。しかしながら各パケットの送信側におけるタイムアウトを検査することも依然として必要である。その代わりに、待ち行列116を、この一定の長さに到達する前に一掃してもよい。したがって一定の長さよりも短い待ち行列116内で生き続けているタイムアウトしたパケットによってメモリスペースを空ける。
【００７９】
リンクマネージャプロセスによる小さいバンド幅リンクの管理に対するこのアプローチの成果は、巡回する優先度設定を活動時間の設定と組合せて、図７および８と関連付けて詳しく示し、記載することにする。
【００８０】
シミュレーションを次のように記載した。‘サーバ’プロセスは単一のＰＣ上に、各々が位置状態を保持している少数の最初のエンティティと共に設定された。‘クライアント’プロセスは、同じ機械上に同一の状態で設定され、‘サーバ’プロセスと‘クライアント’プロセスの２つは、２８．８キロビット／秒のＵＤＰ／ＩＰリンクおよび（単にサーバからクライアントへパケットを戻す）‘リフレクタ（reflector）’機械を介して接続される。
【００８１】
サーバは全てのエンティティをランダムな方向に一定のレートで、かつ各エンティティごとに一定の周期性（したがって各エンティティのパケットメッセージに対して割り当てられた活動時間）で移動し、各エンティティはクライアントへ位置更新を送る。この例における巡回する優先度設定は、ｎ＝３、すなわち４レベルの優先度方式を使用した。状態遷移の効果は、サーバおよびクライアントの状態間の差を評価することによって測定することができる。（バンド幅が無限であり、待ち時間がゼロである）完璧なリンクでは、この状態は同一である。完璧でないリンクではこの状態は異なり、この差をピタゴラスの法則を適用することによって測定し、サーバエンティティとクライアントエンティティとの位置間の差を判断することができる。
【００８２】
所与の数のエンティティにおけるこの状態の差は次の何れかとして示すことができる。
１．長い時間期間にわたる全てのサーバ−クライアント位置差の平均。
２．長い時間期間にわたる最大のサーバ−クライアント位置差の平均。
【００８３】
エンティティ数が増加し、生成される状態更新量が増加するのにしたがって、サーバからクライアントへのリンク上に加えられるロードはより大きくなる。
【００８４】
優先度を与えずに送信するアプローチと４つのレベルの巡回する優先度を与えて送信するアプローチとは、２５までのエンティティがデータを送るときはほぼ同様に振る舞う。これは、エンティティが２５までのときは、一定の時間期間内で生成された全ての状態更新を、同じ期間内にサーバからクライアントへのリンク上で送ることができるからである。
【００８５】
多数のエンティティが増加し、クライアントへ送られるトラヒック量が増加するとき、優先度を付けられていない場合に検出されるエラーは迅速に劣化する。これは、ＵＤＰリンクが余分なデータを捨てて、本質的に供給された更新をランダムに選択するからである。一方のエンティティは１０の位置更新のシーケンスをなんとか送ることに成功するが、一方で他方のエンティティは同じ期間に位置更新成し遂げられない。
【００８６】
対照的に、２５ないし９５のエンティティにおいて巡回する優先度方式は、検出されるエラーの平均値および最大値の両者を相当に向上したことを示している。これは、巡回する優先度を使用すると、リンクのバンド幅を越えるときに各送信側エンティティが有効なバンド幅を公平に細分することが保証されるからである。例えば、生成されたトラヒックが有効バンド幅の３倍である（７５のエンティティ）とき、最大のエラーは優先順に配置されていない場合の約４倍増加する。
【００８７】
生成されたトラヒック量が、優先度レベルの数によって乗算されたリンクバンド幅に等しいとき、優先度方式のアプローチは優先度を付けられていないアプローチと同じエラーレベルに劣化（縮退）する。これは、最上位の優先度の状態更新の全てを送るには使用可能なバンド幅が不十分であり、したがって何れの更新が選択されるかが再度ネットワークの機能になるからである。これは、エンティティの数が１００に近付くにしたがって、最大エラーのグラフ上で明らかに分かる。
【００８８】
ここで本発明の第３の実施形態を、図１、２、３、９、１０、および１１に関して記載することにする。この第３の実施形態は、ソースエンティティによって送られるパケットメッセージの構造およびリンクマネージャプロセスの機能のみに関して、第１および第２の実施形態と異なっており、したがってここでも図１、２、および３に対して適切な参照を行なう。図９は本発明のこの第２の実施形態の機能の態様（特徴）についての手続きのフローチャートを示している。ここでも、手続きのフローチャートの段階は、リンク管理コンピュータ上を走行するソフトウエアアプリケーションプログラムの実行によって行われる。
【００８９】
本発明の第３の実施形態にしたがい、とくに図３と関係して、ソースエンティティ100、100'は次の構造をもつパケットメッセージ300を送る。パケットヘッダ302内の第１のフィールド306は、送信側のソースエンティティの識別子で設定される。宛先エンティティを識別するパケットヘッダ302内の第２のフィールドは、この例における1つの宛先エンティティのみが存在するように設定される必要はない。
【００９０】
優先度設定を識別する第３のフィールド310は、再び第１および第２の実施形態のように設定される。各個々のパケットメッセージは、例えば０（最低優先度）ないしｎ（最高優先度）の等級における優先度設定を割り当てられる。ここでも本質的に、ｎ＋１のメッセージのシーケンスは、ソースエンティティから、問題としているソースエンティティに割り当てられた固定された優先度はもたないが、巡回して変化する優先度をもって送り出される。巡回する優先度は、パケットが優先度に基いて捨てられるとき、シーケンス内の残りのパケットは可能な限り均等に間隔を空けられるように変化する。
【００９１】
ここでも、簡単な例、ｎ＝７において、優先度における対応する適切な巡回する変化は、それぞれ０、７、２、４、１、６、３、および５に設定された優先度をもつ８個のメッセージのシーケンスである。０、７、２、４、１、６、３、５のシーケンスでは、連続する低い優先度をドロップしなければならないとき、優先度０をもつメッセージが最初にドロップされ、次に優先度１をもつメッセージ、以下同様に続き、残りのパケットは可能な限り均等に間隔を空けられることを保証する。
【００９２】
この第３の実施形態では、活動時間の期間を与える第４のフィールド312は設定されない。しかしながらこの第３の実施形態では、パケットのペイロードタイプを与える、パケットヘッダ302内の第５のフィールド314が設定される。
【００９３】
上述の第２の実施形態に記載したように、送信側のソースエンティティによる活動時間の期間の設定はソースエンティティの周期性に対応する。上述の例では、２０の公称の時間ユニットごとに、２０の公称の時間ユニットに対応する活動時間をもつパケットメッセージをソースエンティティに送る。状態更新を保持する各パケットメッセージは、別のこのような時間期間の後で、新しい状態更新パケットメッセージが送られるので、ソースエンティティの送信期間よりも長く生きる必要はない。
【００９４】
この第３の実施形態では、活動時間は設定されない。その代わりに各ソースエンティティは、パケットのペイロードタイプの指標、すなわちこの例では位置の指標をもって設定されたパケットヘッダ302の第５のフィールド314で状態更新メッセージを送り出す。したがって各ソースエンティティは、状態更新パケットメッセージを必要なときのみ送り出す。
【００９５】
この第３の実施形態によると、リンクマネージャプロセス114は到来する非周期性のパケットメッセージを予備選択し、その結果同じソースエンティティからの同じペイロードタイプをもつパケットメッセージが結合されて、最新の可能とされる状態更新をもつ新しいパケットメッセージを作ることができる。
【００９６】
したがってこのようなパケットメッセージ流は、ここでも上述のように巡回する優先度設定を指示し、ソースエンティティ100、100'から送り出される。第１の実施形態に関して、これらのパケットメッセージは各サーバコンピュータ104、104'を介してリンク管理コンピュータ110へ送られる。
【００９７】
図９に関して、第１の段階900において、これらのパケットメッセージは、第１および第２のリンク管理コンピュータ入力ポート112、112'において受け取られた後、リンクマネージャプロセス114へ送られる。
【００９８】
第２の段階902において、新しいパケットメッセージがリンク管理コンピュータ入力ポート112、112'の一方において受け取られるとき、リンクマネージャプロセス114は、パケットヘッダ302の第１のフィールド306を読み取り、送信側のソースエンティティの識別子を判断する。既に記載したように、この実施形態では、宛先エンティティを識別する、パケットヘッダ302内の第２のフィールド308は、この例において1つのみの宛先エンティティが存在するので設定されない。第３の段階904では、リンクマネージャプロセス114はさらに、パケットのペイロードタイプの指標、すなわちこの例では位置指標を与える、パケットヘッダ302内の第５のフィールド314を読み取る。第４の段階906では、リンクマネージャプロセス114はさらに、割り当てられた優先度設定を与える、パケットヘッダ302の第３のフィールド310を読み取る。
【００９９】
リンクマネージャプロセス114は再び、第１および第２の実施形態において優先度にしたがって順序付けられる簡単なパケットメッセージの待ち行列116を維持する。
【０１００】
第５の段階908において、リンクマネージャプロセス114はこのパケットの待ち行列116を掃引し、待ち行列に入れられたパケットメッセージのパケットヘッダ302内の第１および第２のフィールド306、314を読み取り、ソースエンティティから受け取られ、かつこのペイロードタイプを支持しているパケットメッセージが現在待ち行列に入れられているか否かを判断する。ソースエンティティから送られたパケットメッセージが、有意な遅延をもたずにリンク管理コンピュータ110へ到達すると仮定すると、より後に到達するパケットメッセージは、先に到達したパケットメッセージよりも最近の状態更新を保持すると仮定される。
【０１０１】
この整合は少なくとも送信側のソース識別子およびペイロードタイプに対して行なわれるので、各送信側のソースエンティティは、それが要求するペイロードタイプがどれであっても、何れかのペイロードの指標と共に自由に表示することが望まれることに注意すべきである（すなわち、ソースＡが位置のペイロードをタイプ＝１で表示することを選択し、一方でソースＢは温度のペイロードを、同じタイプ、すなわちタイプ＝１で表示することができる）。
【０１０２】
したがってリンクマネージャプロセス114が、同じソースエンティティから、同じペイロードタイプを保持しており、依然として待ち行列へ入れられている先行するパケットメッセージを位置付けるとき、第６の段階910において、リンクマネージャプロセスは、割り当てられた優先度設定を与える、待ち行列に入れられたパケットメッセージのパケットヘッダ302の第３のフィールド310を読み取る。
【０１０３】
第７の段階912において、リンクマネージャプロセス114は新しいパケットメッセージを次のように作成する。図２に関して、リンクマネージャプロセスは新しいパケットメッセージのパケットヘッダ302の第１のフィールド306へ書込み、共通のソースエンティティの識別子は、新しく受け取られたパケットメッセージおよび待ち行列に入れられたパケットメッセージの両者のパケットヘッダ302の第１のフィールド306から読み取る。リンクマネージャプロセス114は新しいパケットメッセージのペイロードの選択304へ、リンク管理コンピュータによって受け取ったばかりのパケットメッセージのペイロード、言い換えると使用可能な最近の状態更新を書込む。リンクマネージャプロセス114は、待ち行列へ入れられたパケットメッセージおよび新しく受け取られたパケットメッセージのパケットヘッダ302の第３のフィールド310内の優先度設定を比較し、新しいパケットメッセージのパケットヘッダ302の第３のフィールド310へ、待ち行列へ入れられたパケットメッセージおよび新しく受け取られたパケットメッセージの２つの優先度のうちのより高い方を書込む。
【０１０４】
第８の段階914において、このような新しいパケットメッセージを作成したリンクマネージャプロセス114は、この新しいパケットを簡単な優先度の待ち行列116へ分類して入れる。
【０１０５】
第９の段階916において、リンクマネージャプロセス114は新しく受け取ったパケットメッセージおよび待ち行列へ入れられたメッセージを捨てる。
【０１０６】
代わりの例として、第７および第８の段階912、914の代わりに、リンクマネージャプロセス114は次のように実行されることが分かるであろう。待ち行列へ入れられたパケットメッセージが新しく受け取られたパケットよりも高い優先度をもつとき、新しく受け取られたパケットメッセージのペイロードは待ち行列へ入れられたパケットメッセージのペイロードへ単にコピーされ、新しく受け取られたパケットメッセージは捨てられる。しかしながら、新しく受け取られたパケットが待ち行列に入れられたパケットメッセージよりも高い優先度をもつとき、待ち行列に入れられたパケットメッセージは単に捨てられ、新しく受け取られたパケットメッセージは優先度の待ち行列116へ入れられる。
【０１０７】
リンクマネージャプロセス114において基準に対する整合が見付けられないとき、第１０の段階918において、受け取られたパケットメッセージは単に待ち行列116へ直接に分類される。
【０１０８】
本発明の第３の実施形態では、リンクマネージャプロセス114は再び、第１および第２の実施形態のように、送信前に優先度の待ち行列116のヘッドにあるパケットメッセージを送るための容量についてリンク120を試験する。
【０１０９】
第１および第２の実施形態のように、リンク管理コンピュータ110によって受け取られるパケットメッセージトラヒックの瞬間の全バンド幅が通信リンク120の既知の（小さい）バンド幅よりも小さい限り、リンクマネージャプロセスの待ち行列116内に置かれている全てのパケットメッセージは待ち合わせ遅延なしにリンク120上へ送り出されることになる。受信側エンティティは全てのソースエンティティから送られた全てのパケットメッセージを受け取る。ここでも、第１および第２の実施形態において、パケットメッセージのトラヒック量が増加するときに、到来するパケットメッセージのトラヒックの全バンド幅が通信リンク120のバンド幅を越える地点に到達する。この地点でも、受信側のエンティティに向けられた全てのパケットメッセージを同時に送ることは最早できない。
【０１１０】
本発明の第３の実施形態は、全トラヒックのバンド幅が小さいバンド幅の容量を越えるとき、サービスの最適なグレースフルデグラデーションを伝えることができる巡回する優先度設定に関して本発明の第１の実施形態の全ての長所を備えている。しかしながら本発明の第３の実施形態は、ここで記載するように、第１の実施形態における振舞いに関して、さらに別の長所を備えている。
【０１１１】
本発明のこの第３の実施形態に関して記載したリンクマネージャプロセスによる小さいバンド幅リンクの管理に対するアプローチの成果を、図１０および１１に関して適切に示し、記載することにする。
【０１１２】
図７および８に関して記載したシミュレーションに類似のシミュレーションを実行した。この実験は、優先度方式を全く使用しないとき、それ自身に対して巡回する優先度方式を使用したとき、およびメッセージ組み合わせ機構で巡回する優先度方式を使用したときの結果を示している。この例では、ｎ＝７における巡回する優先度方式、すなわち８レベルの優先度方式を使用した。
【０１１３】
優先度方式を使用しなくても、サーバ上で生成されたトラヒック量がクライアント（３０エンティティ）を更新するのに使用可能なバンド幅を越える地点まで適切に振る舞う。この点から平均および最大のエラー増加において、状態更新のようにネットワークによってランダムに捨てられる。
【０１１４】
それ自身に対して８レベルの優先度方式を使用する結果は、両方のグラフにおいて点線で示されている。これは、いくらかのトラヒック量（例えば、７０エンティティおよび９０エンティティ）においては優先度を与えられていない場合よりも相当により適切に振る舞い、他のトラヒック量（例えば、３５エンティティ）においては相当に劣悪に振る舞う。このデータの組からのエラーにおける各ピークは、生成されたトラヒック量が、サーバとクライアントとの間で送ることができる制限された量の整数倍に等しいときに対応する。上述の例に記載したように、これらのピークを生じるイベントのシーケンスを次に示す：
１．時間ｔにおいてエンティティＸは優先度Ｐをもつ状態更新Ｓｔを生成する；
２．リンクがより高い優先度の更新によって、現在、完全に利用されているので、Ｓｔは待ち行列に入れられる；
３．時間ｔ＋１においてエンティティＸは優先度＞Ｐをもつ状態更新Ｓｔ＋１を生成する；
４．Ｓｔ＋１は、他の待ち行列に入れられたトラヒックに取って代わるのに十分に高い優先度をもつので送信される；
５．新しい状態更新の生成における変動により、待ち行列に入れられたより低い優先度の更新が送り出され、すなわちＳｔが送られて、クライアント上の受信側エンティティはこれを更新Ｓｔ＋２として取扱う。
【０１１５】
ここで、これらのエラーピークは、状態更新生成レートにおける変動が上述の再順序付けの場合に生じるとき、すなわち生成されたトラヒック量が有効バンド幅の整数倍に近いときのみ生成され、１つの特定の優先度レベルは、せいぜい時折り、それを小さいバンド幅リンクへする。
【０１１６】
この問題は、本発明の第３の実施形態によって、両方のグラフ上で点線によって示されているように解決されるが、新しいメッセージは同じエンティティからの古い待ち行列に入れられたメッセージと結合される。したがって既に概略的に記載した再順序付けタイプの問題はなくなり、優先度方式は全てのトラヒックレベルにおいて適切に振る舞う。
【０１１７】
図３に関して、とくにパケットヘッダ302の第２のフィールド308において、それぞれの異なる宛先エンティティの識別子が用いられているときに、単一のリンクマネージャから多数のクライアントへ送ることができることが分かるであろう。次にリンクマネージャプロセスは、例えばクライアントごとに１つのこのような待ち行列を用意することに基いて、多数の分類された優先度のパケットメッセージの待ち行列を維持することができる。
【０１１８】
したがってリンクマネージャは宛先エンティティの識別フィールドを使用して、到来するパケットが位置するのが何れの待ち行列であるかを判断する。パケットの宛先フィールドを使用して、関連する待ち行列を判断するとき、リンクマネージャは上述の機構を使用して、待ち行列内にパケットを置き、それを伝えるか、または捨てることができる。リンクマネージャが多数のクライアント、および多数の優先分類されたパケットの待ち行列を一旦サポートすると、これらの待ち行列の間でラウンドロビンすることが必要であり、これらの待ち行列の各々に、クライアントへのリンクが時間内のその瞬間において保持できる待ち行列のヘッドからパケットを送るための処理時間を許可することが分かるであろう。
【０１１９】
図１２は、本発明の第４の実施形態を示す。
【０１２０】
各クライアント1200、1202、1204は単一の受信側エンティティ1206として取扱われており、その上にゼロ以上の送信側エンティティ1208を常駐させている。全てのクライアントはリンクマネージャ1210へ接続されている。各クライアント1200、1202、1204は送信側エンティティから更新数を生成し、これらを他のクライアントの受信側エンティティへアドレス指定する。各更新はリンクマネージャ1210へ送られ、これは到来する更新を関連するクライアント1200、1202、1204へ分配するタスクをもつ。単一のクライアント1200、1202、1204は多数の他のクライアント1200、1202、1204から更新を受け取るので、ファンインタイプの問題が発生し、それによって各クライアントは制限された数の更新のみを生成するが、特定のクライアントは、ネットワーク接続のバンド幅において可能な更新よりも多数の更新を送られる。
【０１２１】
この問題に効果的に対処するために、リンクマネージャ1210は各クライアントに対して優先度の分類された待ち行列1212、1214、1216、を維持し、この待ち行列1212、1214、1216は、リンクマネージャがクライアントのリンクに対してサポートすることができるのが何なるバンド幅でも、空にされて、クライアント1200、1202、1204へ送られる。これらの待ち行列1212、1214、1216は、上述の巡回する優先度方式を使用して管理され、各更新は、生成されたときに、活動時間またはペイロードタイプと一緒に、クライアントによって優先度を割り当てられる。したがってクライアントがリンクのバンド幅を受け取ることができるよりも多くの更新を送られるとき、リンクマネージャ、受け取った更新の周期性においてグレースフルデグラデーションを行うことを確実にするように働くことができる。
【０１２２】
このアプローチは、クライアントからリンクマネージャへ向かう生成された上流のトラヒックが使用可能なリンクバンド幅を越えない、すなわちクライアントが送信側エンティティによって生成された更新の周期性を規制して、単一の時間期間内に生成される全トラヒックを、クライアントが同じ時間期間内で送ることができる最大値よりも低く維持することを保証する。そうでない場合には、リンクマネージャによって採用されたのと同じ方式をクライアント、すなわち優先度の分類された待ち行列において、リンクバンド幅が許可する何れかのバンド幅でヘッドから送られるメッセージを使用するために、待ち行列の大きさを制約し、かつメッセージの再順序付けを防ぐのに使用される活動時間またはデータ結合のアプローチと共に採用することができる。
【０１２３】
この構成では、各メッセージは２以内の待ち行列を、一方はクライアントから送られる前に、他方はクライアントへ伝えるのを待つ一方でリンクマネージャにおいて通る。この２つの待ち行列作成方式（double queuing scheme）において活動時間のアプローチを使用するとき、メッセージの活動時間は、メッセージが送られる前に正確に調節されなければならないことに注意すべきである。例えば、メッセージがｔ＝０において２０のＴＴＬ（time to live、活動時間）で生成され、５の時間期間においてクライアント側の待ち行列に留まるとき、１５のＴＴＬ（すなわち、（元のＴＴＬ）−（待ち行列内で費やされた時間））でリンクマネージャへ送られる。
【０１２４】
上述の実施形態では、優先度ラベルがソースによって各パケットメッセージへ割り当てられる技術を示したが、常にこの通りである必要はない。パケットメッセージがソースによって送られるシーケンス順序（例えば、シーケンス順序フィールド）が保存される限り、優先度ラベルの割当てはソースの下流で実行される。事実、パケットメッセージ待ち行列のどの部分に受け取ったパケットメッセージを分類するかについて判断する目的で、優先度ラベルが割り当てられることが決められた条件下では、（上述のように巡回するラベルシーケンス技術と、所与のソースからの所与の受け取られたパケットメッセージのシーケンスの位置の知識とを利用する）分類アルゴリズムが使用されて、上述のように２つの段階で実行されたように、適切な優先度ラベルの割当ておよび優先度に基く待ち行列への分類を伴って、受け取ったパケットメッセージを待ち行列の同じ部分へ分類することができる。
【図面の簡単な説明】
【図１】 本発明にしたがって第1の実施形態を示す図。
【図２】 汎用コンピュータを示す図。
【図３】 パケットメッセージ構造を示す図。
【図４】 第１の手続きのフローチャートを示す図（図４Ａおよび４Ｂ）。
【図５】 本発明の第２の実施形態に関して、第２の手続きのフローチャートを示す図。
【図６】 本発明の第２の実施形態に関して、第３の手続きのフローチャートを示す図。
【図７】 第２の実施形態についての動作の結果を示す第１のグラフ。
【図８】 第２の実施形態における別の動作の結果を示す第２のグラフ。
【図９】 本発明にしたがう第３の実施形態に関して、第４の手続きのフローチャートを示す図（図９ＡおよびＢ）。
【図１０】 第３の実施形態における動作の結果を示す第３のグラフ。
【図１１】 第３の実施形態における別の動作の結果を示す第４のグラフ。
【図１２】 本発明にしたがう第４の実施形態を示す図。

Claims (11)

1. パケットメッセージのシーケンスの各パケットメッセージ内にそれぞれのパケットメッセージのペイロードを含むように構成された手段と、
   優先度ラベルを前記シーケンス内の各連続するパケットメッセージに前記優先度ラベルの所定の巡回するシーケンスにしたがって関係付けるように構成された手段とを備え、
   各優先度ラベルはそれぞれ異なる優先度レベルを表わしており、前記巡回するシーケンスにおける前記優先度ラベルの位置は、前記巡回するシーケンスにおいて、各ラベルと、前記各ラベルの最も近くにあるより高い優先度ラベルとの間に現れる、連続するより低い優先度ラベルの数を最大化するように制御され、
   更に、
   前記パケットメッセージを送るように構成された手段を備える、パケットメッセージソース。
2. 前記パケットメッセージソースが、関係付けられたダイナミック状態をもち、
   前記それぞれのパケットメッセージのペイロードがソース状態の更新メッセージを含む請求項１に記載のパケットメッセージソース。
3. 活動時間のラベルを各パケットメッセージと関係付けるように構成された手段をさらに含む請求項１または請求項２に記載のパケットメッセージソース。
4. パケットメッセージのソース識別子を各パケットメッセージと関係付けるように構成された手段と、
   パケットメッセージのペイロードタイプ設定を各パケットメッセージと関係付けるように構成された手段と、をさらに含む請求項１ないし請求項３の何れか１項に記載のパケットメッセージソース。
5. 請求項１ないし請求項４の何れか１項に記載の複数のパケットメッセージソースと、
   通信リンクインターフェイスと、を備えるパケットメッセージングシステムであって、
   前記通信リンクインターフェイスが、
   前記複数のパケットメッセージソースからパケットメッセージを受け取る入力ポートと、
   各受け取ったパケットメッセージと関係付けられた優先度ラベルを読み取るように構成された手段と、
   関係付けられた優先度ラベルの降順で、受け取ったパケットメッセージを待ち行列に入れるための待ち行列と、
   前記待ち行列の先頭の各パケットメッセージを通信リンクへ送る出力ポートとを含む、パケットメッセージングシステム。
6. パケットメッセージソースは活動時間ラベルを各パケットメッセージに関連付けるように構成された手段を有し、
   前記通信リンクインターフェイスが、
   各受け取ったパケットメッセージと関係付けられたパケットメッセージの活動時間のラベルを読み取るように構成された手段と、
   パケットメッセージが待ち行列に入れられた時間期間の指標を各パケットメッセージに関係付けるように構成された手段と、
   パケットメッセージが関係付けられたパケットメッセージの活動時間のラベルよりも長い時間期間の間待ち行列へ入れられたことを示す関係付けられた指標をもつ各パケットメッセージを捨てるように構成された手段と、
   をさらに含む請求項３に従属するときの請求項５に記載されたパケットメッセージングシステム。
7. パケットメッセージソースは活動時間ラベルを各パケットメッセージに関連付けるように構成された手段を有し、
   前記通信リンクインターフェイスが、さらに、
   クロックと、
   各パケットメッセージと関係付けられたパケットメッセージの活動時間のラベルを、パケットメッセージから読み取った活動時間のラベルの値とパケットを受け取ったローカル時間との和の調節された活動時間のラベルと置換するように構成された手段とを含み、
   前記時間期間の指標を各パケットメッセージに関係付けるように構成された手段は、少なくとも1つのパケットメッセージを、各前記パケットメッセージから読み取られた前記調節された活動時間から前記パケットメッセージが到達したローカル時間を減算した結果と関係付け、各パケットメッセージを捨てるように構成された手段が、前記関係付けられた減算した結果がゼロ以下であるときにパケットメッセージを捨てるように構成されている、
   請求項３に従属するときの請求項５に記載されたパケットメッセージングシステム。
8. パケットメッセージソースが、パケットメッセージのソース識別子を各パケットメッセージに関係付けるように構成された手段と、パケットメッセージのペイロードタイプ設定を各パケットメッセージに関係付けるように構成された手段とを含み、
   前記通信リンクインターフェイスが、
   各受け取ったパケットメッセージからパケットメッセージのソース識別子を読み取るように構成された手段と、
   各受け取ったパケットメッセージと関係付けられたパケットメッセージのペイロードタイプ設定を読み取るように構成された手段と、
   受け取ったパケットメッセージの関係付けられたソース識別子と整合する関係付けられたソース識別子をもつ待ち行列に入れられたパケットメッセージのためのパケットメッセージ待ち行列を試験するように構成された手段と、
   整合する待ち行列に入れられたパケットメッセージと関係付けられた優先度ラベルを読み取るように構成された手段と、
   整合する受け取ったパケットメッセージ及び待ち行列に入れられたパケットメッセージに代えて、整合する受け取ったパケットメッセージ及び待ち行列に入れられたパケットメッセージの関係付けられたソース識別子と、受け取ったパケットメッセージのペイロードと、整合する受け取ったパケットメッセージ及び待ち行列に入れられたパケットメッセージの関係付けられた優先度ラベルのうちの何れかより高い優先度を表わす優先度ラベルとをもつ、パケットメッセージを、優先度ラベルに基いて分類して待ち行列へ入れるように構成された手段と、
   をさらに含む請求項４に従属するときの請求項５に記載のパケットメッセージングシステム。
9. パケットメッセージのシーケンスの各パケットメッセージ内にそれぞれのパケットメッセージのペイロードを含むように構成された手段と、前記パケットメッセージを送るように構成された手段と、を各々が備える複数のパケットメッセージソースと、
   通信リンクインターフェイスと、を備えるパケットメッセージングシステムであって、
   該通信リンクインターフェイスは、
   前記複数のパケットメッセージソースからパケットメッセージを受け取る入力ポートと、
   各受け取ったパケットメッセージと関係付けられた優先度ラベルを読み取るように構成された手段と、
   それぞれの割り当てられた優先度ラベルの降順でパケットメッセージを待ち行列に入れるための待ち行列とを含み、
   前記複数のパケットメッセージソースの各々における前記シーケンスの中の検討されている連続するパケットは、前記優先度ラベルを、前記優先度ラベルの所定の巡回するシーケンスにしたがって割り当てていて、各優先度ラベルはそれぞれ異なる優先度レベルを表わしており、前記巡回するシーケンスにおける前記優先度ラベルの位置は、前記巡回するシーケンスにおいて、各ラベルと、前記各ラベルの最も近くにあるより高い優先度ラベルとの間に現れる、連続するより低い優先度ラベルの数を最大化するように制御され、
   更に、
   前記待ち行列の先頭の各パケットメッセージを通信リンクへ送る出力ポートを含む、パケットメッセージングシステム。
10. パケットメッセージのシーケンスの中の各パケットメッセージ内にそれぞれのパケットメッセージのペイロードを含むステップと、
    優先度ラベルを前記シーケンスの各連続するパケットメッセージに、優先度ラベルの所定の巡回するシーケンスにしたがって関係付けるステップとを含み、
    各優先度ラベルはそれぞれ異なる複数の優先度レベルを表わしており、前記巡回するシーケンスにおける前記優先度ラベルの位置は、前記巡回するシーケンスにおいて、各ラベルと、前記各ラベルの最も近くにあるより高い優先度ラベルとの間に現れる、連続するより低い優先度ラベルの数を最大化するように制御され、
    更に、
    前記パケットメッセージを送るステップを含む、パケットメッセージングの方法。
11. 複数のパケットメッセージソースと通信リンクインターフェイスとを含むパケットメッセージングシステムを動作する方法であって、
    パケットメッセージソースの各々における元のシーケンスの中の検討されている連続するパケットに、優先度ラベルの所定の巡回するシーケンスにしたがって優先度ラベルを割り当てるステップを含み、
    各優先度ラベルはそれぞれ異なる優先度レベルを表わしており、前記巡回するシーケンスにおける前記優先度ラベルの位置は、前記巡回するシーケンスにおいて、各ラベルと、前記各ラベルの最も近くにあるより高い優先度ラベルとの間に現れる、連続するより低い優先度ラベルの数を最大化するように制御され、
    更に、
    前記パケットメッセージを、それぞれの割り当てられた優先度ラベルの降順で、前記通信リンクインターフェイスにおいて待ち行列に入れるステップと、
    前記待ち行列の先頭の各パケットメッセージを通信リンクへ送るステップと、
    を含む方法。

Images