(57)【要約】【課題】ある送信先装置に対するデータ送信速度が低下した場合における他の送信先装置に対するデータ送信速度の低下を抑制する。【解決手段】記憶部１１は、送信先装置２１〜２３のそれぞれに対応する制御値１１ａ〜１１ｃを記憶する。制御部１２は、送信先装置２１〜２３のそれぞれに対するデータＤ１ａ〜Ｄ１ｃの送信に要した所要時間を測定し、所要時間に基づいて送信先装置２１〜２３のそれぞれに対応する制御値１１ａ〜１１ｃを更新する。また、制御部１２は、送信先装置２１〜２３のそれぞれに対するデータＤ２ａ〜Ｄ２ｃの送信時に、制御値１１ａ〜１１ｃに基づき、所要時間が短い送信先装置が優先されるように送信先装置２１〜２３に対するデータ送信順を決定する。【選択図】図１
2020031375.tif 000002
【特許請求の範囲】
【請求項１】
複数の送信先装置のそれぞれに対応する制御値を記憶する記憶部と、
前記複数の送信先装置のそれぞれに対するデータ送信に要した所要時間を測定し、前記所要時間に基づいて前記複数の送信先装置のそれぞれに対応する前記制御値を更新し、前記複数の送信先装置に対するデータ送信時に、前記制御値に基づき、前記所要時間が短い送信先装置が優先されるように前記複数の送信先装置に対するデータ送信順を決定する制御部と、
を有する送信制御装置。
【請求項２】
前記制御部は、前記データ送信において、前記制御値に基づき、前記所要時間が短い送信先装置ほど短い時間間隔でデータを送信する、
請求項１記載の送信制御装置。
【請求項３】
前記記憶部は、送信キューをさらに記憶し、
前記制御部は、前記データ送信において、
前記複数の送信先装置のそれぞれにデータを送信するためのキューデータを前記送信キューにキューイングする際、前記制御値に基づき、前記所要時間が短い送信先装置に対応する前記キューデータを優先的に前記送信キューにキューイングし、
前記送信キューから前記キューデータを順番に取り出し、前記複数の送信先装置のうち取り出した前記キューデータに対応する送信先装置にデータを送信する、
請求項１記載の送信制御装置。
【請求項４】
前記記憶部は、前記制御値として次回送信時刻を記憶し、
前記制御部は、
前記制御値の更新において、前記所要時間が短いほど次のデータ送信までの時間間隔が短くなるように前記複数の送信先装置のそれぞれに対応する前記次回送信時刻を決定し、
前記キューイングにおいて、前記次回送信時刻が早い送信先装置に対応する前記キューデータを優先的に前記送信キューにキューイングする、
請求項３記載の送信制御装置。
【請求項５】
前記記憶部は、前記制御値として次回送信時刻を記憶し、さらに、前記複数の送信先装置のそれぞれに対応する許容時間を記憶し、
前記制御部は、
前記制御値の更新において、前記複数の送信先装置のそれぞれについて、測定された前記所要時間に基づいて所定個数のデータを送信可能な時間によって前記許容時間を更新し、前記所要時間が測定されたデータ送信の開始時刻に前記許容時間を加算した時刻によって前記次回送信時刻を更新し、
前記キューイングにおいて、前記次回送信時刻が早い送信先装置に対応する前記キューデータを優先的に前記送信キューにキューイングする、
請求項３記載の送信制御装置。
【請求項６】
前記制御部は、前記キューイングにおいて、前記複数の送信先装置のうち、前記次回送信時刻が現時刻より後の送信先装置に対応する前記キューデータについて、前記送信キューへのキューイングをスキップする、
請求項５記載の送信制御装置。
【請求項７】
前記制御部は、前記データ送信において、前記複数の送信先装置のうち同一の送信先装置に対して、当該送信先装置に対応する前記許容時間の範囲内でデータを連続して送信する、
請求項５または６記載の送信制御装置。
【請求項８】
前記制御部は、前記データ送信において、前記送信キューを用いて、前記複数の送信先装置のうち２以上の所定数の送信先装置に対して並列にデータを送信する、
請求項３乃至７のいずれか１項に記載の送信制御装置。
【請求項９】
前記制御部は、さらに、
前記複数の送信先装置のそれぞれについて、データの送信に失敗した失敗回数をカウントし、
前記複数の送信先装置のうち一の送信先装置に対応する前記失敗回数が所定の閾値に達した場合、前記一の送信先装置に対するデータの送信を停止するとともに、一定時間間隔で前記一の送信先装置に対するデータ送信可否の確認処理を実行し、
前記確認処理によって前記一の送信先装置に対するデータの送信が可能であることが確認されると、前記一の送信先装置に対するデータの送信を再開する、
請求項１乃至８のいずれか１項に記載の送信制御装置。
【請求項１０】
コンピュータに、
複数の送信先装置のそれぞれに対するデータ送信に要した所要時間を測定し、前記所要時間に基づいて前記複数の送信先装置のそれぞれに対応する制御値を記憶部に記録し、
前記複数の送信先装置に対するデータ送信時に、前記制御値に基づき、前記所要時間が短い送信先装置が優先されるように前記複数の送信先装置に対するデータ送信順を決定する、
処理を実行させる送信制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信制御装置および送信制御プログラムに関する。
【背景技術】
【０００２】
情報処理装置において発生するイベントの内容を複数の送信先装置に送信する技術が知られている。例えば、ストレージ装置の管理に関するＳＭＩ−Ｓ（Storage Management Initiative Specification）規格では、ストレージ装置で発生するイベントの内容を示す「Indication」と呼ばれる情報を複数のクライアントに通知するための情報が規定されている。ＳＭＩ−Ｓ規格では、複数のクライアントのそれぞれについて、イベントの種別ごとにイベント内容を通知するか否かを事前に登録できるようになっている。そして、イベントが発生したとき、イベント内容を通知すべきクライアントが特定され、特定されたクライアントに対してイベント内容を示す情報が送信される。
【０００３】
また、イベント内容の通知に関して、次のような技術が提案されている。例えば、イベントごとに、イベントの発生を監視する周期を監視結果の通知対象となるクライアント数に応じて設定するようにしたイベント通知装置が提案されている。また、発生したイベントをイベントハンドラに非同期でレポートし、イベントハンドラによりイベントレポート基準にしたがってイベントディスパッチャに対してイベントをレポートするようにしたストレージシステムが提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−９７５８２号公報
【特許文献２】国際公開第２００６／１０４５３３号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、上記のように複数の送信先装置にイベント内容を送信する場合には、例えば、あるイベントが発生すると、そのイベント内容が各送信先装置に対して順次送信される。また、その後に別のイベントが発生すると、そのイベント内容が各送信先装置に対してさらに順次送信される。
【０００６】
このような処理では、ある送信先装置に対するデータ通信速度が低下して、その送信先装置に対するイベント内容の送信処理が遅延すると、後続のイベント内容の送信処理にも遅延が発生してしまう。このため、ある送信先装置に対するデータ送信速度の低下が、データ送信速度が低下していない他の送信先装置に対する送信処理にも影響を与えてしまい、その結果としてすべての送信先装置に対するデータ送信速度が低下してしまうという問題がある。
【０００７】
また、このような問題は、上記のようなイベント内容の送信処理に限らず、複数の送信先装置に対して次々にデータを送信する処理において発生し得る。
１つの側面では、本発明は、ある送信先装置に対するデータ送信速度が低下した場合における他の送信先装置に対するデータ送信速度の低下を抑制可能な送信制御装置および送信制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
１つの案では、次のような記憶部と制御部とを有する送信制御装置が提供される。記憶部は、複数の送信先装置のそれぞれに対応する制御値を記憶する。制御部は、複数の送信先装置のそれぞれに対するデータ送信に要した所要時間を測定し、所要時間に基づいて複数の送信先装置のそれぞれに対応する制御値を更新し、複数の送信先装置に対するデータ送信時に、制御値に基づき、所要時間が短い送信先装置が優先されるように複数の送信先装置に対するデータ送信順を決定する。
【０００９】
また、１つの案では、上記の送信制御装置と同様の処理をコンピュータに実行させる送信制御プログラムが提供される。
【発明の効果】
【００１０】
１つの側面では、ある送信先装置に対するデータ送信速度が低下した場合における他の送信先装置に対するデータ送信速度の低下を抑制できる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施の形態に係るデータ送信システムの構成例および処理例を示す図である。
【図２】第２の実施の形態に係るストレージシステムの構成例を示す図である。
【図３】ＣＭのハードウェア構成例を示す図である。
【図４】イベント通知処理手順の比較例を示す図である。
【図５】送信遅延が発生しなかった場合におけるデータ送信処理の比較例を示す図である。
【図６】送信遅延が発生した場合におけるデータ送信処理の比較例を示す図である。
【図７】ＣＭが備える処理機能の構成例を示す図である。
【図８】リスナ管理テーブルのデータ構成例を示す図である。
【図９】サブスクリプション情報のデータ構成例を示す図である。
【図１０】送信管理テーブルのデータ構成例を示す図である。
【図１１】送信管理データ生成部の処理を説明するための図である。
【図１２】送信管理データ生成部によるデータ生成処理を説明するための図である。
【図１３】キューイング制御部の処理を説明するための図である。
【図１４】送信制御部の処理を説明するための図である。
【図１５】イベント検出時の処理を示すフローチャートの例である。
【図１６】キューイング処理を示すフローチャートの例である。
【図１７】送信キューに基づく送信制御処理を示すフローチャートの例（その１）である。
【図１８】送信キューに基づく送信制御処理を示すフローチャートの例（その２）である。
【図１９】送信キューに基づく送信制御処理を示すフローチャートの例（その３）である。
【図２０】接続失敗時の処理を示すフローチャートの例である。
【図２１】接続先確認処理を示すフローチャートの例である。
【図２２】第２の実施の形態におけるデータ送信処理例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るデータ送信システムの構成例および処理例を示す図である。図１に示すデータ送信システムは、送信制御装置１０と、送信制御装置１０に接続された送信先装置２１〜２３を含む。なお、送信制御装置１０に接続される送信先装置の台数は図１のように３台に限定されるものではなく、２台以上の任意の台数の送信先装置を送信制御装置１０に接続させることができる。
【００１３】
送信制御装置１０は、送信先装置２１〜２３に対してデータを送信する装置である。送信制御装置１０は、記憶部１１と制御部１２を備える。なお、記憶部１１は、例えば、送信制御装置１０が備えるＲＡＭ（Random Access Memory）やＨＤＤ（Hard Disk Drive）などの記憶装置として実現される。制御部１２は、例えば、送信制御装置１０が備えるプロセッサとして実現される。
【００１４】
記憶部１１には、送信先装置２１〜２３のそれぞれに対応する制御値１１ａ〜１１ｃが記憶される。制御値１１ａ〜１１ｃは、送信制御装置１０から送信先装置２１〜２３のそれぞれに対するデータ送信に要した所要時間に基づいて設定される値である。
【００１５】
制御部１２は、送信先装置２１〜２３のそれぞれに対するデータ送信に要した所要時間を測定する。制御部１２は、測定された所要時間に基づいて制御値１１ａ〜１１ｃを更新する。図１の例では、制御部１２は、送信先装置２１に対するデータＤ１ａの送信に要した所要時間を測定し、この所要時間に基づいて送信先装置２１に対応する制御値１１ａを更新する。また、制御部１２は、送信先装置２２に対するデータＤ１ｂの送信に要した所要時間を測定し、この所要時間に基づいて送信先装置２２に対応する制御値１１ｂを更新する。さらに、制御部１２は、送信先装置２３に対するデータＤ１ｃの送信に要した所要時間を測定し、この所要時間に基づいて送信先装置２３に対応する制御値１１ｃを更新する。
【００１６】
その後、制御部１２は、送信先装置２１〜２３に対してそれぞれデータＤ２ａ〜Ｄ２ｃを送信する。この送信の際に、制御部１２は、制御値１１ａ〜１１ｃに基づき、測定された上記の所要時間が短い送信先装置が優先されるように、送信先装置２１〜２３に対するデータＤ２ａ〜Ｄ２ｃの送信順を決定する。
【００１７】
図１では例として、送信キュー１２ａが用いられるものとする。この場合、制御部１２は、制御値１１ａ〜１１ｃに基づき、データＤ２ａ〜Ｄ２ｃを送信するためのキューデータを送信キュー１２ａにキューイングする順序を決定する。例えば、送信先装置２１，２３，２２の順に所要時間が短い場合、制御部１２は、データＤ２ａ，Ｄ２ｃ，Ｄ２ｂの順に対応するキューデータを送信キュー１２ａにキューイングする。
【００１８】
これにより、データ送信時には、制御部１２はまず、送信キュー１２ａからデータＤ２ａに対応するキューデータを取り出し、このキューデータに基づいてデータＤ２ａを送信先装置２１に送信する。次に、制御部１２は、送信キュー１２ａからデータＤ２ｃに対応するキューデータを取り出し、このキューデータに基づいてデータＤ２ｃを送信先装置２３に送信する。次に、制御部１２は、送信キュー１２ａからデータＤ２ｂに対応するキューデータを取り出し、このキューデータに基づいてデータＤ２ｂを送信先装置２２に送信する。
【００１９】
以上の制御部１２の処理により、送信制御装置１０は、ある送信先装置に対するデータ送信速度が低下した場合に、そのことに起因して発生する、他の送信先装置に対するデータ送信速度の低下を抑制できる。
【００２０】
例えば、データＤ１ａ，Ｄ１ｂ，Ｄ１ｃの順に送信したとき、データＤ１ａ，Ｄ１ｃ，Ｄ１ｂの順に所要時間が短く、なおかつ、データＤ１ｃの所要時間が他と比較して大幅に長くなったとする。この場合に、次にデータＤ２ａ，Ｄ２ｂ，Ｄ２ｃの順に送信した場合、送信先装置２２に対するデータＤ２ｂの送信に長い時間がかかり、その次に送信先装置２３に対してデータＤ２ｃを送信するタイミングが大幅に遅延してしまう。すなわち、送信先装置２３に対する送信速度は特に低下していないにもかかわらず、送信先装置２２に対する送信速度の低下に起因して、送信先装置２３に対する送信処理に大きな遅延が発生してしまう。
【００２１】
これに対して、制御部１２による上記処理によれば、データＤ１ａ〜Ｄ１ｃの所要時間に基づいて、データＤ２ａ，Ｄ２ｃ，Ｄ２ｂの順に送信される。これにより、送信先装置２３に対するデータＤ２ｃの送信処理の際に特に遅延が発生しなくなる。このように、送信制御装置１０によれば、ある送信先装置に対するデータ送信速度の低下が、他の送信先装置に対するデータ送信速度に与える影響を低減できる。
【００２２】
〔第２の実施の形態〕
次に、図１の送信制御装置１０の一例としてストレージ制御装置を適用したストレージシステムについて説明する。
【００２３】
図２は、第２の実施の形態に係るストレージシステムの構成例を示す図である。図２に示すストレージシステムは、ＣＭ（Controller Module）１１０およびドライブ部１２０を備えたストレージ装置１００と、ホスト装置２０１，２０２，・・・と、管理装置３０１，３０２，３０３，・・・とを含む。なお、ＣＭ１１０は、図１の送信制御装置１０の一例であり、管理装置３０１，３０２，３０３，・・・は、図１の送信先装置２１〜２３の一例である。
【００２４】
ＣＭ１１０は、例えばＳＡＮ（Storage Area Network）を介して、ホスト装置２０１，２０２，・・・と接続されている。ＣＭ１１０は、ホスト装置２０１，２０２，・・・からの要求に応じて、ドライブ部１２０に搭載された記憶装置に対するアクセスを制御するストレージ制御装置である。
【００２５】
例えば、ＣＭ１１０は、ドライブ部１２０に搭載された記憶装置の記憶領域を用いた論理ボリュームを生成し、ホスト装置２０１，２０２，・・・から論理ボリュームに対するアクセスを受け付ける。また、この論理ボリュームは、仮想ボリュームとして生成されてもよい。この場合、ＣＭ１１０は、例えば、ドライブ部１２０に搭載された記憶装置の記憶領域を用いたストレージプールを生成する。ＣＭ１１０は、仮想ボリュームに対するデータの書き込み要求を受け付けると、そのデータの書き込み領域に対応する記憶領域をストレージプールから割り当てる。これにより、仮想ボリュームの領域のうちデータが書き込まれた領域に対してのみ、ストレージプールから記憶領域が割り当てられる。
【００２６】
また、ＣＭ１１０は、ＳＭＩ−Ｓで規定された非同期イベント通知を実現するサーバとしても動作する。ＣＭ１１０は、ストレージ制御に関する各種のイベントの発生を監視し、イベントが発生すると、発生したイベントの内容を示す「Indication」と呼ばれるイベント通知情報を、管理装置３０１，３０２，３０３，・・・に送信することができる。監視されるイベントとしては、例えば、論理ボリュームやストレージプールについての構成の変更、障害の発生などがある。
【００２７】
ドライブ部１２０には、ホスト装置２０１，２０２，・・・からのアクセス対象となる複数台の記憶装置が搭載されている。このような記憶装置としては、ＨＤＤ、ＳＳＤ（Solid State Drive）などの不揮発性記憶装置が用いられる。
【００２８】
ホスト装置２０１，２０２，・・・は、例えば、種々の業務処理を実行するサーバコンピュータである。ホスト装置２０１，２０２，・・・は、論理ボリュームに対するアクセス要求をＣＭ１１０に送信することで、論理ボリュームにアクセスする。
【００２９】
管理装置３０１，３０２，３０３，・・・は、ネットワーク３１０を介してＣＭ１１０に接続されている。ネットワーク３１０は、例えば、ＬＡＮ（Local Area Network）でもよいし、ＷＡＮ（Wide Area Network）やインターネットなどの広域ネットワークでもよい。
【００３０】
管理装置３０１，３０２，３０３，・・・は、ＳＭＩ−Ｓのイベント通知情報（Indication）を受信可能なクライアントとして動作する。ＳＭＩ−Ｓでは、このようなクライアントは「リスナ（Listener）」と呼ばれる。管理装置３０１，３０２，３０３，・・・は、ストレージ装置１００を管理するための装置であり、その管理のための処理の一環としてＣＭ１１０からイベント通知情報を受信する。管理装置３０１，３０２，３０３，・・・のそれぞれは、例えば、企業内の管理サーバや、管理者が操作する管理端末として実現される。管理端末としては、タブレット型端末などの可搬型の端末装置も含み得る。
【００３１】
図３は、ＣＭのハードウェア構成例を示す図である。ＣＭ１１０は、プロセッサ１１１、ＲＡＭ１１２、ＳＳＤ１１３、ホストインタフェース１１４、ドライブインタフェース１１５およびネットワークインタフェース１１６を備える。
【００３２】
プロセッサ１１１は、ＣＭ１１０全体を統括的に制御する。プロセッサ１１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。また、プロセッサ１１１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。
【００３３】
ＲＡＭ１１２は、ＣＭ１１０の主記憶装置として使用される。ＲＡＭ１１２には、プロセッサ１１１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１１２には、プロセッサ１１１による処理に必要な各種データが格納される。
【００３４】
ＳＳＤ１１３は、ＣＭ１１０の補助記憶装置として使用される。ＳＳＤ１１３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、ＨＤＤなどの他の種類の不揮発性記憶装置を使用することもできる。
【００３５】
ホストインタフェース１１４は、ホスト装置２０１，２０２，・・・と通信するための通信インタフェースである。ドライブインタフェース１１５は、ドライブ部１２０に搭載された記憶装置と通信するための通信インタフェースである。ネットワークインタフェース１１６は、ネットワーク３１０を介して管理装置３０１，３０２，３０３，・・・と通信するための通信インタフェースである。
【００３６】
以上のハードウェア構成によって、ＣＭ１１０の処理機能を実現できる。なお、図示しないが、ホスト装置２０１，２０２，・・・や管理装置３０１，３０２，３０３，・・・も、プロセッサや主記憶装置、補助記憶装置などを有するコンピュータとして実現可能である。
【００３７】
次に、図４〜図６を用いて、ＳＭＩ−Ｓの非同期イベント通知処理の比較例について説明する。なお、図４〜図６では、ＣＭ１１０から管理装置３０１，３０２，３０３，・・・に対してイベント通知情報が送信されるものとして説明する。
【００３８】
図４は、イベント通知処理手順の比較例を示す図である。なお、図４に示すリスナ＃１，＃２，＃３，・・・は、それぞれ管理装置３０１，３０２，３０３，・・・に対応する。
【００３９】
ＳＭＩ−Ｓの非同期イベント通知では、イベント通知情報の送信先となるリスナごとに、送信条件が「サブスクリプション（Subscription）」と呼ばれる情報に事前に登録される。送信条件は、どの種類のイベントのイベント通知情報をリスナに送信するかを示す。リスナごとに送信条件を任意に設定でき、これにより各リスナが必要としているイベント通知情報だけを送信できる。
【００４０】
サブスクリプションでは、イベントの種別は「フィルタ（Filter）」として規定される。図４に示すサブスクリプション情報１３１は、サブスクリプションの一例であり、リスナごとに、イベント通知情報を通知すべきイベントを示すフィルタが対応付けて登録されている。
【００４１】
ＣＭ１１０は、イベントの発生を検出すると、サブスクリプション情報１３１を検索し、発生したイベントに対応するイベント通知情報の送信先リスナを特定する（ステップＳ１１）。ＣＭ１１０には、リスナ別の送信キューである「リスナ別キュー」が用意されている。図４に示すリスナ別キュー１３２ａ，１３２ｂ，１３２ｃ，・・・は、それぞれリスナ＃１，＃２，＃３，・・・に対応する送信キューである。ＣＭ１１０は、送信先リスナを特定すると、リスナ別キュー１３２ａ，１３２ｂ，１３２ｃ，・・・のうち、特定された送信先リスナに対応するリスナ別キューに、送信されるイベント通知情報に対応するキューデータ（キューエントリ）を設定する。また、ＣＭ１１０は、発生したイベントに対応する送信データ（イベント通知情報）を送信先リスナごとに生成する。
【００４２】
また、ＣＭ１１０は、リスナ別キュー１３２ａ，１３２ｂ，１３２ｃ，・・・からキューデータを取り出して送信キュー１３３に設定（キューイング）する（ステップＳ１２）。送信キュー１３３は、リスナ＃１，＃２，＃３，・・・について共有される送信キューである。ＣＭ１１０は、例えば、リスナ別キュー１３２ａ，１３２ｂ，１３２ｃ，・・・を順番に走査しながら、それらの先頭のキューデータを取り出して送信キュー１３３に設定する。
【００４３】
そして、ＣＭ１１０は、送信キュー１３３の先頭からキューデータを順番に取り出し、取り出したキューデータに対応する送信データ（イベント通知情報）を送信先リスナに送信する（ステップＳ１３）。このように、リスナ別キュー１３２ａ，１３２ｂ，１３２ｃ，・・・と送信キュー１３３とを用いることで、リスナごとにイベントの発生順に各イベントに対応するイベント通知情報が送信される。
【００４４】
また、ステップＳ１３の送信制御では、それぞれ個別のイベント通知情報を送信するための送信処理タスクが、並行して複数実行される。送信先リスナが異なる送信処理タスクは、それぞれ個別のソケットを用いて実行される。ソケットは、ＯＳが備えるデータ送信機能をアプリケーションが利用するためのＡＰＩ（Application Programming Interface）である。図４では、ソケット＃１を用いた送信処理タスク＃１と、ソケット＃２を用いた送信処理タスク＃２とが並列に実行されている例を示している。
【００４５】
このソケットに関しては、ＯＳの仕様により、同時に使用可能なソケット数の上限が決められているとともに、１つのソケットは１つの通信先によって占有されるという制約がある。このため、上記のステップＳ１３の送信制御では、同時に使用可能なソケット数の範囲で、同時並行して動作可能な複数の送信処理タスクが設けられ、各送信処理タスクに１つのソケットが割り当てられる。そして、各送信処理タスクに対して、複数の送信先リスナが分配されて割り当てられる。したがって、各送信処理タスクでは、１つのソケットを使用して、接続先のリスナを切り替えながらデータ送信処理が実行される。
【００４６】
図５は、送信遅延が発生しなかった場合におけるデータ送信処理の比較例を示す図である。
この図５では、例として、同時に使用可能なソケット数が「２」であり、２つのソケットをそれぞれ用いて送信処理タスク＃１，＃２が実行されるものとする。また、例として、まず、イベント＃１の検出に伴って、イベント通知情報の送信先がリスナ＃１〜＃４と判定され、これらに対応するキューデータが送信キュー１３３に設定されたとする。また、イベント＃２の検出に伴って、イベント通知情報の送信先がリスナ＃１〜＃４と判定され、これらに対応するキューデータが送信キュー１３３に設定されたとする。さらに、イベント＃３の検出に伴って、イベント通知情報の送信先がリスナ＃１〜＃４と判定され、これらに対応するキューデータが送信キュー１３３に設定されたとする。
【００４７】
この場合、まず、送信処理タスク＃１により、イベント＃１に対応するイベント通知情報のリスナ＃１に対する送信処理が実行される。これと並行して、送信処理タスク＃２により、イベント＃１に対応するイベント通知情報のリスナ＃２に対する送信処理が実行される。
【００４８】
リスナ＃１に対する送信処理が遅延なく完了すると、次に、送信処理タスク＃１により、イベント＃１に対応するイベント通知情報のリスナ＃３に対する送信処理が実行される。この場合、送信処理タスク＃１では、接続先がリスナ＃１からリスナ＃３に切り替えられた後、リスナ＃３に対してイベント通知情報が送信される。
【００４９】
また、リスナ＃１に対する送信処理の完了後に、リスナ＃２に対する送信処理が遅延なく完了すると、次に、送信処理タスク＃２により、イベント＃１に対応するイベント通知情報のリスナ＃４に対する送信処理が実行される。この場合、送信処理タスク＃２では、接続先がリスナ＃２からリスナ＃４に切り替えられた後、リスナ＃４に対してイベント通知情報が送信される。
【００５０】
このようにして、送信処理タスク＃１，＃２によって、イベント＃１，＃２，＃３の検出に伴う送信処理が順次実行される。図５では例として、送信処理タスク＃１により、イベント＃２に対応するイベント通知情報のリスナ＃２に対する送信処理、同イベント通知情報のリスナ＃４に対する送信処理、イベント＃３に対応するイベント通知情報のリスナ＃１に対する送信処理、同イベント通知情報のリスナ＃３に対する送信処理が、続いて実行される。また、送信処理タスク＃２により、イベント＃２に対応するイベント通知情報のリスナ＃１に対する送信処理、同イベント通知情報のリスナ＃３に対する送信処理、イベント＃３に対応するイベント通知情報のリスナ＃２に対する送信処理、同イベント通知情報のリスナ＃４に対する送信処理が、続いて実行される。これにより、リスナごとに、イベント発生の順序性を維持したまま各イベントに対応するイベント通知情報が送信される。
【００５１】
しかしながら、上記のような送信制御が行われた場合、次のような問題がある。例えば、ある送信処理タスクによるあるリスナへのデータ送信の際に遅延が発生すると、その送信処理タスクを用いて次に実行される他のリスナへのデータ送信の実行開始タイミングが遅延してしまう。したがって、あるリスナへのデータ送信の際に遅延が発生したとき、他のリスナへのデータ送信が正常に可能な状態であったとしても、他のリスナへのデータ送信も遅延してしまう。このように、１つのリスナに対する送信遅延が他のリスナへのデータ送信にも影響を与えてしまい、全体として大きな送信遅延が発生してしまうという問題がある。
【００５２】
図６は、送信遅延が発生した場合におけるデータ送信処理の比較例を示す図である。この図６では、図５と同様のイベント＃１，＃２，＃３が検出されたものとする。
図６の例では、送信処理タスク＃２では、イベント＃１に対応するイベント通知情報のリスナ＃２に対する送信処理の際にタイムアウトが発生したとする。この場合、例えば、送信処理タスク＃１により、同イベント通知情報のリスナ＃３に対する送信処理後に、同イベント通知情報のリスナ＃２に対する再送が行われる。このため、送信処理タスク＃１に対して、イベント＃２に対応するイベント通知情報の送信処理が割り当てられるまでの時間が長くなり、このイベント通知情報の送信処理にも遅延が発生してしまう。
【００５３】
また、図６の例では、送信処理タスク＃１において、イベント＃１に対応するイベント通知情報のリスナ＃３に対する送信処理の際にタイムアウトが発生したとする。また、図６では、このタイムアウトの発生タイミングの関係で、送信処理タスク＃２において、イベント＃２に対応するイベント通知情報のリスナ＃１に対する送信が完了した後に、イベント＃１に対応するイベント通知情報のリスナ＃３に対する再送が行われる。このため、送信処理タスク＃２でも、イベント＃２に対応するイベント通知情報についての、リスナ＃１以外の他のリスナに対する送信処理に遅延が発生してしまう。
【００５４】
さらに、図６の例では、イベント＃１に対応するイベント通知情報のリスナ＃２，＃３への再送の際にもタイムアウトが発生している。これにより、後続の送信処理にも大きな影響が及んでしまう。当然ながら、イベント＃２だけでなくイベント＃３に対応するイベント通知情報の送信開始タイミングも遅延してしまう。
【００５５】
イベント通知情報の送信先となるリスナとしては、管理サーバのように継続的に安定して通信可能な装置だけでなく、管理者が携帯する携帯型端末のようにネットワークに常時接続されているとは限らない装置も含み得る。このため、後者のようなリスナとの間の通信状態が悪化すると、前者のようなリスナに対する送信速度を大幅に低下させてしまう可能性がある。
【００５６】
このような課題に鑑み、本実施の形態のＣＭ１１０では、あるリスナに対する送信遅延が発生した場合でも、その送信遅延が正常に通信可能な他のリスナに対する送信処理に与える影響が抑制されるような送信制御が行われる。すなわち、あるリスナに対する送信遅延が発生した場合でも、正常に通信可能な他のリスナに対する送信速度ができるだけ維持されるような送信制御が行われる。これとともに、送信遅延が発生したリスナについても、一定間隔で確実にイベント通知情報の再送が行われるようにして、そのリスナに対してイベント通知情報が送信される確実性が高められるような送信制御が行われる。
【００５７】
図７は、ＣＭが備える処理機能の構成例を示す図である。ＣＭ１１０は、記憶部１３０、Ｉ／Ｏ（Input／Output）制御部１４１、イベント検出部１４２、送信管理データ生成部１４３、キューイング制御部１４４および送信制御部１４５を備える。
【００５８】
記憶部１３０は、例えば、ＲＡＭ１１２やＳＳＤ１１３などのＣＭ１１０が備える記憶装置の記憶領域によって実現される。記憶部１３０には、前述のサブスクリプション情報１３１の他、リスナ管理テーブル１３４と送信管理テーブル１３５が記憶される。なお、図示しないが、記憶部１３０には、図４に示した送信キュー１３３も記憶される。
【００５９】
ここで、図８を用いて、リスナ管理テーブル１３４に保持されるデータについて説明する。図８は、リスナ管理テーブルのデータ構成例を示す図である。
リスナ管理テーブル１３４には、リスナに関する情報が保持される。図８に示すように、リスナ管理テーブル１３４には、リスナを識別するためのリスナ番号に対して、リスナ名、ＩＰ（Internet Protocol）アドレスおよびプロトコルが記録される。リスナ名は、リスナの名称を示す。ＩＰアドレスは、ネットワーク３１０におけるリスナのアドレスを示す。プロトコルは、リスナとの通信に用いられる通信プロトコルを示す。
【００６０】
次に、図９を用いて、サブスクリプション情報１３１に保持されるデータについて説明する。図９は、サブスクリプション情報のデータ構成例を示す図である。
前述のように、サブスクリプション情報１３１には、どの種類のイベントのイベント通知情報を送信するかを示す送信条件が、リスナごとに記録される。図９に示すように、サブスクリプション情報１３１には、イベントの名称を示すイベント名およびイベントに対応するフィルタを示すフィルタ名に対して、リスナごとの送信設定フラグが対応付けて記録されている。送信設定フラグは、フィルタに対応するイベント通知情報を対応するリスナに送信する場合、「１」に設定され、そのイベント通知情報を対応するリスナに送信しない場合、「０」に設定される。
【００６１】
したがって、ＣＭ１１０は、フィルタ名を検索キーとしてサブスクリプション情報１３１を検索し、そのフィルタ名に対応付けられた送信設定フラグのビット列を取得することで、イベント通知情報をどのリスナに送信すべきかを認識できる。例えば、図９では、「ボリューム作成」というイベントに対して、「１００１１０・・・」という送信設定フラグのビット列が対応付けられている。これは、「ボリューム作成」というイベントが検出された場合、そのイベントに対応するイベント通知情報がリスナ＃１，＃４，＃５に送信されることを示す。
【００６２】
なお、図９の例では、イベント名「ボリューム作成」は、新たに論理ボリュームが作成されたというイベントを示す。イベント名「ボリューム削除」は、論理ボリュームが削除されたというイベントを示す。イベント名「ボリューム状態変更」は、論理ボリュームの処理状態が変更されたというイベントを示す。例えば、論理ボリュームに対する書き込みエラーが発生し、その論理ボリュームの動作状態を示すエラーモードが正常状態からエラー状態を示すように変更された場合に、「ボリューム状態変更」のイベントが発生したと判定される。
【００６３】
イベント名「プール作成」は、新たにストレージプールが作成されたというイベントを示す。イベント名「プール削除」は、ストレージプールが削除されたというイベントを示す。イベント名「プール容量不足」は、ストレージプールの容量が不足した（残容量が一定のサイズＳ１以下になった）ことを示すイベントである。イベント名「プール容量枯渇」は、ストレージプールの残容量がほとんどなくなった（サイズＳ１より小さいサイズＳ２以下になった）ことを示すイベントである。
【００６４】
次に、図１０を用いて、送信管理テーブル１３５に保持されるデータについて説明する。図１０は、送信管理テーブルのデータ構成例を示す図である。
送信管理テーブル１３５は、送信先となり得るリスナ別に存在し、記憶部１３０に記憶される。図１０に示す送信管理テーブル１３５ａ，１３５ｂ，１３５ｃ，・・・は、それぞれ個別のリスナに対応している。送信管理テーブル１３５ａ，１３５ｂ，１３５ｃ，・・・のそれぞれには、リスナ番号、有効フラグ、送信シリアル番号、次回送信可能時刻、処理許容時間、送信失敗回数、リトライ間隔、送信データリストが記録される。
【００６５】
リスナ番号は、リスナを識別するための識別番号を示す。有効フラグは、リスナに対するデータ送信を停止しているか否かを示す。有効フラグが「１」の場合、データ送信が停止されていないことを示し、有効フラグが「０」の場合、データ送信が停止されていることを示す。なお、初期状態では、有効フラグは「１」に設定される。送信シリアル番号は、リスナに対して最後に実行されたデータ送信処理を識別するための識別番号を示す。
【００６６】
次回送信可能時刻は、リスナに対する次回のイベント通知情報の送信が可能になる時刻を示す。処理許容時間は、リスナに接続してイベント通知情報の送信処理を継続可能な許容時間を示す。
【００６７】
処理許容時間は、直近のリスナに対するイベント通知情報の送信処理において１つのイベント通知情報の送信にかかった時間の平均値に、イベント通知情報についての規定の個数を乗算することで算出される。処理許容時間内では、同じリスナに接続したまま、そのリスナに対してイベント通知情報を連続して送信可能になる。なお、初期状態では、あらかじめ決められた最大処理許容時間が、処理許容時間として設定される。
【００６８】
次回送信可能時刻には、リスナへのイベント通知情報の送信処理が実行されて処理許容時間が算出されるたびに、その送信処理の開始時刻に処理許容時間を加算した時刻が設定される。リスナへのイベント通知情報の送信処理が短時間で完了すると、次回送信可能時刻までの時間が短くなり、そのリスナについて短い間隔で次の送信処理が実行されるようになる。これにより、送信速度が高いリスナに対して優先的にイベント通知情報が送信されるようになる。一方、リスナへのイベント通知情報の送信処理に長い時間がかかると、次回送信可能時刻までの時間が長くなり、そのリスナに対するイベント通知情報の送信が長い間隔を空けて実行されるようになる。
【００６９】
送信失敗回数は、リスナに対するイベント通知情報の送信に失敗した回数の累積値を示す。なお、初期状態では、送信失敗回数は「０」に設定される。リトライ間隔は、リスナに対するイベント通知情報の送信に失敗した後、そのイベント通知情報の再送が行われるまでの時間間隔を示す。なお、初期状態では、リトライ間隔はあらかじめ決められた初期値に設定される。
【００７０】
送信データリストは、図４に示したリスナ別の送信キューであるリスナ別キュー１３２ａ，１３２ｂ，１３２ｃ，・・・として使用される。送信データリストには、ＦＩＦＯ（First In First Out）方式により、リスナ別キューのキューデータとしてアドレスが記録される。このアドレスは、送信管理データが記録された場所を示す。送信管理データは、イベントが検出されるたびに生成される情報である。図１０の例では、アドレスＡＤＲ１が送信管理データ１３６ａのアドレスを示し、アドレスＡＤＲ２が送信管理データ１３６ｂのアドレスを示す。
【００７１】
送信管理データには、生成時刻、ビットマップアドレス、雛形データアドレスが記録される。生成時刻は、送信管理データが生成された時刻を示す。ビットマップアドレスは、検出されたイベントに対応する送信管理ビットマップが記録された位置を示す。雛形データアドレスは、検出されたイベントに対応する送信雛形データが記録された位置を示す。後述するように、送信管理ビットマップと送信雛形データも、送信管理データと同様にイベントが検出されるたびに生成される。
【００７２】
以下、図７に戻って説明を続ける。
Ｉ／Ｏ制御部１４１、イベント検出部１４２、送信管理データ生成部１４３、キューイング制御部１４４および送信制御部１４５の処理は、例えば、プロセッサ１１１が所定のプログラムを実行することで実現される。
【００７３】
Ｉ／Ｏ制御部１４１は、ドライブ部１２０に搭載された記憶装置の記憶領域を用いて論理ボリュームを生成する。そして、Ｉ／Ｏ制御部１４１は、ホスト装置２０１，２０２，・・・からのアクセス要求に応じて、論理ボリュームに対するアクセス処理を制御する。また、前述のように、論理ボリュームは、仮想ボリュームとして生成されてもよい。
【００７４】
イベント検出部１４２は、Ｉ／Ｏ制御部１４１において発生する、ストレージ制御に関する各種のイベントを監視する。イベント検出部１４２は、イベントの発生を検出すると、そのイベントに対応するフィルタ名とイベントの内容を示す内容情報とともに送信管理データ生成部１４３に通知する。
【００７５】
次に、図１１を用いて、送信管理データ生成部１４３の処理について説明する。
図１１は、送信管理データ生成部の処理を説明するための図である。なお、図１１では例として、イベント通知情報の送信先となり得るリスナとしてリスナ＃１〜＃６が存在するものとする。また、図１１に示すリスナ別キュー１３２ａ〜１３２ｆは、それぞれリスナ＃１〜＃６に対応するリスナ別キューである。この場合、図１０で説明したように、リスナ別キュー１３２ａ〜１３２ｆは、それぞれリスナ＃１〜＃６に対応する送信管理テーブルの送信データリストに相当する。
【００７６】
送信管理データ生成部１４３は、イベント検出部１４２からフィルタ名とイベントの内容情報の通知を受けると、サブスクリプション情報１３１から、通知されたフィルタ名に対応付けられた送信設定フラグのビット列を取得する。送信管理データ生成部１４３は、取得したビット列に基づいて、通知されたフィルタ名に対応する送信先リスナ、すなわち、検出されたイベントに対応するイベント通知情報を送信すべきリスナを特定する。この処理では、取得したビット列において送信設定フラグが「１」に設定されているリスナが、送信先リスナとして特定される。図１１の例では、リスナ＃１，＃３，＃４が送信先リスナとして特定された場合を示している。
【００７７】
また、送信管理データ生成部１４３は、図１０に示した送信管理データと、送信管理ビットマップおよび送信雛形データを生成する。ここで、図１２を用いて、送信管理データ生成部１４３によるデータ生成処理について説明する。
【００７８】
図１２は、送信管理データ生成部によるデータ生成処理を説明するための図である。
送信管理データ生成部１４３は、送信管理データ１３６を生成して、記憶部１４０に記録する。図１０に示したように、送信管理データ１３６には、生成時刻、ビットマップアドレスおよび雛形データアドレスが記録される。生成時刻としては、この送信管理データ１３６が生成された時刻、すなわち、対応するイベントの発生が検出された時刻が記録される。
【００７９】
また、前述のように、送信管理データ生成部１４３は、イベント検出部１４２からフィルタ名とイベントの内容情報の通知を受けると、サブスクリプション情報１３１から、通知されたフィルタ名に対応付けられた送信設定フラグのビット列を取得する。送信管理データ生成部１４３は、取得したビット列を送信管理ビットマップ１３７として記憶部１３０に記録し、その記録先のアドレスを送信管理データ１３６におけるビットマップアドレスの項目に設定する。送信管理ビットマップ１３７は、対応するイベント通知情報が送信先リスナに送信されたか否かを管理するために利用される。
【００８０】
さらに、送信管理データ生成部１４３は、検出されたイベントに対応するイベント通知情報を生成するための送信雛形データ１３８を生成し、記憶部１３０に記録する。このとき、送信管理データ生成部１４３は、送信雛形データ１３８の記録先のアドレスを送信管理データ１３６における雛形データアドレスの項目に設定する。
【００８１】
イベント通知情報は、イベントごとに定型的な形式を有しているので、記憶部１４０には、イベントごとに雛形データがあらかじめ用意されている。これらの雛形データでは、可変情報の設定欄がすべて空欄になっている。一方、送信雛形データ１３８では、これらの可変情報の設定欄のうち、特定の設定欄のみが空欄になっており、残りの設定欄にはイベント検出部１４２から通知されたイベントの内容情報に基づいて可変情報が設定される。空欄とされる特定の設定欄とは、送信先リスナごとに異なる情報が設定される設定欄である。
【００８２】
例えば、「ボリューム状態変更」というイベントが検出された場合、可変情報として、状態が変更された論理ボリュームの識別番号や、状態変更の内容を示す情報（例えば、変更後のエラーモード）が、そのイベントに対応する雛形データ内の該当する設定欄に設定される。一方、イベント通知情報の送信ごとの通し番号を示すシーケンス番号（図１２中の「SequenceNumber」）の設定欄は、空欄のまま（あるいは、空欄を示す特定の文字列）とされる。このようにして送信雛形データ１３８が生成される。送信雛形データ１３８が生成されることで、各送信先リスナに送信するイベント通知情報を生成する際に、対応する送信雛形データ１３８を読み出し、送信雛形データ１３８内の特定の設定欄に情報を設定するだけで、イベント通知情報を生成できるようになる。
【００８３】
以下、図１１に戻って説明を続ける。
送信管理データ生成部１４３は、リスナ別キュー１３２ａ〜１３２ｆのうち、検出されたイベントに対応するイベント通知情報の送信先リスナ（ここではリスナ＃１，＃３，＃４）に対応するリスナ別キュー１３２ａ，１３２ｃ，１３２ｄに対して、キューデータを設定する。これらのキューデータとしては、生成された送信管理データ１３６の記録場所を示すアドレスが設定される。
【００８４】
以上の図１１、図１２に示したように、イベントの発生が検出されるたびに、送信管理データ１３６、送信管理ビットマップ１３７および送信雛形データ１３８が生成される。送信管理データ１３６は、送信管理ビットマップ１３７および送信雛形データ１３８に対するリンク情報（ビットマップアドレス、雛形データアドレス）を保持している。そして、生成された送信管理データ１３６に対するリンク情報（アドレス）が、キューデータとして、イベント通知情報の送信先リスナに対応するリスナ別キューにキューイングされる。
【００８５】
次に、図１３を用いて、キューイング制御部１４４の処理について説明する。
図１３は、キューイング制御部の処理を説明するための図である。なお、図１３では例として、図１１の場合と同様に、イベント通知情報の送信先となり得るリスナとしてリスナ＃１〜＃６が存在するものとする。
【００８６】
キューイング制御部１４４は、送信キュー１３３へのキューイング処理を繰り返し実行する。キューイング処理は、例えば、一定時間間隔で実行される。キューイング処理では、各リスナに対応する送信管理テーブル１３５の記録場所を示すアドレスが、キューデータとして送信キュー１３３に設定される。以下、このアドレスを「テーブルアドレス」と記載する。図１３では、テーブルアドレス１３３ａ〜１３３ｆは、それぞれリスナ＃１〜＃６に対応する送信管理テーブル１３５のアドレスを示している。なお、これらのテーブルアドレス１３３ａ〜１３３ｆは、実質的にリスナ＃１〜＃６を識別する情報となっている。
【００８７】
キューイング処理では、キューイング制御部１４４は、リスナ＃１〜＃６のすべてについてテーブルアドレスを送信キュー１３３にキューイングするか否かを判定する。そして、キューイング制御部１４４は、キューイングすると判定したリスナについて、テーブルアドレスを送信キュー１３３に設定する順序を決定する。
【００８８】
このような判定および決定のために、キューイング制御部１４４は、リスナ＃１〜＃６にそれぞれ対応する送信管理テーブル１３５に設定された次回送信可能時刻を参照する。キューイング制御部１４４は、まず、リスナ＃１〜＃６のうち、次回送信可能時刻が現時刻以前になっている（現時刻が次回送信可能時刻に達している）リスナについて、送信キュー１３３にキューイングすると判定する。
【００８９】
図１３では、現時刻をＴとしてリスナ＃１〜＃６の次回送信可能時刻を示している。図１３の例では、リスナ＃１〜＃５の次回送信可能時刻が現時刻Ｔ以前になっているが、リスナ＃６の次回送信可能時刻は現時刻Ｔより後になっている。このため、リスナ＃１〜＃５に対応するテーブルアドレス１３３ａ〜１３３ｅはキューイング対象として判定される。一方、リスナ＃６に対応するテーブルアドレス１３３ｆはキューイングされない。
【００９０】
次に、キューイング制御部１４４は、キューイング対象として判定されたテーブルアドレス１３３ａ〜１３３ｅについて、次回送信可能時刻が早い順に送信キュー１３３に設定する。図１３の例では、リスナ＃１に対応するテーブルアドレス１３３ａ、リスナ＃３に対応するテーブルアドレス１３３ｃ、リスナ＃４に対応するテーブルアドレス１３３ｄ、リスナ＃２に対応するテーブルアドレス１３３ｂ、リスナ＃５に対応するテーブルアドレス１３３ｅの順に、送信キュー１３３にキューイングされる。
【００９１】
ここで、あるリスナの次回送信可能時刻は、そのリスナに対する前回のイベント通知情報の送信処理の開始時刻に、処理許容時間を加算した時刻である。また、処理許容時間は、前回の送信処理において１つのイベント通知情報の送信にかかった時間の平均値に、イベント通知情報についての規定の個数を乗算することで算出される。したがって、次回送信可能時刻が早いリスナほど、高速な通信が可能なリスナであると推定される。
【００９２】
キューイング制御部１４４による上記のキューイング処理では、次回送信可能時刻が早いリスナに対応するテーブルアドレスほど、送信キュー１３３に対して先にキューイングされる。これにより、高速な通信が可能なリスナに対して優先的にイベント通知情報が送信されるようになる。
【００９３】
一方、現時刻が次回送信可能時刻に達していないリスナについては、送信キュー１３３に対するキューイングが行われない。このような制御により、各リスナに対しては、処理許容時間分の間隔を空けて送信処理が実行されるようになる。その結果、例えば、送信処理に長い時間がかかったリスナについては、その後にある程度長い時間間隔を空けて送信処理が実行されるようになる。
【００９４】
このようにして、高速な通信が可能なリスナに対しては、その速度をできるだけ維持したまま送信処理が実行される一方、送信速度が低下しているリスナに対しては、ある程度時間間隔を空けて送信処理が実行されるようになる。その結果、あるリスナへの送信速度が低下した場合でも、その速度低下の影響が、送信速度の高いリスナに対する送信処理に与える影響を低減できる。
【００９５】
また、送信速度が低下したリスナについても、そのまま送信処理の実行が停止されるのではなく、時間間隔を空けて送信処理が確実に再実行される。このため、送信速度が低下したリスナに対してイベント通知情報が送信される確実性を高めることができる。例えば、あるリスナに対する送信速度が一時的に低下した場合でも、時間間隔を空けた後にそのリスナに対するイベント通知情報の送信をリトライする機会が必ず与えられる。このため、リトライのタイミングでは送信速度が回復していた場合、そのリスナに対してイベント通知情報を確実に送信できる。
【００９６】
次に、図１４を用いて、送信制御部１４５の処理について説明する。図１４は、送信制御部の処理を説明するための図である。
送信制御部１４５は、基本的に、送信キュー１３３の先頭からキューデータを１つずつ取得し、取得したキューデータに対応するイベント通知情報をリスナに送信する。図１３に示したように、送信キュー１３３のキューデータは、送信管理テーブル１３５の記録場所を示すテーブルアドレスである。したがって、送信制御部１４５は、取得したテーブルアドレスに基づいて送信管理テーブル１３５を参照する。
【００９７】
図１４では、送信キュー１３３から取得したテーブルアドレスがリスナ＃１に対応するテーブルアドレスであったものとする。この場合、送信制御部１４５は、取得したテーブルアドレスに基づき、リスナ＃１に対応する送信管理テーブル１３５ａを参照する。送信制御部１４５は、送信管理テーブル１３５ａの送信データリスト（リスナ別キュー）から、キューデータとして先頭のアドレスＡＤＲ１を取得する。送信制御部１４５は、取得したアドレスＡＤＲ１が示す送信管理データ１３６を参照し、その送信管理データ１３６に記録された雛形データアドレスに基づいて、送信雛形データ１３８を取得する。送信制御部１４５は、送信雛形データ１３８における特定の設定欄に、送信先リスナに応じた情報を設定する。図１１に示した例では、イベント通知情報の送信ごとの通し番号がシーケンス番号の設定欄に設定される。これによってイベント通知情報１４５ａが生成され、送信制御部１４５は、生成されたイベント通知情報１４５ａをリスナ＃１に対して送信する。
【００９８】
また、例えば、上記送信処理の開始時から送信管理テーブル１３５ａに設定された処理許容時間（図示せず）が経過する前に、イベント通知情報１４５ａの送信が完了したとする。この場合、送信制御部１４５は、送信管理テーブル１３５ａの送信データリスト（リスナ別キュー）から次のアドレスＡＤＲ２を取得し、上記と同様の手順で、アドレスＡＤＲ２に対応するイベント通知情報を生成してリスナ＃１に送信する。
【００９９】
このように、送信制御部１４５は、送信許容時間の範囲内で、同じリスナに対してイベント通知情報を連続して送信できる。例えば、リスナ＃１に対する送信速度が低下して、リスナ＃１に対応する送信許容時間が長く設定されたとする。また、その速度低下が一時的なものであり、送信制御部１４５が次にリスナ＃１に対応するキューデータを送信キュー１３３から取得したときに、送信速度が回復していたとする。この場合、送信制御部１４５は、長く設定されている送信許容時間の中で、リスナ別キューに蓄積されたキューデータに対応するイベント通知情報を連続してリスナ＃１に送信できる。したがって、一時的な速度低下によって送信待ち状態になった多数のイベント通知情報を、通信速度の回復時に一度に送信できる。
【０１００】
次に、ＣＭ１１０の処理についてフローチャートを用いて説明する。
図１５は、イベント検出時の処理を示すフローチャートの例である。
［ステップＳ２１］イベント検出部１４２は、Ｉ／Ｏ制御部１４１において発生する、ストレージ制御に関する各種のイベントを監視する。イベント検出部１４２は、イベントの発生を検出すると、そのイベントに対応するフィルタ名とイベントの内容を示す内容情報とともに送信管理データ生成部１４３に通知する。そして、処理がステップＳ２２に進められる。
【０１０１】
［ステップＳ２２］送信管理データ生成部１４３は、イベント検出部１４２から通知されたフィルタ名に対応付けられた送信設定フラグのビット列を、サブスクリプション情報１３１から取得する。送信管理データ生成部１４３は、取得したビット列に基づいて、通知されたフィルタ名に対応する送信先リスナ、すなわち、検出されたイベントに対応するイベント通知情報を送信すべきリスナを特定する。
【０１０２】
［ステップＳ２３］送信管理データ生成部１４３は、送信管理データ１３６を生成して、記憶部１４０に記録する。送信管理データ生成部１４３は、送信管理データ１３６における生成時刻の項目に、現在の時刻を設定する。
【０１０３】
また、送信管理データ生成部１４３は、ステップＳ２２でサブスクリプション情報１３１から取得したビット列を送信管理ビットマップ１３７として記憶部１３０に記録する。送信管理データ生成部１４３は、送信管理ビットマップ１３７の記録先のアドレスを送信管理データ１３６におけるビットマップアドレスの項目に設定する。
【０１０４】
さらに、送信管理データ生成部１４３は、検出されたイベントに対応するイベント通知情報を生成するための送信雛形データ１３８を生成し、記憶部１３０に記録する。送信管理データ生成部１４３は、送信雛形データ１３８の記録先のアドレスを送信管理データ１３６における雛形データアドレスの項目に設定する。
【０１０５】
［ステップＳ２４］送信管理データ生成部１４３は、ステップＳ２２で特定された送信先リスナの中から、未処理の送信先リスナを選択する。
［ステップＳ２５］送信管理データ生成部１４３は、ステップＳ２４で選択された送信先リスナに対応する送信管理テーブル１３５を参照し、この送信管理テーブル１３５から有効フラグの値を取得する。送信管理データ生成部１４３は、有効フラグの値が「１」の場合、ステップＳ２６の処理を実行し、有効フラグの値が「０」の場合、ステップＳ２７の処理を実行する。
【０１０６】
［ステップＳ２６］送信管理データ生成部１４３は、ステップＳ２５で参照された送信管理テーブル１３５における送信データリスト（リスナ別キュー）の末尾に、キューデータとしてステップＳ２３で生成された送信管理データ１３６の記録先のアドレスを設定（キューイング）する。
【０１０７】
［ステップＳ２７］このケースでは、選択された送信先リスナに対するデータ送信が停止された状態になっている。この場合、送信データリスト（リスナ別キュー）へのキューイングが行われず、対応するイベント通知情報は選択された送信先リスナに送信されない。送信管理データ生成部１４３は、ステップＳ２３で生成された送信管理ビットマップ１３７のビットのうち、選択された送信先リスナに対応するビットの値を「０」に更新する。
【０１０８】
［ステップＳ２８］送信管理データ生成部１４３は、ステップＳ２２で特定された送信先リスナのすべてについて、ステップＳ２４〜Ｓ２７の処理を実行したかを判定する。送信管理データ生成部１４３は、未処理の送信先リスナがある場合、処理をステップＳ２４に進め、未処理の送信先リスナの１つについてステップＳ２４，Ｓ２５の処理を実行する。一方、送信管理データ生成部１４３は、すべての送信先リスナについて処理済みの場合、処理を終了する。
【０１０９】
図１６は、キューイング処理を示すフローチャートの例である。なお、図１６の処理は、例えば、一定時間間隔で実行される。
［ステップＳ３１］キューイング制御部１４４は、リスナ管理テーブル１３４に記録されたすべてのリスナに対応する送信管理テーブル１３５を参照し、各送信管理テーブル１３５から次回送信可能時刻を取得する。
【０１１０】
［ステップＳ３２］キューイング制御部１４４は、リスナ管理テーブル１３４に記録されているリスナの中から、次回送信可能時刻が現時刻以前になっている（現時刻が次回送信可能時刻に達している）リスナを、キューイング対象のリスナとして特定する。
【０１１１】
［ステップＳ３３］キューイング制御部１４４は、ステップＳ３２でキューイング対象として特定されたリスナに対応するキューデータを、次回送信可能時刻が早い順に送信キュー１３３に設定（キューイング）する。設定されるキューデータは、各リスナに対応する送信管理テーブル１３５の記録場所を示すテーブルアドレスである。
【０１１２】
図１７〜図１９は、送信キューに基づく送信制御処理を示すフローチャートの例である。なお、図１７の処理は、利用可能なソケットが存在する場合に実行される。例えば、ある送信先リスナとの接続が切断されて、利用可能なソケットが発生した場合に、そのソケットを利用して図１７の処理が実行される。
【０１１３】
［ステップＳ４１］送信制御部１４５は、送信キュー１３３の先頭からキューデータ（テーブルアドレス）を１つ取り出す。
［ステップＳ４２］前述のように、送信キュー１３３から取り出されたキューデータ（テーブルアドレス）は、イベント通知情報の送信先リスナに対応する送信管理テーブル１３５の記録場所を示す。送信制御部１４５は、取り出されたキューデータに基づいて送信管理テーブル１３５を参照し、この送信管理テーブル１３５の送信データリスト（リスナ別キュー）に、キューデータ（アドレス）が存在するかを判定する。送信制御部１４５は、キューデータが１つ以上存在する場合、ステップＳ４４の処理を実行し、キューデータが存在しない場合、ステップＳ４３の処理を実行する。
【０１１４】
［ステップＳ４３］ステップＳ４２で「Ｎｏ」と判定された場合、送信先リスナに対するイベント通知情報の送信失敗回数が所定の閾値以上となったために、この送信先リスナに対する送信処理が停止されている可能性がある。このケースとは、後の図２０のステップＳ９０〜Ｓ９２が実行されたケースに相当する。そこで、送信制御部１４５は、送信先リスナに対するデータ送信が可能かを判定するための接続先確認処理を実行する。接続先確認処理の内容については、後の図２１において説明する。接続先確認処理が終了すると、送信制御処理は終了する。
【０１１５】
［ステップＳ４４］送信制御部１４５は、ソケットを利用するための関数を用いて、ＯＳに対して送信先リスナとの接続を依頼する。これにより、ソケットを用いて送信先リスナと接続される。
【０１１６】
［ステップＳ４５］送信制御部１４５は、送信先リスナとの接続に成功したかを判定する。送信制御部１４５は、接続に成功した場合、図１８のステップＳ５１の処理を実行し、接続に失敗した場合、ステップＳ４６の処理を実行する。
【０１１７】
［ステップＳ４６］送信制御部１４５は、接続失敗時の処理を実行する。この処理内容については、後の図２０において説明する。接続失敗時の処理が終了すると、送信制御処理は終了する。
【０１１８】
以下、図１８を用いて説明を続ける。
［ステップＳ５１］送信制御部１４５は、ステップＳ４１で送信キュー１３３から取り出されたキューデータ（テーブルアドレス）が示す送信管理テーブル１３５を参照する。送信制御部１４５は、この送信管理テーブル１３５から、送信データリスト（リスナ別キュー）に設定された先頭のキューデータ（アドレス）を取得する。なお、この段階では、取得されたキューデータは送信データリストに残され、削除されない。
【０１１９】
送信制御部１４５は、取得されたキューデータが示す送信管理データ１３６を参照し、その送信管理データ１３６に記録された雛形データアドレスに基づいて、送信雛形データ１３８を取得する。送信制御部１４５は、取得された送信雛形データ１３８における特定の設定欄に送信先リスナに応じた情報を設定することで、送信先リスナ宛てのイベント通知情報を生成し、生成されたイベント通知情報を、ステップＳ４４での接続先の送信先リスナに対して送信する。
【０１２０】
［ステップＳ５２］送信制御部１４５は、イベント通知情報の送信が正常に完了したかを判定する。送信制御部１４５は、送信が正常に完了した場合、ステップＳ５３の処理を実行し、送信が完了しなかった場合、図１９のステップＳ７１の処理を実行する。なお、送信が完了しない場合としては、例えば、送信が完了する前に送信先リスナとの接続が切断された場合や、タイムアウトになった場合などがある。
【０１２１】
［ステップＳ５３］送信制御部１４５は、ステップＳ５１で参照された送信管理データ１３６からビットマップアドレスを取得し、ビットマップアドレスが示す送信管理ビットマップ１３７を参照する。送信制御部１４５は、参照先の送信管理ビットマップ１３７のビットのうち、送信先リスナに対応するビットのビット値を「０」にクリアする。また、送信制御部１４５は、ステップＳ５１で送信データリスト（リスナ別キュー）から取得されたキューデータを、送信データリストから削除する。
【０１２２】
［ステップＳ５４］送信制御部１４５は、ステップＳ５３でビット値が更新された送信管理ビットマップ１３７を用いて、次のようなビットマップチェック処理を実行する。
送信制御部１４５は、更新後の送信管理ビットマップ１３７のすべてのビットのビット値が「０」の場合、この送信管理ビットマップ１３７を記憶部１３０から削除する。これとともに、送信制御部１４５は、ステップＳ５１で参照された送信雛形データ１３８を記憶部１３０から削除する。さらに、送信制御部１４５は、ステップＳ５１で参照された送信管理データ１３６を記憶部１３０から削除する。これにより、送信されたイベント通知情報が示すイベントの検出時に生成された送信管理データ１３６、送信管理ビットマップ１３７および送信雛形データ１３８が消去され、このイベントについてのイベント通知処理が完了する。
【０１２３】
一方、送信制御部１４５は、更新後の送信管理ビットマップ１３７の中にビット値が「１」のビットが１つでも存在する場合には、上記の削除処理を実行せずに処理を次のステップＳ５５に進める。
【０１２４】
［ステップＳ５５］送信制御部１４５は、ステップＳ４２で参照された送信管理テーブル１３５から、処理許容時間を取得する。送信制御部１４５は、送信制御処理の開始からの経過時間が、処理許容時間を超えたかを判定する。ここでは、送信管理テーブル１３５に設定されている次回送信可能時刻は、送信制御処理の開始時刻と見なして使用され、経過時間は現時刻と次回送信可能時刻との差分として算出される。送信制御部１４５は、経過時間が処理許容時間を超えていない場合、ステップＳ５６の処理を実行し、経過時間が処理許容時間を超えた場合、ステップＳ５９の処理を実行する。
【０１２５】
［ステップＳ５６］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５の送信データリスト（リスナ別キュー）に、キューデータ（アドレス）が存在するかを判定する。なお、参照される送信データリストは、ステップＳ５３の処理によって更新されている。送信制御部１４５は、キューデータが１つ以上存在する場合、ステップＳ５７の処理を実行し、キューデータが存在しない場合、ステップＳ５９の処理を実行する。
【０１２６】
［ステップＳ５７］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５から、送信データリスト（リスナ別キュー）に設定された先頭のキューデータ（アドレス）を取得する。なお、ステップＳ５１と同様に、この段階では、取得されたキューデータは送信データリストに残され、削除されない。
【０１２７】
送信制御部１４５は、取得されたキューデータが示す送信管理データ１３６を参照し、その送信管理データ１３６に記録された雛形データアドレスに基づいて、送信雛形データ１３８を取得する。送信制御部１４５は、取得された送信雛形データ１３８における特定の設定欄に送信先リスナに応じた情報を設定することで、送信先リスナ宛てのイベント通知情報を生成し、生成されたイベント通知情報を、ステップＳ４４での接続先の送信先リスナに対して送信する。
【０１２８】
［ステップＳ５８］送信制御部１４５は、イベント通知情報の送信が正常に完了したかを判定する。送信制御部１４５は、送信が正常に完了した場合、ステップＳ５３の処理を実行し、送信が完了しなかった場合、ステップＳ５９の処理を実行する。
【０１２９】
以上のステップＳ５１〜Ｓ５８の処理では、送信制御処理の開始時点で送信データリスト（リスナ別キュー）に設定されていた先頭キューデータに対応する１つ目のイベント通知情報が、ステップＳ５１で送信先リスナに送信される。また、経過時間が処理許容時間内であり、送信データリストに次のキューデータが設定されている場合には、このキューデータに対応する２つ目のイベント通知情報が、ステップＳ５７で同じ送信先リスナに送信される。さらに、この時点での経過時間が処理許容時間内であり、送信データリストに次のキューデータが設定されている場合には、このキューデータに対応するイベント通知情報が、ステップＳ５７で同じ送信先リスナに送信される。
【０１３０】
このように、送信制御処理の開始時点から処理許容時間が経過するまでの期間では、同じ送信先リスナに接続されたまま、その送信先リスナに対してイベント通知情報が連続して送信される。これにより、例えば、通信速度の一時的な低下によって送信待ち状態になった同一リスナ宛ての複数のイベント通知情報を、通信速度が回復したときに即座に送信できるようになる。
【０１３１】
［ステップＳ５９］送信制御部１４５は、直近のイベント通知情報の送信にかかった時間に基づいて、イベント通知情報の平均送信時間を算出する。具体的には、送信制御部１４５は、直近にステップＳ５１の処理が開始されてから現在までの期間にステップＳ５１，Ｓ５７で送信が完了したイベント通知情報の数を判定する。送信制御部１４５は、直近のステップＳ５５で算出された、送信制御処理の開始からの経過時間を、送信が完了したイベント通知情報の数で除算することによって、平均送信時間を算出する。
【０１３２】
［ステップＳ６０］送信制御部１４５は、算出された平均送信時間と、あらかじめ設定されたイベント通知情報の個数を示す連続送信設定数Ｎとを乗算する。連続送信設定数Ｎとしては、任意の値を設定可能であるが、例えば「１０」が設定される。送信制御部１４５は、乗算結果と、あらかじめ決められた最大処理許容時間とを比較する。送信制御部１４５は、乗算結果の値が最大処理許容時間以下の場合、ステップＳ６１の処理を実行し、乗算結果の値が最大処理許容時間より大きい場合、ステップＳ６２の処理を実行する。
【０１３３】
［ステップＳ６１］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５に設定された処理許容時間を、ステップＳ６０で算出された、平均送信時間と連続送信設定数Ｎとの乗算結果の値に更新する。
【０１３４】
［ステップＳ６２］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５に設定された処理許容時間を、最大処理許容時間に更新する。
［ステップＳ６３］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５について、次のように更新する。
【０１３５】
送信制御部１４５は、送信制御処理の開始時刻にステップＳ６１またはステップＳ６２で更新された処理許容時間を加算した値によって、次回送信可能時刻を更新する。ステップＳ５５と同様に、ここでは、更新前の次回送信可能時刻が送信制御処理の開始時刻と見なして使用され、次回送信可能時刻は、更新前の次回送信可能時刻に更新後の処理許容時間を加算することによって再計算される。
【０１３６】
また、送信制御部１４５は、送信失敗回数が「０」でない場合、送信失敗回数の値を「１」だけ減算する。さらに、送信制御部１４５は、リトライ間隔を、あらかじめ決められた初期値に設定する。
【０１３７】
ここで、ステップＳ６０，Ｓ６１，Ｓ６３の処理では、直近でのイベント通知情報の平均送信時間に所定の連続送信設定数Ｎを乗算した乗算結果が、最大処理許容時間以下である場合に、その乗算結果によって処理許容時間が更新される。したがって、処理許容時間は、直近に検出された送信速度によってＮ個のイベント通知情報を送信可能な時間に設定される。また、更新後の次回送信可能時刻は、直近に検出された送信速度が高いほど早い時刻に設定され、送信速度が遅いほど遅い時刻に設定される。
【０１３８】
例えば、あるリスナへの送信速度が速い状態から遅い状態に変化した場合、現時刻から更新後の次回送信可能時刻までの間隔が長くなる。この場合、同じリスナへのイベント通知情報の送信は次回通信可能時刻まで行われず、その間に送信速度がより高速な他のリスナへのイベント通知情報の送信が優先的に行われる。
【０１３９】
一方、例えば、あるリスナへの送信速度が遅い状態から速い状態に回復した場合、更新後の次回送信可能時刻はその算出時における時刻より前の時刻になる可能性もある。しかしその場合には、その後の送信キュー１３３へのキューイング時において、そのリスナに対応するキューデータが優先的にキューイングされる。これにより、送信速度が回復したリスナに対して、それ以前より短い間隔でイベント通知情報が送信されるようになる。
【０１４０】
なお、処理許容時間は、所定の最大処理許容時間を超えないように設定される（ステップＳ６０，Ｓ６２に対応）。これにより、あるリスナへの送信速度が遅い場合でも、一定の時間間隔でそのリスナへのデータ送信のためのキューデータが送信キューにキューイングされ、その結果、送信速度が遅いリスナに対しても一定の時間間隔でデータ送信が実行されるようになる。
【０１４１】
［ステップＳ６４］送信制御部１４５は、次の２つの条件が満たされるかを判定する。第１の条件は、送信キュー１３３にキューデータが存在しない（送信キュー１３３が空である）という条件である。第２の条件は、ステップＳ５１で参照された送信管理テーブル１３５の送信データリスト（リスナ別キュー）にキューデータが存在するという条件である。送信制御部１４５は、両方の条件が満たされる場合、処理をステップＳ５１に進める。なお、ステップＳ６４で「Ｙｅｓ」と判定された後では、ステップＳ５９〜Ｓ６３の処理はスキップされ、送信管理テーブル１３５の更新は行われないものとする。一方、送信制御部１４５は、少なくとも一方の条件が満たされない場合、処理を図１９のステップＳ７５に進める。この場合、送信先リスナとの接続が切断される。
【０１４２】
以下、図１９を用いて説明を続ける。
［ステップＳ７１］ステップＳ５２でイベント通知情報の送信が完了しなかった場合、送信されたイベント通知情報は破棄される。ただし、このイベント通知情報に対応する送信データリスト（リスナ別キュー）上のキューエントリ（ステップＳ５１で送信データリストから取得されたキューエントリ）は、送信データリストに残る。送信制御部１４５は、ステップＳ７１〜Ｓ７３の処理により、処理許容時間を長くして、現在より長い時間間隔を空けて同じ送信先リスナに対する同じイベント通知情報の再送が実行されるようにする。
【０１４３】
ステップＳ７１では、送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５から、処理許容時間を取得する。送信制御部１４５は、取得された処理許容時間に「１．５」を乗算した乗算結果の値と、所定の最大処理許容時間とを比較する。送信制御部１４５は、乗算結果の値が最大処理許容時間以下の場合、ステップＳ７２の処理を実行し、乗算結果の値が最大処理許容時間より大きい場合、ステップＳ７３の処理を実行する。
【０１４４】
［ステップＳ７２］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５に設定された処理許容時間を、その１．５倍の値に更新する。
［ステップＳ７３］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５に設定された処理許容時間を、最大処理許容時間に更新する。
【０１４５】
［ステップＳ７４］送信制御部１４５は、ステップＳ５１で参照された送信管理テーブル１３５から、リトライ間隔と次回送信可能時刻とを取得する。送信制御部１４５は、送信制御処理の開始時刻に、取得されたリトライ間隔の値を加算し、加算結果の値によって送信管理テーブル１３５の次回送信可能時刻を更新する。ここでは、ステップＳ６１と同様に、更新前の次回送信可能時刻が送信制御処理の開始時刻と見なして使用され、次回送信可能時刻は、更新前の次回送信可能時刻にリトライ間隔の値を加算することによって再計算される。
【０１４６】
［ステップＳ７５］送信制御部１４５は、送信先リスナとの接続を切断する。
図２０は、接続失敗時の処理を示すフローチャートの例である。この図２０の処理は、図１７のステップＳ４６の処理に対応する。
【０１４７】
［ステップＳ８１］送信制御部１４５は、ステップＳ４１で送信キュー１３３から取り出されたキューデータ（テーブルアドレス）が示す送信管理テーブル１３５を参照し、この送信管理テーブル１３５からリトライ間隔を取得する。送信制御部１４５は、取得されたリトライ間隔の値を現時刻に加算し、加算結果の値によって送信管理テーブル１３５に設定されたリトライ間隔の値を更新する。
【０１４８】
［ステップＳ８２］送信制御部１４５は、送信先リスナに対する送信待ち状態のイベント通知情報についてのデータ有効時刻を算出する。このデータ有効時刻としては、送信先リスナに対応する送信データリスト（リスナ別キュー）の先頭に設定されたキューエントリに対応するイベント通知情報のデータ有効時刻が算出される。送信制御部１４５は、ステップＳ８１で参照された送信管理テーブル１３５の送信データリストから、先頭のキューエントリ（アドレス）を取得し、このキューエントリが示す送信管理データ１３６を参照する。送信制御部１４５は、送信管理データ１３６から生成時刻を取得し、この生成時刻に最大処理許容時間を加算した時間を、データ有効時刻として算出する。
【０１４９】
また、送信制御部１４５は、送信管理テーブル１３５からリトライ間隔を取得し、現時刻にリトライ間隔を加算した時刻を、データ送信をリトライするリトライ時刻として算出する。そして、送信制御部１４５は、リトライ時刻がデータ有効時刻と一致しているか、またはそれより前の場合、ステップＳ８３の処理を実行し、リトライ時刻がデータ有効時刻より後の場合、ステップＳ８４の処理を実行する。
【０１５０】
［ステップＳ８３］このケースでは、リトライ時刻がデータ有効時刻以前であるので、イベント通知情報の送信をリトライ可能と判定される。送信制御部１４５は、ステップＳ８１で参照された送信管理テーブル１３５の次回送信可能時刻に、リトライ時刻を設定する。これにより、リトライ時刻以降において、接続失敗により送信できなかったイベント通知情報を送信するためのキューデータが送信キュー１３３にキューイングされ、このキューデータが取り出されることでイベント通知情報の送信がリトライされる。
【０１５１】
［ステップＳ８４］このケースでは、リトライ時刻がデータ有効時刻を過ぎているので、送信できなかったイベント通知情報が削除される。送信制御部１４５は、ステップＳ８２で参照された、削除対象のイベント通知情報に対応する送信管理データ１３６に基づいて、対応する送信管理ビットマップ１３７を参照する。送信制御部１４５は、参照先の送信管理ビットマップ１３７のビットのうち、送信先リスナに対応するビットのビット値を「０」にクリアする。また、送信制御部１４５は、ステップＳ８２で送信データリスト（リスナ別キュー）から取得されたキューデータを、送信データリストから削除する。
【０１５２】
［ステップＳ８５］送信制御部１４５は、ステップＳ８４でビット値が更新された送信管理ビットマップ１３７を用いて、ステップＳ５４と同様のビットマップチェック処理を実行する。この処理では、更新後の送信管理ビットマップ１３７のすべてのビットのビット値が「０」の場合、この送信管理ビットマップ１３７を記憶部１３０から削除され、対応する送信雛形データ１３８も記憶部１３０から削除される。
【０１５３】
［ステップＳ８６］送信制御部１４５は、ステップＳ８１で参照された送信管理テーブル１３５に設定された送信失敗回数に「１」を加算して、送信失敗回数の設定値を更新する。
【０１５４】
［ステップＳ８７］送信制御部１４５は、更新後の送信失敗回数を所定の閾値と比較する。送信制御部１４５は、送信失敗回数が閾値より小さい場合、処理を終了し、送信失敗回数が閾値以上の場合、ステップＳ８８の処理を実行する。
【０１５５】
［ステップＳ８８］送信制御部１４５は、ステップＳ８１で参照された送信管理テーブル１３５に設定されたリトライ間隔と、最大処理許容時間とを比較する。送信制御部１４５は、リトライ間隔が最大許容時間以下の場合、ステップＳ８９の処理を実行し、リトライ間隔が最大許容時間を超えている場合、ステップＳ９０の処理を実行する。
【０１５６】
［ステップＳ８９］このケースでは、送信失敗回数が多いものの、リトライ間隔が最大許容時間以下であるので、同じリスナ宛ての後続のイベント通知情報については送信のリトライが可能と判定される。送信制御部１４５は、ステップＳ８１で参照された送信管理テーブル１３５に設定されたリトライ間隔を、その１．５倍の値に更新する。
【０１５７】
［ステップＳ９０］このケースでは、送信失敗回数が多く、なおかつリトライ間隔が最大許容時間を超えているので、送信先リスナとの通信が困難な状態にあると推定される。この場合、送信制御部１４５は、ステップＳ８１で参照された送信管理テーブル１３５に設定された有効フラグを「０」に更新する。これにより、送信先リスナに対するデータ送信が停止され、この送信先リスナがデータ送信対象から一時的に除外される。
【０１５８】
続いて、送信制御部１４５は、ステップＳ８１で参照された送信管理テーブル１３５の送信データリスト（リスナ別キュー）に残っているキューデータのそれぞれについて、ステップＳ９１，Ｓ９２の処理を実行する。
【０１５９】
［ステップＳ９１］送信制御部１４５は、送信データリストから取得したキューデータ（アドレス）が示す送信管理データ１３６を参照し、ビットマップアドレスが示す送信管理ビットマップ１３７を参照する。送信制御部１４５は、参照先の送信管理ビットマップ１３７のビットのうち、送信先リスナに対応するビットのビット値を「０」にクリアする。また、送信制御部１４５は、送信データリストから取得されたキューデータを、送信データリストから削除する。
【０１６０】
［ステップＳ９２］送信制御部１４５は、ステップＳ９１でビット値が更新された送信管理ビットマップ１３７を用いて、ステップＳ５４と同様のビットマップチェック処理を実行する。この処理では、更新後の送信管理ビットマップ１３７のすべてのビットのビット値が「０」の場合、この送信管理ビットマップ１３７を記憶部１３０から削除され、対応する送信雛形データ１３８も記憶部１３０から削除される。
【０１６１】
以上のステップＳ９０〜Ｓ９２の処理により、通信が困難な状態にあると推定される送信先リスナに対して送信が予約されているイベント通知情報がすべて破棄され、この送信先リスナに対するデータ送信が停止状態になる。このようにデータ送信が停止されたリスナに対しては、次の図２１に示す処理によって定期的にポーリングが行われ、通信が復旧したことが確認されるとデータ送信が再開される。
【０１６２】
図２１は、接続先確認処理を示すフローチャートの例である。この図２１の処理は、図１７のステップＳ４３の処理に対応する。
［ステップＳ１０１］送信制御部１４５は、ステップＳ４１で送信キュー１３３から取り出されたキューデータ（テーブルアドレス）が示す送信管理テーブル１３５を参照し、この送信管理テーブル１３５から有効フラグの値を取得する。送信制御部１４５は、有効フラグが「０」の場合、すなわち送信先リスナに対するデータ送信が停止されている場合には、ステップＳ１０２の処理を実行し、有効フラグが「１」の場合には処理を終了する。
【０１６３】
［ステップＳ１０２］送信制御部１４５は、ソケットを利用するための関数を用いて、ＯＳに対して送信先リスナとの接続を依頼する。これにより、ソケットを用いて送信先リスナと接続される。送信制御部１４５は、送信先リスナに対して送達確認用のメッセージを送信する。
【０１６４】
［ステップＳ１０３］送信制御部１４５は、メッセージの送達に成功した場合、ステップＳ１０５の処理を実行し、メッセージの送達に失敗した場合、ステップＳ１０４の処理を実行する。
【０１６５】
［ステップＳ１０４］送信制御部１４５は、送信先リスナとの接続を切断する。送信制御部１４５は、ステップＳ１０１で参照された送信管理テーブル１３５の次回送信可能時刻として、現時刻から２４時間後の時刻を設定する。これにより、送信先リスナに対するデータ送信の停止状態が２４時間継続される。そして、２４時間後に送信先リスナに対応するキューデータが送信キュー１３３にキューイングされ、このキューデータが取り出されることによって再度、ステップＳ１０２のメッセージ送達が実行されるようになる。
【０１６６】
［ステップＳ１０５］送信制御部１４５は、送信先リスナとの接続を切断する。送信制御部１４５は、ステップＳ１０１で参照された送信管理テーブル１３５の有効フラグを、有効を示す「１」に更新する。これにより、送信先リスナに対するデータ送信の停止状態が解消される。
【０１６７】
［ステップＳ１０６］送信制御部１４５は、ステップＳ１０１で参照された送信管理テーブル１３５からリトライ間隔を取得する。送信制御部１４５は、取得されたリトライ間隔の値を現時刻に加算し、加算結果の値によって送信管理テーブル１３５に設定されたリトライ間隔の値を更新する。
【０１６８】
図２２は、第２の実施の形態におけるデータ送信処理例を示す図である。図２２では例として、図５と同様に、同時に使用可能なソケット数が「２」であり、２つのソケットをそれぞれ用いて送信処理タスク＃１，＃２が実行されるものとする。
【０１６９】
また、例として、まず、イベント＃１の検出に伴って、イベント通知情報の送信先がリスナ＃１〜＃４と判定され、これらのイベント通知情報に対応するキューデータがリスナ＃１〜＃４にそれぞれ対応するリスナ別キューに設定されたとする。次に、イベント＃２の検出に伴って、イベント通知情報の送信先がリスナ＃１〜＃４と判定され、これらのイベント通知情報に対応するキューデータがリスナ＃１〜＃４にそれぞれ対応するリスナ別キューに設定されたとする。次に、イベント＃３の検出に伴って、イベント通知情報の送信先がリスナ＃１〜＃４と判定され、これらのイベント通知情報に対応するキューデータがリスナ＃１〜＃４にそれぞれ対応するリスナ別キューに設定されたとする。
【０１７０】
送信キュー１３３に対しては、リスナ別キュー上のイベント＃１に対応するキューデータに基づき、リスナ＃１，＃２，＃３，＃４の順にキューデータ（テーブルアドレス）がキューイングされたとする。この場合、図２２に示すように、送信処理タスク＃１により、イベント＃１に対応するイベント通知情報のリスナ＃１に対する送信処理が実行される。これと並行して、送信処理タスク＃２により、同イベント通知情報のリスナ＃２に対する送信処理が実行される。
【０１７１】
リスナ＃１に対する送信処理が遅延なく完了すると、次に、送信処理タスク＃１により、イベント＃１に対応するイベント通知情報のリスナ＃３に対する送信処理が実行される。一方、送信処理タスク＃２では、同イベント通知情報のリスナ＃２に対する送信処理の際にタイムアウトが発生したとする。この場合、リスナ＃２に対する接続が切断され、送信処理タスク＃２により、同イベント通知情報のリスナ＃４に対する送信処理が実行される。イベント＃１に対応するイベント通知情報のリスナ＃４に対する送信処理は、遅延なく完了したとする。他方、同イベント通知情報のリスナ＃３に対する送信処理では、タイムアウトが発生したとする。
【０１７２】
以上の結果、リスナ＃１，＃４の送信許容時間よりリスナ＃２，＃３の送信許容時間が長く設定される。これにより、次回送信可能時刻は、リスナ＃１，＃４，＃２，＃３の順に早い時刻が設定される。そして、リスナ別キュー上のイベント＃２に対応するキューデータに基づく送信キュー１３３へのキューイングでは、上記の次回送信可能時刻に基づき、リスナ＃１，＃４，＃２の順でキューデータ（テーブルアドレス）がキューイングされる。ただし、この時点ではリスナ＃３の次回送信可能時刻に達しておらず、リスナ＃３に対応するキューデータ（テーブルアドレス）は送信キュー１３３にキューイングされなかったとする。
【０１７３】
その結果、図２２に示すように、送信処理タスク＃１では次に、イベント＃２に対応するイベント通知情報のリスナ＃１に対する送信処理が実行され、送信処理タスク＃２では次に、同イベント通知情報のリスナ＃４に対する送信処理が実行される。また、送信処理タスク＃１によるリスナ＃１に対する送信処理が先に完了したとする、送信処理タスク＃１では次に、リスナ＃２に対する送信処理が実行される。この処理では、図２２に示すように、イベント＃１に対応するイベント通知情報のリスナ＃２に対する再送処理が実行される。
【０１７４】
このように、本実施の形態によれば、送信速度が低下しているリスナ＃２より、送信速度が低下していないリスナ＃４に対する次のイベント通知情報の送信が先に実行される。これにより、リスナ＃２に対する送信速度の低下に起因した、リスナ＃４に対する送信速度が低下量を抑制できる。
【０１７５】
また、図２２の例では、リスナ＃２に対する送信速度が回復して、イベント＃１に対応するイベント通知情報のリスナ＃２に対する再送処理が短時間で完了したとする。このとき、リスナ＃２に対応する送信許容時間は長い値となっており、再送処理は送信許容時間より短い時間で完了する。この場合、送信処理タスク＃１では、リスナ＃２との接続が維持されたまま、次のイベント＃２に対応するイベント通知情報がリスナ＃２に対して続けて送信される。このように、リスナ＃２に対する送信速度の低下が一時的なものである場合、送信速度が回復すると、送信待ちとなっていたイベント通知情報をリスナ＃２に連続して送信でき、リスナ＃２に対する送信性能を回復させることができる。
【０１７６】
なお、図２２の例ではその後、送信処理タスク＃２により、イベント＃３に対応するイベント通知情報のリスナ＃１に対する送信処理、同イベント通知情報のリスナ＃４に対する送信処理が実行される。そしてその後に、イベント＃１に対応するイベント通知情報のリスナ＃３に対する再送処理が実行される。また、送信処理タスク＃１により、イベント＃３に対応するイベント通知情報のリスナ＃２に対する送信処理が実行される。このように、リスナ＃１，＃４と、送信速度が回復したリスナ＃２に対する送信速度の低下が抑制されていることがわかる。
【０１７７】
なお、上記の各実施の形態に示した装置（例えば、送信制御装置１０、ＣＭ１１０）の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク（Blu-ray Disc：ＢＤ、登録商標）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０１７８】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１７９】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。
【符号の説明】
【０１８０】
１０  送信制御装置
１１  記憶部
１１ａ〜１１ｃ  制御値
１２  制御部
１２ａ  送信キュー
２１〜２３  送信先装置
Ｄ１ａ〜Ｄ１ｃ，Ｄ２ａ〜Ｄ２ｃ  データ
【図１】
2020031375.tif 000003
【図２】
2020031375.tif 000004
【図３】
2020031375.tif 000005
【図４】
2020031375.tif 000006
【図５】
2020031375.tif 000007
【図６】
2020031375.tif 000008
【図７】
2020031375.tif 000009
【図８】
2020031375.tif 000010
【図９】
2020031375.tif 000011
【図１０】
2020031375.tif 000012
【図１１】
2020031375.tif 000013
【図１２】
2020031375.tif 000014
【図１３】
2020031375.tif 000015
【図１４】
2020031375.tif 000016
【図１５】
2020031375.tif 000017
【図１６】
2020031375.tif 000018
【図１７】
2020031375.tif 000019
【図１８】
2020031375.tif 000020
【図１９】
2020031375.tif 000021
【図２０】
2020031375.tif 000022
【図２１】
2020031375.tif 000023
【図２２】
2020031375.tif 000024