(57)【特許請求の範囲】
【請求項１】
２以上のソフトウエア要素間で通信を行う方法であって、ホストコンピュータ手段は、ホストスペース内でアプリケーションソフトウエア要素をホストするアプリケーションプログラム（305，306）をホストするようにされていて、２以上のアプリケーションソフトウエア要素（308，310，312）が前記ホストスペース内でホストされていて、
前記ホストコンピュータ手段が、各アプリケーションソフトウエア要素（308，310，312）を、メッセージを送受信するのに通る通信ソフトウエア要素（309，311，313）と関係付けるステップと、
各通信ソフトウエア要素が、各関係するアプリケーションソフトウエア要素（308，310，312）の通信状態を保持するステップと、
前記ホストコンピュータ手段が、各アプリケーションソフトウエア要素（308，310，312）が、それぞれ関係する通信ソフトウエア要素（309,311,313）を介してメッセージを送受信することによって他のアプリケーションソフトウエアと通信できるようにするステップと、
前記ホストコンピュータ手段が、各アプリケーションソフトウエア要素（308，310，312）と関係する通信ソフトウエア要素（309,311,313）とが前記ホストスペース内で移動できるようにするステップとを含み、
前記ホストコンピュータ手段が２以上のホストコンピュータ（301，302）を含み、
各アプリケーションソフトウエア要素（308，310，312）と関係する通信ソフトウエア要素（309,311,313）とが前記ホストスペース内で移動できるようにする前記ステップが、各アプリケーションソフトウエア要素と関係する通信ソフトウエア要素とが前記２以上のホストコンピュータ（301，302）間を移動できるようにするステップを含む方法。
【請求項２】
各関係するアプリケーションソフトウエア要素（308，310，312）の通信状態を保持する前記ステップが、前記ホストコンピュータが関係するアプリケーションソフトウエア要素へまだ伝えられていないメッセージの待ち行列を保持するステップを含む請求項１記載の方法。
【請求項３】
各関係するアプリケーションソフトウエア要素の通信状態を保持する前記ステップが、前記ホストコンピュータ手段が独特の通信識別を保持するステップを含む請求項１または２記載の方法。
【請求項４】
選択されたアプリケーションソフトウエア要素（308）の独特の通信識別を受け取ることに応答して、前記ホストコンピュータ（301，302）の何れの上に前記選択されたアプリケーションソフトウエア要素が存在するかを前記ホストコンピュータ手段が判断するステップをさらに含む請求項３記載の方法。
【請求項５】
２以上のアプリケーションソフトウエア要素（308,310,312,314）間で通信を行う装置であって：
ホストスペース内でアプリケーションソフトウエア要素(308,310,312)をホストするアプリケーションプログラム(305,306)をホストするようにされているホストコンピュータ手段と；
前記ホストスペース内でホストされる２以上のアプリケーションソフトウエア要素(308,310,312)と；
該アプリケーションソフトウエア要素は各々、メッセージの送信または受信、あるいはこの両者を行うのに通る関係する通信ソフトウエア要素(309,311,313)をもっていて；
該通信ソフトウエア要素は各々、関係するアプリケーションソフトウエア要素(308,310,312)の通信状態を保持していて；
通信ソフトウエア要素(309,311,313)間のメッセージングを可能にするようにされているメッセージング手段(318,319)と；
ソフトウエア要素が前記ホストスペース内で移動できるようにされている移動手段とを含み、
前記ホストコンピュータ手段が２以上のホストコンピュータ（301,302）を含み、
前記移動手段は、アプリケーションソフトウエア要素が前記２以上のホストコンピュータ間を移動できるように構成されている装置。
【請求項６】
前記通信状態が、関係するアプリケーションソフトウエア要素へまだ伝えられていないメッセージの待ち行列を含む請求項５記載の装置。
【請求項７】
前記通信状態が、独特の通信識別を含む請求項５または６記載の装置。
【請求項８】
選択されたアプリケーションソフトウエア要素（308）の独特の通信識別を受け取ることに応答して、前記ホストコンピュータ（301，302）の何れの上に前記選択されたアプリケーションソフトウエア要素が存在しているかを判断するように構成されている位置手段（319，321）をさらに含む請求項７記載の装置。
【発明の詳細な説明】
【０００１】
発明の属する技術分野
本発明は、２以上のソフトウエア要素間で通信を行うための方法および装置を提供することに関する。本発明はここでは、限定はしないが、とくに高モバイルのソフトウエア要素をもつ動的な実時間の分散形システムに応用される。
【０００２】
従来の技術
多数のクライアントの対話を可能にするこのようなアプリケーションによって使用される今日のアーキテクチャの周知の例を図１および２を参照して記載することにする。
【０００３】
図１（ａ）は、各クライアントと全ての他のクライアントとの非常に簡単な相互接続を示している。このようなアプローチは、クライアント数が増加するのにしたがって、非常に早く実行不可能になることが明らかである。例えば１００人のクライアントが対話できることが容易に望まれている。
【０００４】
図１（ｂ）は、より高度なアプローチであって、各クライアントを単一の中央のサーバに接続することをを示している。クライアント／サーバ構成および関係する専門用語の概念がよく分かるであろう。しかしながら、クライアント数が増加し始めると直ぐに、このアプローチも実行不可能になる。例えば数百のクライアントがトリビアルでなく（non-trivial manner）対話するとき、単一の今日のサーバではコンピュータ処理ロードおよびネットワークトラヒックの両者によって簡単に圧倒されてしまう。
【０００５】
図２は、より高度なアプローチであって、ここでは多数のクライアントの各々をインターフェイスを介して、単一の中央サーバではなく、多数のサーバから構成されているサーバクラスタへ接続するを示している。このアプローチではサーバクラスタ内の中央サーバに接続するアプリケーションを扱う能力を保持している一方で、コンピュータ処理ロードおよびネットワークトラヒックの両者をサーバクラスタの多数のサーバ間で分散することもできる。
【０００６】
最近の数年間においてコンピュータプログラミングに対して、いわゆるオブジェクト指向のアプローチが普及したことがよく知られており、大型のマルチプレーヤゲームのようなアプリケーションは例外ではない。オブジェクトおよび関係する専門用語の概念がよく分かるであろう。‘ゲームの構成要素（game-component）’という用語を使用して、ここではゲームのオブジェクト、いわゆるゲームの構成のもつ幾つかのアスペクト（aspect）を表わす自蔵形のコードおよびデータのグループを指す。
【０００７】
一般的に、サーバクラスタの各サーバは多数のプロセスを実行し、各プロセスは多数のゲームの構成要素をホストしている。このアプローチでは、いくつかの構成要素、例えば、いわゆる‘ログインマネージャ（login manager）’が、固定位置において一度限りインスタンス生成されることが分かるであろう。他の構成要素、例えばディスインテグレータピストル（disintegrator pistol）は、多くの異なる位置において何度もインスタンス生成される。事実、このような構成要素は、第１のクライアント上で操作している第１のゲームプレーヤから、第２のクライアント上で操作している第２のゲームプレーヤへ送られることがよくある。このやり方では、構成要素は第１のクライアントからサーバクラスタへ移動し、第２のクライアントへ戻ることが必要である。
【０００８】
このアーキテクチャは、さらに別の点で動的であることが要求される。
【０００９】
このようなマルチプレーヤゲームの大きさおよび複雑性を増すか、または接続されたクライアント数が増加するとき、サーバクラスタ内のサーバ数を増加することがよく望ましい。既に記載したように、このやり方では、ゲームのホスティングと関係するコンピュータ処理ロードと、ゲームをしている途中で生成されるネットワークトラヒックとが、多数の個々のサーバ上で分散されるか、また平衡化される。特定の機能性をもつ新しいサーバを、サーバクラスタ、例えば高性能の人工知能（Artificial Intelligence, AI）エンジンに接続することも望ましい。
【００１０】
さらに加えて、ゲーム環境が発展するのにしたがって、それを維持するのに必要とされるコンピュータ処理タスクが変化することがよくある。新しいプロセスが生成され、古いプロセスは要求にしたがって破壊されることがある。
【００１１】
したがって大型のマルチプレーヤゲームのようなアプリケーションの開発者は、このような非常に動的で分散形のアーキテクチャと共に働く際の相当な問題に直面している。とくに、高度に動的な分散形のマルチプレーヤゲームがプレーできるように分散形のゲームの構成要素間で、実時間の、待ち時間の短い通信を可能にすることについての問題が示されていることが明らかである。
【００１２】
上述のオブジェクト指向のコンピュータプログラミングにおいて一般的な関心があるので、現在、オブジェクトが互いに通信できる多数のアプローチがあることがよく知られている。上述の問題について、とくに関心をひくことには、いわゆる分散形オブジェクト、すなわちクライアント／サーバシステム上で分散されているオブジェクトが互いに通信できるようにするための異なるアプローチがあることである。
【００１３】
文献（‘The Essential Distributed Objects Survival Guide’, Robert Orfali, Dan Harkey, Jeri Edwards, John Wiley & Sons Inc, 1996）では、良好な導入部を見付けることができる。
【００１４】
第１の例では、クライアント／サーバ構成は、単に、標準の伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol/Internet Protocol, TCP/IP）のバークレイソケットＡＰＩを使用して構成されている。しかしながら、次に記載する多くの問題が直ぐに発生する。
【００１５】
（ａ）各クライアントは、（‘関連する（relevant）’の定義が規則的に変化するとして）全ての関連するサーバプロセスへの接続を連続的に生成および破壊しなければならず、これは待ち時間および処理オーバーヘッドの問題を導く；
（ｂ）位置が変わる（すなわち、プロセス間を移動する）ゲームの構成要素は、位置追跡およびデータシーケンシングの問題を生成する。ＴＣＰ／ＩＰリンクは各端部間においてデータ命令を保証するが、モバイルのゲーム構成要素間の通信は多数のＴＣＰ／ＩＰリンクを含み、関連するシーケンス情報は維持されない；
（ｃ）ＴＣＰ／ＩＰリンクの実行された順序付けにより、環境内のクライアント間の知覚された待ち時間を相当に増加する。例えば、このシーケンスにおいて‘プレーヤＡはこんにちはと言い、プレーヤＢはあなたを撃つ（Player A says hello, Player B shoots you）’とき、第１の要素は移送中に失われ、次に第２の要素は遅延され、一方でタイムアウト／伝送機構が呼出される。
【００１６】
別の簡単な構成では、ＴＣＰ／ＩＰの代わりに、ユーザデータグラムプロトコル／インターネットプロトコル（User Datagram Protocol/Internet Protocol, UDP/IP）を使用することができる。しかしながら、実行された順序付けの問題が取除かれる一方で、例えばデータの順序付けまたは確実な伝達の概念も取除かれてしまう。
【００１７】
現在の周知の共通のオブジェクト要求ブローカアーキテクチャ（Common Object Request Broker Architecture, CORBA）および分散された構成要素オブジェクトモデル（Distributed Component Object Model, DCOM）は、ネットワーク上で分散形オブジェクト間で情報を共有する一般的な機構を用意している。しかしながら、ＣＯＲＢＡ／ＤＣＯＭのアプローチに基いて、均一のオブジェクトのインターフェイスを用意しているネットワークの存在を全く隠す試行をしなければならない。これらは効果的な技術であるが、時間が非常に重要であり、かつトラヒック量について感度の高いアプリケーションに応用できない。その代わりに、どのようにネットワークトラヒックが分散され、処理されるかについての制御を維持することが不可欠である。関連する技術は、例えば集中形待ち行列からメッセージを非同期に検索することに依存する。
【００１８】
したがって、今日のアプローチは単に、上述で概略的に記載した問題に対する解決案を与えることができない。
【００１９】
発明が解決しようとする課題
しかしながら本発明の第１の態様にしたがって、２以上のソフトウエア要素間で通信を行う方法であって、ホストコンピュータ手段は、ホストスペース内でアプリケーションソフトウエア要素をホストするアプリケーションプログラムをホストするようにされていて、２以上のアプリケーションソフトウエア要素が前記ホストスペース内でホストされていて：
各アプリケーションソフトウエア要素を、メッセージを送受信するのに通る通信ソフトウエア要素と関係付けることと；
関係する通信ソフトウエア要素において各関係するアプリケーションソフトウエア要素の通信状態を保持することと；
各アプリケーションソフトウエア要素が、それぞれ関係する通信ソフトウエア要素を介してメッセージを送受信することによって他のアプリケーションソフトウエアと通信できるようにすることと；
各アプリケーションソフトウエア要素と関係する通信ソフトウエア要素とが前記ホストスペース内で移動できるようにすることとを含む方法を提供する。
【００２０】
所与のソフトウエア要素と関係する通信ソフトウエア要素内の全通信状態を保持することによって、アプリケーションソフトウエア要素および通信ソフトウエア要素アセンブリが通信し、とくに動的に移動できるようにする。その結果イネーブルされた、メッセージングを要素ごとに実行され、これらがこのように動的に移動しても、ソフトウエア要素間の通信の継続することができる。
【００２１】
本発明の別の態様にしたがって、２以上のソフトウエア要素間で通信を行う装置であって：
ホストスペース内でアプリケーションソフトウエア要素をホストするアプリケーションプログラムをホストするようにされているホストコンピュータ手段と；
前記ホストスペース内でホストされる２以上のアプリケーションソフトウエア要素と；
該アプリケーションソフトウエア要素は各々、メッセージの送信または受信、あるいはこの両者を行うのに通る関係する通信ソフトウエア要素をもっていて；
該通信ソフトウエア要素は各々、関係するアプリケーションソフトウエア要素の通信状態を保持していて；
通信ソフトウエア要素間のメッセージングを可能にするようにされているメッセージング手段と；
ソフトウエア要素が前記ホストスペース内で移動できるようにされている移動手段とを含む装置を提供する。
【００２２】
ここでも、所与のソフトウエア要素と関係する通信ソフトウエア要素内で全通信状態を保持することによって、アプリケーションソフトウエア要素および通信ソフトウエア要素アセンブリは通信し、とくに動的に移動することができる。結果的にイネーブルされたメッセージングは、要素ごとに実行され、それらがこのような動的に移動してもソフトウエア要素間の通信を継続することができる。
【００２３】
ここで本発明の１つの実施形態を、例示的に、添付の図面を参照して記載することにする。
【００２４】
発明の実施の形態
サーバクラスタ構造
図３は、本発明のこの例示的な実施形態で使用するのに適した簡単なサーバクラスタ（300）およびネットワーク構成の１例を示している。適切なサーバコンピュータクラスタ（300）が、第１のサーバコンピュータ（301）、第２のサーバコンピュータ（302）、および第３のサーバコンピュータ（303）をもち、ローカルエリアネットワーク（Local Area Network, LAN）（304）を介して相互接続されていることを示している。
【００２５】
例えばUnix(Irix、Linux、およびSolaris)またはMicrosoft Windows(商標)を実行する適切なコンピュータは、よく知られている。
【００２６】
別途記載するように、図７を参照すると、多数のクライアントコンピュータ（図３には示されていない）はサーバコンピュータクラスタ（300）に接続されていてもよい。
【００２７】
第１のサーバコンピュータ（301）は、第１および第２のサーバプロセス（305，306）をホストし、第２のサーバコンピュータ（302）は第３のサーバプロセス（307）をホストする。各このようなサーバプロセス（305,306,307）は、アプリケーションに関係する構成要素（308,310,312,314）をホストする。既に記載したように、各構成要素は、アプリケーションの構成の若干のアスペクトを表わすコードおよびデータの内蔵されたグループを示すために採用されている。“ソフトウエア要素（software element）”という用語は、構成要素またはオブジェクトの代わりに同様に使用することができる。
【００２８】
ゲームの開発者に関して、サーバプロセス（305,306,307）は、例えばバーチャル環境内の空間（room）を表わしている。このようなプロセスにおいてホストされる構成要素(308,310,312,314)は、このような空間内のオブジェクトであってもよい。これらのオブジェクトはしばしば移動を可能にする必要があり、ゲーム中のキャラクタのアバタは１つの明白な例であるが、例えばディスインテグレータピストルは拾い上げられて、１つの空間から別の空間へ移動することができる。
【００２９】
別途記載するように、各構成要素(308,310,312,314)はいわゆる‘エンドポイント’（309,311,313,315）と関係している。各このようなエンドポイントは独特のシステム全体のアドレスをもつ。構成要素と関係しているこのようなエンドポイントの目的は、より明らかになるように、各エンドポイントを介してメッセージを送受信することによって、構成要素が互いに通信できるようにすることである。
【００３０】
第１、第２、第３、および第４の構成要素（308,310,312,314）が、それぞれ第１、第２、第３、および第４のエンドポイント（309,311,313,315）をもつことが示されている。第１および第２の構成要素（308，310）および関係するエンドポイント（309,311）は、第１のサーバコンピュータ（301）上でホストされる第１のサーバプロセス（305）内にある。第３の構成要素および関係するエンドポイント（312,313）は、第1のサーバコンピュータ（301）上でホストされる第２のサーバコンピュータ（306）内にある。第４の構成要素および関係するエンドポイント（314,315）は、第1のサーバコンピュータ（301）上でホストされる第３のサーバコンピュータ（307）内にある。
【００３１】
異なるサーバプロセス内に位置する構成要素とのメッセージの送受信は、サーバメッセージングインターフェイス（316,317）を使用して達成される。１つのこのようなサーバメッセージングインターフェイス（Server Messaging Interface, SMI）はサーバごとに用意されている。したがって、例示したエンドポイント間のメッセージングは、それぞれ第１および第２のサーバコンピュータ（301，302）上でホストされる第１および第２のサーバメッセージングインターフェイス（316，317）によって処理される。
【００３２】
各サーバメッセージングインターフェイスは、1対のルート設定テーブルを維持している。アウトバウンドのルート設定テーブルは宛先のエンドポイントアドレスをサーバメッセージングインターフェイスにマップし、サーバメッセージングインターフェイスが責務を負っているサーバプロセスにおいて、宛先のエンドポイントアドレスを見付けることができる。インバウンドのルート設定テーブルは、宛先のエンドポイントアドレスを、このサーバ上で実行されるサーバプロセスへマップし、サーバメッセージングインターフェイスが責務を負っているこのサーバにおいて、宛先のエンドポントアドレスを見付けることができる。第１のサーバメッセージングインターフェイス（316）は、それぞれ第１および第２のインバウンドおよびアウトバウンドのルート設定テーブル（それぞれ、318,319）をもつように示されている。第２のサーバメッセージングインターフェイス（317）は、第２のインバウンドおよびアウトバウンドのルート設定テーブル（それぞれ、320,321）をもつように示されている。これらのルート設定テーブルは、別途記載するように、エンドポイントおよび関係する構成要素の生成および移動のようなイベントのときに更新される。
【００３３】
構成要素およびエンドポイントの生成、並びにアドレスの割当て
ここで独特のシステム全体の識別をエンドポイントへ割当てるプロセスを、エンドポイントアドレス割当てプロセスのフローチャートである図３および４に関して示す。
【００３４】
第３のサーバコンピュータ（303）は、ＬＡＮ（304）上で第１および第２のサーバコンピュータ（301，302）と相互接続されていて、この実施形態では、いわゆるエンドポイント位置サーバ（Endpoint Location Server, ELS）として機能している。第１の段階（400）では、新しいサーバメッセージングインターフェイス（Server Messaging Interface, SMI）の起動の際に、エンドポイント位置サーバ（303）は新しいサーバメッセージングインターフェイスへ、新しく生成されたエンドポイントへ解放するための識別（アイデンティティ）ブロックを割り当てて送る。
【００３５】
第２の段階（401）では、サーバメッセージングインターフェイスと関係するサーバ内の新しいサーバプロセスの起動の際に、サーバメッセージングインターフェイスは新しいプロセスを、新しく生成されたエンドポイントへ解放するためのこの識別のサブブロックへ割り当てて送る。このやり方では、この識別のサブブロックは、要求されたときに割当てるサーバプロセスに使用することができる。
【００３６】
構成要素オブジェクトの生成プロセスは、アプリケーションサーバプロセスの制御のもとで行われ、このような識別の割当てを含む。構成要素が異なるプロセスにおいて他の構成要素と通信できるようにするために、構成要素はそれと関係するエンドポイントをもつことが必要である。したがって、問題のサーバプロセスによる構成要素のインスタンス生成プロセス中に、呼は通常、エンドポイントの生成を要求する。
【００３７】
次にサーバプロセスは、要求された通りにエンドポイントのオブジェクトを生成するが、第３の段階（402）には、サーバプロセスによって保持されているサブブロックから識別の１つをエンドポイントへ割り当てることを含んでいる。例示的にこの実施形態では、３２ビットのシステム全体の識別を各エンドポイントに用意することができる。
【００３８】
しかしながら別途記載するように、エンドポイントはこのシステムの識別のみを含む訳ではなく、関係する構成要素の完全な通信状態も含む。
【００３９】
いったんエンドポイントが生成されると、サーバプロセスはポインタを構成要素へ戻し、エンドポイントを構成要素に結合する。通常、構成要素は一連の機能アドレスをエンドポイントへ与え、エンドポイントが（例えば、構成要素に対するメッセージを受取ったとき）非同期のイベントを構成要素に再び伝えることができるようにする。
【００４０】
第４の段階（403）では、新しくインスタンス生成された構成要素と関係するエンドポイントに割り当てられたアドレスは、サーバメッセージングインターフェイスへ通知される。サーバメッセージングインターフェイスはインバウンドのルート設定テーブルを更新する。
【００４１】
第５の段階（404）では、この通知はエンドポイント位置サーバ（303）、すなわちグローバルエンドポイント識別メモリへさらに送られる。
【００４２】
上述の段階は、記載とは異なる順序で実行できることが分かるであろう。その代わりに、例えば、エンドポイントを新しく生成された構成要素へ戻すこと、および構成要素によって関連するコールバック機能に対してエンドポイントをフックすることを上述の第４および第５の段階の後で実行してもよい。
【００４３】
このやり方では、新しい構成要素のオブジェクトがインスタンス生成され、通信するのに通る新しいエンドポイント、すなわちエンドポイントを可能にするアドレスを要求する場合、およびそのとき、インスタンス生成に対して責務を負うサーバプロセスからシステム全体の識別子を直接に割り当てることができる。都合の悪い遅延を含む、遠隔アドレス割当てプロセスへの非同期の要求を行う必要はない。
【００４４】
特定のサーバプロセスがアドレス上で行アドレスを走行するとき、例えばそれに対して使用可能なアドレス数が所定の閾値よりも低くなるとき、サーバプロセスは、それらに割り当てる要求に先立って、サーバメッセージインターフェイスから別のサブブロックを要求することができる。同様に、サーバメッセージングインターフェイスは、行アドレスを実行するとき、類似のやり方でエンドポイント位置サーバから新しいブロックを要求する。
【００４５】
さらにシステム全体のアドレスの所定のブロックは、エンドポイント位置サーバによってこのプロセスから戻されて維持され、特定の重要度のオブジェクトに静止アドレスを用意する。
【００４６】
さらに、エンドポイント位置サーバ（ＥＬＳ）は、それが発行したのはどの識別ブロックか、および各ブロック内で依然として使用されていない識別数を追跡する。エンドポイントが解放されるとき、エンドポイント位置サーバは関連するサーバメッセージングインターフェイスによって通知され、関連するブロックにおける未使用の識別計数をデクレメントすることができる。同様に、プロセスが終了するとき、まだ割り当てられていない識別の全てがエンドポイント位置サーバへ戻され、関連するブロックから照合（チェック、tick off）することができる。所与のブロックについての未使用の識別計数がゼロに達するとき、ブロックは再発行のためにプールへ戻される。
【００４７】
静止オブジェクト間の簡単なメッセージング
同じプロセス内でホストされる構成要素は、互いにメソッドコール（method call）を行うことによって直接に通信することができる。異なるプロセスにおいてホストされる構成要素で、同じサーバコンピュータ上を走行しながら、一方ではエンドポイント機構の使用をしているものが、共有メモリを利用するという利点をもつことができて、メッセージ送信機構が、宛先がどこであるかとは無関係に同一に見える一方で、プロセス間を移動するメッセージは単にポインタを次々に回すことによって転送される。
【００４８】
しかしながら本発明にしたがって、異なるサーバコンピュータ上に置かれた構成要素間の通信について、次のようにエンドポイントの使用が要求される。
【００４９】
構成要素が他の関連する構成要素の存在を発見するために、種々の機構が存在する。仮想環境内の余地空間を表わすサーバプロセスについての上述の例を採用するために、RoomManagerオブジェクトを各空間に対して生成することができる。各空間内でインスタンス生成される全ての構成要素はRoomManagerオブジェクトにメッセージを伝えて、それに自分の存在を知らせる。代わって各RoomManagerオブジェクトは、各空間内に存在する構成要素の対話をメッセージングを介して監督する。
【００５０】
例示的に、ここでは第１の構成要素から第４の構成要素へメッセージを送るプロセスを図３に関して示し、構成要素から構成要素へのメッセージングプロセスのフローチャートを図５に関して示している。
【００５１】
第１の段階（500）では、第1のサーバ（301）上の第１のサーバプロセス（305）においてホストされる第１の構成要素（308）は、第２のサーバ（302）上の第３のサーバプロセス（308）においてホストされる第４の構成要素（314）へ意図されたメッセージを生成する。第２の段階（501）では、このメッセージは関係する第１のエンドポイント（309）へ送られる。第３の段階（502）では、メッセージは、第４の構成要素（314）へ送られることになる識別をもち、第１のサーバメッセージングインターフェイス（316）、すなわち第１のサーバプロセス（305）が走行しているサーバ（301）と関係するサーバメッセージングインターフェイスへ送られる。
【００５２】
第４の段階（503）では、第１のサーバメッセージングインターフェイス（316）は関係する第１のアウトバウンドのルート設定テーブル（319）を調べて、何れのサーバメッセージングインターフェイスが、メッセージのアドレス指定先の構成要素が存在するサーバプロセスに対して責務を負うかを明らかにする。さらに別途記載するように、ルート設定テーブルが要求されるアドレスのキャッシュされたコピーをもたないとき、ＬＡＮを介してエンドポイント位置サーバ（303）へ要求を送ることができる。次にエンドポイント位置サーバ（303）は、最もよく分かっている構成要素の要求されたアドレスに応答する。次にサーバメッセージングインターフェイス（316）は、将来の使用のために戻れさたアドレスをキャッシュに入れることができる。この例では、ルート設定テーブル（319）またはエンドポイント位置サーバ（303）は、第４の構成要素（314）へのメッセージを第２のサーバメッセージングインターフェイス（317）へ送ることを示す。
【００５３】
第５の段階（504）では、第１のサーバコンピュータ（301）上でホストされている第１のサーバメッセージングインターフェイス（316）は、ＬＡＮ（304）を介して、第２のサーバコンピュータ（302）上でホストされている第２のサーバメッセージングインターフェイス（317）へメッセージを送る。第６の段階（505）では、第２のサーバメッセージングインターフェイス（317）は、サーバプロセスがホストされている関係する第２のインバウンドのルート設定テーブル（320）を調べて、メッセージの送り先の第４の構成要素（314）と関係するエンドポイントを判断する。この第２のインバウンドのルート設定テーブル（320）は、第４の構成要素（314）が第３のサーバプロセス（307）内でインスタンス生成されたとき、または第４の構成要素（314）が他のところから第３のサーバプロセス（307）へ移動したときに、第４の構成要素（314）がホストされているサーバプロセスを識別する情報をキャッシュに入れる。このような構成要素の移動については、別途記載する。
【００５４】
この例では、インバウンドのルート設定テーブル（320）は、第４の構成要素（314）と関係する第４のエンドポイント（315）が、第３のサーバプロセス（307）内に存在することを明らかにする。第７の段階（506）では、第２のサーバメッセージングインターフェイス（317）は、メッセージを、第３のサーバプロセス（307）内でホストされている第４のエンドポイント（315）へ送る。第８の段階（507）では、第４のエンドポイント（315）は、第４の構成要素（314）へメッセージを送る。
【００５５】
メッセージ自体は常に送り回されるわけではないことは、既に記載した。メッセージがネットワーク（ＬＡＮ 304）上を送られるときのみ、読み取られ、書き込まれるバイトのコンセプトがある。サーバメッセージングインターフェイスと関係するサーバプロセスとの間を移動するとき、電送中の（一般的に数バイトのみの大きさである）メッセージに対してキーは事実上１つだけ存在する。このキーはポインタから実際のメッセージデータへ迅速に再びマップされる。
【００５６】
オブジェクトの移動
既に記載したように、所与の構成要素と関係するエンドポイント内の全通信状態を保持する結果の１つは、構成要素とエンドポイントとのアセンブリが、プロセス間を動的に移動するのに適することである。オブジェクトごとに実行される本発明のメッセージングは、このように動的に移動しても、構成要素間の通信を継続することができる。
【００５７】
構成要素は形状および大きさが多様になる。構成要素はサーバプロセスによって1つのプロセスから別のプロセスへ移動するように命令される。次に構成要素は第１のプロセスによって直列化され、メッセージとして宛先プロセスへ送ることができる。このメッセージは、宛先プロセスにおいて受取られると、纏まりを分解され（unbundle、バンドル解除）、構成要素を再構成することができる。直列化、伝送、および纏まりの分解（unbundling）を行うやり方は、問題の開発者の選択に相当に依存する。
【００５８】
同様にエンドポイントは、関係する構成要素と共に移動する必要があるが、エンドポイントの直列化、伝送、および纏まりの分解は、エンドポイント自体の周知の性質が与えられるより均一なやり方で実行することができる。
【００５９】
例示的に、ここでは第２のサーバプロセス（306）から第３のサーバプロセス（307）へエンドポイント（313）を移動するプロセスを図３に関して示し、エンドポイント移動プロセスのフローチャートを図６に関して示すことにする。
【００６０】
第３のエンドポイント（313）について第３のサーバプロセス（307）へ移動する命令の次に、第１の段階（600）では、第1のサーバメッセージングインターフェイス（316）は、第３のエンドポイント（313）へのメッセージ送信を終えるように命令される。
【００６１】
第２の段階（601）では、その状態を含む第３のエンドポイントオブジェクト（313）が直列化される。この直列化はパケットメッセージを生成し、各ヘッダは宛先識別およびバイト流のペイロードを含む（エンドポイントの状態は、とくに、単一のメッセージにおける使用可能なバイト数を越えて、相当に‘大きい’）。
【００６２】
既に記載したように、関係する構成要素（312）を移送する並行プロセスは、問題の開発者によって特定されるやり方で実行されることになることが喚起される（この開発者は開発者が生成した構成要素の知識をもち、したがって効果的な転送を行うことができる）。
【００６３】
第３の段階（602）では、メッセージは第1のサーバメッセージングインターフェイス（316）へ送られる。
【００６４】
上述の宛先識別は、例えば宛先メッセージングインターフェイス（317）および宛先プロセス（307）を、１対の１６ビットの値によってそれにコード化し、これを抽出して、一連のメッセージが送られることになる場所を判断することができる。この場合に、第1のサーバメッセージングインターフェイス（316）は、メッセージを第２のサーバメッセージングインターフェイス（317）へ送らなければならないことを明らかにする。
【００６５】
第４の段階（603）では、メッセージは第２のサーバメッセージングインターフェイス（317）、すなわち意図された宛先プロセス（307）に対して責務を負うサーバメッセージングインターフェイスへ送られる。別途記載するように、これらのメッセージは、例えば、それらがエンドポイント間のメッセージを含むのではなく、高レベルの制御情報を含む指標と共に送ることができる。
【００６６】
第1のサーバメッセージングインターフェイス（316）が責務を負っている第３の構成要素（313）が最早何れのプロセスにおいてもホストされないという意味で、第１のサーバメッセージングインターフェイス（316）はさらに、第１のインバウンドルート設定テーブルを更新する。これは、第３の構成要素（313）が第２のサーバメッセージングインターフェイス（317）が責務を負っているサーバプロセスへ移動するという意味で、第１のアウトバウンドルート設定テーブル（319）を更新することになる。
【００６７】
第５の段階（604）では、メッセージは宛先サーバプロセス、この場合は第３のサーバプロセス（307）へ送られる。
【００６８】
第６の段階（605）では、メッセージは要求されたときに、まとまりを分解されて、第３のサーバプロセス（307）において第３のエンドポイント（313）を再生成する。第３のエンドポイント（313）は、いったん再生成されると、第３のサーバプロセス（307）においていったん再生成された第３の構成要素（312）に再び付加することができる。その通信状態の一部として、関係する構成要素を移送する並列プロセスが、このときに構成要素をまだ再生成していないときでさえ、エンドポイント（313）は、いったん生成されると、関係する構成要素（312）へ意図されたメッセージを受諾して、待ち行列に入れることができることに注意すべきである。
【００６９】
このやり方では、第３の構成要素（312）および関係するエンドポイント（313）は、第１のサーバコンピュータ（301）上の第２のサーバプロセス（306）から、第２のサーバコンピュータ（302）上の第３のサーバプロセス（307）へ移動したことになる。関係するエンドポイント（313）をもつ第３の構成要素（312）は、移動命令の前にメッセージングに加わり、再生成後も加わり続けることができるとき、短期間の間メッセージを生成できないが、構成要素および関係するエンドポイントはメッセージの形態で送られることが分かるであろう。
【００７０】
しかしながら、第１のサーバメッセージングインターフェイス（316）のルート設定テーブル（318，319）の更新の結果が、第３の構成要素（313）についてのメッセージが、第２のサーバプロセス（306）から第３の構成要素（313）を移動した後で、第１のサーバメッセージングインターフェイス（316）によって受け取られるとき、第１のサーバメッセージングインターフェイス（316）は、単に第２のサーバメッセージングインターフェイス（317）へメッセージを送るだけで、再設定されたエンドポイントへ伝えることができる。とくに、エンドポイントについてのメッセージが第１のサーバメッセージングインターフェイス（316）に到達するとき、最初に第１のインバウンドルート設定テーブル（318）を使用して、それを関連するプロセスへ伝える試行をする。エンドポイント（315）は、第１のサーバメッセージングインターフェイス（316）が責務を負うプロセス内に最早位置していないので、この試行は失敗することになる。次に第１のサーバメッセージングインターフェイス（316）は、エンドポイント（315）の移動先の位置（307）を識別するアウトバウンドルート設定テーブル（319）を使用して、メッセージを前送りにルート設定する。
【００７１】
より一層高度な無効の宛先へのメッセージングについては、別途記載する。
【００７２】
クライアント／サーバクラスタアーキテクチャ
図３に関する記載において既に示したように、多数のクライアントコンピュータをサーバコンピュータクラスタ（300）と接続することができる。ここでも、適切なコンピュータは、例えばMicrosoft Windows（商標）を実行するコンピュータがよく知られている。
【００７３】
図７は、例えば図３に示したような第１および第２のサーバコンピュータ（700，701）を含むサーバコンピュータを示している。ここでも各サーバコンピュータ（700,701）は、少なくとも１つのそれぞれのサーバプロセス（702,703）をホストする。さらにここでも、各サーバプロセスは少なくとも1つのそれぞれの構成要素（704，706）およびそれぞれの関係するエンドポイント（705,707）をホストする。さらにここでも、各サーバコンピュータ（700，701）はそれぞれのサーバメッセージングインターフェイス（708,709）を用意されている。
【００７４】
図７はさらに、多数のクライアントコンピュータ（710，711）を示している。各クライアントコンピュータは、少なくとも1つのそれぞれのクライアントプロセス（712，713）をホストする。各クライアントプロセスは、それぞれの関係するエンドポイント（715,717）をもつ少なくとも1つのそれぞれの構成要素（714，716）をホストする。
【００７５】
各クライアントコンピュータ（710，711）は、第１および第２のインターフェイスコンピュータ（718，719）を介して、サーバコンピュータクラスタの、第１および第２のサーバコンピュータ（700，701）の両者へ接続される。各サーバコンピュータ（700，701）は、ＴＣＰ／ＩＰのような確実なパケット接続プロトコルを使用して、高バンド幅リンクを介して各インターフェイスコンピュータ（718，719）へ接続される。各クライアントコンピュータ（710，711）は、ＰＳＴＮ接続上でモデムを使用して与えられる低バンド幅リンクを介して、インターフェイスコンピュータ（それぞれ、718，719）の1つのみに接続される。ＵＤＰ／ＩＰのような不確実なパケット接続プロトコルが適切に使用される。第１および第２のインターフェイスコンピュータ（718，719）は、それぞれ第１および第２のクライアントメッセージングインターフェイス（720，721）を与えられている。
【００７６】
メッセージング機構において、メッセージの性質に関する‘ヒント’を示す能力を含むことが望ましい。これらには、例えばメッセージの優先度、優先度時間の修正、活動時間、内容組み合わせ指標、および信頼性のフラグに関する表示を含む。このやり方では、クライアントメッセージングインターフェイス（720，721）は、とくに、輻輳が低バンド幅リンク上に存在する環境において、各メッセージと関係するヒントに反応して、可能な限り効果的にクライアントへのリンクトラヒックを管理することにしている。
【００７７】
低バンド幅リンクのこのような管理におけるとくに適切で好都合で効果的な方式は、出願人の連合王国（United Kingdom）特許出願第GB 9907445.2号に示されており、これから優先権が発行された国際特許出願第WO 00/62506号によって権利を主張されている。
【００７８】
サーバプロセス（702）においてホストされているゲーム構成要素（704）は、クライアントプロセス（712）内に位置しているゲーム構成要素（714）に対して意図されたメッセージを生成することができる。このメッセージは、このゲーム構成要素（704）と関係するエンドポイント（705）を介して送ることができる。メッセージは、プロセスを実行しているサーバ（700）と関係するサーバメッセージングインターフェイス（708）へ送られる。サーバメッセージングインターフェイス（708）は、アドレッシングテーブルを調べて、何れのクライアントメッセージングインターフェイス（720）が、メッセージがアドレス指定されている構成要素（714）が置かれているクライアントプロセス（712）に責務を負うかを明らかにすることができる。
【００７９】
宛先エンドポイントが‘到達する’ことができる場所を判断するための検索において、サーバメッセージングインターフェイス（316，708）が関連するメッセージングインターフェイスを位置決めすることが分かるであろう。このメッセージングインターフェイスは、（上述の図５に関して記載した例のように）別のサーバメッセージングインターフェイス（317）、または（この場合のように）クライアントメッセージングインターフェイス（720）の何れであってもよい。
【００８０】
サーバメッセージングインターフェイス（708）はメッセージを、適切なインターフェイスコンピュータ（718）上でホストされる関連するクライアントメッセージングインターフェイス（720）へ送る。クライアントメッセージングインターフェイス（720）はメッセージを、低バンド幅接続上のインターフェイスコンピュータ（718）とクライアントコンピュータ（710）との間で、クライアントプロセス（712）へ送ることができる。メッセージは、関係するエンドポイント（715）を介して、メッセージがアドレス指定される構成要素（714）へ送ることができる。
【００８１】
同様に、クライアントコンピュータ（710，711）上で実行されているプロセス（712，713）においてホストされている構成要素（714，716）は、サーバプロセス（702，703）においてホストされている構成要素（706，704）へメッセージを伝えることができる。
【００８２】
代わりの例では、インターフェイスコンピュータ（718，719）も同様に簡単にサーバプロセス、すなわちサーバメッセージングインターフェイスおよびクライアントメッセージングインターフェイスの両者する１つの機械をホストできることに注意すべきである。例えば、ゲームが普及するのにしたがって、単にクライアントメッセージングインターフェイスを実行するための一定の機械を予約する選択肢と共に、追加の機械を加えることができる。
【００８３】
さらに、サーバメッセージングインターフェイス／クライアントメッセージングインターフェイスは、次に示す３つの別個の構成要素を含む：
（ａ）メッセージングインターフェイス−イン／アウトルート設定テーブルを用意して、ネットワーク上でメッセージを送信する；
（ｂ）サーバメッセージングインターフェイス−メッセージングインターフェイスおよびサーバプロセスへのインターフェイスを組込む；
（ｃ）クライアントメッセージングインターフェイス−メッセージングインターフェイスおよびクライアントプロセスへのインターフェイスを組込む。
（サーバメッセージングインターフェイスおよびクライアントメッセージングインターフェイスは２つの別個のプロセスであるが、これらはメッセージングインターフェイスの形態で一緒にコードの大部分をもつ）。
【００８４】
このやり方では、例えばゲームをするための分散形のクライアント／サーバシステムが用意され、本発明にしたがって、非常に動的な移動を可能にし、ゲーム構成要素および関係するエンドポイントのオブジェクトのメッセージングを可能にする。
【００８５】
高度なメッセージング機構
上述のメッセージングは、１つの構成要素から別の構成要素へのメッセージ送信を行うエンドポイントの通信状態の比較的に簡単な特定に依存する。上述から、例えば、メッセージングのシーケンス中に構成要素が移動しても、１つの構成要素から別の構成要素へ送られるメッセージのシーケンスが全て意図された宛先構成要素へルート設定できることが明らかであるが、この簡単な機構は、メッセージのシーケンスが、送られたのと同じ順番で目標の構成要素において受け取られることを保証していないことが分かるであろう。
【００８６】
エンドポイントの通信状態をより完全に記載することによって、一般的に次に示すものを表わす：
（ａ）識別（アイデンティティ、ＩＤ）；
エンドポイントが生成されたシステム内に独特の（ユニークな）、３２ビット値。
（ｂ）未処理のメッセージのリスト；
これは、エンドポイントに到達したが、まだ処理できないメッセージのリストである。これは、エンドポイントを新しい位置に移動するが、まだオブジェクトに付加されていないときに使用される。
（ｃ）出力（outgoing）ディストリビュータの収集（別途記載する）；
これらは、エンドポイントに関係するオブジェクトがメッセージを送るために生成されたディストリビュータである。
（ｄ）入力(incoming)ディストリビュータの収集（別途記載する）；
これらは、遠隔のエンドポイント上で出ディストリビュータと対にされ、出ディストリビュータの対で動作して、確実にメッセージが正しく伝えられるようにする。例えばストリーム（下記参照）上を送られるメッセージは、ワイヤ上で、（それにシーケンス番号を与える）StreamOutから、（伝送前にメッセージが確実にソートされるようにする）StreamInへ向かう。入ディストリビュータは、本発明にしたがって技術を使用する開発者から事実上隠され、一定のタイプの出ディストリビュータを生成する結果としてのみ生成される。
【００８７】
ここで、さらに３つの高度なメッセージング機構、すなわち（Ｉ）“ストリーム（Stream）”、（II）“反復子（Replicator）”、および（III）“ソース（Source）”について記載する：
（Ｉ）第１のこのようなメッセージング機構は‘ストリーム’と呼ばれる。
【００８８】
メッセージのシーケンスが、１つの構成要素のエンドポイントから、別の構成要素のエンドポイントへ送られるとき、シーケンスのためのストリーム機構を呼出すことによって、シーケンスが送信側のエンドポイントから発信されたのと同じ順序で宛先のエンドポイントに到達することを確実にする。
【００８９】
ストリーム上で送られるメッセージは、ソースおよび宛先エンドポイントと一緒に、シーケンス番号、およびそれらを送るのに使用されるストリームの識別で分類される。このシーケンス番号を使用して、宛先のエンドポイントに到達したときに、メッセージを元のシーケンスへ再び順序付けることができる。ストリーム上を送られる最初のデータメッセージは‘ストリームスタート’メッセージとしてタグを付けられ、入力ストリームディストリビュータを生成して、このストリーム上に到達するメッセージを処理しなければならないことを受信側エンドポイントに知らせる。ストリーム上を送られる最後のメッセージは、‘近ストリーム（close stream）’メッセージであり、それが関係する入力ストリームディストリビュータを破壊することを受信側エンドポイントへ知らせる。
【００９０】
出力するストリームの生成には、次のデータを必要とする：
（ａ）識別；
それが生成されたエンドポイント内に独特の、１６ビットの値。
（ｂ）宛先エンドポイントの識別；
ストリーム上を送られるメッセージの宛先。
（ｃ）シーケンス番号；
これは、次のメッセージを類別する（stamp）ためのシーケンス番号である。
（ｄ）有効なフラグ；
ストリームが、その宛先へ伝達するのに失敗したことを検出したか否かを判断するのに使用される。
【００９１】
入力する順序付けられたストリームの生成には、次のデータを必要とする：
（ａ）１６ビットの識別；
これは、出力用のディストリビュータ識別と同じであり、したがって識別はイン／アウトのディストリビュータの対と一緒である。
（ｂ）シーケンス番号；
これは、エンドポイントの関係するオブジェクトへ伝達する次のメッセージのシーケンス番号である。
（ｃ）伝達されていないメッセージリスト；
これは、シーケンスから外れて到達したメッセージのリストであり、伝達前に失ったメッセージを待たなければならない。
【００９２】
（II）第２のこのようなメッセージング機構は、‘反復子（レプリケータ）’と呼ばれる。
【００９３】
反復子を使用して、多数の宛先に特定のメッセージを送ることができる。メッセージが１つの構成要素のエンドポイントから送られ、多数の目標構成要素と関係する多数のエンドポイントにアドレス指定されるとき、反復子機構を呼出すことによって、メッセージの最低数のみのコピーが、メッセージを受け取る全ての送信先エンドポイントのために作られることを確実にする。例えば、クライアントの構成要素が、幾つかのコンピュータクラスタ上でホストされている多数の構成要素へ伝達することを意図されているメッセージを送るとき、反復子機構を呼出すことによって、宛先オブジェクトごとに１つのコピーをサーバコンピュータクラスタへ送るのではなく、メッセージは、要求に応じてコピーされて宛先の構成要素の各々へ送られる前に、１つのみのコピーでサーバコンピュータクラスタへ送られることを確実にする。反復子機能の使用によって、ネットワークトラヒックを最小値に維持するのを助けることが明らかになるであろう。
【００９４】
出力する順序付けられていない反復メッセージの生成が必要とされる：
（ａ）識別；
それが生成されたエンドポイント内の独特の、１６ビットの値。
（ｂ）宛先エンドポイントのリスト；
反復子上を送られるメッセージの宛先。
【００９５】
出力する順序付けられていない反復子：
順序付けられた反復子は、順序付けられていない反復子と同じ長所、すなわちネットワークの効率的な使用および生成されたトラヒックの最小化を与える。さらに加えて、全てのメッセージは送られた順番で宛先へ伝えられることも確実にされる。これは、出力メッセージに添付されたシーケンス番号をもつ、ストリームディストリビュータ、および各受信側エンドポイントにおける入力する順序付けられた反復子ディストリビュータと同じやり方で管理される。唯一の別の厄介な問題は、動作の次のシーケンスで発見される：
１．反復子r1は、エンドポイントe1上に存在する；
２．エンドポイントe2はr1に加えられ、メッセージm1およびm2は反復子r1を介して送られる；
３．エンドポイントe2はr1から取除かれ、メッセージm3およびm4は反復子r1を介して送られる；
４．エンドポイントe2は再びr1へ加えられ、メッセージm5およびm6は反復子r1を介して送られる；
５．エンドポイントe2はr1から取除かれる。
【００９６】
（第１のメッセージが‘開始’および最後の閉鎖メッセージとしてマークを付される）簡単なストリーム機構を使用し、これらの動作が素早く連続して行われると仮定するとき、２つの別個の有効なシーケンスはe2へ移動中である。これらはm1+'start flag'/m2/closeおよびm5+'start flag'/m6/closeである。ネットワークにおけるメッセージの再順序付けによって、第２のシーケンスが到達するとき、最初にこれは有効なシーケンスとして処理され、メッセージは間違ったシーケンスで伝送される。
【００９７】
解決案は、上述の競合条件が生じなくなるまで、順序付けられた反復子から除去された宛先を、それが除去された宛先のシーケンス番号と一緒に記憶することである。記憶時間量は、ネットワーク内で待ち時間によって管理され−宛先が再び加えられ、一方で競合条件が依然として可能であるとき、新しいシーケンスは生成されず、その代わりに受信者のシーケンス番号を、再送信が行われる値へ進める（advance）（“パッドする（pad）”）ためにメッセージが送られる。上述の例を続けるために、正しいメッセージシーケンスは、m1+'start flag'/m2/pad 2 to 5/m5/m6である。
【００９８】
宛先が、解決するために、この競合条件に要求される時間期間内で反復子に再び加えられないとき、最後の終了メッセージを送ることができる。ここでも先の例を続け、段階（５）の段階の後でe2が再びr1に加えられないとき、最後のメッセージシーケンスは、m1+'start flag'/m2/pad 2 to 5/m5/m6…delay…closeである。
【００９９】
この最後の終了メッセージによって、入力する順序付けられた反復子のディストリビュータは受信側エンドポイントにおいて破壊される。その生成には次のデータを必要とする：
（ａ）識別；
それが生成されたエンドポイント内に独特の、１６ビットの値。
（ｂ）現在の宛先エンドポイントのリスト；
反復子上を送られるメッセージの宛先。
（ｃ）シーケンス番号：
これは、次のメッセージ上で類別するためのシーケンス番号である。
【０１００】
（ｄ）‘除去する’シーケンス計数、および同時に“除去される”シーケンス計数を備えた、最近の除去された宛先エンドポイントのリスト：
これを使用して、何れのエンドポイントが反復子の宛先リスト内に最近存在していたかを追跡し、エンドポイントのオブジェクトが再びそれらの１つを加えるとき、それに“シーケンス開始”のメッセージを送るのではなく、シーケンス番号を最後の値から進めることができる。これは、迅速な追加／除去／追加のシーケンスで競合条件を回避するのに必要とされる。
【０１０１】
入力する順序付けられた反復子は、“ストリーム”に関して働くが、さらに閉フラグ（close flag）を含み、この閉フラグは、シーケンスが再スタートされたとき（すなわち、sender went remove x（送り側がremove xに進んだとき））、待機、タイムアウトｘ(= send closure to x（ｘに閉止を送る）)、ｘ追加、データ送信(= send start sequence to x（ｘに開始シーケンスを送る）)に設定される。閉止および開始シーケンスが競合するとき、受信者は誤った順番でそれらを得てしまい、閉止フラグについて閉止が失われていると理解する。
【０１０２】
（III）第３のこのようなメッセージング機構は、‘ソース’と呼ばれる。
【０１０３】
ソースは、特定のメッセージを多数の宛先へ送る点で反復子に類似している。しかしながら、ソースは反復子とは異なり、送信する構成要素が、送り先の他の構成要素を選択する代わりに、構成要素は、‘選択された’ソースから送られたメッセージに‘加入する’ことを選択することができる。したがってソースは、この構成要素が、メッセージを必要とする全ての構成要素へメッセージをどのように送るかについて心配する必要なしに、構成要素によって幅広く使用されるメッセージの‘発行（publication）’を許可する。むしろ、構成要素が特定のソース構成要素からメッセージを必要とするとき、ソース機構を使用することによって単にメッセージに加入することができる。
【０１０４】
順序付けられていないソースから出力するメッセージを生成するには、次に示すものが必要とされる：
（ａ）識別；
それが生成されたエンドポイント内に独特の、１６ビットの値。
（ｂ）各宛先ごとの加入計数をもつ現在の宛先エンドポイントのリスト；
これらはソース上を送られるメッセージの宛先である。加入計数を使用して、受け取った加入／未加入メッセージ数を追跡し、無効の加入状態ではメッセージの順番の混乱は生じない。
【０１０５】
順序付けられたソースから出力するメッセージを生成するには、同じデータが必要であり、さらにまた、順序付けられていないソースに関しては、次のものが必要とされる：
（ｃ）シーケンス番号
これは、次のメッセージを類別するシーケンス番号である；
（ｄ）‘除去’シーケンス計数および同時に“除去された”シーケンス計数をもつ、最近の宛先エンドポイントのリスト。
これを使用して、何れのエンドポイントがソース宛先リスト内に最近存在しているかを追跡し、エンドポイントオブジェクトが再びそれらを加えると判断するとき、それに“シーケンス開始”のメッセージを送るのではなく、シーケンス番号を最後の値から進めることができる。これは、迅速な追加／除去／追加のシーケンスで競合条件をを回避するのに必要とされる。
【０１０６】
入力する順序付けられたソースは：順序付けられた反復子に関する同じデータを要求する；
順序付けられていないソースおよび反復子は、入力するディストリビュータをもたないことに注意すべきである。メッセージが宛先に到達するとき、そのまま通してもよい。
【０１０７】
例示的に、サーバクラスタにおいてホストされている構成要素から、各クライアントコンピュータ上でホストされる多数の構成要素へメッセージを送るプロセスを、適切なアーキテクチャを示す図８と、別のプロセスのフローチャートを示す図９とを参照して記載することにする。
【０１０８】
第１のサーバプロセス（801）を実行する第１のサーバコンピュータ（800）内では、関係するエンドポイントをもつ第１のゲーム構成要素（802）は、状態更新メッセージを、第２、第３、および第４のゲーム構成要素（803,804,805）へ送ることを必要とし、なお第２、第３、および第４のゲーム構成要素（803,804,805）は、第１、第２、および第３のクライアントコンピュータ（809,810,811）上でそれぞれ第１、第２、および第３のクライアントプロセス（806,807,808）においてホストされている。
【０１０９】
第１の段階（900）では、第１のゲーム構成要素（802）はメッセージを要求し、要求状態更新を使用して、それを埋める。この情報は、共有されるメモリへ直接に書き込まれる。
【０１１０】
第２の段階（901）では、第１のゲーム構成要素（802）はメッセージを、関係するエンドポイントを介して、サーバメッセージングインターフェイス（812）上でホストされている関連する予め規定された反復子へ送る。この場合に、反復子は、第２、第３、および第４のゲーム構成要素（803,804,805）へメッセージを伝えるために用意されている。この段階では単に、制御コードおよびポインタをサーバプロセス(801)からサーバメッセージインターフェイス(812)を介して共有メモリへ転送することを要求する。
【０１１１】
第３の段階（902）では、サーバメッセージングインターフェイス（812）はアウトバウンドルート設定テーブルにおいてルックアップを実行し、宛先のエンドポイント（803,804,805）へ伝えるために、何れのクライアントメッセージングインターフェイスにメッセージを送る必要があるかを判断する。この場合に、インターフェイスコンピュータ（814）上でホストされている同じクライアントメッセージングインターフェイス（813）へ接続されたクライアントコンピュータ（809,810,811）の３つ全てを使用して、メッセージの１つのみのコピーがＬＡＮ上で送られる必要がある。
【０１１２】
第４の段階（903）では、サーバメッセージングインターフェイス（812）はメッセージをクライアントメッセージングインターフェイス（813）へ送る。
【０１１３】
第５の段階（904）では、クライアントメッセージングインターフェイス（813）は、メッセージのコピーを、第２、第３、および第４のエンドポイント（803,804,805）および関係するゲーム構成要素をホストしているクライアントコンピュータ（809,810,811）の各々へ送る。既に示したように、顧客伝送プロトコルを使用して、待ち時間を最低値へ低減することができる。
【０１１４】
第６の段階（905）では、各クライアントコンピュータにおいてホストされている各エンドポイント（803,804,805）はメッセージを受け取り、メッセージを関係するゲーム構成要素へ送る。
【０１１５】
このやり方では、サーバクラスタ内でホストされている第１のゲーム構成要素（802）は、各クライアントコンピュータ（809,810,811）上でホストされている第２、第３、および第４のゲーム構成要素の各々に対して状態更新を送り、一方でネットワークトラヒックを最低に維持することができる。
【０１１６】
既に記載したように、無効な（invalid）宛先へ送られるメッセージを取扱うための別の機構も用意されている。これは、メッセージ送信者が特定の宛先が最早有効（valid）でないことを明らかにするのに使用できる機構である。
【０１１７】
メッセージが送られるとき、伝達の失敗についてのアクノリッジメントを要求しているとマークを付すことができる。宛先が最早存在しないために、メッセージを伝達できないとき、このマーキングは検査される。必要であれば、メッセージは‘バウンス（bounce）’メッセージへ変換され、送信者へ戻される。次に送信者は入力メッセージを受け取り、“バウンスされた”としてフラグを立てられる。次に送信者は、それが誰からバウンスされたかを知るためにメッセージを検査することができる。
【０１１８】
この失敗についての追跡は、メッセージが送られるときに特定される２つの形態で入力する。１つの形態では全メッセージを戻し、何れのメッセージの伝達に失敗したかを送信者が正確に検査できるようにしている。別の形態ではメッセージヘッダのみを戻す。これは、送信者が、宛先が最早有効でないことを識別する必要がある−（したがって、送信者はメッセージの送信を停止できる）が、何れのデータを送るのに失敗したかを厳密に知る必要がないときに有益である。
【０１１９】
これは、ストリーム／反復子／ソースが、宛先が無効であるときを検出し、それにしたがって状態を更新する機構であることに注意すべきである。例えば、反復子は、失敗のアクノリッジメントを要求するときに全てのメッセージにマークを付す。バウンスメッセージを受け取るとき、反復子のエンドポイントは反復子に知らせ、反復子は有効な宛先のリストから宛先を除去する。構成要素がそれを要求するとき、反復子のエンドポイントは、このタイプの変更に関して、そのディストリビュータの１つへも伝える。
【０１２０】
適切なパケットメッセージフォーマット
確実な、または不確実な機構の何れかについて転送できるメッセージは、フォーマットを次のように適切に使用することができる。
【０１２１】
メッセージインターフェイス間で実行される転送プロトコルは、適切に次の形態をとることができる：
[4 byte - header data] [2 bytes - payload len] [1 bytes - payload type] [………payload………]。
【０１２２】
これらの‘パケット’の各々の処理は、ペイロードタイプに依存して行われる。例示的に、1組のオプションでは：
（ａ）INTER EMS    −    メッセージはメッセージインターフェイスの内にある。ペイロードは、キャッシュを更新する、エンドポイントｘにおいて情報の送信を停止する、エンドポイントｘは現在はこの位置である、などといった情報を保持する；
（ｂ）DP TO DP    −    メッセージはディベロッパーのプロセスを意図している。この場合のペイロードは通常エンドポイント移動データである。ヘッダデータフィールドは宛先ディベロッパープロセスの識別子を与える；
（ｃ）EP TO EP    −    メッセージは、エンドポイントからエンドポイントへのメッセージを含む。この場合のヘッダデータフィールドは、宛先エンドポイントの識別子を含む；
（ｄ）EP TO EPS    −    メッセージは１つのエンドポイントから多数のエンドポイントへのメッセージを含む。この場合にヘッダデータフィールドは宛先のエンドポイント数を含み、エンドポイントの実際のリストはペイロードの最後に付されている。
【０１２３】
このプロトコルは、システムを中心として実際にメッセージを伝える転送プロトコルを表わしているが、もちろん処理されていないネットワーク用語（raw network terms）に関して、実際にはこれよりも相当に階層形である。これは、例えば、イーサネットネットワークの２つのサーバメッセージインターフェイス上の２つのエンドポイント間でのメッセージ送信は階層形にされる：
[ethernet header] [IP header] [TCP header] [Mari Transport header] [EP Message Header] [Data]。
【０１２４】
プロトコルの第２の層はエンドポイントに対して明らかにされ、適切なヘッダは次のテーブルに示した形態をとる：
【表１】
0004546009.tif 000002
【０１２５】
同様に、ダイヤルアップインターネット接続においてクライアント上でのエンドポイントへのメッセージの送信は、次の形態をとる：
[ppp header] [ip header] [UDP header] [Mari Client Transport header] [Mari Client Message header] [Data]。
【０１２６】
有利なアプリケーション
アウトライン。モバイルオブジェクトを使用してロードバランシングを行う；  シナリオ。大きい分散形環境における共通のタスクは、移動エンティティ（例えば、プレーヤの表示）が一定の範囲内の他のモバイルエンティティの存在について知らされることを確実にする。これは通常、オーラ衝突検出（aura collision detection、オブジェクト周辺の重要でない現象の接近検出）と呼ばれ、簡単なピタゴラスのアルゴリズムによって達成できるが、これはｎ２の問題である；  アプローチ。環境を異なる領域に細分し、‘オーラマネージャ（aura manager）’の活動で領域を割り当てる。エンティティは関連するオーラマネージャに接近する新しいエンティティに関してそれらに知らせることができる。世界中のエンティティの分散が変わると、各オーラマネージャと関係する処理オーバーヘッドは変化する。エンドポイントを動かす能力によって、サーバホストと通信しているオブジェクトに影響を与えずに、それらの間を中心としてこれらのオーラマネージャを転送するのをより簡単にし、したがってロードバランシングを簡単に達成することができる。
【０１２７】
アウトライン。データをクライアントへトリックリングし、一方でユーザはゲームを行う（すなわち、クライアントは多数のサーバと多数の実時間の対話を行なう）；
シナリオ。ユーザを待機させて、一方でクライアントが最新のパッチおよび文書変更をフェッチするのではなく、ゲームのバックグラウンドにおいて更新をトリックルするのがより好ましい。ゲームが再開されたとき、この新しいデータを自動的に取り込むことができる；
アプローチ。送られるデータを一連の別個の小さいメッセージへ分割する。最初の数個を確実に送るが、−しかし−非常に低い優先度で、最後のメッセージについての送信の受取りを要求する。ユーザはゲーム中に活動中である（したがってネットワークトラヒックを生成する）一方で、これらのメッセージの優先度が低いので、クライアントネットワークリンクのヘッドにおいてそれらは待ち行列に入れられる。しかしながら、余分のスロットがこのリンク上に生成されるとき、これらのパケットの１つは送られ、全てが送られるときは、送信の受取りは送信者へ伝えられる。ここでプロセスはメッセージの次のグループについて繰返される。
【０１２８】
アウトライン。サーバ間で機能を分割する；
シナリオ。ゲーム内の知能をもつ移動性のプレーヤ以外のキャラクタは２つの別個の機能領域をもつ。一方は、複雑で特定的なＡＩコードと、それを知能的に知能的に活動させるために必要とされるデータベースである。他方は、物理的な身体の振舞いを表わす相当により軽量のコードおよびデータである。これらの２つの領域の構成を分割して、多数の長所を与える。例えば、キャラクターが他のエンティティに接近するとき、他のエンティティの全てを共通のアドレススペースへもってきて、物理的な同期性の精度を向上することが有益である。しかしながら、ＡＩモデルに関係する全てのデータを移動すると、加えられるオーバーヘッドは大きくなり過ぎる；
アプローチ。ＡＩをゲームに供給するタスクに専用のサーバ上にＡＩに、要求されるコードおよびデータを置く。物理的な表示を処理するために設計されるコードおよびデータを、システムを中心として容易に移動できる単一のモバイルオブジェクトに位置付ける。次に１対のストリームを介してこの２つを一緒にリンクし、物理的な表示が携わっているのが何れのプロセスホッピングであるかに関わらず、これらを確実に順序付けて、通信できるようにする。
【０１２９】
アウトライン。位置更新を伝送する；
シナリオ １。プレーヤの位置を、１つのクライアントから他の関連するクライアントへ送る；
アプローチ。プレーヤのキャラクタを表わすオブジェクトを生成し、それをエンドポイントへ付加する。エンドポイント上にソースを生成し、位置更新のために指定された周知の名前を付す。プレーヤの位置に関心のあるクライアントは、このソースに加入し、それへ発行された位置更新を受け取ることができる。したがって、ネットワークは非常に効果的に使用され（ソースを使用することによって、システムはメッセージのルート設定を最適化することができる）、コードが非常に簡単になる（情報を発行するクライアントは、誰へ情報を送る必要があるかについて心配する必要がない）。
【０１３０】
シナリオ ２。クライアントへ送られる位置更新の総数が、クライアントのネットワークリンクの容量を越えるとき、グレースフルパフォーマンスデグラデーション（graceful performance degradation）を行うように、送信位置が更新する；
アプローチ。各移動オブジェクトについて、その位置更新メッセージを使用するための一連のメッセージの優先順位を事前定義する。例えば、リスト４、２、３、１は、一連の位置メッセージを優先度４、２、３、１、４、２、３、１、４などで生成する。さらに加えて、各位置更新メッセージは、位置更新の期間に等しい活動時間に割り当てられる。僅かにロードされたクライアントリンクは、それらが到達する全ての位置更新を処理する。容量が増加するのにしたがって、より低い優先度のメッセージがストールされ、タイムアウトされる。このやり方では、クライアントにおける世界モデルの精度は、余分なローディングのもとで劣化される一方で、最悪の場合のエラーを最小にするグレースフル線形方式（graceful linear way）で劣化する。各オブジェクトに対して使用される優先度のリストを慎重に選択することによって、クライアントリンクの使用に優先度を与えることができ（例えば、主として装飾のオブジェクト（decorative object）はリスト４、４、４、４、４、１を使用して、重いローディングのもとで、その更新の６の中の１のみを伝えることを確実にする）ことにも注意すべきである。
【図面の簡単な説明】
【図１】  各クライアントと全ての他のクライアントとの非常に簡単な相互接続を示す図（図１ａ）と、より高度なアプローチにおいて、各クライアントを単一の中央サーバに接続することを示す図（図１ｂ）。
【図２】  より高度なアプローチにおいて、多数のクライアントの各々をインターフェイスを介して、単一の中央サーバではなく、多数のサーバに接続することを示す図。
【図３】  本発明を使用するのに適したサーバコンピュータクラスタを示す図。
【図４】  エンドポイント識別割当てプロセスのフローチャート。
【図５】  構成要素から構成要素へのメッセージングプロセスのフローチャート。
【図６】  エンドポイント移動プロセスのフローチャート。
【図７】  本発明を使用するのに適したクライアント／サーバ構成を表わす図。
【図８】  別の適切なクライアント／サーバ構成を表わす図。
【図９】  別のメッセージングプロセスのフローチャート。
【図１】
0004546009.tif 000003
【図２】
0004546009.tif 000004
【図３】
0004546009.tif 000005
【図４】
0004546009.tif 000006
【図５】
0004546009.tif 000007
【図６】
0004546009.tif 000008
【図７】
0004546009.tif 000009
【図８】
0004546009.tif 000010
【図９】
0004546009.tif 000011