JP2004049922A - クライアントサーバシステム - Google Patents

Abstract

【課題】ＯＳ依存性やシステム構築の負担を増やすことなく、多人数が同時に接続した状態においてリアルタイム性を確保しつつ安定してゲーム等を実行することができる新たな枠組みを提供する。
【解決手段】複数のクライアントと少なくとも１つのゲームサーバとを含むゲームシステムを対象とし、クライアントが操作情報をサーバへ送信する工程、サーバがクライアントから操作情報を受信し、これに基づきゲームを進行させてゲームデータを更新する工程、サーバがゲームデータをクライアントへ送信する工程、クライアントがサーバからゲームデータを受信し、これに基づきユーザにゲーム情報を出力する工程を備える。このとき、クライアントからの操作情報の送信（サーバにおける操作情報の受信）はＵＤＰに基づいて行い、サーバからのゲームデータの送信（クライアントにおけるゲームデータの受信）はＴＣＰに基づいて行う。
【選択図】図４

Description

　本発明は、複数のクライアントと、クライアントと通信可能に構成された少なくとも１つのサーバとを含んで構成されるクライアントサーバシステムにおいて、複数のユーザが同時に参加するタイプのオンラインゲーム等を実行するのに適した枠組みに関する。

　インターネット等の急速な発展、更にそのブロードバンド化に伴い、通信ネットワークを介して複数のユーザが参加するオンラインゲーム(ネットワークゲーム)が注目を集めている。このようなオンラインゲームとして、特に多数のユーザが同時に参加するＭＭＯゲーム（Massively Multiplayer Online Game；多人数型オンラインゲーム)と呼ばれるジャンルがある。

　従来においてオンラインゲームは、クライアントサーバシステム、すなわち、ユーザから操作情報等を受け付けるとともにユーザに対しゲーム画面等の情報を出力するクライアントと、ゲームデータを管理しゲーム進行処理を実行するゲームサーバとを備え、両者のあいだでＴＣＰ（Transmission Control Protocol）に基づきコネクション型接続を行うシステム構成を採る場合が多い（図５参照）。

　コネクション型接続を行う場合、サーバ側の構成としては、例えば以下のようなタイプが考えられる。すなわち、１）ＴＣＰコネクションを介して行われるデータ受信を監視するスレッドをクライアントごとに作成し、スレッドを切り替えることにより各クライアントとの間で通信を行うマルチスレッドタイプ、２）ＴＣＰコネクションを介して行われる入出力を複数のクライアントについてまとめて監視する一つのスレッドを作成し、該スレッド内で複数のＴＣＰコネクションをポーリングすることにより各クライアントとの間で通信を行うシングルスレッドタイプ、３）データを受信した場合に割り込みを行うソケットをクライアントごとに作成し、該ソケットからの割り込みに基づいて各クライアントとの間で通信を行う割り込みタイプ、などである。

　しかし、マルチスレッドタイプやシングルスレッドタイプの構成では、クライアント数が増加するにつれてサーバの負担が大きくなってしまうという問題が生ずる。例えばマルチスレッドタイプでは、クライアントごとにスレッドが作成されるため、クライアント数が増加すると、スレッド管理・スレッド切り替えに起因するオーバヘッドが増大してしまうという問題が生ずる。また、シングルスレッドタイプでは、スレッド管理・スレッド切り替えに起因するオーバヘッドは生じないものの、クライアント数分のソケットをポーリングにより監視しなければならないため、ポーリングに起因するオーバヘッドが増大してしまうという問題が生ずる。

　特に、大人数（例えば１０００人以上）が同時にサーバに接続するＭＭＯゲームでは上記オーバヘッドは著しく、このことは、例えば入力した情報が反映されるまでのタイムラグの増大や、いわゆる処理落ちの発生など、ゲーム進行に関するリアルタイム性やパフォーマンスを大きく低下させ、またサーバダウンを引き起こす原因となっていた。

　一方、割り込みタイプでは、上記のようなオーバヘッドの問題は回避可能であるが、ＯＳレベルが提供するソケットが割り込み機能を持たない場合、アプリケーションレベル（ゲームプログラム側）で割り込みに対応できるようにソケットの機能を拡張しなければならず、ＯＳ依存性が高まる上にシステム構築の負担も大きくなってしまうという問題が生ずる。また、プログラム言語自体も割り込みに対応している必要があるが、広く普及している言語の多くは割り込みに対応していないことから、開発環境が制限されてしまうという問題もある。

　そこで、本発明は、ＯＳ依存性やシステム構築の負担を増やすことなく、多人数が同時に接続した状態においてもリアルタイム性を確保しつつ安定してゲーム処理等を実行することができる新たな枠組みを提供することを目的とする。

　本発明のサーバシステムは、複数のクライアントと通信可能に構成された少なくとも１つのサーバを備え、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたサーバシステムであって、前記サーバは、クライアントから前記ＡＰに関わるデータを受信する場合は、データが届いたかどうかを送信側が受信側に確認しないプロトコルに基づいて受信し、クライアントへ前記ＡＰに関わるデータを送信する場合は、データが届いたかどうかを送信側及び受信側で相互に確認するプロトコルに基づいて送信するように制御する手段を備えることを特徴とする。

　また本発明のサーバシステムは、複数のクライアントと通信可能に構成された少なくとも１つのサーバを備え、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたサーバシステムであって、前記サーバは、クライアントから前記ＡＰに関わるデータを受信する場合はＵＤＰ（User Datagram Protocol）に基づいて受信し、クライアントへ前記ＡＰに関わるデータを送信する場合はＴＣＰ（Transmission Control Protocol）に基づいて送信するように制御する手段を備えることを特徴とする。

　前記サーバは、ＵＤＰに基づいてクライアントから受信したパケットが該クライアントの認証情報を含んでいる場合に正当なパケットと判断する手段を備えることが望ましい。

　前記サーバは、ＵＤＰに基づいてクライアントから受信したパケットより検証情報を抽出し、該パケットの順序をチェックして未到着のパケットがあると判断した場合に、対応するクライアントへＴＣＰに基づいて前記未到着のパケットの再送指示を送信する手段を備えることが望ましい。

　本発明のクライアントは、所定のサーバと通信可能に構成され、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたクライアントであって、前記クライアントは、サーバから前記ＡＰに関わるデータを受信する場合は、データが届いたかどうかを送信側及び受信側で相互に確認するプロトコルに基づいて受信し、サーバへ前記ＡＰに関わるデータを送信する場合は、データが届いたかどうかを送信側が受信側に確認しないプロトコルに基づいて送信するように制御する手段を備えることを特徴とする。

　また本発明のクライアントは、所定のサーバと通信可能に構成され、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたクライアントであって、前記クライアントは、サーバから前記ＡＰに関わるデータを受信する場合はＴＣＰ（Transmission Control Protocol）に基づいて受信し、サーバへ前記ＡＰに関わるデータを送信する場合はＵＤＰ（User Datagram Protocol）に基づいて送信するように制御する手段を備えることを特徴とする。

　前記クライアントは、更に、ＵＤＰに基づいてサーバへ送信するパケットに、該クライアントの認証情報を挿入する手段を備えることが望ましい。

　前記クライアントは、更に、ＵＤＰに基づいてサーバへ送信するパケット（以下、「ＵＤＰパケット」と呼ぶ。）に、該パケットの順序をチェックするための検証情報を挿入する手段と、ＴＣＰに基づいてサーバからＵＤＰパケットの再送指示を受信した場合に、ＵＤＰに基づいてサーバへ再送対象のＵＤＰパケットを送信する手段を備えることが望ましい。

　本発明のクライアントサーバシステムは、本発明のサーバシステムと、本発明のクライアントと、を備えることを特徴とする。

　本発明において、前記認証情報は、クライアント−サーバ間のＴＣＰコネクションごとに異なっており、該コネクションが終了するまでの間においてのみ有効となるように制御されることが望ましい。

　また、前記ＡＰは、例えば、複数のユーザが同時に参加するタイプのオンラインゲームとすることができる。

　本発明のゲーム制御方法は、複数のクライアントと、少なくとも１つのゲームサーバとを含んで構成されるゲームシステムを対象としたゲーム制御方法であって、クライアントが操作情報をサーバへ送信する工程、サーバがクライアントから操作情報を受信し、これに基づきゲームを進行させてゲームデータを更新する工程、サーバがゲームデータをクライアントへ送信する工程、クライアントがサーバからゲームデータを受信し、これに基づきユーザにゲーム情報を出力する工程と、を備えており、クライアントからの操作情報の送信（サーバにおける操作情報の受信）は、データが届いたかどうかを送信側が受信側に確認しないプロトコルに基づいて行い、サーバからのゲームデータの送信（クライアントにおけるゲームデータの受信）は、データが届いたかどうかを送信側及び受信側で相互に確認するプロトコルに基づいて行うことを特徴とする。

　また本発明のゲーム制御方法は、複数のクライアントと、少なくとも１つのゲームサーバとを含んで構成されるゲームシステムを対象としたゲーム制御方法であって、クライアントが操作情報をサーバへ送信する工程、サーバがクライアントから操作情報を受信し、これに基づきゲームを進行させてゲームデータを更新する工程、サーバがゲームデータをクライアントへ送信する工程、クライアントがサーバからゲームデータを受信し、これに基づきユーザにゲーム情報を出力する工程と、を備えており、クライアントからの操作情報の送信（サーバにおける操作情報の受信）はＵＤＰ（User Datagram Protocol）に基づいて行い、サーバからのゲームデータの送信（クライアントにおけるゲームデータの受信）はＴＣＰ（Transmission Control Protocol）に基づいて行うことを特徴とする。

　本発明のプログラムは、本発明のゲーム制御方法の工程をコンピュータ上で実行させることを特徴とする。本発明のプログラムは、ＣＤ−ＲＯＭ、磁気ディスク、半導体メモリなどの各種の記録媒体を通じてコンピュータにインストールまたはロードすることができる。

　なお、本明細書において、１つの機能が２つ以上の物理的手段により実現されても、２つ以上の機能が１つの物理的手段により実現されても良い。

　本発明によれば、ＯＳ依存性やシステム構築の負担を増やすことなく、多人数が同時に接続した状態においてもリアルタイム性を確保しつつ安定してゲーム処理等を実行することができる新たな枠組みを提供することができる。

　（システム構成）
　以下に本発明の実施の形態について図面を用いて説明する。図１は、本発明を利用したシステムの全体構成をあらわすブロック図である。

　図１に示すように、全体システム１は、サーバシステム１０と、複数のクライアント２０とを含んでおり、それぞれ、インターネット等の通信ネットワークを介して互いに通信可能に構成されている。

　本発明において、全体システム１上でどのようなアプリケーションプログラムを実行するかは設計に応じて定めることができるが、以下、本実施形態ではゲームプログラム（特にＭＭＯゲームプログラム）を対象とした場合を例として説明を行う。

　サーバシステム１０は、相互に通信可能に構成された、ログインサーバ１１、ゲームサーバ１２、管理データベース１３等を含んで構成される。ただし、ログインサーバ１１、ゲームサーバ１２、管理データベース１３は、機能的に区分したものであり、物理的には同一の情報処理装置上に実現されていてもよい。

　ログインサーバ１１は、制御手段（ＣＰＵ）、入出力手段、記憶手段等を備えた一般的な構成を備える情報処理装置において、例えばＷｅｂサーバプログラム（Apache httpdや、CERN httpdなど）を実行することにより実現することができる。

　ログインサーバ１１は、クライアント２０からの要求に基づき、管理データベース１３を参照してユーザ認証を行い、認証が成立した場合にセッションＩＤを発行し、これをクライアント２０へ送信する機能を備える。

　ゲームサーバ１２は、制御手段（ＣＰＵ）、入出力手段、記憶手段等を備えた一般的な構成を備える情報処理装置によって構成することができる。

　ゲームサーバ１２には、ゲームサーバプログラムが実装されており、これを実行することにより、サーバ側通信制御機能、サーバ側ゲーム制御機能等を実現することができる。ゲームサーバプログラムは、ＣＤ−ＲＯＭ、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又はインターネット等を介して、ゲームサーバ１２にインストールまたはロードすることができる。

　サーバ側通信制御機能は、例えば、クライアントとの間でＴＣＰコネクションを確立する機能、クライアントに対しＴＣＰコネクションを介してゲームデータ（一部又は全部）を送信する機能、クライアントからＵＤＰ（User Datagram Protocol）に基づいて操作情報を受信する機能等を含む。

　サーバ側ゲーム制御機能は、例えば、クライアントから受信した操作情報に基づきゲームを進行させる機能、ゲーム進行に応じてゲームデータを管理・更新する機能等を含む。

　ここで、サーバ側ゲーム制御機能の具体的内容、例えばゲームの進行方法やゲームデータの内容は、設計に応じて定めることができる。例えば、いわゆる３次元タイプのロールプレイングゲームの場合、ゲームサーバ内に仮想空間を形成し、この空間にゲームのオブジェクトを配置するようにプログラムを構成する。そして、ゲームルールに従ってオブジェクトの動きを制御し、また、ユーザから受け付ける操作情報に従ってユーザが登録したオブジェクト(キャラクタ)を制御して、ゲームデータ（仮想空間内のオブジェクト等のデータ、ゲーム進行状態を示すデータ、ユーザが登録したキャラクタのパラメータ情報等）を更新するようにプログラムを構成する。このようなプログラムは、従来技術を用いて構成することができる。

　管理データベース１３は、制御手段（ＣＰＵ）、入出力手段、記憶手段等を備えた一般的な構成を備える情報処理装置において、リレーショナルデータベース等の従来のデータベース技術を用いて実現することができる。

　管理データベース１３は、ユーザＩＤやパスワード、その他のユーザ情報などを管理するとともに、ログインサーバ１１が発行したセッションＩＤを管理する機能を備える。ユーザ情報は、ユーザが登録したキャラクタのパラメータ情報など、ゲームデータの一部を含んでいてもよい。

　なお、ユーザＩＤの発行機能、パスワードやユーザ情報の登録機能等については、ログインサーバ１１等において、又は専用のサーバを設けて、従来システムと同様のプログラムを実行することにより、実現することができる。

　クライアント２０は、制御手段（ＣＰＵ）、入出力手段、記憶手段等を備えた一般的な構成の情報処理装置、例えば通常のパソコンやゲーム装置によって構成することができる。入力手段として、通常のキーボードやマウス等のほか、例えば画像情報や音声情報を入力するための手段、すなわちデジタルカメラ、ビデオカメラ、マイク等を備えていてもよい。

　クライアント２０には、クライアントプログラムが実装されており、これを実行することにより、ログイン機能、クライアント側通信制御機能、クライアント側ゲーム制御機能等を実現することができる。クライアントプログラムは、ＣＤ−ＲＯＭ、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又はインターネット等を介して、クライアント２０にインストールまたはロードすることができる。

　ログイン機能は、例えば、ユーザからの入力に基づき、ログインサーバ１１に対してセッションＩＤの発行を要求し、これを取得する機能等を含む。

　クライアント側通信制御機能は、例えば、サーバとの間でＴＣＰコネクションを確立する機能、サーバからＴＣＰに基づいてゲームデータを受信する機能、サーバに対してＵＤＰに基づいて操作情報を送信する機能等を含む。

　クライアント側ゲーム制御機能は、例えば、ユーザから操作情報を受け付ける機能、ユーザに対し、サーバから受信したゲームデータに基づきゲーム情報を出力する機能等を含む。

　ここで、クライアント側ゲーム制御機能の具体的内容、例えばユーザからどのような操作情報を受け付けるか、ユーザに対しどのようなゲーム情報を出力するかは、設計に応じて定めることができる。例えば、いわゆる３次元タイプのロールプレイングゲームの場合、仮想的な視点から見える仮想空間の様子をゲーム画面として表示するようにプログラムを構成する。また、ユーザが登録したオブジェクト(キャラクタ)に、移動、会話、戦闘、売買などの所定のアクションを行わせるコマンドや、ゲーム進行に関する各種コマンド等を受け付けるようにプログラムを構成する。このようなプログラムは、従来技術を用いて構成することができる。

　（ゲームの開始手順）
　以下に、ゲームを開始する場合の手順について、図２を参照して説明する。なお、各工程は処理内容に矛盾を生じない範囲で任意に順番を変更して、又は並列に実行することができる。

　まず、クライアント２０は、ユーザからの入力に基づき、例えばｈｔｔｐ（HyperText Transfer Protocol）に従って、ユーザＩＤ等とともにセッションＩＤの発行要求をログインサーバ１１へ出力する（Ｓ１００）。

　ログインサーバ１１は、クライアント２０からセッションＩＤの発行要求を受け付けた場合、ユーザ認証処理を実行する（Ｓ１０１）。ユーザ認証処理は、例えば正規ユーザに割り当てられているユーザＩＤ及び該ユーザが選択したパスワード等を記憶しておき、ユーザが入力した情報と前記記憶する情報とを照合するなど、従来の方法により行うことができる。

　ログインサーバ１１は、認証不成立の場合、その旨のメッセージ等をクライアント２０へ出力する。一方、認証成立の場合、セッションＩＤの発行処理を実行する（Ｓ１０２）。

　セッションＩＤは、ゲームサーバ１２において正規なアクセスであるかどうか等を判断する際に用いられるＩＤであり、例えばユーザＩＤと、セッションＩＤの発行処理ごとにランダムに生成した数列等とを組み合わせて、構成することができる。このように構成した場合、同一のユーザであっても、ログインサーバ１１にセッションＩＤの発行を要求する都度、異なるセッションＩＤが発行されることになる。

　ログインサーバ１１は、発行したセッションＩＤをクライアント２０へ送信するとともに（Ｓ１０３）、該セッションＩＤを管理データベース１３に有効なセッションＩＤとして登録する（Ｓ１０４）。

　なお、ログインサーバ１１は、ゲームサーバのＩＰアドレス及び通信に用いるポート番号を併せてクライアント２０へ送信するように構成してもよい。このように構成した場合、ゲームサーバを実現する情報処理装置を変更した場合等においてもユーザは特にその変更を意識することなくゲームサーバにアクセスすることが可能となり、柔軟なゲームシステムを構築することができる。

　クライアント２０は、セッションＩＤを受信した場合、ゲームサーバ１２へＴＣＰコネクションの確立を試みる（Ｓ１０５）。

　ＴＣＰコネクションの確立（Ｓ１０６）は、ＴＣＰに基づく通常の方法、例えば以下のようなスリーウェイハンドシェークと呼ばれる手順で行われる。まず、クライアント２０は、パッシブオープン状態にあるゲームサーバ１２に対して、ＳＹＮフラグの設定されたＴＣＰパケットを送信する。これを受けて、ゲームサーバ１２は、クライアント２０にポート番号を割り当てるとともにＴＣＰソケットを作成し、ＡＣＫフラグ及びＳＹＮフラグの設定されたＴＣＰパケットに前記割り当てたポート番号を挿入してクライアント２０へ送信する。これを受けて、クライアント２０は、ゲームサーバ１２にポート番号を割り当てるとともにＴＣＰソケットを作成し、ＡＣＫフラグの設定されたＴＣＰパケットに前記割り当てたポート番号を挿入してゲームサーバ１２へ送信する。かかる手順により、ＴＣＰコネクションが確立する。

　クライアント２０は、ＴＣＰコネクションの確立後、ＴＣＰに基づいてセッションＩＤをゲームサーバ１２へ送信する（Ｓ１０７）。

　ゲームサーバ１２は、クライアント２０からＴＣＰに基づいてセッションＩＤを受信した場合、クライアント２０からのアクセスが正規であるかどうか（正規の手順を経て行われたアクセスであるかどうか）の確認処理を実行する（Ｓ１０８）。

　具体的には、管理データベース１３を参照して（又は、ログインサーバ１１から）現在有効なセッションＩＤを取得し、前記受信したセッションＩＤが現在有効であるかどうかをチェックする。

　ゲームサーバ１２は、確認処理の結果に応じてメッセージ等をクライアント２０へ出力する（Ｓ１０９）。また、セッションＩＤが有効である場合、確立したＴＣＰコネクションの情報（クライアントのＩＰアドレスやポート番号など）とともに該セッションＩＤをクライアントリストに登録する（Ｓ１１０）。これにより、クライアントリストを参照することで、ゲームに対して参加状態となっているクライアントを知ることができる。

　（ゲームの実行手順）
　以下に、ゲームを実行する場合の手順について、図３、図４を参照して説明する。

　まず前提として、ゲームサーバ１２と各クライアント２０との間に、ゲーム開始手順に従ってＴＣＰコネクションが確立しているものとする。また、ゲームサーバ１２において、サーバ側通信制御機能により、ＵＤＰパケット受信用にポートが割り当てられ（以下、「ＵＤＰポート」と呼ぶ。）、該ＵＤＰポートに対応してデータを読み出すためのＵＤＰソケットが作成されているものとする（図４（ａ）参照）。なお、ＵＤＰポートは原則として１つあればよいが、設計に応じて複数設ける構成としてもよい。

　ゲームの実行は、上記前提のもと、以下の一連の工程（Ｓ２００〜Ｓ２１０）を原則としてサイクリックに実行することにより行われる。なお、各工程は処理内容に矛盾を生じない範囲で任意に順番を変更して、又は並列に実行することができる。

　ゲームサーバ１２は、クライアントリストに登録されているクライアント２０に対し、該クライアントとの間に確立されているＴＣＰコネクションを利用して、ＴＣＰに基づいてゲームデータを送信する（Ｓ２００）。図４（ｂ）において符号Ｔはゲームデータを含むＴＣＰパケットを示している。

　ここで、ゲームデータのうちどのデータを送信するかは設計に応じて定めることができるが、送信するデータ量を少なくするために、２回目以降の送信では前回との差分データのみを送信するように構成することが望ましい。

　クライアント２０は、ゲームサーバ１２からＴＣＰに基づいてゲームデータを受信し、ＴＣＰに基づく応答確認等をゲームサーバ２０へ返信する（Ｓ２０１）。また、ユーザに対し、前記受信したゲームデータに基づいてゲーム情報を出力する（Ｓ２０２）。また、ユーザから操作情報を受け付ける（Ｓ２０３）。

　クライアント２０は、ユーザから受け付けた操作情報、セッションＩＤ、シーケンス番号等をデータとして含み、ゲームサーバ１２のＵＤＰポートを送信先とするＵＤＰパケットを作成し、これをゲームサーバ１２へＵＤＰに基づいて送信する（Ｓ２０４）。図４（ｂ）において符号Ｕは、かかる操作情報等を含むＵＤＰパケットを示している。

　ここで、シーケンス番号は、ＵＤＰパケットの送信順序（受信順序）を示す番号であり、例えば前回送信したＵＤＰパケットのシーケンス番号に予め定めた所定数を加算（又は減算）して生成することができる（以下では１を加算する場合を例として説明する）。

　ゲームサーバ１２は、クライアント２０からＵＤＰに基づいて（すなわちＵＤＰポートを介して）ＵＤＰパケットを受信し、これを読み出す（Ｓ２０５）。

　そして、前記受信したＵＤＰパケットの正当性チェック処理を行う（Ｓ２０６）。ＵＤＰによる通信はコネクションに基づく正当性が保証されないため、パケットごとに、その正当性（正規の手順を経て送信されたパケットであるかどうか）をチェックすることが望ましいからである。

　具体的には、受信したＵＤＰパケットに含まれるセッションＩＤがクライアントリストに登録されている場合、受信したＵＤＰパケットが正当であると判断する。このとき、クライアントリストにはセッションＩＤとともにＴＣＰコネクションの情報も登録されているため、ゲームサーバ１２は、セッションＩＤに対応するＴＣＰコネクションの情報を参照することにより、ＵＤＰパケットがどのクライアント２０から送信されたものであるかを識別することができる。一方、セッションＩＤがクライアントリストに登録されていない場合、受信したＵＤＰパケットは正当でないと判断して、これを破棄する。

　ここで、単純には、セッションＩＤの代わりにユーザＩＤを用いてパケットの正当性をチェックする構成も考えられる。しかし、かかる構成の場合、ユーザＩＤがいったん漏洩してしまうと、成りすまし等のリスクを回避するためにはユーザＩＤを変更しなければならなくなり、このような変更は、システム側、ユーザ側の双方に煩雑な作業を強いることになる。これに対し、本実施形態のように、セッションＩＤを用いてパケットの正当性をチェックする構成の場合、セッションＩＤは１回の接続（ＴＣＰコネクションの確立から終了までの間）ごとに異なり、かつその１回の接続においてのみ有効であるため、仮にセッションＩＤが漏洩したとしても、次回の接続以降にそのセッションＩＤを用いて成りすまし等を行うことは不可能となり、ＩＤの漏洩に対して頑強なシステムを構築することができる。

　ゲームサーバ１２は、ＵＤＰパケットが正当であると判断した場合、次に、ＵＤＰパケットが正しい順序のパケットであるかどうかをチェックする（Ｓ２０７）。ＵＤＰによる通信はＴＣＰのように通信の信頼性が確保されていないため、アプリケーション側においてデータ欠落等に対応することが望ましいからである。

　具体的には、式（今回受信したＵＤＰパケット（以下、「直近受信ＵＤＰパケット」と呼ぶ。）のシーケンス番号）＝（前回受信した同じセッションＩＤを含むＵＤＰパケットのシーケンス番号）＋１が成立するかどうかに基づき、正しい順序であるか否かを判断する。

　ゲームサーバ１２は、前記式が成立しない場合、正しい順序でないと判断する。そして、所定期間経過しても正しい順序のＵＤＰパケットが到着しない場合、クライアントリストを参照して直近受信ＵＤＰパケットのセッションＩＤに対応するクライアント２０を選択し、未到着のＵＤＰパケット（正しい順序のシーケンス番号を含むＵＤＰパケット）の再送指示を、前記選択したクライアント２０へＴＣＰに基づいて送信する。

　一方、ゲームサーバ１２は、前記式が成立する場合、正しい順序であると判断する。そして、クライアントリストを参照して直近受信ＵＤＰパケットのセッションＩＤに対応するクライアント２０を選択し、ＵＤＰパケットを正しく受信できたことを示す確認情報（直近受信ＵＤＰパケットのシーケンス番号など）を、前記選択したクライアント２０へＴＣＰに基づいて送信する（Ｓ２０８）。

　また、ゲームサーバ１２は、直近受信ＵＤＰパケットに含まれる操作情報に基づいてゲームを進行させ、記憶手段に記憶するゲームデータをゲーム進行に応じて更新する（Ｓ２０９）。

　クライアント２０は、ゲームサーバ１２からＴＣＰに基づいてＵＤＰパケットの再送指示や確認情報を受信し、ＴＣＰに基づく応答確認等をゲームサーバ２０へ返信する（Ｓ２１０）。また、再送指示に対しては、対応するＵＤＰパケットをゲームサーバ１２へＵＤＰに基づいて送信する。

　なお、ＵＤＰパケットに含まれる操作情報が、ゲームをいったん中止する（ゲームサーバとの接続をいったん中止する）ことを指示するものである場合、ゲームサーバ１２は、ログアウト処理を実行する。

　具体的には、ゲームサーバ１２は、クライアントリストから該当するクライアントの情報を削除する。また、管理データベース１３を参照して該当するセッションＩＤを削除するとともに、必要に応じて管理データベース１３が記憶するユーザ情報（ユーザが登録したキャラクタのパラメータ情報など）を更新する。

　また、該当するクライアント２０及びゲームサーバ１２は、ＴＣＰに基づく通常の方法により、両者の間に確立しているＴＣＰコネクションを終了する。

　このように、本実施形態では、ゲームの実行中、クライアントからゲームサーバへ操作情報を送信する場合、ＴＣＰコネクションを介さずに、コネクション型接続ではないＵＤＰに基づいて送信するように構成している。

　かかる構成のもとでは、ゲームサーバにおいて、各コネクションに対応させてスレッドを作成したり、各コネクションをポーリングにより監視する必要が無くなるため、クライアント数が増加した場合でもスレッドの切り替えやポーリングによるオーバヘッドが生じず、サーバ側の負担を大きく抑制することができる。その結果、ＭＭＯゲームのような多人数が同時に参加するタイプのゲームであっても、リアルタイム性やパフォーマンスを低下させることなく、安定してゲームを実行することが可能となる。

　また、もともとＵＤＰパケットはＴＣＰパケットよりもデータサイズが小さいため、トラフィック量の減少、伝送速度の向上という効果を得ることができ、かかる点からもリアルタイム性を向上させることができる。

　また、コネクション型接続ではないPeer-to-Peerタイプのシステム構成と比較した場合、Peer-to-Peerタイプのシステム構成では、ＮＡＴ（Network Address Translation）やＩＰマスカレード技術を利用してプライベートＩＰアドレスを使用している場合、クライアントは自己宛てのパケットを受信することができない（又は非常に複雑な環境設定が必要となる）という問題が生ずるが、本実施形態では、ゲームサーバからクライアントへゲームデータを送信する場合には、ＴＣＰコネクションを介して送信するように構成しているため、上記のような問題は生じない。

　更に、本実施形態の構成は、ＴＣＰ、ＵＤＰという一般的なプロトコルを利用する構成となっているため、ＯＳレベルにより提供される機能を特に拡張する必要はなく、一般的なＯＳのもとで一般的なプログラム言語を用いてシステムを構築することができる。

　（その他）
　本発明は、上記実施形態に限定されることなく種々に変形して適用することが可能である。

　例えば、サーバシステム１０内に複数のゲームサーバを設け、各ゲームサーバにおいてゲーム制御機能を並列に又は分担して実現する構成としてもよい。この場合、サーバシステム１０内にＮＡＴ（ＩＰマスカレード機能）を設け、一つのグローバルＩＰアドレスで複数のゲームサーバとの接続を管理できるように構成してもよい。

　いわゆる３次元タイプのロールプレイングゲームにおいて複数のゲームサーバを設ける場合、各ゲームサーバがそれぞれの仮想世界を並列に管理する（ゲーム進行を制御する）構成や、各ゲームサーバが仮想空間内の一部の領域（国、地域、町、店など）を分担して管理する構成や、又はこれらを組み合わせた構成とすることが考えられる。

　上記のような複数のゲームサーバを設ける構成では、ユーザが、複数のゲームサーバを移動しながら（クライアントとの接続を切り替えながら）ゲームに参加できるように、以下のような構成することが望ましい。

　すなわち、ゲームサーバ１２Ａは、クライアント２０から送信されるＵＤＰパケットに、別のゲームサーバ１２Ｂが管理する仮想世界又は領域への移動を指示する操作情報が含まれている場合、ＴＣＰコネクションを介して、該クライアント２０にゲームサーバ１２ＢのＩＰアドレス及びポート番号を送信するとともに、ログアウト処理を実行する。ただし、ゲームサーバ１２ＢのＩＰアドレス等が固定されている場合は、その都度送信する必要はなく、予めクライアント２０において記憶しておけばよい。

　次に、クライアント２０及びゲームサーバ１２Ａは、ＴＣＰに基づく通常の方法により、両者の間に確立しているＴＣＰコネクションを終了する。ただし、必要に応じて復帰が迅速に行えるように維持したままとしてもよい。

　次に、クライアント２０は、ゲームサーバ１２Ｂとの間で、ゲーム開始手順に従って新たにＴＣＰコネクションを確立し、ゲーム実行手順に従ってゲームを引き続き実行する。ただし、ゲームサーバ１２Ｂにおいて、管理データベース１３を参照する代わりに、ゲームサーバ１２Ａから直接クライアント２０のセッションＩＤを取得し、アクセスが正規であるかどうかの確認処理やパケットの正当性チェック処理に用いるように構成してもよい。

　なお、上記実施形態では、ログインサーバ１１が発行したセッションＩＤをパケットの認証情報として用いているが、必ずしもこのような構成に限られず、例えば、ゲームサーバ１２においてアクセスが正規であると判断された場合に改めてセッションＩＤを発行し、これをパケットの認証情報として用いる構成としてもよい。この場合、ゲームサーバ１２がユーザ認証についても行う構成とすれば、ログインサーバ１１を省略することも可能である。

　また、上記実施形態では、ゲームサーバ１２において常にＵＤＰパケットの正当性チェック処理や順序のチェック処理を行う構成としているが、これらの処理を行わない構成、又はＵＤＰパケットに含まれる情報の種類によってチェックを行うかどうかを切り替える構成など、種々の態様を考えることができる。なお、ＵＤＰパケットの受信時にクライアントリストを参照しての正当性チェック処理を行わない場合は、例えばＵＤＰパケットに含まれるセッションＩＤやユーザＩＤ、送信元のＩＰアドレスなどに基づいて直接的に、受信したＵＤＰパケットがどのクライアント２０から送信されたものであるかを識別する構成としてもよい。

　また、上記実施形態では、クライアントからゲームサーバへの送信は常にＵＤＰに基づいて、ゲームサーバからクライアントへの送信は常にＴＣＰに基づいて行う構成としているが、本発明は必ずしもこのような構成に限られるものではなく、例えば、送信するデータの内容に応じてプロトコルを選択して送信する構成としてもよい。例えば、リアルタイム性を要求されないデータや欠落が許されないデータについてはクライアントからゲームサーバへ送信する場合は、ＵＤＰではなくＴＣＰに基づいて送信するといった構成を考えることができる。

　リアルタイム性を要求されないデータとは、例えばＭＭＯゲームであれば直ちにゲーム進行に反映させる必要性の低いデータ等であり、具体的には、ゲーム中のイベントをクリアしたかどうかを示すフラグ、ゲームキャラクタの所持するお金やアイテム、ゲームキャラクタのパラメータ・経験値などである。このようなリアルタイム性を要求されないデータについてクライアントからゲームサーバへＴＣＰに基づいて送信する構成を採用する場合、ゲームサーバは、ＴＣＰソケットのポーリングをリアルタイムに常時行うのではなく、通常よりも間隔を空けて行うことで（例えば１秒に１回など）、ポーリングに起因するオーバヘッドを軽減することができる。

　また、欠落が許されないデータとしては、ゲーム中のイベントをクリアしたかどうかを示すフラグ、特定のアイテムを入手したことを示すフラグ、課金情報などを考えることができる。このような欠落が許されないデータについてクライアントからゲームサーバへＴＣＰに基づいて送信する構成を採用する場合、裏を返せば、クライアントからゲームサーバへＵＤＰに基づいて送信するデータは欠落が許されるデータ（例えば、チャットにおけるテキストデータ、音声データなど）となることから、ゲームサーバでは、ＵＤＰパケットについて欠落が生じている場合でも再送指示を送信する必要はなく、更に言うならば、ＵＤＰパケットの順序チェック処理自体を行う必要がなくなるため、かかる点においてもゲームサーバの負担を軽減することができる。

　最後に、上記実施形態では、出願時点において広く使用されているプロトコルであるＴＣＰ、ＵＤＰを特定して説明したが、本発明はこのようなプロトコルを用いる構成に限定されるものではない。すなわち、上記実施形態において、データが届いたかどうかを送信側が受信側に確認しないプロトコル、２つのノード上のプロセス（アプリケーション）間でベストエフォート型のデータグラム指向の通信を行うプロトコルであれば、ＵＤＰに代えて用いることができる。また、データが届いたかどうかを送信側及び受信側で相互に確認するプロトコル、クライアントから送信される要求メッセージに基づいてサーバが応答メッセージを返信する要求／応答型のプロトコル、２つのノード上のプロセス（アプリケーション）間でギャランティ型の信頼性のあるセッション指向の通信を行うプロトコルであれば、ＴＣＰに代えて用いることが可能である。

本発明の全体システムの構成を示すブロック図である。 ゲーム開始手順を説明するための流れ図である。 ゲーム実行手順を説明するための流れ図である。 本発明の枠組みを説明するための図である。 従来技術の枠組みを説明するための図である。

符号の説明

１　全体システム
１０　サーバシステム
１１　ログインサーバ
１２　ゲームサーバ
１３　管理データベース
２０　クライアント

Claims (17)

1. 複数のクライアントと通信可能に構成された少なくとも１つのサーバを備え、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたサーバシステムであって、
   　前記サーバは、クライアントから前記ＡＰに関わるデータを受信する場合は、データが届いたかどうかを送信側が受信側に確認しないプロトコルに基づいて受信し、クライアントへ前記ＡＰに関わるデータを送信する場合は、データが届いたかどうかを送信側及び受信側で相互に確認するプロトコルに基づいて送信するように制御する手段を備えることを特徴とする、サーバシステム。
2. 複数のクライアントと通信可能に構成された少なくとも１つのサーバを備え、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたサーバシステムであって、
   　前記サーバは、クライアントから前記ＡＰに関わるデータを受信する場合はＵＤＰ（User Datagram Protocol）に基づいて受信し、クライアントへ前記ＡＰに関わるデータを送信する場合はＴＣＰ（Transmission Control Protocol）に基づいて送信するように制御する手段を備えることを特徴とする、サーバシステム。
3. 前記サーバが、ＵＤＰに基づいてクライアントから受信したパケットが該クライアントの認証情報を含んでいる場合に正当なパケットと判断する手段を備えることを特徴とする請求項１記載のサーバシステム。
4. 前記認証情報は、クライアント−サーバ間のＴＣＰコネクションごとに異なっており、該コネクションが終了するまでの間においてのみ有効となるように制御されることを特徴とする請求項３記載のサーバシステム。
5. 前記サーバが、ＵＤＰに基づいてクライアントから受信したパケットより検証情報を抽出し、該パケットの順序をチェックして未到着のパケットがあると判断した場合に、対応するクライアントへＴＣＰに基づいて前記未到着のパケットの再送指示を送信する手段を備えることを特徴とする請求項２乃至４のいずれか１項に記載のサーバシステム。
6. 前記ＡＰは、複数のユーザが同時に参加するタイプのオンラインゲームであることを特徴とする請求項２乃至５のいずれか１項に記載のサーバシステム。
7. 所定のサーバと通信可能に構成され、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたクライアントであって、
   　前記クライアントは、サーバから前記ＡＰに関わるデータを受信する場合は、データが届いたかどうかを送信側及び受信側で相互に確認するプロトコルに基づいて受信し、サーバへ前記ＡＰに関わるデータを送信する場合は、データが届いたかどうかを送信側が受信側に確認しないプロトコルに基づいて送信するように制御する手段を備えることを特徴とするクライアント。
8. 所定のサーバと通信可能に構成され、所定のアプリケーション（以下、「ＡＰ」と呼ぶ。）を実行可能に構成されたクライアントであって、
   　前記クライアントは、サーバから前記ＡＰに関わるデータを受信する場合はＴＣＰ（Transmission Control Protocol）に基づいて受信し、サーバへ前記ＡＰに関わるデータを送信する場合はＵＤＰ（User Datagram Protocol）に基づいて送信するように制御する手段を備えることを特徴とするクライアント。
9. 更に、ＵＤＰに基づいてサーバへ送信するパケットに、該クライアントの認証情報を挿入する手段を備えることを特徴とする請求項８記載のクライアント。
10. 前記認証情報は、クライアント−サーバ間のＴＣＰコネクションごとに異なっており、該コネクションが終了するまでの間においてのみ有効となるように制御されることを特徴とする請求項９記載のクライアント。
11. 更に、ＵＤＰに基づいてサーバへ送信するパケット（以下、「ＵＤＰパケット」と呼ぶ。）に、該パケットの順序をチェックするための検証情報を挿入する手段と、
    　ＴＣＰに基づいてサーバからＵＤＰパケットの再送指示を受信した場合に、ＵＤＰに基づいてサーバへ再送対象のＵＤＰパケットを送信する手段と、を備えることを特徴とする請求項８乃至１０のいずれか１項に記載のクライアント。
12. 前記ＡＰは、複数のユーザが同時に参加するタイプのオンラインゲームであることを特徴とする、請求項８乃至１１のいずれか１項に記載のクライアント。
13. 請求項１乃至５のいずれか１項に記載のサーバシステムと、請求項７乃至１１のいずれか１項に記載のクライアントと、を備えることを特徴とするクライアントサーバシステム。
14. 前記ＡＰは、複数のユーザが同時に参加するタイプのオンラインゲームであることを特徴とする、請求項１３記載のクライアントサーバシステム。
15. 複数のクライアントと、少なくとも１つのゲームサーバとを含んで構成されるゲームシステムを対象としたゲーム制御方法であって、
    　クライアントが操作情報をサーバへ送信する工程、サーバがクライアントから操作情報を受信し、これに基づきゲームを進行させてゲームデータを更新する工程、サーバがゲームデータをクライアントへ送信する工程、クライアントがサーバからゲームデータを受信し、これに基づきユーザにゲーム情報を出力する工程と、を備えており、
    　クライアントからの操作情報の送信（サーバにおける操作情報の受信）は、データが届いたかどうかを送信側が受信側に確認しないプロトコルに基づいて行い、サーバからのゲームデータの送信（クライアントにおけるゲームデータの受信）は、データが届いたかどうかを送信側及び受信側で相互に確認するプロトコルに基づいて行うことを特徴とするゲーム制御方法。
16. 複数のクライアントと、少なくとも１つのゲームサーバとを含んで構成されるゲームシステムを対象としたゲーム制御方法であって、
    　クライアントが操作情報をサーバへ送信する工程、サーバがクライアントから操作情報を受信し、これに基づきゲームを進行させてゲームデータを更新する工程、サーバがゲームデータをクライアントへ送信する工程、クライアントがサーバからゲームデータを受信し、これに基づきユーザにゲーム情報を出力する工程と、を備えており、
    　クライアントからの操作情報の送信（サーバにおける操作情報の受信）はＵＤＰ（User Datagram Protocol）に基づいて行い、サーバからのゲームデータの送信（クライアントにおけるゲームデータの受信）はＴＣＰ（Transmission Control Protocol）に基づいて行うことを特徴とするゲーム制御方法。
17. 請求項１５又は１６記載のゲーム制御方法の工程をコンピュータで実行させるためのプログラム。

Images