(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023020822
(43)【公開日】2023-02-09
(54)【発明の名称】通信管理プログラム、情報処理装置及び通信管理方法
(51)【国際特許分類】
G06F 13/10 20060101AFI20230202BHJP
G06F 13/38 20060101ALI20230202BHJP
G06F 9/52 20060101ALI20230202BHJP
【ＦＩ】
G06F13/10 330A
G06F13/38 310A
G06F9/52 150Z
【審査請求】未請求
【請求項の数】6
【出願形態】ＯＬ
(21)【出願番号】P 2021199095
(22)【出願日】2021-12-08
(62)【分割の表示】P 2021125358の分割
【原出願日】2021-07-30
(71)【出願人】
【識別番号】308020799
【氏名又は名称】株式会社ソフトギア
(74)【代理人】
【識別番号】100180758
【弁理士】
【氏名又は名称】荒木 利之
(72)【発明者】
【氏名】宮永 直樹
【テーマコード（参考）】
5B077
【Ｆターム（参考）】
5B077DD04
(57)【要約】 （修正有）
【課題】アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化する情報処理装置、通信管理プログラム及び方法を提供する。
【解決手段】通信管理システムにおいて、サーバ装置１は、１以上のイベントをノンブロッキングに蓄積するバッファリング手段１０６と、フラグを立てるフラグ管理手段１０７と、蓄積したイベントの処理を要求するソケット書込要求手段１０２ａと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段１０２ｂとを有する。フラグ管理手段は、イベントの処理の開始のタイミングで排他的にフラグを立て、コールバック処理手段１０２ｂの終了のタイミングでフラグを解除する。ソケット書込手段１０２は、バッファリング手段に対する蓄積及びコールバック処理手段の終了のタイミングで呼び出しを受け付けて、フラグが立てられた場合はバッファリング手段が蓄積したイベントを処理する。
【選択図】図２
【解決手段】通信管理システムにおいて、サーバ装置１は、１以上のイベントをノンブロッキングに蓄積するバッファリング手段１０６と、フラグを立てるフラグ管理手段１０７と、蓄積したイベントの処理を要求するソケット書込要求手段１０２ａと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段１０２ｂとを有する。フラグ管理手段は、イベントの処理の開始のタイミングで排他的にフラグを立て、コールバック処理手段１０２ｂの終了のタイミングでフラグを解除する。ソケット書込手段１０２は、バッファリング手段に対する蓄積及びコールバック処理手段の終了のタイミングで呼び出しを受け付けて、フラグが立てられた場合はバッファリング手段が蓄積したイベントを処理する。
【選択図】図２
【特許請求の範囲】
【請求項1】
コンピュータを、
１以上のイベントを蓄積するバッファリング手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する通信管理プログラム。
１以上のイベントを蓄積するバッファリング手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する通信管理プログラム。
【請求項2】
前記バッファリング手段は、ノンブロッキングキューに前記イベントを蓄積する請求項１に記載の通信管理プログラム。
【請求項3】
前記バッファリング手段は、メモリプールに前記イベントを蓄積する請求項１又は２に記載の通信管理プログラム。
【請求項4】
前記バッファリング手段は、リングバッファに前記イベントを蓄積する請求項１又は２に記載の通信管理プログラム。
【請求項5】
１以上のイベントを蓄積するバッファリング手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
【請求項6】
情報を処理するコンピュータにおいて、
１以上のイベントをノンブロッキングに蓄積するバッファリングステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップと、
前記イベントの処理を要求する処理要求ステップと、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを有し、
前記フラグ管理ステップは、前記処理要求ステップによる要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理ステップのイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求ステップは、前記バッファリングステップに対する蓄積及び前記コールバック処理ステップの終了のタイミングで呼び出しを受け付けて、前記フラグ管理ステップのフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリングステップが蓄積した前記イベントを処理する通信管理方法。
１以上のイベントをノンブロッキングに蓄積するバッファリングステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップと、
前記イベントの処理を要求する処理要求ステップと、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを有し、
前記フラグ管理ステップは、前記処理要求ステップによる要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理ステップのイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求ステップは、前記バッファリングステップに対する蓄積及び前記コールバック処理ステップの終了のタイミングで呼び出しを受け付けて、前記フラグ管理ステップのフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリングステップが蓄積した前記イベントを処理する通信管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信管理プログラム、情報処理装置及び通信管理方法に関する。
【背景技術】
【0002】
従来の技術として、データの大きさに応じて使用するバッファを変更してデータを送信する情報処理装置が提案されている（例えば、特許文献１参照）。
【0003】
特許文献１に開示された情報処理装置のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）は、アプリケーションバッファエリアを占有するアプリケーションタスクとリングバッファエリアを占有するＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）タスクとを並列的に実行する。アプリケーションタスクは、データ生成処理によってアプリケーションバッファエリアに格納されたデータのサイズが閾値以下であるか否かを判別し、判別結果が肯定的であるときアプリケーションバッファエリア上のデータをリングバッファエリアに複製してデータ送信指示を発行する一方、判別結果が否定的であるときアプリケーションバッファエリアの占有権をＴＣＰ／ＩＰタスクに一時的に付与してデータ送信指示を発行する。ＴＣＰ／ＩＰタスクは、自ら占有するメモリエリア上の送信データをデータ送信指示に応答して送信する。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０１０－５５２１４号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかし、特許文献１の情報処理装置は、送信するデータ量が少ない場合はリングバッファを用いてデータを送信して、アプリケーションタスクを並列して行い、送信するデータ量が多い場合はＴＣＰ／ＩＰタスクを専有的に処理することで通信速度の高速化を図るものの、送信するデータ量が多い場合はアプリケーションタスクがブロッキングされて処理されない、という問題がある。
【0006】
従って本発明の目的は、アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化する通信管理プログラム、情報処理装置及び通信管理方法を提供することにある。
【課題を解決するための手段】
【0007】
本発明の一態様は、上記目的を達成するため、以下の通信管理プログラム、情報処理装置及び通信管理方法を提供する。
【0008】
［１］コンピュータを、
１以上のイベントを蓄積するバッファリング手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する通信管理プログラム。
［２］前記バッファリング手段は、ノンブロッキングキューに前記イベントを蓄積する前記［１］に記載の通信管理プログラム。
［３］前記バッファリング手段は、メモリプールに前記イベントを蓄積する前記［１］又は［２］に記載の通信管理プログラム。
［４］前記バッファリング手段は、リングバッファに前記イベントを蓄積する前記［１］又は［２］に記載の通信管理プログラム。
［５］１以上のイベントを蓄積するバッファリング手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
［６］情報を処理するコンピュータにおいて、
１以上のイベントをノンブロッキングに蓄積するバッファリングステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップと、
前記イベントの処理を要求する処理要求ステップと、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを有し、
前記フラグ管理ステップは、前記処理要求ステップによる要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理ステップのイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求ステップは、前記バッファリングステップに対する蓄積及び前記コールバック処理ステップの終了のタイミングで呼び出しを受け付けて、前記フラグ管理ステップのフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリングステップが蓄積した前記イベントを処理する通信管理方法。
１以上のイベントを蓄積するバッファリング手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する通信管理プログラム。
［２］前記バッファリング手段は、ノンブロッキングキューに前記イベントを蓄積する前記［１］に記載の通信管理プログラム。
［３］前記バッファリング手段は、メモリプールに前記イベントを蓄積する前記［１］又は［２］に記載の通信管理プログラム。
［４］前記バッファリング手段は、リングバッファに前記イベントを蓄積する前記［１］又は［２］に記載の通信管理プログラム。
［５］１以上のイベントを蓄積するバッファリング手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段と、
前記イベントの処理を要求する処理要求手段と、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段として機能させ、
前記フラグ管理手段は、前記処理要求手段による要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
［６］情報を処理するコンピュータにおいて、
１以上のイベントをノンブロッキングに蓄積するバッファリングステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップと、
前記イベントの処理を要求する処理要求ステップと、
前記イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを有し、
前記フラグ管理ステップは、前記処理要求ステップによる要求で前記イベントの処理が開始されたタイミングで排他的にフラグを立て、前記コールバック処理ステップのイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求ステップは、前記バッファリングステップに対する蓄積及び前記コールバック処理ステップの終了のタイミングで呼び出しを受け付けて、前記フラグ管理ステップのフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリングステップが蓄積した前記イベントを処理する通信管理方法。
【発明の効果】
【0009】
請求項１、５、６に係る発明によれば、アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化することができる。
請求項２に係る発明によれば、ノンブロッキングキューにイベントを蓄積することができる。
請求項３に係る発明によれば、メモリプールにイベントを蓄積することができる。
請求項４に係る発明によれば、リングバッファにイベントを蓄積することができる。
請求項２に係る発明によれば、ノンブロッキングキューにイベントを蓄積することができる。
請求項３に係る発明によれば、メモリプールにイベントを蓄積することができる。
請求項４に係る発明によれば、リングバッファにイベントを蓄積することができる。
【図面の簡単な説明】
【0010】
【0011】
【0012】
この通信管理システムは、情報処理装置としてのサーバ装置１と、クライアントとしての端末装置２ａ、２ｂ、２ｃとをネットワークによって互いに通信可能に接続することで構成される。通信管理システムに含まれる装置は、パソコン、ゲーム端末、クラウド、仮想マシンであってもよい。ネットワークは、ＬＡＮやインターネットであってもよいし、仮想ネットワークなどであってもよい。
【0013】
サーバ装置１は、サーバ型の情報処理装置であり、操作者の操作する端末装置２ａ、２ｂ、２ｃの要求に応じて動作するものであって、本体内に情報を処理するための機能を有するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はフラッシュメモリ、揮発性メモリ、ＬＡＮボード（無線／有線）等の電子部品を備える。サーバ装置１は、端末装置２ａ、２ｂ、２ｃと通信し、データの送受信を行うことで端末装置２ａ、２ｂ、２ｃ上で扱うデータの同期を行うものであって、例えば、ゲームサーバ等である。サーバ装置１は、同期動作を行う場合は容量の小さいデータを頻繁にやりとりするものであるが、これに限られるものではない。なお、サーバ装置１は、複数のクラスタによって構成してもよく、分散処理を実行するよう構成してもよい。あるいは、クラウド環境において仮想マシンとして構成してもよい。
【0014】
端末装置２ａ、２ｂ、２ｃは、端末型の情報処理装置であり、プログラムに基づいて動作するものであって、本体内に情報を処理するための機能を有するＣＰＵやＨＤＤ又はフラッシュメモリ等の電子部品を備える。端末装置２ａ、２ｂ、２ｃは、例えば、ＭＭＯＧ（Ｍａｓｓｉｖｅｌｙ Ｍｕｌｔｉｐｌａｙｅｒ Ｏｎｌｉｎｅ Ｇａｍｅ）等のプログラムに基づいて動作し、動作の結果としてデータをサーバ装置１に対して逐次出力するとともに、サーバ装置１から他の端末の動作の結果としてのデータを受信して各端末装置２ａ、２ｂ、２ｃ間で高頻度にゲームオブジェクトを同期するものである。なお、端末装置２ａ、２ｂ、２ｃは３つの装置で描かれているが単一あるいは２個の装置であってもよいし、４以上の装置で構成してもよく、好ましくは、１０００台オーダーの端末装置が接続されるような場合であっても通信可能な構成を提供する。
【0015】
ネットワーク４は、高速通信が可能な通信ネットワークであり、例えば、イントラネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の有線又は無線の通信網である。
【0016】
一例として、本実施の形態における通信管理システムにおいて、複数の参加者が共通の仮想空間における活動、例えばゲームを行う多人数参加型ゲームが実行される。サーバ装置１及び端末装置２ａ、２ｂ、２ｃは、ゲームの進行に伴い各装置内でオブジェクトとして保持している情報（同期対象オブジェクト）を、各装置間で同期するために動作し、特にサーバ装置１は、データ通信を高速化すべくアプリケーションとＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）との間にバッファを設けてアプリケーションとＮＩＣ間のデータ授受の動作を制御する。言い換えれば、マルチプロセス、マルチスレッドが、共有リソース（ソケットやＮＩＣ）に非同期に書き込む要求が大量に発生する場合、データが混ざらないようにシリアライズするには、排他制御が必要となるため、送信通信路を効率よく使用（特に、送信通路がデータで混雑してからのスループット向上）するために、バッファにバッファリングして、当該バッファへの書込で排他制御（ブロッキング）を行い、当該バッファからの共有リソースへの書込はＣＡＳ（Ｃｏｍｐａｒｅ ａｎｄ Ｓｗａｐ）等でロックフリー（ノンブロッキング）な制御をする。動作の詳細について、実施の形態において具体的に説明する。
【0017】
また、本実施の形態において使用する「オブジェクト」等の語句は、例えば、Ｊａｖａ（登録商標）、Ｃ＋＋、Ｃ＃、Ｐｙｔｈｏｎ、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｒｕｂｙ等で用いられる同語句と同義で用いられるが、以降、クラス、及びインスタンス化されたクラス（インスタンス）のことを総称して「オブジェクト」と言う場合がある。
【0018】
（サーバ装置の構成）
図２は、実施の形態に係るサーバ装置１の構成例を示すブロック図である。以下にサーバ装置１での実装について記述するが、端末装置２ａ、２ｂ、２ｃも同様な構成としてもよい。
図２は、実施の形態に係るサーバ装置１の構成例を示すブロック図である。以下にサーバ装置１での実装について記述するが、端末装置２ａ、２ｂ、２ｃも同様な構成としてもよい。
【0019】
サーバ装置１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等から構成され、各部を制御するとともに、各種のプログラムを実行する制御部１０と、フラッシュメモリ等の記憶媒体から構成され情報を記憶する記憶部１１と、揮発性記録媒体から構成され一時的に情報を記憶するメモリ１２と、ネットワークを介して外部と通信する通信部１３とを備える。
【0020】
制御部１０は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１１０を実行することで、ＯＳ実行手段１００（Ｊａｖａの場合はＪＶＭも含む）として機能し、アプリケーション１１２を実行することで、アプリケーション実行手段１０３、アプリケーション読出手段１０４、アプリケーション書込手段１０５として機能し、通信管理プログラムとしての通信管理プログラム１１１を実行することで、ソケット読出手段１０１、ソケット書込手段１０２、バッファリング手段１０６（受信バッファ１０６ａと送信バッファ１０６ｂを含む）、フラグ管理手段１０７等として機能する。
【0021】
ＯＳ実行手段１００（ＯＳカーネル）は、ＯＳ１１０を実行し、ＯＳ１１０が有する各機能を提供する。ＯＳ実行手段１００は、特に通信部１３（ＮＩＣ）を制御してネットワークにデータを送信し、ネットワークからデータを受信する。なお、ＪＡＶＡを利用している場合は、Ｊａｖａ ＶＭもＯＳの一部とみなし、ＯＳ実行手段１００によって実行されるものとする。
【0022】
アプリケーション実行手段１０３は、処理手段としてアプリケーション１１２を実行し、アプリケーション１１２が有する各機能を提供するものであり、実行に伴い単一又は複数のスレッドを処理する。典型的には、それぞれのスレッドは、単一又は複数の端末装置とそれぞれ対応する単一又は複数のソケット（端末装置２ａ、２ｂ、又は、２ｃの通信対象プログラムのＩＰアドレス及びポート番号）を介してネットワーク通信（送受信）を行う。
【0023】
アプリケーション読出手段１０４は、アプリケーション１１２が有する機能として特に、スレッドの受信処理のために受信対象となるソケット（端末装置２ａ、２ｂ、又は、２ｃ）に対応する受信バッファ１０６ａのデータを読み出す。
【0024】
アプリケーション書込手段１０５は、スレッドの処理の結果生成されたデータを送信対象となるソケット（端末装置２ａ、２ｂ、又は、２ｃ）に対応する送信処理のために送信バッファに書き込む。書き込まれたデータは書き込まれた順に送信バッファ１０６ｂに追加される。例えば、ゲームサーバがゲームオブジェクトの同期処理のため、同期情報のリレー処理を行う場合、アプリケーション書込手段１０５は、端末装置２ａから同期情報のデータ受信し、スレッドで受信データを処理した結果、端末装置２ｂ、および、２ｃに同期情報データを送信する。アプリケーション書込手段１０５は、それぞれの端末装置に対応する２個のソケットに対応する２個の送信バッファ１０６ｂにデータを書き込む。
【0025】
ソケット読出手段１０１は、ＯＳ１１０が有する機能として特に、ネットワークとの通信においてソケットによって受信したデータを後述する受信バッファ１０６ａに読み出す。
【0026】
処理手段としてのソケット書込手段１０２は、処理要求手段としてのソケット書込要求手段１０２ａとコールバック処理手段１０２ｂとして機能する。
【0027】
【0028】
ソケット書込要求手段１０２ａは、まず、フラグ管理手段１０７に依頼して、フラグ管理手段１０７の管理するフラグの状態を確認し（Ｓ１０）、フラグが解除されている場合（Ｓ１１；Ｙｅｓ）、フラグを立てる（Ｓ１２）。フラグが立てられると、次に、ソケット書込要求手段１０２ａは、ネットワークとの通信により送信するデータを送信バッファ１０６ｂからソケットに書き込んで、ＯＳ実行手段１００にイベントの処理を要求する（Ｓ１３）。もし、フラグ管理手段１０７の管理しているフラグがすでに立っている場合は（Ｓ１１；Ｎｏ）、処理を直ちに終了する。なお、ここでは理解の容易性のため、フラグの検査Ｓ１０／Ｓ１１とフラグの変更Ｓ１２を３個の別ブロックとして説明したが、マルチスレッド環境では、フラグの検査Ｓ１０とフラグのセットＳ１２の間に別スレッドがスイッチされて割り込むと、複数のスレッドそれぞれがフラグを立てた状態にして（Ｓ１２）、自分のスレッドがフラグを立てたつもりになってイベント処理（Ｓ１３）を実行するので、同時時期に、イベント処理（Ｓ１３）を複数回実行してしまう可能性があり不都合である。この問題を解決するために、本発明では、ブロッキングによってソケット書込手段１０２ａ実行を排他制御するかわりに、後述するようなフラグ管理手段１０７が提供するＣＡＳ（Ｃｏｍｐａｒｅ ａｎｄ ｓｗａｐ）の機能を利用して、フラグの検査（Ｓ１０／Ｓ１１）と変更設定（Ｓ１２）を単一のＣＰＵ命令で実行し、Ｓ１１とＳ１２の間に他のスレッドが実行されない工夫を行っている。
【0029】
コールバック処理手段１０２ｂは、ＯＳ実行手段１００がソケット書込要求手段１０２ａの書込イベントの処理を完了した場合に、ＯＳ実行手段１００から完了通知を受け付けて（非同期に）実行する。ＯＳ実行手段１００が実行したネットワーク送信結果を受け取る（Ｓ２０）。送信結果が正常の場合は（Ｓ２１；Ｙｅｓ）、コールバック処理手段１０２ｂは、送信完了分を送信バッファから除外する（Ｓ２２）。引き続き、コールバック処理手段１０２ｂは、フラグ管理手段１０７に依頼して、フラグを解除する（Ｓ２３）。引き続き、コールバック処理手段１０２ｂは、送信バッファに送信対象データが存在することを確認する（Ｓ２４）。確認結果が肯定的であれば（送信バッファにデータがあれば）（Ｓ２４；Ｙｅｓ）、コールバック処理手段１０２ｂは、ソケット書込要求手段１０２ａに呼び出しを行う（Ｓ２５）。確認結果が否定的であれば（Ｓ２４；Ｎｏ）、コールバック処理手段１０２ｂは、処理を終了する。送信結果が異常の場合は（Ｓ２１；Ｎｏ）、コールバック処理手段１０２ｂは、通信断、タイムアウトなどの例外処理（接続の切断など）を行う（Ｓ２６）。
【0030】
他の実装としては、以下のように構成してもよい。例えば、コールバック処理手段１０２ｂは、ＯＳ実行手段１００がソケット書込要求手段１０２ａの書込イベントの処理を完了した場合に完了通知を受け付けて（非同期に）実行された送信結果を受け取る。送信結果が異常の場合は、通信断、タイムアウトなどの例外処理（接続の切断など）を行い、終了する。送信結果が正常の場合は、送信完了分を送信バッファから削除する。引き続き、コールバック処理手段１０２ｂは、送信バッファに送信対象データが存在することを確認し、確認結果が肯定的であれば、ソケット書込要求手段１０２ａに呼び出しを行う。確認結果が否定的であれば、フラグ管理手段１０７に依頼して、フラグを解除して処理を終了する。
【0031】
バッファリング手段１０６は、メモリ１２に２種類のバッファ領域、受信バッファ１０６ａと送信バッファ１０６ｂを用意し、どちらも読み出し及び書き出しの対象を提供するとともに、読み出し及び書き出しをするデータを管理する。バッファを解することで読み出しと書き出しを非同期に行うことができる。受信バッファ１０６ａは、ソケット読出手段１０１が書き込み、アプリケーション読出手段１０４が読み出す。送信バッファ１０６ｂは、アプリケーション書込手段１０５が書き込み、ソケット書込手段１０２が読み出す。なお、バッファリング手段１０６（１０６ａおよび１０６ｂ）は、データをノンブロッキングに読み書きする。バッファに必要なメモリを都度実行時に割り当てるのはＣＰＵの効率が悪いので、事前に大きなメモリブロックを確保して、それを細分化したサブブロックのメモリをメモリープールとして独自のメモリ管理をし、使い回すのは一般的である。また、これらのサブブロックを組合せて、論理的にリングバッファを構成することも一般的である。ここでは、バッファ領域はメモリプールの一種であるリングバッファ１２１（受信バッファ１０６ａとして受信リングバッファ１２１ａ、及び、送信バッファ１０６ｂとして送信リングバッファ１２１ｂ）を用いた場合について説明するが、必ずしもリングバッファである必要はなく、論理的に無限長のバッファを提供できるバッファであればよく、好ましくはダイレクトバッファ等のヒープ領域外のメモリ領域に作成される高速に入出力が可能な一時記憶領域を用いる。ここで、メモリプールとは、コンピュータプログラムの実行時に素早く動的に必要なメモリ領域を確保するために、プログラムの起動時などにメインメモリの空き領域からある程度大きな領域を一括して確保したものとする。
【0032】
フラグ管理手段１０７は、例えば、ＣＡＳ（Ｃｏｍｐａｒｅ ａｎｄ Ｓｗａｐ）等の手段により、フラグをアトミックに管理する。ここでアトミックとは、不可分操作を指し、具体的には、あるメモリ位置の内容と指定された値を比較し、等しければそのメモリ位置に別の指定された値を格納することを１命令で行うＣＰＵの特別な命令を指す。具体的にフラグ管理手段１０７は、ソケット書込要求手段１０２ａの要求によりＯＳ実行手段１００がイベント処理を開始するタイミングで排他的にフラグを立て、イベントの処理の終了のタイミング（コールバック処理手段１０２ｂの処理）でフラグを解除する。前述のように、図６に示す動作をするので、フラグ管理手段１０７の機能により、ソケット書込要求手段１０２ａ及びコールバック処理手段１０２ｂは、ひとつのソケットについては、両手段あわせて高々１個しか同時には実行しないように制御され、ソケットへの書込操作の整合性が保証される。フラグを立てたソケット書込要求手段１０２ａ、または、当該書き込み要求手段１０２ａに対応するコールバック処理手段１０２ｂが処理中の場合は、２個目以降のソケット書込要求手段１０２ａの呼び出しは、フラグが立っている間は、フラグを自らが立てることができないので、処理を中断し、ＯＳ実行手段１００への書き込みを行わずに終了（図６のＳ１１；Ｎｏ）する。このため、ソケット書込要求手段１０２ａはノンブロッキングに実行する。
【0033】
記憶部１１は、制御部１０を上述した各手段１００－１０７として動作させるＯＳ１１０、通信管理プログラム１１１、アプリケーション１１２等を記憶する。なお、各手段１００～１０７として機能させるための対象は、ＯＳ１１０、通信管理プログラム１１１、アプリケーション１１２を適宜入れ替えて行うものであってもよい。また、記憶部は、リレーショナル・データベースやファイルシステムなどを用いる。なお、高速化のために、Ｒｅｄｉｓなどインメモリデータベースを利用、あるいは、併用してもよい。
【0034】
メモリ１２は、バッファリング手段１０６及びその他図示しない手段により制御され、情報を一時的に記憶する。
【0035】
なお、端末装置２ａ、２ｂ、２ｃは、サーバ装置１と同様の構成に加え、操作部及び表示部を備える。サーバ装置１と構成が共通する部分については説明を省略する。
【0036】
（情報処理装置の動作）
次に、本実施の形態の作用を、（１）基本動作、（２）データ送信動作に分けて説明する。
次に、本実施の形態の作用を、（１）基本動作、（２）データ送信動作に分けて説明する。
【0037】
（１）基本動作
一例として、複数のユーザが、複数のゲームオブジェクトを同期させて同一の仮想空間（ルーム）での体験（ゲームプレイ）を共有するために、同じ仮想空間に参加する。ゲームの進行は各端末装置２ａ、２ｂ、２ｃで行い、サーバ装置１は、ゲームの進行は行わず、オブジェクトの同期動作のみを行ってもよいし、サーバ装置１がゲームの進行も行ってもよい。
一例として、複数のユーザが、複数のゲームオブジェクトを同期させて同一の仮想空間（ルーム）での体験（ゲームプレイ）を共有するために、同じ仮想空間に参加する。ゲームの進行は各端末装置２ａ、２ｂ、２ｃで行い、サーバ装置１は、ゲームの進行は行わず、オブジェクトの同期動作のみを行ってもよいし、サーバ装置１がゲームの進行も行ってもよい。
【0038】
サーバ装置１の図示しない参加者管理手段は、ルームへの参加要求を受信すると、参加者に対してユーザＩＤ、ユーザ名、ソケットＩＤ、参加日時とともに記憶部１１の当該ルームＩＤに関連付けられた参加者管理情報に記録する。
【0039】
端末装置２ａ、２ｂ、２ｃは、ゲームのプレイ中は、プログラムの実行に伴い複数のオブジェクト（キャラクター、武器、アイテム等）を逐次生成、更新、削除して処理する。サーバ装置１は、ゲームの進行を行う場合、端末装置２ａ、２ｂ、２ｃによるオブジェクトの操作要求を受け付けて、処理し、その処理結果を端末装置２ａ、２ｂ、２ｃに通知することで、オブジェクトを同期させる。サーバ装置１は、ゲームの進行を行わない場合、端末装置２ａ、２ｂ、２ｃにおけるオブジェクトの同期のためのリレー動作を行う。当該リレー動作において、サーバ装置１は、複数のオブジェクトの送受信を行う。いずれの場合でも、サーバ装置は、端末装置２ａ、２ｂ、２ｃより、それぞれが操作する複数のオブジェクトの操作に関する情報を受信し、同期対象の端末装置に対応する複数のオブジェクト操作に関する情報を送信する。個々のオブジェクト操作情報のサイズは小さいが、各端末装置２ａ、２ｂ、２ｃにおいて、なめらかなオブジェクトの描画を実現するには他頻度なデータ同期（少なくても秒２０回から３０回程度）が必要となり、洗練されたゲームで同期対象のオブジェクトの数が多い場合、ＭＭＯＧなど同期対象の端末装置が多い場合、サーバが処理する同期のための送受信パケット数は組み合わせ爆発でストリーミング送受信のように莫大となりうる。近年ＣＰＵやメモリの高速化は著しいが、ネットワークの帯域幅、個々の端末とのスループットやレイテンシは、物理的・距離的制約や、モバイルからの利用形態などのトレンドもあり、高速化はよりゆるやかである。そのため、ネットワーク送受信はサーバでの処理において、ボトルネックとなりやすい。本発明では、ネットワーク送信の効率的な利用、ＮＩＣレベルで常に処理中で空き時間のなるべくないような利用方法、特に、Ｊａｖａを用いた実装で送信時のソケットの利用率の向上を実現する。以下、サーバ装置１の送受信の動作詳細について説明する。
【0040】
図３は、データ送受信の動作の一例を説明するための概略図である。
【0041】
まず、ネットワーク４からサーバ装置１がデータを受信する場合、ネットワーク４のソース１３１からあるチャネル１３０を介し、ソケット読出手段１０１がチャネルに対応するソケット（受信元端末装置に対応するあるＩＰアドレスのあるポート）によって受信したデータを読み出して受信リングバッファ１２１ａの書込ポインタの位置に書き込む。データは受信リングバッファ１２１ａに追加される。なお、バッファはチャネルあるいはソケットごとに別々に用意する。また、チャネル／ソケットは送受信共用で、対応する端末装置（端末装置の通信相手となる特定のプログラム）ごとに１つ用意する。アプリバッファは、１つで図示しているが、実際は送受信別に管理する。また、リングバッファは、プールとしては、全チャネルで１つとして管理されており、１つで図示しているが、リングバッファ１２１は、チャネルごと、送受信別々に、それぞれ独立なポインタの管理があり、チャネルごとに、別々の受信リングバッファ１２１ａ、送信リングバッファ１２１ｂとして区別する。
【0042】
次に、アプリケーション読出手段１０４は、受信元端末装置に対応（チャネルあるいはソケット）した受信リングバッファ１２１ａのデータを読出ポインタの位置から読み出してアプリバッファ１２０に書き込む。データは受信リングバッファ１２１ａから取り出され、受信リングバッファ１２１ａから除外される。ここでアプリバッファ１２０はアプリケーションが独自に管理するもので、バッファリング手段１０６が提供するものではない。アプリバッファは、別のバッファリング手段が提供する。たとえば、ＯＳ機能（通常のメモリ割当、メモリ解放）がアプリバッファを提供してもよい。メモリを再利用してメモリ管理を効率化するためには、バッファリング手段１０６同等の機能が提供するように別のバッファリング手段を構成して、アプリバッファを提供してもよい。
【0043】
アプリケーション実行手段１０３は、アプリバッファ１２０のデータを読み出してスレッドにて処理する。
【0044】
また、アプリケーション実行手段１０３のスレッドで処理されたデータをネットワーク４に送信する場合、アプリケーション実行手段１０３は、スレッドで処理されたデータをアプリバッファ１２０に書き込む。
【0045】
次に、アプリケーション書込手段１０５は、アプリバッファ１２０のデータを意図する送信先端末装置に応じて、送信先端末装置、より厳密には、チャネルあるいはソケットに対応する送信リングバッファ１２１ｂの書込ポインタの位置に書き込む。この結果、データは送信リングバッファ１２１ｂに追加される。データを書き込み終わると、書込ポインタを進めて、書込終了位置の次に移動する。次回、アプリケーション書込手段１０５がデータを書き込む時は、移動後の書込ポインタを使用するので、次回書き込むデータは、今回書き込んだデータの後ろに追加される。一方で、アプリバッファ１２０のデータは、送信リングバッファ１２１にコピーされた後は不要なり、アプリケーション実行手段１０３はこのバッファ領域を再利用できる。なお、送信リングバッファ１２１ｂはチャネルあるいはソケットごとに用意する。
【0046】
次に、ソケット書込手段１０２は、送信リングバッファ１２１ｂの読出ポインタの位置から書き出しポインタの位置の手前までのデータを読み出し、ソケットによってチャネル１３０に書き込む。データは、チャネル１３０を介してソース１３１に送信される。読出ポインタは、送信に成功したバイト数だけ進めて、送信が完了したデータの次の位置に移動する。この時、データは送信リングバッファ１２１ｂから取り出され、送信対象としてＯＳ実行手段１００が送信処理をし、送信が完了したデータ（取り出したデータの全部あるいは一部）については、送信リングバッファ１２１ｂから除外される。送信が完了しなかったデータについては、引き続き送信リングバッファ１２１ｂにとどまる。ここでは、送信リングバッファ１２１ｂに蓄積されたデータを全部一度に送信するものとしたが、送信リングバッファ１２１ｂに蓄積されているデータが巨大になった場合は、ＯＳ送信機能呼出の制限を考慮するなど、全部一度に読み出さず、一部だけを読み出して送信する制御をしてもよい。
【0047】
以下、アプリケーション実行手段１０３のスレッドで処理されたデータをＯＳ実行手段１００からネットワーク４に送信する場合について詳細に説明する。
【0048】
（２）データ送信動作
図４は、データ送信動作の一例を説明するための概略図である。
図４は、データ送信動作の一例を説明するための概略図である。
【0049】
アプリケーション実行手段１０３は、例えば、複数のスレッド１、スレッド２によりデータを処理し、処理結果のデータＡ、データＢを同一の端末装置（より厳密には、同一のソケットあるいはチャネル）に送信するために、アプリケーション書込手段１０５により送信先端末へ通信するソケットに対応する送信リングバッファ１２１ｂに書き込まれる。スレッド１、スレッド２の処理は非同期に発生するものとする。アプリケーション書込手段１０５は、データＡ、データＢをチャネル毎に最大１つのデータ書込だけ実行するようブロッキング制御し、アプリケーション書込手段１０５がスレッド１のデータＡを送信リングバッファ１２１ｂに書き込んでいる間、スレッド２のデータＢの書込処理を待機させる。同様にアプリケーション書込手段１０５がスレッド２のデータＢを送信リングバッファ１２１ｂに書き込んでいる間、スレッド１はデータＣの書込処理を待機させる。送信リングバッファ１２１ｂへの書込は、書込ポインタの位置から開始し、書込終了時には書込ポインタを書込終了位置の次に移動させる。ここでは説明の簡単のために、スレッド間の書込操作が送信リングバッファ１２１ｂで混ざらないようにブロッキング制御を行う、送信バッファ１０６ｂとして、ノンブロッキングなバッファを採用すれば、さらにアプリケーション書込手段１０５は効率的に機能する。
【0050】
次に、ソケット書込要求手段１０２ａは、フラグ管理手段１０７のＣＡＳフラグを参照し、フラグが立っていない場合、フラグを立てて、ＯＳシステムコール（例えばＪＡＶＡのＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（））呼び出しを行い、送信リングバッファ１２１ｂに蓄積されているデータ（読出しポインタから呼出時点での書込ポインタの一つ前までのデータ）を送信する。この時点では送信リングバッファ１２１ｂにはデータＡのみ蓄積されている。ソケット書込要求手段１０２ａは、送信リングバッファ１２１のデータＡをＯＳ実行手段１００（ＯＳカーネル）に書き込み要求をして完了する（１）。
【0051】
次に、ＯＳカーネル１００は、データＡを適切なサイズ（サイズは、例えば、ネットワーク依存の送信可能な最大パケットサイズＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ、イーサネットならＭＴＵは１５００バイト）と各種プロトコルヘッダに応じて決定する。典型的には、イーサネットでＴＣＰ／ＩＰであれば、ＴＣＰヘッダ２０バイトとＩＰヘッダ２０バイトを差し引いたＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）１４６０バイト）に分割してデータＡ１、Ａ２としてネットワーク４に送信する。ＯＳカーネル１００のイベント処理中に、アプリケーション書込手段１０５から送信リングバッファ１２１ｂにデータＢを書き込むと送信リングバッファ１２１ｂは、ＯＳカーネル１００が読取処理をしている最中ではあっても、データＢをノンブロッキングに蓄積する。アプリケーション書込手段１０５は、引き続きソケット書込要求手段１０２ａを呼び出すが、ソケット書込要求手段１０２ａはデータＡの処理中でフラグ管理手段１０７のＣＡＳフラグが立っているのでソケット書込要求手段１０２ａはデータＢの送信処理をせずに、ノンブロッキングに直ちに終了する（２）。スレッド２は、比較的長時間のネットワーク送信処理（ＯＳカーネル１００のイベント処理）の完了を待たずに次の処理を実行できる。この時点で、送信リングバッファ１２１ｂには、データＢが追加され、データＡとデータＢが存在する。
【0052】
次に、ＯＳカーネル１００は、データＡの送信を完了するとコールバック処理手段１０２ｂを起動して、送信完了を通知する。コールバック処理手段１０２ｂは、送信完了したバイト数を確認し、この場合はデータＡ全体が送信完了しているので、送信リングバッファ１２１ｂの読出ポインタをデータＡの直後へ移動し、データＡを送信リングバッファ１２１ｂから除外する。次に、コールバック処理手段１０２ｂは、フラグ管理手段１０７のＣＡＳフラグを解除する。この時点で、送信リングバッファ１２１ｂは、データＡが除外され、データＢのみが存在する。次に、コールバック処理手段１０２ｂは、送信リングバッファ１２１ｂにまだ送信すべきデータがあるか（読出ポインタと書込ポインタが一致していれば送信すべきデータはない）を判定する。送信すべきデータがある場合は、ソケット書込要求手段１０２ａを呼び出す。送信すべきデータがない場合は終了する。この場合はすでに、データＢが送信リングバッファ１２１ｂに存在しているので、ソケット書込要求手段１０２ａを呼び出す（３）。
【0053】
次に、ソケット書込要求手段１０２ａは、フラグ管理手段１０７に依頼して、ＣＡＳフラグを参照し、フラグが立っていないので、フラグを立てて、ＯＳシステムコール（ＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（））呼び出しを行い、送信リングバッファ１２１ｂに蓄積されているデータ（読出しポインタから呼出時点での書込ポインタの一つ前までのデータ）を送信する。この時点では送信リングバッファ１２１ｂにデータＢのみ蓄積されている。ソケット書込要求手段１０２ａは、送信リングバッファ１２１ｂのデータＢをＯＳカーネル１００に書き込み要求をして終了する。
【0054】
次に、ＯＳカーネル１００は、データＢを適切なサイズに分割してデータＢ１、Ｂ２、Ｂ３としてネットワーク４に送信する。ＯＳカーネル１００のイベント処理中に、アプリケーション書込手段１０５から送信リングバッファ１２１ｂにデータＣを書き込むと送信リングバッファ１２１ｂはデータＣをノンブロッキングに蓄積し、ソケット書込要求手段１０２ａを呼び出すが、ソケット書込手段１０２は、直前のソケット書込要求手段１０２ａがＯＳに依頼したデータＢの処理中で、フラグ管理手段１０７のＣＡＳフラグが立っているのでソケット書込要求手段１０２ａはデータＣの送信処理をＯＳカーネル１００に依頼せずに直ちに終了する（４）。また、同様にして、アプリケーション書込手段１０５からリングバッファ１２１にデータＤを書き込むとリングバッファ１２１はデータＤをノンブロッキングに蓄積し、ソケット書込要求手段１０２ａを呼び出すが、ソケット書込手段１０２はデータＢの処理中でフラグ管理手段１０７のＣＡＳフラグが立っているのでソケット書込要求手段１０２ａはデータＤの送信処理をせずに直ちに終了する（５）。この時点では送信リングバッファ１２１ｂにデータＢ、データＣ、データＤが順番に蓄積されている。
【0055】
次に、ＯＳカーネル１００は、データＢの送信を完了するとコールバック処理手段１０２ｂを起動して、送信完了を通知する。コールバック処理手段１０２ｂは、まず、送信完了バイト数がデータＢ全体であることを確認した上で、送信リングバッファ１２１ｂの読出ポインタをデータＢの次の位置（この場合はデータＣの先頭）に移動する。この時点では送信リングバッファ１２１ｂは、データＢが除外されて、データＣとデータＤを蓄積している。コールバック処理手段１０２ｂは、次に、フラグ管理手段１０７のＣＡＳフラグを解除して、その次に、送信リングバッファ１２１ｂは空でない（この場合はデータＣおよびデータＤが蓄積されている）ことを確認して、ソケット書込要求手段１０２ａを呼び出す。
【0056】
次に、ソケット書込要求手段１０２ａは、フラグ管理手段１０７のＣＡＳフラグを参照し、フラグが立っていないので、フラグを立てて、ＯＳシステムコール（ＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（））呼び出しを行い、送信リングバッファ１２１ｂのデータＣとデータＤをＯＳカーネル１００に書き込む（６）。
【0057】
次に、ＯＳカーネル１００は、データＣ及びデータＤを適切なサイズに分割してデータＣ１、Ｃ２、Ｃ３、…としてネットワーク４に送信する。ＯＳカーネル１００のイベント処理中に、アプリケーション書込手段１０５から送信リングバッファ１２１ｂにデータＥを書き込むと、送信リングバッファ１２１ｂはデータＥをノンブロッキングに蓄積するが、ソケット書込要求手段１０２ａの呼出はフラグ管理手段１０７のＣＡＳフラグが立っているのでソケット書込要求手段１０２ａはデータＥの送信処理をせずに終了する（７）。また、同様にしてアプリケーション書込手段１０５から送信リングバッファ１２１ｂにデータＦを書き込むと、送信リングバッファ１２１ｂはデータＦをノンブロッキングに蓄積する（８）。この時点で送信リングバッファ１２１ｂはデータＣ、データＤ、データＥ、データＦを蓄積している。
【0058】
次に、ＯＳカーネル１００は、データＣの送信を完了すると、今回はたまたまＤの処理を完了せずに、コールバック処理手段１０２ｂを起動して、送信完了を通知する。一般にＯＳシステムコール（ＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（））は必ずしも要求したデータすべての送信を完了することを保証しない。したがって、送信完了したバイト数の確認は必須である。この例では、偶然データＣの全体の送信終了を通知したが、ＯＳカーネル１００にとってはデータＣとデータＤは連続したブロックで、別のデータであるかどうかの区別はしていないので、データＣを送りきったのは全くの偶然で、データＣの送信中、データＣの一部を残して送信を終了する場合もある。例えば、Ｃ１とＣ２を送信完了して、Ｃ３を残す場合とか、Ｃ１とＣ２に加えてＣ３の前半まで送信完了して、Ｃ３の後半を残す場合とかも考えられる。コールバック処理手段１０２ｂは、まず、送信完了したバイト数を確認し、この場合は、データＣのみが全部送信完了であるので、送信リングバッファ１２１ｂの読出ポインタをデータＣの次の位置（この場合はデータＤの先頭位置）に移動する。この時点で、送信リングバッファ１２１ｂは、データＣが除外されるが、データＣ送信処理中にデータＥとデータＦが追加されているので、送信リングバッファ１２１ｂは、データＤ、データＥ、データＦを蓄積している。コールバック処理手段１０２ｂは、次に、フラグ管理手段１０７のＣＡＳフラグを解除する。コールバック処理手段１０２ｂは、この場合は、送信リングバッファ１２１ｂに送信対象のデータ（この場合は、データＤ、データＥ、データＦ）が存在するので、ソケット書込要求手段１０２ａを呼び出す。
【0059】
次に、ソケット書込要求手段１０２ａは、フラグ管理手段１０７のＣＡＳフラグを参照し、フラグが立っていないので、フラグを立てて、ＯＳシステムコール（ＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（））呼び出しを行い、送信リングバッファ１２１ｂのすべてのデータＤＥＦをＯＳカーネル１００に書き込み要求する（９）。
【0060】
次に、ＯＳカーネル１００は、データＤＥＦを適切なサイズに分割してデータＤ１、Ｄ２、…としてネットワーク４に送信する。
【0061】
次に、ＯＳカーネル１００は、たまたまデータＤだけの送信を完了するとコールバック処理手段１０２ｂを起動して、送信完了を通知する。コールバック処理手段１０２ｂは、送信済バイト数を確認すると、偶然Ｄだけが送信完了となっていたので、送信リングバッファ１２１ｂの読出ポインタをデータＥの先頭に移動し、フラグ管理手段１０７のＣＡＳフラグを解除して、送信リングバッファが空ではないので、ソケット書込要求手段１０２ａを呼び出す。
【0062】
次に、ソケット書込要求手段１０２ａは、フラグ管理手段１０７のＣＡＳフラグを参照し、フラグが立っていないので、フラグを立てて、ＯＳシステムコール（ＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（））呼び出しを行い、リングバッファ１２１のデータＥＦをＯＳカーネル１００に書き込み要求する（１０）。
【0063】
次に、ＯＳカーネル１００は、データＥＦを適切なサイズに分割してデータＥ、Ｆ１、Ｆ２としてネットワーク４に送信する。
【0064】
次に、ＯＳカーネル１００は、データＥＦの送信を完了するとコールバック処理手段１０２ｂを起動して、送信完了を通知する。コールバック処理手段１０２ｂは、送信完了バイト数を確認し、送信リングバッファ１２１ｂの読出ポインタをデータＦの次に移動させ、フラグ管理手段１０７のＣＡＳフラグを解除する。コールバック処理手段１０２ｂは、送信リングバッファ１２１ｂが空（読出ポインタと書込ポインタが一致）になり、処理を終了する
【0065】
以上の例では、説明しやすいように、データＡ－Ｆはそれぞれが１個以上のネットワークパケットとして送信されるような大きなデータとして図示した。ゲームサーバでオブジェクトの同期情報をストリーミングのように送受信する際には、個々のデータのサイズはネットワークの送信パケットサイズにくらべて非常に小さく、データが蓄積されれば、多数のデータがひとつのネットワーク送信パケットとして送信される。したがって、ＣＡＳによるノンブロッキングなソケット書込手段は、ＯＳのロック機能を使用する場合に比べて、著しくオーバヘッドが小さくなり、また、複数のデータをまとめて連続なブロックに配置したり、複数のデータをまとめて１回のＯＳ送信要求で送ったりすることにより、送信チャネルを切れ目なく効率よく稼働させることができ、特にストリーミングのような利用形態では有用である。
【0066】
（実施の形態の効果）
上記した実施の形態によれば、アプリケーション書込手段１０５とソケット書込手段１０２の間に送信リングバッファ１２１ｂを設け、送信リングバッファ１２１ｂはアプリケーション書込手段１０５の書込データをノンブロッキングに蓄積して、ソケット書込要求手段１０２ａの書込動作をＣＡＳフラグに応じて実行し、ＣＡＳフラグをフラグ管理手段１０７によって管理し、ソケット書込要求手段１０２ａの書込開始でフラグを立て、ＯＳ実行手段１００のイベント処理完了の通知を受けたコールバック処理手段１０２ｂがフラグを解除するようにしたため、アプリケーション書込手段１０５の書き込み動作がＯＳ実行手段１００の送信イベント処理の動作に直接影響を及ぼさないようになり（アプリケーション書込手段１０５、ＯＳ実行手段１００がそれぞれに対応するための待ち時間がなくなり、また、それぞれの呼出回数が削減され）、アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化することができる。特に、所要時間の比較的長いネットワークへの送信処理を、ウェイト時間（レイテンシ）短く、なるべく連続処理、かつ、ノンブロッキングに実行することで、ネットワーク送信処理を優先し、送信スループットを上げ、非同期送信（ＮＩＯ）の処理待ちの間の時間にアプリ処理を実行することができる。
上記した実施の形態によれば、アプリケーション書込手段１０５とソケット書込手段１０２の間に送信リングバッファ１２１ｂを設け、送信リングバッファ１２１ｂはアプリケーション書込手段１０５の書込データをノンブロッキングに蓄積して、ソケット書込要求手段１０２ａの書込動作をＣＡＳフラグに応じて実行し、ＣＡＳフラグをフラグ管理手段１０７によって管理し、ソケット書込要求手段１０２ａの書込開始でフラグを立て、ＯＳ実行手段１００のイベント処理完了の通知を受けたコールバック処理手段１０２ｂがフラグを解除するようにしたため、アプリケーション書込手段１０５の書き込み動作がＯＳ実行手段１００の送信イベント処理の動作に直接影響を及ぼさないようになり（アプリケーション書込手段１０５、ＯＳ実行手段１００がそれぞれに対応するための待ち時間がなくなり、また、それぞれの呼出回数が削減され）、アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化することができる。特に、所要時間の比較的長いネットワークへの送信処理を、ウェイト時間（レイテンシ）短く、なるべく連続処理、かつ、ノンブロッキングに実行することで、ネットワーク送信処理を優先し、送信スループットを上げ、非同期送信（ＮＩＯ）の処理待ちの間の時間にアプリ処理を実行することができる。
【0067】
［他の実施の形態］
なお、本発明は、上記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で種々な変形が可能である。
なお、本発明は、上記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で種々な変形が可能である。
【0068】
図５は、レイヤ構成の変形例を示す概略図である。
【0069】
例えば、本願は、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルの７層のうち、アプリケーション層（アプリケーション１１２）とプレゼンテーション層及びセッション層（通信管理プログラム１１１）との間にバッファ（ａ）を設けた例を説明したが、イ～オの異なる層構成で、異なる位置にバッファ（ｂ）～（ｅ）を設けてもよい。
【0070】
ここで、送信スループットを上げるためには、下位の送信に関するレイヤで待ち、下位のレイヤでレイテンシが発生しないためには、上位のアプリは下位への依頼・呼出はロックフリー（ノンブロッキング）であることが望ましい。上位から下位へはなんらかの集約が発生するので、マルチタスク環境では各スレッドのデータが混ざらないように通常はなんらかの排他制御が必要となる。排他制御にＯＳの「ロック（Ｍｕｔｅｘ）」を使用すると処理負荷が重くなるため、ロックフリーなアルゴリズムが望ましい。特にゲームサーバのように、同期のためのパケットをストリーミングのように大量に他頻度に送信するような場合は、パケット送信単位でロックがかかるのは望ましくない。ウ～オではＯＳの排他制御は使えないため、アプリケーションによる排他制御を独自に行う必要がある。
【0071】
ア（本実施の形態）の場合、Ｊａｖａ ＶＭ（仮想ＯＳ）によって作成されたＴＣＰまたはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）チャネルにデータを順次送信する。同一チャネルを複数スレッドで利用する場合には排他制御が必要となる。ＲＵＤＰ（Ｒｅｌｉａｂｌｅ Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）の場合は、ＵＤＰソケットを使うアプリがＡＣＫ（肯定応答）や再送などの信頼性保証のレイヤを独自に作成する必要がある。
【0072】
イの場合、アとの相違点は仮想ＯＳかＮａｔｉｖｅ ＯＳかの違いであるため、アとほぼ同じ構成、動作で実現可能である。
【0073】
ウの場合、ステートレス（コネクションレス）なＵＤＰで実現可能性がある。ＯＳの内部のレイヤを直接呼び出すことは、通常できないため実現可能性は低いが、直接呼び出す構成があれば可能となる。複数のアプリプログラムおよびスレッドが、ＮＩＣを共用する複数の送信先（端末装置）に対する通信全てについて集約が必要となる。
【0074】
エの場合、ＯＳのプロトコルスタックをバイパスして高速化することができる。プロトコルスタックを独自に制作する必要がある。（例えばＤＰＤＫ（Ｄａｔａ Ｐｌａｎｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）等を用いることができる。ｈｔｔｐｓ：／／ｗｗｗ．ｄｐｄｋ．ｏｒｇ／）。ＮＩＣドライバは、ＮＤＩＳではなく特殊となり、通常は特定のＮＩＣプロダクト依存となる。ＵＤＰの場合、データグラムとして、ソケットを介さずに直接送信が可能な場合もある。ＯＳの内部のレイヤを直接呼び出すことは、通常できないため実現可能性は低いが、ＤＰＤＫのように専用のＮＩＣドライバがあれば可能となる。ウ同様に、複数のアプリプログラムおよびスレッドが、ＮＩＣを共用する複数の送信先（端末装置）に対する通信全てについて集約が必要となる。
【0075】
オの場合、アプリケーションが完全にハードウェア依存となるため、組込みシステムなど特殊用途以外で用いられる。ウ同様に、複数のアプリプログラムおよびスレッドが、ＮＩＣを共用する複数の送信先（端末装置）に対する通信全てについて集約が必要となる。
【0076】
次に、各バッファ（ａ）～（ｅ）について説明する。
【0077】
（ａ）の場合、一般的用法としてはＪＡＶＡ限定、ＯＳ非依存のものとなり、ソケット単位でのマルチスレッドのアプリパケット（アプリ送信単位）が混ざらないように集約するものとなる。
【0078】
（ｂ）の場合、一般的用法としては言語依存、ＯＳに依存することもあり、（ａ）と同様となる。（ａ）経由の場合はそのままパラメータのパススルーで引き渡してもよいし、分散書込の場合は、送信バイトバッファが連続領域にあれば一つの送信バッファにまとめるなどの最適化をしてもよい。ここで、分散書込とは、例えばＪａｖａのＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（）の機能で、１つ以上の可変長のデータブロックをグループ化した複数のバッファを指定して送信要求するものを指す。
【0079】
（ｃ）の場合、通常はＯＳ内部、ＯＳカーネルの作業となり、アプリは横断的に対応してプロトコルごとに集約する。なお、プロトコルヘッダの追加が必要となる。ＴＣＰソケットに書かれた時点でコネクションごとのデータストリーム状態、アプリパケットの送信単位の境界は問題としない。適当な大きさに分割して、プロトコルドライバに渡す。その際に、データのコピーや詰替えが発生する可能性がある。ＵＤＰソケットの場合は、コネクションレスのため、ソケットに書きまれればバッファリングされずに送信され、まとめて送ることはない。ＲＵＤＰで複数のデータをまとめて送る場合には、ＵＤＰソケットに書き込む前にまとめてから書き込む。
【0080】
（ｄ）の場合、通常はＯＳ内部、プロトコルドライバの作業となり、アプリは横断的に対応して、各種プロトコルをＮＩＣごとに集約する。なお、プロトコルヘッダの追加が必要となる。各パケットの結合、分割、プロトコルヘッダを追加した、全データをＮＩＣごとに集約する。
【0081】
（ｅ）の場合、ＮＩＣ内部の作業となる。ネットワークタイプに応じた分割、結合、圧縮などの加工、ヘッダなどの追加をして、ビット列に対応する電気信号に変換して、通信回線に送信する。
【0082】
上記実施の形態では制御部１０の各手段１００～１０７の機能をプログラムで実現したが、各手段の全て又は一部をＡＳＩＣ等のハードウェアによって実現してもよい。また、上記実施の形態で用いたプログラムをＣＤ－ＲＯＭ等の記録媒体に記憶して提供することもできる。また、上記実施の形態で説明した上記ステップの入れ替え、削除、追加等は本発明の要旨を変更しない範囲内で可能である。また、各手段の機能は適宜他の手段に結合してもよいし、複数の手段に分離してもよい。
【0083】
本発明の他の態様は、上記目的を達成するため、以下のアプリケーション管理プログラ
ム、情報処理装置及びアプリケーション管理システムを提供する。
ム、情報処理装置及びアプリケーション管理システムを提供する。
【0084】
［１］コンピュータを、
１以上のイベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理手段のイベントの処理の開始のタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する通信管理プログラム。
［２］前記バッファリング手段は、ノンブロッキングキューに前記イベントを蓄積する前記［１］に記載の通信管理プログラム。
［３］前記バッファリング手段は、メモリプールに前記イベントを蓄積する前記［１］又は［２］に記載の通信管理プログラム。
［４］前記バッファリング手段は、リングバッファに前記イベントを蓄積する［１］又は［２］に記載の通信管理プログラム。
［５］１以上のイベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理手段のイベントの処理の開始のタイミングで排他的にフラグを立て、前記コールバック処理手段のイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
［６］情報を処理するコンピュータにおいて、
１以上のイベントをノンブロッキングに蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記処理ステップのイベントの処理の開始のタイミングで排他的にフラグを立て、前記コールバック処理ステップのイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求ステップは、前記バッファリングステップに対する蓄積及び前記コールバック処理ステップの終了のタイミングで呼び出しを受け付けて、前記フラグ管理ステップのフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリングステップが蓄積した前記イベントを処理する通信管理方法。
１以上のイベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理手段のイベントの処理の開始のタイミングで排他的にフラグを立て、前記コールバック処理手段の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する通信管理プログラム。
［２］前記バッファリング手段は、ノンブロッキングキューに前記イベントを蓄積する前記［１］に記載の通信管理プログラム。
［３］前記バッファリング手段は、メモリプールに前記イベントを蓄積する前記［１］又は［２］に記載の通信管理プログラム。
［４］前記バッファリング手段は、リングバッファに前記イベントを蓄積する［１］又は［２］に記載の通信管理プログラム。
［５］１以上のイベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理手段のイベントの処理の開始のタイミングで排他的にフラグを立て、前記コールバック処理手段のイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求手段は、前記バッファリング手段に対する蓄積及び前記コールバック処理手段の終了のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
［６］情報を処理するコンピュータにおいて、
１以上のイベントをノンブロッキングに蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記処理ステップのイベントの処理の開始のタイミングで排他的にフラグを立て、前記コールバック処理ステップのイベントの処理の終了のタイミングでフラグを解除し、
前記処理要求ステップは、前記バッファリングステップに対する蓄積及び前記コールバック処理ステップの終了のタイミングで呼び出しを受け付けて、前記フラグ管理ステップのフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリングステップが蓄積した前記イベントを処理する通信管理方法。
【符号の説明】
【0085】
１ ：サーバ装置
２ａ、２ｂ、２ｃ：端末装置
４ ：ネットワーク
１０ ：制御部
１１ ：記憶部
１２ ：メモリ
１３ ：通信部
１００ ：ＯＳ実行手段（ＯＳカーネル）
１０１ ：ソケット読出手段
１０２ ：ソケット書込手段
１０２ａ ：ソケット書込要求手段
１０２ｂ ：コールバック処理手段
１０３ ：アプリケーション実行手段
１０４ ：アプリケーション読出手段
１０５ ：アプリケーション書込手段
１０６ ：バッファリング手段
１０７ ：フラグ管理手段
１１１ ：通信管理プログラム
１１２ ：アプリケーション
１２０ ：アプリバッファ
１２１ ：リングバッファ
１３０ ：チャネル
１３１ ：ソース
２ａ、２ｂ、２ｃ：端末装置
４ ：ネットワーク
１０ ：制御部
１１ ：記憶部
１２ ：メモリ
１３ ：通信部
１００ ：ＯＳ実行手段（ＯＳカーネル）
１０１ ：ソケット読出手段
１０２ ：ソケット書込手段
１０２ａ ：ソケット書込要求手段
１０２ｂ ：コールバック処理手段
１０３ ：アプリケーション実行手段
１０４ ：アプリケーション読出手段
１０５ ：アプリケーション書込手段
１０６ ：バッファリング手段
１０７ ：フラグ管理手段
１１１ ：通信管理プログラム
１１２ ：アプリケーション
１２０ ：アプリバッファ
１２１ ：リングバッファ
１３０ ：チャネル
１３１ ：ソース
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】