(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023085797
(43)【公開日】2023-06-21
(54)【発明の名称】情報処理プログラム、情報処理装置及び情報処理方法
(51)【国際特許分類】
H04L 49/9005 20220101AFI20230614BHJP
G06F 13/10 20060101ALI20230614BHJP
H04L 47/50 20220101ALI20230614BHJP
【ＦＩ】
H04L49/9005
G06F13/10 330A
H04L47/50
【審査請求】有
【請求項の数】16
【出願形態】ＯＬ
(21)【出願番号】P 2021200032
(22)【出願日】2021-12-09
(11)【特許番号】
(45)【特許公報発行日】2022-04-28
(71)【出願人】
【識別番号】308020799
【氏名又は名称】株式会社ソフトギア
(74)【代理人】
【識別番号】100180758
【弁理士】
【氏名又は名称】荒木 利之
(72)【発明者】
【氏名】宮永 直樹
【テーマコード（参考）】
5K030
【Ｆターム（参考）】
5K030GA01
5K030JL01
5K030JT09
5K030LD01
5K030LE01
5K030MA13
5K030MB15
(57)【要約】 （修正有）
【課題】アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化する情報処理プログラム、情報処理装置及び情報処理方法を提供する。
【解決手段】サーバ装置１は、イベントを蓄積するバッファリング手段１０６と、イベントを処理するソケット書込手段１０２と、排他的にフラグを立てるフラグ管理手段１０７とを有する。ソケット書込手段１０２は、ソケット書込要求手段１０２ａと、コールバック処理手段１０２ｂとを含む。フラグ管理手段１０７は、ソケット書込要求手段１０２ａがイベントの処理の開始前のタイミングで排他的にフラグを立て、コールバック処理手段１０２ｂの処理の終了後のタイミングでフラグを解除する。ソケット書込要求手段１０２ａは、呼び出しを受け付けて、当該フラグが立てられた場合は、バッファリング手段１０６が蓄積したイベントを処理する。
【選択図】図２
【解決手段】サーバ装置１は、イベントを蓄積するバッファリング手段１０６と、イベントを処理するソケット書込手段１０２と、排他的にフラグを立てるフラグ管理手段１０７とを有する。ソケット書込手段１０２は、ソケット書込要求手段１０２ａと、コールバック処理手段１０２ｂとを含む。フラグ管理手段１０７は、ソケット書込要求手段１０２ａがイベントの処理の開始前のタイミングで排他的にフラグを立て、コールバック処理手段１０２ｂの処理の終了後のタイミングでフラグを解除する。ソケット書込要求手段１０２ａは、呼び出しを受け付けて、当該フラグが立てられた場合は、バッファリング手段１０６が蓄積したイベントを処理する。
【選択図】図２
【特許請求の範囲】
【請求項1】
コンピュータを、
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了し
た場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記イベント処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理プログラム。
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了し
た場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記イベント処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理プログラム。
【請求項2】
前記バッファリング手段は、イベントを蓄積する第１のバッファリング手段と、前記第１のバッファリング手段に蓄積された前記イベントを蓄積する第２のバッファリング手段とを有し、
前記処理要求手段は、フラグが立てられた場合に、前記第１のバッファリング手段から前記第２のバッファリング手段に前記イベントを移動して蓄積し、前記第２のバッファリング手段が蓄積している前記イベントの全て又は一部を処理する請求項１に記載の情報処理プログラム。
前記処理要求手段は、フラグが立てられた場合に、前記第１のバッファリング手段から前記第２のバッファリング手段に前記イベントを移動して蓄積し、前記第２のバッファリング手段が蓄積している前記イベントの全て又は一部を処理する請求項１に記載の情報処理プログラム。
【請求項3】
前記第１のバッファリング手段と前記第２のバッファリング手段の間、前記第１のバッファリング手段の前段又は前記第２のバッファリング手段の後段に、さらに１以上のバッファリング手段を有する請求項２に記載の情報処理プログラム。
【請求項4】
前記バッファリング手段間の移動において、データブロックのサイズ、個数、タイプ、イベント保持形式の少なくとも１つを変更する請求項２又は３に記載の情報処理プログラム。
【請求項5】
前記バッファリング手段間の移動において、移動イベントの数やサイズを予め定めた条件で制限する請求項２から４のいずれか１項に記載の情報処理プログラム。
【請求項6】
前記バッファリング手段は、イベント蓄積手段のイベント蓄積動作と、前記処理手段の処理動作とが、非同期に実行される請求項１から５のいずれか１項に記載の情報処理プログラム。
【請求項7】
前記バッファリング手段は、並列動作する複数のイベント生成元が実行するそれぞれのイベントの蓄積手段が非同期にイベントを蓄積する請求項１から６のいずれか１項に記載の情報処理プログラム。
【請求項8】
前記バッファリング手段は、リングバッファである請求項１から７のいずれか１項に記載の情報処理プログラム。
【請求項9】
前記バッファリング手段は、前記イベントそのものをメモリ領域に順次蓄積するリングバッファである請求項１に記載の情報処理プログラム。
【請求項10】
前記バッファリング手段は、２段リングバッファ構成であり、第１段のリングバッファは並列動作するイベント蓄積手段のイベントを蓄積し、第２段のリングバッファは前記処理手段の処理に応じて定められたサイズに当該イベントを連結および分割するとともに前記処理手段に応じて定められた個数保持する請求項２、６又は７に記載の情報処理プログラム。
【請求項11】
前記バッファリング手段は、ダイレクトバッファに前記イベントを格納することを特徴とする請求項１、２又は６から１０のいずれか１項に記載の情報処理プログラム。
【請求項12】
前記バッファリング手段は、バッファプールのバッファに前記イベントを蓄積する請求項１、２又は６から１０のいずれか１項に記載の情報処理プログラム。
【請求項13】
前記バッファリング手段は、前記第１段のリングバッファと前記第２段のリングバッファとで、異なるバッファサイズを保持するバッファプールのバッファにイベントを蓄積する請求項１０に記載の情報処理プログラム。
【請求項14】
前記処理手段は、蓄積されている前記イベントをすべて処理してからイベント処理を終了する請求項１から請求項１３のいずれか１項に記載の情報処理プログラム。
【請求項15】
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了し
た場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記イベント処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了し
た場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記イベント処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
【請求項16】
コンピュータを、
処理対象とするイベントを蓄積するイベント蓄積ステップと、
前記イベントを蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記イベント処理要求ステップにおけるイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理ステップにおける処理の終了後のタイミングでフラグを解除し、
前記処理要求ステップは、前記イベント蓄積ステップにおけるイベント蓄積終了後のタイミング及び前記コールバック処理ステップにおけるイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は蓄積した前記イベントを処理する情報処理方法。
処理対象とするイベントを蓄積するイベント蓄積ステップと、
前記イベントを蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記イベント処理要求ステップにおけるイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理ステップにおける処理の終了後のタイミングでフラグを解除し、
前記処理要求ステップは、前記イベント蓄積ステップにおけるイベント蓄積終了後のタイミング及び前記コールバック処理ステップにおけるイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は蓄積した前記イベントを処理する情報処理方法。
【発明の詳細な説明】
【技術分野】
【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】
以上、２個のバッファ（第１のバッファ１２１ｂ１と第２のバッファ１２１ｂ２）の例を記載したが、バッファの個数を２個に限定するものではない。メモリチャンクのタイプの変更やメモリチャンクのサイズの変更やメモリチャンク内のデータ配置の変更や移動個数の制御あるいはその他の性能向上の工夫は、２個のバッファ間の１回の移動ですべて実施する必要はなく、３個以上のバッファを用いて、多段に順次実行してもよい。
【0086】
また、イベント単位の移動の例を記載したが、移動をイベント単位に限定するものではない。ネットワーク送信などＯＳ処理システムが、個々のイベントの境界にとらわれず、蓄積されたバイト単位に処理をする場合、バッファ間のイベントの移動はイベント単位（０個以上の複数個のイベント）に限定されない。あるイベントの一部分だけでもよいし、連続するイベントの部分を結合したもの（例えば、イベントＡ，イベントＢ、イベントＣが順番に蓄積されていた時に、イベントＡの前半が移動した後は、イベントＡの後半の一部（イベントＡの残りの後半）、イベントＢ全部、イベントＣの前半の一部を連続するイベントの部分を結合したもの）でもよい。
【0087】
また、第１のバッファ１２１ｂ１に送信対象のデータがない場合（Ｓ６０；Ｎｏ）、ステップＳ６２へと進む。
【0088】
なお、第１のバッファ１２１ｂ１へイベントを追加するのは、アプリケーション書込手段１０５である。アプリケーション書込手段１０５は、第１のバッファ１２１ｂ１へイベントを追加後（図１０）に、ソケット書込要求手段１０２ａを呼び出す。アプリケーション書込手段１０５は、並行動作する複数スレッド１０３から非同期に呼出され、ノンブロッキングで第１のバッファ１２１ｂ１にイベントを蓄積する。バッファとしては、たとえば、Ｊａｖａが提供するキュー（ｊａｖａ．ｕｔｉｌ．ｃｏｎｃｕｒｒｅｎｔ．ＣｏｎｃｕｒｒｅｎｔＬｉｎｋｅｄＱｕｅｕｅ）を、メモリチャンクへのポインタを管理するＦＩＦＯバッファを利用する。バッファプールが管理する、メモリチャンクを再利用することで、効率のよいリングバッファを実現できる。バッファプールのメモリチャンクは典型的なイベントサイズより少し大きめのメモリサイズで規格化するとよい。メモリチャンクにはいりきらない大きなイベントは複数のチャンクに保管する。チャンクサイズは、ページサイズの２の累乗数分の１となるように調整する。第２のバッファ１２１ｂ２も、第１のバッファ１２１ｂ１同様に、イベント情報格納したメモリチャンクへのポインタを保持するＦＩＦＯキュー（例えば、ｊａｖａ．ｕｔｉｌ．ｃｏｎｃｕｒｒｅｎｔ．ＣｏｎｃｕｒｒｅｎｔＬｉｎｋｅｄＱｕｅｕｅ）が使用できる。
【0089】
次に、ソケット書込要求手段１０２ａは、第２のバッファ１２１ｂ２に送信対象のデータがある場合（Ｓ６２；Ｙｅｓ）、ＯＳ実行手段１００にＯＳ非同期送信要求を行ってイベントの処理を要求する（Ｓ６３）。例えば、ＪａｖａのＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（）の集約書込（ｇａｔｈｅｒｉｎｇ ｗｒｉｔｅ）を呼び出して、複数メモリチャンクを送信対象として、１回の呼び出しで複数のイベントの処理を要求する。また、ソケット書込要求手段１０２ａは、第２のバッファ１２１ｂ２に送信対象のデータがない場合（Ｓ６２；Ｎｏ）、フラグ管理手段１０７に依頼して、フラグを解除する（Ｓ６４）。第１のバッファ１２１ｂ１にデータがないことを確認（Ｓ６０）後、第２のバッファ１２１ｂ２にもデータがないことを確認（Ｓ６２）したので、中間バッファ１２１Ｂ（第１のバッファ１２１ｂ１及び第２のバッファ１２１ｂ２）が保持するデータをすべて送信し終わったとみなして、フラグを解除して、場合によってはフラグをたてたまま複数回連続的に行ってきたＯＳ非同期送信呼び出しを終了する。送信し終わったとみなした後、フラグを解除するまでの間に、第１のバッファ１２１ｂ１にイベントが追加された場合は、次のイベントとともにＯＳ処理が実行される。
【0090】
図１２に示すコールバック処理手段１０２ｂは、ＯＳ実行手段１００がソケット書込要求手段１０２ａの書込イベントの処理を完了した場合に、ＯＳ実行手段１００から完了通知を受け付けて、対応するソケット書込要求手段１０２ａとは非同期に実行する。コールバック処理手段１０２ｂは、ＯＳ実行手段１００が実行したネットワーク送信結果を受け取る（Ｓ５０）。送信結果が正常の場合は（Ｓ５１；Ｙｅｓ）、コールバック処理手段１０２ｂは、送信完了分を第２のバッファ１２１ｂ２から削除し（Ｓ５２）、ソケット書込要求手段１０２ａに呼び出しを行う（Ｓ５３）。また、送信結果が異常の場合は（Ｓ５１；Ｎｏ）、コールバック処理手段１０２ｂは、通信断、タイムアウトなどの例外処理（接続の切断など）を行う（Ｓ５４）。
【0091】
（情報処理装置の動作）
第２の実施の形態の作用を、（１）基本動作、（２）データ送信動作に分けて説明する。
第２の実施の形態の作用を、（１）基本動作、（２）データ送信動作に分けて説明する。
【0092】
図９は、第２の実施の形態のデータ送受信の動作の一例を説明するための概略図である。
【0093】
（１）基本動作
まず、ネットワーク４からサーバ装置１がデータを受信する場合、ネットワーク４のソース１３１からあるチャネル１３０を介し、ソケット読出手段１０１がチャネルに対応するソケット（受信元端末装置に対応するあるＩＰアドレスのあるポート）によって受信したデータを読み出して中間バッファ１２１Ｂに書き込む。データは中間バッファ１２１Ｂに追加される。なお、バッファはチャネルあるいはソケットごとに別々に用意する。また、チャネル／ソケットは送受信共用で、対応する端末装置（端末装置の通信相手となる特定のプログラム）ごとに１つ用意する。アプリバッファは、１つで図示しているが、実際は送受信別に管理する。また、中間バッファ１２１Ｂは、バッファプールとしては、全チャネルで１つとして管理されており、１つで図示しているが、チャネルごと、送受信別々に管理され、チャネルごとに、別々の受信中間バッファ、送信中間バッファとして区別する。
まず、ネットワーク４からサーバ装置１がデータを受信する場合、ネットワーク４のソース１３１からあるチャネル１３０を介し、ソケット読出手段１０１がチャネルに対応するソケット（受信元端末装置に対応するあるＩＰアドレスのあるポート）によって受信したデータを読み出して中間バッファ１２１Ｂに書き込む。データは中間バッファ１２１Ｂに追加される。なお、バッファはチャネルあるいはソケットごとに別々に用意する。また、チャネル／ソケットは送受信共用で、対応する端末装置（端末装置の通信相手となる特定のプログラム）ごとに１つ用意する。アプリバッファは、１つで図示しているが、実際は送受信別に管理する。また、中間バッファ１２１Ｂは、バッファプールとしては、全チャネルで１つとして管理されており、１つで図示しているが、チャネルごと、送受信別々に管理され、チャネルごとに、別々の受信中間バッファ、送信中間バッファとして区別する。
【0094】
以降のアプリバッファ１２０への書込動作は第１の実施の形態と共通するため省略する。
【0095】
次に、アプリケーション実行手段１０３は、アプリバッファ１２０のデータを読み出してスレッドにて処理する。
【0096】
また、アプリケーション実行手段１０３のスレッドで処理されたデータをネットワーク４に送信する場合、アプリケーション実行手段１０３は、スレッドで処理されたデータをアプリバッファ１２０に書き込む。第２の実施の形態ではアプリケーション書込手段１０５がマルチスレッドで並行処理される場合をメインに説明する。
【0097】
アプリケーション書込手段１０５は、アプリバッファ１２０のデータを意図する送信先端末装置に応じて、送信先端末装置、より厳密には、チャネルあるいはソケットに対応する中間バッファ１２１Ｂ、特に第１のバッファ１２１ｂ１にスレッド毎に書き込む。第１のバッファ１２１ｂ１には、スレッド毎に用意された領域に順次データが書き込まれる。アプリケーション書込手段１０５の並行処理の効率をよくするために、アプリケーション書込手段１０５はノンブロキングに中間バッファ１２１Ｂにデータ（処理結果のイベント）を書き込む。
【0098】
次に、ソケット書込手段１０２は、任意のタイミングで第１のバッファ１２１ｂ１から第２のバッファ１２１ｂ２へ順次データを移動する。移動とは、データを保持するメモリチャンクを第１のバッファ１２１ｂ１から第２のバッファ１２１ｂ２へと文字通りバッファ間で移動する場合だけでなく、対象データを第２のバッファへコピーした後に、第１のバッファからは削除する場合を含む。また、移動とは、単なる１対１の移動にとどまらず、移動によりバッファのタイプ、メモリチャンクのサイズ、メモリチャンク内での配置方法を変更したり、移動するイベント個数の調整をしたり、ＯＳ実行手段が処理しやすいデータ保持形態に変換したりすることも含む。これらの変換を段階的に実施するためには、第３のバッファ、第４のバッファなどさらにバッファ個数（バッファの段数）を増やしてもよい。また、バッファの利用都度に発生するメモリの割当・解放の負荷を軽減するために、データを保持するメモリチャンクはあらかじめまとめて割り当てたメモリを再利用するバッファプールで管理することができる。第１のバッファ、第２のバッファでバッファプールを共有することもできる。また、複数チャネルでそれぞれのバッファ管理を行う場合でも、単一のバッファプールを共有することもできる。バッファプールでは、多くの場合、規格化されたサイズのメモリチャンクを１種類あるいは複数種類保持する。バッファプールは通信管理プログラム起動時にシステムから確保したメモリを使い回すため、バッファプールのメモリを使ったメモリの割当・解放はシステムコールを伴わず処理が軽い、頻繁で複雑なメモリ利用をしても、システムメモリのフラグメンテーションを引き起こさないなどの効果がある。バッファプールは起動時に適切量を確保するが、実行時に不足が起きてしまった場合は、その時点、あるいは、不足が予測された時点で、ＯＳに負荷を与えてしまうので、可能であればある適当なタイミングを見計らって、ＯＳにリクエストして追加のメモリを確保し、バッファプールを拡張することが望ましい。バッファプールが確保するメモリチャンクのメモリの種類やチャンクのサイズは利用形態で適切にチューニングする。第１のバッファで扱うメモリチャンクとしては、通常のヒープが管理する非ダイレクトバッファから平均的なイベントサイズより少し大きな単一サイズ（例えば２５６バイト）を選択する。第２のバッファで扱うメモリチャンクとしては、ＯＳが扱いやすいサイズとタイプ、例えばページサイズ、あるいはページサイズの半分（例えば２ＫＢ）のダイレクトバッファを選択する。メモリプールのサイズは、ＯＳからまとめて取得したバッファを小分けにして使うので、ページサイズやメモリ境界を意識して、ページサイズ、あるいは、ページサイズの２の累乗数分の１の値を採用し、２５バイトや５０バイトのような任意の値を採用しない。
【0099】
次に第１のバッファから第２のバッファへ移動するタイミングは、予め定めた時間間隔毎であってもよいし、第１のバッファ１２１ｂ１又は第１のバッファ１２１ｂ１内のチャンクに蓄積されたデータ量が予め定めた量になった場合であってもよいし、第１のバッファ１２１ｂ１又は第１のバッファ１２１ｂ１内のチャンク蓄積されたイベントの数が予め定めた数になった場合であってもよい。
【0100】
ソケット書込手段１０２の起動のトリガ、あるいは、第１のバッファ１２１ｂ１から第２のバッファ１２１ｂ２へのデータの移動のトリガは、ポーリングやタイマなどであってもよいし、すべてあるいは一部のアプリケーション書込手段１０５の実行直後であってもよい。
【0101】
なお、３段以上のバッファを使用する場合において、格段のバッファ間のデータの移動のタイミング、トリガ、移動方法などは、それぞれの段間で、上記記載の第１バッファと第２バッファについて記述した方法をそれぞれの段で独立に採用することができる。上記の例では移動の際に複数の操作（チャンクのメモリタイプの変更、チャンクサイズの変更、移動量の制限など）を同時に行ったが、操作を分割して、途中結果を追加のバッファとして保持することが考えられる。その場合には、移動のタイミング、トリガはすべての段で同じであってもよい。
【0102】
次に、ソケット書込手段１０２は、第２のバッファ１２１ｂ２のデータを読み出し、ソケットによってチャネル１３０に書き込む。データは、チャネル１３０を介してソース１３１に送信される。この時、データは第２のバッファ１２１ｂ２から取り出され、送信対象としてＯＳ実行手段１００が送信処理をし、送信が完了したデータ（取り出したデータの全部あるいは一部）については、第２のバッファ１２１ｂ２から削除される。送信が完了しなかったデータについては、引き続き第２のバッファ１２１ｂ２にとどまる。ここでは、第２のバッファ１２１ｂ２に蓄積されたデータを全部一度に送信するものとしたが、第２のバッファ１２１ｂ２に蓄積されているデータが巨大になった場合は、ＯＳ送信機能呼出の制限を考慮するなど、全部一度に読み出さず、一部だけを読み出して送信する制御をしてもよい。あるいは、第２のバッファ１２１ｂ２が蓄積するデータが巨大にならないように、第１のバッファ１２１ｂ１から第２のバッファ１２１ｂ２へ移動するイベントの数やバイト数を移動の際にあらかじめ制限してもよい。
【0103】
以下、アプリケーション実行手段１０３のスレッドで処理されたデータをＯＳ実行手段１００からネットワーク４に送信する場合について詳細に説明する。
【0104】
（２）データ送信動作
図１０は、データ送信動作の一例を説明するための概略図である。スレッド１とスレッド２が、非同期にそれぞれイベントＡ，Ｃ，Ｆ，及びイベントＢ，Ｄ，Ｅを順次生成し、アプリケーション書込手段１０５、ソケット書込要求手段１０２ａを呼び出し、それぞれのイベントＡ－Ｆをネットワーク４に送信する。アプリケーション書込手段１０５は、スレッド１及びスレッド２が生成したイベント１個を第１のバッファ１２１ｂ１に追加し、ソケット書込手段１０２ａを呼び出す。ソケット書込手段１０２ａは、ＯＳカーネル１００がすでにイベント処理を実行中の場合は処理を行わないで終了するが、ＯＳカーネル１００がイベント処理を実行中でない場合は、第１のバッファ１２１ｂ１が保持する０個以上のイベントを第２のバッファ１２１ｂ２へ移動し、第２のバッファ１２１ｂ２が保持するイベントについて、ＯＳカーネル１００にイベントの処理を依頼する。ＯＳカーネル１００がイベントの処理中であるかどうかの状態は、フラグ管理手段１０７が提供するＣＡＳフラグにより管理される。ＯＳカーネル１００は要求されたイベントの処理を完了すると、コールバックスレッド（スレッド１のコールバックスレッド）で、コールバック処理手段１０２ｂを、スレッド１及びスレッド２とも非同期に実行する。コールバックスレッドは、イベント処理の進捗状況を確認して、第２のバッファ１２１ｂ２を調整後（処理済のイベントを第２のバッファから削除したり、第１のバッファから第２のバッファへイベントを移動したりして）、ソケット書込手段ａを再帰的かつ排他的に呼び出し、ＯＳカーネル１００が処理中に第１のバッファ１２１ｂ１に蓄積されたイベントについても、イベント処理を行う。コールバックスレッドは、ソケット書込要求手段１０２ａ及びコールバック処理手段１０２ｂの処理を繰り返して、中間バッファ１２１Ｂ（すなわち、第１のバッファ１２１ｂ１及び第２のバッファ１２１ｂ２）が保持するイベントがなくなるまで稼働する。
図１０は、データ送信動作の一例を説明するための概略図である。スレッド１とスレッド２が、非同期にそれぞれイベントＡ，Ｃ，Ｆ，及びイベントＢ，Ｄ，Ｅを順次生成し、アプリケーション書込手段１０５、ソケット書込要求手段１０２ａを呼び出し、それぞれのイベントＡ－Ｆをネットワーク４に送信する。アプリケーション書込手段１０５は、スレッド１及びスレッド２が生成したイベント１個を第１のバッファ１２１ｂ１に追加し、ソケット書込手段１０２ａを呼び出す。ソケット書込手段１０２ａは、ＯＳカーネル１００がすでにイベント処理を実行中の場合は処理を行わないで終了するが、ＯＳカーネル１００がイベント処理を実行中でない場合は、第１のバッファ１２１ｂ１が保持する０個以上のイベントを第２のバッファ１２１ｂ２へ移動し、第２のバッファ１２１ｂ２が保持するイベントについて、ＯＳカーネル１００にイベントの処理を依頼する。ＯＳカーネル１００がイベントの処理中であるかどうかの状態は、フラグ管理手段１０７が提供するＣＡＳフラグにより管理される。ＯＳカーネル１００は要求されたイベントの処理を完了すると、コールバックスレッド（スレッド１のコールバックスレッド）で、コールバック処理手段１０２ｂを、スレッド１及びスレッド２とも非同期に実行する。コールバックスレッドは、イベント処理の進捗状況を確認して、第２のバッファ１２１ｂ２を調整後（処理済のイベントを第２のバッファから削除したり、第１のバッファから第２のバッファへイベントを移動したりして）、ソケット書込手段ａを再帰的かつ排他的に呼び出し、ＯＳカーネル１００が処理中に第１のバッファ１２１ｂ１に蓄積されたイベントについても、イベント処理を行う。コールバックスレッドは、ソケット書込要求手段１０２ａ及びコールバック処理手段１０２ｂの処理を繰り返して、中間バッファ１２１Ｂ（すなわち、第１のバッファ１２１ｂ１及び第２のバッファ１２１ｂ２）が保持するイベントがなくなるまで稼働する。
【0105】
アプリケーション実行手段１０３は、例えば、複数のスレッド１、スレッド２によりデータを処理し、処理結果のイベントＡ、イベントＢを同一の端末装置（より厳密には、同一のソケットあるいはチャネル）に送信するために、当該イベントＡ、イベントＢはアプリケーション書込手段１０５により送信先端末へ通信するソケットに対応する第１のバッファ１２１ｂ１に書き込まれる。スレッド１、スレッド２の処理は非同期に発生するものとする。第１のバッファ１２１ｂ１は、例えばスレッドセーフでノンブロッキングなリングバッファ（例えば、ノンブロッキングでスレッドセーフなＦＩＦＯキュー ｊａｖａ．ｕｔｉｌ．ＣｏｎｃｕｒｒｅｎｔＬｉｎｋｅｄＱｕｅｕｅ にイベントを格納するメモリチャンクのポインタを登録することで実現可能）である。アプリケーション書込手段１０５は、イベントＡ、イベントＢをスレッド毎に異なる領域（チャンク）にノンブロッキングにイベントを書き込む（１）（２）。特に、イベントのサイズのメモリチャンクの代わりに、規格化されたサイズのメモリチャンクを用いる場合は、メモリチャンクは、例えば、ｊａｖａ．ｎｉｏ．ＢｙｔｅＢｕｆｆｅｒを用いて、保管しているイベントの開始位置と終了位置も管理する。また、規格化されたサイズのメモリチャンクにイベントを保管する場合、チャンクサイズより大きなイベントについては、イベントを複数チャンクにわたるチャンクグループに保管し、チャンクグループへのポインタをリングバッファに追加してもよい。
【0106】
さて、まず、スレッド１のイベントＡについては、アプリケーション書込手段１０５は第１のバッファ１２１ｂ１のイベントＡの処理を要求すべくソケット書込要求手段１０２ａを呼び出す（３）。ソケット書込要求手段１０２ａは、呼出元がアプリケーション書込手段１０５なので、フラグ管理手段１０７のＣＡＳフラグを参照し、フラグが立っていないので、フラグを立てて（４）、第１のバッファ１２１ｂ１にイベントが蓄積されているか確認し、イベントがあるので第１のバッファ１２１ｂ１のイベントＡを第２のバッファ１２１ｂ２へ移動する（５）。ここで、第２のバッファ１２１ｂ２も、第１のバッファ１２１ｂ１同様に、例えばノンブロッキングなリングバッファ（例えば、ノンブロッキングでスレッドセーフなＦＩＦＯキュー ｊａｖａ．ｕｔｉｌ．ＣｏｎｃｕｒｒｅｎｔＬｉｎｋｅｄＱｕｅｕｅ にイベントを格納するメモリチャンクのポインタを登録することで実現可能）であってもよい。ただし、第２のバッファの操作を行うスレッドは、フラグ管理手段１０７により、高々１個に制御されているので、スレッドセーフでなくてもよい。また、ソケット書込要求手段１０２ａは、イベントＡを第２のバッファ１２１ｂ２へ移動した後、スレッド１に次の処理を進めるよう呼び出しを行い、処理はＯＳカーネル１００にまかせて（６）、ＯＳカーネル１００の処理の完了をまたずに終了し、スレッド１の処理に戻る（７）。
【0107】
一方で、スレッド２のイベントＢについては、アプリケーション書込手段１０５は第１のバッファ１２１ｂ１のイベントＢの処理を要求すべくソケット書込要求手段１０２ａを呼び出す（８）。ソケット書込要求手段１０２ａは、呼出元がアプリケーション書込手段１０５なので、フラグ管理手段１０７のＣＡＳフラグを参照し（９）、この場合は先のイベントＡの処理のためにすでにフラグが立っている（４）ため、もはやフラグをたてられない。ソケット書込要求手段１０２ａは、処理ができるようになるまで待たず、ノンブロッキングで処理を終了してスレッド２の処理に戻る（１０）。
【0108】
スレッド１については、アプリケーション実行手段１０３は、引き続きデータを処理し、アプリケーション書込手段１０５は処理結果のイベントＣを第１のバッファ１２１ｂ１に書き込む（１１）。第１のバッファ１２１ｂ１は、未処理のイベントＢとイベントＣを保持している（１１）。スレッド１のイベントＣについては、アプリケーション書込手段１０５は第１のバッファ１２１ｂ１のデータ（追加したデータＣだけでなく、すでに追加されているデータＢも）の処理を要求すべくソケット書込要求手段１０２ａを呼び出す（５０）。ソケット書込要求手段１０２ａは、呼出元がアプリケーション書込手段１０５なので、フラグ管理手段１０７のＣＡＳフラグを参照し、この場合は先のデータＡの処理のためにすでにフラグが立っている（４）ため、もはやフラグをたてられない。ソケット書込要求手段１０２ａは、処理ができるようになるまで待たず、ノンブロッキングでソケット書込要求手段１０２ａの処理を終了してスレッド１の処理に戻る。
【0109】
スレッド１のイベントＡのネットワーク送信については、具体的には、ソケット書込要求手段１０２ａが、ＯＳカーネル１００に処理をまかせる（６）際には、ＯＳシステムコール（例えばＪＡＶＡのＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（））呼び出しを行い、第２のバッファ１２１ｂ２に存在するイベントＡ（１２）を指定して送信要求する。ソケット書込要求手段１０２ａは、第２のバッファ１２１ｂ２のイベントＡをＯＳ実行手段１００（ＯＳカーネル）に書き込み要求をして終了し、スレッド１の処理に戻る（７）。
【0110】
スレッド１のイベントＡのネットワーク送信については、送信依頼されたＯＳカーネル１００は、第１の実施の形態と同様に、イベントＡを適切なサイズに分割してイベントＡ１、Ａ２を送信する（１３）。分割のサイズ、分割の個数、送信間隔はＯＳやネットワークの負荷などに依存する。
【0111】
また、一方で、スレッド２のイベントＢについて、ＯＳカーネル１００がイベントＡの処理中に、アプリケーション書込手段１０５は、第１のバッファ１２１ｂ１のイベントＢを処理すべく、引き続きソケット書込要求手段１０２ａを呼び出す（８）が、ソケット書込要求手段１０２ａは、まだイベントＡが処理中（４）でフラグ管理手段１０７のＣＡＳフラグが立っている（９）のでソケット書込要求手段１０２ａは第１のバッファ１２１ｂ１のイベントＢを第２のバッファ１２１ｂ２へ移動せず、アプリケーション書込手段１０５は処理を終了し、スレッド２は次の処理を進める（１０）。この時点では、第１のバッファ１２１ｂ１には、イベントＢ、Ｃが蓄積されており、まだイベントＤは生成されていない（１１）。アプリケーション実行手段１０３は、スレッド２によりデータを処理して、後のタイミングでイベントＤを生成する。
【0112】
次に、スレッド１よりイベントＡの送信依頼されたＯＳカーネル１００は、イベントＡの送信を完了すると、コールバック処理手段１０２ｂをスレッド１のコールバックスレッドとして起動して（１４）、コールバック処理手段１０２ｂは送信完了したバイト数を確認し、この場合はイベントＡ全体が送信完了しているので、第１のバッファ１２１ｂ１からイベントＡを削除する（１５）。この時点で第１のバッファ１２１ｂ１にはイベントＢ、Ｃが存在する（１１）。その後、コールバック処理手段１０２ｂは、ソケット書込要求手段１０２ａを呼び出す（１６）。
【0113】
引き続き、コールバックスレッドにおいて、ソケット書込要求手段１０２ａは、第１のバッファ１２１ｂ１にイベントが蓄積されているか確認し、イベントがあるので第１のバッファ１２１ｂ１のイベントＢ、Ｃを第２のバッファ１２１ｂ２へ移動する（１７）。ここでは、第２のバッファ１２１ｂ２の容量に十分余裕があるので、第１のバッファ１２１ｂ１のイベントすべてを移動したが、第２のバッファ１２１ｂ２の容量などを考慮して、第１のバッファ１２１ｂ１が蓄積するイベントの一部だけ（例えばイベントＢだけ）を移動してもよい。たまたま、この後のタイミングで、スレッド２のイベントＤについて、アプリケーション書込手段１０５は処理結果のイベントＤを第１のバッファ１２１ｂ１に書き込む（１８）。この時点では、第１のバッファ１２１ｂ１はイベントＤだけを保持している。
【0114】
さて、スレッド１のイベントＣについては、引き続きソケット書込要求手段１０２ａを呼び出すが、フラグ管理手段１０７のＣＡＳフラグが立っているので、ソケット書込要求手段１０２ａは第１のバッファ１２１ｂ１のイベントＢ、イベントＣを第２のバッファ１２１ｂ２へ移動せず、アプリケーション書込手段１０５は処理を終了し、スレッド１に戻り処理を進める（１９）。アプリケーション実行手段１０３は、スレッド１によりデータを処理し、後のタイミングでイベントＦを生成する（２０）。また、この第１バッファ１２１ｂ１のイベントＢとイベントＣについては、前述したように、後のタイミングで、コールバックスレッドによりイベント処理が行われることになる。
【0115】
次に、コールバックスレッドにおいて、ソケット書込要求手段１０２ａは、呼出元がコールバック処理手段１０２ｂの場合なので、引き続きＯＳシステムコール呼び出しを行い、第２のバッファ１２１ｂ２のイベントＢとイベントＣを送信要求する（２１）。ソケット書込要求手段１０２ａは、第２のバッファ１２１ｂ２のイベントＢをＯＳ実行手段１００（ＯＳカーネル）に書き込み要求をしてコールバックスレッドを終了する。
【0116】
次に、コールバックスレッドよりイベントＢ、Ｃの送信依頼をされたＯＳカーネル１００は、イベントＢ及びイベントＣを適切なサイズに分割してネットワークに送信する。まずイベントＢを３分割してイベントＢ１、Ｂ２、Ｂ３と送信して、終了（ＯＳカーネルは処理を完了）する。イベントＢのみ送信してイベントＣを送信しない理由、あるいはイベントＢの一部でなくイベントＢ全体を送信した理由は、ＯＳの都合であり、サーバ装置１又はネットワーク４の負荷などの状況による（２２）。
【0117】
また、スレッド２のイベントＤについて、スレッド１のコールバックスレッドに依頼されたＯＳカーネル１００のイベント処理中に、アプリケーション書込手段１０５は、第１のバッファ１２１ｂ１のイベントＤを処理すべく、引き続きソケット書込要求手段１０２ａを呼び出す（２３）が、ソケット書込要求手段１０２ａはイベントＢ、Ｃの処理中（１６）でフラグ管理手段１０７のＣＡＳフラグが立っている（２４）のでソケット書込要求手段１０２ａは第１のバッファ１２１ｂ１のイベントＤを第２のバッファ１２１ｂ２へ移動せず、アプリケーション書込手段１０５は終了し、スレッド２に戻り次の処理を進める（２５）。アプリケーション実行手段１０３は、引き続きスレッド２によりデータを処理して、後のタイミングでイベントＥを生成する（２６）。この時点で、第１のバッファ１２１ｂ１には、イベントＤが蓄積（１８）されており、まだイベントＥは生成されていない。
【0118】
次に、コールバックスレッドよりイベントＢ、Ｃの送信依頼をされたＯＳカーネル１００は、イベントＢの送信を完了すると、コールバック処理手段１０２ｂを起動して（２７）、コールバック処理手段１０２ｂは送信完了したバイト数を確認し、この場合はイベントＢ全体が送信完了しているので、第１のバッファ１２１ｂ１からイベントＢを削除する。
【0119】
この時点で、スレッド２は、イベントＥを生成し、アプリケーション書込手段１０５によりイベントＥを第１のバッファ１２１ｂ１に書き込む。第１のバッファ１２１ｂ１にはイベントＤ、Ｅが存在する（２８）。スレッド２において、イベントＥを生成（２６）したアプリケーション書込手段１０５は、ソケット書込要求手段１０２ａを呼び出す（３０）。ソケット書込要求手段１０２ａは、まだイベントＣ及びイベントＤの処理中（２７）でフラグ管理手段１０７のＣＡＳフラグが立っている（３１）のでソケット書込要求手段１０２ａは第１のバッファ１２１ｂ１のイベントＤ及びＥを第２のバッファ１２１ｂ２へ移動せず、アプリケーション書込手段１０５は処理を終了しスレッド２に戻り、スレッド２は次の処理を進める（３２）。
【0120】
スレッド１のコールバックスレッドよりイベントＢ、Ｃの送信依頼をされたＯＳカーネル１００が、イベントＢの送信を完了後に、再び、スレッド１のコールバックスレッドを起動し、起動したコールバック処理手段１０２ｂは、再び、ソケット読み込み要求手段１０２ａを呼び出す（２９）。ソケット書込要求手段１０２ａは、第１のバッファ１２１ｂ１にイベントが蓄積されているか確認し、イベントがあるので第１のバッファ１２１ｂ１のイベントＤ、Ｅ（２８）を第２のバッファ１２１ｂ２へイベントを移動する（３３）。この時点で、第２のバッファ１２１ｂ２はイベントＣ、Ｄ、Ｅを保持する。
【0121】
次に、スレッド１のコールバックスレッドにおいて、ソケット書込要求手段１０２ａは、呼出元がコールバック処理手段１０２ｂなので、ＯＳシステムコール呼び出しを行い、第２のバッファ１２１ｂ２のイベントＣ、Ｄ、ＥをＯＳに送信要求してコールバックスレッドを終了（３４）する。
【0122】
次に、ＯＳカーネル１００は、イベントＣ，Ｄ，Ｅを送信しようとする。まずイベントＣを適切なサイズに分割（Ｃ１，Ｃ２，Ｃ３）してイベントＣ１、Ｃ２を送信して終了（ＯＳカーネルは処理を完了）する（３５）。イベントＣの一部（Ｃ１，Ｃ２）のみを送信（３５）して、残りのイベントＣ（Ｃ３）、イベントＤ、イベントＥを送信しない理由は、前述したようにＯＳの都合である。この時点で、第１のバッファ１２１ｂ１には、イベントＦが蓄積されている。
【0123】
次に、ＯＳカーネル１００は、イベントＣの一部の送信を完了すると、再び、スレッド１のコールバックスレッドとして、コールバック処理手段１０２ｂを起動（３６）して、コールバック処理手段１０２ｂは送信完了したバイト数を確認し、この場合はイベントＣのうちＣ１、Ｃ２が送信完了しているので、第２のバッファ１２１ｂ２からイベントＣのうちＣ１、Ｃ２に相当する部分を削除する。Ｃが単一のチャンクに格納されている場合、Ｃ３の送信が完了するまではチャンク全体のメモリ解放はできない。例えば、ｊａｖａ．ｎｉｏ．ＢｙｔｅＢｕｆｆｅｒを用いて送信開始位置と送信終了位置を管理する場合、Ｃ全体の解放はＣ３の処理終了後とし、Ｃ１，Ｃ２の完了は、送信開始位置をＣ１からＣ３に移動すればよい。そして再び、ソケット書込要求手段１０２ａを呼び出す（３７）。
【0124】
次に、コールバックスレッドにおいて、ソケット書込要求手段１０２ａは、呼出元がコールバック処理手段１０２ｂなので、第１のバッファ１２１ｂ１にイベントが蓄積されているか確認するが、イベントＦが蓄積されていたので、イベントＦを第２のバッファ１２１ｂ２へ移動する。イベントＦは第１のバッファ１２１ｂ１から第２のバッファ１２１ｂ２へ移動し、第１のバッファはイベントがなくなり（３８）、第２のバッファはイベントＣ３、Ｄ、Ｅ、Ｆ（３９）を保持する。ソケット書込要求手段１０２ａは、引き続き、ＯＳシステムコール呼び出しを行い、第２のバッファ１２１ｂ２のイベントＣ３、Ｄ、Ｅ、Ｆ（３９）をＯＳ実行手段１００（ＯＳカーネル）に書き込み要求をしてコールバックスレッドを終了する（４０）。
【0125】
次に、イベントＣ３、Ｄ、Ｅ、Ｆの送信依頼されたＯＳカーネル１００は、イベントＣ、Ｄを適切なサイズに分割してイベントＣ３、Ｄ１、Ｄ２を送信する（４１）。イベントＣ３とＤのみ送信してイベントＥ、Ｆを送信しない理由は、前述したようにＯＳの都合である。
【0126】
次に、イベントＣ３、Ｄ、Ｅ、Ｆの送信依頼されたＯＳカーネル１００は、イベントＣ、Ｄの送信を完了すると、コールバックスレッドとして、コールバック処理手段１０２ｂを起動して（４２）、コールバック処理手段１０２ｂは送信完了したバイト数を確認し、この場合はイベントＣのうちＣ３が、イベントＤのすべてが送信完了しているので、第２のバッファ１２１ｂ２からイベントＣ３（あるいはイベントＣ全体）およびイベントＤを削除する。そして再び、ソケット書込要求手段１０２ａを呼び出す（４３）。
【0127】
次に、コールバックスレッドにおいて、ソケット書込要求手段１０２ａは、呼出元がコールバック処理手段１０２ｂなので、まず第１のバッファ１２１ｂ１にイベントが蓄積されているか確認し、イベントがない（３８）ので第２のバッファ１２１ｂ２にイベントを移動せず、ＯＳシステムコール呼び出しを行い、第２のバッファ１２１ｂ２のイベントＥ、Ｆ（４４）をＯＳ実行手段１００（ＯＳカーネル）に書き込み要求をしてコールバックスレッドを終了する（４５）。
【0128】
次に、イベントＥ、Ｆの送信依頼されたＯＳカーネル１００は、イベントＥ、Ｆを適切なサイズに分割してイベントＥ１、Ｅ２、Ｆを送信する（４６）。
【0129】
次に、イベントＥ、Ｆの送信依頼されたＯＳカーネル１００は、イベントＥ、Ｆの送信を完了すると、コールバックスレッドとして、コールバック処理手段１０２ｂを起動して（４７）、コールバック処理手段１０２ｂは送信完了したバイト数を確認し、この場合はイベントＥ、Ｆのすべてが送信完了しているので、第２のバッファ１２１ｂ２からイベントＥ、Ｆを削除する。そして再び、ソケット書込要求手段１０２ａを呼び出す（４８）。
【0130】
その後、コールバックスレッドにおいて、ソケット書込要求手段１０２ａは、呼出元がコールバック処理手段１０２ｂなので、第１のバッファ１２１ｂ１及び第２のバッファ１２１ｂ２を順に確認するが、第１のバッファ１２１ｂ１及び第２のバッファ１２１ｂ２のいずれにもイベントがなくなっているので、フラグ管理手段１０７のＣＡＳフラグを解除（４９）し、コールバックスレッドを終了する。
【0131】
（第２の実施の形態の効果）
上記した第２の実施の形態によれば、アプリケーション書込手段１０５とソケット書込手段１０２の間に中間バッファ１２１Ｂを設け、中間バッファ１２１Ｂの第１のバッファ１２１ｂ１はアプリケーション書込手段１０５の書込データをスレッド毎にノンブロッキングに蓄積して、ソケット書込要求手段１０２ａの書込動作をＣＡＳフラグに応じて実行し、ＣＡＳフラグをフラグ管理手段１０７によって管理し、ソケット書込要求手段１０２ａの書込開始でフラグを立て、ＯＳ実行手段１００のイベント処理完了の通知を受けたコールバック処理手段１０２ｂがフラグを解除するとともに、第１のバッファ１２１ｂ１にイベントが存在する場合は第２のバッファ１２１ｂ２にイベントをまとめるなどＯＳ実行手段の処理に適した形式に変換した上で移動してからＯＳ実行手段１００により第２のバッファ１２１ｂ２のイベントを処理するようにしたため、アプリケーション書込手段１０５の書き込み動作がＯＳ実行手段１００の送信イベント処理の動作に直接影響を及ぼさないようになり（アプリケーション書込手段１０５、ＯＳ実行手段１００がそれぞれに対応するための待ち時間がなくなり、また、イベントごとにＯＳ実行手段１００を呼び出す場合に比べてＯＳ実行手段１００の呼出回数が削減され）、アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化することができる。特に、所要時間の比較的長いネットワークへの送信処理を、ウェイト時間（レイテンシ）短く、なるべく連続処理、かつ、ノンブロッキングに実行することで、ネットワーク送信処理を優先し、送信スループットを上げつつ、非同期送信（ＮＩＯ）の処理待ちの間の時間にアプリ処理をノンブロッキングに並列実行することができる。
上記した第２の実施の形態によれば、アプリケーション書込手段１０５とソケット書込手段１０２の間に中間バッファ１２１Ｂを設け、中間バッファ１２１Ｂの第１のバッファ１２１ｂ１はアプリケーション書込手段１０５の書込データをスレッド毎にノンブロッキングに蓄積して、ソケット書込要求手段１０２ａの書込動作をＣＡＳフラグに応じて実行し、ＣＡＳフラグをフラグ管理手段１０７によって管理し、ソケット書込要求手段１０２ａの書込開始でフラグを立て、ＯＳ実行手段１００のイベント処理完了の通知を受けたコールバック処理手段１０２ｂがフラグを解除するとともに、第１のバッファ１２１ｂ１にイベントが存在する場合は第２のバッファ１２１ｂ２にイベントをまとめるなどＯＳ実行手段の処理に適した形式に変換した上で移動してからＯＳ実行手段１００により第２のバッファ１２１ｂ２のイベントを処理するようにしたため、アプリケーション書込手段１０５の書き込み動作がＯＳ実行手段１００の送信イベント処理の動作に直接影響を及ぼさないようになり（アプリケーション書込手段１０５、ＯＳ実行手段１００がそれぞれに対応するための待ち時間がなくなり、また、イベントごとにＯＳ実行手段１００を呼び出す場合に比べてＯＳ実行手段１００の呼出回数が削減され）、アプリケーション処理及びデータの送信をノンブロッキングに実行して通信を高速化することができる。特に、所要時間の比較的長いネットワークへの送信処理を、ウェイト時間（レイテンシ）短く、なるべく連続処理、かつ、ノンブロッキングに実行することで、ネットワーク送信処理を優先し、送信スループットを上げつつ、非同期送信（ＮＩＯ）の処理待ちの間の時間にアプリ処理をノンブロッキングに並列実行することができる。
【0132】
（変形例）
上記した第２の実施の形態において、ソケット書込要求手段１０２ａを、アプリケーション書込手段１０５からの呼び出しにのみ応じてＯＳ実行手段１００にイベント処理を要求するソケット書込要求手段１０２ａ１と、コールバック処理手段１０２ｂの呼び出しにのみ応じてＯＳ実行手段１００にイベント処理を要求するソケットフラッシュ書込手段１０２ａ２とに分けてもよい。この場合、図１１のステップＳ４０が不要となり、図１２のステップＳ５３が「ＯＳ実行手段１００にイベント処理を要求する」に変わり、図１３の動作をソケットフラッシュ書込手段１０２ａ２が担うこととなる。このように実装した場合についても第２の実施の形態と同様の上記効果を奏する。
上記した第２の実施の形態において、ソケット書込要求手段１０２ａを、アプリケーション書込手段１０５からの呼び出しにのみ応じてＯＳ実行手段１００にイベント処理を要求するソケット書込要求手段１０２ａ１と、コールバック処理手段１０２ｂの呼び出しにのみ応じてＯＳ実行手段１００にイベント処理を要求するソケットフラッシュ書込手段１０２ａ２とに分けてもよい。この場合、図１１のステップＳ４０が不要となり、図１２のステップＳ５３が「ＯＳ実行手段１００にイベント処理を要求する」に変わり、図１３の動作をソケットフラッシュ書込手段１０２ａ２が担うこととなる。このように実装した場合についても第２の実施の形態と同様の上記効果を奏する。
【0133】
［他の実施の形態］
なお、本発明は、上記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で種々な変形や組み合わせが可能である。
（Ａ）ＣＡＳによるノンブロッキングな排他制御
本発明の基本は、ＣＡＳによるノンブロッキングなＯＳ実行手段１００の呼び出しである。ネットワーク送信処理において、ＯＳ実行手段１００の呼び出しは、送信要求したデータの一部のみを送信することがあるなど、送信バッファのセットアップ、送信処理、送信完了後の済送信バッファの調整など、同一チャネルへの送信は並行処理することができない。そのためなんらかの排他制御が必要である。そこで、ＯＳの機能を利用して、Ｓｙｎｃｈｒｏｎｉｚｅｄメソッドなどで実装し、同時に単一のスレッドしか実行できず、他のスレッドは実行中のスレッドの終了を待ち、暫時、ひとつずつ実行が再開されるような、排他制御を行うことが一般的である。ただ、ネットワークゲームでゲームオブジェクトの変化を大量多頻度に中継するようなゲームサーバのような用途では、小さなデータを大量多頻度に送受信することになり、ＯＳの機能を用いた排他制御も多頻度となるため、ＯＳ機能呼び出しのオーバヘッドが無視できなくなり、サーバ機能の処理性能を低下させる。そこで本発明は、アトミックなインストラクションで実行されるノンブロッキングなＣＡＳを用いて排他制御を行う。イベントをＯＳ機能処理中に、別のイベントのためにＯＳ機能呼び出しを行おうとしてもＣＡＳの排他制御によって、実行されることなく、待つこともなく終了してしまう。イベントごとに逐次に処理することはできないので、イベントは一旦、バッファへ蓄積し、ＯＳ機能処理実行中のスレッドは、起動時に想定していたイベントだけでなく、起動前に蓄積されていたイベント、あるいは、ＯＳ機能処理実行中に蓄積されたイベントも、処理するように工夫している。一般に、ＯＳの機能呼び出しは通常のメモリ処理に比べて、処理時間が長いので、ゲームサーバのような用途では、ＯＳ機能呼び出し中に新たなイベントが蓄積される可能性が高い。第１の実施例と第２の実施例で典型的な２種類のＣＡＳによるノンブロッキング排他制御方法を示したが、この２個の実施例に限定するものではない。
（Ｂ）イベント蓄積の仮想的なリングバッファの形式
ＯＳの機能呼び出しに時間がかかる場合、機能呼び出し実行中に別の処理を非同期に実行できるように、ＯＳは機能呼び出しとコールバックとに分けて処理する仕組みを提供する。そのため、イベント処理後のコールバックは、イベント処理のための機能呼び出しとは非同期に発生する。また、アプリケーションのイベントの生成も非同期である。これらを調停するために、イベントはリングバッファに蓄積し、ＦＩＦＯでイベント処理できるように、蓄積と処理を完全に非同期に実行できるようにする必要がある。リングバッファにはさまざまなバリエーションがあり、第１の実施例ではイベントデータをバイトシーケンスで蓄積するリングバッファを示し、第２の実施例ではイベントデータを蓄積するメモリチャンクのポインタを蓄積するリングバッファを示したが、開示した２個の方法及びその変形だけに限定するものではない。
（Ｃ）イベントの蓄積とＯＳの機能呼び出しの非同期処理
イベントの蓄積はイベントの発生に同期できる。一方で蓄積しているイベントの処理はイベント処理完了のコールバックから起動すればよい。ただ、イベント処理が全く動作していない、例えば最初の１個目のイベント処理を起動するには別の機構が必要である。第１の実施例及び第２の実施例では、イベント処理が停止している場合に限り、イベント蓄積をトリガとする方式を開示した。しかし、前述しているように、このトリガは、タイマなどで完全に非同期であってもよいし、毎回あるいは数回に一度のイベント蓄積と同期であってもよい。また、トリガとしては、機能呼び出し（メッソッドや関数の呼び出し）であってもよいし、ＯＳ機能を用いたシグナリングでもよいし、それ以外の方法でもよい。第２の実施例では、アプリケーションのイベント処理の効率を考慮して、トリガとしてコールバックからのメソッド呼び出しを優先する方式を示した。適用するアプリケーションにより適切な方法を選択するものであり、実施例及びその変形として開示した手法のみに限定するものではない。
（Ｄ）メモリの再利用
頻繁にメモリの割当解放を繰り返す場合は、その都度ＯＳ機能呼び出しを行うのはオーバヘッドとなるので、事前にまとまったメモリを確保し、メモリの割当解放はＯＳに依頼するのではなく、確保済のメモリを再利用するバッファプールは一般的である。メモリのフラグメンテーションやそれに伴うガベージコレクションを回避し、メモリの再利用を促進するには、バッファプールは、規格化したメモリチャンクの集合として管理し、アプリケーションが使用するメモリサイズに応じて、必要個数のチャンクを結合して使うのも一般的である。仮想的にリングバッファを実現するには、メモリのバファプールを用いるのがよい。チャンクのサイズや個数、また、使用するメモリの種類（ダイレクトバファであるか非ダイレクトバッファであるか）は適用するアプリケーションにより適切に選択するものであり、実施例及びその変形として開示した手法による選択に限定されるものではない。
なお、本発明は、上記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で種々な変形や組み合わせが可能である。
（Ａ）ＣＡＳによるノンブロッキングな排他制御
本発明の基本は、ＣＡＳによるノンブロッキングなＯＳ実行手段１００の呼び出しである。ネットワーク送信処理において、ＯＳ実行手段１００の呼び出しは、送信要求したデータの一部のみを送信することがあるなど、送信バッファのセットアップ、送信処理、送信完了後の済送信バッファの調整など、同一チャネルへの送信は並行処理することができない。そのためなんらかの排他制御が必要である。そこで、ＯＳの機能を利用して、Ｓｙｎｃｈｒｏｎｉｚｅｄメソッドなどで実装し、同時に単一のスレッドしか実行できず、他のスレッドは実行中のスレッドの終了を待ち、暫時、ひとつずつ実行が再開されるような、排他制御を行うことが一般的である。ただ、ネットワークゲームでゲームオブジェクトの変化を大量多頻度に中継するようなゲームサーバのような用途では、小さなデータを大量多頻度に送受信することになり、ＯＳの機能を用いた排他制御も多頻度となるため、ＯＳ機能呼び出しのオーバヘッドが無視できなくなり、サーバ機能の処理性能を低下させる。そこで本発明は、アトミックなインストラクションで実行されるノンブロッキングなＣＡＳを用いて排他制御を行う。イベントをＯＳ機能処理中に、別のイベントのためにＯＳ機能呼び出しを行おうとしてもＣＡＳの排他制御によって、実行されることなく、待つこともなく終了してしまう。イベントごとに逐次に処理することはできないので、イベントは一旦、バッファへ蓄積し、ＯＳ機能処理実行中のスレッドは、起動時に想定していたイベントだけでなく、起動前に蓄積されていたイベント、あるいは、ＯＳ機能処理実行中に蓄積されたイベントも、処理するように工夫している。一般に、ＯＳの機能呼び出しは通常のメモリ処理に比べて、処理時間が長いので、ゲームサーバのような用途では、ＯＳ機能呼び出し中に新たなイベントが蓄積される可能性が高い。第１の実施例と第２の実施例で典型的な２種類のＣＡＳによるノンブロッキング排他制御方法を示したが、この２個の実施例に限定するものではない。
（Ｂ）イベント蓄積の仮想的なリングバッファの形式
ＯＳの機能呼び出しに時間がかかる場合、機能呼び出し実行中に別の処理を非同期に実行できるように、ＯＳは機能呼び出しとコールバックとに分けて処理する仕組みを提供する。そのため、イベント処理後のコールバックは、イベント処理のための機能呼び出しとは非同期に発生する。また、アプリケーションのイベントの生成も非同期である。これらを調停するために、イベントはリングバッファに蓄積し、ＦＩＦＯでイベント処理できるように、蓄積と処理を完全に非同期に実行できるようにする必要がある。リングバッファにはさまざまなバリエーションがあり、第１の実施例ではイベントデータをバイトシーケンスで蓄積するリングバッファを示し、第２の実施例ではイベントデータを蓄積するメモリチャンクのポインタを蓄積するリングバッファを示したが、開示した２個の方法及びその変形だけに限定するものではない。
（Ｃ）イベントの蓄積とＯＳの機能呼び出しの非同期処理
イベントの蓄積はイベントの発生に同期できる。一方で蓄積しているイベントの処理はイベント処理完了のコールバックから起動すればよい。ただ、イベント処理が全く動作していない、例えば最初の１個目のイベント処理を起動するには別の機構が必要である。第１の実施例及び第２の実施例では、イベント処理が停止している場合に限り、イベント蓄積をトリガとする方式を開示した。しかし、前述しているように、このトリガは、タイマなどで完全に非同期であってもよいし、毎回あるいは数回に一度のイベント蓄積と同期であってもよい。また、トリガとしては、機能呼び出し（メッソッドや関数の呼び出し）であってもよいし、ＯＳ機能を用いたシグナリングでもよいし、それ以外の方法でもよい。第２の実施例では、アプリケーションのイベント処理の効率を考慮して、トリガとしてコールバックからのメソッド呼び出しを優先する方式を示した。適用するアプリケーションにより適切な方法を選択するものであり、実施例及びその変形として開示した手法のみに限定するものではない。
（Ｄ）メモリの再利用
頻繁にメモリの割当解放を繰り返す場合は、その都度ＯＳ機能呼び出しを行うのはオーバヘッドとなるので、事前にまとまったメモリを確保し、メモリの割当解放はＯＳに依頼するのではなく、確保済のメモリを再利用するバッファプールは一般的である。メモリのフラグメンテーションやそれに伴うガベージコレクションを回避し、メモリの再利用を促進するには、バッファプールは、規格化したメモリチャンクの集合として管理し、アプリケーションが使用するメモリサイズに応じて、必要個数のチャンクを結合して使うのも一般的である。仮想的にリングバッファを実現するには、メモリのバファプールを用いるのがよい。チャンクのサイズや個数、また、使用するメモリの種類（ダイレクトバファであるか非ダイレクトバッファであるか）は適用するアプリケーションにより適切に選択するものであり、実施例及びその変形として開示した手法による選択に限定されるものではない。
【0134】
図５は、レイヤ構成の変形例を示す概略図である。
【0135】
例えば、本願は、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルの７層のうち、アプリケーション層（アプリケーション１１２）とプレゼンテーション層及びセッション層（通信管理プログラム１１１）との間にバッファ（ａ）を設けた例を説明したが、イ～オの異なる層構成で、異なる位置にバッファ（ｂ）～（ｅ）を設けてもよい。
【0136】
ここで、送信スループットを上げるためには、下位の送信に関するレイヤで待ち、下位のレイヤでレイテンシが発生しないためには、上位のアプリは下位への依頼・呼出はロックフリー（ノンブロッキング）であることが望ましい。上位から下位へはなんらかの集約が発生するので、マルチタスク環境では各スレッドのデータが混ざらないように通常はなんらかの排他制御が必要となる。排他制御にＯＳの「ロック（Ｍｕｔｅｘ）」を使用すると処理負荷が重くなるため、ロックフリーなアルゴリズムが望ましい。特にゲームサーバのように、同期のためのパケットをストリーミングのように大量に他頻度に送信するような場合は、パケット送信単位でロックがかかるのは望ましくない。ウ～オではＯＳの排他制御は使えないため、アプリケーションによる排他制御を独自に行う必要がある。
【0137】
ア（第１の実施の形態および第２の実施の形態）の場合、Ｊａｖａ ＶＭ（仮想ＯＳ）によって作成されたＴＣＰ又はＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）チャネルにデータを順次送信する。同一チャネルを複数スレッドで利用する場合には排他制御が必要となる。ＲＵＤＰ（Ｒｅｌｉａｂｌｅ Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）の場合は、ＵＤＰソケットを使うアプリがＡＣＫ（肯定応答）や再送などの信頼性保証のレイヤを独自に作成する必要がある。
【0138】
イの場合、アとの相違点は仮想ＯＳかＮａｔｉｖｅ ＯＳかの違いであるため、アとほぼ同じ構成、動作で実現可能である。
【0139】
ウの場合、ステートレス（コネクションレス）なＵＤＰで実現可能性がある。ＯＳの内部のレイヤを直接呼び出すことは、通常できないため実現可能性は低いが、直接呼び出す構成があれば可能となる。複数のアプリケーション及びスレッドが、ＮＩＣを共用する複数の送信先（端末装置）に対する通信全てについて集約が必要となる。
【0140】
エの場合、ＯＳのプロトコルスタックをバイパスして高速化することができる。プロトコルスタックを独自に制作する必要がある。（例えばＤＰＤＫ（Ｄａｔａ Ｐｌａｎｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）等を用いることができる。ｈｔｔｐｓ：／／ｗｗｗ．ｄｐｄｋ．ｏｒｇ／）。ＮＩＣドライバは、ＮＤＩＳではなく特殊となり、通常は特定のＮＩＣプロダクト依存となる。ＵＤＰの場合、データグラムとして、ソケットを介さずに直接送信が可能な場合もある。ＯＳの内部のレイヤを直接呼び出すことは、通常できないため実現可能性は低いが、ＤＰＤＫのように専用のＮＩＣドライバがあれば可能となる。ウ同様に、複数のアプリケーション及びスレッドが、ＮＩＣを共用する複数の送信先（端末装置）に対する通信全てについて集約が必要となる。
【0141】
オの場合、アプリケーションが完全にハードウェア依存となるため、組込みシステムなど特殊用途以外で用いられる。ウ同様に、複数のアプリケーション及びスレッドが、ＮＩＣを共用する複数の送信先（端末装置）に対する通信全てについて集約が必要となる。
【0142】
次に、各バッファ（ａ）～（ｅ）について説明する。
【0143】
（ａ）の場合、一般的用法としてはＪＡＶＡ限定、ＯＳ非依存のものとなり、ソケット単位でのマルチスレッドのアプリパケット（アプリ送信単位）が混ざらないように集約するものとなる。
【0144】
（ｂ）の場合、一般的用法としては言語依存、ＯＳに依存することもあり、（ａ）と同様となる。（ａ）経由の場合はそのままパラメータのパススルーで引き渡してもよいし、分散書込の場合は、送信バイトバッファが連続領域にあれば一つの送信バッファにまとめるなどの最適化をしてもよい。ここで、分散書込とは、例えばＪａｖａのＡｓｙｎｃｈｒｏｎｏｕｓＳｏｃｋｅｔＣｈａｎｎｅｌ．ｗｒｉｔｅ（）の機能で、１つ以上の可変長のデータブロックをグループ化した複数のバッファを指定して送信要求するものを指す。
【0145】
（ｃ）の場合、通常はＯＳ内部、ＯＳカーネルの作業となり、アプリは横断的に対応してプロトコルごとに集約する。なお、プロトコルヘッダの追加が必要となる。ＴＣＰソケットに書かれた時点でコネクションごとのデータストリーム状態、アプリパケットの送信単位の境界は問題としない。適当な大きさに分割して、プロトコルドライバに渡す。その際に、データのコピーや詰替えが発生する可能性がある。ＵＤＰソケットの場合は、コネクションレスのため、ソケットに書きまれればバッファリングされずに送信され、まとめて送ることはない。ＲＵＤＰで複数のデータをまとめて送る場合には、ＵＤＰソケットに書き込む前にまとめてから書き込む。
【0146】
（ｄ）の場合、通常はＯＳ内部、プロトコルドライバの作業となり、アプリは横断的に対応して、各種プロトコルをＮＩＣごとに集約する。なお、プロトコルヘッダの追加が必要となる。各パケットの結合、分割、プロトコルヘッダを追加した、全データをＮＩＣごとに集約する。
【0147】
（ｅ）の場合、ＮＩＣ内部の作業となる。ネットワークタイプに応じた分割、結合、圧縮などの加工、ヘッダなどの追加をして、ビット列に対応する電気信号に変換して、通信回線に送信する。
【0148】
上記実施の形態では制御部１０の各手段１００～１０７の機能をプログラムで実現したが、各手段の全て又は一部をＡＳＩＣ等のハードウェアによって実現してもよい。また、上記実施の形態で用いたプログラムをＣＤ－ＲＯＭ等の記録媒体に記憶して提供することもできる。また、上記実施の形態で説明した上記ステップの入れ替え、削除、追加等は本発明の要旨を変更しない範囲内で可能である。また、各手段の機能は適宜他の手段に結合してもよいし、複数の手段に分離してもよい。
【0149】
上記実施の形態では、主にネットワークの送信イベントの処理について記述したが、本発明は、処理する対象のイベントをネットワーク送信イベントのみに限定するものではない。本発明の各手段のすべて又は一部は、ネットワークの送信以外のイベント処理、特にＯＳ機能に処理操作を依頼する比較的長時間を要する処理（ＯＳ機能が非同期処理を可能とするために処理要求手段とコールバック手段とを提供する処理、典型的には各種Ｉ／Ｏ操作）、より具体的には、ネットワークやディスクなど各種メディアなどに対する出力操作に、対応する要求手段とコールバック手段を差し替えることで、適用できる。また、ＯＳ機能を順次複数回呼び出してイベント処理するには、本発明のイベント処理の仕組みを複数段組み合わせることができる。
【符号の説明】
【0150】
１ ：サーバ装置
２ａ、２ｂ、２ｃ：端末装置
４ ：ネットワーク
１０ ：制御部
１１ ：記憶部
１２ ：メモリ
１３ ：通信部
１００ ：ＯＳ実行手段（ＯＳカーネル）
１０１ ：ソケット読出手段
１０２ ：ソケット書込手段
１０２ａ ：ソケット書込要求手段
１０２ｂ ：コールバック処理手段
１０３ ：アプリケーション実行手段
１０４ ：アプリケーション読出手段
１０５ ：アプリケーション書込手段
１０６ ：バッファリング手段
１０７ ：フラグ管理手段
１１１ ：通信管理プログラム
１１２ ：アプリケーション
１２０ ：アプリバッファ
１２１ ：リングバッファ
１２１Ｂ ：中間バッファ
１２１ｂ１ ：第１のバッファ
１２１ｂ２ ：第２のバッファ
１３０ ：チャネル
１３１ ：ソース
２ａ、２ｂ、２ｃ：端末装置
４ ：ネットワーク
１０ ：制御部
１１ ：記憶部
１２ ：メモリ
１３ ：通信部
１００ ：ＯＳ実行手段（ＯＳカーネル）
１０１ ：ソケット読出手段
１０２ ：ソケット書込手段
１０２ａ ：ソケット書込要求手段
１０２ｂ ：コールバック処理手段
１０３ ：アプリケーション実行手段
１０４ ：アプリケーション読出手段
１０５ ：アプリケーション書込手段
１０６ ：バッファリング手段
１０７ ：フラグ管理手段
１１１ ：通信管理プログラム
１１２ ：アプリケーション
１２０ ：アプリバッファ
１２１ ：リングバッファ
１２１Ｂ ：中間バッファ
１２１ｂ１ ：第１のバッファ
１２１ｂ２ ：第２のバッファ
１３０ ：チャネル
１３１ ：ソース
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【手続補正書】
【提出日】2022-03-17
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
コンピュータを、
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理プログラム。
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理プログラム。
【請求項2】
前記バッファリング手段は、イベントを蓄積する第１のバッファリング手段と、前記第１のバッファリング手段に蓄積された前記イベントを蓄積する第２のバッファリング手段とを有し、
前記処理要求手段は、フラグが立てられた場合に、前記第１のバッファリング手段から前記第２のバッファリング手段に前記イベントを移動して蓄積し、前記第２のバッファリング手段が蓄積している前記イベントの全て又は一部を処理する請求項１に記載の情報処理プログラム。
前記処理要求手段は、フラグが立てられた場合に、前記第１のバッファリング手段から前記第２のバッファリング手段に前記イベントを移動して蓄積し、前記第２のバッファリング手段が蓄積している前記イベントの全て又は一部を処理する請求項１に記載の情報処理プログラム。
【請求項3】
前記第１のバッファリング手段と前記第２のバッファリング手段の間、前記第１のバッファリング手段の前段又は前記第２のバッファリング手段の後段に、さらに１以上のバッファリング手段を有する請求項２に記載の情報処理プログラム。
【請求項4】
前記バッファリング手段間の移動において、データブロックのサイズ、個数、タイプ、イベント保持形式の少なくとも１つを変更する請求項２又は３に記載の情報処理プログラム。
【請求項5】
前記バッファリング手段間の移動において、移動イベントの数やサイズを予め定めた条件で制限する請求項２から４のいずれか１項に記載の情報処理プログラム。
【請求項6】
前記バッファリング手段は、イベント蓄積手段のイベント蓄積動作と、前記処理手段の処理動作とが、非同期に実行される請求項１から５のいずれか１項に記載の情報処理プログラム。
【請求項7】
前記バッファリング手段は、並列動作する複数のイベント生成元が実行するそれぞれのイベントの蓄積手段が非同期にイベントを蓄積する請求項１から６のいずれか１項に記載の情報処理プログラム。
【請求項8】
前記バッファリング手段は、リングバッファである請求項１から７のいずれか１項に記載の情報処理プログラム。
【請求項9】
前記バッファリング手段は、前記イベントそのものをメモリ領域に順次蓄積するリングバッファである請求項１に記載の情報処理プログラム。
【請求項10】
前記バッファリング手段は、２段リングバッファ構成であり、第１段のリングバッファは並列動作するイベント蓄積手段のイベントを蓄積し、第２段のリングバッファは前記処理手段の処理に応じて定められたサイズに当該イベントを連結および分割するとともに前記処理手段に応じて定められた個数保持する請求項２、６又は７に記載の情報処理プログラム。
【請求項11】
前記バッファリング手段は、ダイレクトバッファに前記イベントを格納することを特徴とする請求項１、２又は６から１０のいずれか１項に記載の情報処理プログラム。
【請求項12】
前記バッファリング手段は、バッファプールのバッファに前記イベントを蓄積する請求項１、２又は６から１０のいずれか１項に記載の情報処理プログラム。
【請求項13】
前記バッファリング手段は、前記第１段のリングバッファと前記第２段のリングバッファとで、異なるバッファサイズを保持するバッファプールのバッファにイベントを蓄積する請求項１０に記載の情報処理プログラム。
【請求項14】
前記処理手段は、蓄積されている前記イベントをすべて処理してからイベント処理を終了する請求項１から請求項１３のいずれか１項に記載の情報処理プログラム。
【請求項15】
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
【請求項16】
コンピュータにおいて実行される情報処理方法であって、
処理対象とするイベントを蓄積するイベント蓄積ステップと、
前記イベントを蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記処理要求ステップにおけるイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理ステップにおける処理の終了後のタイミングでフラグを解除し、
前記処理要求ステップは、前記イベント蓄積ステップにおけるイベント蓄積終了後のタイミング及び前記コールバック処理ステップにおけるイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は蓄積した前記イベントを処理する情報処理方法。
処理対象とするイベントを蓄積するイベント蓄積ステップと、
前記イベントを蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記処理要求ステップにおけるイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理ステップにおける処理の終了後のタイミングでフラグを解除し、
前記処理要求ステップは、前記イベント蓄積ステップにおけるイベント蓄積終了後のタイミング及び前記コールバック処理ステップにおけるイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は蓄積した前記イベントを処理する情報処理方法。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【0008】
［１］コンピュータを、
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理プログラム。
［２］前記バッファリング手段は、イベントを蓄積する第１のバッファリング手段と、前記第１のバッファリング手段に蓄積された前記イベントを蓄積する第２のバッファリング手段とを有し、
前記処理要求手段は、フラグが立てられた場合に、前記第１のバッファリング手段から前記第２のバッファリング手段に前記イベントを移動して蓄積し、前記第２のバッファリング手段が蓄積している前記イベントの全て又は一部を処理する前記［１］に記載の情報処理プログラム。
［３］前記第１のバッファリング手段と前記第２のバッファリング手段の間、前記第１のバッファリング手段の前段又は前記第２のバッファリング手段の後段に、さらに１以上のバッファリング手段を有する前記［２］に記載の情報処理プログラム。
［４］前記バッファリング手段間の移動において、データブロックのサイズ、個数、タイプ、イベント保持形式の少なくとも１つを変更する前記［２］又は［３］に記載の情報処理プログラム。
［５］前記バッファリング手段間の移動において、移動イベントの数やサイズを予め定めた条件で制限する前記［２］から［４］のいずれか１項に記載の情報処理プログラム。
［６］前記バッファリング手段は、イベント蓄積手段のイベント蓄積動作と、前記処理手段の処理動作とが、非同期に実行される前記［１］から［５］のいずれか１項に記載の情報処理プログラム。
［７］前記バッファリング手段は、並列動作する複数のイベント生成元が実行するそれぞれのイベントの蓄積手段が非同期にイベントを蓄積する前記［１］から［６］のいずれか１項に記載の情報処理プログラム。
［８］前記バッファリング手段は、リングバッファである前記［１］から［７］のいずれか１項に記載の情報処理プログラム。
［９］前記バッファリング手段は、前記イベントそのものをメモリ領域に順次蓄積するリングバッファである前記［１］に記載の情報処理プログラム。
［１０］前記バッファリング手段は、２段リングバッファ構成であり、第１段のリングバッファは並列動作するイベント蓄積手段のイベントを蓄積し、第２段のリングバッファは前記処理手段の処理に応じて定められたサイズに当該イベントを連結および分割するとともに前記処理手段に応じて定められた個数保持する前記［２］、［６］又は［７］に記載の情報処理プログラム。
［１１］前記バッファリング手段は、ダイレクトバッファに前記イベントを格納することを特徴とする前記［１］、［２］又は［６］から［１０］のいずれか１項に記載の情報処理プログラム。
［１２］前記バッファリング手段は、バッファプールのバッファに前記イベントを蓄積する前記［１］、［２］又は［６］から［１０］のいずれか１項に記載の情報処理プログラム。
［１３］前記バッファリング手段は、前記第１段のリングバッファと前記第２段のリングバッファとで、異なるバッファサイズを保持するバッファプールのバッファにイベントを蓄積する前記［１０］に記載の情報処理プログラム。
［１４］前記処理手段は、蓄積されている前記イベントをすべて処理してからイベント処理を終了する前記［１］から［１３］のいずれか１項に記載の情報処理プログラム。
［１５］処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
［１６］コンピュータにおいて実行される情報処理方法であって、
処理対象とするイベントを蓄積するイベント蓄積ステップと、
前記イベントを蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記処理要求ステップにおけるイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理ステップにおける処理の終了後のタイミングでフラグを解除し、
前記処理要求ステップは、前記イベント蓄積ステップにおけるイベント蓄積終了後のタイミング及び前記コールバック処理ステップにおけるイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は蓄積した前記イベントを処理する情報処理方法。
処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段として機能させ、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理プログラム。
［２］前記バッファリング手段は、イベントを蓄積する第１のバッファリング手段と、前記第１のバッファリング手段に蓄積された前記イベントを蓄積する第２のバッファリング手段とを有し、
前記処理要求手段は、フラグが立てられた場合に、前記第１のバッファリング手段から前記第２のバッファリング手段に前記イベントを移動して蓄積し、前記第２のバッファリング手段が蓄積している前記イベントの全て又は一部を処理する前記［１］に記載の情報処理プログラム。
［３］前記第１のバッファリング手段と前記第２のバッファリング手段の間、前記第１のバッファリング手段の前段又は前記第２のバッファリング手段の後段に、さらに１以上のバッファリング手段を有する前記［２］に記載の情報処理プログラム。
［４］前記バッファリング手段間の移動において、データブロックのサイズ、個数、タイプ、イベント保持形式の少なくとも１つを変更する前記［２］又は［３］に記載の情報処理プログラム。
［５］前記バッファリング手段間の移動において、移動イベントの数やサイズを予め定めた条件で制限する前記［２］から［４］のいずれか１項に記載の情報処理プログラム。
［６］前記バッファリング手段は、イベント蓄積手段のイベント蓄積動作と、前記処理手段の処理動作とが、非同期に実行される前記［１］から［５］のいずれか１項に記載の情報処理プログラム。
［７］前記バッファリング手段は、並列動作する複数のイベント生成元が実行するそれぞれのイベントの蓄積手段が非同期にイベントを蓄積する前記［１］から［６］のいずれか１項に記載の情報処理プログラム。
［８］前記バッファリング手段は、リングバッファである前記［１］から［７］のいずれか１項に記載の情報処理プログラム。
［９］前記バッファリング手段は、前記イベントそのものをメモリ領域に順次蓄積するリングバッファである前記［１］に記載の情報処理プログラム。
［１０］前記バッファリング手段は、２段リングバッファ構成であり、第１段のリングバッファは並列動作するイベント蓄積手段のイベントを蓄積し、第２段のリングバッファは前記処理手段の処理に応じて定められたサイズに当該イベントを連結および分割するとともに前記処理手段に応じて定められた個数保持する前記［２］、［６］又は［７］に記載の情報処理プログラム。
［１１］前記バッファリング手段は、ダイレクトバッファに前記イベントを格納することを特徴とする前記［１］、［２］又は［６］から［１０］のいずれか１項に記載の情報処理プログラム。
［１２］前記バッファリング手段は、バッファプールのバッファに前記イベントを蓄積する前記［１］、［２］又は［６］から［１０］のいずれか１項に記載の情報処理プログラム。
［１３］前記バッファリング手段は、前記第１段のリングバッファと前記第２段のリングバッファとで、異なるバッファサイズを保持するバッファプールのバッファにイベントを蓄積する前記［１０］に記載の情報処理プログラム。
［１４］前記処理手段は、蓄積されている前記イベントをすべて処理してからイベント処理を終了する前記［１］から［１３］のいずれか１項に記載の情報処理プログラム。
［１５］処理対象とするイベントを蓄積するイベント蓄積手段と、
前記イベントを蓄積するバッファリング手段と、
前記蓄積したイベントを処理する処理手段と、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理手段とを有し、
前記処理手段は、イベントの処理を要求する処理要求手段と、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理手段とを含み、
前記フラグ管理手段は、前記処理要求手段がイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理手段の処理の終了後のタイミングでフラグを解除し、
前記処理要求手段は、前記イベント蓄積手段の前記バッファリング手段へのイベント蓄積終了後のタイミング及び前記コールバック処理手段のイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグ管理手段のフラグに応じて当該フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は前記バッファリング手段が蓄積した前記イベントを処理する情報処理装置。
［１６］コンピュータにおいて実行される情報処理方法であって、
処理対象とするイベントを蓄積するイベント蓄積ステップと、
前記イベントを蓄積するバッファリングステップと、
前記蓄積したイベントを処理する処理ステップと、
呼び出しを受け付けて排他的にフラグを立てるフラグ管理ステップとを有し、
前記処理ステップは、イベントの処理を要求する処理要求ステップと、イベントの処理を完了した場合に完了通知を受けて実行するコールバック処理ステップとを含み、
前記フラグ管理ステップは、前記処理要求ステップにおけるイベントの処理の開始前のタイミングで排他的にフラグを立て、前記コールバック処理ステップにおける処理の終了後のタイミングでフラグを解除し、
前記処理要求ステップは、前記イベント蓄積ステップにおけるイベント蓄積終了後のタイミング及び前記コールバック処理ステップにおけるイベント処理終了後のタイミングで呼び出しを受け付けて、前記フラグが、立てられなかった場合は処理をせずに終了し、立てられた場合は蓄積した前記イベントを処理する情報処理方法。