JP7291247B2 - 配送制御装置、配送制御方法及び配送制御プログラム - Google Patents

Description

本発明は、配送制御装置、配送制御方法及び配送制御プログラムに関する。

クライアントサーバシステムでは、クライアントがサーバにパケットを送信すると、このパケットを受信したサーバは、このパケットの宛先のポート番号が待ち受けポート番号であるサーバプロセスにこのパケットを配送する。

サーバプログラムを起動することにより生成されるサーバプロセスの待ち受けポート番号は、当該サーバプログラムの開発者によって予め設定される。

ここでサーバプログラムの開発者は他のサーバプログラムにおいて設定される待ち受けポート番号を事前に把握できない。そのため、サーバプロセスの待ち受けポート番号が複数のサーバプログラムにおいて重複することがある。

この場合、重複する待ち受けポート番号が宛先であるパケットの配送先のサーバプロセスを特定できない。

本発明は上記実情に鑑みてなされたものであって、その目的の一つは、複数のサーバプロセスにおいて待ち受けポート番号が重複していても、当該待ち受けポート番号を宛先とするパケットを適切に配送できる配送制御装置、配送制御方法及び配送制御プログラムを提供することにある。

上記課題を解決するために、本発明に係る配送制御装置は、互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスを検出する検出部と、検出される前記複数の実行中のサーバプロセスのうち、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御するプロセス制御部と、前記待ち受けポート番号が宛先であるパケットを受信する受信部と、受信する前記パケットを前記動作状態の前記サーバプロセスに配送する配送制御部と、を含む。

本発明の一態様では、パケットの送信元と当該パケットの配送先である前記サーバプロセスとが関連付けられたソケット管理データを記憶するソケット管理データ記憶部、をさらに含み、前記配送制御部は、前記ソケット管理データに登録されていない送信元から受信するパケットを、前記動作状態の前記サーバプロセスに配送する。

この態様では、前記配送制御部は、前記ソケット管理データにおいて前記待機状態の前記サーバプロセスと関連付けられている送信元から受信するパケットを破棄してもよい。

この場合、前記配送制御部は、前記パケットがＴＣＰ ＲＳＴパケットである場合は当該パケットを破棄せずに当該サーバプロセスに配送してもよい。

また、前記配送制御部は、前記パケットがＴＣＰ ＦＩＮパケットである場合は当該パケット及び送信元が同じである後続するパケットを破棄せずに当該サーバプロセスに配送してもよい。

また、本発明の一態様では、前記プロセス制御部は、新たな前記サーバプロセスが生成される際に、当該サーバプロセスが動作状態になるように制御し、当該サーバプロセスと待ち受けポート番号が同じである動作状態の前記サーバプロセスを待機状態に遷移させる。

また、本発明の一態様では、前記プロセス制御部は、待機状態である前記サーバプロセスの指定に応じて、当該サーバプロセスを動作状態に遷移させるとともに、当該サーバプロセスと待ち受けポート番号が同じである動作状態の前記サーバプロセスを待機状態に遷移させる。

また、本発明に係る配送制御方法は、互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスを検出するステップと、検出される前記複数の実行中のサーバプロセスのうち、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御するステップと、前記待ち受けポート番号が宛先であるパケットを受信するステップと、受信する前記パケットを前記動作状態の前記サーバプロセスに配送するステップと、を含む。

また、本発明に係る配送制御プログラムは、互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスを検出する手順、検出される前記複数の実行中のサーバプロセスのうち、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御する手順、前記待ち受けポート番号が宛先であるパケットを受信する手順、受信する前記パケットを前記動作状態の前記サーバプロセスに配送する手順、をコンピュータに実行させる。

本発明の一実施形態の全体構成の一例を示す図である。 本実施形態に係る通信の一例を模式的に示す図である。 ソケット管理データの一例を示す図である。 本実施形態に係る通信の一例を模式的に示す図である。 サスペンド管理データの一例を示す図である。 ソケット管理データの一例を示す図である。 サスペンド管理データの一例を示す図である。 本発明の一実施形態に係る端末の機能の一例を示す機能ブロック図である。 本発明の一実施形態に係る端末で行われる処理の流れの一例を示すフロー図である。 本発明の一実施形態に係る端末で行われる処理の流れの一例を示すフロー図である。 本発明の一実施形態に係る端末で行われる処理の流れの一例を示すフロー図である。

以下、本発明の一実施形態について図面に基づき詳細に説明する。

図１は、本発明の一実施形態に係るゲームシステム１の全体構成の一例を示す図である。図１に示すように、本実施形態に係るゲームシステム１には、端末１０、端末１２、及び、端末１４が含まれている。端末１０、端末１２、及び、端末１４は、インターネット等のコンピュータネットワーク１６に接続されている。そのため端末１０、端末１２、及び、端末１４は、コンピュータネットワーク１６を介して互いに通信可能となっている。

図１に示すように、端末１０には、例えば、プロセッサ１０ａ、記憶部１０ｂ、通信部１０ｃ、操作部１０ｄ、表示部１０ｅが含まれる。端末１２には、例えば、プロセッサ１２ａ、記憶部１２ｂ、通信部１２ｃ、操作部１２ｄ、表示部１２ｅが含まれる。端末１４には、例えば、プロセッサ１４ａ、記憶部１４ｂ、通信部１４ｃ、操作部１４ｄ、表示部１４ｅが含まれる。

プロセッサ１０ａ、プロセッサ１２ａ、プロセッサ１４ａは、それぞれ、例えば、端末１０、端末１２、端末１４にインストールされるプログラムに従って動作するマイクロプロセッサ等のプログラム制御デバイスである。

記憶部１０ｂ、記憶部１２ｂ、記憶部１４ｂは、例えばＲＯＭやＲＡＭ等の記憶素子や、ソリッドステートドライブ（ＳＳＤ）などである。記憶部１０ｂ、記憶部１２ｂ、記憶部１４ｂには、それぞれ、プロセッサ１０ａ、プロセッサ１２ａ、プロセッサ１４ａ、によって実行されるプログラムなどが記憶される。

通信部１０ｃ、通信部１２ｃ、通信部１４ｃは、例えば、無線ＬＡＮモジュールなどの通信インタフェースである。通信部１０ｃは、コンピュータネットワーク１６を介して、端末１２や端末１４との間でデータを授受する。通信部１２ｃは、コンピュータネットワーク１６を介して、端末１０や端末１４との間でデータを授受する。通信部１４ｃは、コンピュータネットワーク１６を介して、端末１０や端末１２との間でデータを授受する。

操作部１０ｄ、操作部１２ｄ、操作部１４ｄは、例えばユーザが行った操作の内容を、それぞれ、プロセッサ１０ａ、プロセッサ１２ａ、プロセッサ１４ａに出力するボタンやタッチセンサ等の操作部材である。

表示部１０ｅ、表示部１２ｅ、表示部１４ｅは、例えば液晶ディスプレイや有機ＥＬディスプレイ等のディスプレイである。

本実施形態では例えば、端末１０において、複数のゲームプログラムを実行することができる。ただし、実行中である複数のゲームプログラムのうち動作状態であるものは１つに制限され、残りのゲームプログラムは待機状態（サスペンド状態）になるよう制御される。そのため本実施形態では、複数のゲームプログラムが同時に動作状態になっていることを考慮したゲームプログラムの品質保証タスク（ＱＡタスク）を行う必要がない。

実行中のゲームプログラムが動作状態から待機状態に遷移すると、ワークメモリやレジスタ等に記憶されている当該ゲームプログラムの実行状態を示す状態データが、記憶部１０ｂのメモリ又はＳＳＤに設けられた退避領域に保存される。そして、当該ゲームプログラムが待機状態から動作状態に復帰（レジューム）すると、退避領域に保存されていた状態データが元の場所に戻される。

また、ゲームプログラムが動作状態である際に行われていた通信は、待機状態になると中断される。そして、当該ゲームプログラムが待機状態から動作状態に復帰すると、中断されていた通信が再開される。

以上のことは、端末１２、及び、端末１４においても同様である。

また、本実施形態に係るゲームプログラムは、マルチプレイのゲームのプログラムであり、クライアント機能とサーバ機能とを備えている。そして、本実施形態に係るゲームプログラムは、サーバとして機能するサーバモード又はクライアントとして機能するクライアントモードのいずれかの動作モードで動作させることができるようになっている。

本実施形態では例えば、ゲームプログラムをサーバモードで起動することで、当該ゲームプログラムに対応するサーバプロセスが生成される。本実施形態では例えば、ゲームプログラムに対応するサーバプロセスがバインドされる待ち受けポート番号は、当該ゲームプログラムの開発者によって予め設定されている。

また本実施形態では例えば、ゲームプログラムをクライアントモードで起動することで、当該ゲームプログラムに対応するクライアントプロセスが生成される。本実施形態では例えば、ゲームプログラムに対応するクライアントプロセスがバインドされるポートのポート番号は、空いているポート番号のうちからオペレーティングシステム等のシステムプログラムによって動的に決定される。

以下、本実施形態に係るゲームシステム１における動作の一例について説明する。以下の説明では、端末１０、端末１２、端末１４のユーザを、それぞれ、ユーザＡ、ユーザＢ、ユーザＣと呼ぶこととする。また、端末１０、端末１２、端末１４に設定されたＩＰアドレスは、それぞれ、１１．１１．１１．１１、２２．２２．２２．２２、３３．３３．３３．３３であることとする。

当該動作例では、まず、図２に示すように、端末１０が、ゲームプログラムＡｐｐ１をサーバモードで起動する。このことによって、サーバプロセスＳ１が端末１０に生成される。そして、サーバプロセスＳ１は、動作状態での実行を開始する。図２に示すように、サーバプロセスＳ１は、ポート番号５００００にバインドされる。上述のように、サーバプロセスＳ１にバインドされるポート番号５００００は、ゲームプログラムＡｐｐ１において予め設定されている。

そして、端末１２が、ゲームプログラムＡｐｐ１をクライアントモードで起動する。このことによって、クライアントプロセスＣ１が端末１２に生成される。そして、クライアントプロセスＣ１は、動作状態での実行を開始する。図２に示すように、クライアントプロセスＣ１は、ポート番号５１０００にバインドされる。上述のように、クライアントプロセスＣ１にバインドされるポート番号５１０００は、端末１２で動作するシステムプログラムによって動的に割り当てられる。

そして、端末１０と端末１２との間で通信が行われることにより、ユーザＡとユーザＢは、ゲームプログラムＡｐｐ１によって提供されるマルチプレイのゲームを楽しむことができる。端末１０は、このゲームがプレイされている際に端末１０のポート番号５００００を宛先とするパケットを受信すると、端末１０によってカーネルメモリに動的に確保されるサーバプロセスＳ１のソケットバッファに当該パケットを格納する。そして、サーバプロセスＳ１は、当該パケットに含まれるデータに応じた処理を実行する。このようにして、当該パケットは、動作状態であるサーバプロセスＳ１に配送される。

図３は、パケットの送信元と当該パケットの配送先であるサーバプロセスとが関連付けられたソケット管理データの一例を示す図である。図３に示すソケット管理データは、例えば、端末１２の５１０００番ポートが送信元であり端末１０の５００００番ポートが宛先である最初のＴＣＰパケットを端末１０が受信した際に端末１０に登録される。ソケット管理データには、例えば、プロセスＩＤ、プロトコルデータ、クライアントＩＰアドレス、クライアントポート番号、サーバＩＰアドレス、及び、サーバポート番号が含まれる。このように本実施形態に係るソケット管理データによって、サーバのソケットとクライアントのソケットとの組合せによって特定される通信経路が、当該通信経路によって通信されるパケットの配送先のサーバプロセスに関連付けられる。

ソケット管理データに含まれるプロセスＩＤには、当該ソケット管理データに対応付けられるプロセスの識別情報であるプロセスＩＤが設定される。ここでは、サーバプロセスＳ１のプロセスＩＤが１であることとする。

ソケット管理データに含まれるプロトコルデータは、当該ソケット管理データに対応付けられる通信経路での通信に用いられるプロトコルの種類を示すデータである。プロトコルデータの値の例としては、「ＴＣＰ」、「ＵＤＰ」などが挙げられる。

ソケット管理データのクライアントＩＰアドレス及びクライアントポート番号には、それぞれ、当該ソケット管理データに対応付けられるクライアントのＩＰアドレス及びポート番号が設定される。また、ソケット管理データのサーバソケットＩＰアドレス及びサーバソケットポート番号には、それぞれ、当該ソケット管理データに対応付けられるサーバのＩＰアドレス及びポート番号が設定される。

図３の例では、端末１０の通信相手である端末１２のＩＰアドレス及びポート番号が、それぞれ、当該ソケット管理データのクライアントＩＰアドレス、及び、クライアントポート番号の値に設定されている。また、端末１０のＩＰアドレス及びポート番号が、それぞれ、当該ソケット管理データのサーバＩＰアドレス、及び、サーバポート番号の値に設定されている。

なお、ハンドシェイクによる通信経路の確立に応じて、当該通信経路に対応付けられるソケット管理データが登録されてもよい。

端末１０と端末１２との間での一連の通信が行われた後、図４に示すように、ユーザＡが端末１０を操作することにより、端末１０でゲームプログラムＡｐｐ２がサーバモードで起動され、サーバプロセスＳ２が生成されることとする。このとき、動作状態であったサーバプロセスＳ１は待機状態に遷移する。そして、サーバプロセスＳ２は、動作状態での実行を開始する。また、端末１４でゲームプログラムＡｐｐ２がクライアントモードで起動され、クライアントプロセスＣ２が生成されることとする。そして、クライアントプロセスＣ２は、動作状態での実行を開始する。

ここで例えば、ゲームプログラムＡｐｐ２において予め設定されているポート番号が５００００であり、サーバプロセスＳ２が、サーバプロセスＳ１と同様に、ポート番号５００００にバインドされることとする。また、クライアントプロセスＣ２は、端末１４で動作するシステムプログラムによって動的に割り当てられるポート番号５２０００にバインドされることとする。

そして、端末１０と端末１４との間で通信が行われることにより、ユーザＡとユーザＣは、ゲームプログラムＡｐｐ２によって提供されるマルチプレイのゲームを楽しむことができる。

本実施形態では例えば、端末１０で動作するカーネルによって、互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスが検出される。そして、当該検出に応じて、当該複数の実行中のプロセスが動作状態であるか待機状態であるかを管理するための、図５に例示するサスペンド管理データが生成される。

サスペンド管理データには、例えば、端末１０で実行中であるサーバプロセスの識別情報であるプロセスＩＤ、当該サーバプロセスの待ち受けポート番号、及び、サスペンドフラグ、が含まれる。ここで、上述のようにサーバプロセスＳ１のプロセスＩＤは１であることとする。また、サーバプロセスＳ２のプロセスＩＤは２であることとする。

サスペンド管理データに含まれるサスペンドフラグには、当該サスペンド管理データに対応付けられるサーバプロセスが動作状態であるか待機状態であるかを示す値が設定される。例えば、サスペンド管理データに対応付けられるサーバプロセスが動作状態である際には、当該サスペンド管理データに含まれるサスペンドフラグには値０が設定される。また、サスペンド管理データに対応付けられるサーバプロセスが待機状態である際には、当該サスペンド管理データに含まれるサスペンドフラグには値１が設定される。

端末１０でサーバプロセスＳ２が生成され、動作状態であったサーバプロセスＳ１が待機状態に遷移すると、図５に示すように、プロセスＩＤの値が１であるサスペンド管理データ、及び、プロセスＩＤの値が２であるサスペンド管理データが端末１０に登録される。ここで、プロセスＩＤの値が１であるサスペンド管理データのサスペンドフラグの値は１に設定される。そして、プロセスＩＤの値が２であるサスペンド管理データのサスペンドフラグの値は０に設定される。

端末１０が、ゲームプログラムＡｐｐ２によって提供されるゲームがプレイされている際に、端末１４のポート番号５２０００を送信元とし、端末１０のポート番号５００００を宛先とするパケットを端末１４から受信したとする。そしてこのとき、図３に示すように、端末１４のＩＰアドレスやポート番号を含むソケット管理データが端末１０に登録されていないとする。

この場合、本実施形態では、端末１０は、図５に示すサスペンド管理データに基づいて特定される動作状態であるサーバプロセス（ここではサーバプロセスＳ２）を、受信した上述のパケットの配送先に決定する。そして、端末１０は、受信した上述のパケットをこのようにして決定されるサーバプロセスＳ２のソケットバッファに格納する。当該ソケットバッファは、端末１０によってカーネルメモリに動的に確保される。そして、サーバプロセスＳ２は、当該パケットに含まれるデータに応じた処理を実行する。このようにして、当該パケットは、動作状態であるサーバプロセスＳ２に配送される。

上述のように、サーバプログラムを起動することにより生成されるサーバプロセスの待ち受けポート番号は、当該サーバプログラムの開発者によって予め設定される。ここでサーバプログラムの開発者は他のサーバプログラムにおいて設定される待ち受けポート番号を事前に把握できない。そのため、サーバプロセスの待ち受けポート番号が複数のサーバプログラムにおいて重複することがある。

本実施形態では、複数のサーバプロセスにおいて待ち受けポート番号が重複していても、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御される。そして、重複する待ち受けポート番号が宛先である、端末１０が受信したパケットは、動作状態のサーバプロセスに配送される。このようにして本実施形態によれば、複数のサーバプロセスにおいて待ち受けポート番号が重複していても、当該待ち受けポート番号を宛先とするパケットを適切に配送できることとなる。

また、本実施形態において、サーバプロセスＳ１が待機状態である際に、端末１０が、端末１２のポート番号５１０００を送信元とし、端末１０のポート番号５００００を宛先とするパケットを端末１２から受信したとする。そしてこのとき図３に示す、端末１２のポート番号５１０００とサーバプロセスＳ１とが関連付けられたソケット管理データが端末１０に登録されているとする。

この場合、本実施形態では、端末１０は、受信したパケットを待機状態であるサーバプロセスＳ１に配送せずに破棄する。この場合は、サーバプロセスＳ１のソケットバッファに当該パケットが格納されない。このようにして、本実施形態によれば、カーネルメモリの使用量を抑制することができる。

本実施形態では、端末１４の５２０００番ポートが送信元であり端末１０の５００００番ポートが宛先である最初のＴＣＰパケットを端末１０が受信した際に、図６に示すように、プロセスＩＤの値が２である新たなソケット管理データが端末１０に登録される。

その後、ユーザＡが端末１０を操作することにより、待機状態であったサーバプロセスＳ１が動作状態に復帰し、動作状態であったサーバプロセスＳ２が待機状態に遷移したとする。すると図７に示すように、プロセスＩＤの値が１であるサスペンド管理データのサスペンドフラグの値は０に変更され、プロセスＩＤの値が２であるサスペンド管理データのサスペンドフラグの値は１に変更される。

そして、ユーザＡとユーザＢは、ゲームプログラムＡｐｐ１によって提供されるマルチプレイのゲームを再開することができる。また、サーバプロセスＳ１が待機状態であった際に中断されていた端末１０と端末１２との通信は再開される。そのため、例えば通信ができないことによるＴＣＰ ＲＳＴパケット（リセットパケット）の送信が端末１２によって行われない程度の時間（例えば６０秒）以内にサーバプロセスＳ１が復帰すると、ユーザＡとユーザＢのユーザ体験は維持されることとなる。

本実施形態において、サーバプロセスＳ１が待機状態である際に、端末１０が、ソケット管理データにおいて待機状態であるサーバプロセスＳ１と関連付けられている送信元からＴＣＰ ＲＳＴパケットを受信したとする。この場合に、端末１０は、当該パケットを破棄せずに待機状態であるサーバプロセスＳ１に配送してもよい。

当該ＴＣＰ ＲＳＴパケットは、サーバプロセスＳ１が復帰するまでの間は、サーバプロセスＳ１のソケットバッファに格納される。そして、サーバプロセスＳ１が復帰すると、ソケットバッファに格納されたＴＣＰ ＲＳＴパケットに基づいて、サーバプロセスＳ１は、通信相手との通信を終了（リセット）する処理を実行する。

このようにすることで、サーバプロセスＳ１は、復帰した際に、通信相手との通信をリセットすべきであることを直ちに把握することが可能となる。そのため、ＴＣＰ ＲＳＴパケットを送信した通信相手からのパケットを待ち受けるためのリソースを節約することができる。

また、本実施形態において、サーバプロセスＳ１が待機状態である際に、端末１０が、ソケット管理データにおいて待機状態であるサーバプロセスＳ１と関連付けられている送信元からＴＣＰ ＦＩＮパケット（終了パケット）を受信したとする。この場合に、端末１０は、当該パケット及び送信元が同じである後続するパケットを破棄せずに待機状態であるサーバプロセスＳ１に配送してもよい。

これらのパケットは、サーバプロセスＳ１が復帰するまでの間は、サーバプロセスＳ１のソケットバッファに格納される。そして、サーバプロセスＳ１が復帰すると、ソケットバッファに格納されたこれらのパケットに基づいて、サーバプロセスＳ１は、通信相手から送信されたパケットをもれなく受信して、通信相手との通信を終了させることができる。

以下、本実施形態に係る端末１０の機能及び端末１０で実行される処理について、さらに説明する。

図８は、本実施形態に係る端末１０で実装される機能の一例を示す機能ブロック図である。なお、本実施形態に係る端末１０で、図８に示す機能のすべてが実装される必要はなく、また、図８に示す機能以外の機能が実装されていても構わない。

図８に示すように、端末１０には、機能的には例えば、サスペンド管理データ記憶部２０、ソケット管理データ記憶部２２、プロセス管理部２４、受信部２６、配送制御部２８、送信部３０、が含まれる。

サスペンド管理データ記憶部２０、ソケット管理データ記憶部２２は、記憶部１０ｂを主として実装される。プロセス管理部２４、配送制御部２８は、プロセッサ１０ａを主として実装される。受信部２６、送信部３０は、通信部１０ｃを主として実装される。

以上の機能は、コンピュータである端末１０にインストールされた、以上の機能に対応する指令を含むプログラムをプロセッサ１０ａで実行することにより実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介して端末１０に供給されてもよい。

また、端末１０では、上述のサーバプロセスＳ１やサーバプロセスＳ２などのプロセス３２が実行される。

サスペンド管理データ記憶部２０は、本実施形態では例えば、図５及び図７に例示されているサスペンド管理データを記憶する。

ソケット管理データ記憶部２２は、本実施形態では例えば、図３及び図６に例示されているソケット管理データを記憶する。

プロセス管理部２４は、本実施形態では例えば、端末１０で実行されるプロセス３２を管理する。プロセス管理部２４の機能は、例えば、オペレーティングシステムのカーネルで実装される。プロセス管理部２４は例えば、プロセス３２を起動したり停止したりする。

また、プロセス管理部２４は、互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスを検出する。そして、プロセス管理部２４は、検出されるこれら複数の実行中のサーバプロセスのうち、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御する。

ここで例えば、プロセス管理部２４が、新たなサーバプロセスが生成される際に、当該サーバプロセスが動作状態になるように制御し、当該サーバプロセスと待ち受けポート番号が同じである動作状態のサーバプロセスを待機状態に遷移させてもよい。

例えば、プロセス管理部２４がサーバプログラムを起動することで新たなサーバプロセスが生成されたとする。以下、当該サーバプロセスを新規サーバプロセスと呼ぶこととする。この場合、プロセス管理部２４は、新規サーバプロセスと待ち受けポート番号が同じである動作状態のサーバプロセスが存在するか否かを確認する。以下、当該サーバプロセスを重複サーバプロセスと呼ぶこととする。ここで、このような重複サーバプロセスが存在する場合は、当該重複サーバプロセスを待機状態に遷移させる。そして、プロセス管理部２４は、新規サーバプロセスの動作状態での実行を開始させる。

なお、新規サーバプロセスと待ち受けポート番号が異なる動作状態のサーバプロセスが存在していても問題はない。この場合は、当該サーバプロセスと新規サーバプロセスの両方が動作状態となる。

また、プロセス管理部２４は、待機状態であるサーバプロセスの指定に応じて、当該サーバプロセスを動作状態に遷移させるとともに、当該サーバプロセスと待ち受けポート番号が同じである動作状態のサーバプロセスを待機状態に遷移させてもよい。

例えば、ユーザによって待機状態のサーバプロセスを指定する操作に応じて、当該サーバプロセスを動作状態に遷移させる。このとき、プロセス管理部２４は、動作状態に復帰したサーバプロセスと待ち受けポート番号が同じである、動作状態のサーバプロセスを待機状態に遷移させる。このようにして、待ち受けポート番号が同じである複数の実行中のサーバプロセスは、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御される。

また、プロセス管理部２４は、上述した、待ち受けポート番号が同じである複数の実行中のサーバプロセスの検出に応じて、サスペンド管理データを生成する。そしてプロセス管理部２４は、生成されたサスペンド管理データをサスペンド管理データ記憶部２０に記憶させる。例えば上述の重複サーバプロセスが存在することが確認された際に、サスペンドデータ管理データが生成されてもよい。

また、プロセス管理部２４は、プロセス３２の状態の変化に応じて、サスペンド管理データ記憶部２０に記憶されるサスペンド管理データの追加、削除、更新などといった、サスペンド管理データの管理を実行する。例えば、サーバプロセスが動作状態から待機状態に遷移した際に、当該サーバプロセスに対応するサスペンド管理データのサスペンドフラグの値は０から１に変更される。逆に、サーバプロセスが待機状態から動作状態に遷移した際に、当該サーバプロセスに対応するサスペンド管理データのサスペンドフラグの値は１から０に変更される。

受信部２６は、本実施形態では例えば、端末１２又は端末１４から送信されるパケットを受信する。

配送制御部２８は、本実施形態では例えば、受信部２６が受信するパケットをどのサーバプロセスに配送するかを制御する。配送制御部２８の機能は、例えば、オペレーティングシステムのカーネルで実装される。配送制御部２８は、例えば、複数のサーバプロセスで重複している待ち受けポート番号が宛先であるパケットを動作状態のサーバプロセスに配送する。ここで例えば、配送制御部２８が、ソケット管理データに登録されていない送信元から受信するパケットを、動作状態のサーバプロセスに配送してもよい。

また、配送制御部２８は、新たな通信経路を用いた通信の発生に応じて、当該通信経路に対応付けられるソケット管理データを生成する。そして、配送制御部２８は、生成されたソケット管理データをソケット管理データ記憶部２２に記憶させる。

配送制御部２８は、ソケット管理データにおいて待機状態のサーバプロセスと関連付けられている送信元から受信するパケットを破棄してもよい。

ここで、配送制御部２８は、上述のように、ソケット管理データにおいて待機状態のサーバプロセスと関連付けられている送信元から受信するパケットがＴＣＰ ＲＳＴパケットである場合は当該パケットを破棄せずに当該サーバプロセスに配送してもよい。

また、配送制御部２８は、上述のように、ソケット管理データにおいて待機状態のサーバプロセスと関連付けられている送信元から受信するパケットがＴＣＰ ＦＩＮパケットである場合は当該パケットを破棄せずに当該サーバプロセスに配送してもよい。この場合、配送制御部２８は、送信元が同じである後続するパケットについても破棄せずに当該サーバプロセスに配送してもよい。

送信部３０は、本実施形態では例えば、端末１０で実行されているプロセス３２が出力するパケットを送信先である端末１２又は端末１４に送信する。

ここで、本実施形態に係る端末１０がサーバプログラムを起動することで新たなサーバプロセス（新規サーバプロセス）が生成された際に行われる処理の流れの一例を、図９に例示するフロー図を参照しながら説明する。

まず、プロセス管理部２４は、新規サーバプロセスと待ち受けポート番号が同じである、動作状態であるサーバプロセス（重複サーバプロセス）が存在するか否かを確認する（Ｓ１０１）。

重複サーバプロセスが存在することが確認された場合は（Ｓ１０１：Ｙ）、プロセス管理部２４は、確認された重複サーバプロセスを待機状態に遷移させる（Ｓ１０２）。

そして、プロセス管理部２４は、新規サーバプロセスに対応するサスペンド管理データを生成して、生成されたサスペンド管理データをサスペンド管理データ記憶部２０に記憶させる（Ｓ１０３）。当該サスペンド管理データのサスペンドフラグの値は０に設定される。

そして、プロセス管理部２４は、重複サーバプロセスに対応するサスペンド管理データがサスペンド管理データ記憶部２０に記憶されているか否かを確認する（Ｓ１０４）。

記憶されている場合は（Ｓ１０４：Ｙ）、プロセス管理部２４は、当該サスペンド管理データのサスペンドフラグの値を０から１に変更する（Ｓ１０５）。

記憶されていない場合は（Ｓ１０４：Ｎ）、プロセス管理部２４は、重複サーバプロセスに対応するサスペンド管理データを生成する。そして、プロセス管理部２４は、生成されたサスペンド管理データをサスペンド管理データ記憶部２０に記憶させる（Ｓ１０６）。この場合、生成されたサスペンド管理データのサスペンドフラグの値は１に設定される。

そして、プロセス管理部２４は、新規サーバプロセスの動作状態での実行を開始させて（Ｓ１０７）、本処理例に示す処理は終了される。

Ｓ１０１に示す処理で、重複サーバプロセスが存在しないことが確認されたとする（Ｓ１０１：Ｎ）。この場合も、プロセス管理部２４は、新規サーバプロセスの動作状態での実行を開始させて（Ｓ１０７）、本処理例に示す処理は終了される。

次に、本実施形態に係る端末１０の受信部２６がパケットを受信した際に行われる処理の流れの一例を、図１０Ａ及び図１０Ｂに例示するフロー図を参照しながら説明する。

まず、配送制御部２８が、受信部２６が受信したパケットの送信元のＩＰアドレス及びポート番号が登録されたソケット管理データが存在するか否かを確認する（Ｓ２０１）。ここでは例えば、受信したパケットの送信元のＩＰアドレス及びポート番号が、それぞれ、クライアントＩＰアドレスの値及びクライアントポート番号の値に設定されたソケット管理データがソケット管理データ記憶部２２に記憶されているか否かが確認される。

存在しない場合は（Ｓ２０１：Ｎ）、配送制御部２８は、サスペンド管理データ記憶部２０に記憶されているサスペンド管理データに基づいて、端末１０において動作状態であるサーバプロセスを特定する（Ｓ２０２）。

そして、配送制御部２８は、Ｓ２０２に示す処理で特定されたサーバプロセスに受信したパケットを配送して（Ｓ２０３）、本処理例に示す処理は終了される。

Ｓ２０１に示す処理で、受信部２６が受信したパケットの送信元のＩＰアドレス及びポート番号が登録されたソケット管理データの存在が確認されたとする（Ｓ２０１：Ｙ）。この場合は、配送制御部２８は、当該ソケット管理データに示されているサーバプロセスを特定する（Ｓ２０４）。

そして、配送制御部２８は、Ｓ２０４に示す処理で特定されたサーバプロセスが動作状態である否かを確認する（Ｓ２０５）。ここで、配送制御部２８は、サスペンド管理データ記憶部２０に記憶されているサスペンド管理データに基づいて、Ｓ２０４に示す処理で特定されたサーバプロセスが動作状態である否かを確認してもよい。

Ｓ２０４に示す処理で特定されたサーバプロセスが動作状態であることが確認された場合は（Ｓ２０５：Ｙ）、配送制御部２８は、Ｓ２０４に示す処理で特定されたサーバプロセスに受信したパケットを配送して（Ｓ２０３）、本処理例に示す処理は終了される。

Ｓ２０５に示す処理で、Ｓ２０４に示す処理で特定されたサーバプロセスが待機状態であることが確認されたとする（Ｓ２０５：Ｎ）。この場合は、配送制御部２８は、受信したパケットがＴＣＰ ＲＳＴパケットであるか否かを確認する（Ｓ２０６）。

ＴＣＰ ＲＳＴパケットである場合は（Ｓ２０６：Ｙ）、配送制御部２８は、Ｓ２０４に示す処理で特定された待機状態であるサーバプロセスに受信したパケットを配送して（Ｓ２０３）、本処理例に示す処理は終了される。

Ｓ２０６に示す処理で、受信したパケットがＴＣＰ ＲＳＴパケットでないことが確認されたとする（Ｓ２０６：Ｎ）。この場合は、配送制御部２８は、受信したパケットが、ＴＣＰ ＦＩＮパケット、又は、ＴＣＰ ＦＩＮパケットに後続するパケットであるか否かを確認する（Ｓ２０７）。

Ｓ２０７に示す処理で、受信したパケットが、ＴＣＰ ＦＩＮパケット、又は、ＴＣＰ
ＦＩＮパケットに後続するパケットであることが確認されたとする（Ｓ２０７：Ｙ）。この場合は、配送制御部２８は、Ｓ２０４に示す処理で特定された待機状態であるサーバプロセスに受信したパケットを配送して（Ｓ２０３）、本処理例に示す処理は終了される。

Ｓ２０７に示す処理で、受信したパケットが、ＴＣＰ ＦＩＮパケットでもＴＣＰ ＦＩＮパケットに後続するパケットでもないことが確認されたとする（Ｓ２０７：Ｎ）。この場合は、配送制御部２８は、受信したパケットを破棄して（Ｓ２０８）、本処理例に示す処理は終了される。

なお、本発明は上述の実施形態に限定されるものではない。

本発明の適用範囲は、ＴＣＰプロトコルやＵＤＰプロトコルには限定されない。また、本発明の適用範囲は、ゲームプログラムには限定されない。

また、端末１０、端末１２、端末１４の役割分担は上述のものに限定されない。例えば、端末１２や端末１４に端末１０の機能が実装されてもよい。また、端末１０に端末１２や端末１４の機能が実装されてもよい。すなわち、端末１０において、クライアントプロセスが実行されてもよい。また、端末１２及び端末１４において、サーバプロセスが実行されてもよい。また、端末１０、端末１２、端末１４において、サーバプロセスとクライアントプロセスの両方が実行されてもよい。

また、端末１０のクライアントプロセスと端末１２あるいは端末１４のサーバプロセスとが通信してもよい。また、端末１２のクライアントプロセスと端末１４のサーバプロセスとが通信してもよい。また、端末１４のクライアントプロセスと端末１２のサーバプロセスとが通信してもよい。

また、上記の具体的な文字列や数値及び図面中の具体的な文字列や数値は例示であり、これらの文字列や数値には限定されない。

Claims (9)

1. 互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスを検出する検出部と、
   検出される前記複数の実行中のサーバプロセスのうち、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御するプロセス制御部と、
   前記待ち受けポート番号が宛先であるパケットを受信する受信部と、
   受信する前記パケットを前記動作状態の前記サーバプロセスに配送する配送制御部と、
   を含むことを特徴とする配送制御装置。
2. パケットの送信元と当該パケットの配送先である前記サーバプロセスとが関連付けられたソケット管理データを記憶するソケット管理データ記憶部、をさらに含み、
   前記配送制御部は、前記ソケット管理データに登録されていない送信元から受信するパケットを、前記動作状態の前記サーバプロセスに配送する、
   ことを特徴とする請求項１に記載の配送制御装置。
3. 前記配送制御部は、前記ソケット管理データにおいて前記待機状態の前記サーバプロセスと関連付けられている送信元から受信するパケットを破棄する、
   ことを特徴とする請求項２に記載の配送制御装置。
4. 前記配送制御部は、前記パケットがＴＣＰ ＲＳＴパケットである場合は当該パケットを破棄せずに当該サーバプロセスに配送する、
   ことを特徴とする請求項３に記載の配送制御装置。
5. 前記配送制御部は、前記パケットがＴＣＰ ＦＩＮパケットである場合は当該パケット及び送信元が同じである後続するパケットを破棄せずに当該サーバプロセスに配送する、
   ことを特徴とする請求項３又は４に記載の配送制御装置。
6. 前記プロセス制御部は、新たな前記サーバプロセスが生成される際に、当該サーバプロセスが動作状態になるように制御し、当該サーバプロセスと待ち受けポート番号が同じである動作状態の前記サーバプロセスを待機状態に遷移させる、
   ことを特徴とする請求項１から５のいずれか一項に記載の配送制御装置。
7. 前記プロセス制御部は、待機状態である前記サーバプロセスの指定に応じて、当該サーバプロセスを動作状態に遷移させるとともに、当該サーバプロセスと待ち受けポート番号が同じである動作状態の前記サーバプロセスを待機状態に遷移させる、
   ことを特徴とする請求項１から６のいずれか一項に記載の配送制御装置。
8. 互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスを検出するステップと、
   検出される前記複数の実行中のサーバプロセスのうち、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御するステップと、
   前記待ち受けポート番号が宛先であるパケットを受信するステップと、
   受信する前記パケットを前記動作状態の前記サーバプロセスに配送するステップと、
   を含むことを特徴とする配送制御方法。
9. 互いに異なるサーバプログラムを起動することにより生成される、待ち受けポート番号が同じである複数の実行中のサーバプロセスを検出する手順、
   検出される前記複数の実行中のサーバプロセスのうち、１つのサーバプロセスが動作状態になり、残りのサーバプロセスが待機状態になるよう制御する手順、
   前記待ち受けポート番号が宛先であるパケットを受信する手順、
   受信する前記パケットを前記動作状態の前記サーバプロセスに配送する手順、
   をコンピュータに実行させることを特徴とする配送制御プログラム。

Images