JP2000504133A - 対話型アプリケーションのためのグループサーバー通信システム - Google Patents

Abstract

(57)【要約】 ホストコンピュータ（５８、５９、６０、６１）およびグループ通信サーバー（６２）を含むネットワークを通して対話型アプリケーションを展開する方法が開示される。方法は、従来のネットワークリンク、ユニキャストゲートウェイ、およびルーターよりなる従来のユニキャストネットワークアーキテクチャーで動作する。ホストは、ユニキャストによって宛先グループアドレスを含むメッセージをグループ通信サーバーに送る。グループアドレスは、グループ通信サーバーによって維持されるメッセージグループを選択する。各メッセージグループに対して、グループ通信サーバーはまた、特定のグループのメンバーであるすべてのホストのリスト（１４２）を維持する。この最も簡単な実現形態において、方法は、グループサーバーが宛先グループアドレスを含むホストからのメッセージを受け取ることを含む。グループアドレスを用いて、グループ通信サーバーは次に、グループへのメッセージの目的地であるグループのすべてのホストメンバーをリストするメッセージグループを選択する。グループ通信サーバーは次に、メッセージを各目的地ホストに送る。対話型アプリケーションでは、多くのメッセージは時間的に互いに接近してグループサーバーに到着する。単に各メッセージを目的地ホストに送るのではなく、グループ通信サーバーは、特定の期間中に受け取られた各メッセージの内容を集成して、集成メッセージを目的地ホストに送る。この方法は、ネットワーク化された対話型アプリケーション内のホスト間のメッセージ通信量を減らし、またホスト間の通信での待ち時間の減少に貢献する。

Description

【発明の詳細な説明】 対話型アプリケーションのためのグループサーバー通信システム 産業上の利用分野 本発明は、コンピュータネットワークシステムに関し、特に、メッセージレー トおよび待ち時間を減少させるグループサーバ通信システムおよび方法に関する 。 発明の背景 今日、コンピュータシステム上で実行される対話型アプリケーションは広範囲 にわたっている。これらはすべて、ユーザに対するダイナミックな応答によって 特徴づけられる。ユーザは、コンピュータに入力を提供し、アプリケーションは 迅速に応答する。パーソナルコンピュータ（ＰＣ）上の対話型アプリケーション の一般に普及している一例としてゲームが挙げられる。この場合、ユーザに対す る迅速な応答とは、３０ミリ秒と１００ミリ秒との間で新しい画像を画面上に描 き出すことを意味し得る。ゲームなどの対話型アプリケーションは、内部タイム ベースを用いてユーザとの対話速度を制御する。アプリケーションは、このタイ ムベースを用いて、ユーザの入力がサンプリングされ、画面が再び描き出され、 サウンドが鳴らされるレートを引き出す。 コンピュータがより強力かつ一般的になるにつれて、コンピュータをネットワ ークで接続することは重要になった。ネットワークは、ノードおよびリンクから 構成される。ノードは、リンクを介しかつ他のノードを通して、各ノードからネ ットワーク内の他のノードのそれぞれにパスが存在するように接続されている。 各ノードは、少なくとも１つのリンクでネットワークに接続され得る。ノードは さらに、ホスト、ゲートウェイ、およびルータに分類される。ホストは、１つの リンクによってネットワークに接続されているコンピュータシステムである。ホ ストは、メッセージを送信および受信することによってネットワーク上の他のノ ードと通信する。ゲートウェイは、１つより多くのリンクによってネットワーク に接続されているコンピュータシステムである。ゲートウェイは、ホストのよう に他のノードと通信するだけでなく、それらのネットワークリンクの１つのリン ク上のメッセージを他のネットワークリンク上の他のノードに転送する。メッセ ージを転送するこの処理は、ルーティングと呼ばれる。メッセージを送信および 受信する機能、ならびにそれらのルーティング機能に加えて、ゲートウェイは、 ネットワーク内の他の機能を果たし得る。ルータは、１つより多くのリンクによ ってネットワークに接続されているノードであり、その唯一の機能は、１つのネ ットワークリンク上のメッセージをそのネットワークリンクが接続されている他 のネットワークリンクに転送することである。多くのネットワークリンクからな るネットワークは、ゲートウェイを有するサブネットワークおよび／またはサブ ネットワークを共に接続して、いわゆるインターネットを形成するルータのネッ トワークであると考えられ得る。今日、世界的なインターネットの広範囲に知ら れている例としては、フルタイムで世界的に、１９９５年では１０、０００、０ ００より多くのコンピュータが接続されている、いわゆる「インターネット」で ある。 単一の世界的なネットワーク上に非常に多くのコンピュータが存在するので、 多くの人々を、共同で使用されるネットワーク化された対話型アプリケーション にまとめるネットワーク化された対話型アプリケーションを形成することが所望 される。残念なことに、このような共同で使用されるネットワーク化された対話 型アプリケーションの形成については、既存のネットワーク技術に制限されると いう問題がある。 例えば、ネットワーク上で展開されるように設計され、多数のプレイヤーによ って同時にプレイされるゲームについて考えてみよう。このようなゲームは、ネ ットワークに接続されているＰＣ上のソフトウェアにおいて実行され得る。レー トは、その内部タイムベースによって設定され、ローカルユーザの入力がサンプ リングされ、他のプレイヤーのＰＣからネットワークを通じてメッセージを受信 し、他のプレイヤーのＰＣにメッセージを送信する。典型的なレートは、１００ ミリ秒の期間において１秒間あたり１０回である。ＰＣ間で送信されるメッセー ジは、すべてのＰＣ間でゲームを一貫したものに維持するのに必要な情報を含む 。各プレイヤーが移動し得るように空間環境の錯覚を起こさせるゲームにおいて は、パケットは、プレイヤーが移動するプレイヤーの新しい位置に関する情報を 含み得る。今日、ローカルエリアネットワーク（ＬＡＮ）上で多数のプレイヤー 間で、またはモデムを用いて公衆電話回線を通して２人のプレイヤーでプレイさ れ得るＰＣゲームが多く市販されている。このようなゲームによって送信される ネットワークメッセージは、ゲームに特異的な広範囲な情報を含む。これには、 ゲーム内の他のプレイヤーに影響する、あるプレイヤーによって取られる特別な アクションと共に、ゲーム内のオブジェクトの位置および速度情報が含まれ得る 。 モデムを介してプレイされる２人のプレイヤー用ゲームの場合は、特に簡単で ある。メッセージレートが１秒当たり１０メッセージである場合、各ＰＣは、他 のＰＣに１秒当たり１０メッセージを送信し、一秒当たり１０メッセージを受信 する。モデムおよび電話回線によって導入される遅延は、小さく、大抵のゲーム においては認識されない。残念なことに、ネットワーク化された対話型アプリケ ーションでは、２人のプレイヤーの場合面白くない。ＬＡＮ上で８人のプレイヤ ーが同じゲームをプレイする場合、メッセージレートは増加する。各ＰＣは、各 期間毎に他の７人のプレイヤーのそれぞれに１つずつ７個のメッセージを送らな ければならず、同一の期間に他のプレイヤーから７個のメッセージを受け取る。 通信期間が１００ミリ秒である場合、メッセージレートの合計は、１秒当たり７ ０メッセージが送信され、１秒当たり７０メッセージが受信される。これより理 解され得るように、メッセージレートは、ゲームのプレイヤーの数に対して直線 的に増加する。一般に普及しているＬＡＮによってサポートされているメッセー ジレートおよびデータレートは、妥当なメッセージサイズで大多数のプレイヤー をサポートするのに十分高い。残念なことに、ＬＡＮは、市販のアプリケーショ ン内でのみ展開され、ネットワーク化された対話型アプリケーションを消費者ユ ーザに対して展開することについては考慮され得ない。 消費者ユーザが今日利用できる広エリアネットワークはすべて、モデムを用い て公衆電話回線を通してアクセスされなければならない。モデム速度は、急速に 増加し、今では１秒当たり２８．８キロビットのビットレートに到達した。これ は、従来の電話回線の信号対ノイズ比によって設定される限界に近い。ＩＳＤＮ を用いることによってさらに速度を増加させることが可能であるが、この技術は 、大量使用のために市場に出せる準備が整っていない。はるかに広い帯域幅を提 供する他の新しい広エリアネットワーキング技術について議論されているが、い ずれも商業用に実用化するには至っていない。従って、ネットワーク化された対 話型アプリケーションを展開する場合、既存のネットワーキングおよび通信イン フラストラクチャと共に動作するように展開させる必要がある。 ８人のプレイヤー用のネットワーク化されたゲームを例に挙げて、プレイヤー のそれぞれのＰＣがネットワークに１秒当たり２８．８キロビットのモデムで接 続されている広エリアネットワークの実行について考えてみよう。この例で用い られるネットワークを、ネットワークプロトコルおよびルーティング挙動のすべ てがうまく定義され理解されるように、インターネットであると仮定しよう。ゲ ームがＴＣＰ／ＩＰを用いて、そのメッセージをゲーム内のＰＣ間で送信する場 合、公衆電話回線を介したＰＰＰプロトコルは、ＴＣＰ／ＩＰヘッダを圧縮する ようにうまく利用され得る。それでも、典型的なメッセージは、約２５バイトの サイズである。これは、モデムを通して送信すると、２５０ビットである。メッ セージは、ゲーム内の他のＰＣのそれぞれに対して１秒当たり１０回で送信され 、他のＰＣから１秒当たり１０回で受信される。これは、１秒当たり３５．０キ ロビットであり、モデムの能力を２０％越えている。メッセージが２０バイトに 減少すると、８人のプレイヤーしかサポートされ得ないが、このアプローチは、 明らかに、多数の参加者によって使用されるネットワーク化された対話型アプリ ケーションをサポートし得ない。ネットワーク接続の帯域幅だけでなく、他の問 題がある。高パケットレートによって引き起こされる各ＰＣ上のローディングが あり、送信用のパケットをすべて送信するのに必要な時間によって導入される待 ち時間がある。ＰＣによって送信または受信される各パケットは、ある量の処理 時間を必要とする。パケットレートがゲーム内のプレイヤーの数と共に増加する につれて、ゲームソフトウェア自体を走らせるために利用できるプロセッサの数 は減る。対話型アプリケーションにおいて待ち時間は重要である。なぜなら、待 ち時間は、システムの応答性を限定するからである。プレイヤーがそのシステム 上 で新しい入力を提供すると、その入力が即座に他のプレイヤーのすべてのシステ ム上のゲームに影響を与えることが所望される。これは、特に、ゲームの結果が 、他のプレイヤーのアクションによって移動する標的を撃つプレイヤーに依存す る任意のゲームにおいて特に重要である。この場合待ち時間は、プレイヤーが標 的を動かすように動作したときから、標的がゲーム内の他のプレイヤーの画面上 で移動するときまでの時間である。この待ち時間の主な部分は、メッセージをゲ ーム内の他の７人のプレイヤーに送信する必要がある時間から生じる。この例に おいて、メッセージを他の７人のプレイヤーに送信する時間は、約５０ミリ秒で ある。７人のうちの最初のプレイヤーがメッセージを迅速に受信してから、５０ ミリ秒経過してから、７人のうちの最後のプレイヤーがメッセージを受信する。 インターネットプロトコルマルチキャスティング 上記のように、インターネットは、高エリアネットワークの広く知られている 例である。インターネットは、正式にはインターネットプロトコル（ＩＰ）と呼 ばれるプロトコルに基づいている。ネットワークプロトコルのレイヤーのＯＳＩ 基準モデルにおいて、ＩＰは、レイヤー３またはネットワークレイヤープロトコ ルに対応する。ＩＰは、インターネット内の２つのノード間におけるパケットの 送信およびルーティングのためのサービスを提供する。アドレッシングモデルは 、ネットワーク内のすべてのノードに対して３２ビットアドレスを提供し、すべ てのパケットは、ソースおよび宛先アドレスを搬送する。ＩＰはまた、インター ネットワークにおけるネットワークリンク間のパケットのルーティングを規定す る。ゲートウェイおよびルータは、受信するパケットの宛先アドレスに基づいて ルーティング情報を参照するために用いられるテーブルを維持する。ルーティン グ情報は、パケットが、ゲートウェイ／ルータに接続されたローカルネットワー クリンク上でその宛先に直接到達可能であるかどうかをゲートウェイ／ルータに 知らせ、または、もし到達可能でない場合には、パケットが転送されるべきロー カルネットワークリンクの１つのリンク上の他のゲートウェイ／ルータのアドレ スを知らせる。ＩＰ以外には、レイヤー４搬送プロトコルＴＣＰおよびＵＤＰが ある。ＵＤＰは、データグラムの信頼のおけるまたは秩序のある送達を保証しな いアプ リケーションにデータグラム送達サービスを提供する。ＴＣＰは、データストリ ームの信頼のおける送達を提供するアプリケーションとの接続指向のサービスで ある。ＴＣＰは、ストリームをパケットに分割し、信頼のおける秩序のある送達 を確実にする。Internet Society RFGs: RFC-791"Internet Protocol"，RFC-793 "Transmission Control Protocol" and RFC-1180"A TCP/IP Tutorial"を参照の こと。ＩＰ、ＴＣＰおよびＵＤＰは、ユニキャストプロトコルであり、パケット 、ストリームまたはデータグラムは、ソースから単一の宛先に送信される。 例として、図１および図２を参照する。図１は、ホスト１、２、３および４、 ならびにネットワークリンク１１、１２、１３、１４、１５、１６、１７、１８ および１９、ならびにルータ５、６、７、８、９および１０を有する従来のユニ キャストネットワークを示す。この例において、各ホストは、データペイロード を他のホストのそれぞれに送信したい。ホスト１は、ネットワークアドレスＡ、 ホスト２は、ネットワークアドレスＣ、ホスト３は、ネットワークアドレスＢ、 およびホスト４は、ネットワークアドレスＤを有する。既存のネットワークプロ トコルは、通常、ソースアドレス、宛先アドレス、およびペイロードを含むパケ ットフォーマットに基づいている。これは、ＩＰなどの一般に用いられる広エリ アネットワークプロトコルを示す。実際のＩＰパケットには他の構成要素がある が、この例のために、これらのアイテムのみを考慮する。図２は、ＩＰなどの従 来のユニキャストネットワークプロトコルを用いてホストによって互いに送信さ れるパケットの例を示す。ホスト１は、パケット２０をホスト３に、パケット２ １をホスト２に、パケット２２をホスト４に送信する。ホスト１は、同一のデー タＰ１を他の３つのホストのそれぞれに送信したいので、これらの３つのすべて のパケットにおけるペイロードは同一である。パケット２０は、ネットワークリ ンク１１、１２、１５および１８を介して、ルータ５、６および８を通ってホス ト３に到達する。同様に、ホスト３は、パケット２３をホスト１に、パケット２ ４をホスト２に、パケット２５をホスト４に送信する。ホスト２および４は、パ ケット２６、２７、２８および２９、３０、３１をそれぞれ他の３つのホストに 送信する。これらのパケットはすべて、ソースホストから宛先ホストまで個別に ユニキャストネットワークによって搬送される。従って、この例では、各ホスト は、そのペイロードを他の３つのホストに送信するために、３つのパケットを送 信し、３つのパケットを受信しなければならない。 理解され得るように、各ホストは、対話型アプリケーションにおいて通信を所 望する他のホストの各々にパケットを送信しなければならない。さらに、各ホス トは、そのホストと通信を所望する他のホストの各々からパケットを受信する。 対話型アプリケーションにおいて、これは、規則的かつ高いレートで発生する。 互いに通信を所望するホストはすべて、１秒間に８から１０回で互いにパケット を送信する必要がある。この例のように４つのホストが互いに通信する場合、各 ホストは、１秒当たり８から１０回で、３つのメッセージを送信し、３つのメッ セージを受信する。互いに通信する必要があるアプリケーション内のホストの数 が増加するにつれて、メッセージレートは、従来の公衆回線ではサポートされ得 ないレートに到達する。これによって、ユニキャスト搬送プロトコルは、多数の 参加者に対して対話型アプリケーションを送達するには不適切となる。なぜなら 、これらを使用すると、参加者の数と共に増える高パケットレートの問題を引き 起こすからである。 ＩＰプロトコルを拡張し、マルチキャスティングをサポートする試みがなされ ている。RFC-1112"Host Extensions for IP Multicasting"を参照のこと。この 文献は、ＩＰマルチキャスティングを可能にするＩＰプロトコルの一連の拡張に ついて記載している。ＩＰマルチキャスティングは、データグラムを単一の宛先 アドレスにアドレス指定することによって、ＩＰデータグラムのホストグループ への送信をサポートする。マルチキャストアドレスは、ＩＰアドレス空間のサブ セットであり、クラスＤ ＩＰアドレス（これらは、高位４ビットにおける「１ １１０」を有するＩＰアドレスである）のサブセットである。ホストグループは 、ゼロまたはそれ以上のＩＰホストを含み、ＩＰマルチキャスティングプロトコ ルは、アドレス指定されるグループのすべてのメンバーにマルチキャストデータ グラムを送信する。ホストは、ダイナミックにグループに参加およびグループか ら離れ、マルチキャストデータグラムのルーティングは、マルチキャストルータ およびゲートウェイによってサポートされる。マルチキャスト通信へのこの一般 的なアプローチを「分配マルチキャスト通信」として記載するのが適切である。 こ れは、分配技術である。なぜなら、メッセージ送達および複製の仕事が、ネット ワークを通じて、すべてのマルチキャストルータに分配されるからである。広エ リアネットワークにおいて分配されたマルチキャスト通信を動作させるためには 、マルチキャストホストのルータ処理データグラムのすべてが、マルチキャスト データグラムのルーティングをサポートしなければならない。このようなマルチ キャストルータは、マルチキャストデータグラムをローカルホストに送達するた めに、ローカルでルータに接続されたすべてのホストのマルチキャストグループ メンバーシップを知らなければならない。マルチキャストルータはまた、ローカ ルネットワークリンク上でマルチキャストパケットをルータに転送することがで きなければならない。マルチキャストルータはまた、どのローカルルータ（もし 存在するならば）にマルチキャストデータグラムを転送しなければならないかを 決定しなければならない。マルチキャストルータによってマスチキャストデータ グラムが受け取られると、そのグループアドレスは、グループアドレスの各ロー カルマルチキャストルータ用のリストと比較される。一致した場合、データグラ ムはそのローカルマルチキャストルータに転送される。従って、ネットワークに おけるマルチキャストルータは、それらが、データグラムを転送するグループア ドレスの正確かつ最新のデータリストを維持しなければならない。これらのリス トは、ホストが、マルチキャストグループに参加またはグループから離れるとき に更新される。ホストは、これを、インターネットグループ管理プロトコル（Ｉ ＧＭＰ）を用いてメッセージをそれらのすぐ近隣のマルチキャストルータに送信 することによって行う。分配マルチキャスト通信の他の属性は、ルータが、特定 のグループに関するグループのメンバーシップ情報を、ネットワークを通じてそ のグループの転送トラヒックとなるすべての他のルータに伝搬しなければならな いことである。ＲＦＣ−１１１２は、どのようにしてこれが行われるかについて 記載していない。多くの様々なアプローチがこの問題を解決するために規定され ているが、これらのアプローチについては、関連の従来技術の記載において後述 する。これらのアプローチはすべて、それらの相違にもかかわらず、マルチキャ ストルータ間でマルチキャストルーティング情報を伝搬する方法および分配され たマルチキャスト通信をサポートするインターネットワークにおけるマルチキャ ス トデータグラムのルーティングの技術である。 分配されたマルチキャスト通信アプローチは、多くの望ましくない副作用を有 する。すべての関連ルータへのグループメンバーシップ情報の伝搬プロセスは瞬 間的ではない。大きく複雑なネットワークにおいては、更新されたグループメン バーシップ情報を受信しなければならないルータの数およびグループメンバーシ ップ更新の情報が通過しなければならないルータの数に依存して非常に長い時間 かかり得る。このプロセスは、使用されるアルゴリズムの特性に応じて、優に数 秒および数分かかり得る。ＲＦＣ−１１１２は、この問題およびマルチキャスト 通信のための実用的なルーティングアルゴリズムを実行することによって取り扱 われなければならない副作用のいくつかについて言及している。グループがダイ ナミックに作成および破壊されるときに１つの問題が発生する。グループアドレ スを割り当てるための中央管轄部がネットワーク内に存在しないため、分配ネッ トワークにおいてグループアドレスの割当てを複製することは容易にできる。こ れによって、正しくないデータグラム送達が行われ、ホストは、複製グループか ら欲しくないデータグラムを受信することになる。これには、各ホストが欲しく ないデータグラムをフィルターにかける方法が必要である。他の一連の問題は、 グループが作成され、破壊され、またはそのメンバーシップが変更されたときか ら、データグラムをメンバーホストにルートする必要があるすべてのルータにこ れらの変更が伝えられたときまでの時間遅延から生じる。ホストＮが、参加メッ セージをそのローカルルータに送信することによって既存のグループに参加する 場合を想定してみよう。グループはすでにネットワーク内でホストＮから離れた 多数のルータホップであるホストＭを含んでいる。ホストＮがホストＭに参加メ ッセージを送信した直後、ホストＭは、データグラムをグループに送信するが、 ホストＭのローカルルータは、グループメンバーシップの変更を知らされていな い。その結果、データグラムは、最終的にホストＮに到達する、ルータからのネ ットワーク内の唯一のパスであるホストＭのローカルルータに接続されている特 定のネットワークリンクの１つに転送されない。その結果、Ｍのローカルルータ がそのグループメンバーシップ情報を更新するまで、ホストＮは、ホストＭから グループにアドレス指定されたデータグラムを受信しない。他の関連した問題も 発生し得る。ホストがグループを離れるとき、そのグループにアドレス指定され たメッセージは、しばらくの間連続して、そのホストのローカルルータまでその ホストにルートされる。ローカルルータは、そのホストのローカルネットワーク にデータグラムをルートしないことは少なくとも知っている。それでも、迅速に 変更されるメンバーシップを有するアクティブなメッセージグループが多く存在 するときには、大きなネットワークにおいて、大量の不要なデータグラムが搬送 され得る。 最後に、分配マルチキャスト通信は、ホスト間のメッセージレートを十分に減 少させない。分配マルチキャスト通信では、各ホストは、メッセージをグループ 内の他のホストのすべてに送信するために、メッセージグループにアドレス指定 された１つのメッセージを送信するだけでよい。これは、１つのメッセージが、 グループ内の他のホストのそれぞれに送信されなければならない従来のユニキャ スト通信よりも改善されている。しかし、分配マルチキャスト通信は、グループ 内の多数のホストが、時間的に近接したグループにメッセージを送信していると きに、ホストのそれぞれにおいて受信したメッセージレートを減少させるために 何もしない。１秒当たり７回でメッセージをグループに送信する１０個のホスト グループの例に戻ろう。従来のユニキャスト通信では、各ホストは、１秒当たり ７回で９つのメッセージを他のホストに送信し、１秒当たり７回で９つのメッセ ージを受信する必要がある。分配マルチキャスト通信では、各ホストは、すべて のホストを含むグループに１秒当たり７回で１つのメッセージのみを送信する必 要があるが、１秒当たり７回で９つのメッセージを受信する。受信されるメッセ ージの数をさらに減少させることが所望される。 分配マルチキャスティングの例を図３および図４に示す。図３は、マルチキャ ストルータ３９、４０、４１、４２、４３および４４、ならびにホスト３５、３ ６、３７および３８、ならびにネットワークリンク４５、４６、４７、４８、４ ９、５０、５１、５２および５３を有するネットワークを示す。４つのホストは 、ユニキャストネットワークアドレスＡ、Ｂ、ＣおよびＤを有し、アドレスＥを 有するメッセージグループのすべてのメンバーでもある。予め、メッセージグル ープを作成し、各ホストは、マルチキャストルータのそれぞれがメッセージグル ー プを知り、適切なルーティング情報を有するように、メッセージグループに参加 した。マルチキャスト拡張を有するＩＰなどのネットワークプロトコルを、この 例において使用するものと仮定する。ホスト３５は、ソースアドレスＡおよび宛 先マルチキャストアドレスＥを有するパケット５４を全メッセージグループに送 信する。同様に、ホスト３７はパケット５５を全メッセージグループに送信し、 ホスト３６はパケット５６を全メッセージグループに送信し、ホスト３８はパケ ット５７を全メッセージグループに送信する。パケットがマルチキャストルータ によって取り扱われている間、パケットをグループのすべてのメンバーに送達さ せるためにパケットは必要に応じて複製される。ホスト３５によって送信される パケットがどのようにして最終的に他のホストに送達されるかについて考えてみ よう。パケット５４は、ネットワークリンク４５を介してマルチキャストルータ ３９に搬送される。ルータは、そのルーティングテーブルから、マルチキャスト パケットが、ネットワークリンク４６および４７に送信されなければならないこ とを決定し、そのパケットを複製し、これらのネットワークリンクの両方にパケ ットを送信する。パケットは、マルチキャストルータ４０および４３に受信され る。マルチキャストルータ４３は、パケットをネットワークリンク５０に送信し 、ルータ４０は、そのパケットをリンク４８および４９に送信する。次に、パケ ットは、マルチキャストルータ４４、４２および４１で受信される。ルータ４１ は、パケットがホスト３６によって受信される、ネットワークリンク５１を介し てパケットを送信する。ルータ４２は、パケットをネットワークリンク５２を介 してホスト３７に送信し、ルータ４４は、パケットをリンク５３を介してホスト ３８に送信する。ホストによってマルチキャストグループＥに送信される他のパ ケットのそれぞれについて、同様のプロセスが行われる。各ホストによって受信 される最後のパケットを図４に示す。 分配マルチキャスティングが、ネットワーク化された対話型アプリケーション においてホストによって送信される必要があるメッセージの数を減少させる一方 、ホストが受信するメッセージの数に影響はない。グループメンバーシップが迅 速に変化し、マルチキャストルータの特別なネットワークインフラストラクチャ を必要とするとき、分配マルチキャスティングは、挙動が良好でないという他の 欠 点を有する。分配マルチキャスティングはまた、メッセージの凝集をサポートせ ず、また凝集することもできない。なぜなら、メッセージ送達は分配されている からである。分配マルチキャスティングは、メッセージグループとユニキャスト ホストアドレス間での論理的な動作を規定するメッセージもサポートしない。 これらの問題はすべて、分配マルチキャスト通信に対する設計目標に関連して 配置されると理解され得る。分配マルチキャスト通信は、グループが迅速に作成 され、変更され、破壊される対話型アプリケーションに対して設計されなかった 。その代わりに、分配マルチキャスト通信は、おそらく数分または数時間におい て測定される比較的長期の間にわたってグループが作成、変更、および破壊され るアプリケーションに対して最適化された。一例としては、すべての参加者が、 １時間連続し得る会議に対して特定の時間に接続されることに同意したビデオ会 議が挙げられる。他の例としては、おそらく数千または数百万で測定される、１ つのホストから多くの受信ホストへの音声または映像プログラムの送信が挙げら れる。マルチキャストグループは、音声／映像プログラムの存続している間存在 する。ホストメンバーは、ダイナミックに参加および離れるが、このアプリケー ションにおいて、接続が確立または切断される前に参加または離れたときからか なりの時間遅延があることが受け入れられ得る。 ＩＰおよびＩＰへのマルチキャスト拡張は、パケットのルーティングに基づい ているが、非同期転送モード（ＡＴＭ）を呼ばれる他の形式の広エリアネットワ ーキング技術は、スイッチを介して固定サイズのセルを切り替えることに基づい ている。データグラムおよび接続指向サービスの両方をサポートするＩＰと違っ て、ＡＴＭは、基本的に接続指向である。ＡＴＭネットワークは、ポイントから ポイントへのリンクによって相互に接続されているＡＴＭスイッチからなる。ホ ストシステムは、ネットワークのリーブ（leaves）に接続されている。通信が、 ネットワークを通してホスト間で発生し得る前に、仮想の回路は、ネットワーク にわってセットアップされなければならない。２つの形態の通信は、ＡＴＭネッ トワークによってサポートされ得る。２つのホスト間の双方向のポイントからポ イントへのおよび１つのホストから多数のホストへの一方向のポイントからマル チポイントである。しかし、ＡＴＭは、どんな形態のマルチキャスティングも直 接サポートしない。ＡＴＭの他に、マルチキャスティングをレイヤー状にするた めの多数の提案がなされている。１つのアプローチは、図８に示すマルチキャス トサーバと呼ばれるものである。ホストシステム１１２、１１３、１１４および １１５は、マルチキャストサーバ１０５に対してポイントからポイントへの接続 １０６、１０７、１０８および１０９をセットアップする。ＡＴＭセルは、これ らのリンクを介してホストによってマルチキャストサーバへ送信される。マルチ キャストサーバは、集合的にメッセージグループを構成するホストにポイントか らマルチポイントへの接続１１１をセットアップする。グループにアドレス指定 されサーバに送信されるセルは、ポイントからマルチポイントへのリンク１１１ に転送される。ＡＴＭネットワーク１１０は、ホストとサーバとの間のすべての 接続を維持するための転送および切り替えを行う。ポイントからマルチポイント への接続によって搬送されるセルは、分岐ネットワークリンク間のネットワーク ツリーにおける分岐点におけるＡＴＭスイッチによって必要に応じて複製され、 分岐ネットワークリンクに転送される。従って、サーバではなく、ネットワーク が、セルおよびそれらのペイロードの複製を行う。この方法は、対話型アプリケ ーションに使用される場合、分配マルチキャスティングと同様の問題を有する。 各ホストは、他のホストのそれぞれから個々のセルを受信するので、単一のホス トに標的付けられたセルのペイロードの凝集はない。ホストグループの一連のメ ンバーに対する論理的な動作に基づいて、セルをホストにアドレス指定するサポ ートはない。 関連の従来技術 本発明の分野に関連する既存の特許および欧州特許出願が多数ある。これらは 、２つの個別のカテゴリー：マルチキャストルーティング／分配およびソースか ら宛先マルチキャストストリームに分類され得る。 マルチキャストルーティングおよび分配 これらの特許は、Cottonらによる米国特許第4,740,954号、Perlmanによる米国 特許第4,864,559号、Doeringerらによる米国特許第5,361,256号、Perlmanによる 米国特許第5,079,767号、およびCidonらによる米国特許第5,309,433号である。 これらの特許は、集合的に、分配マルチキャストネットワークにおけるデータグ ラムのルーティングおよび分配に関する様々なアルゴリズムを網羅している。こ れらの特許のいずれも、メッセージグループが迅速に変化したときに挙動が良好 でないなどの、このクラスのマルチキャストルーティングおよびメッセージ分配 について上述した問題を扱っていない。これらすべての特許において、メッセー ジは、ルータの分配ネットワークを介して、ホストからグループのメンバーであ る複数の宛先ホストに送信される。これらの特許は、分配マルチキャスティング の改変を扱っているに過ぎないので、これらの特許は、受信メッセージのレート を減少させる手段、メッセージを凝集する方法を提供せず、メッセージグループ に対する論理動作を行うメッセージ内での方法を提供していない。 宛先マルチキャストストリームへのソース これらは、ＰＣＴおよび欧州特許出願である。これらは、PerlmanらによるEP0 637 149 A2号、DanneelsらによるPCT/US94/11282号、およびSivakumarらによる ＰＣＴ／ＵＳ９４／１１２７８号である。これらの３つの特許出願は、データス トリームのソースからグループの宛先への送信を取り扱う。これらの特許出願の いずれにおいても、グループの多数のメンバー間でのデータの送信方法について は記載していない。これらのすべての出願において、データ送信は、ソースから 複数の宛先において行われる。これらの特許出願は、ポイントからマルチポイン トへの通信のみを取り扱うので、これらの特許出願は、受信されたメッセージの レートを減少させる手段、メッセージを凝集する方法を提供せず、メッセージグ ループに対する論理的な動作を行うためのメッセージ内での方法を提供しない。 発明の要旨 本発明は、従来の広域通信ネットワークにわたる多数のホストコンピュータ間 の効率的な通信を促進することにより、多数のプレーヤー間でのコンピュータゲ ームなどの対話型アプリケーションを実現することに関する。このようなアプリ ケーションでは、各ホストは、対話型アプリケーションが各ホスト上で一致して 動作するのを保持するために他のホストが必要とする情報を互いにダイナミック に送り合う。本発明は、ホスト間で情報の通信を行うためにホストが用いるメッ セージグループの集合を維持するネットワークに接続するグループ通信サーバー を含む。本発明はさらに、ホストおよびサーバーによって使用されるサーバー− グループ通信プロトコルを含む。サーバー−グループ通信プロトコルは、ネット ワークのトランスポートレベルプロトコル（ＴＬＰ）の上層に位置し、上位レベ ルプロトコル（またはＵＬＰ）と呼ばれる。ＯＳＩ基準モデルでは、ＵＬＰは、 トランスポートの上部に構築されたセッション層プロトコル、またはアプリケー ション層プロトコルとして考えられ得る。ＵＬＰプロトコルは、ＴＬＰのアドレ ススペースとは異なるサーバー−グループアドレススペースを用いる。ホストは 、ＵＬＰアドレススペース内のアドレスへのメッセージを、ネットワークの下層 のユニキャストトランスポートプロトコルを用いてグループ通信サーバーに送る 。ＵＬＰアドレススペースは、ユニキャストアドレス、暗黙グループ通信アドレ ス、および論理グループ通信アドレスに区分される。暗黙および論理グループ通 信アドレスはまとめてグループ通信アドレスと呼ばれる。 ホストシステムは先ず、メッセージをいずれのＵＬＰアドレスに送る前にもグ ループ通信サーバーへの接続を確立しなければならない。この接続を確立するプ ロセスは、ＴＬＰメッセージをサーバーに送ることによって行われる。サーバー は、ユニキャストＵＬＰアドレスをホストに割り当て、このアドレスを受け取り 通知メッセージに入れてホストに戻すことによって接続を確立する。接続が行わ れると、ホストは、現存するメッセージグループについての問い合わせ、現存す るメッセージグループへの参加、新しいメッセージグループの作成、参加してい るメッセージグループからの離脱、およびサーバーの知っているＵＬＰアドレス へのメッセージの送信を行うことができる。各メッセージグループは、タイプに 依存して暗黙または論理ＵＬＰアドレスのいずれかを割り当てられる。 図５は、グループ通信サーバー（「ＧＭＳ」）を有する広域ネットワークの一 例を示す。ホスト５８はＴＬＰアドレスＡおよびＵＬＰアドレスＨを有し、ホス ト５９はＴＬＰアドレスＣおよびＵＬＰアドレスＪを有し、ホスト６０はＴＬＰ アドレスＢおよびＵＬＰアドレスＩを有し、ホスト６１はＴＬＰアドレスＤおよ びＵＬＰアドレスＫを有する。このネットワークは、ネットワークリンク６９、 ７０、７１、７２、７３、７４、７５、７６、および７７、ならびにユニキャス トルーター６３、６４、６５、６６、６７、および６８よりなる従来のユニキャ ストネットワークである。グループ通信サーバー６２は、あるメッセージグルー プに向けられたホストからのメッセージを受け取り、メッセージの内容をそのメ ッセージグループのメンバーに送る。図６は、ホストからそのホストがメンバー であるメッセージグループに送られるデータグラムの一例を示す。前述のように 、ここではＩＰなどのＴＬＰ（メッセージヘッダが発信元および宛先ＴＬＰアド レスを含む）が使用されるものと仮定する。ホスト５８は、ホストのＴＬＰ発信 元アドレスＡとＧＭＳ６２のための宛先ＴＬＰアドレスＳとを含むメッセージ８ ０を送る。宛先ＵＬＰアドレスＧは、ＧＭＳによって扱われる暗黙ＵＬＰアドレ スであり、ペイロードＰ１は、送られるデータとホストの発信元ＵＬＰアドレス Ｈの両方を含む。ＵＬＰメッセージをＧＭＳに送る前に、各ホストは既にＧＭＳ への接続を確立し、メッセージグループＧに参加しているものと仮定する。ホス ト６０は、データと発信元ＵＬＰアドレスＩとを含むペイロードＰ２を有するメ ッセージ８１を送る。ホスト５９は、データと発信元ＵＬＰアドレスＪとを含む ペイロードＰ３を有するメッセージ８２を送る。ホスト６１は、データと発信元 ＵＬＰアドレスＫとを含むペイロードＰ４を有するメッセージ８３を送る。ＧＭ Ｓはこれらのメッセージのすべてを受け取り、各メッセージがメンバーＨ、Ｉ、 Ｊ、およびＫを擁する暗黙メッセージグループＧに向けられていることを知る。 ＧＭＳはこれらのペイロードを集成してまたは集成せずにメッセージの処理を行 う。図６は集成しない場合を示し、図７は集成する場合を示す。 集成しない場合、ＧＭＳは発信メッセージ８４、８５、８６、８７、８８、８ ９、９０、９１、９２、９３、９４、および９５を生成し、これらをホストに送 る。これらのデータグラムは、それぞれＧＭＳおよびホストの発信元および宛先 ＴＬＰアドレスを含むＴＬＰヘッダを有する。データグラムの次のフィールドは データグラムの宛先ＵＬＰである。データグラム８４および８５は、ＴＬＰアド レスＡおよびＵＬＰアドレスＨを有するホスト５８に送られる。データグラム８ ７、８８、および８９は、ＴＬＰアドレスＢおよびＵＬＰアドレスＩを有するホ スト６０に送られる。データグラム９０、９１、および９２は、ＴＬＰアドレス ＣおよびＵＬＰアドレスＪを有するホスト５９に送られる。データグラム９３、 ９４、および９５は、ＴＬＰアドレスＤおよびＵＬＰアドレスＫを有するホスト ６１に送られる。各ホストが受け取ったペイロードから分かるように、各ホスト は他の３つのホストからのペイロードを受け取っている。各ホストはそれ自体の オリジナルメッセージのコピーは受け取っていないことに有意されたい。これは ＧＭＳがエコー抑制を行ったからである。アプリケーションによっては、ホスト が、自らもメンバーであるグループに送る各メッセージのエコーを受け取ること が有用である場合もあるため、これはＧＭＳの選択可能な属性である。図６の例 では、配信マルチキャスティングと同じメッセージ送達を本発明が如何に欠点な く実現し得るかを示している。集成しない場合、本発明により、ホストが、単一 のメッセージを１つのメッセージグループのメンバーである多数の他のホストに 送ることが可能である。これにより、各ホストが他のホストに送らなければなら ないメッセージの数が減るため、対話型アプリケーションでホストが処理しなけ ればならないメッセージ通信量が減少する。しかし、集成しない場合は、ホスト が受け取るメッセージ数は減らない。集成しない場合は、マルチキャストルータ ーを有するネットワークを必要とせず、配信マルチキャスティングと同じメッセ ージレートを実現することができる。インターネットなどの従来のユニキャスト ネットワークを使用することができる。本発明はまた、ダイナミックグループメ ンバーシップにより配信マルチキャスティングに生じる問題を回避する。グルー プメンバーシップは極めて迅速に変更することができる。ホストからＧＭＳにそ れぞれ１つのユニキャストメッセージを送るだけで、グループの結成、参加、お よび離脱が可能である。これらのメッセージはポイントからポイントへのメッセ ージであり、ネットワーク全体にわたって伝播させる必要はなく、またルーター 内のルーティングテーブルを変更する必要もない。この迅速且つ正確にグループ メンバーシップを変更できる能力は、ネットワーク化された対話型アプリケーシ ョンの実現にとって重要である。ゲームによって作成される３次元空間を通して 広がる何百人ものプレーヤーをサポートする、多プレーヤー用コンピュータゲー ムについて考えてみる。他のプレーヤーは視野から外れた他の領域にいるため、 常時見ることができ互いに影響し合うことができるのは２〜３人のプレーヤーだ けである。各プレーヤーのコンピュータからのデータをネットワークに伝送する ために従来の電話線を使用すると、各プレーヤーのすべてのアクションを他のす べてのプレーヤーに送ることは不可能である。しかし、常時近くには２〜３人の プレーヤーしかいないため、これを行う必要はない。必要なのは、互いに近くに いるプレーヤー間のデータを送ることだけである。これらのプレーヤー「グルー プ」が当然ながら本発明のメッセージグループに写像する。プレーヤーがゲーム の３次元空間を移動するに従って、プレーヤーは必要に応じてメッセージグルー プへの参加およびメッセージグループからの離脱を行う。これが迅速に行われな い場合は、ゲームの対話性が制約されるか、またはゲーム内の異なるプレーヤー 間で結果が一致しない事態が生じる。 本発明はまた、単一のホストに向けられた多数のメッセージのメッセージペイ ロードを単一のより大きなメッセージへと集成することが可能である。これは、 メッセージのすべてがホストに送られる前にＧＭＳによって受け取られるため、 可能となる。図７は、これがどのように働くかの一例を示す。ホストは、図５で 既に規定された同じアドレスを用いて、図６に示すのと全く同じ方法でＧＭＳに メッセージを送る。ホスト５８はメッセージ９６を送り、ホスト６０はメッセー ジ９７を送り、ホスト５９はメッセージ９８を送り、ホスト６１はメッセージ９ ９を送る。ＧＭＳはこれらのメッセージのすべてを受け取り、発信メッセージ１ ００、１０１、１０２、および１０３を作成する。これらのメッセージを作成す るプロセスについては、発明の詳細な説明において詳細に説明する。各メッセー ジは単一のホストに向けられ、多数のペイロード項目を有する集成ペイロードを 含む。メッセージ１００は、ホスト５８のための宛先ＵＬＰアドレスＨと、ホス ト５９、６０、および６１からのメッセージに含まれる集成ペイロードＰ２、Ｐ ３、およびＰ４とを有する。メッセージ１０１はホスト６０を宛先とし、１０２ はホスト５９を宛先とし、メッセージ１０３はホスト６１を宛先とする。分かり 得るように、各ホストは１つのメッセージを送り、１つのメッセージを受け取る 。受け取られたメッセージは長く、多数のペイロードを含むが、これは、多数の メッセージヘッダおよびメッセージ処理時間のためのの無駄な費用を掛けて多数 の メッセージを受け取ることに較べると著しい改善である。全体的に、本発明は、 各ホストが送信および受信しなければならないデータ量を飛躍的に低減させる。 モデムを使用する従来の電話線を通してのビットレートは低いため、送信および 受信しなければならないデータ量の削減は、直接、ホスト間のメッセージ通信に おける時間および待ち時間期を向上させる。 ホストは、ＵＬＰプロトコルでのＧＭＳへのコントロールメッセージを用いて 、メッセージグループの作成、参加、および離脱を行う。ホストはまた、ＧＭＳ に格納されているアプリケーション特異的ステート情報の読み出しおよび書き込 みを行い得る。ホストがメッセージを他のホストに送ると、メッセージは少なく とも暗黙グループアドレスに向けられなければならない。ＵＬＰ暗黙アドレスは いつでも、１つのホストから別のホストへのメッセージ内の主要アドレスであり 得る。メッセージは、選択的に、補助宛先アドレスを特定してもよい。多くの場 合、暗黙ＵＬＰアドレスがメッセージ内の唯一の宛先ＵＬＰアドレスである。Ｇ ＭＳは、暗黙メッセージグループに向けられたＵＬＰメッセージの、グループの メンバーであるすべてのホストへの送達を扱う。ＵＬＰ送信メッセージは、暗黙 ＵＬＰアドレスの主要宛先に加えて、選択的に、補助アドレスのアドレスリスト を特定し得る。この補助アドレスリストは、ユニキャストおよび論理ＵＬＰアド レスのみを含み得る。アドレスリストはまた、ユニキャストアドレスおよび論理 グループによって規定されるホストＵＬＰアドレス集合間で行われる集合演算子 を特定し得る。アドレスリストが処理されホスト集合を生成すると、この集合は 、メッセージ内の主要暗黙ＵＬＰアドレスによって特定される暗黙メッセージグ ループのメンバーであるホストの集合と交差する。このメッセージグループにお ける論理集合演算子を行う能力は、対話型アプリケーションでは非常に有用であ る。これにより、単一のＵＬＰメッセージが、送信しているホストがアドレスリ スト内のグループのメンバーについて何かを知る必要なく、計算された基準の集 合に適合するホストに選択的にメッセージを送達することが可能になる。ゲーム によって創成される３次元環境内で何百人のプレーヤーとネットワーク化された ゲームを行う例を再び取り上げる。プレーヤーのすべてが互いに対話を行い得る ゲームのうちのある領域内のすべてのゲームプレーヤーよりなる暗黙メッセージ グル ープについて考える。プレーヤーは多数のチームに分かれているものとする。ゲ ーム内の各チーム毎に論理メッセージグループが作成され得る。１つのチームに 属するこの領域内のプレーヤーのすべてに対してメッセージを送るためには、Ｕ ＬＰメッセージは、選択されたチームに属するすべてのプレーヤーのための論理 メッセージグループの補助アドレスを有する、その領域内のすべてのプレーヤー のためのＵＬＰ暗黙メッセージグループに送られ得る。ＧＭＳは、得られるメッ セージを目標ホストに送る前に、適切な集合共通部分化を行い得る。この結果、 メッセージはゲームの選択された領域内の選択されたチームに属するプレーヤー のみに送達され得る。 要約すれば、本発明は、全体的なメッセージレートを低減し、待ち時間を低減 する方法を提供することによって、広域ネットワーク上で多数の参加者のための 対話型アプリケーションを展開するという問題を取り扱う。本発明は、上述の「 配信マルチキャスト通信」方法に対抗するものとして、サーバーグループ通信方 法を使用する。本発明は、配信マルチキャスト通信方法の望ましくない副作用を 克服する。さらに、本発明はホスト間のメッセージレートを低減させる。上述の 例で指摘したように、従来の配信マルチキャスト通信では、各ホストは、すべて のホストを含むグループに１つのメッセージを毎秒７回送るだけでよいが、９つ のメッセージを毎秒７回受け取る。サーバーグループ通信の本発明では、各ホス トは１つのメッセージを毎秒７回送り、１つのメッセージを毎秒７回受け取る。 本発明は、米国特許第4,740,954号、第4,864,559号、第5,361,256号、第5,079 ,767号、および5,309,433号に開示されたマルチキャストルーティングおよび配 信方法とは異なる。これらの特許は、配信マルチキャスティングの変形例のみに 関するものであるため、受信メッセージレートを低減する手段、メッセージを集 成する方法、およびメッセージグループで論理演算を行うメッセージ内の方法を 提供しない。これは、多数のホストから１つのメッセージグループに向けられた メッセージがグループサーバーによって受け取られ、グループサーバーがメッセ ージの内容を処理しその結果を宛先ホストに伝送する本発明とは異なる。 本発明はまた、EP 0 637 149 A2、PCT/US94/11282、およびPCT/US94/11278に 開示された宛先マルチキャストストリーム方法とは異なる。これらの参照のすべ てにおいて、データ伝送は発信元から複数の指定先へと行われるが、本発明は、 送信しているホストからサーバホストシステムへ、次にサーバーホストから宛先 ホストへのデータ伝送について記載している。 本発明の上記のおよび他の特徴および利点は、添付の図面を参照して以下に述 びる発明の詳細な説明のより理解され得る。 図面の説明 図１は、ホスト、ネットワークリンク、およびルーターよりなる従来のユニキ ャストネットワークを示す。 図２は、４つのホスト間で対話型アプリケーションを実現するのに必要な従来 のユニキャストネットワーク上のユニキャストデータグラムを示す。 図３は、ホスト、ネットワークリンク、およびマルチキャストルーターよりな る従来のマルチキャストネットワークを示す。 図４は、４つのホスト間で対話型アプリケーションを実現するのに必要な従来 のマルチキャストネットワーク上のマルチキャストデータグラムを示す。 図５は、本発明のグループ通信サーバーを備えたユニキャストネットワークを 示す。 図６は、４つのホスト間で対話型アプリケーションを実現するのに必要な、本 発明のネットワーク上のペイロードの集成を行わないＵＬＰデータグラムを示す 。 図７は、４つのホスト間で対話型アプリケーションを実現するのに必要な、本 発明のネットワーク上のペイロードの集成を行わうＵＬＰデータグラムを示す。 図８は、マルチキャストサーバーを有する従来のＡＴＭネットワークを示す。 図９は、本発明のＵＬＰメッセージのための詳細なデータグラムフォーマット およびアドレスフォーマットを示す。 図１０は、本発明のＧＭＳの内部機能を示す。 図１１は、本発明のＵＬＰをサポートするのに必要なホストソフトウェアイン タフェースおよび機能を示す。 発明の詳細な説明 本発明は、多数のユーザ間で対話型アプリケーションを実現するために、多数 のホストコンピュータが広域ネットワークにわたって互いに効率的に情報を通信 する方法を提供する。この方法は３つの成分、ホストプロトコルインタフェース 、プロトコル、およびサーバーよりなる。プロトコルは、ホストプロトコルイン タフェースとサーバーとの間に位置し、広域ネットワークのネットワークトラン スポートプロトコルの上層に実現される。このプロトコルは、現存するネットワ ークトランスポートレベルプロトコル（ＴＬＰ）より上の層に位置するため上位 レベルプロトコル（ＵＬＰ）と呼ばれる。ＯＳＩ基準モデルでは、このプロトコ ルは、ネットワークのトランスポート層の上層のセッション層プロトコルとして 説明され得る。図１１は、対話型アプリケーション１５０およびトランスポート レベルプロトコルのためのホストインタフェース１５３に対するホストプロトコ ルインタフェース１５１を示す。ネットワークインタフェース１５５は、ホスト のネットワークへの物理的な接続を提供する。ネットワーク通信スタック１５４ は、ホストとトランスポートレベルプロトコル１５３のためのホストインタフェ ースとのためのネットワークトランスポートサービスを提供し、ホストアプリケ ーションソフトウェアとネットワーク通信スタックのネットワークトランスポー トサービスとの間のインタフェースである。 対話型アプリケーションは、ＴＬＰへのホストインタフェースを用いて従来の ネットワークメッセージを送信および受信することができる。対話型アプリケー ションはまた、ＵＬＰのためのホストインタフェースを通してＵＬＰメッセージ を送信および受信することができる。ＵＬＰのためのホストインタフェースの内 部にはテーブル１５２が配備され、ホストはそのすべてのＵＬＰアドレスにメッ セージを送ることができる。テーブルの各エントリは一対のアドレス、ＵＬＰア ドレスおよびその対応するＴＬＰアドレスを含む。ホストがメッセージをＵＬＰ アドレスに送ると、そのメッセージは、そのＵＬＰアドレスに対応するＴＬＰア ドレスに送られるＴＬＰメッセージに組み込まれる。これにより、ＵＬＰメッセ ージを現存するネットワークのトランスポートメカニズムによってトランスパレ ントに取り扱うことができる。ＵＬＰの中心的な機能は、ホストが多数のホスト が集合したメッセージグループにメッセージを送るグループ通信である。これに より、ホストは、１つのＵＬＰメッセージで多数のホストにメッセージを送るこ とができる。ＵＬＰはＴＬＰの上層に位置しているため、ＵＬＰのグループ通信 機能は、ＴＬＰメッセージを１つのホストから他の唯１つのホストにしか送るこ とができない従来のユニキャストネットワーク上で作動する。 グループベース通信は、グループ通信サーバーと呼ばれるサーバーを用いるこ とにより実現される。ホストからのすべてのＵＬＰメッセージは、ＴＬＰプロト コルを用いてホストからグループ通信サーバーに送られる。サーバーはメッセー ジのＵＬＰ部分を処理して、ＵＬＰメッセージによって必要とされる必要部分を 取り出す。コントロールＵＬＰメッセージがサーバーによって局所的に処理され 、送信ホストに受け取り通知が送付される。他のホストに向けられたＵＬＰメッ セージはグループ通信サーバーによって処理され、適切なＵＬＰ宛先ホストに再 伝送される。この場合も、ＴＬＰプロトコルを用いてこれらのメッセージの組み 込みおよびトランスポートが行われる。 図５では、ホスト５８、５９、６０、および６１は、グループ通信サーバー６ ２を用いて従来のユニキャストネットワークを通してＵＬＰを用いて互いにメッ セージを送る。ネットワークは、従来のネットワークリンク６９、７０、７１、 ７２、７３、７４、７５、７６、および７７と接続する従来のルーター６３、６ ４、６５、６６、６７、および６８より構成される。ホスト５８は、ＵＬＰメッ セージグループである宛先アドレスを特定している単一のＵＬＰメッセージをグ ループ通信サーバー６２に送ることによって、メッセージをホスト５９、６０、 および６１に送ることができる。ＵＬＰメッセージはグループ通信サーバーに向 けられるＴＬＰメッセージに組み込まれる。これにより、メッセージはルーター ６３によってネットワークリンク７１へ、次にルーター６７へ、さらにサーバー ６２へと適切に送られる。グループ通信サーバーはＵＬＰメッセージを受け取り 、このメッセージがホスト５９、６０、および６１をメンバーとして含むメッセ ージグループに向けれられたものであると決定する。サーバーは受け取ったメッ セージのペイロードをホストのそれぞれに、３つのホストに個別に送られる３つ の新しいＵＬＰメッセージとして送る。各メッセージはＴＬＰメッセージに組み 込まれているため、メッセージは従来のユニキャストネットワークを通して適切 に 送信される。第１のＵＬＰメッセージはグループ通信サーバーによってホスト６ １に送られる。このメッセージはネットワークリンク７１、７０、７２、および ７５、ならびにルーター６７、６３、６４、および６５によって運ばれる。第２ のＵＬＰメッセージはグループ通信サーバーによってホスト６０に送られる。こ のメッセージはネットワークリンク７１、７０、７３、および７６、ならびにル ーター６７、６３、６４、および６６によって運ばれる。第３のＵＬＰメッセー ジはグループ通信サーバーによってホスト６１に送られる。このメッセージはネ ットワークリンク７４および７７、ならびにルーター６７および６８によって運 ばれる。 本発明は、データグラム形態および接続志向形態の両方で実現され得る。本発 明の詳細を最良に理解するためには、先ずデータグラムでの実現について考慮す るのが最良である。 データグラムトランスポートによる実現化 ＵＬＰは、アドレス、メッセージタイプの情報、およびメッセージペイロード を、下層ネットワークトランスポートプロトコルのデータグラム内に組み込むこ とによって、データグラムプロトコルとして実現され得る。ＵＬＰデータグラム メッセージフォーマットの一般的な形態を図９に、要素１２３、１２４、１２５ 、１２６、１２７、１２８、および１２９として示す。トランスポートヘッダ１ ２３は、ＵＬＰデータグラムを組み込むＴＬＰのデータグラムヘッダである。Ｕ ＬＰメッセージタイプフィールド１２４は、送信メッセージであるか受信メッセ ージであるか、コントロールメッセージであるかステートメッセージであるかを 示す。下記の表はいくつかのメッセージタイプを示す。ＵＬＰメッセージタイプ フィールドはＵＬＰデータグラム内に存在しなければならない。 メッセージタイプ １ 送信 ２ 受信 ３ コントロール送信 ４ コントロール受信 ５ ステート送信 ６ ステート受信 送信メッセージは常にホストからグループ通信サーバーに送られる。グループ サーバーからホストへのメッセージは常に受信メッセージである。コントロール 送信メッセージは、ホストからグループ通信サーバーへのコントロール機能を実 行するように要求するメッセージである。コントロール受信メッセージは、先の コントロール送信メッセージに応答してグループ通信サーバーからホストへの受 け取り通知である。ステート送信および受信メッセージは、ホストがグループ通 信サーバー内に格納されたアプリケーション特異的ステートの読み出しおよび書 き込みを可能にする、コントロール送信および受信の特別な場合である。ＵＬＰ によってサポートされる特定のコントロール機能については後述する。 宛先ＵＬＰアドレス１２５はＵＬＰデータグラムで必要とされ、ＵＬＰメッセ ージの主要宛先を特定する。アドレスカウントフィールド１２６はＵＬＰ送信メ ッセージタイプで必要とされ、ＵＬＰ受信メッセージタイプには存在しない。Ｕ ＬＰ送信メッセージ内のアドレスカウントフィールドがゼロでないときは、これ はアドレスカウントフィールドに続く送信メッセージのための補助宛先アドレス の数を特定する。これらの補助宛先アドレスは項目１２７および１２８として示 されているが、アドレスカウントフィールドによって特定される分だけの補助Ｕ ＬＰ宛先アドレスが存在することは理解される。最後にペイロード１２９が続く 。 ＵＬＰデータグラムのためのペイロードフォーマットは、項目１１６、１１７ 、１１８、１１９、１２０、１２１、および１２２によって規定される。項目１ １６はメッセージカウントであり、ペイロード内に含まれるペイロード要素の数 を規定する。１つのペイロード要素は、発信元ＵＬＰアドレス、データ長、およ びデータの三つ組よりなる。項目１１７、１１８、および１１９がペイロードの 第１のペイロード要素を構成する。項目１１７は、ペイロード要素の発信元のＵ ＬＰアドレスであり、項目１１８はペイロード要素内のデータのデータ長であり 、項目１１９は実際のデータである。項目１２０、１２１、および１２２はペイ ロ ードの最後のペイロード要素を構成する。ＵＬＰ送信メッセージは、単一のペイ ロード要素を有するペイロードのみをサポートする。従って、メッセージカウン トは１に等しくなければならない。ＵＬＰ受信メッセージは１つ以上のペイロー ド要素を有するペイロードを有し得る。 ＵＬＰアドレススペース ＵＬＰのアドレススペースは３つのセグメント、すなわち、ユニキャストホス トアドレス、暗黙グループアドレス、および論理グループアドレスに分割される 。ＵＬＰのすべての発信元および宛先アドレスはこのアドレススペース内に存在 しなければならない。ＵＬＰアドレススペースは１つのグループ通信サーバーに 固有のものである。従って、各グループ通信サーバーは固有のＵＬＰアドレスス ペースを有する。各ＵＬＰデータグラムはＴＬＰのヘッダを含むため、多数のグ ループ通信サーバーがネットワークに接続され得、ホストは混乱なく多数のグル ープ通信サーバーと通信し得る。異なるグループ通信サーバーは、多数のＵＬＰ アドレススペースを固有に識別するためにホストによって使用され得る固有のＴ ＬＰアドレスを有し得る。ＵＬＰアドレスのためのフォーマットを図９に項目１ ３０、１３１、よび１３２で示す。アドレスフォーマットフィールド１３０は、 多数のアドレス長のサポートが可能なように使用される可変長フィールドである 。アドレスタイプフィールド１３１はＵＬＰアドレスのタイプ、すなわち、ユニ キャストホスト、暗黙グループ、または論理グループを示す。符号化は以下の通 りである。 アドレスタイプ符号化 ００ ユニキャストホストアドレス ０１ ユニキャストホストアドレス １０ 暗黙グループアドレス １１ 論理グループアドレス アドレスフォーマット符号化により、アドレスフィールドの長さ、従ってＵＬ Ｐアドレスの全長が決定される。この符号化について以下に示す。アドレスタイ プがユニキャストホストアドレスを特定するときは、アドレスタイプフィールド bの下位ビットはアドレスフィールドに連結され、アドレスの最重要ビットとな る。これにより、ユニキャストホストアドレスのためのアドレススペースのサイ ズが二倍になる。これは、通常ホストはグループ通信サーバーより多いため、有 用である。 アドレスフォーマット符号化 ０ ２９ビットアドレスフィールド １０ ４ビットアドレスフィールド １１０ １１ビットアドレスフィールド ＵＬＰユニキャストホストアドレスは、グループ通信サーバーに最初に接続す るとき各ホストに割り当てられる。ホストが他のＵＬＰアドレスにメッセージを 送るとき、ホストのユニキャストＵＬＰアドレスが受信したペイロード要素内の 発信元ＵＬＰアドレスとして現れる。ユニキャストＵＬＰホストアドレスはまた 、ＵＬＰ送信メッセージ内の補助アドレスとしてのみ宛先アドレスとして使用さ れ得る。これらは主要ＵＬＰ宛先アドレスとして使用することはできない。これ は、ホストはＵＬＰを直接互いに送ることはできず、常にグループ通信サーバー を通してメッセージを互いに送らなければならないことを意味する。 暗黙グループアドレスは、暗黙メッセージグループの作成を要求するグループ 通信サーバーへのコントロールメッセージに応答して、グループ通信サーバーに よって作成される。暗黙メッセージグループの作成を要求するホストは、これが 作成されるとそのメッセージグループのメンバーとなる。他のホストは、グルー プ通信サーバーへ問い合わせコントロールメッセージを送って、その存在を知り 、次にこのグループに参加するために暗黙グループ参加メッセージを送ることが できる。グループ通信サーバーは、暗黙メッセージグループのメンバーであるホ ストのＵＬＰアドレスリストを維持する。暗黙ＵＬＰグループアドレスのみが、 ＵＬＰ送信メッセージの主要宛先であることを許されるＵＬＰアドレスである。 暗 黙ＵＬＰアドレスは、ペイロード要素内のＵＬＰ発信元アドレスとして現れるこ とはない。 論理ＵＬＰアドレスは、論理メッセージグループに対して、およびＵＬＰ送信 メッセージ内の補助ＵＬＰアドレスのグループメンバー間の集合演算を特定する ための両方に用いられる。論理メッセージグループは、暗黙メッセージグループ と同様に、作成および参加が行われるが、論理ＵＬＰアドレスは、ＵＬＰ送信メ ッセージ内の補助ＵＬＰアドレスとしてのみ使用され得る。論理ＵＬＰアドレス もまた、ペイロード要素内の発信元ＵＬＰアドレスとして現れることはない。Ｕ ＬＰ送信メッセージの一部としてのメッセージグループ間の集合演算のサポート については、ＵＬＰ送信メッセージについての後のセクションで説明する。 グループ通信サーバーの内部機能 グループ通信サーバーの内部要素を図１０に示す。 好適な実施形態では、グループ通信サーバーは、広域ネットワークに接続させ るネットワークインタフェースを有する汎用コンピュータシステムである。項目 １３５はグループ通信サーバーのためのネットワークインタフェースであり、ネ ットワークへのハードウェア接続のみでなく、サーバーにＴＬＰを実現するため に使用される通信プロトコルスタックを含む。 項目１３６は、グループ通信サーバーのための全体的なコントロール機能であ る。このコントロール機能は、ＧＭＳによって送信または受信されるすべてのＵ ＬＰメッセージを受け持つ。このコントロール機能の内部には、いくつかの重要 な格納および処理機能が存在する。項目１３７は、ＧＭＳに現在接続しているす べてのホストのためのアドレスマップである。このアドレスマップは、ＧＭＳに 接続する各ホストのＵＬＰホストアドレスおよびこれに対応するＴＬＰアドレス のリストである。これにより、コントロール機能が、ＧＭＳに接続されたホスト にＵＬＰメッセージを送るために必要なＴＬＰヘッダを構築するのが可能となる 。項目１３８は、ＧＭＳによって現在認識されている現在アクティブな暗黙ＵＬ Ｐアドレスすべてのリストである。項目１３９は、アプリケーション特異的ステ ートの格納および処理機能である。ネットワークを通じて展開される多くの対話 型 アプリケーションが、ホストベースの処理のみによって実現され得る。このよう な場合には、ホスト間で送る必要のあるすべてのデータがＵＬＰを用いてトラン スポートされ得る。しかし、アプリケーションによっては、アプリケーションの ステート情報を中心に格納し維持し続ける必要があるものがある。これは、ホス トがダイナミックにアプリケーションへの参加または離脱を行うときには有用で ある。ホストがこのようなアプリケーションに参加するとき、既にアプリケーシ ョンのどこかの部分にいる他のホストと一致するために、アプリケーションの現 在のステートについての速写を得ることができる位置を必要とする。このステー ト格納領域の読み出しおよび書き込みを行うために、ＵＬＰはステート送信およ び受信メッセージタイプをサポートする。これらのメッセージ内には、ステート の異なる部分が個別にアクセスされ得るようにステートアドレススペースにアク セスする能力がある。このステート格納領域に書き込まれたアプリケーション特 異的なステート処理もまた実現され得る。 項目１４０および１４１は、ＧＭＳ上で走る多数のＵＬＰサーバープロセスの うちの２つである。これらは、ＵＬＰの心臓部に存在するソフトウェアプロセス である。ＧＭＳによって認識される各暗黙ＵＬＰアドレスは、ＵＬＰサーバープ ロセスおよびこのプロセスによって維持されるメッセージグループに１対１の対 応を有する。すべてのＵＬＰ送信メッセージは、メッセージの主要宛先アドレス として暗黙ＵＬＰアドレスを持たなくてはならないため、すべてのＵＬＰ送信メ ッセージはＵＬＰサーバープロセスに送られ、そこで処理される。これらのプロ セスは、ＵＬＰコントロールメッセージに応答してＧＭＳコントロール機能によ って作成され、新しい暗黙ＵＬＰアドレスを作成する。これらは、そのメッセー ジグループのメンバーである最後のホストがメッセージグループを離脱すると、 破壊される。ＵＬＰサーバープロセスの内部には、メッセージグループのメンバ ーのＵＬＰホストアドレスのリスト１４２、メッセージグループのメンバーであ る各ホストのためのメッセージキューセット１４３、および単一のホストへの多 数のメッセージを単一のメッセージへと集成するために使用されるメッセージ集 成機能１４９が存在する。 項目１４５は、ＧＭＳ内の論理ＵＬＰアドレスおよびメッセージグループすべ てのリストを維持する。項目１４４および１４６は、多数の論理ＵＬＰアドレス のうちの２つを表す。各論理ＵＬＰアドレスに対しては、論理メッセージグルー プのメンバーのホストＵＬＰアドレスの対応するリスト１４７および１４８が存 在する。論理メッセージグループは特定のＵＬＰサーバープロセスにつながって はおらず、ＵＬＰサーバープロセスのすべてに対してＧＭＳとグローバルの関係 にある。 コントロール機能 コントロール機能は、接続、切断、グループ作成、グループ閉鎖、グループ参 加、グループ問い合わせ、グループメンバー問い合わせ、グループ属性問い合わ せよりなる。これらのコントロール機能は、ＵＬＰコントロール送信および受信 メッセージによって実現される。コントロール機能は、ホストがＵＬＰコントロ ール送信メッセージをＧＭＳに送ることによって開始される。これらのメッセー ジは、メッセージ内に主要ＵＬＰ宛先アドレスのみを許可し、補助アドレスは許 可しない。主要ＵＬＰアドレスは、上述に列挙したコントロール機能のそれぞれ に割り当てられる固有の固定アドレスを有するコントロールアドレススペースと して解釈される。ペイロード内のデータの内容により、コントロール機能が必要 とする引数が供給される。コントロール機能からの戻り値は、データの戻しが行 われている最初のコントロールメッセージを送ったホストに向けられるＵＬＰコ ントロール受信メッセージで戻される。これらのコントロール機能の詳細な動作 については後述する。接続 このコントロール機能により、ホストはＧＭＳに接続することができる。メッ セージ内の宛先ＵＬＰアドレスが接続機能を示す固定アドレスである。ペイロー ド内の発信元ＵＬＰアドレスおよびすべてのデータが無視される。 このメッセージを受け取ると、ＧＭＳコントロール機能１３６は、新しいホス トアドレスを作成し、このホストアドレスを、メッセージのＴＬＰヘッダからの 発信元ＴＬＰアドレスと共に、ホストアドレスマップ１３６内に入れる。これが 成功裏に完了すると、ＧＭＳコントロール機能は、ホスト接続が成功したことを 示す、ペイロードのデータ部分内の機能コードと共に、コントロール受信ＵＬＰ メッセージをホストに送る。メッセージ内の宛先ＵＬＰアドレスは、ホストに割 り当てられたＵＬＰアドレスである。ホストはこれを保存して、将来ＧＭＳにメ ッセージを送るときに使用する。エラーが発生した場合は、コントロール機能は 、ホスト接続が失敗したことを示す、ペイロードのデータ部分内の機能コードと 共に、ホストにメッセージを戻す。切断 この機能により、ホストはＧＭＳからの切断が可能になる。メッセージ内の宛 先ＵＬＰアドレスが切断機能を示す固定アドレスである。発信元ＵＬＰアドレス は、切断を行う前にホストを暗黙または論理グループのメンバーシップから離脱 させるために使用される。ペイロード内のすべてのデータは無視される。ＧＭＳ コントロール機能はまた、ホストアドレスマップからホストのエントリを除去す る。成功裏に完了すると、ＧＭＳコントロール機能は、ホストの切断が成功した ことを示す、ペイロードのデータ部分内の機能コードと共に、コントロール受信 ＵＬＰメッセージをホストに送る。メッセージ内の宛先ＵＬＰアドレスは、ホス トに割り当てられたＵＬＰアドレスである。エラーが発生した場合は、コントロ ール機能は、ホスト切断が失敗したことを示す、ペイロードのデータ部分内の機 能コードと共に、ホストにメッセージを戻す。暗黙グループ作成 この機能により、ホストは新しい暗黙メッセージグループならびに関連する暗 黙ＵＬＰアドレスおよびサーバープロセスを作成することができる。メッセージ 内のペイロードは単一のペイロード項目を含み得、このデータフィールドがグル ープの属性を保持する。これらの属性はグループのいずれの選択的機能を規定す るためにも使用され得る。メッセージ内の宛先ＵＬＰアドレスが暗黙グループ作 成機能を示す固定アドレスである。ＧＭＳコントロール機能は新しい暗黙ＵＬＰ アドレスを割り当て、これを暗黙ＵＬＰアドレスリスト１３８に加え、新しいＵ ＬＰサーバープロセス１４０を作成する。このメッセージを送るホストは、暗黙 グループのメンバーシップリストに加えられる。これは、メッセージ内の発信元 ＵＬＰアドレスをＵＬＰサーバープロセス内のグループメンバーシップリスト１ ４２に加えることによって行われる。成功裏に完了すると、ＧＭＳコントロール 機能は、暗黙グループ作成が成功したことを示す、ペイロードのデータ部分内の 機能コードと共に、コントロール受信ＵＬＰメッセージをホストに送る。ペイロ ード内の発信元ＵＬＰアドレスは新しい暗黙グループに割り当てられたＵＬＰア ドレスである。エラーが発生した場合は、コントロール機能は、暗黙グループ作 成が失敗したことを示す、ペイロードのデータ部分内の機能コードと共に、ホス トにメッセージを戻す。論理グループ作成 この機能により、ホストは新しい論理メッセージグループおよび関連する論理 ＵＬＰアドレスを作成することができる。メッセージ内のペイロードは単一のペ イロード項目を含み得、このデータフィールドがグループの属性を保持する。こ れらの属性はグループのいずれの選択的機能を規定するためにも使用され得る。 メッセージ内の宛先ＵＬＰアドレスは、論理グループ作成機能を示す固定アドレ スである。ＧＭＳコントロール機能は新しい論理ＵＬＰアドレスを割り当て、こ れを論理ＵＬＰアドレスリスト１４５に加える。このメッセージを送るホストは 、論理グループのメンバーシップリストに加えられる。これは、メッセージ内の 発信元ＵＬＰアドレスを新しい論理メッセージグループ１４４のためのグループ メンバーシップリスト１４７に加えることによって行われる。成功裏に完了する と、ＧＭＳコントロール機能は、論理グループ作成が成功したことを示す、ペイ ロードのデータ部分内の機能コードと共に、コントロール受信ＵＬＰメッセージ をホストに送る。ペイロード内の発信元ＵＬＰアドレスは、新しい論理グループ に割り当てられたＵＬＰアドレスである。エラーが発生した場合は、コントロー ル機能は、論理グループ作成が失敗したことを示す、ペイロードのデータ部分内 の機能コードと共に、ホストにメッセージを戻す。グループ参加 この機能により、ホストは現存する論理または暗黙メッセージグループに参加 することができる。メッセージ内の宛先ＵＬＰアドレスがグループ参加機能を示 す固定アドレスである。ペイロードのデータ部分は、参加する予定のグループの ＵＬＰアドレスを含む。ＧＭＳコントロール機能はこのアドレスを調べて、これ bが暗黙ＵＬＰアドレスであるか論理ＵＬＰアドレスであるかどうかを決定する 。これが暗黙ＵＬＰアドレスである場合は、ＧＭＳコントロール機能は、メッセ ージペイロード内のアドレスによって選択されたＵＬＰサーバープロセスを見い 出して、メッセージからの発信元ＵＬＰホストアドレスをグループメンバーシッ プリスト１４２に加える。これが論理ＵＬＰアドレスである場合は、ＧＭＳコン トロール機能はメッセージペイロード内のアドレスによって選択された論理ＵＬ Ｐアドレス１４４を見い出して、メッセージからの発信元ＵＬＰホストアドレス をグループメンバーシップリスト１４７に加える。成功裏に完了すると、ＧＭＳ コントロール機能は、グループ参加が成功したことを示す、ペイロードのデータ 部分内の機能コードと共に、コントロール受信ＵＬＰメッセージをホストに送る 。ペイロード内の発信元ＵＬＰアドレスが参加したグループのＵＬＰアドレスで ある。エラーが発生した場合は、コントロール機能は、グループ作成が失敗した ことを示す、ペイロードのデータ部分内の機能コードと共に、ホストにメッセー ジを戻す。グループ離脱 この機能により、ホストはメンバーである現存する論理または暗黙メッセージ グループから離脱することができる。メッセージ内の宛先ＵＬＰアドレスがグル ープ離脱機能を示す固定アドレスである。ペイロードのデータ部分は、離脱する 予定のグループのＵＬＰアドレスを含む。ＧＭＳコントロール機能はこのアドレ スを調べて、これが暗黙ＵＬＰアドレスであるか論理ＵＬＰアドレスであるかど うかを決定する。これが暗黙ＵＬＰアドレスである場合は、ＧＭＳコントロール 機能は、メッセージペイロード内のアドレスによって選択されるＵＬＰサーバー プロセスを見い出して、メッセージからの発信元ＵＬＰホストアドレスをグルー プメンバーシップリスト１４２から除去する。このホストがグループの最後のメ ンバーである場合は、ＵＬＰサーバープロセスは終了し、この暗黙ＵＬＰアドレ スの割り当てが除去される。これが論理ＵＬＰアドレスである場合は、ＧＭＳコ ントロール機能はメッセージペイロード内のアドレスによって選択される論理Ｕ ＬＰアドレス１４４を見い出して、メッセージからの発信元ＵＬＰホストアドレ スをグループメンバーシップリスト１４７から除去する。ホストがグループの最 後のメンバーであれば、ＵＬＰアドレスは割り当てられない。成功裏に完了する と、ＧＭＳコントロール機能は、グループ離脱が成功したことを示す、ペイロー ドのデータ部分内の機能コードと共に、コントロール受信ＵＬＰメッセージをホ ストに送る。エラーが発生した場合は、コントロール機能は、グループ作成が失 敗したことを示す、ペイロードのデータ部分内の機能コードと共に、ホストにメ ッセージを戻す。グループ問い合わせ この機能により、ホストはＧＭＳ上で現在アクティブである暗黙または論理メ ッセージグループのリストを手に入れることができる。メッセージ内の宛先ＵＬ Ｐアドレスがグループ問い合わせ機能を示す固定アドレスである。ペイロードの すべてのデータ部分は無視される。成功裏に完了すると、ＧＭＳコントロール機 能は、多数のペイロード要素を有するペイロードと共に、コントロール受信ＵＬ Ｐメッセージをホストに送る。最初のペイロード要素はグループ問い合わせが成 功したことを示す機能コードを含む。最初のペイロード要素内の発信元ＵＬＰア ドレスは無視される。後に続くペイロード要素のそれぞれは、ＧＭＳ上のアクテ ィブなグループアドレスのうちの１つであるペイロード要素の発信元アドレスフ ィールド内のＵＬＰグループアドレスを含む。これら後に続くペイロード要素に はデータフィールドはない。エラーが発生した場合は、コントロール機能は、グ ループ問い合わせが失敗したことを示す、単一のペイロード要素を有するペイロ ードのデータ部分内の機能コードと共に、ホストにメッセージを戻す。グループメンバー問い合わせ この機能により、ホストはメッセージグループのメンバーであるすべてのホス トのリストを手に入れることができる。メッセージ内の宛先ＵＬＰアドレスがグ ループメンバー問い合わせ機能を示す固定アドレスである。ペイロードのデータ 部分が、問い合わせを行うメッセージグループのアドレスを有する。成功裏に完 了すると、ＧＭＳコントロール機能は、多数のペイロード要素を有するペイロー ドと共に、コントロール受信ＵＬＰメッセージをホストに送る。最初のペイロー ド要素はグループメンバー問い合わせが成功したことを示す機能コードを含む。 最初のペイロード要素内の発信元ＵＬＰアドレスは無視される。後に続くペイロ ード要素のそれぞれは、ＧＭＳ上のアクティブなグループアドレスのうちの１つ であるペイロード要素の発信元アドレスフィールド内のＵＬＰグループアドレス を含む。これら後に続くペイロード要素にはデータフィールドはない。エラーが 発生した場合は、コントロール機能は、グループメンバー問い合わせが失敗した ことを示す、単一のペイロード要素を有するペイロードのデータ部分内の機能コ ードと共に、ホストにメッセージを戻す。グループ属性問い合わせ この機能により、ホストはメッセージグループの属性のリストを手に入れるこ とができる。メッセージ内の宛先ＵＬＰアドレスがグループ属性問い合わせ機能 を示す固定アドレスである。ペイロードのデータ部分が、問い合わせを行うメッ セージグループのアドレスを有する。成功裏に完了すると、ＧＭＳコントロール 機能は、２つのペイロード要素を有するペイロードと共に、コントロール受信Ｕ ＬＰメッセージをホストに送る。最初のペイロード要素は、グループ属性問い合 わせが成功したことを示す機能コードを含む。第２のペイロード要素はメッセー ジグループの属性を含む。エラーが発生した場合は、コントロール機能は、グル ープ属性問い合わせが失敗したことを示す、単一のペイロード要素を有するペイ ロードのデータ部分内の機能コードと共に、ホストにメッセージを戻す。 送信メッセージ動作 送信メッセージ機能の動作を十分に理解するために、多くの個別のケースにつ いて考えるのは無駄ではない。単一の暗黙宛先 最も簡単なケースは、メッセージを単一の暗黙ＵＬＰアドレスに送ることであ る。すべての送信メッセージデータグラムでは、宛先ＵＬＰアドレス１２５は暗 黙ＵＬＰアドレスでなければならない。この単一の暗黙宛先のケースでは、これ がデータグラム内の唯一の宛先アドレスである。補助アドレスカウント１２６は ゼロであり、補助宛先アドレス１２７または１２８は存在しない。ペイロードは 、１であるメッセージカウント１１６、発信元ＵＬＰアドレス１１７内のメッセ ージを送るホストのＵＬＰ、データ長１１８、およびデータ１１９よりなる。送 信メッセージデータグラムは、１つのペイロード項目しか持たないため、メッセ ージカウントフィールド１１６は常に１でなければならない。 ホストは、データグラムをメッセージの選択された目標であるＧＭＳに向ける ＴＬＰヘッダと共に、送信メッセージをネットワークに送る。ＧＭＳはメッセー ジを受け取り、ＧＭＳコントロール機能１３６が、これは送信メッセージデータ グラムであると決定し、その暗黙ＵＬＰアドレスリスト１３８内の暗黙宛先アド レスを調べる。アドレスが存在しない場合は、ＵＬＰ受信メッセージデータグラ ムと共にエラーメッセージが送信ホストへ戻される。アドレスが有効である場合 は、ＧＭＳコントロール機能により、ＴＬＰヘッダがデータグラムから除去され 、ＵＬＰ部分を宛先暗黙ＵＬＰアドレスに対応するＵＬＰサーバープロセスに送 る。説明のために、これがＵＬＰサーバープロセス１４０であると仮定する。Ｕ ＬＰサーバープロセス１４０は、メッセージ１１７、１１８、および１１９から 単一のペイロード項目を取り出して、このペイロード項目をメッセージキュー１ ４３のそれぞれに配置する。ＵＬＰサーバープロセス１４０によって奉仕される メッセージグループの各メンバーに対して１つのメッセージキューが存在し得る 。グループの各メンバーは、ホストアドレスリスト１４２に列挙されているそれ ぞれのホストＵＬＰアドレスを有し得る。ＵＬＰサーバープロセス内の各メッセ ージキューは、特定の宛先ホストを目標とするペイロード項目で満たされ得る。 ペイロード項目がキューから取り出されホストに送られるメカニズムについては 後述する。補助ユニキャスト宛先 このケースでは、暗黙宛先１２５に加えて、データグラムには１つの補助アド レス１２７もまた存在する。補助アドレスカウント１２６は１であり、補助宛先 アドレス１２７はユニキャストホストＵＬＰアドレスである。ペイロードは、１ であるメッセージカウント１１６、発信元ＵＬＰアドレス１１７内のメッセージ を送るホストのＵＬＰ、データ長１１８、およびデータ１１９よりなる。 ホストは、データグラムをメッセージの選択された目標であるＧＭＳに向ける ＴＬＰヘッダと共に、送信メッセージをネットワーク上に送る。ＧＭＳはメッセ ージを受け取り、ＧＭＳコントロール機能１３６が、これは送信メッセージデー タグラムであると決定し、その暗黙ＵＬＰアドレスリスト１３８内の暗黙宛先ア ドレス、およびホストアドレスマップ１３７内のユニキャストホストＵＬＰ補助 アドレスを調べる。これらのアドレスのいずれも存在しない場合は、送信ホスト に、ＵＬＰ受信メッセージデータグラムと共にエラーメッセージが戻される。ア ドレスが有効である場合は、ＧＭＳコントロール機能により、ＴＬＰヘッダがデ ータグラムから除去され、ＵＬＰ部分が宛先暗黙ＵＬＰアドレスに対応するＵＬ Ｐサーバープロセスに送られる。説明のために、これがＵＬＰサーバープロセス １４０であると仮定する。ＵＬＰサーバープロセスは、メッセージから補助ＵＬ Ｐアドレスを取り出して、このアドレスからこれがユニキャストホストＵＬＰア ドレスであると決定する。サーバープロセスは次に、このアドレスがホストアド レスリスト１４２によって規定されるメッセージグループのメンバーであるかど うかを調べる。メンバーでない場合は、これ以上のアクションは行われず、メッ セージ内のペイロード項目はメッセージキュー１４３のいずれにも配置されない 。ホストアドレスがメッセージグループ内にある場合は、メッセージ内のペイロ ード項目は、そのホストに対応する単一のメッセージキュー内に配置される。こ の正味の効果は、ＵＬＰサーバープロセスが、暗黙ＵＬＰ宛先アドレスによって 選択されグループメンバーシップリスト１４２によって規定されたメッセージグ ループのメンバーに、補助アドレスによって規定されるホストセットのメンバー と共に、集合共通部分演算を行ったということである。次にペイロード項目は、 こ の集合共通部分のメンバーであるホストのみに送られる。補助論理宛先 このケースでは、暗黙宛先１２５に加えて、データグラムには１つの補助アド レス１２７もまた存在する。補助アドレスカウント１２６は１であり、補助宛先 アドレス１２７は論理ＵＬＰアドレスである。ペイロードは、１であるメッセー ジカウント１１６、発信元ＵＬＰアドレス１１７内のメッセージを送るホストの ＵＬＰ、データ長１１８、およびデータ１１９よりなる。 ホストは、データグラムをメッセージの選択された目標であるＧＭＳに向ける ＴＬＰヘッダと共に、送信メッセージをネットワーク上に送る。ＧＭＳはメッセ ージを受け取り、ＧＭＳコントロール機能１３６が、これは送信メッセージデー タグラムであると決定し、その暗黙ＵＬＰアドレスリスト１３８内の暗黙宛先ア ドレス、および論理ＵＬＰアドレスリスト１４５内の論理ＵＬＰ補助アドレスを 調べる。これらのアドレスのいずれも存在しない場合は、送信ホストに、ＵＬＰ 受信メッセージデータグラムと共にエラーメッセージが戻される。アドレスが有 効である場合は、ＧＭＳコントロール機能により、ＴＬＰヘッダがデータグラム から除去され、ＵＬＰ部分が宛先暗黙ＵＬＰアドレスに対応するＵＬＰサーバー プロセスに送られる。説明のために、これがＵＬＰサーバープロセス１４０であ ると仮定する。ＵＬＰサーバープロセスは、メッセージから補助ＵＬＰアドレス を取り出して、このアドレスからこれが論理ＵＬＰアドレスであると決定する。 この例では、この論理ＵＬＰアドレスが論理アドレス１４４であると仮定する。 サーバープロセスは、論理アドレスに対応するグループメンバーシップリスト１ ４７を調べて、サーバープロセスのグループメンバーシップリスト１４２との集 合共通部分演算を行う。この集合共通部分にメンバーが存在しない場合は、これ 以上のアクションは行われず、メッセージ内のペイロード項目はメッセージキュ ー１４３のいずれにも配置されない。集合共通部分演算のメンバーが存在する場 合は、メッセージ内のペイロード項目は、集合共通部分のメンバーであるホスト に対応するキューに配置される。論理演算を伴う多数の補助アドレス 最も高度な形態では、送信メッセージは、ＵＬＰサーバープロセスの暗黙メッ セージグループと多数の論理およびユニキャストＵＬＰアドレスとの間で集合演 算を行うことができる。これは、メッセージ内の多数の補助宛先ＵＬＰアドレス を、アドレスリストに埋め込まれた論理演算子と共に配置することによって行わ れる。アドレスカウント１２６は、アドレスリスト１２７および１２８内のすべ ての補助アドレスのカウントを保持する。補助アドレスは、論理ＵＬＰアドレス とユニキャストホストＵＬＰアドレスの混合である。ＵＬＰアドレススペース内 の２つの論理ＵＬＰアドレスが、論理メッセージグループとメッセージリスト内 のユニキャストホストアドレスとの間で行われる集合演算を特定化する役割を割 り当てられる。これらは、機能である集合共通部分、和集合のために特に割り当 てられたアドレスである。集合の補完体を示すためには、第３の論理アドレスが 用いられる。ペイロードは、１であるメッセージカウント１１６、発信元ＵＬＰ アドレス１１７内のメッセージを送るホストのＵＬＰ、データ長１１８、および データ１１９よりなる。 ホストは、データグラムをメッセージの選択された目標であるＧＭＳに向ける ＴＬＰヘッダと共に、送信メッセージをネットワーク上に送る。ＧＭＳはメッセ ージを受け取り、ＧＭＳコントロール機能１３６が、これは送信メッセージデー タグラムであると決定し、暗黙ＵＬＰアドレスリスト１３８内の暗黙ＵＬＰメッ セージ、およびホストＵＬＰアドレスマップ１３７かまたは論理ＵＬＰアドレス リスト１４５のいずれかの適切な方のアドレスリスト内のすべてのアドレスを調 べる。いずれのアドレスも存在しない場合は、ＵＬＰ受信メッセージデータグラ ムと共に、エラーメッセージが送信ホストに戻される。アドレスが有効である場 合は、ＧＭＳコントロール機能により、ＴＬＰヘッダがデータグラムから除去さ れ、ＵＬＰ部分を宛先暗黙ＵＬＰアドレスに対応するＵＬＰサーバープロセスに b送る。説明のために、これがＵＬＰサーバープロセス１４０であると仮定する 。ＵＬＰサーバープロセスは、メッセージから補助ＵＬＰアドレスを取り出して 、これを始めから終わりまで走査する。集合演算子の走査および処理はポストフ ィックス方式で行われる。これは、引数が読み出され、続いて演算子が読み出さ れ、 これが次に引数に適用されることを意味する。演算子の結果は次の演算の最初の 引数になる。従って、走査の開始時には２つのアドレスがアドレスリストから読 み出される。次のアドレスはこれらの引数に適用される演算子であり、この演算 子の結果が、次の演算子によって使用される最初の引数である。これ以降は、１ つのアドレスがアドレスリストから読み出され、続いて論理ＵＬＰアドレスが読 み出され、これは新しい引数と最後の演算子の結果とからなる２つの引数におけ る演算子である。集合補完を示すために用いられる論理アドレスは集合演算子で はなく、引数限定子である。何故なら、これはアドレスリスト内のいかなるアド レスにも先行し得るからである。集合補完引数限定子の意味は、送信メッセージ 内の暗黙グループアドレスのグループメンバーシップに関連する。集合補完限定 子が、送信メッセージ内の暗黙ＵＬＰアドレスによって選択されるメッセージグ ループのメンバーではないユニキャストホストアドレスに先行する場合は、有効 引数は、暗黙メッセージグループのメンバーであるすべてのホストの集合である 。集合補完限定子が、送信メッセージ内の暗黙ＵＬＰアドレスによって選択され るメッセージグループのメンバーであるユニキャストホストアドレスに先行する 場合は、有効引数は、補完関数によって限定されるオリジナルのユニキャストホ ストアドレス以外の暗黙メッセージグループのメンバーであるすべてのホストの 集合である。集合補完限定子が論理ＵＬＰアドレスに先行する場合は、有効引数 は、集合補完限定子によって先行される論理メッセージグループのメンバーであ るホスト以外の、送信メッセージによって特定される暗黙メッセージグループの メンバーであるすべてのホストの集合である。アドレスリスト全体がホストの単 一の結果集合となるように処理されると、この集合、および送信メッセージ内の 暗黙アドレスによって規定される暗黙メッセージグループ１４２のメンバーの集 合について集合共通部分演算が行われる。この集合共通部分にメンバーが存在し ない場合は、もはやアクションは行われず、メッセージ内のペイロード項目はメ ッセージキュー１４３のいずれにも配置されない。集合共通部分演算のメンバー が存在する場合は、メッセージ内のペイロード項目は、集合共通部分のメンバー であるホストに対応するキューに配置される。 メッセージ送達および集成 メッセージがＵＬＰサーバープロセス内のメッセージキューに入れられると、 これらが最終的に目標ホストに送達され得るには様々な方法がある。本発明では 、送達方法は、暗黙ＵＬＰメッセージグループおよびサーバープロセスが作成さ れるときに提供される属性によってＵＬＰサーバープロセス毎に設定される。こ れらの方法についての記述においては、本発明は、ネットワーク化された対話型 アプリケーションを実現中はホストグループが互いに高速でメッセージを送る効 率的な手段を提供するように意図されていることを念頭に置くことが重要である 。また、以下の記述においては、ＧＭＳは、ホストが自らの属するグループにメ ッセージを送るときエコー抑制を行うものと仮定する。このことは、ホストはグ ループへのそれ自体のメッセージのコピーを、単一の非集成メッセージとしても 集成メッセージ内のペイロード項目としても受け取らないことを意味する。これ は、ＵＬＰサーバープロセスの属性によって制御され、エコー抑制を停止するよ うに変更され得るが、エコー抑制がデフォルトである。即時送達 最も簡単な送達方法は、ペイロード項目がメッセージキュー内に置かれると直 ちにそれらの目標ホストに即時送達することである。メッセージキュー内の各ペ イロード項目は、ＵＬＰ発信元アドレス、データ長、および送付されるデータを 含み得る。即時送達を実現するためには、ＵＬＰサーバープロセスは、特定のホ スト１４３のためのメッセージキューからペイロード項目を取り出す。このホス トのためのホストアドレスは、グループメンバーシップリスト１４２から得られ 得る。ペイロード項目および宛先ホストアドレスがＧＭＳコントロール機能１３ ６に送られ、そこで宛先ホストに送られるＵＬＰ受信メッセージを作成するため に用いられる。ＧＭＳコントロール機能１３６は宛先ＵＬＰホストアドレスを用 いて、ホストアドレスマップ１３７からホストのＴＬＰアドレスを調べる。これ は、メッセージのためのＴＬＰヘッダ１２３を作成するために用いられ得る。Ｕ ＬＰメッセージタイプ１２４はＵＬＰ受信であり、宛先ＵＬＰアドレス１２５は 宛先ホストであり、アドレスカウントはで０であり、補助アドレスは存在しない 。 このケースでのペイロードは、１であるメッセージカウント１１６を有し、フィ ールド１１７、１１８、および１１９よりなるペイロード項目がメッセージキュ ーから取り出されるペイロード要素となる。 即時送達は、ホストグループ間のメッセージレートが低いとき有用である。グ ループの各メンバーが固定レートでグループの他のメンバーすべてにメッセージ を送る、暗黙メッセージグループのメンバーである４つのホストについて考える 。即時送達では、各ホストは固定レートでグループの他のメンバーに３つのメッ セージを送り、またグループの他のメンバーから３つのメッセージを受け取る。 これは、グループのサイズが小さくメッセージレートが低い場合は受容可能であ る。しかし、全メッセージレートは、基本メッセージレートとグループの全メン バー数マイナス１との積であることは明らかである。このことから、大きなグル ープおよび対話度の高いメッセージレートに対してはメッセージレートが受容範 囲を超えて高くなり過ぎることは明らかである。毎秒１０個のメッセージという 基本メッセージレートを有する２０のメンバーよりなるグループでは、各ホスト におおいて毎秒１９０個のメッセージの送信および１９０個のメッセージの受信 という全メッセージレートが得られる。このメッセージレートは、インターネッ トなどの従来の広域ネットワークへの従来のダイアルアップ接続ではサポート不 能となり得る。集成 本発明の中心的な概念は、メッセージキュー内の多数のメッセージを、ペイロ ード内に多数のペイロード項目を含むホストへの単一のＵＬＰ受信メッセージへ と集成することである。ＵＬＰサーバープロセス１４０はホストのためのメッセ ージキュー１４３からペイロード項目を取り出し、これらを集成バッファ１４９ 内に蓄積する。集成バッファは、メッセージキューを有する各ホストのためのバ ッファ領域を有する。集成バッファ内のこれらの個別のホスト領域は、ホスト集 成バッファと呼ばれる。この集成期間の開始および終了は、次のセクションで述 べる多くの方法で制御され得る。集成期間の終了時には、各ホスト集成バッファ は、多数のペイロード項目を保持し得る。ホスト集成バッファは、ペイロード項 目のメッセージカウントを保持し、これに多数のペイロード項目が続く。ホスト 集成バッファの内容は、対応するホストのＵＬＰホストアドレスと共に、ＧＭＳ コントロール機能１３６に送られ、ここで、宛先ホストに送られるＵＬＰ受信メ ッセージを作成するために使用される。ＧＭＳコントロール機能１３６は、宛先 ＵＬＰホストアドレスを用いて、ホストアドレスマップ１３７からホストのＴＬ Ｐアドレスを調べる。これは、メッセージのためのＴＬＰヘッダ１２３を作成す るために使用され得る。ＵＬＰメッセージタイプ１２４はＵＬＰ受信であり、宛 先ＵＬＰアドレス１２５は宛先ホストであり、アドレスカウントは０であり、補 助アドレスは存在しない。このケースでのペイロードは、メッセージカウント１ １６をホスト集成バッファからのメッセージカウント値によって設定する。ペイ ロードは、ホスト集成バッファからのペイロード項目すべてを含み得る。 集成の効果は、ホストによって受け取られる全メッセージレートを大幅に低減 させ得ることである。ホストへの単一のメッセージが、集成期間中に他のホスト から受信される多数のペイロード項目を運ぶことが可能となり得る。これは、ホ ストグループが定期的なレートでグループ内の他のホストすべてにメッセージを 送っている本発明の対話型アプリケーションに非常に良好に適合する。集成は、 他のホストすべてからのメッセージすべてをグループの各メンバーのための単一 のメッセージへとまとめるのに非常に効果的であり得る。これにより、多くの個 別のメッセージではなく単一のメッセージを受け取るため、各受信ホストでの処 理が低減する。また、集成は各ペイロード項目のために個別のメッセージヘッダ を設ける必要をなくすため、ホストへの全データレートを低減させ得る。多数の ペイロード項目に対してフィールド１２３、１２４、および１２５よりなる唯１ つのメッセージヘッダしか存在しないため、小さなペイロード項目にとってはこ の節約は重要である。ホストグループが定期的なレートでグループにメッセージ を送る場合、多くの対話型アプリケーションでは、各ホストがグループに送るデ ータが他のホストが送るメッセージに非常に類似していることが多い。このため 、多数のペイロード項目が集成されたペイロード内で、ペイロード要素の多数の データ要素にわたってデータ圧縮方法を適用する機会が与えられる。これには様 々な既知のデータ圧縮方法が適用され得る。最初のペイロード項目内の最初のデ ー タ要素は非圧縮形態で送られ、これに続く各データ要素は、ある形態の差異符号 化方法を用いて圧縮される。様々な既知のデータ圧縮方法が、符号化される予測 値からの差異を有する予測子の概念を用いる。集成されたペイロード内の最初の データ要素がこの予測子として用いられ得、これに続くデータ要素はこのような データ圧縮方法を用いて符号化される。これらの従来のデータ圧縮方法は、圧縮 するデータ要素の一部の内部構造または機能についてのいかなる知識も仮定しな い。符号化の効率性を暗黙的にもっと高くするために、このような知識を利用す るアプリケーション特異的符号化方法を用いることも可能である。サーバー等時 集成期間を規定し得る１つの方法として、サーバー等時またはＳＩと呼ばれる ものがある。この方法では、ＵＬＰサーバープロセスが、集成期間を規定するた めの均一時間ベースを規定する。この時間ベースは３つのパラメータ、すなわち 期間、集成オフセット、および伝送オフセット、によって規定される。これらの パラメータは、暗黙グループおよびＵＬＰサーバープロセスが作成されるとき、 暗黙グループ作成コントロール機能に提供される属性によって設定される。期間 は、固定時間間隔であり、この間に、ＵＬＰサーバープロセスがメッセージキュ ー内にメッセージを蓄積し、キュー内のメッセージを集成し、そして集成された メッセージを目標ホストに送る。集成オフセットは、期間の開始後のある時点を 規定する。期間の開始後は、到着メッセージは次の期間での送達のためにメッセ ージキュー内に格納される。従って、期間開始後の集成オフセットでは、各メッ セージキュー内のすべてのメッセージの速写が得られる。新しいメッセージが続 いて到着し集成オフセット後のキューに入れられる。集成オフセット時点より前 のキュー内のメッセージのみが発信メッセージへと集成されることになる。得ら れる集成メッセージは次に、期間の開始後の伝送オフセットである時点で、それ らの目標ホストに送られ得る。この結果、メッセージは連続して到着しメッセー ジキューに格納される。各期間に１回、メッセージは、メッセージの目標である 各ホストへの単一のメッセージへと集成され、各期間に１回、これらの集成メッ セージはホストに送られる。 ＳＩ方法の別の実施形態として、ＵＬＰサーバープロセスは、受信メッセージ レートおよび／または受信データレートなどのある基準に基づいて期間をダイナ ミックに変動させ得る。ＵＬＰサーバーは、毎秒受信されるメッセージ数または 毎秒受信されるペイロードバイト全数に基づいて集成期間を規定する機能を用い 得る。１つの妥当な機能としては、受信メッセージのレートまたは受信ペイロー ドのデータレートが増大するに従って集成期間を短くすることがある。これによ り、受信メッセージおよび／または受信データレートが増大するに従って発信メ ッセージのサイズが大きくなり過ぎないようにされる。受信メッセージレート、 受信ペイロードデータレート、またはＵＬＰサーバープロセスが利用可能な他の パラメータに基づいて集成期間を変動させる他の他の可能な機能も用いられ得る 。ホスト同期 集成期間を規定するホスト同期またはＨＳ方法は、ホストによって制御される 柔軟な期間を規定することが可能である。これは、ホストがＨＳモードで動作し ている暗黙メッセージグループの１つ以上のメンバーにメッセージを送る順番の 概念に基づく。メッセージグループ内のすべてのホストが順番を終えると、集成 期間は終了する。メッセージキューの内容の速写が得られ、各キューの内容が集 成され、集成されたメッセージが各メッセージキューによって目標ホストに送ら れる。この方法の改良によれば、グループへの３つのＵＬＰ送信メッセージタイ プ、すなわちグループの暗黙アドレスのみへの送信、グループ内のユニキャスト ホストアドレスへの送信、およびメンバーをグループと共有する論理ＵＬＰアド レスへの送信、のうちのいずれがホストの順番を構成するかを限定する。グルー プの属性は、ＨＳ集成を規定するのみでなく、ホストの順番であると見なされ得 る１つ以上のＵＬＰ送信メッセージタイプも規定する。さらなる改良によれば、 単一の集成期間内でホストに回ってくる順番の全回数を設定する。デフォルトは １回であるが、多数回でも許可され得る。ホストが許可されている回数を超えて 順番を取ろうとすると、メッセージは無視される。 この集成方法は、ＨＳ暗黙メッセージグループのメンバーであるホスト同志が 、同じ対話型アプリケーションを実行しているとき同期化される処理機能を有す る というさらなる利点を持つ。多くのネットワーク化された対話型アプリケーショ ンは、簡単で包括的な３段階動作モデル、すなわち、他のホストからのメッセー ジを待つ、メッセージおよびローカルユーザの入力を処理してローカルアプリケ ーションを更新する、メッセージを他のホストに送るというモデルに基づく。こ の基本的なアプリケーションループは、毎秒５〜３０回などの対話回数を提供す るのに十分な速さのレートで繰り返される。アプリケーションのステートが異な るホストマシーン間で一致するように、このようなアプリケーションを同期状態 に保つことが望ましい。このようなアプリケーションが本発明のＨＳモデルを用 いて通信するとき、これらの動作は自然に同期化される。ＨＳによるＵＬＰサー バープロセスは、メッセージグループのすべてのメンバーがそれそれの順番を終 え、グループにメッセージを送るまで待ち、その後グループのメンバーに集成メ ッセージを送る。これにより、ホスト上のアプリケーションは、集成メッセージ を受け取るまで待つことになる。この後で、各アプリケーションはこれらのメッ セージならびにローカルユーザの入力の処理を開始する。各アプリケーションが それぞれの処理を異なる速度で行い、次のメッセージをグループに異なる時間に 送る場合でも、ＨＳによるＵＬＰサーバーは、すべてがそれぞれの処理を完了し メッセージをグループに報告するまで待つ。これにより、すべてのホストが他の すべてと同じアプリケーションループ反復位置にあるように、すべてのホストア プリケーションが同期化された状態で保たれる。これにより、アプリケーション ステートがすべてのホストで一致した状態に保たれる。ＧＭＳからホストへのネ ットワーク伝播遅延およびホスト間での処理速度の違いによってのみ、それぞれ の処理の開始および終了が異なる時間に始まる結果となり得る。すべてのホスト を正確に同期化状態に保つことはネットワーク化されたアプリケーションでは必 要条件ではない。アプリケーションステートが一致していることのみが必要であ る。ＨＳ方法は、本発明の環境においてこれを行う自然の方法を提供する。 好適な実施形態 本発明の詳細な記述では、本発明を説明する最良の方法として、本発明のデー タグラムの実現について述べた。本発明の好適な実施形態について以下に述べる 。 この好適な実施形態では、広域ネットワークはインターネットであり、ＴＬＰ プロトコルはＴＣＰ／ＩＰである。ＧＭＳは、インターネットに接続された汎用 コンピュータシステムであり、ホストはインターネットに接続されたパーソナル コンピュータである。 ＴＣＰ／ＩＰは、ホスト１５１上にもっと効率的なアプリケーションインタフ ェースを提供する多くの利点を与える。ＴＣＰ／ＩＰは、そのヘッダ内の発信元 および宛先ポート番号の概念をサポートする。ＵＬＰは、発信元および宛先ＵＬ Ｐ接続を識別するポート番号を利用し得る。ほとんどのＵＬＰ送信メッセージは ホストから暗黙ＵＬＰグループアドレスへのものであり、ほとんどのＵＬＰ受信 メッセージは暗黙ＵＬＰアドレスからＵＬＰホストアドレスへのものである。こ れらおよびＵＬＰメッセージタイプフィールドのすべては、ＴＣＰ／ＩＰヘッダ 内の発信元および宛先ポートアドレスによって表され得る。これは、ほとんどの ＵＬＰメッセージにとって、ＴＣＰ／ＩＰメッセージ内に組み込まれたＵＬＰメ ッセージはペイロードを含むだけでよいことを意味する。ＵＬＰサーバープロセ スからホストに送られる集成ＵＬＰ受信メッセージは僅かに複雑になる。ここで は、宛先ポートはホストであり、発信元ポートは暗黙ＵＬＰグループアドレスで あり、ペイロードは各ペイロード項目内に発信元ホストＵＬＰアドレスを依然と して含んでいる。 ＴＣＰ／ＩＰはまた、低速ダイアルアップラインに対するヘッダ圧縮をサポー トし、これもまたこのアプリケーションでは重要である。ＲＦＣ１４４を参照。 ＴＣＰ／ＩＰは、信頼できる端部−端部接続のトランスポートを提供する接続志 向型プロトコルである。これは、エラーの再伝送ならびにデータの上位レベルプ ロトコルへのトランスパレントな断片化および再構築を扱う。ヘッダ圧縮により 、ＴＣＰ／ＩＰヘッダの多くを各パケットと共に省略し、小さな接続識別子に置 き換えることが可能である。この接続ＩＤは発信元および宛先ＩＰアドレスなら びに発信元および宛先ＴＣＰ／ＩＰポート番号よりなる接続を固有に規定し得る 。 ホスト上のアプリケーションへのインタフェースでは、この好適な実施形態で のＵＬＰはセッション層プロトコルとして働く。この好適な実施形態では、ホス ト上のアプリケーションはＵＬＰサーバープロセスによりセッションを開く。こ のセッションはホスト上の固有のセッションＩＤにより識別される。ホストアプ リケーションは次にデータを、このセッションＩＤの標識の付いたＵＬＰホスト インタフェース１５１に送る。セッションＩＤは、暗黙ＵＬＰアドレスのための 特定のＵＬＰサーバープロセスを走らせるＧＭＳサーバーのＴＣＰ／ＩＰ ＴＬ Ｐアドレスを含む、ホストおよび暗黙ＵＬＰペアを規定する。ＵＬＰサーバープ ロセスのＧＭＳのトランスポートアドレスをセッションＩＤに結びつけることに よって、ネットワーク上の多数のグループ通信サーバーをアプリケーシヨンにと ってトランスパレントな方法でサポートすることができ、単一のホストが、異な る物理的なグループ通信サーバーを有する多数のアクティブなセッションを持つ ことができる。これにより、ＵＬＰアドレススペースが各ＧＭＳに固有であると いう事実から生じ得るアドレススペースの衝突問題が回避される。 別の実施形態 本発明の１つの可能な拡張は、ＧＭＳおよびこれに接続するホストの共通の同 期化時間ベースをサポートするようにＵＬＰを拡張することである。これはＳＩ メッセージ集成モード環境において最も興味深いものである。ＧＭＳのＳＩ時間 ベースはすべてのホスト上で複製され得、またすべてのホストおよびＧＭＳはま とめてこれらの時間ベースをロックし得る。多数のコンピュータシステムで時間 ベースを同期化する方法は既に存在する。このような方法の１つはＮＴＰと呼ば れる。 本発明の別の拡張は、受信されるメッセージの内容に特定のアプリケーション 特異的な処理を行うＵＬＰサーバープロセスを規定することである。様々な異な るアプリケーション特異的処理機能が規定および実現され得る。１つの特定の機 能は、暗黙グループ作成機能で提供される属性によって選択され得る。これらの 機能はメッセージペイロード内のデータを処理し、ペイロード内のデータ要素を 処理結果に置き換えることができる。個別に、またはメッセージペイロードの処 理と組み合わせて、処理は裸のメッセージペイロードデータをアプリケーション 特異的ステート格納領域に格納し得るか、または処理結果を格納し得る。 ホストシステムはパーソナルコンピュータである必要はなく、専用ゲームコン ソール、テレビのトップボックス、またはＵＬＰプロトコルを実現し得るプログ ラム可能コントローラを有する他の装置であり得ることは明らかである。 ＵＬＰプロトコルをトランスポートするために使用される広域ネットワークは インターネットである必要はなく、またＩＰに基づく必要はない。ＡＴＭネット ワークまたはデジタルケーブルテレビジョンネットワークを含む、広域パケット またはデータグラムトランスポートのための手段を有する他のネットワークでも 可能である。 上記の本発明の十分な説明により、本明細書で述べた本発明の精神または範囲 から外れることなく、本発明に変更および改変がなされ得ることは、当業者にと っては明らかである。従って、本発明は添付の請求の範囲によってのみ限定され るものとする。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ， ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，Ｇ Ｅ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ， ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者 ウィアトコウスキー，マーク ピーター アメリカ合衆国 カリフォルニア 95030, ロス ガトス，マッソル アベニュー ナ ンバー108 347 (72)発明者 ロスチャイルド，ジェフリー ジャッキエ ル アメリカ合衆国 カリフォルニア 95030, ロス ガトス，オールド ランチ ロード 15560 【要約の続き】 地ホストに送る。対話型アプリケーションでは、多くの メッセージは時間的に互いに接近してグループサーバー に到着する。単に各メッセージを目的地ホストに送るの ではなく、グループ通信サーバーは、特定の期間中に受 け取られた各メッセージの内容を集成して、集成メッセ ージを目的地ホストに送る。この方法は、ネットワーク 化された対話型アプリケーション内のホスト間のメッセ ージ通信量を減らし、またホスト間の通信での待ち時間 の減少に貢献する。

Claims (1)

1. 【特許請求の範囲】 １．ユニキャスト広域通信ネットワークを通して接続される複数のホストコンピ ュータにメッセージを提供する方法であって、該複数のホストコンピュータは、 複数のネットワークアドレスに関連付けられている方法において、 該ネットワークに連結するサーバーを提供するステップであって、該サーバー は該ユニキャストネットワークを用いて該複数のホストコンピュータのそれぞれ と通信し、該サーバーは上位レベルプロトコルアドレスのリストと該ホストコン ピュータに関連付けられた該ネットワークアドレスのリストとを維持する、ステ ップと、 該サーバーが、該上位レベルプロトコルアドレスリスト内の第１の上位レベル プロトコルアドレスと、該ネットワークアドレスリスト内の第１のネットワーク アドレスセットとの間に第１のアドレスマッピングを形成するステップと、 該第１のネットワークアドレスセットのうちの１つに関連付けられた第１のホ ストコンピュータが、メッセージを該サーバーに該ユニキャストネットワークを 介して送るステップであって、該メッセージはペイロード部分と識別部分とを含 み、該識別部分は該第１の上位レベルプロトコルアドレスを含む、ステップと、 該サーバーが、該ユニキャストネットワークを介して該ペイロード部分を、該 第１のネットワークアドレスセットに関連付けられた選択されたホストコンピュ ータに伝送するステップと、 を包含する方法、 ２．前記選択されたホストコンピュータは、前記第１のホストコンピュータ以外 の、前記第１のネットワークアドレスセットに関連付けられたすべてのホストコ ンピュータよりなる、請求項１に記載の方法。 ３．前記ホストコンピュータに関連付けられた前記リスト化されたネットワーク アドレスは、インターネットプロトコルアドレスである、請求項１に記載の方法 。 ４．前記サーバによって受け取られるコントロールメッセージに応答して該サー バーが、前記上位レベルプロトコルアドレスリストのうちの第２の上位レベルプ ロトコルアドレスと少なくとも第１にリストされたネットワークアドレスとの間 に第２のアドレスマッピングを作成するステップであって、該コントロールメッ セージは、該第１にリストされたネットワークアドレスに関連付けられたホスト コンピュータから前記ネットワークを介して送られる、ステップをさらに包含す る、請求項１に記載の方法。 ５．前記サーバによって受け取られる第２のコントロールメッセージに応答して 該サーバーが、別のリストされたネットワークアドレスを前記第２のアドレスマ ッピングに加えるステップであって、該別のリストされたネットワークアドレス は、前記複数のホストコンピュータ内の別のホストコンピュータに関連付けられ 、該第２のコントロールメッセージは該別のホストコンピュータから送られる、 ステップをさらに包含する、請求項４に記載の方法。 ６．前記ネットワークは少なくとも１つのインターネットプロトコルを用い、前 記サーバーは、セッション層プロトコルを用いて前記複数のホストコンピュータ と通信する、請求項１に記載の方法。 ７．ユニキャスト広域通信ネットワークを通して接続される複数のホストコンピ ュータにグループメッセージを提供する方法であって、 該ネットワークに連結するグループ通信サーバーを提供するステップであって 、該サーバーは該ユニキャストネットワークを用いて該複数のホストコンピュー タと通信し、またメッセージグループのリストを維持し、各メッセージグループ は少なくとも１つのホストコンピュータを含む、ステップと、 第１のメッセージグループに属する複数のホストコンピュータが、メッセージ を該サーバーに該ユニキャストネットワークを介して送るステップであって、該 メッセージはペイロード部分と該第１のメッセージグループを識別する部分とを 含む、ステップと、 該サーバーが、所定の基準に従って決定された時間間隔内で、該メッセージの 該ペイロード部分を集成して、集成ペイロードを作成するステップと、 該集成ぺイロードを用いて集成メッセージを形成するステップと、 該サーバが、該ユニキャストネットワークを介して該集成メッセージを、該第 １のメッセージグループに属する受信ホストコンピュータに伝送するステップと 、 を包含する方法。 ８．前記時間間隔は固定期間である、請求項７に記載の方法。 ９．前記時間間隔は、前記サーバーが、前記第１のメッセージグループに属する 各ホストコンピュータから少なくとも１つのメッセージを受け取る時間に対応す る、請求項７に記載の方法。 １０．前記複数のホストコンピュータのうちの１つが、第１のコントロールメッ セージを前記サーバーに前記ユニキャストネットワークを介して送ることによっ て、前記第１のメッセージグループを作成するステップをさらに包含する請求項 ７に記載の方法。 １１．前記複数のホストコンピュータのいずれかが、前記第１のメッセージグル ープを特定するコントロールメッセージを前記ユニキャストネットワークを介し て前記サーバに送ることによって、該第１のメッセージグループに参加するステ ップをさらに包含する、請求項１０に記載の方法。 １２．前記ネットワークはインターネットであり、前記サーバーは、セッション 層プロトコルを用いて前記複数のホストコンピュータと通信する、請求項７に記 載の方法。 １３．ユニキャスト広域通信ネットワークを通して接続される複数のホストコン ピュータにメッセージを提供する方法であって、該複数のホストコンピュータは 、 複数のネットワークアドレスに関連付けられている方法において、 該ネットワークに連結するサーバーを提供するステップであって、該サーバー は該ユニキャストネットワークを用いて該複数のホストコンピュータのそれぞれ と通信し、該サーバーは、上位レベルプロトコルアドレスのリストと該ホストコ ンピュータに関連付けられた該ネットワークアドレスのリストとを維持し、該サ ーバーはさらに、該上位レベルプロトコルアドレスリストのうちの第１のアドレ スとネットワークアドレスリストのうちの第１のセットとの間の第１のアドレス マッピングを維持する、ステップと、 該サーバによって受け取られる第１のコントロールメッセージに応答して該サ ーバーが、該複数のネットワークアドレスのうちの第１のネットワークアドレス を該第１のアドレスマッピングにダイナミックに加えるステップであって、該第 １のネットワークアドレスは、該複数のホストコンピュータ内の第１のホストコ ンピュータに関連付けられ、該第１のコントロールメッセージは、該第１のホス トコンピュータによって該ネットワークを介して送られる、ステップと、 該第１のホストコンピュータによって発行される第２のコントロールメッセー ジに応答して、該サーバーが該第１のアドレスマッピングから該第１のネットワ ークアドレスをダイナミックに除去するステップと、 を包含する方法。 １４．ユニキャスト広域通信ネットワークを通して接続される複数のホストコン ピュータにメッセージを提供する方法であって、該複数のホストコンピュータは 、複数のネットワークアドレスに関連付けられている方法において、 該ネットワークに連結するサーバーを提供するステップであって、該サーバー は該ユニキャストネットワークを用いて該複数のホストコンピュータのそれぞれ と通信し、該サーバーは、上位レベルプロトコルアドレスのリストと該ホストコ ンピュータに関連付けられた該ネットワークアドレスのリストとを維持する、ス テップと、 該サーバーが、該上位レベルプロトコルアドレスリスト内の第１の上位レベル プロトコルアドレスと、該ネットワークアドレスリスト内の第１のネットワーク アドレスセットとの間に第１のアドレスマッピングを形成するステップと、 該サーバーが、該上位レベルプロトコルアドレスリスト内の第２の上位レベル プロトコルアドレスと、該ネットワークアドレスリスト内の第２のネットワーク アドレスセットとの間に第２のアドレスマッピングを形成するステップと、 該第１のネットワークアドレスセットのうちの１つに関連付けられた第１の ホストコンピュータが、メッセージを該サーバーに該ユニキャストネットワーク を介して送るステップであって、該メッセージはペイロード部分と識別部分とを 含み、該識別部分は該第１の上位レベルプロトコルアドレスを含み、さらに該第 ２の上位レベルプロトコルアドレスを含む、ステップと、 該第１および第２のネットワークアドレスセットを用いて論理集合演算を行い 、第３のネットワークアドレスセットを形成するステップと、 該サーバーが、該ユニキャストネットワークを介して該ペイロード部分を、該 第３のネットワークアドレスセットに関連付けられた選択されたホストコンピュ ータに伝送するステップと、 を包含する方法。