(57)【要約】      （修正有）【課題】多数の参加者間での協働的通信におけるリアルタイム性能の改善を可能とする。【解決手段】情報が、配布されたインタラクティブ・アプリケーションについての状態情報の一部を少なくとも含んでおり、サーバ・ユニットが、クライアント・ユニットの少なくとも１つから受信したアプリケーションの状態情報を格納する状態情報格納手段と、クライアントから受信した状態情報を、ネットワーク内の少なくとも１つの他のノードに送り、状態情報格納手段に格納された情報の少なくとも一部を、少なくとも１つのクライアントに送信する送信手段と、を備えている、サーバ・ユニットによって改善される。このようにしてアプリケーションの状態の全部が、ネットワーク内の１つ以上のユニットによって保持され得、これは各クライアントが状態全部を格納する必要をなくし、そのため各クライアントについてのメモリ及び帯域幅の要件を低減する。【選択図】なし【特許請求の範囲】
【請求項１】
少なくとも第１及び第２のクライアント・ユニットと接続可能なサーバ・ユニットであって、前記第１及び第２のクライアント・ユニットの両方によって同時に影響を及ぼし関与することができる状態を有する、配布されたインタラクティブ・アプリケーションを実行させるために、該サーバ・ユニットによって前記第１及び第２のクライアント・ユニット間の通信を可能とするように構成されており、前記サーバ・ユニットが、
−少なくとも前記第１のクライアント・ユニットから、前記アプリケーションの状態についてのアプリケーション状態情報を受信する第１の受信手段と、
−アプリケーション状態情報を格納する状態情報格納手段と、
−少なくとも前記第１のクライアント・ユニットから、前記第１のクライアント・ユニットに送信されるべきアプリケーション状態情報についての優先度情報を受信する第２の受信手段と、
−受信した優先度情報を格納する優先度情報格納手段と、
−前記状態情報格納手段と協働して、前記優先度情報に応じて、前記第１のクライアント・ユニットにアプリケーション状態情報を送信する第１の送信手段と、
前記第１及び第２の送信手段と前記第１及び第２の受信手段とを有する少なくとも１つのアプリケーション・ルータと、
前記情報格納手段を有するアプリケーション・サーバと、
を備えることを特徴とするサーバ・ユニット。
【請求項２】
前記アプリケーション・サーバと前記少なくとも１つのアプリケーション・ルータとが、別々のハードウェア・ユニットで実現されている
ことを特徴とする請求項１に記載のサーバ・ユニット。
【請求項３】
前記アプリケーション・サーバと前記少なくとも１つのアプリケーション・ルータとがソフトウェアによって実現されており、前記アプリケーション・サーバと前記少なくとも１つのアプリケーション・ルータとに関するそれぞれのソフトウェアが、確保されたコンピュータ・リソースを有する
ことを特徴とする請求項１に記載のサーバ・ユニット。
【請求項４】
前記アプリケーション・ルータが、ストリーム・オブジェクトを受信し、それを少なくとも１つの他のアプリケーション・アクセス・サーバに送信するように構成されている
ことを特徴とする請求項１から３のいずれか１項に記載のサーバ・ユニット。
【請求項５】
前記アプリケーション・ルータが、通信セッションに関係する他の全てのアプリケーション・アクセス・サーバに、前記ストリーム・オブジェクトをブロードキャストするように構成されている
ことを特徴とする請求項４に記載のサーバ・ユニット。
【請求項６】
前記アプリケーション・ルータが、基本オブジェクトを受信し、それを少なくとも１つのアプリケーション・サーバのデータベースへの格納のために前記アプリケーション・サーバに送り、前記アプリケーション・サーバから基本オブジェクトに関するアドレス指定されたデータ・パケットを受信し、それをクライアント・ユニット及び少なくとも１つの他のサーバ・ユニットの少なくとも一方に送るように構成されている
ことを特徴とする請求項１から５のいずれか１項に記載のサーバ・ユニット。
【請求項７】
前記アプリケーション・ルータが、前記アプリケーション・サーバから制御情報を受信し、それをクライアント及び少なくとも１つの他のサーバ・ユニットの少なくとも一方、及びサイト・マネージャの少なくとも一方に送るように構成されている
ことを特徴とする請求項１から６のいずれか１項に記載のサーバ・ユニット。
【請求項８】
請求項１から７のいずれか１項に記載のサーバ・ユニットの少なくとも１つと、少なくとも１つのクライアント・ユニットとを備える
ことを特徴とする通信ネットワーク。
【請求項９】
少なくとも１つの第２のアプリケーション・アクセス・サーバと、前記第１及び第２のアプリケーション・アクセス・サーバを接続する接続手段とを更に備え、通信リソースが前記接続手段に確保され得る
ことを特徴とする請求項８に記載の通信ネットワーク。
【請求項１０】
少なくとも１つのアプリケーション・アクセス・サーバを制御するように構成された少なくとも１つのサイト・マネージャを更に備える
ことを特徴とする請求項８又は９に記載の通信ネットワーク。
【請求項１１】
少なくとも１つのアプリケーション・ロビー・サーバと前記少なくとも１つのサイト・マネージャとの間のインタフェースを形成するように構成された、ロビー・アクセス・サーバを更に備える
ことを特徴とする請求項１０に記載の通信ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
［技術分野］
本発明は通信ネットワークに関し、より詳細には、そのようなネットワークのアプリケーションのいくつかのユーザ間のリアルタイム通信に関する。
【０００２】
［従来技術の説明］
マルチユーザ通信のアプリケーションは、例えば、マルチユーザのゲームのために、現在開発されている。このようなゲームは、同じＬＡＮあるいはインターネットなどの大きなネットワークの異なった部分に接続された数人のユーザによってプレーされるであろう。そのようなアプリケーションに対しては、３つの主な同期モデルが使用される。すなわち、クライアント−サーバ同期、ピアツーピア同期あるいはブロードキャスト同期である。インターネット上のいくつかのマルチユーザ・ゲームには、今日１０００００人に達するプレーヤが係わり、その数千人は同時にプレーすることがある。現在使用される全ての同期方法はかなり長い遅延を生ずる。従って、現在インターネットによってプレーされるマルチユーザ・ゲームは、速度が重要でないゲームである。例えば、数分の１秒以内に起こったことにユーザが反応しなければならない、カー・レーシング・ゲームや対戦ゲームのような高速アクション・ゲームは、あらゆる標準的な同期方法を使用しても許容できる品質でプレーできない。
【０００３】
ダイヤルイン・ネットワークは通常クライアント−サーバ同期を使用する。この場合、サーバは全てのプレーヤからデータを受信する。サーバは、各プレーヤが必要とする情報を理解し送信しなければならない。このシステムでは中央サーバが明らかにボトルネックとなる。中央クライアント−サーバ型ゲームは、２〜２５０のプレーヤをサポートできる。サービスする数が増えると更新レートは２Ｈｚ程度まで遅くなる。中央サーバは、転送距離の増大とサーバ内の処理及びスケジューリングの遅延との両方の理由でレイテンシ（待ち時間）を付加する。例えば、クライアントが米国の西海岸におり、サーバが米国の東海岸にある状況について考える。クライアント−サーバ・モードの動作により、約８０ｍｓの転送のレイテンシと少なくとも数１０ｍｓの処理のレイテンシが生じる。
【０００４】
従って、クライアント−サーバ同期は、遅延が重要である多数のプレーヤでのリアルタイムのアプリケーションに適していない。
【０００５】
ピアツーピア同期は、全てのクライアントが他の全てのクライアントにアプリケーション・データを直接送ることを意味する。このモデルは公共的なインターネットによってプレーされるゲームに、しばしば使用される。ゲームの開発者は、プレーヤがゲームの設定及び実行中のゲームに参加するために集まる、フリー・アプリケーション・ロビー・サーバを提供する。ゲームは一旦開始すると、ゲーム開発者のサイトからは何のリソースも使用せずに、ピアツーピア・モードでプレーされる。
【０００６】
ピアツーピア同期は明らかにスケーラビリティに問題がある、なぜならネットワークの負荷はプレーヤの数の二乗に比例するからである。すなわち、クライアントのアクセス帯域幅とＣＰＵ能力の要件はプレーヤの数に比例する。各パケットのペイロードは１０〜４０バイトであり、これはプロトコルのオーバヘッドが通常５０％より多いことを意味する。ゲームの小さなパケットはプロトコルのオーバヘッドを大きくする。しかしながら、ヘッダ圧縮方法でこのオーバヘッドはかなり小さくできる。インターネットによるピアツーピアのゲームは、予期できない遅延及び同期の喪失により頻発する崩壊（collapses）で損なわれる。
【０００７】
続けると、ピアツーピア同期はまた、距離が比較的短くユーザの数が限定された通信を行う小さなネットワークに最も良く適合する。
【０００８】
ブロードキャスト同期は、ローカル・エリア・ネットワーク（ＬＡＮ）での限定された数のプレーヤには使用できるが、大きなネットワークには適していない。
【０００９】
同期方法によって課せられた制限のため、現在の技術では良好なリアルタイム特性を有する参加者が多数の通信は実現できない。
【００１０】
各ユーザに一度送信する代わりに、各マルチキャスト・サーバに一度だけ情報を送信すればよい点で、マルチキャストによりネットワーク内で送信すべき情報はかなり削減できる。各マルチキャスト・サーバは、情報をコピーしてそれを接続されたユーザに送信する。各ユーザが受信する必要のある情報が選択されるであろう。これはサーバ間及び各サーバとそのユーザ間の両方のトラフィックを減少するであろう。このような解決策をゲームに適用することが、米国特許番号５，８４１，９８０に開示されている。
【００１１】
米国特許番号５，８４１，９８０に開示されたシステムでは、各ユーザはユーザが現在の状況において関連するゲームの部分に関する情報、例えば、ユーザが現在いる地理的領域に関する情報だけを有している。状況が変わると、例えば、ユーザが別の部屋に入ると、新たな状況で重要な情報をユーザは入手できないであろう。
【００１２】
［発明の目的］
本発明の目的は、通信ネットワーク、特に多数の参加者間での協働的通信におけるリアルタイム性能を改善することである。
【００１３】
［発明の概要］
上記目的は、通信ネットワークで使用されるサーバ・ユニットによる本発明によって達成され、前記サーバ・ユニットは、少なくとも第１のクライアント・ユニットから情報を受信する受信手段を備えており、前記情報が、配布されたインタラクティブ・アプリケーションについての状態情報を少なくとも含んでおり、前記サーバ・ユニットが、
−前記第１及び第２のクライアント・ユニットから受信手段によって受信した情報に含まれる、アプリケーションの状態情報を格納する状態情報格納手段と、
−前記少なくとも第１のクライアント・ユニットから受信した状態情報を、ネットワーク内の少なくとも１つの他のノードに送る第１の送信手段と、
−前記状態情報格納手段に格納された情報の少なくとも一部を、前記少なくとも１つのクライアント・ユニットに送信する第２の送信手段と、を備えることを特徴とする。
【００１４】
これにより、ネットワーク内の１つ以上のユニットのアプリケーションの全ての状態を保つことが可能となり、これは各クライアントが全体の状態を格納する必要をなくし、このため各クライアントで必要なメモリ容量と各クライアントでとの通信に必要な帯域幅とが削減される。アプリケーションの状態の各部分が１つ以上のネットワーク・ノードに格納されれば、バックアップ機能が達成される。
【００１５】
上記目的は、通信ネットワークの端末で使用されるクライアント・ユニットによる本発明によって達成され、該クライアント・ユニットは、配布されたインタラクティブ・アプリケーション・ソフトウェアを備えており、
−前記端末からの入力を読み取る少なくとも１つの入力手段であって、前記入力は配布されたインタラクティブ・アプリケーションのアプリケーション状態情報を構成する、入力手段と、
−アプリケーション状態情報をアプリケーション・アクセス・サーバに送信する送信手段と、
−前記アプリケーション・アクセス・サーバから配布されたインタラクティブ・アプリケーションの少なくともアプリケーション状態情報を受信する受信手段と、
−前記状態情報を表示する手段と、を備えることを特徴とする。
【００１６】
本発明による方法及び装置は、特にリアルタイム通信に係る、配布されたインタラクティブ・アプリケーションに有用である。
【００１７】
好ましくは、前記サーバ手段の受信手段は、
−前記第１のクライアントが受信を望む情報について配布されたインタラクティブ・アプリケーションのオブジェクトを識別するサブスクリプション情報を、少なくとも前記第１のクライアントから受信し、
−少なくとも１つのクライアント・ユニットに該クライアントユニットから受信したサブスクリプション情報に応じて情報を送信し、
−前記サーバ・ユニットが前記サブスクリプション情報を格納する少なくとも１つのクライアント・サブスクリプション・リストを更に備える、ように構成される。
【００１８】
このため、前記クライアント・ユニットは、入手可能な情報をそこから受信すべき、配布されたインタラクティブ・アプリケーションの少なくとも１つのオブジェクトを指定する、サブスクリプション情報を設定する手段と、前記サブスクリプション情報を前記アプリケーション・アクセス・サーバに送信する手段とを備える。
【００１９】
これにより、各ユーザに送信されるべき情報の量が減少し、このため伝送遅延が減少し、特定のユーザにとって最も重要な情報だけがそのユーザに示されるので、各ユーザが情報を分析するのを助長する。各クライアントはどれが重要なのかを自身で決定できる。
【００２０】
好適な実施形態では、受信手段は、少なくとも第２のクライアントから前記第１のクライアントに関する緊急情報を受信するよう構成される。緊急情報が第１のクライアントに送信されてもよく、あるいは前記第２のクライアントに関するアプリケーション状態情報が、前記緊急情報に応じて少なくとも前記第１のクライアントに送られてもよい。緊急情報はまた、あるアプリケーション状態情報が前記第１のクライアントに送られるべきでないことを示すのに使用されてもよい。緊急情報はクライアントのサブスクリプションを変更するのに使用されてもよい。
【００２１】
前記好適な実施形態では、クライアント・ユニットは、該クライアントから状態情報をできるだけ速く受信すべき、少なくとも１つの他のクライアントを特定するための、緊急データを設定する手段を更に備える。
【００２２】
有利なことには、アプリケーション状態情報を送信するクライアント・ユニットの送信手段が、パケットがサーバ・ユニットに送信される前に、各パケットがアプリケーションの一部を構成するオブジェクトに関連するように、オブジェクト情報パケット内の情報を配置するように構成され、前記受信手段が、サーバ・ユニットから受信したパケットから情報を抽出するように構成される。
【００２３】
アプリケーション・アクセス・サーバ・システムは、アプリケーションから独立しており、そのため広い範囲の異なったアプリケーションをサポートできる。
【００２４】
一緒に動作するアプリケーション・アクセス・サーバ・ユニットは、好ましくは確保されたあるいは管理された伝送容量を提供する、ネットワークによって通信するかもしれない。アプリケーションの合計した帯域幅の要件は、ネットワーク管理システムによって推定することができ、アプリケーション・アクセス・サーバ・ユニットを接続する確保されたネットワークに、十分なネットワーク・リソースが割り当てられ得る。リソースが利用可能であるときだけ、新たなアプリケーションが許可される。ネットワーク管理は、アプリケーション・アクセス・サーバの再送及び複製の方針も制御する。マルチキャスト及びリソース予約プロトコルを、アプリケーション・アクセス・サーバ間の合計したストリームに使用できる。このシステムの利点は、プレーヤ・レベルでのリソース予約が必要で無いことである。アプリケーションのクライアントは通常、全体の統計的性能が良好であれば、偶発的に失ったパケットを処理する。本発明によるアプリケーション・アクセス・サーバを使用することは、アプリケーション・アクセス・サーバが常にゲームの状態を維持するので、ゲームのクライアントが同期を失うことが永久にないことを意味する。
【００２５】
［実施形態の詳細な説明］
本発明による装置及び方法を、添付図面を参照してより詳細に説明する。
【００２６】
図１は本発明による通信ネットワークの実施形態を示している。本発明によれば、ネットワークは少なくとも１つのアプリケーション・アクセス・サーバを備えている。図１では、第１（１）、第２（３）及び第３（５）のアプリケーション・アクセス・サーバが示されており、これらは例えば、確保された電気通信ネットワークなどのネットワーク７によって互いに接続されている。他のあらゆるタイプのネットワークでも良いが、インターネットなどのネットワーク・リソースを確保することができないネットワークでは、負荷が重くなると品質が低下するであろう。いくつかのクライアント１１、１２、１３、１４、１５もネットワーク７に接続されている。クライアントはアプリケーション・アクセス・サーバ１、３、又は５に、以下で詳細に説明するように、当該技術分野で知られているあらゆる方法で接続することができる。
【００２７】
参加者の多くのメンバーが同時にアプリケーションの状態に影響を及ぼし関与する、例えば、リアルタイムのマルチユーザ・ゲームなどの、配布されたインタラクティブ・アプリケーションを実行する目的で、クライアントはアプリケーション・アクセス・サーバを通して互いに通信する。各クライアントと該クライアントと接続されているアプリケーション・アクセス・サーバとの間の接続は、通常、モデム接続などの容量の小さな接続である。一方、２つのアプリケーション・アクセス・サーバ間では、大きくかつ可変のネットワーク容量が利用できる。従って、本発明によるアプリケーション・アクセス・サーバは、各クライアントにそのクライアントに最も関係のある情報だけを送信することにより、各クライアントに送信される情報が減少されるような方法で、アプリケーションの状態についての情報を処理するように構成されている。アプリケーション・アクセス・サーバ間では、伝送容量は通常問題とならず、そのためアプリケーション・アクセス・サーバ間でより多くの情報を送信することができる。
【００２８】
それ自体は既知の種類のアプリケーション・ロビー・サーバが、１つ以上ネットワーク内にあってもよい。これらのサーバは、通常、クライアントが、課金機能などを処理する、特定のタイプのサーバへ登録するのを許可する機能を有している。
【００２９】
本発明によれば、アプリケーションに必要なソフトウェアは、クライアント１１、１２、１３、１４、１５内にある。従って、本発明による通信機能を使用するためには、ユーザは自分が必要とするアプリケーション・ソフトウェアを持っていることを確かめる必要がある。例えば、インターネットからのダウンロードあるいはＣＤ−ＲＯＭからのインストールなどのこの技術分野で既知のあらゆる方法で、アプリケーション・ソフトウェアが獲得される。アプリケーションにとって必要であれば、ユーザはアプリケーションをロビー・サーバに登録する必要がある。一般に、アプリケーション・ロビー・サーバ２１は、通常はＩＰアドレスなどのアドレスと、１つ以上のアプリケーション・アクセス・サーバ１、３、５のポート番号を提供するが、このアドレスは他のあらゆる方法で獲得されてもよい。
【００３０】
ユーザはこの技術分野で一般的な方法で、通常は１つのアプリケーション・アクセス・サーバあるいはアプリケーション・アクセス・サーバのプール（pool）のＩＰアドレスを入力することによってアプリケーション・アクセス・サーバに接続する。同じアドレスで識別されるネットワーク内のいくつかのノードの適切な１つを選択するのに、いくつかのアルゴリズムが存在する。アプリケーション・アクセス・サーバは、以下でより詳細に説明するように、ユーザから情報を受信して、ユーザへの情報の送信を開始する。クライアントがアプリケーション・アクセス・サーバにログインする代わりに、アプリケーション・ロビー・サーバがクライアントのネットワーク・アドレスをアプリケーション・アクセス・サーバに送信することもできる。
【００３１】
アプリケーションが、参加者によって制御されるオブジェクトのセットからなると想定する。オブジェクトは、人間の参加者によって制御されるかクライアントで生成されるアプリケーションのエンティティであり、例えば、乱数発生器や他の予測できない計算処理によって制御されて、各アプリケーション・クライアントで局所的に再生されるものではない。アプリケーション・オブジェクトは、参加者が直感的にオブジェクトとして認識するもの、あるいはゲームのフィギュアであるが、プレーヤによって制御される環境変数などのバックグランド・データの構成物であってもよい。各オブジェクトは通常、アプリケーションの実行中に変更され得る、特性のセットと属性を有している。ゲームにおいてこれらの特性は、キャラクタの強さ及び他の能力、あるいは車の最大速度であり、属性は、例えば、キャラクタによって制御されるアイテム等であろう。
【００３２】
ユーザから受信した情報は通常、シグナリング・オーバヘッドに加えて３つの異なったタイプの情報を含み、それらは、状態情報、サブスクリプション情報、制御データ及び緊急情報である。状態情報は、オブジェクトあるいはユーザによって制御されるオブジェクトについての情報であり、アプリケーションの他のユーザにも分配されるべきものである。サブスクリプション情報は、アプリケーション・アクセス・サーバによって提供される異なったアプリケーション・オブジェクトに関するユーザの優先度をリストで表わす。例えば、あるオブジェクトのグループに関する情報は、利用可能となったときに一度に、あるいはできるだけ頻繁に受信されるべきであるが、別のオブジェクトのグループからの情報は急を要するものではない。例えば、帯域幅が足りない場合、許容可能な遅延や優先順位の形式で、いくつかの優先度レベルが設定されるであろう。クライアントによって生成される緊急情報は、他のクライアントが自身のサブスクリプションに含まれていないオブジェクトについての情報を受信するように、別のクライアントのサブスクリプションを変更あるいはオーバーライドするため、あるいはクライアントがある種の情報を受信していないのを確かめるために使用される。３つのタイプの情報全てについて以下でより詳細に検討する。
【００３３】
例として、多数のユーザによってプレーされるリアルタイムのゲームのアプリケーションを説明する。このようなゲームは現在は、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）内などの、互いに極めて近くに位置する限定された数のユーザでプレーされる。広域ネットワークでプレーされれば、そのようなゲームには将来は、通常は大きなゲーム・フィールドあるいは仮想的図形領域にわたって分布する数千のプレーヤが係わるであろう。上記で検討したように、従来の技術では、許容できる品質でこれを実現するのは可能ではない。
【００３４】
各プレーヤは、仮想ゲーム領域において彼の近くで起こることによってのみ、すぐに影響を受ける。遠く離れた別のプレーヤは、このプレーヤより変更が重要ではない。例えば、プレーヤが第１の敵対するプレーヤと戦うと、仲間のプレーヤがが助けに来るかもしれず、第２の敵対するプレーヤが仲間のプレーヤを止めようとするかもしれない。同時に、他のプレーヤは後で重要となるかもしれないことを行うであろが、プレーヤは戦いを勝ち抜くことに主に専念する。従って、第１の敵対するプレーヤの動きは、ただちに表示されなければならない。仲間のプレーヤ及び第２の敵対するプレーヤの動きにも高い優先度を与えるべきであり、遠く離れて起こることには低い優先度を与えるべきである。
【００３５】
上記で説明した例では、明らかに、別の時点では他のプレーヤ、通常はいずれか所与の時点でユーザの近くに位置するプレーヤが最も高い優先度を持つので、プレーヤの構成は変化するであろう。
【００３６】
アプリケーション・アクセス・サーバは、アプリケーション・クライアントとの通信を扱う。該サーバは、アプリケーションの状態に影響を与えるクライアントの動作に関する情報と他の情報とを受信する。該サーバはまた、他の参加者からのアプリケーション状態情報を、参加者のサブスクリプションに従って参加者に送信する。各アプリケーション・クライアントは、受信するアプリケーション情報に関するサブスクリプションを設定し、これらサブスクリプションに関する情報をアプリケーション・アクセス・サーバに送信する。アプリケーション・アクセス・サーバは、アプリケーション・アクセス・サーバによってサービスされるクライアントのサブスクリプションの記録を格納し更新する。各クライアントのサブスクリプションは、どのデータをこのクライアントに送信すべきかを決定するのに使用される。クライアントは、別のクライアントに対するサブスクリプションも設定してもよい。ある一つの動作モードでは、マスター・クライアントが例えば、他の全てのクライアントのサブスクリプションを設定してもよい。
【００３７】
あるクライアントが関係するアプリケーション・アクセス・サーバは、そのクライアントのローカル・アプリケーション・アクセス・サーバであり、そのクライアントは、そのアプリケーション・アクセス・サーバのローカル・クライアントと呼ばれる。
【００３８】
アプリケーション・アクセス・サーバはまた、クライアント権限リストを保持する。各クライアントは、１つ以上のゲーム・オブジェクトの状態を変更する権利を持っている。クライアント権限リストは、各クライアントに対して１つのエントリを有し、そこにはクライアントによって制御されるオブジェクトの識別子が格納される。アプリケーション・アクセス・サーバは、クライアントからオブジェクト状態情報を受信する度に権限をチェックする。ゲームの状態は、情報パケット内にある識別子が権限リストのクライアントに対するエントリ内の数と一致したときだけ更新され、そうでなければその情報は無視される。他アプリケーション・アクセス・サーバから来たオブジェクト状態情報は、送信したアプリケーション・アクセス・サーバが権限を既にチェックしたので照合されない。
【００３９】
アプリケーション・アクセス・サーバはまた、アプリケーション状態情報と、選択的にはそれらに対して集められたサブスクリプションとを送信し、同じタイプの情報をそれらから受信する、他のアプリケーション・アクセス・サーバ・ユニットと通信する。通常、他のアプリケーション・アクセス・サーバに送信すべき情報は、いずれの方法でも優先順位を付けたり格納されたりせずに、適切なプロトコルに従ってパッケージ化される。ローカル・クライアントのユーザのサブスクリプションに応じて、各アプリケーション・アクセス・サーバに送信すべき情報を選択することももちろん可能であろう。集められたサブスクリプションは、所与のアプリケーション・アクセス・サーバに属するクライアントからの全てのアプリケーション・オブジェクト要求の合計である。例えば、アプリケーション・アクセス・サーバは、他のアプリケーション・アクセス・サーバに対してマルチキャストを使用してもよい。これは各アプリケーション・アクセス・サーバ・ユニットが必要な全ての更新を受信し、アプリケーション・アクセス・サーバによってゲーム状態が効率的に配布されることを保証する。
【００４０】
緊急データは、そのデータが別のクライアントにとって重要であるが、他のクライアントがこのことに気付いておらず、従って自身のサブスクリプションを設定できない場合に、クライアントによって設定される。従って、緊急度は送信するクライアントによって定義され、受信するクライアントそれぞれで異なっているかもしれない。アプリケーション・アクセス・サーバは、緊急データが待機していれば受信するクライアントに気を配る。緊急情報は、ある種の情報が１つ以上のクライアントに送られるのを禁止するのにも使用されてもよい。
【００４１】
各アプリケーション・アクセス・サーバはまた、アプリケーション状態の完全なあるいは部分的なコピーを格納し更新する。それらの間で、通信セッションに割り当てられたアプリケーション・アクセス・サーバ・ユニットは、完全なアプリケーション状態を格納しなければならない。最も単純な場合には、全てのアプリケーション・アクセス・サーバが完全なアプリケーション状態を格納するが、アプリケーション・アクセス・サーバ間で、オーバーラップする情報を持つ又は持たないように情報を分離することも可能である。そのような解決策は、各アプリケーション・アクセス・サーバへの適切なデータの配布を処理するのに、特別なソフトウェアを必要とする。
【００４２】
アプリケーション・アクセス・サーバは、アプリケーションを設定し、アプリケーションの実行中に参加者を追加しかつ削除し、エラーやネットワークの故障を処理するために、アプリケーション・ロビー・サーバと通信する。
【００４３】
図２は、本発明の実施形態によるアプリケーション・アクセス・サーバ５０をその機能的エンティティで示している。このアプリケーション・アクセス・サーバは、ハードウェアあるいはソフトウェアで実現できる。図２に関しては、概略的説明だけをする。適切なフォーマット及びプロトコルについては後述する。
【００４４】
アプリケーション・アクセス・サーバは、ネットワーク内の各クライアントから、及び他のアプリケーション・アクセス・サーバなどの他のユニットから、入力バッファ５１によってデータを受信する。クライアント、リモート・アプリケーション・アクセス・サーバ及びアプリケーション・ロビー・サーバのそれぞれには１つの入力バッファがあるが、図２では簡潔にするため１つの入力バッファだけが示されている。
【００４５】
ローカルな参加者それぞれの動作は、そのクライアントに関連するアプリケーション・アクセス・サーバの入力バッファに到着する、アプリケーション・オブジェクト・パケットのペイロードとして送信される。これらアプリケーション・オブジェクト・パケットは、参加者によって制御されるアプリケーション・オブジェクトを更新する。アプリケーション・オブジェクト。パケットは、１組の挿入規則を用いてアプリケーション状態レコードに書き込まれる。
【００４６】
クライアントから受信したデータは、３つのタイプのデータ、すなわち、アプリケーションの状態についてのデータ（状態データ）、クライアントのサブスクリプションについてのデータ（優先度データ）及び他のクライアントの時間基準状態に対する要求及びシステムからの他の情報などの他の制御情報、を含んでいてもよい。状態データは、アプリケーション・オブジェクト・パイプライン５３を通ってアプリケーション状態レコード５５に渡される。アプリケーション状態レコード５５は、以下でより詳細に説明するように、関連する全てのオブジェクトに対する全ての状態データを保持する。アプリケーション状態レコードは、上記で説明した緊急データも保持する。
【００４７】
クライアントのグループが定義されてもよく、このグループは例えば、作業グループの参加者や、ゲームの場合には同じチームの参加者を含んでいる。この場合、サブスクリプション及び／又は緊急データもまた、個々のユーザについてだけではなく、ユーザのグループについて指定されてもよい。
【００４８】
制御データ、特に、アプリケーション・オブジェクトについて追加されるあるいは削除される、リアルタイムで処理される必要のないデータは、入力バッファ５１からアプリケーション・アクセス・サーバ制御ユニット５７に渡される。ハードウェアによる実施では、制御ユニット５７はマイクロプロセッサであろう。制御ユニットによって処理される制御データは、例えば、プレーヤ及びオブジェクトの生成及び破壊と、プレーヤ及びオブジェクトのグループに関連するものであり得る。
【００４９】
サブスクリプションは、アプリケーション優先度制御プロトコル・メッセージ・パイプライン５９を通って、アプリケーション・アクセス・サーバによってサポートされる各クライアントのサブスクリプションを含んでいる、クライアント優先度リスト（ＣＰＬ）６１に渡される。サブスクリプションは、クライアント及びアプリケーション・アクセス・サーバ制御ユニットによって更新され得る。制御ユニットは、例えば、別のクライアントから受信した緊急メッセージに応じて、クライアントのサブスクリプションを更新するのを決定できる。
【００５０】
アプリケーション・アクセス・サーバ・システムを用いるアプリケーション・クライアントによって、いくつかの異なった優先順位付け方法が用いられてもよい。簡単な方法は、アプリケーション・クライアントがオブジェクトを列挙したリストをＣＰＬ６１に送ることである。この場合、例えば、ラウンドロビン・モードで、リスト上の全てのオブジェクトが更新されたときに、リストに載っていないオブジェクトが更新され得る。例えば、ラウンドロビン・モードでは、リストの全てのオブジェクトが更新されたら、残りのオブジェクトが更新され得る。特定のクライアントのサブスクリプションは、このクライアントによって設定されたサブスクリプションについての全てのオブジェクトのリストを含んでいる。アプリケーション・アクセス・サーバに格納されたリストに加え、各オブジェクトについて新たな情報が受信されたかどうかを示すフラグを含んでいるのが好ましい。このフラグは、あるオブジェクトについての情報をクライアントに送信する必要があるかどうかを判定するのに使用される。情報がクライアントに送信されたとき、フラグはリセットされる。アプリケーション・アクセス・サーバからオブジェクトについての新たな更新を受信したとき、フラグが再度設定される。
【００５１】
クライアントのサブスクリプションはまた、各オブジェクトに関連した時間間隔と共に定義され得る。そしてクライアントは、例えば、＜オブジェクト番号＞，＜オブジェクト優先度＞，＜オブジェクト更新時間間隔＞，＜フラグ＞、というフォーマットで一連の要求を送信する。簡単なリストは、＜オブジェクト番号＞，＜オブジェクト優先度＞という簡単なフォーマットであってもよい。アプリケーション・アクセス・サーバは、要求内の＜オブジェクト優先度＞フィールドに従って与えられた優先度で、各時間間隔中に各オブジェクトが少なくとも１度更新されるように、クライアントに更新を送信する。いくつかのオブジェクトを全く更新しないように、無限大記号が使用されてもよい。特別な、「新たな完全なオブジェクト状態の送信」フラグが設定されてもよい。このオプションは、クライアントがオブジェクトに対する更新を長い間隔（数秒）で望むときに使用される。所望する時間解像度が状態リフレッシュ間隔よりも長いと、増分による更新の送信は無駄が多くなるだろう。
【００５２】
出力パイプライン６３は、クライアント優先度リスト６１からサブスクリプション情報を受信し、上記で説明した適切なアルゴリズムを用いて、当該クライアントに送信すべき情報をアプリケーション状態レコード５５から探すために、この情報を使用する。選択された状態情報は、アプリケーション状態レコード５５から出力パイプライン６３を通って出力バッファ６５に渡され、出力バッファからクライアントに渡される。制御ユニット５７は、例えば、クロックを同期させるため、あるいはレイテンシの推定値をクライアントに提供するために、制御メッセージをクライアント及びリモード・サーバに送信する。
【００５３】
図２に示したアプリケーション・アクセス・サーバは各タイプのユニットを１つだけ有するように示されているが、好ましくはアプリケーション・アクセス・サーバは、アプリケーション・アクセス・サーバが情報を交換するネットワーク内の各クライアント及び他のサーバ等のそれぞれに対して、１つの入力バッファ５１、１つのアプリケーション・オブジェクト・パケット入力パイプライン５３、１つの優先度メッセージ・パイプライン５５、及び１つの出力処理パイプライン６３及び１つの出力バッファ６５を備えている。代替的に、クライアント又はサーバのグループが、１つの入力バッファ５１、１つのアプリケーション・オブジェクト・パケット入力パイプライン５３、１つの優先度メッセージ・パイプライン５５、及び１つの出力処理パイプライン６３及び１つの出力バッファ６５を共用してもよい。アプリケーション・アクセス・サーバはまた、各クライアント、サーバ等に対して、１つのクライアント優先度リスト６１を備えている。
【００５４】
他のアプリケーション・アクセス・サーバから受信したデータは、他のクライアントからのオブジェクト状態データを含んでいる。それがまた好ましくは各オブジェクトが優先度リストに１度現れるような方法で集められた、これらクライアントからの優先度情報を含んでいてもよい。この場合、各アプリケーション・アクセス・サーバに対して１つの優先度リストが存在し、すなわち、各アプリケーション・アクセス・サーバがクライアントのように取り扱われるように、情報がパッケージ化される。別のアプリケーション・アクセス・サーバから受信した情報は、以下で説明するように、いずれもあるプロトコル処理を実施する必要のある入力及び出力バッファ５１、６５を除いて、クライアントから受信した情報と同様に取り扱われる。代替的には、他のアプリケーション・アクセス・サーバからサブスクリプション情報は全く送信されず、この場合、全ての状態情報がこれらアプリケーション・アクセス・サーバに送信される。
【００５５】
アプリケーション・アクセス・サーバは、全てのプレーヤが同時に更新される、オプションのフェアプレイ・モードを処理する（下記参照）。
【００５６】
上述のように、ネットワーク内にはそれ自体は既知の種類の１つ以上のアプリケーション・ロビー・サーバ（図１の２１）が存在している。アプリケーション・ロビー・サーバは、ゲーム中に構成データを更新するのを受け持ち、アプリケーション・アクセス・サーバに、以下のようなデータを提供する。
【００５７】
・ゲームに参加する新たなアプリケーション・アクセス・サーバ・ユニットのＩＰアドレス又は他のネットワーク・アドレス。
・アプリケーション・アクセス・サーバによってサービスされる参加者を識別するネットワーク・アドレスの更新されたリスト。これにより新たな参加者が進行中のアプリケーションに参加できる。
・列挙されたゲーム・オブジェクトの更新されたリスト。各オブジェクトに対して、状態がアプリケーション・アクセス・サーバ間で配布された場合に、どのアプリケーション・アクセス・サーバがその状態を格納するのを受け持つかが指定される。状態を更新するのを誰が認可されているのかが指定されていてもよい。これにより、ゲーム・オブジェクトの生成、破壊及び制御の変更が可能となる。クライアントもゲーム・オブジェクトの生成及び破壊ができる。
・新たな完全なあるいは部分的なゲーム状態。これにより、アプリケーション・アクセス・サーバがゲーム状態を廃棄したとき、ゲームの中断や故障の後の回復が可能となる。
【００５８】
図３は、本発明によるアプリケーション・アクセス・サーバで使用されるアプリケーション状態レコードの例を示している。各アプリケーション・オブジェクトの状態は、アプリケーション状態レコード内に列挙されたアプリケーション・オブジェクト状態ＡＯＳ１〜ＡＯＳ４として格納される。各アプリケーション・オブジェクト状態は、それぞれ一連のアプリケーション・オブジェクト・パケットＡＯＰ１１〜ＡＯＰ１３、ＡＯＰ２１〜ＡＯＰ２４、ＡＯＰ３１及びＡＯＰ４１〜ＡＯＰ４２からなる。オブジェクト・パケットは、オブジェクト・データ用の入れ物である。アプリケーションからリモート・アプリケーション・クライアント又はサーバに送信された全てのデータは、アプリケーション・アクセス・サーバ・システムによって処理できるように、アプリケーション・オブジェクト・パッケージに包含される。
【００５９】
アプリケーション・アクセス・サーバによって受信された、接続されている他の全てのアプリケーション・アクセス・サーバからの情報は、アプリケーション状態レコード内のアプリケーション・オブジェクト情報を更新するのに使用される。好ましくは、２つのタイプのアプリケーション・オブジェクト・パケットがある。すなわち、１）オブジェクトについての現在のデータ全てを含む基準アプリケーション・オブジェクト・パケット、及び２）参照するＡＰＯのタイムスタンプによって求められる時間から何が変わったかについての情報だけを含む増分パケット、である。ＡＯＳ内の第１のＡＯＰは基準パケットである必要があり、その後に増分パケットあるいは基準パケットの組が続くであろう。あるゲームでは基準パケットだけが生成されるであろう。
【００６０】
アプリケーション状態レコードはまた、他のアプリケーション・アクセス・サーバ・ユニットに配信される必要のあるアプリケーション・オブジェクト・パケットの記録をとる。これは、各要素がフラグのマトリクス、new_cliant_data(i,k)として実現されるデータ構造、new_cliant_dataを用いて行われる。パラメータｉはクライアント番号であり、パラメータｋはアプリケーション・アクセス・サーバ番号である。アプリケーション・オブジェクト・パケットが、外部のアプリケーション・アクセス・サーバに配信されるべきであれば、フラグが設定される。
【００６１】
アプリケーション・オブジェクトを表わすのに、アプリケーション・オブジェクト状態がどのように使用されるのかの例として、図３は、アプリケーション・オブジェクト状態ＡＯＳ１を示している。このオブジェクトがレーシング・ゲームにおける乗り物の位置を示しているとする。乗り物の位置（ｘ１，ｙ１）が、ゲーム時間ｔ１で基準アプリケーション・オブジェクト・パケットＡＯＰ１１のゲームのペイロードとして最初に送信される。帯域幅を節約するために、増分アプリケーション・オブジェクト・パケットＡＯＰ１２として、ゲーム時間ｔ２で位置の相対的変化（Δｘ２，Δｙ２）が送信される。増分アプリケーション・オブジェクト・パケットＡＯＰ１２は、基準として基準アプリケーション・オブジェクト・パケットＡＯＰ１１を指し示している。ゲーム時間ｔ３で、新たな増分位置（Δｘ３，Δｙ３）が第３のアプリケーション・オブジェクト・パケットＡＯＰ１３で送信される。第３のアプリケーション・オブジェクト・パケットＡＯＰ１３は、基準として第２のアプリケーション・オブジェクト・パケットＡＯＰ１２を有している。３つのアプリケーション・オブジェクト・パケットＡＯＰ１１、ＡＯＰ１２、ＡＯ１３の全てを受信した後に、クライアントは時間ｔ３での乗り物の位置を、（ｘ１＋Δｘ２＋Δｘ３，ｙ１＋Δｙ２＋Δｙ３）によって計算できる。
【００６２】
特定のオブジェクトに対して新たなアプリケーション・オブジェクト・パケットが受信されたとき、アプリケーション状態レコードは、そのオブジェクトに属する前のパケット全てを削除し、新たな基準パケットだけを格納してもよい。ゲームのペイロードの構文及び意味は、クライアント端末で実行中のゲームのアプリケーションによってのみ理解されることに注意されたい。データの喪失によって生じる長期の中断を避けるために、アプリケーションは基準パケットを頻繁に送るべきである。
【００６３】
アプリケーションをコーディングする代替的方法は、時間ｔ３でのアプリケーション・オブジェクト・パケットＡＯＰ１３を、基準としてアプリケーション・オブジェクト・パケットＡＯＰ１１を用い、（ｘ１，ｙ１）に対する位置の変化δｘ，δｙを表わすようにすることであろう。これは、第３のアプリケーション・オブジェクト・パケットＡＯＰ１３が到着するとすぐに第２のアプリケーション・オブジェクト・パケットＡＯＰ１２を削除できるので、アプリケーション・アクセス・サーバのメモリを節約できるだろう。ここでクライアントは、時間ｔ３での乗り物の位置を、（ｘ１＋δｘ３，ｙ１＋δｙ３）によって計算する。アプリケーション・アクセス・サーバはアプリケーション・オブジェクト・パケットのヘッダ内の情報を、前のアプリケーション・オブジェクト・パケットの期限が切れ削除できるかどうかを判定するのに使用する。図３では、ＡＯＳ２は４つのアプリケーション・オブジェクト・パケットＡＯＰ２１、ＡＯＰ２２、ＡＯＰ２３及びＡＯＰ２４からなり、ここで最初のＡＯＰ２１は基準パケットであり続く３つのアプリケーション・オブジェクト・パケットＡＯＰ２２、ＡＯＰ２３、ＡＯ２４は増分パケットである。最後の増分はタイムスタンプｔ８を有している。このようにＡＯＳ２は、ゲーム時間ｔ８迄のオブジェクト２の状態を記載している。図３のＡＯＳ３は、オブジェクトを記載するのに十分な１つの基準アプリケーション・オブジェクト・パケットＡＯＰ３１からなる。
【００６４】
新たなクライアントが入って来るのを許可する前に、アプリケーション・アクセス・サーバは、好適な実施形態によれば、必要な地域幅の増加を見積もり、ネットワーク内でこの帯域幅が利用できることを保証するのがよい。このようにする方法は当該技術分野では周知である。容量の問題が全く予期されなければ、このステップは必要ではない。
【００６５】
図４は、本発明によるクライアントを実行するコンピュータの実施形態を示している。コンピュータは、例えば、本発明によるアプリケーション・プログラム１０３などのプログラムが実行される処理ユニット１０１を備えている。処理ユニットはまた、アプリケーション・アクセス・サーバ（不図示）及びもしあればネットワーク内の他のユニットと、通信ソフトウェア１０５によって通信する。アプリケーション・プログラム１０３は、ネットワーク・アプリケーション・インタフェース１０７によって通信ソフトウェア１０５と通信する。ネットワーク・アプリケーション・インタフェースは、アプリケーション・プログラムからのアプリケーション・データを送信し受信する機能を有している。
【００６６】
コンピュータはまた、参加者が現在関係するゲームの一部の外観などのアプリケーションについてのデータを表示する、画面１０９を備えている。アプリケーションにデータを入力するために、例えば、コンピュータにはキーボード１１１、マウス１１３及び／又はジョイスティック１１５が接続されているのがよく、それによりゲーム中のオブジェクトを移動させたり他のタイプの変更を入力できる。
【００６７】
クライアント・アプリケーション１０３は前記入力を受信し、それを処理してその結果を画面１０９で、及び／又は例えばスピーカ及び／又は触覚型の（haptic）表示手段によって表わす。またアプリケーションは、アプリケーション状態データを前記入力に基づいてネットワーク・アプリケーション・インタフェース１０７に送り、そこから該データはアプリケーション・アクセス・サーバに送られる。
【００６８】
通信ソフトウェア１０５及びネットワーク・アプリケーション・インタフェース１０７によって、アプリケーション１０３は、ゲーム・アクセス・サーバから他のオブジェクトに関するアプリケーション状態情報も受信し、それを処理して結果を画面１０９に表示する。
【００６９】
この実施形態では、ネットワーク・アプリケーション・インタフェース１０７は２つの部分、すなわち、アプリケーション・プログラミング・インタフェース１０７Ａとアプリケーション・アクセス・インタフェース（ＡＡＩ）１０７Ｂを含んでいる。このやり方は、以下で検討するように、ネットワークＡＡＩ  １０７Ｂを実現するのに、マイクロソフト  DirectPlayなどの標準的プログラム・モジュールの使用を可能とする。
【００７０】
アプリケーション・アクセス・インタフェース（ＡＡＩ）１０７Ｂは、クライアント端末のソフトウェア・モジュールである。これはネットワーク・インタフェースとネットワークＡＰＩ  １０７Ａとの間の中間モジュールである。アプリケーション・アクセス・インタフェース１０７Ｂは、アプリケーション・オブジェクト・パケットと制御メッセージとを受信して終了し、アプリケーション・オブジェクト・パケットのペイロードがネットワーク・アプリケーション・インタフェースに渡される前に、アプリケーション・オブジェクト・パケットのヘッダを削除する。該インタフェース１０７Ｂはまた、制御メッセージを解釈してそれらをＡＰＩ  １０７Ａに渡すか又は直接処理する。ＡＡＩ  １０７Ｂは、アプリケーション・アクセス・サーバとの通信に必要であるが、クライアント・アプリケーション・プログラム内では実施しない機能を働かせるよう処理する。従って、本発明によるアプリケーション・アクセス・サーバとの使用のために開発されたクライアントにとっては、それは必要ではないだろう。例えば、クライアントがアプリケーション・オブジェクト・パケットにタイムスタンプを押す機能を有していなければ、ＡＡＩがタイムスタンプを押すクロックを扱ってもよい。
【００７１】
アップストリーム方向において、ＡＡＩ  １０７Ｂは、ＡＰＩ  １０７Ａからメッセージ及びオブジェクトを受信する。クライアントからのアプリケーション・オブジェクトに関するデータは、アプリケーション・オブジェクト・パケット形式に変換される。アプリケーション・オブジェクト・パケットは、アプリケーション・アクセス・サーバへの通信リンクによって送信される。
【００７２】
ＡＡＩ  １０７Ｂはまた、アップストリーム・アプリケーション制御プロトコル・メッセージ、特に、アプリケーション制御プロトコル・サブスクリプション・メッセージを生成する。サブスクリプション及び他のアプリケーション制御プロトコル・メッセージを設定するのに必要な情報は、ネットワークＡＰＩを介してアプリケーションから、及びアプリケーション・アクセス・サーバからの緊急リスト・メッセージから抽出する必要がある。
【００７３】
物理的クライアント、例えばゲーム・コンソールが、いくつかのゲーム又はホスト、同じゲームにおいて数人の人間のプレーヤに関与してもよい。論理的アプリケーション・クライアントが、アプリケーション・アクセス・インタフェースの１つのインスタンスに接続されたアプリケーションの１つのインスタンスに対応するとき、各物理的アプリケーション・クライアントは、いくつかの論理的アプリケーション・クライアントを実行できる。本明細書におけるアプリケーション・クライアントは、論理的アプリケーション・クライアントに相当する。論理的アプリケーション・クライアントを指し示すネットワーク・アドレスは、物理的クライアントのＩＰアドレスにアプリケーション・アクセス・インタフェースのポート番号を組合せたものとできる。
【００７４】
アプリケーション・プログラムが開発されるときにアプリケーション・アクセス・サーバ・システムが考慮されると、最高の性能が発揮される。そうすれば、データ受信の好ましい順番を示すサブスクリプションを決定する機能を、アプリケーション・プログラムに含められる。ゲーム内での状況から、受信するプレーヤがメッセージの高い優先度を予測できないことが明らかであれば、メッセージが高い緊急度でコプレーヤ（co-player）に直接送られてもよい。例えば、ゲームでプレーヤ１がプレーヤ２を追い回す状況を考える。プレーヤ２は何も警告無しに突然プレーヤ１に攻撃される。プレーヤ２はプレーヤ１からのメッセージに対して正しい優先度を設定することができないが、プレーヤ１は高い緊急メッセージをプレーヤ２に送信できる。
【００７５】
ネットワークＡＰＩを開発するのに、例えば、マイクロソフト  DirectPlay ＡＰＩを使用してもよい。そしてＡＰＩは、出力をＡＣＰ及びＡＯＰ等にフォーマットするよう要求され、DirectPlay サービス・プロバイダとして表わされてもよい。マイクロソフト  DirectPlay ＡＰＩを使用して、サブスクリプションを抽出する異なった方法が、少なくとも２つある。サブスクリプションが、ローカルな参加者が列挙されたアプリケーション・オブジェクトについての更新を受信する優先度を表わすべきものであることに注意されたい。DirectPlayの「プレーヤ」はメッセージの送信及び受信ができるアプリケーション・エンティティであるので、本明細書でのアプリケーション・オブジェクトは、DirectPlayの表記では「プレーヤ」と同様である。DirectPlayの「プレーヤ」は、人間のプレーヤによって制御されてもよく、あるいは自立型のゲーム・オブジェクトであってもよい。
【００７６】
第１の方法では、DirectPlayの受信方法によって得られた情報が使用される。DPRECEIVE_FROMPLAYERフラグを設定し、lpidFromパラメータを適切に指定することにより、この方法でlpidFromパラメータによって識別される「プレーヤ」からの第１のメッセージを回収することができる。この情報はサブスクリプションを作成するのにアプリケーション・アクセス・インタフェースによって使用され得る。DirectPlay メッセージのキューに識別された「プレーヤ」からの入手可能なメッセージが何もなければ、識別されたアプリケーション・オブジェクトを優先度リストの最上位にすることは合理的であろう。
【００７７】
第２の方法ではDirectPlay送信方法が使用され、idToパラメータがメッセージを受信すべき「プレーヤ」又はプレーヤのグループを識別する。頻繁にメッセージを受信する「プレーヤ」が、ローカルなプレーヤが現在対話しているアプリケーション・オブジェクトに関連しているとみなすのが合理的である。
【００７８】
図５は、本発明により使用され得る通信スタックの例を示している。１つの通信スタックが、図４に示したようなクライアントとアプリケーション・アクセス・サーバとの間の通信に使用される。クライアント及びアプリケーション・アクセス・サーバは、基本的に同じタイプのスタックを備えている。クライアントでは最上位層のスタックが図４のアプリケーション・アクセス・インタフェース層と通信し、アプリケーション・アクセス・サーバではアプリケーション・アクセス・サーバ・ソフトウェアと通信するスタックが示されている。図５は、アプリケーション・アクセス・サーバとネットワーク内の別のユニットとの間で使用する通信スタックも示している。この他のユニットは、例えば、別のアプリケーション・アクセス・サーバ、あるいはアプリケーション・ロビー・サーバであり得る。通信スタックはＯＳＩモデルに適合するように使用される。
【００７９】
クライアントの通信スタックは、クライアント内のアプリケーションプログラミング・インタフェース１０７と通信する。最上位レベルのスタックは、ＡＣＰ／ＡＯＰ層１０９である。このレベルは、図４のアプリケーション・アクセス・インタフェース１０７によって処理される。
【００８０】
ＡＣＰ／ＡＯＰ層１０９から、アプリケーション・オブジェクト・データ又はサブスクリプション情報等の情報を含む、ＡＣＰ／ＡＯＰパケットがリンク層１１１に配信される。リンク・プロトコルは、例えばＰＰＰであり得る。反対方向では、ＡＣＰ／ＡＯＰ層１０９は、アプリケーション・アクセス・サーバから受信した情報パケットからヘッダ情報を削除し、アプリケーション状態をクライアント・アプリケーションに送る。ＡＣＰパケットはＡＡＩ内で終結され得る。サブスクリプション自身は、クライアントがサブスクリプションを処理する機能を有していればクライアント自身で処理される。
【００８１】
最下位の層はチャネル層１１３であり、チャネル・コーディング及び実際の物理的接続を含んでいる。
【００８２】
アプリケーション・アクセス・サーバは、クライアントとの通信のために基本的に同じタイプのスタックを含んでおり、チャネル層１１３’はクライアントのチャネル層に相当する。チャネル層１１３’は、リンク層１１１’によってＡＣＰ／ＡＯＰ層１０９’に接続されている。
【００８３】
アプリケーション・アクセス・サーバのＡＣＰ／ＡＯＰ層１０９’は、ＡＯＰ及びＡＣＰ情報を処理するように構成されているアプリケーション・アクセス・サーバ・ソフトウェアと直接通信する。
【００８４】
アプリケーション・アクセス・サーバは、多くの異なったリンク・プロトコルに対するインタフェースと共に形成され得る。理想的には、アプリケーション・アクセス・サーバは、ＵＤＰ、ＴＣＰ及びＲＴＰを含むあらゆるリンク・プロトコルを処理できるべきである。ＲＴＰは、音声及びビデオ・データの送信のために特別に開発されたプロトコルである。
【００８５】
リンク・プロトコルは、アプリケーション・アクセス・サーバからクライアントへのリンク上でのオーバヘッドが低く保たれるように設計されるべきである。これは、例えば、ＩＰ／ＵＤＰ／ＲＴＰが使用されない適切なリンク・プロトコルを用いること、あるいはＩＰ／ＵＤＰ／ＲＴＰヘッダの効率的な圧縮によって行われ得る。リンク層は、レイテンシをより最小化し、アプリケーション・アクセス・サーバにリンクの特性の情報を提供する必要がある。そのような情報には、予期される帯域幅、ビット誤り率及びリンク・レイテンシが含まれる。
【００８６】
ここではアプリケーション転送プロトコルと呼ぶ、適切な転送プロトコル、ＡＴＰがリンクで使用されるべきであるが、アプリケーション・オブジェクト・パケット及びアプリケーション制御パケットが、リンク・プロトコルを介して直接送信されてもよい。
【００８７】
２つ以上のアプリケーション・アクセス・サーバ間での通信のために、ＩＰパケットのストリームが、ローカル・アプリケーション・アクセス・サーバの出力バッファ６５（図２参照）から、実行中のアプリケーションに参加している１つ以上のリモート・アプリケーション・アクセス・サーバに送信される。ＴＣＰ又はＵＤＰパケットとＴＣＰ又はＵＤＰペイロードとを含む各ＩＰパケットは、アプリケーション転送プロトコル（ＡＴＰ）パケットである。
【００８８】
２つのアプリケーション・アクセス・サーバ間での通信のための通信スタックの最上位のプロトコル層は、クライアントの通信スタックで使用されるものと同様なＡＯＰ／ＡＣＰ層１１７である。アプリケーション・オブジェクト・パケットは、極めて小さい、すなわち、４０バイト以下であるかもしれない。２つのアプリケーション・アクセス・サーバ間での通信をより効率的にするため、いくつかのアプリケーション・オブジェクト・パケットはアプリケーション転送プロトコル（ＡＴＰ）層に集められる。次の層はＴＣＰ又はＵＤＰ層１２１であり、最下位層はＩＰ層１２３であるが、１２１、１２３の両方は当技術分野では周知である。ＩＰ層から情報パケットがリモート・アプリケーション・アクセス・サーバ・ユニットに送信される。出力バッファ・ユニット（図２の６５）は、ＡＴＰペイロードとなるアプリケーション・オブジェクト・パケットを集めるソーティング・バッファの組を有する。これらバッファの構造は、配布の方針によって決定される。リモートアプリケーション・アクセス・サーバのそれぞれに対して、１つのソーティング・バッファがあるかもしれない。
【００８９】
アプリケーション・オブジェクト・パケットは、更新すべきクライアントをリストで表わすフィールドを含んでいてもよい。このフィールドは、アプリケーション・オブジェクト・パケットを受信すべきアプリケーション・アクセス・サーバ・ユニットのリストに変換される。アプリケーション・アクセス・サーバは、クライアント番号をアプリケーション・アクセス・サーバの番号とを突き合わせるテーブルを有している。これは、全ての関連するアプリケーション・アクセス・サーバ・ユニットが、結局は更新されることを意味する。そしてアプリケーション・アクセス・サーバ・ユニットは、アプリケーション・オブジェクト・パケットをそれらのローカル・クライアントに発送する。簡単なオプションの動作モードとしては、全てのアプリケーション・アクセス・サーバ・ユニットが全てのアプリケーション・データを受信する。
【００９０】
ローカル・アプリケーション・アクセス・サーバは、リモート・アプリケーション・アクセス・サーバを介してリモート・クライアントに送信する必要がある、アプリケーション・オブジェクト・パケットを識別する。このため、ローカル・アプリケーション・アクセス・サーバのアプリケーション状態レシーバがスキャンされ、new_client_dataフラグが設定されたアプリケーション・オブジェクト・パケットが見つけられる。アプリケーション・オブジェクト・パケット・ヘッダは、そのアプリケーション・オブジェクト・パケットが送信されるべき１つ以上のクライアント・アドレスをリストで表わす受信者グループ・フィールドを含んでいる。この受信者グループ・フィールドが検査される。クライアント・アドレスは、リモート・アプリケーション・アクセス・サーバのアドレスに変換され、アプリケーション・オブジェクト・パケットのコピーが、受信者であるアプリケーション・アクセス・サーバ・ユニットに対応するソーティング・バッファに挿入される。受信しているアプリケーション・アクセス・サーバあるいはアプリケーション・アクセス・サーバのグループに属する受信者としてのクライアントだけが残るように、受信者グループ・フィールドが各アプリケーション・オブジェクト・パケットのコピーに対して変更される。新たなnew_client_dataフラグが設定される。
【００９１】
アプリケーション・オブジェクト・パケットは、ゲーム・アプリケーションからのペイロードを含んでいる。アプリケーション・アクセス・サーバ・システムは、内部のゲームのペイロード・フォーマットは読み取れない。従ってこのようなメッセージはアプリケーション・オブジェクト・パケット（ＡＯＰ）内に包含される。ＡＯＰのヘッダは、アプリケーション・アクセス・サーバ・システムで読み取られる。これはゲーム・ペイロードのタイムリーな配信のために必要な情報を付加するのに使用される。
【００９２】
ここで検討した実施形態では、ＩＰ、ＴＣＰ、ＵＤＰ及びＲＴＰなどの標準的インターネット・プロトコルに加え、以下の３つの非標準的プロトコルを使用する。
【００９３】
・アプリケーション・オブジェクト・パケット（ＡＯＰ）は、ゲーム・データのコンテナである。ゲーム・アプリケーションからリモート・ゲーム・クライアント又はサーバに送信される全てのデータは、アプリケーション・アクセス・サーバ・システムによって処理されるように、ＡＯＰに包含される。
・アプリケーション制御プロトコル（ＡＣＰ）は、制御メッセージを送信するのに使用される。制御メッセージは、アプリケーション・アクセス・サーバ・ユニット、クライアント及びアプリケーション・ロビー・サーバの間で送信される。
・アプリケーション転送プロトコル（ＡＴＰ）は、アプリケーション・アクセス・サーバ・ユニット間及びオプションとしてアプリケーション・アクセス・サーバとクライアントの間で、集められたゲーム・データを送信するのに使用される。
【００９４】
アプリケーション・オブジェクト・パケットは、ゲーム・アプリケーションからのメッセージを含んでいる。アプリケーション・アクセス・サーバ・システムは、ゲームの内部メッセージ・フォーマットは読み取れない。従ってこのようなメッセージは、アプリケーション・オブジェクト・パケット（ＡＯＰ）に包含される。ＡＯＰのヘッダは、アプリケーション・アクセス・サーバ・システムで読み取られる。これはゲーム・ペイロードのタイムリーな配信のために必要な情報を付加するのに使用される。
【００９５】
アプリケーション・メッセージは、アプリケーション・オブジェクトの状態を完全に定義できるか、そうでなければ基準状態に対するアプリケーション・オブジェクトを表わすことができる。従ってＡＯＰは、基準パケット（ＢＰ）と増分パケット（ＩＰ）の２つのタイプがある。
【００９６】
アプリケーション・オブジェクト・パケットは、ヘッダと後続するゲームに特定のペイロードからなり、ＡＯＰで使用されるヘッダ・フィールドは以下を含む。
１）アプリケーション・オブジェクト番号
２）ＡＯＰが生成されたときのゲームにおける時願を示すタイムスタンプ
３）オプションのパケット番号。オブジェクト番号及びタイムスタンプと組み合わされて、パケットにユニークな識別子を形成する。同じゲーム・オブジェクトに属するいくつかのＡＯＰが、同じタイムスタンプを有するときにだけ、パケット番号が使用される。
４）例えば、音声及び／又はビデオ情報が送信される場合、パケットがこのタイプの情報を含むかどうかを示すフラグが含まれ得る。
５）ＡＯＰが基準パケットか増分パケットかを示すフラグ
６）ＡＯＰが増分パケットである場合、基準ＡＯＰへのポインタ。このポインタは、タイムスタンプと基準ＡＯＰのパケット番号から構成され得る。基準ＡＯＰは基本ＡＯＰ又は増分ＡＯＰのいずれでもよい。
７）メッセージを受信すべきクライアントを表わすレコード。これは、クライアントをリストで表わすこと、あるいは予め定められたクライアント・グループを使用することで行われる。デフォルトでは全てのクライアントがデータを受信する。緊急フィールドは、各受信クライアントあるいはグループ・クライアントに関連する。このフィールドは、メッセージが緊急である場合に、受信者を警告するのに使用される。３つの緊急ビットで十分であろう。
【００９７】
なお、緊急フィールドに設定され得るフラグは、
Forbidden：ＡＯＰはクライアント又はライアント・グループに送信すべきでない
Fair_Play：フェア・プレイ・モードを使用（下記）
Very_Urgent：クライアントの優先度をオーバーライド
Urgent：クライアントが警告される
Normal：クライアントの優先度に従って配信される
Not_Urgent：ベスト・エフォートで配信される
簡単なフォーマットとしては、
＜エントリ数＞＜クライアント１＞＜クライアント１への緊急度＞
＜クライアント２＞＜クライアント２への緊急度＞…
であり、リスト内の後の項目は前の項目をオーバーライドする。
例えば、2,all Forbidden,client_3 Urgent
というフィールドは、全てのクライアントはＡＯＰの受信を禁止されるが、例外としてクライアント番号３はUrgentモードでＡＯＰを得ることを意味する。
【００９８】
８）ペイロードのサイズ。
【００９９】
アプリケーション制御プロトコル（ＡＣＰ）は、ゲーム・クライアント、アプリケーション・アクセス・サーバ・ユニット及びアプリケーション・ロビー・サーバ（ＡＬＳ）の間で制御メッセージを送信するのに使用される。ＡＣＰの概要をここで説明する。ＡＣＰパケットはヘッダとメッセージ本体からなる。
【０１００】
ＡＣＰメッセージは以下のフィールドを含み得る。
１）ＡＣＰメッセージ・タイプ
２）メッセージが生成されたときのゲームにおける時間を示すタイムスタンプ
３）メッセージのサイズ
４）メッセージ本体
メッセージの送信元は高位のプロトコル・レベルで識別されることに注意されたい。以下において、ＡＣＰを用いて送信されるメッセージの概要を説明する。
【０１０１】
クライアントからアプリケーション・アクセス・サーバへのＡＣＰメッセージは以下のものを含み得る。
・クライアント終了。アプリケーション・アクセス・サーバ管理システムは、全てのレコードからそのクライアントを削除し、アプリケーション・ロビー・サーバ（ＡＬＳ）に通知する。ゲームをやめていたら、クライアントはＡＬＳへ通知するのを受け持つ。ＡＬＳは、例えば、最終スコアを送信して他のプレーヤに通知することによって、終了したクライアントとの接続を終了させるのを受け持つ。
・サブスクリプション
・ゲーム・オブジェクト追加。新たなゲーム・オブジェクト番号がアプリケーション・アクセス・サーバで生成され、アプリケーション・アクセス・サーバのメモリがクライアントからオブジェクト状態情報を受信するために割り当てられる。
・ゲーム・オブジェクト削除。更新を受信するリストに記された、全てのクライアント及びアプリケーション・アクセス・サーバ・ユニットが最後の更新を受信した後に、全てのアプリケーション・アクセス・サーバのメモリからオブジェクトが削除される。
・オブジェクトの推定レイテンシ送信。この要求はオブジェクト番号のリストを含む。アプリケーション・アクセス・サーバは、オブジェクトに対してエンドツーエンドで推定されたレイテンシを送信することで応答する。クライアント・アプリケーションは、レイテンシを隠すのに推定値を使用する。
・オブジェクト・グループの定義。そうでなければＡＯＰフィールド内のクライアントとのリンクによって送信しなければならない、オブジェクト番号の長いリストに短い名前を付けられるので、オブジェクト・グループは有用である。アプリケーション・アクセス・サーバは、クライアント・グループ情報を格納し、クライアント・グループをクライアントのリストのエイリアス（別名）として扱う。メッセージのフォーマットは、
メッセージ・タイプ＝クライアント・グループ定義＜クライアント・グループ名＞＜クライアントのリスト＞  などでよい。
・時間基準送信。このメッセージは、アプリケーション・アクセス・サーバから基準時間をダウンロードするのに使用される。
【０１０２】
アプリケーション・アクセス・サーバからクライアントへのＡＣＰメッセージは、以下のものを含み得る。
・緊急リスト。このメッセージは、未読の緊急ＡＯＰが残っている場合、クライアントを警告するのに使用される。アプリケーション・アクセス・サーバは、ＡＯＰ受信者リスト上に現在のクライアントを有する、全ての未読ＡＯＰをスキャンする。緊急リストのフォーマットは、
＜緊急クラス  １＞＜オブジェクト番号のリスト＞＜緊急クラス  ２＞＜オブジェクト番号のリスト＞…以下同様、などでよい。
・レイテンシ推定。これは以下のようなエントリのセットからなる。すなわち、
＜ゲーム・オブジェクト番号＞＜アップストリーム・レイテンシ＞＜アップストリーム・レイテンシ変数＞＜ダウンストリーム・レイテンシ＞＜ダウンストリーム・レイテンシ変数＞  である。「不明」の記号を最初以外のフィールドに使用できる。
・オブジェクト・グループ番号確認。アプリケーション・アクセス・サーバは、クライアントから「オブジェクト・グループ定義」メッセージを既に受信している。これでグローバル・オブジェクト番号が割り当てられたのを確認する。メッセージ本体は、
＜グローバル・オブジェクト・グループ番号＞＜クライアントのオブジェクト・グループ名＞  を含むであろう。
【０１０３】
オブジェクト番号を割り当てる簡単な方法は以下のようなものである。
合計でＮ個のアプリケーション・アクセス・サーバ・ユニットが動作中であると想定する。全てのアプリケーション・アクセス・サーバ・ユニットを列挙する。番号ｋのアプリケーション・アクセス・サーバが新たなオブジェクト番号を要求したら、｛ｋ，Ｎ＋ｋ，２Ｎ＋ｋ，３Ｎ＋ｋ，…｝から最も小さい未使用のオブジェクト番号を割り当てる。
・クライアント・グループ番号確認。アプリケーション・アクセス・サーバは、クライアントから「クライアント・グループ定義メッセージを既に受信している。これでグローバル・クライアント・グループ番号が割り当てられたのを確認する。メッセージ本体は、
＜グルーバル・クライアント・グループ番号＞＜クライアントのクライアント・グループ名＞  を含むであろう。
クライアント・グループ番号を割り当てるのに、グローバル・オブジェクト・グループ番号を割り当てるのと同じアルゴリズムが使用できる。
・クロック同期。アプリケーション・アクセス・サーバは、以下のフォーマットに従って時間基準を送信する。すなわち、
＜クライアント時間＞＝＜時間＞＋＜クライアントのクロックのレイテンシ＞  である。
クライアントは、受信した一連のクロック同期メッセージに従って、ローカル・クロックを調整するアルゴリズムを有している。
【０１０４】
あるアプリケーション・アクセス・サーバから別のサーバへのＡＣＰは以下のものを含み得る。
・集められたサブスクリプション。送信するアプリケーション・アクセス・サーバに属するクライアントが見る必要のあるオブジェクト、すなわち、送信するアプリケーション・アクセス・サーバに情報が送信されるべきオブジェクト、を示す集められた優先度リスト。このリストは単純なクライアント優先度リストと同様なフォーマットである。これは有効なローカル・クライアント優先度リストを合算し、重複部分を削除することで組み立てられる。
・再送要求。このメッセージは、単純な優先度リストと同様なフォーマットであり、リストに示されたオブジェクトの状態を再送する要求であると解釈される。
・オブジェクト・グループ定義。オブジェクト・グループ定義は、アプリケーション・アクセス・サーバ間で配布され得る。オブジェクト番号の長いリストに対してグローバルな名前を使用することで、トラフィックを削減するのを助長する。
・クライアント・グループ定義。クライアント・グループ定義は、アプリケーション・アクセス・サーバ間で配布され得る。
【０１０５】
アプリケーション・アクセス・サーバからアプリケーション・ロビー・サーバへのＡＣＰメッセージは以下のものを含み得る。
・クライアントが終了した。このメッセージは、クライアントが自発的にゲームから抜けたときに送信される。
・クライアントのタイムアウト。クライアントとの通信が長時間ないとき、あるいはクライアントへのリンクが閉鎖されたときに、アプリケーション・アクセス・サーバはＡＬＳにメッセージを送信し得る。ＡＬＳは、ゲームからのクライアントの削除などの更なる動作を決定する。
【０１０６】
ＡＬＳはクライアントとして動作できる。ＡＬＳは例えば、ゲームのスコアを維持するゲーム・オブジェクトを制御するかもしれない。ＡＬＳのポートは、ＴＣＰ／ＩＰなどの「リンク」プロトコルを使用するクライアントとして、ＡＡＳに接続される。従ってＡＬＳは、クライアントと同じメッセージを使用できる。ＡＬＳからＡＡＳへの他のメッセージを以下にリストする。
【０１０７】
以下のものを含むアプリケーション設定情報。
・ＡＬＳを識別するポート番号を含むネットワーク・アドレス
・ゲームをユニークに識別するＵＲＬ
・ゲームに参加している他のアプリケーション・アクセス・サーバ・ユニットのＩＰアドレス
・オプションとして、列挙されたゲーム・オブジェクトのリスト。各オブジェクトに対して、状態を格納するのを受け持つアプリケーション・アクセス・サーバが指定される。誰が状態を更新するのを認可されたかも指定されてもよい。
・オプションとして、格納すべき最初のゲーム状態。
・タイムアウトなどのオプションのデータ指定制御方針。
・アプリケーション・アクセス・サーバ追加。新たなアプリケーション・アクセス・サーバのネットワーク・アドレス、番号及びクライアント・リストが指定される。
・アプリケーション・アクセス・サーバ削除。削除すべきアプリケーション・アクセス・サーバの番号が指定される。
・クライアント追加。これは新たなクライアントのネットワーク・アドレスを含み、オプションとして、新たなクライアントによって制御される新たなゲーム・オブジェクトの初期状態も含まれる。
・クライアント削除。アプリケーション・アクセス・サーバ・システムは、ゲームからクライアントを削除する。
・クライアント状態変更。このメッセージは、ゲーム・オブジェクトを制御するクライアントの権限を変更するか、あるいはクライアントを別のアプリケーション・アクセス・サーバと結びつける。フォーマットは、
＜クライアント番号＞＜アプリケーション・アクセス・サーバ番号＞＜オブジェクト番号＞  などであり得、ここでオブジェクト番号は、クライアントによって制御されるゲーム・オブジェクトを示す。
【０１０８】
アプリケーション転送プロトコル（ＡＴＰ）は、アプリケーション・オブジェクト・パケット（ＡＯＰ）及びアプリケーション制御プロトコル（ＡＣＰ）メッセージを転送するのに使用される。ＡＴＰは、ペイロードに一連のＡＯＰ及びＡＣＰメッセージを有し、アプリケーション・アクセス・サーバ・ユニット間で集められたデータを送信するのに主に使用される。アプリケーション・アクセス・サーバ・ユニットは、通常はＩＰ／ＵＰＤ／ＡＴＰのプロトコル・スタックを用いて通信する。このためＡＴＰはＲＴＰプロトコルと論理レベルが同じである。
【０１０９】
ＡＴＰヘッダは、
・ゲームを識別するＵＲＬ、
・ＡＯＰあるいはＡＣＰの最先のタイムスタンプ、
・ＡＯＰあるいはＡＣＰの最後のタイムスタンプ、
・ＡＯＰ及びＡＴＰメッセージの数、を含んでいる。
【０１１０】
ＡＴＰは通常、説明したように、アプリケーション・アクセス・サーバ間での通信にのみ使用される。クライアントとアプリケーション・アクセス・サーバとの間の接続の帯域幅が十分に大きければ、これらの接続にも使用され得る。
【０１１１】
ＴＣＰ／ＩＰ及び／又はＵＰＤ／ＩＰなどの従来のプロトコルは、アプリケーション・ロビー・サーバ及び他のアプリケーション・アクセス・サーバ・ユニットとの通信に使用される。以下に示す理由で、ＴＣＰ／ＩＰはゲームを設定するのに使用される必要があり、ＵＤＰ／ＩＰはリアルタイムのゲーム・データを送信するのに使用される必要がある。すなわち、ＴＣＰの再送及び再発注は遅すぎてゲーム・アプリケーションには複雑である。ＴＣＰの再発注は、古すぎるデータを配信する目的のため、直近の更新の配信が遅延するかもしれない。も早必要でないデータの再送は明らかに無駄である。アプリケーション・アクセス・サーバ・ユニットは、正確な優先度を知っており、必要であればいくつかの送信元からの再送を要求できる。
【０１１２】
タイムスタンプを送信するのにＲＴＰが使用されてもよいが、ＲＴＰは音声及びビデオ・ストリームのために設計されておりゲームのストリームには最適ではない。しかしながらＲＴＰは、ゲームに関連する音声及びビデオ・ストリームを運ぶのには使用できる。
【０１１３】
「フェアプレイ・モード」をシステムで実施することもできる。このモードでは、アプリケーション・アクセス・サーバ・ユニットは、重要なアプリケーション情報の配信を同期させ、そのためこれらの更新は関連する全てのクライアントで同時に受信される。このモードは競争に使用できる。
【０１１４】
アプリケーション・ロビー・サーバは、アプリケーションを設定する間に、フェアプレイ・モードが利用可能かどうか決定する。フェアプレイ・モードが許可されたら、送信クライアントは、送信されたＡＯＰそれぞれについて、フェアプレイ配信を使用すべきかどうか決定する。これはＡＯＰの緊急フィールド内のFair_Playフラグを設定することにより行われる。アプリケーション・アクセス・サーバ・システムはここで、ＡＯＰを全てのクライアントに「同時に」配信するのを受け持つ。この要件は他の全てのクライアント優先度をオーバーライドする。
【０１１５】
これに対する技術的解決策は、「バケット同期（bucket synchronization）」方法である。複数のアプリケーション・アクセス・サーバ・ユニットが、クライアントを固定の絶対遅延で更新するよう合意する。速く到着した更新は、合意したタイムスロットまで待たねばならない。この方法は、システム内の全体の遅延が増加するという欠点がある。フェアプレイ・モードが、代替的にゲーム・アプリケーションで処理されてもよい。このモードでは、クライアント・アプリケーションは、合意した絶対遅延を達成するのにパケットをどれだけ遅延させるべきかを計算するのに各ゲーム・オブジェクトのタイムスタンプを用いて、受信したゲーム・データに合意した遅延を適用する。
【０１１６】
図６は、本発明によるアプリケーション・アクセス・サーバ１５０の別の実施形態を示している。特に言及しない限り、この実施形態は上記で検討したものと同様である。この実施形態では、アプリケーション・アクセス・サーバの通信機能は、１つ以上のアプリケーション・ルータ１５２とアプリケーション・サーバ１５４とに分離されている。アプリケーション・サーバ１５４は、図１に関して説明したような、アプリケーション状態レコード１５５及びクライアント優先度リスト１６１を備えている。アプリケーション・ルータ１５２は、以下でより詳細に説明する、クライアントのアプリケーション・プログラミング・インタフェース（ＡＰＩ）１７２によって１つ以上のクライアントと通信する。各アプリケーション・アクセス・サーバ１５０は、１つ以上のアプリケーション・ルータ１５２をサービスする１つのアプリケーション・サーバ１５４を備えている。アプリケーション・ルータ１５２も、別のアプリケーション・アクセス・サーバ（不図示）内のアプリケーション・ルータなどのネットワーク内の他のノードと通信する。好ましくは、アプリケーション・サーバ１５４及びアプリケーション・ルータ１５２は、各々をそれらの特定の機能について最適化すべく、別々のハードウェアとして実現される。代替的には、それらに割り当てられた別々のプロセッサ・リソースを有していてもよい。特に、アプリケーション・ルータは、中断はクライアント・アプリケーションのリアルタイム性能を悪化させるよう影響するので、中断せずに動作することが必要である。
【０１１７】
上記では、あるクライアントに接続されたアプリケーション・アクセス・サーバをそのクライアントのローカル・アプリケーション・アクセス・サーバとし、そのクライアントをアプリケーション・アクセス・サーバのローカル・クライアントとした。同様に、クライアントをサービスするアプリケーション・サーバ及びアプリケーション・ルータを、クライアントのローカルなアプリケーション・サーバ及びアプリケーション・ルータとする。
【０１１８】
アプリケーション・サーバは、クライアントからアプリケーション・ルータを通じて基本オブジェクト（下記参照）と制御メッセージを含むＡＴＰパケットを受信する。基本オブジェクトを、例えば、アプリケーション状態データベースに入れることによって処理する前に、アプリケーション・サーバは送信クライアントがそのオブジェクトを更新するのを許可されていることをチェックする。クライアントがオブジェクトを更新するのを認可されていない場合、そのオブジェクトは拒絶され、送信クライアントはエラー・メッセージを受信するであろう。制御メッセージを処理する前に、アプリケーション・サーバは、送信クライアントが示された動作を要求するのを許可されていることをチェックし、そうでなければ制御メッセージを拒絶し、オプションとしてエラー・メッセージを送信クライアントに返す。例えば、送信クライアントがオブジェクト・グループの削除を要求した場合を考える。このグループはコンテント・サーバによって作成されたものかも知れないが、該コンテント・サーバは、ゲーム状態の管理と標準的クライアントＡＰＩによるアプリケーション・アクセス・サーバとの通信とを受け持つ、特別なクライアントである。コンテント・サーバは、ゲーム・アクセス・サーバにクライアントがオブジェクト・グループを削除するのを禁止する認可規則をアップロードした。この場合、アプリケーション・サーバは、オブジェクト・グループの削除を要求する制御メッセージを拒絶するであろう。
【０１１９】
この認可チェックは、クライアントが実行を許可された動作の種類を示す、認可規則のテーブルを用いて実行される。認可テーブルはクライアントあるいは初期化ファイルを使用する制御ユニットによって設定される。
【０１２０】
もしそのように認可されていれば、クライアントは、オブジェクト・グループの作成を要求できる。クライアントはまた、メンバーの追加、メンバーの削除及びオブジェクト・グループの削除を行える。オブジェクト・グループのメンバーは、オブジェクトとオブジェクト・グループである。オブジェクト・グループについてのそのような動作の要求は、アプリケーション・ルータからセッションに参加している全てのアプリケーション・サーバにブロードキャストされる制御メッセージとして、クライアントによって送信される。オブジェクト・グループは、オブジェクト識別子と同じフォーマットを有する識別子によって識別される。各アプリケーション・サーバは、各アプリケーション・セッションについて、そのセッションの間に作成されたオブジェクト・グループを格納する、オブジェクト・グループ・データベース１６２を含んでいる。オブジェクト・グループ・データベース１６２は、各オブジェクト・グループに対して、少なくとも以下のフィールドを格納する。すなわち、１）オブジェクト・グループ識別子、２）オブジェクト・グループのメンバーのリスト、３）オブジェクト・グループの親のリスト、である。オブジェクト・グループＡの親は、メンバーとしてオブジェクト・グループＡを持つオブジェクト・グループである。オブジェクト・データベースは、前の実施形態におけるオブジェクト・データベースとして構築されるが、各オブジェクトについて、そのオブジェクトに対する親であるオブジェクト・グループのリストがある。
【０１２１】
アプリケーション状態の一部を形成すべき、クライアントから又は他のアプリケーション・アクセス・サーバから受信したオブジェクトは、アプリケーション・ルータ１５２からアプリケーション・サーバ１５４に送られ、アプリケーション状態レコード１５５に格納される。クライアントから又は他のアプリケーション・アクセス・サーバから受信したサブスクリプション情報は、アプリケーション・サーバ１５４に送られ、クライアント優先度リスト１６１に格納される。
【０１２２】
サイト・マネージャ１７４は、１つ以上のアプリケーション・ルータ１５２及びアプリケーション・サーバ１５４をそれぞれ備える、１つ以上のアプリケーション・アクセス・サーバの機能を、好ましくはアプリケーション・ルータ１５２への接続を通じて制御する。サイト・マネージャはまた、サイトを制御するのに標準的プロトコルＳＮＭＰ（簡易網管理プロトコル）を使用できる。
【０１２３】
従って、１つのサイトは、１つのサイト・マネージャと１つのサイト・マネージャによって制御されるいくつかのアプリケーション・アクセス・サーバ１５０とを備えている。サイト・マネージャ１７４のメイン・タスクは、接続管理、クライアント接続、リソース管理、アプリケーション・サーバ及びルータの構成、許可制御、クライアントの認可、サイトの時間同期、ネットワーク管理と、負荷、アプリケーションサーバ及びアプリケーション・ルータの状態の監視である。
【０１２４】
サイト・マネージャはオプションとして、クライアントからの制御メッセージを含むアプリケーション転送プロトコル（ＡＴＰ）パケットを受信する。この実施形態におけるＡＴＰは、以下で説明するが、先の実施形態に関して説明したＡＴＰとは異なっていることに注意されたい。制御メッセージを処理する前に、ＳＭは送信クライアントが示された動作を要求するのを許可されていることをチェックし、もしそうでなければ制御メッセージは拒絶され、送信クライアントはオプションのエラー・メッセージを受信する。この認可チェックは、クライアントが行うのを許可された動作の種類を示す、認可規則のテーブルを用いて実行される。認可テーブルは、クライアントあるいは初期化ファイルを使用するロビー・アクセス・サーバ１７８によって設定される。
【０１２５】
アプリケーション・ロビー・サーバ１７６及び１つ以上のロビー・アクセス・サーバ１７８への接続に、１つ以上のアクセス・ロビー・サーバ１７８が提供される。アプリケーション・ロビー・サーバは、図２に関して検討した。１つあるいは複数のロビー・アクセス・サーバ１７８は、サイト・マネージャ１７４に接続されている。ロビー・アクセス・サーバは、ロビー・サーバからのゲーム・セッションを処理し、ゲーム・セッションをアレンジし管理する。これにはロビー・サーバの登録及び認可並びに清算を含む。該サーバはまた、データベース内にゲーム及びロビー・サーバについての情報を保持する。アプリケーション通信システムの監視及び保全に、中央制御ユニット（不図示）が使用されてもよい。
【０１２６】
アプリケーション通信システムは、１つ以上の相互接続されたサイト及びロビー・アクセス・サーバを備えている。アプリケーション通信システムの監視及び保全に、中央制御ユニット（不図示）が使用されてもよい。
【０１２７】
ロビー・アクセス・サーバ１７８は、どのアプリケーション・ロビー・サーバが、特定のゲームあるいは特定のアプリケーション・アクセス・サーバにクライアントを追加するのを許可されているのか、などのネットワーク内にあるアプリケーション・ロビー・サーバについての情報を含む、データベース１８０を備えている、あるいはそれに接続されている。アプリケーション・ロビー・サーバ１７６は、各クライアントについての認可プロファイルなどのクライアント・データを含む、データベース１８２を備えて、あるいはそれに接続されていてもよい。
【０１２８】
サイト・マネージャと１つ又は複数のアプリケーション・サーバとの間の通信は、セッションの追加及び削除、セッションについてのクライアントの追加及び削除を含む制御を行う。サイト・マネージャと１つ又は複数のアプリケーション・ルータとの間の通信は、上記並びにクライアントに対するログイン許可と同様である。また、エラー・メッセージは、アプリケーション・サーバ又はアプリケーション・ルータからサイト・マネージャに送信される。
【０１２９】
好ましくは、ローカル・アプリケーション・ルータ１５２は、クライアント、ネットワーク内の他のアプリケーション・ルータ又は他のユニットから受信した、ストリーム・オブジェクト及び基本オブジェクトの両方を扱える。クライアントは、基本オブジェクトの更新それぞれのコピー１つを、ローカル・アプリケーション・アクセス・サーバに送信する。オブジェクトは例えば、プレーヤのアバター（化身）の状態を含んでいる。基本オブジェクトは、セッションに関係する全てのアプリケーション・サーバに送られる。クライアント又は他のアプリケーション・アクセス・サーバからのアプリケーション・ルータによって受信された基本オブジェクトは、関連するアプリケーション・サーバのアプリケーション状態レコードに格納される。ストリーム・オブジェクトの受信望むプレーヤは、ローカル・アプリケーション・サーバにサブスクリプションを発信する。アプリケーション・サーバは、サブスクリプションのパラメータに従って、ローカル・アプリケーション状態レコードから一連のオブジェクトの更新を送信する。ストリーム・オブジェクトは、アプリケーション・サーバに格納されていない。基本オブジェクト及びストリーム・オブジェクトについて以下でより詳細に検討する。アプリケーション・ルータは、アプリケーション転送プロトコル（ＡＴＰ）パケットを、クライアント、ローカル・アプリケーション・サーバ、他のアプリケーション・ルータ及びオプションでローカル・サイト・マネージャから受信する。ＡＴＰパケットは、ＵＤＰ／ＩＰなどの他のネットワーク・プロトコルによって転送される。他のアプリケーション・ルータは、リモート（リモート・アプリケーション・アクセス・サーバに属している）か、ローカル（アプリケーション・ルータと同じアプリケーション・アクセス・サーバに属している）のいずれかである。受信されたＡＴＰパケットには異なる３つのタイプがある。すなわち、アプリケーション・オブジェクト・パケット（ＡＯＰ）の基本オブジェクト及びストリーム・オブジェクト、アプリケーション制御パケット（ＡＣＰ）の制御データ、及びクライアント・メッセージ・パケット（ＣＭＰ）のクライアント・メッセージである。ＡＴＰパケットは、ユニキャスト又はマルチキャストによって、受信クライアント、アプリケーション・ルータ、ローカル・アプリケーション・サーバあるいはローカル・サイト・マネージャにルーティングされるか又は削除される。異なったルーティングの場合を表に示す。受信するアプリケーション・ルータに宛てられた制御パケットは、ルーティングされない。
【０１３０】
アプリケーション・ルータのルーティング・テーブルを以下に示す。
2008022573.tif 000002
2008022573.tif 000003
2008022573.tif 000004
【０１３１】
ストリーム・オブジェクトは、アプリケーション・サーバには格納されない。クライアントは通常、それらを仮想世界において移動するアイテムの位置を送信するのに使用する。それらはネットワークを通じて非常に高速で転送され得る。ストリーム・オブジェクトの直近のバージョンだけが、受信クライアントにとって重要であると想定される。ストリーム・オブジェクトの処理は、フロー制御のためにアプリケーション・ルータによって意図的に抜かされることがあるので、通常は当てにならない。アプリケーション・ルータによって受信された全てのストリーム・オブジェクトは、そのストリーム・オブジェクトを申込んだ全てのローカル・クライアント、又はそのストリーム・オブジェクトを含むストリーム・オブジェクト・グループに送られる。以下で検討するように、これらのオブジェクトはアプリケーション・サーバで処理されないので、アプリケーション・ルータ１５２も、優先度又はサブスクリプション情報を備えている。
【０１３２】
通常、例えば、実行中の特定のマルチプレーヤ・セッションなどのセッションに加わるのを望むクライアントは、アプリケーション・ロビー・サーバ１７６にインターネットによって接続する。アプリケーション・ロビー・サーバは、実行中のアプリケーション・セッションについての情報を提供し、普通はクライアントに新たなセッションを作成することを許可し、加入するように他のクライアントを招待する。クライアントは、アプリケーション・ロビー・サーバ１７６に、セッションの作成、削除、加入又はやめる要求を送信できる。アプリケーション・ロビー・サーバは、そのようなセッション制御要求を受け取ると、その要求をロビー・アクセス・サーバ１７８に送る。セッションの作成が要求されると、ロビー・アクセス・サーバ１７８は、アプリケーション・セッション識別子を発信することにより応答する。セッションを削除したりクライアントの加入又は削除などの要求に対しては、アプリケーション・ロビー・サーバ１７６は、ロビー・アクセス・サーバ１７８に送信される要求にアプリケーション・セッション識別子を含める。ロビー・アクセス・サーバ１７８は、アプリケーション・アクセス・サーバ・システム内で要求された動作に合うリソースが使用可能であるかを調査することによって応答する。リソースが使用可能であれば、ロビー・アクセス・サーバ１７８は要求された動作を実行する。
【０１３３】
セッションの作成が要求されたら、ロビー・アクセス・サーバ１７８は、セッションをサービスするサイトのセットを選択し、関連するサイト・マネージャ１７４に、セッション識別子を含み、適切なアプリケーション・アクセス・サーバ１５０でセッションが開始されることを要求する制御メッセージを送信する。
【０１３４】
セッションの削除が要求されたら、ロビー・アクセス・サーバ１７８は、セッションを実行しているサイトのサイト・マネージャ１７４に、セッション識別子を含み、セッションが削除されることを要求する制御メッセージを送信する。
【０１３５】
クライアントの加入が要求されたら、アプリケーション・ロビー・サーバ１７６は、少なくともクライアント１７０のネットワーク・アドレス、セッション識別子、及びオプションとしてサイト識別子を、ロビー・アクセス・サーバ１７８への制御メッセージに含める。ネットワーク・アドレスは、例えば、クライアント・アプリケーション処理のＩＰアドレス及びポート番号でよい。ロビー・アクセス・サーバ１７８は、適切なサイトを選択し、サイトのサイト・マネージャ１７４に、クライアント１７０がゲーム・セッションに加わることを要求する制御メッセージを送信する。この制御メッセージは、クライアント１７０のネットワーク・アドレスと、サイトのサイト・マネージャ１７４へのセッション識別子とを少なくとも含んでいる。サイト・マネージャは、適切なアプリケーション・アクセス・サーバと、適切なアプリケーション・ルータとを、クライアントをサービスするのを受け持つべきユニット内で選択し、クライアントをゲームに加入するよう招待する制御メッセージをクライアントに送信する。クライアントをサービスするアプリケーション・ルータのネットワーク・アドレスとパスワードとが、そのメッセージには含まれている。クライアント１７０は、パスワードを含む制御メッセージで関連するアプリケーション・アクセス・サーバ１５０に連絡する。アプリケーション・アクセス・サーバ１５０は、ローカル・クライアント・データベースにクライアント１７０を含め、クライアントはゲームデータを送信及び受信して処理を続行することができる。
【０１３６】
代替的には、サイト・マネージャ１７４は、ロビー・アクセス・サーバ１７８にクライアント１７０をサービスするアプリケーション・ルータ１５２のネットワーク・アドレスを送信することができ、ロビー・アクセス・サーバ１７８は、アプリケーション・ロビー・サーバ１７６にネットワーク・アドレスとパスワードとを送る。アプリケーション・ロビー・サーバ１７８は、ネットワーク・アドレスとパスワードとを、上記で説明したように、関連するアプリケーション・アクセス・サーバに接続する、要求クライアントに送る。
【０１３７】
図６には、バッファ、ソフトウェア処理等が何も示されていないが、本発明のアプリケーション・アクセス・サーバを実現するためにはそれらが必要なことは当業者には理解できるであろう。
【０１３８】
クライアント１７０、アプリケーション・アクセス・サーバ１５０及びサイト・マネージャ１７４は、アプリケーション転送プロトコル（ＡＴＰ）を用いて通信する。ＡＴＰパケットは通常、先の実施形態で検討したように、ＵＤＰパケットのペイロードとして運ばれる。この実施形態で使用されるＡＴＰを以下で説明する。アプリケーション転送プロトコルは、１）複合（コンパウンド）ＡＴＰパケット、２）標準ＡＴＰパケット２つのプロトコル・レベルを含んでいる。
【０１３９】
複合ＡＴＰパケットは、ソース・ヘッダといくつかの標準ＡＴＰパケットを含んでいる。ソース・ヘッダは以下のようなフィールドを含んでいる。
１）アプリケーション・セッション識別子、
２）送信クライアントを含むクライアント識別子、
３）保証された送信のプロトコルで使用され、確認フィールドとパケット・カウンタを含む、オプション・フィールド。
【０１４０】
標準ＡＴＰパケット（以下では「ＡＴＰパケット」とも呼ぶ）は、ＡＴＰヘッダ、ＡＴＰオプション・ヘッダ、オプションのＡＴＰターゲット・ヘッダ及びＡＴＰコンテント・パケットからなる。
【０１４１】
ＡＴＰヘッダは、以下のフィールドを含み得る。
１）コンテント・パケットのタイプとコンテント・パケット内のオプション。フィールドの存在を示すフラグのセットである、タイプ・フィールド。コンテント・パケットのタイプは、制御メッセージ、クライアント・メッセージ、基本オブジェクトあるいはストリーム・オブジェクトである。メッセージの意図した受信者を、タイプ・フィールドに示し得る。
２）ＡＴＰパケットが信頼できる又は信頼できないモードで送られたのかを示すフラグ、
３）ターゲット・ヘッダが存在するかを示すフラグ、
４）ＡＴＰオプション・ヘッダの存在及び内容を示すフラグのセット、
５）コンテント・パケットのサイズを示すフラグ。
【０１４２】
ＡＴＰオプション・ヘッダは、以下のオプション・フィールドからなる。
１）セッション識別子、
２）クライアント識別子、
３）オブジェクト識別子。
【０１４３】
ＡＴＰオプション・ヘッダは、コンテント・パケットを識別するのに使用される。基本オブジェクトに関連するアプリケーション・ペイロードは、例えば、コンテント・パケットで送信されてもよい。ＡＴＰオプション・ヘッダは、以下で説明する相対アドレッシング・システムを使用する基本オブジェクトを識別するのに使用される。
【０１４４】
ＡＴＰターゲット・ヘッダＴＨは、ＡＴＰパケットの直接アドレッシングに使用される。受信者のＡＴＰアドレスは、ＡＴＰターゲット・ヘッダに示されている。ＴＨの最初の位置はＴＨのサイズを保持するバイトである。ＴＨは、メッセージの意図する受信者を示すクライアント識別子のリスト、あるいはストリーム・オブジェクト・キーのリストのいずれかである、動的アドレス・フィールドのアレイからなる。キーは、送信者によって送信され得るストリーム・オブジェクトの属性である。クライアントは、所望するストリーム・オブジェクトのオブジェクト識別子がわからなくても、特定のキーを運ぶ所望するストリーム・オブジェクトを申込むことができる。クェーク（Quake）のようなゲームでは、異なった部屋に属するストリーム・オブジェクトを選択するのにキーを使用できる。ストリーム・オブジェクトは、ゲームにおけるアバターの位置を送信するのに使用される。ゲームの各部屋にキーが割り当てられている。ストリーム・オブジェクトを送信しているプレーヤは、アバターが位置する部屋に対応するキーを加える。データを受信しているプレーヤは、彼らが興味を持つ部屋に対応するキーと共にストリーム・オブジェクトを申込む。ストリーム・オブジェクト・キーは、代替的に、例えば、危険であるとして、チームを識別したりオブジェクトを分類するのに使用され得る。ローカル・アプリケーション・アクセス・サーバのストリーム・オブジェクト・フィルタは、プレーヤのストリーム・オブジェクトに対するサブスクリプションを受信して、プレーヤがストリーム・オブジェクトを要求したキーで得るのを保証する。
【０１４５】
ＡＴＰコンテント・パケット（ＣＰ）は、１）基本オブジェクト、２）ストリーム・オブジェクト、３）制御メッセージ、４）クライアント・メッセージ、のいずれのタイプでもよい。基本オブジェクト、ストリーム・オブジェクト及びクライアント・メッセージのＣＰは、アプリケーション・ペイロードを含んでいる。制御メッセージは、メッセージ・タイプとメッセージ・パラメータを含んでいる。アプリケーション制御プロトコルは、メッセージ・タイプ・フィールド及び各メッセージのパラメータのフォーマットを指定する。
【０１４６】
セッション識別子、クライアント識別子及びオブジェクト識別子は、以下で説明するような動的アドレス・フィールドである。クライアント・グループ及びオブジェクト・グループは、クライアント及びオブジェクトのそれぞれと識別子のフォーマットが同じである。
【０１４７】
本明細書においては以下の名前及び定義を使用している。アプリケーション・オブジェクト・パケットとは、コンテント・パケットにアプリケーション・オブジェクトを含むＡＴＰパケットである。アプリケーション制御プロトコル・パケットとは、コンテント・パケットに制御メッセージを含むＡＴＰパケットである。基本オブジェクト、ストリーム・オブジェクトあるいはクライアント・メッセージの送信は、常に、適切なタイプのコンテント・パケットを有するＡＴＰパケットが送信されることを意味する。クライアント・メッセージ・パケットとは、コンテント・パケットに受信者アドレス及びクライアント・メッセージを含むＡＴＰパケットである。
【０１４８】
ＡＴＰ使用例は以下を含む。
Ａ）クライアントは、基本オブジェクトをローカル・アプリケーション・サーバに送信している。クライアント識別子でなくオブジェクト識別子又はセッション識別子がＡＴＰオプション・ヘッダに入れられる。ＡＴＰターゲット・ヘッダは全く必要ない。オブジェクト・ペイロードはコンテント・パケットに入れられる。オプション・ヘッダと動的アドレス・フィールドの使用は、ヘッダ・オーバヘッドが４バイトまで小さくできることを意味する。オブジェクトはしばしば狭い帯域幅の接続で送られるので、これは重要である。
【０１４９】
Ｂ）クライアントは、クライアント・メッセージを別のクライアントに送信している。オブジェクト識別子と送信クライアントのクライアント識別子がＡＴＰオプション・ヘッダに入れられる。セッション識別子は全く必要ない。メッセージ・ペイロードはコンテント・パケットに入れられる。送信側のアプリケーション・ルータの入力フィルタは、ターゲット・ヘッダにセッション識別子を加える。受信側のアプリケーション・ルータの出力フィルタは、パケットを受信クライアントに送る前にセッション識別子を削除する。
【０１５０】
ＡＴＰは動的アドレス・フィールドを使用する。動的フィールドは可変長プレフィクス・コードである。プレフィクス・コードは、前のコード・ワードを参照せずに、ビット・フィールド内の各コード・フィールドが一意に復号され得るコードである。単純な例は、アルファベット、｛１０，１１０，１１１０，…｝である。ハフマン符号は、シンボルの統計的分布について最適な（最小期待長）プレフィクス・コードである。動的アドレス・フィールドの代替的フォーマットは、動的サイズ整数（dynamic size integer）である。動的サイズ整数は、コンピュータ・サイエンスにおいては周知である。動的サイズ整数は、小さな値が最も多いときには常に使用されるが、大きな値が可能でなければならない。２バイトの動的サイズ整数では、最上位ビットは整数のサイズを表し、１は１バイトを意味し、０は２バイトを意味する。４バイトの動的サイズ整数では、最上位の２ビットは整数のサイズを表し、０１は１バイトを意味し、１０は２バイトを意味し、１１は３バイトを意味し、００は４バイトを意味する。
【０１５１】
動的アドレス・フィールドは、以下の２つの方法に従って使用できる。
第１の方法では、ＡＴＰは、１）アプリケーション・セッション識別子、２）クライアント識別子、３）オブジェクト識別子、の３つの異なった識別子のためのフィールドを有している。アプリケーション・セッション識別子は、グローバルにユニークのものであり、ネット・マネージャあるいはロビー・アクセス・サーバなどの中央機関によって割り当てられる。クライアント、アプリケーション・ルータ、アプリケーション・サーバ及びオプションとしてサイト・マネージャのそれぞれは、クライアント識別子を有し、以下のノード内にある。クライアント・グループ識別子は、クライアント識別子のフォーマットを有している。
【０１５２】
クライアント識別子は、特定のアプリケーション・セッションにおいてのみユニークなものである。ロビー・アクセス・サーバ又は中央制御ユニットなどの中央機関が、クライアント識別子を割り当てる。アプリケーション・セッション識別子が既知であるときだけ、クライアント識別子でノードが識別される。ＡＴＰは動的フィールドにクライアント識別子を格納する。アプリケーション・セッションの各ノードには、クライアント識別子ができるだけ少ないビットで割り当てられる。頻繁に使用されるクライアント識別子には、例えば、ハフマン符号化手順に従って、最短のコードが割り当てられるであろう。
【０１５３】
オブジェクト識別子は、所与のセッションで所与のクライアントにユニークである。クライアントがオブジェクト識別子を割り当てる。セッション識別子及びクライアント識別子が既知であるときだけ、オブジェクト識別子によってオブジェクトが識別される。ＡＴＰはオブジェクト識別子を動的フィールドに格納する。各オブジェクトには、オブジェクト識別子ができるだけ少ないビットで割り当てられる。頻繁に使用されるオブジェクト識別子には、例えば、ハフマン符号化手順に従って、最短のコードが割り当てられるであろう。
【０１５４】
第２の方法は、以下の点を除いて第１の方法と同様である。クライアント識別子は２つの動的フィールドからなる。第１のフィールドは、クライアントをサービスしているアプリケーション・ルータの識別子である。第２の動的フィールドは、クライアント・インデックスである。このインデックスは、できるだけ短くなり、かつアプリケーション・セッション識別子が与えられたときにローカル・アプリケーション・ルータ・クライアント識別子が既知のクライアントにユニークとなるように選択される。ローカル・アプリケーション・サーバのクライアント識別子は、代替的に、ローカル・アプリケーション・ルータのクライアント識別子の代わりに使用できる。
【０１５５】
上記のような動的アドレス・フィールドと相対的アドレッシングを使用する利点は、使用する帯域幅と遅延が最小となることである。関連するアドレス・フィールドだけが送信される。この例は以下のようなものである。
１）クライアントは１つのアプリケーション・セッションだけに係わる。クライアントからのオブジェクトを含むＡＴＰパケットは、オブジェクト識別子だけを含んでいる。アプリケーション・セッション識別子及びクライアント識別子は、アプリケーション・ルータは事実上知っているので送信されない。
２）ローカル・アプリケーション・サーバからクライアントへ送信されたオブジェクトを含むＡＴＰパケットは、オブジェクト識別子とそのオブジェクトを所有するクライアントのクライアント識別子だけを含んでいればよい。
３）新たなオブジェクトを作成するクライアントは、すぐにオブジェクト識別子を割り当てる。グローバルにユニークなオブジェクト識別子の集中的割り当ては、新たなオブジェクトが作成される前に中央機関との通信を必要とする。
【０１５６】
クライアント・グループ・アドレッシングは、以下に従って処理される。ＡＴＰのクライアント・グループが、クライアント識別子によって識別される。他のクライアント識別子についてと同様な方法を用いて識別子が作成される。アプリケーション・セッションの間にクライアントによってクライアント・グループの裂くせいが要求されるか、あるいはセッションの初期化の一部としてクライアント・グループの作成が実行される。
【０１５７】
各ＡＴＰパケットはＡＴＰヘッダにタイプ・フィールドを含んでいる。タイプ・フィールドはコンテントの性質を表わしている。タイプ・フィールドの異なったコードは、例えば、コンテントが、基本オブジェクト、ストリーム・オブジェクト、制御パケットあるいはクライアント・メッセージであることを示す。アプリケーション・ルータは、アドレス・フィールドの読み取りや解析をしないある種の場合におけるデフォルトのルーティングのために、タイプ・フィールドを使用できる。タイプ・フィールドに基づいたデフォルトのルーティングの例は以下のようなものである。
１）全ての基本オブジェクトはローカル・アプリケーション・サーバに送られる、２）タイプ・フィールドに特定の１つのコードがある制御パケットは、ローカル・アプリケーション・サーバに送られ、タイプ・フィールドに別の特定の１つのコードがある制御パケットは、ローカル・サイト・マネージャに送られる。
【０１５８】
図７は、図６に関して検討した実施形態で使用されるアプリケーション・ルータ１５２と、ＡＴＰパケットがどのようにアプリケーション・ルータを通って行くのかを示している。アプリケーション・ルータ１５２は、入力フィルタのセット１９０、１９２と、ルータ・コア１９４と、出力フィルタのセット１９６、１９８とからなる。アプリケーション・ルータは、通信する各ノードに対して、入力及び出力フィルタを有している。ルータ・コア１９４は、ＡＴＰパケットのルーティングを実行するために、いくつかのルーティング・テーブル１９９を含んでいる。
【０１５９】
パケットは３つのタイプの送信源、すなわち、同じアプリケーション・アクセス・サーバのアプリケーション・サーバ及び、例えばサイト・マネージャなどの他の同様なユニットからと、他のアプリケーション・ルータからと、このアプリケーション・ルータに接続されたアプリケーション・クライアントから来る。別のアプリケーション・ルータあるいはアプリケーション・クライアントへの全ての接続に対して、１つの入力フィルタ１９０、１９２と１つの出力フィルタ１９６、１９８がある。アプリケーション・サーバへの接続に対しては、入力又は出力フィルタは全く必要ない。フィルタはいくつかのアプリケーション・パケットの転送パッケージへの組立を実施し、信頼できるパケットの再送も扱う。アプリケーション・クライアント出力フィルタ１９６、１９８は、クライアント回線上の冗長な情報を削除し、アプリケーション・クライアント１７０へのダウンリンクについての負荷バランスも取る。
【０１６０】
出力フィルタに接続されたクライアント１７０、あるいは認可されたあらゆる他のクライアントは、受信クライアントの出力フィルタに、ストリーム・オブジェクト又はストリーム・オブジェクト・キーのサブスクリプションを送信できる。サブスクリプションは、サブスクリプションのコンテントと受信クライアントのクライアント識別子を示す制御メッセージとして送信される。出力フィルタは、アプリケーション・ルータに到着するストリーム・オブジェクトをスキャンする。サブスクリプションに合うストリーム・オブジェクトは、おそらくドロップレートを適用した後でクライアントに送信される。ストリーム・オブジェクトがサブスクリプションと合うのは、ストリーム・オブジェクトのオブジェクト識別子がサブスクリプションにあるオブジェクト識別子と等しい場合、あるいはストリーム・オブジェクトで運ばれたストリーム・オブジェクト・キーがサブスクリプションにあるストリーム・オブジェクト・キーと合った場合のいずれかである。
【０１６１】
（出力フィルタに接続された）クライアントが、ストリーム・オブジェクトを申込み、ストリーム・オブジェクトを送信クライアントから受信するときを考える。そのクライアントあるいは他の認可されたあらゆるクライアントは、所与のストリーム・オブジェクトに関連してドロップレートを設定できる。このドロップレートはローカル・アプリケーション・ルータに制御メッセージで送信される。ドロップレートが、０≦Ｒ≦１の値に設定されていれば、出力フィルタはストリーム・オブジェクトの比率Ｒを意図的に削除する。例えば、Ｒ＝０．９であると、到着パケットの１０％だけがクライアントへ渡されるのを許可される。
【０１６２】
出力フィルタは、クライアントに送信される必要のないＡＴＰヘッダ・フィールドを削除する。別のクライアントから直接アドレス指定されたメッセージは、例えば、アプリケーション・セッション識別子と受信クライアントのクライアント識別子をヘッダに含んでいる。この情報を受信クライアントには有用ではなく、このためアプリケーション・ルータの出力フィルタで削除される。
【０１６３】
クライアントなどの特定のノードに対する入力フィルタは、ストリーム・オブジェクト、基本オブジェクト、制御メッセージ及び直接アドレス指定されたクライアント・メッセージを含むＡＴＰパケットをノードから受信する。ＡＴＰパケットをルーティング・コアに送信する前に、以下の動作が実行される。
【０１６４】
１）入力フィルタは、クライアントがストリーム・オブジェクト又は基本オブジェクトを更新するのを許可されているか、あるいは送信クライアントがメッセージ内に示されるクライアントに直接アドレス指定されたメッセージを送信するのを許可されているかをチェックする。この認可チェックは、クライアントがどのような種類の動作の実行を許可されたのかを示す、認可テーブルを参照して実行される。認可テーブルは、クライアント又は初期化ファイルを使用するサイト・マネージャを介してＬＡＳによって設定される。
【０１６５】
２）入力フィルタは送信クライアントのアドレスを適切なＡＴＰヘッダに追加する。このアドレスは、帯域幅を節約するため、送信クライアントとアプリケーション・ルータとの間の通信リンクには送信されない。
【０１６６】
３）アプリケーション・ルータはクライアント・グループのリストを格納する。このようなリストは、クライアント・グループを示すクライアント識別子を、クライアントを示すクライアント識別子のリストに結びつける。クライアント・グループのリストは、クライアント又はサイト・マネージャを介してＬＡＳによって設定される。受信者のアドレス・フィールド内のクライアント・グループを有するＡＴＰパケットが入力フィルタに受信されると、以下の３つの代替的オプションの１つを行う。Ａ）クライアント・グループに属するクライアント識別子のリストを見つける。ＡＴＰパケットのコピーを少なくとも１つ受信すべきアプリケーション・ルータの数Ｎを見つける。受信アプリケーション・ルータそれぞれに対する出力フィルタに入れるＡＴＰパケットをＮ個コピーする。ＡＴＰヘッダには、コンテントをローカル・クライアントだけに配布し、あらゆるリモート受信者に配布すべきでないことを示すフラグがある。このフラグは各出力パケットで設定される。これは好ましい動作モードである。
【０１６７】
４）クライアント・グループに属するクライアント識別子のリストを見つける。ＡＴＰパケットのコピーを少なくとも１つ受信すべきアプリケーション・ルータの数Ｎを見つける。受信アプリケーション・ルータそれぞれに対する出力フィルタに入れるＡＴＰパケットをＮ個コピーする。各パケットにおいて、クライアント・グループ識別子を、受信アプリケーション・ルータのローカル・クライアントであるクライアント・グループのメンバーだけを含む受信クライアントのリストに置き換える。ＡＴＰパケットを複製して、その結果、各複製でクライアント・グループ識別子を、クライアント・グループに関連するクライアント識別子リスト内のクライアント１つを示す、１つのユニークなクライアント識別子に置き換える。
【０１６８】
５）そのクライアントが入力フィルタが送信しているクライアントに関連するとして、各ストリーム・オブジェクトについてデフォルト・ヘッダが入力フィルタによって格納される。このデフォルト・ヘッダは、ストリーム・オブジェクトに関連したストリーム・オブジェクト・キーを含んでいる。クライアントが明らかにストリーム・オブジェクトを含んでいるヘッダを送信したら、このヘッダが入力フィルタによって格納されたデフォルト・ヘッダに置き換わる。クライアントが、ストリーム・オブジェクトを含んでいるヘッダなしにストリーム・オブジェクトを送信したら、入力フィルタはストリームオブジェクトがルータ・コアに送信される前にデフォルト・ヘッダを追加する。これは送信クライアントが、ストリーム・オブジェクトの各コピーと共にストリーム・オブジェクト・キーのコピー１つを送信する必要が無いことを意味する。キーが変わる度とストリーム・オブジェクトが最初に送信されるときに、ストリーム・オブジェクト・キーを含んでいるヘッダを送信すれば十分である。
【０１６９】
標準的ＡＴＰパケットは、アプリケーション・オブジェクト（ストリーム又は基本）、制御メッセージ又はクライアント・メッセージのいずれかであるコンテントを運ぶ。複合ＡＴＰパケットは、オプションの小さな複合ヘッダと、少なくとも１つで普通はいくつかの標準的ＡＴＰパケットからなる。複合ＡＴＰパケットは、標準的転送プロトコルのペイロードとして送信される。普通は複合ＡＴＰパケットはＵＤＰパケットのペイロードとして送信される。
【０１７０】
複合ＡＴＰパケット内に標準的ＡＴＰパケットを集める方法は、帯域幅の効率と小さなレイテンシとの間の正しいバランスを達成するためには重要である。大きな複合ＡＴＰパケットは伝送のレイテンシを大きくするが、ヘッダのオーバヘッドを小さくし、そのため帯域幅を効率的に利用する。標準的ＡＴＰパケットの複合ＡＴＰパケットへの集結は、システムのいくつかのモジュールで行われる。
【０１７１】
ローカル・アプリケーション・ルータに送信するアプリケーション・クライアントでの集結には、２つの代替的方法が使用され得る。第１の方法では、集結はアプリケーション・プログラムの直接制御下にある。標準的ＡＴＰパケットは出力バッファに送信される。アプリケーション・プログラムが、バッファのコンテントが複合ＡＴＰパケットに入れられて、ローカル・アプリケーション・ルータに送信されるときを決定する。第２の方法では、集結はクライアント内の自動的アルゴリズムによって実行される。標準的ＡＴＰパケットはアプリケーション・プログラムによって出力バッファに送信される。アルゴリズムが、バッファのコンテントが複合ＡＴＰパケットに入れられて、ローカル・アプリケーション・ルータに送信されるときを決定する。好ましいアルゴリズムの例は、バッファ・サイズが所与のサイズＳを越えたら複合パケットが送信される。複合パケットの最後の送信からの時間が所与の時間間隔Ｔを越えたら複合パケットが送信される。パラメータＳ及びＴはアプリケーション・プログラムによって設定される。
【０１７２】
クライアントに送信するアプリケーション・ルータでの集結には、例えば、上記第２の方法と同様なアルゴリズムが使用され得る。アプリケーション・ルータに送信するアプリケーション・ルータでの集結には、アプリケーション・ルータ間のリンクは非常に高速であると想定でき、標準的パケットは非常に頻繁に送信されるので、次のプロトコル・レベル、例えばＵＤＰ、によって許可される最大サイズのＡＴＰ複合パケットを送信するのが通常は良好に動作する。
【０１７３】
帯域幅が制限されたりＡＴＰパケットがまれにしか送信されなければ、アプリケーション・クライアントでの集結について先に述べた第２の方法と同様なアルゴリズムを使用するのを勧める。
【０１７４】
サイズＳ（ビット）は、Ｖがビット／秒で測定した２つのアプリケーション・ルータ間の通信速度であり、Ｔ０が普通は１〜１０ｍｓの許される伝送のレイテンシであるとき、Ｓ＜Ｖ＊Ｔ０となるように選択される。時間間隔Ｔは１〜１０ｍｓの間とすべきである。
【０１７５】
クライアントは、基本オブジェクトに対するサブスクリプションを、ローカルアプリケーション・サーバへの制御メッセージとして送信できる。サブスクリプションは、受信クライアント、サブスクリプションのターゲット及びサブスクリプション・パラメータを指定する。サブスクリプションは、アプリケーション・サーバに対して、一連の基本オブジェクトを受信クライアントに送信させる命令である。各オブジェクトの一連の更新は、サブスクリプションのパラメータに従って、かつ基本オブジェクトのソースがどのように変更されたかに応じて送信される。
【０１７６】
サブスクリプションを送信するクライアントは、通常受信クライアントであるが、クライアントは別のクライアントに代わってサブスクリプションを作成するかもしれない。サブスクリプションはまた、クライアント・グループに代わって発行され得る。クライアント・グループの全てのクライアントは、サブスクリプションの結果を受信する。
【０１７７】
サブスクリプションのターゲットは、ＡＴＰプロトコルに従ってオブジェクト識別子によって識別される基本オブジェクトのセットである。ターゲットは、１）オブジェクト識別子、２）オブジェクト識別子のセット、３）オブジェクト・グループ識別子、４）オブジェクト識別子とオブジェクト・グループ識別子の混ざったセット、５）オペランドとしてのオブジェクト・グループ及びオブジェクトと論理演算子ＡＮＤ、ＯＲ及びＮＯＴとを含む一般的ブール論理式、で記述され得る。正しく定義されたターゲットの表現は、オブジェクト・データベース及びオブジェクト・グループ・データベースの情報を用いて、アプリケーション・サーバで見積もられる。この見積もりの結果は常に、基本オブジェクトの有限セットとなる。
【０１７８】
サブスクリプション・パラメータは、サブスクリプションのコンテントが、どれだけの頻繁で、何回、及びどれだけ長く配信されるのかを特定するのに使用され得る。これは、オブジェクトの更新されたバージョンが受信されるべき最大レートとして特定され得る。オブジェクトの所有者が低いレートでオブジェクトを更新すると、新たなバージョン各々は配信されるとすぐに受信されるであろう。オブジェクトが選択された最大レートより速く更新されると、更新は正に選択されたレートで受信されるであろう。この場合、中間のバージョンのいくつかは受信されないであろう。
【０１７９】
コンテント・サーバあるいはマスター・クライアントは、ゲームの状態についてより多くの情報を持っているであろう。従って、マスター・クライアントがターゲット・クライアントの代わりに基本オブジェクトを申込むのは好ましいであろう。マスター・クライアントは、システムに対してサブスクリプションを構成して提出する。ローカル・アプリケーション・アクセス・サーバは、サブスクリプションで要求された基本オブジェクトを、ターゲットのクライアント又はクライアント・グループに直接配信する。
【０１８０】
サブスクリプションは、クライアント又はクライアント・グループに帰属する。サブスクリプションはゲーム・オブジェクトのセットを参照する。このセットは、オブジェクト・グループ及びオブジェクトを含む一般的ブール論理式で表わされ得る。
【０１８１】
アプリケーション・アクセス・サーバ（ＡＡＳ）は、オブジェクトをサブスクリプション周波数で配信しようとする。配信時間は、サブスクリプション周波数の逆数である。サブスクリプションが発信されるときにデータベース内にあるオブジェクトは、配信時間内に配信される。サブスクリプションが有効である間にデータベース内のオブジェクトが変更されると、ＡＡＳはそれを配信時間内に配信しようとする。
【０１８２】
サブスクリプション・クラスは正の整数である。サブスクリプション・クラスに従ってデータを配信する２つの方法をここで説明する。
【０１８３】
方法１：最も大きなクラスのサブスクリプションが、最初に完全に履行される。次に、ＡＡＳは次に大きなクラスのサブスクリプションを完全に履行しようとする。これは、小さなクラスのサブスクリプションは、決して履行されないかもしれないことを意味する。サブスクリプション・クラス内のオブジェクトを要求された周波数で配信するのに帯域幅が不十分であれば、クライアントへの配信が容易となるように、ＡＡＳはクラス内の全ての周波数を上げる。
【０１８４】
方法２：３つの異なったクラスが使用される。異なったクラスは、１＝高、２＝中、３＝低、と呼ばれる。クラス１のオブジェクトは、バッファがフルでレートがゼロに落ちるまで、常に最大レートで申込者に送信される。クラス２のオブジェクトの申込者への送信レートは、バッファの負荷に比例する。バッファの容量が小さくなるとレートが低くなる。クラス３のオブジェクトは、バッファ内に他のオブジェクトが何も無ければ申込者に送信される。
【０１８５】
１つの特定の実施態様では、アプリケーション・オブジェクト・パケットは、いくつかの列挙されたペイロードを含み得る。この場合、サブスクリプションは、オプションの加重パラメータを有している。加重パラメータは整数である。加重＝ｎは、オブジェクトの最初のｎ個のペイロードが配信されることを意味する。
【０１８６】
いくつかのオブジェクトは通常の間隔では更新されないかもしれないが、代わりに正確な回数だけ更新される。従って、特定のオブジェクトに関して指定数の更新を要求することができる。アプリケーション・サーバは、そのオブジェクトに関してカウンタをサブスクリプションで指定された整数値に設定する。オブジェクトが配信される度にカウンタは１づつデクリメントされる。カウンタ＝０となるとサブスクリプションは削除される。
【０１８７】
クライアントは、同じ更新が前に送信された場合であっても、要求した周波数でオブジェクトが送信されるのを要求できる。これは「強制送信」ＦＳフラグを設定することで行われる。
【０１８８】
また、古いサブスクリプションに関するデータでネットワークが過負荷となるのを防止するため、サブスクリプションの寿命、あるいは持続期間が設定されるべきである。サブスクリプションの寿命が過ぎた後に、サブスクリプションは削除される。
【０１８９】
ストリーム・オブジェクトは、アプリケーション・ルータ間で以下の方法の１つを用いて配布される。
【０１９０】
方法１）１つのアプリケーション・ルータによって受信されたストリーム・オブジェクトは、複製されてアプリケーション・セッションに参加している全ての他のアプリケーション・ルータに送信される。これは、例えば、アプリケーション・セッションに参加している全てのアプリケーション・ルータを、ＩＰマルチキャスト・アドレスに関連付けることによって効率的に行われ得る。
【０１９１】
方法２）各アプリケーション・ルータは、ストリーム・オブジェクト及びストリーム・オブジェクト・キーに対するサブスクリプションのセットをローカル・クライアントから受信する。そのようなサブスクリプション全ては、ローカル・クライアントが申込んでいるストリーム・オブジェクト及びストリーム・オブジェクト・キーを少しの重複もなしにすべて含む、ジョイント・サブスクリプションに集められる。ローカル・クライアントで生成されたストリーム・オブジェクト・キーでなくてストリーム・オブジェクトは、集められたサブスクリプションから削除される。集められたサブスクリプションは、他の全てのアプリケーション・ルータに送信される。ローカル・クライアントの中で、別のアプリケーション・ルータから集められたサブスクリプションを受信し、集められたサブスクリプションのストリーム・オブジェクト及びストリーム・オブジェクト・キーに対するいずれかの発信源を知るアプリケーション・ルータは、申込んでいるアプリケーション・ルータにサブスクリプションの一部を送信する。
【０１９２】
方法３）各アプリケーション・ルータは、方法２と同様にサブスクリプションの集められたセットを用意する。集められたサブスクリプションは、サイト・マネージャに任命された親のアプリケーション・ルータに送信される。親のアプリケーション・ルータは、入手可能であり、最初に親のアプリケーション・ルータと任命された親のアプリケーション・ルータに送信された自身の集めたサブスクリプションの残りを含む、集められたサブスクリプションのサブセットを配信する。これは管理システムが、アプリケーション・セッションについてのアプリケーション・ルータの階層を構築したとみなされる。
【０１９３】
基本オブジェクトはアプリケーション・サーバ間で配布される。アプリケーション・サーバには、常に関連するローカル・アプリケーション・ルータの１つを介して届けられる。アプリケーション・サーバが、基本オブジェクトを別のアプリケーション・サーバに送信するとき、最初のアプリケーション・サーバは、第２のアプリケーション・サーバの識別子をＡＴＰパケットの受信アドレス・フィールドに入れて、基本オブジェクトをローカル・アプリケーション・ルータの１つに送信する。このアプリケーション・ルータは、オブジェクトを第２のアプリケーション・サーバのローカル・アプリケーション・ルータに送信する。第２のアプリケーション・サーバのローカル・アプリケーション・ルータは、オブジェクトを第２のアプリケーション・サーバに送信する。
【０１９４】
基本オブジェクトは、アプリケーション・サーバ間で以下の方法の１つを用いて配布される。
方法１）１つのアプリケーション・サーバによって受信された基本オブジェクトは、複製されてアプリケーション・セッションに参加している全ての他のアプリケーション・サーバに送信される。これは、オプションとして、例えば、アプリケーション・セッションに参加している全てのアプリケーション・サーバを、ＩＰマルチキャスト・アドレスに関連付けることによって効率的に行われ得る。
【０１９５】
方法２）各アプリケーション・サーバは、基本オブジェクトに対するサブスクリプションのセットをローカル・クライアントから受信する。そのようなサブスクリプション全ては、ローカル・クライアントが申込んでいる基本オブジェクトをすべて含んでいるがサブスクリプション・パラメータを含んでいない、ジョイント・サブスクリプションに集められる。集められたサブスクリプションは、他の全てのアプリケーション・サーバに送信される。ローカル・クライアントの中で、別のアプリケーション・サーバから集められたサブスクリプションを受信し、集められたサブスクリプションの基本オブジェクトに対するいずれかの発信源を知るアプリケーション・サーバは、申込んでいるアプリケーション・サーバにそのようなオブジェクトをすぐに送信し、サブスクリプションの関連する部分を格納する。関連するオブジェクトのそれ以降の更新も、申込んでいるアプリケーション・サーバにすぐに送信される。
方法３）各アプリケーション・サーバは、方法２と同様にサブスクリプションの集められたセットを用意する。集められたサブスクリプションは、サイト・マネージャに任命された親のアプリケーション・サーバに送信される。親のアプリケーション・サーバは、入手可能であり、最初に親のアプリケーション・サーバと任命された親のアプリケーション・サーバに送信された自身の集めたサブスクリプションの残りを含む、集められたサブスクリプションのサブセットを配信する。これは管理システムが、アプリケーション・セッションについてのアプリケーション・サーバの階層を構築したとみなされる。
【０１９６】
セッションに参加している全てのアプリケーション・アクセス・サーバに配布される必要のある制御データは、例えば、クライアントの加入及び脱退並びにクライアント・グループの作成及び破壊を含んでいる。そのような制御データは、セッションの全てのアプリケーション・ルータにマルチキャストされるべきである。アプリケーション・ルータは、制御メッセージを終了させるか、それを要求に応じてローカル・アプリケーション・サーバ又はサイト・マネージャに送る。
【０１９７】
いくつかのクライアントが、観戦者としてアプリケーション・アクセス・サーバに登録されてもよい。観戦者はアプリケーションの動作を更新することは許可されないが、ゲーム内での観戦者の視点に応じてサブスクリプションを更新することができる。
【０１９８】
本発明によるアプリケーション・アクセス・サーバは、階層的システムでも使用できる。図８はそのような構成の例を示しており、ここで高レベルのアプリケーション・アクセス・サーバ２０１は他のアプリケーション・アクセス・サーバ・ユニット２０３、２０５、２０７をサービスし、そしてこれらはアプリケーション・クライアント２０９をサービスする。高レベルのアプリケーション・アクセス・サーバ２０１は、ＡＴＰパケットをゲームデータ及び集められたサブスクリプションと共に、「クライアント」とみなされる下流のアプリケーション・アクセス・サーバ・ユニットから受信する。高レベルのアプリケーション・アクセス・サーバ２０１は、他のピア・アプリケーション・アクセス・サーバ・ユニット及びもしあれば階層でより高いレベルのアプリケーション・アクセス・サーバ・ユニットと通信する。階層的アプリケーション・アクセス・サーバ・システムは、多数のクライアントが関係するアプリケーションのためのゲーム状態の階層的分散表示を作成するのに使用される。
【０１９９】
リモート・アプリケーション・アクセス・サーバ・ユニットは、マルチキャスト型のツリーに構成されてもよく、その場合、マルチキャスト・グループ毎に１つのソーティング・バッファがあるであろう。全ての情報が全てのリモート・アプリケーション・アクセス・サーバ・ユニットに送信される、簡単な配布方式が使用されてもよい。この場合バッファはただ１つである。
【０２００】
アプリケーション・クライアントのセットが、小さなレイテンシをもたらすブロードバンド接続を有していてもよく、その場合はアプリケーション・アクセス・サーバは全く必要ない。典型的な例としては、全てのプレーヤが同じＬＡＮにつながっているものである。ゲームのアプリケーションやＡＰＩが依然としてアプリケーション・アクセス・サーバを予期したものである場合、クライアントの装置でソフトウェアでアプリケーション・アクセス・サーバ機能を実行することが可能であろう。
【０２０１】
アプリケーション・アクセス・サーバ・ユニットは、ネットワーク内のあらゆる中間的位置に配置されてもよい。これはクライアントとアプリケーション・アクセス・サーバとの間の「リンク」プロトコルが、オプションとしてＵＤＰ／ＩＰ又はＴＣＰ／ＩＰであり得ることを意味する。代替的に、ダイヤル・インのゲーム・サービスを実行中の中央のゲーム・サーバが、部品としてアプリケーション・アクセス・サーバ・ユニットを使用することもできる。ここで中央のサイトは、アプリケーション・アクセス・サーバ・ユニット及びアプリケーション・ロビー・サーバに接続されたモデム・プールのセットから構成されるだろう。これは中央のサイトを構築するのに効率的で規模が変更可能であるが、ゲーム・トラフィックを早期に集めるという利点はないだろう。
【図面の簡単な説明】
【０２０２】
【図１】本発明によるネットワークの実施形態を示す図である。
【図２】本発明の第１の実施形態によるアプリケーション・アクセス・サーバを示す図である。
【図３】本発明によるアプリケーション状態レコードの実施形態を示す図である。
【図４】本発明の実施形態によるアプリケーション・クライアントを示す図である。
【図５】本発明の実施形態によって使用される通信スタックを示す図である。
【図６】本発明のアプリケーション・アクセス・サーバの第２の実施形態を示す図である。
【図７】アプリケーション・アクセス・サーバの第２の実施形態で使用されるアプリケーション・ルータを示す図である。
【図８】本発明の実施形態で使用されるアプリケーション・アクセス・サーバの階層構造を表わす図である。
【図１】
2008022573.tif 000005
【図２】
2008022573.tif 000006
【図３】
2008022573.tif 000007
【図４】
2008022573.tif 000008
【図５】
2008022573.tif 000009
【図６】
2008022573.tif 000010
【図７】
2008022573.tif 000011
【図８】
2008022573.tif 000012