JP3550890B2 - イベント送受信方法及び装置 - Google Patents
イベント送受信方法及び装置 Download PDFInfo
- Publication number
- JP3550890B2 JP3550890B2 JP17544396A JP17544396A JP3550890B2 JP 3550890 B2 JP3550890 B2 JP 3550890B2 JP 17544396 A JP17544396 A JP 17544396A JP 17544396 A JP17544396 A JP 17544396A JP 3550890 B2 JP3550890 B2 JP 3550890B2
- Authority
- JP
- Japan
- Prior art keywords
- event
- reception
- queue
- management table
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【発明の属する技術分野】
本発明は、イベント送受信方法及び装置に関するもので、より具体的には、イベントキューに格納したイベントの読み出し順を決定する部分の改良に関する。
【0002】
【従来の技術】
コンピュータシステム内でのイベントの伝送方式の一つとして、キューを用いたものがある。これはよく知られているように、あるプロセスから送信されたイベントを一旦メモリ内に割り当てられたキュー(本明細書ではこれを「イベントキュー」と称する)に、送信された順に格納していき、そのイベントキューに格納された各イベントは、格納された順に取り出されるFIFO型のデータ構造で管理されるようになっている。
【0003】
また、送信されるイベントには、重要度・緊急度が異なるものがあり、係る場合に常に上記FIFO型で管理されると、スムーズな処理ができなくなる。そこで、係る問題を解決するため、送信する個々のイベントに優先度(プライオリティ)を示すデータを付加し、イベントの取り出しは、優先度が一番高いものから順に行うようにし、仮に優先度が同じものの場合には、先に格納したものを取り出すようにしたものがある。このように優先度とFIFO型を組み合わせたものはプライオリティキューとも称されている。
【0004】
【発明が解決しようとする課題】
しかしながら、上記したプライオリティキュー方式では、各イベントに優先度を付加しなければならず、そのため優先度のフラグの分だけデータ長が長くなり、メモリの利用効率並びに伝送効率が悪くなる。
【0005】
また、優先度(プライオリティ)を付加する処理が必要となるばかりでなく、優先度は、伝送するイベントの種類のみに起因するのではなく、送信後に受信する順番を替えたいことがあり、係る場合には送信後に優先度の変更ができない従来のプライオリティキュー方式では充分に対応できない。すなわち、イベントの受信処理時間がイベントの送信間隔よりも長い時でしかも同時に複数のイベントが送信された場合には、処理しきれないイベントがイベントキューに滞留してしまい、新たに送信されたイベントを受信し、個別処理するためには、滞留している全てのイベントの受信処理を行わなければならないが、これも、同時(比較的短時間の間)にイベントキューに格納されるイベント数が少ない場合には問題が発生しないので、周囲の状況により同一のイベントであっても、FIFO型で受信しても滞留を起こさない場合と、滞留を起こす場合がある。したがって、前記イベントキューに蓄えられたイベントの受信順序を自由に変更することができると好ましいが、従来のものではそれを解決できるものがなかった。
【0006】
本発明は、上記した背景に鑑みてなされたもので、その目的とするところは、上記した問題を解決し、滞留したイベントで不必要なイベントに対して受信処理を行うかどうかを選択的に行えることと、特定の処理要求イベントに対して一時的に受信処理を行わない方法を提供することにより、イベントの受信順序を自由に変更し、効率の良いイベントの送受信を行えるイベント送受信方法及び装置を提供するものである。
【0007】
【課題を解決するための手段】
上記した目的を達成するため、本発明に係るイベント送受信方法では、送信側プロセスから受信側プロセスに対してイベントを送信するに際し、送信側プロセスは、前記イベントをイベントキューに順次格納し、受信側プロセスは、前記イベントキューに格納されたイベントを所定の順で読み出すようにしたイベント送受信方法において、イベントの種類ごとにイベント名(実施の形態では「イベント識別子」)と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルを設け、イベントを送信する際に、そのイベントが前記受信イベント管理テーブルに格納されている場合には、前記イベントキューに格納するとともに、その送信するイベントに対応する前記送信回数を更新し、前記受信側プロセスが、前記イベントキューに格納されたイベントを受信する際には、前記受信イベント管理テーブルのイベントの送信回数と受信回数とを比較し、前記送信回数の方が大きいイベントのみを受信するとともに、前記受信イベント管理テーブルの受信したイベントに対応する受信回数を更新するようにし、かつ、前記受信回数の更新を前記イベントの受信と関係なく、強制的に変更できるようにし、前記受信側プロセスが受信したイベントに加え、前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除するようにした(請求項1)。
【0008】
そして、上記した方法を実施するのに適した本発明に係るイベント送受信装置では、送信側プロセスから送信されたイベントを一時的に格納するイベントキューと、前記イベントキューに格納されたイベントを受信する受信側プロセスと、イベントの種類ごとにイベント名と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルと、前記イベントキューにイベントが格納される都度、その格納されたイベントに対応するイベント名に関連付けられた送信回数を更新する送信回数更新手段(実施の形態では「送信側プロセス」)と、前記イベントキューに格納されたイベントが前記受信側プロセスに受信される都度、その受信されたイベントに対応するイベント名に関連付けられた受信回数を更新する受信回数更新手段(実施の形態では「受信側プロセス」)と、前記イベントの受信と関係なく、前記受信回数を更新する受信回数強制更新手段(実施の形態では「受信側プロセス」)とを備え、さらに、前記受信側プロセスは、前記イベントキューに格納されたイベントのうち、前記受信イベント管理テーブルのイベントの送信回数の方が受信回数よりも大きいイベントのみを受信するようにし、かつ、前記受信側プロセスが受信したイベントと前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除する手段(実施の形態では「受信側プロセス」)とを備えて構成した(請求項2)。
【0009】
なお、受信イベント管理テーブルに対するイベント名の登録は、すべてのイベント名を登録しても良く、或いは選択的に所望イベント名のみを登録しても良い。
【0010】
請求項1,2に記載した発明では、受信イベント管理テーブルに登録されたものでしかも送信回数の方が受信回数よりも大きいイベントのみが受信される。したがって、そもそも受信側プロセスにとって、不要なイベントがある場合には、そのイベントを受信イベント管理テーブルに登録しておかなければ、受信することがない。よって、不要なイベントを受信することによる受信並びにその後の解析に要する時間が短縮できる。また、受信イベント管理テーブルに格納したイベントであっても、イベントキューでイベントの滞留が起こった場合、滞留したイベントのなかで不必要なものがあれば、受信回数強制更新手段を用いて受信イベント管理テーブルにある不必要なイベントの受信回数を送信回数と等しく設定する。すると、不必要なイベントの受信処理を行う必要がなくなる。
【0017】
ここで、上記した送信回数更新手段は、実施の形態では、送信側プロセスの機能に一体的に組み込んでいる。しかし、本発明は必ずしも一体にする必要はなく、例えば、イベントキューに格納されるイベントを監視し、テーブルに登録された受信回数を更新するようにする手段を別途設けても良い。同様に、受信回数更新手段と受信回数強制更新手段は、実施の形態では、受信側プロセスの機能に一体的に組み込んでいるが、これもいずれか一方或いは双方とも別部材として構成しても良い。さらに、イベントを削除する手段も、実施の形態としてでは、受信側プロセスの機能に組み込んでいるが、別途形成しても良く、さらに、受信したイベントを削除する手段と、受信回数と送信回数の大小関係に基づいてイベントを削除する手段を別々に形成してももちろん良い。さらには、各管理テーブルにイベント名等を登録したり、一度登録したものを別の管理テーブルに移し替える管理手段も実施の形態では、受信側プロセスの機能に一体的に組込んでいるが、これも別途構成してもよい。
【0018】
【発明の実施の形態】
図1は本発明が適用されるコンピュータシステムの一例の概略構成を示している。本発明の要部を説明する前に、同図に基づいてシステム全体について説明する。コンピュータがあるシステムを実行する場合には、各プロセス間でイベントの送受を行い、イベントを受け取ったプロセスは、そのイベントの内容に応じて所定の処理をし、必要に応じて他のプロセスに再度イベントを送信したり、外部に出力したりする。そして、そのイベントの送受は、イベントを受信するプロセス側にそれぞれイベントキューを接続し、送信側のプロセスは、そのイベントキューに対して逐次データを格納していき、また受信側のプロセスは、そのイベントキューに格納された自分宛のイベントを所定の順で取り出すようになっている。
【0019】
一例を示すと、あるシステム(例えば変電所内の運転を管理するシステム)を実行するためには、複数のプロセス1a,1b,1c,1d(実際には、これ以外にも多数のプロセスが存在する)を適宜関連づけて連結し、イベントを受信するプロセス1a,1b,1cについては、それぞれにイベントキュー2a,2b,2cを接続している。そして、各プロセスは、実際には、プログラムで構成される。
【0020】
また、図示した例における各プロセスの機能・内容を簡単に説明すると、障害管理プロセス1aは、システムのハードウェア並びにソフトウェアの障害の発生・復旧を通知するイベントを受信し、その情報をモニター画面に表示したりファイルに障害の履歴情報を格納したりする処理をするものである。
【0021】
また、ハードウェア監視プロセス1bは、システムを構築するハードウェアの状態を監視し、障害が発生したり、また、発生した障害が復旧されたことを認識したならば、障害発生イベントまたは復旧イベントを障害管理プロセス1aに対して送信する(実際には、イベントキュー2aに格納する)ように機能する。
【0022】
同様に、ソフトウェア監視プロセス1cは、システムを構築するソフトウェアの状態を監視し、障害が発生したり、また、発生した障害が復旧されたことを認識したならば、障害発生イベントまたは復旧イベントを障害管理プロセス1aに対して送信する(実際には、イベントキュー2aに格納する)ように機能する。
【0023】
また、時刻管理プロセス1dは、内蔵する時計に基づいて、システム全体の時間を管理するもので、予め定められた時刻が来ると、時刻イベントを所定のプロセス1a〜1cに伝えるようになる。また、指定された時間が経過された場合には、タイマーイベントを所定のプロセス1a〜1cに伝えるようになる。そして、この時刻管理プロセス1dから送信されるイベントに基づいて、各プロセスでは、一定時間間隔或いは定時毎に所定の処理を実行することができるようになっている。
【0024】
なお、この時刻管理プロセス1dは、内蔵する時計に基づいて所定のイベントを所定のプロセスに対して送信するだけで、他のプロセスからイベントを取得することがないので、イベントキューは接続していない。なおまた、各プロセスで実行させる基本的な処理は従来と同様のものを用いることができるので、それを実行するためのより具体的な機能の詳細な説明は省略する。
【0025】
ここで本発明では、上記したシステム構成を前提とし、各プロセス1a〜1cがイベントキュー2a〜2cに格納されたイベントを受け取る順番を単純にFIFO型で行うのではなく、イベントの種類やその時の状況に即し、FIFO型を基本としながら、適宜順番を変えたり、不要なイベントの受け取りを拒否するようにし、効率よくデータの受け取りをできるようにしている。そして、それを実行するためのイベント送受信装置の一実施の形態を図2に示している。
【0026】
同図に示すように、コンピュータ10内部に実装される送信側プロセス11から送信されたイベントは、一旦イベントキュー12に格納され、そのイベントキュー12を介して受信側プロセス13に受け渡されるようになっている。この基本構成は、上記した図1に示すものと同様である。なお、送信側プロセス11は、図の例では1つのみ代表として表示したが、仮に受信側プロセス13が図1における障害管理プロセス1aとすると、送信側プロセス11は、ハードウェア監視プロセス1b,ソフトウェア監視プロセス1c,時刻管理プロセス1dの3つのプロセスが並列的に存在することになる。
【0027】
ここで本発明では、送信側プロセス11及び受信側プロセス13からそれぞれアクセス可能な非受信イベント管理テーブル14と、受信イベント管理テーブル15とを設けている。そして、各テーブル14,15のデータ構造は、図示するように、イベントの内容を特定するイベント識別子(イベント名)と、そのイベントを送信した送信回数と、受信側プロセス13がそのイベントを受信した受信回数の3つのデータを関連づけて格納するようになっている。
【0028】
そして、各管理テーブル14,15に対するイベント識別子の登録は、受信側プロセス13が行う。つまり、自己が受け得るイベントを予め受信イベント管理テーブル14か非受信イベント管理テーブル15のいずれか一方に登録する。この時、いずれのテーブルに登録するかは、そのイベントが優先して受信する必要があるか否かにより決定され、具体的には、優先して受信するイベントは受信イベント管理テーブル14に格納し、優先しては受信しないイベントは非受信イベント管理テーブル15に格納するようになっている。さらに、その後の所定のタイミングで、一旦登録したイベント識別子を別の管理テーブルに移し替えることができるようになっている。さらにまた、イベントキュー12に格納されたイベントを受信した(読み取った)場合には、受信イベント管理テーブル14に格納された受信回数の欄の数値をインクリメント(1を加算)する機能を基本機能として持ち、さらに実際に受信したか否かに関係なく、受信回数の欄の数値の更新・書き換えを行うことができる機能も有している。
【0029】
また、管理テーブル14,15の登録項目のうち送信回数の欄の数値は、送信側プロセス11がイベントキュー12にイベントを格納する際に、その数値をインクリメント(1を加算)するようになっている。
【0030】
次に、送信側プロセス11の本発明と関係する部分の機能について説明する。送信側プロセス11は、従来から有している通常の機能に加え、図3のフローチャートに示す機能を有している。すなわち、まず、あるイベントを送信しようとした場合には、その送信先に付随する受信イベント管理テーブル14と非受信イベント管理テーブル15をアクセスし、そのイベント識別子の欄をサーチし、送信するイベントを検索する(S101)。次いで、その検索したイベント識別子に関連するイベント送信回数をインクリメントし(S102)、その後、送信するイベントをイベントキュー12に登録する(S103)。そして、本発明では、FIFO型を基本とするため、イベントキュー12への各イベントの格納は、先頭から順に行う。つまり、一番後ろに格納することになる。
【0031】
一方、受信側プロセス13は、上記したように初期設定としていずれかの管理テーブル14,15にイベント識別子を登録したり、一旦登録したイベント識別子を別のテーブルに移し替えたり、受信回数を擬似的に変更する機能に加え、イベントキュー12に格納されたイベントを受信するという本来の機能を当然有している。すなわち、その受信機能は、先頭に格納された(一番古い)イベントから順に受信するというFIFO型を基本とし、その際に、受信しようとしたイベントが、2つの管理テーブル14,15のいずれに登録されたものか、及びまたはイベント送信回数とイベント受信回数の大小関係に基づいて、「受信する/しない」の選択を行うことにより、不要なイベントを受信しないようにする。さらに、途中でイベント識別子を登録する管理テーブルを替えることにより、一旦受信しないと選択したものをその後に受信可能とし、これにより、受信する順番を替えることができるようにしている。そして、具体的な処理は、図4のフローチャートに示すようになっている。
【0032】
すなわち、まず、イベントキュー12に登録された一番古いイベントを検索する(S201)。そして、検索できた(成功)ならば、受信イベント管理テーブル14をアクセスし、そのイベントが受信イベント管理テーブルに登録されているものか否かを判断し(S202)、登録されている場合には、そのイベント識別子についてのイベント送信回数とイベント受信回数を取得し、送信回数の方が大きいか否かを判断する(S203)。
【0033】
そして、送信回数の方が大きい場合には、そのイベントについてのイベント受信回数をインクリメントする(S204)。その後、通常の受信処理、すなわち、イベントキュー12からそのイベントを読み込んだ後(S205)、イベントキュー12から読み込んだイベント20を削除して処理を終了する(S206)。
【0034】
一方、ステップ202の分岐判断を行った結果、取得したイベントが受信イベント管理テーブル14に登録されていない場合(非受信イベント管理テーブル15に登録されている)には、ステップ207に飛び、次に古いイベントをイベントキュー12から検索し、検索できたならば、ステップ202に戻り、上記した処理を繰り返し行う。また、ステップ207の処理で、イベントを検索できない(失敗)、つまり、最新に格納したイベントまで処理を行ったならば、一連の受信処理を終了するようになる。
【0035】
このように、受信イベント管理テーブル14に登録されたイベントのみを受信するようにしたため、たとえイベントキュー12に先に格納されたイベントがあったとしてもそのイベントが非受信イベント管理テーブル15に登録されている場合には、読み出されない。つまり、FIFO型を前提としつつ、必ずしも先に格納されたイベントが先に読み出されるものではなく、必要なものから先に読み出され、その読み出し順を変えることができる。換言すると、本例では、受信イベント管理テーブル14に登録されたイベントの中で、先に登録されたものから順に読み出す(FIFO型)ようにしている。
【0036】
しかも、受信側プロセス13により、一旦非受信イベント管理テーブル15の登録したイベントを、その後に受信イベント管理テーブル14側に移し替えるようにしたため、当初は、ステップ202の判断でNoとなり読み出されなかったものが、その後に管理テーブルの移し替えが行われることによりステップ202の判断でYesになり読み出しを可能とすることができる。また、逆に当初受信イベント管理テーブル14に登録しておき、その後に非受信イベント管理テーブル15に移し替え、受信を拒否することもできる。このように、完全に読み出しの順番を入れ替えることができるようになる。
【0037】
なお、受信側プロセス13における各管理テーブル14,15への登録及び移し替えは、そのプロセスを設計する際に行う。そして、このように本例では、2つの管理テーブル14,15を設置し、それらを適宜使いわけることにより、例えば、受信に時間がかかるとともに、さほど緊急性を有しないイベントは、とりあえず非受信イベント管理テーブルに格納しておき、イベントキュー12に格納されたイベントがなくなるか、少なくなったときに受信イベント管理テーブルに登録し直すことにより、効率よく受信処理ができる。また、最初はすべてのイベントを受信イベント管理テーブル14に登録しておき、例えば、混んできた(イベントキューに格納されたイベントが滞留する)場合に、受信に時間を要するイベントを非受信イベント管理テーブル15に移し替えることにより、スムーズにイベントの読み出しをすることができるようにもできる。
【0038】
さらに、非受信イベント管理テーブルに登録したままにすると、受信処理しないため、自己のプロセスにとって不要なイベントを受信する必要がなくなる。よって、無駄な読み込み処理や読み取ったイベントを解析する処理等がなくなり、システム全体の稼働効率が向上する。
【0039】
一方、ステップ203の分岐判断で、イベント送信回数とイベント受信回数が等しいか、イベント受信回数の方が大きい場合には、ステップ208に飛び、検索したイベントをイベントキューから削除する。すなわち、通常であれば、送信側プロセス11がイベントをイベントキューに登録する都度イベント送信回数の数値が1加算され(S102)、その登録されたイベントが読み出されることによってイベント受信回数の数値が1加算される(S204)ため、原則としてはイベントキュー12にイベントが残っていると、イベント送信回数の方が必ず大きくなり、ステップ203の判断ではYesになる。
【0040】
しかし、上記したように、受信側プロセス13に、受信回数を強制的に変更する機能を与えたため、実際の受信回数以上の回数に書き換えると、イベントキュー12にイベントが残っていても送信回数の方が小さくなり、ステップ203でNoと判断されることがある。これにより、不要なイベントを受信することなくイベントキュー12から削除することができるようになる。よって、イベントキュー12にイベントが残ったままとなることがなくなり、メモリの使用効率が向上する。
【0041】
次に、上記した装置を用いて、本発明に係るイベント送受信方法の実施の形態を説明する。まず、前提として送信側プロセス11は受信側プロセス13に対してイベントAとイベントBとイベントCを複数送信し、送信された各イベントは一旦イベントキュー12に保存され、イベント受信プロセス13はイベントキュー12からイベントを所定の順で読み込むものとする。そして、受信側プロセス13は、初期状態として、イベントAとイベントBを受信イベント管理テーブル14に登録し、イベントCを非受信イベント管理テーブル15に登録する。なお、各テーブル14,15のイベント送信回数とイベント受信回数はともに「0」になっている。
【0042】
ここで、送信側プロセス11が、受信側プロセス13に対してイベントを「イベントA」,「イベントC」,「イベントB」,「イベントB」,「イベントA」の順に送信したとする。すると、図3のフローチャートに従って、まず、最初のイベントAは、受信イベント管理テーブル14に登録されたイベントであるので、そのテーブル14のイベントAについてのイベント送信回数をインクリメントし、イベントAをイベントキュー12の先頭▲1▼に登録する。次にイベントCは、非受信イベント管理テーブル15に登録されたイベントであるので、そのテーブル15のイベントCについてのイベント送信回数をインクリメントし、イベントCをイベントキュー12の2番目▲2▼に登録する。以後係る処理を繰り返し行うことにより、図2に示すように、イベントキュー12には、送信した順にイベントが格納されるとともに、各管理テーブル14,15の送信回数が所定の値となる。この時、受信はされていないため、各管理テーブル14,15の受信回数は0のままとなる。これにより、送信処理は終了する。
【0043】
次に、受信処理について説明する。受信側プロセス13は、図4に示すフローチャートに従って、まず、イベントキュー12に登録された一番古いイベントを検索し、イベントAを検出する(S201)。そして、イベントAをキーとして受信イベント管理テーブル14をアクセスする。すると、イベントAは、その管理テーブル14に登録されているため、次に受信イベント管理テーブル14に格納されたイベントAについての送信回数(2回)と受信回数(0回)を取得するとともに両者を比較する(S202,203)。この場合、イベントAのイベント送信回数は、イベント受信回数よりも大きいので、ステップ204〜206を順次処理する。すなわち、▲1▼のイベントAのイベント受信回数をインクリメントして「1」にし、イベントキュー12の先頭▲1▼からイベントAを読み込んだ後、イベントキュー12から読み込んだイベントAを削除する。
【0044】
次に、上記処理により▲1▼のイベントAは削除されているため、現在の一番古いイベントは、▲2▼のイベントCとなっている。そこで、ステップ201から再度処理すると、イベントキュー12に登録された現在の一番古いイベントであるイベントCを検出する。すると、イベントCは、非受信イベント管理テーブルから検索されるので、ステップ207に飛びイベントキュー12に格納されたイベントで次に古いイベントを検索し、▲3▼のイベントBを検出する。▲3▼のイベントBは、受信イベント管理テーブル14に登録されており、しかも、その管理テーブル14のイベントBのイベント送信回数(2)は、イベント受信回数(0)よりも大きいので、▲3▼のイベントBのイベント受信回数をインクリメントし、イベントキュー12から▲3▼のイベントBを読み込んだ後、イベントキュー12から読み込んだイベントBを削除し処理を終了する。
【0045】
このように、イベントキュー12に格納した順番は、イベントA,C,B…の順であったが、読み出す際には、イベントCを飛び越えてイベントA,Bの順で行われる。そして、管理テーブルに登録するイベント識別子の移し替えや、受信回数の強制修正がないとすると、イベントキュー12に登録された一番古いイベントであるイベントCは読み出されず、▲4▼以降に登録されたイベントB,Aの順で読み出される。そして、最終的な受信イベント管理テーブル14の受信回数は、ともに2となる。つまり、FIFO型であれば、「A,C,B,B,A」の順で読み取られ、イベントキュー12には、イベントが何も残らないが、「A,B,B,A」の順で読み取られ、イベントCはイベントキュー12に残ったままとなる。そして、例えばイベントCが読取りに時間がかかるような場合には、FIFO型ではイベントCを読み取っている間に、イベントキュー12にイベントが次々に格納されて滞留するが、上記のようにイベントCを受信しないようにすることにより、他のイベントを迅速に読み取ることができ、滞留の発生を抑制できる。
【0046】
一方、上記した▲3▼のイベントを読み取って、イベントキュー12から削除した後で、受信側プロセス13が、以下の処理をしたとする。すなわち、イベントCを受信イベント管理テーブル14に登録するとともに非受信イベント管理テーブル15から削除し、逆にイベントAを非受信イベント管理テーブル15に登録して受信イベント管理テーブル14から削除する処理を行う。さらに、受信イベント管理テーブル14に登録されているイベントBのイベント受信回数の値をイベント送信回数と同じ値に設定したとする。すると、受信イベント管理テーブル14と非受信イベント管理テーブル15は、図5に示すような内容となる。
【0047】
この状態で、さらに受信側プロセス13が、受信処理を継続したとすると、まず、イベントキュー12に登録された一番古いイベントであるイベントCを検出する。このイベントCは、受信イベント管理テーブル14から検索され、しかもイベントCのイベント送信回数(1)は、イベント受信回数(0)よりも大きいので、ステップ204に飛び、イベントCのイベント受信回数をインクリメントし、イベントキュー12からイベントCを読み込んだ後、イベントキュー12から読み込んだイベントCを削除する。
【0048】
次に、イベントキュー12に登録された一番古いイベントである▲4▼のイベントBを検索する。このイベントBは、受信イベント管理テーブル14に登録されているため、イベントBのイベント送信回数(2)と、イベント受信回数(2)を比較する。すると、送信回数は、受信回数より大きくないのでステップ203の分岐判断でNoとなり、ステップ208に飛び、イベントキュー12から検索した▲4▼のイベントBを読み取ることなくイベントキュー12から削除する。これにより、イベントキュー12には、▲5▼のイベントAのみが格納されていることになる。
【0049】
そして、イベントキュー12に登録された一番古いイベントであるイベントAを検出し、イベントAは、非受信イベント管理テーブル15に登録されているためステップ207に飛び、イベントキュー12に格納されたイベントで次に古いイベントを検索しようとするが、検索できないのでそのまま処理を終了する。すなわち、上記したように途中で、管理テーブルの登録の入れ替えや、受信回数の強制変更を行った場合の読み出しの順は、「A▲1▼,B▲3▼,C▲2▼」となり、▲4▼のBは読み取られることなく削除され、▲5▼のAはイベントキュー12に残ったままとなる。
【0050】
さらに、具体的な処理の流れは説明しないが、上記したイベントBについての受信回数を送信回数と同じにする強制修正処理をしない場合には、読み出しの順は、「A▲1▼,B▲3▼,C▲2▼,B▲4▼」となり、▲5▼のAはイベントキュー12に残ったままとなる。さらに、イベントAについての非受信イベント管理テーブル15側への移し替えを行わない(イベントCの受信イベント管理テーブル14側への移し替えのみする)場合には、読み出しの順は、「A▲1▼,B▲3▼,C▲2▼,B▲4▼,A▲5▼」となり、FIFO型とは異なる順番で、イベントキュー12からすべてのイベントが読み出されることになる。そして、当然のことながら、管理テーブル間でのイベント識別子の移し替えのタイミングを変えることにより、読み出し順は、上記したもの以外のものになる。このように、読み出す順番や、読み出すイベントを任意に変えることができるようになる。
【0051】
なお、上記した装置及び方法についての実施の形態は、本発明の最良のものの一つで、例えば、図1に記載のものから非受信イベント管理テーブルを除いても良い。また、非受信イベント管理テーブルを残しておいたとしても、両管理テーブルの送信回数と受信回数の項目をなくし、受信イベント管理テーブルに格納されているイベントのみを受信するようにしても良い。
【0052】
【発明の効果】
以上のように本発明に係るイベント送受信方法及び装置では、滞留したイベントで不必要なイベントに対して受信処理を行うかどうかを選択的に行えることと、特定の処理要求イベントに対して一時的に受信処理を行わない方法を提供することにより、イベントの受信順序を自由に変更し、効率の良いイベントの送受信が行えるようになった。
【0053】
つまり、本発明では、そもそも受信側プロセスにとって、不要なイベントがある場合には、そのイベントを受信イベント管理テーブルに登録しておかなかったり、受信イベント管理テーブルにある不必要なイベントの受信回数を送信回数と等しく設定することにより、不必要なイベントの受信処理を行う必要がなくなる。
【図面の簡単な説明】
【図1】本発明に係るイベント送受信方法及び装置が適用されるシステム全体を示す概略構成図である。
【図2】本発明に係るイベント送受信装置の実施の形態の一例を示す図である。
【図3】送信側プロセスの手順を示すフローチャート図である。
【図4】受信側プロセスの手順を示すフローチャート図である。
【図5】本発明の実施の形態で使われる、受信イベント管理テーブルと非受信イベント管理テーブルの一例である。
【符号の説明】
11 送信側プロセス
12 イベントキュー
13 受信側プロセス
14 受信イベント管理テーブル
15 非受信イベント管理テーブル
Claims (2)
- 送信側プロセスから受信側プロセスに対してイベントを送信するに際し、前記送信側プロセスは、前記イベントをイベントキューに順次格納し、前記受信側プロセスは、前記イベントキューに格納されたイベントを所定の順で読み出すようにしたイベント送受信方法において、
イベントの種類ごとにイベント名と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルを設け、イベントを送信する際に、そのイベントが前記受信イベント管理テーブルに格納されている場合には、前記イベントキューに格納するとともに、その送信するイベントに対応する前記送信回数を更新し、
前記受信側プロセスが、前記イベントキューに格納されたイベントを受信する際には、前記受信イベント管理テーブルのイベントの送信回数と受信回数とを比較し、前記送信回数の方が大きいイベントのみを受信するとともに、前記受信イベント管理テーブルの受信したイベントに対応する受信回数を更新するようにし、
かつ、前記受信回数の更新を前記イベントの受信と関係なく、強制的に変更できるようにし、
前記受信側プロセスが受信したイベントに加え、前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除するようにしたことを特徴とするイベント送受信方法。 - 送信側プロセスから送信されたイベントを一時的に格納するイベントキューと、
前記イベントキューに格納されたイベントを受信する受信側プロセスと、
イベントの種類ごとにイベント名と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルと、
前記イベントキューにイベントが格納される都度、その格納されたイベントに対応するイベント名に関連付けられた送信回数を更新する送信回数更新手段と、 前記イベントキューに格納されたイベントが前記受信側プロセスに受信される都度、その受信されたイベントに対応するイベント名に関連付けられた受信回数を更新する受信回数更新手段と、
前記イベントの受信と関係なく、前記受信回数を更新する受信回数強制更新手段とを備え、
さらに、前記受信側プロセスは、前記イベントキューに格納されたイベントのうち、前記受信イベント管理テーブルのイベントの送信回数の方が受信回数よりも大きいイベントのみを受信するようにし、
かつ、前記受信側プロセスが受信したイベントと前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除する手段を備えたことを特徴とするイベント送受信装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP17544396A JP3550890B2 (ja) | 1996-06-17 | 1996-06-17 | イベント送受信方法及び装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP17544396A JP3550890B2 (ja) | 1996-06-17 | 1996-06-17 | イベント送受信方法及び装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH103393A JPH103393A (ja) | 1998-01-06 |
JP3550890B2 true JP3550890B2 (ja) | 2004-08-04 |
Family
ID=15996179
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP17544396A Expired - Fee Related JP3550890B2 (ja) | 1996-06-17 | 1996-06-17 | イベント送受信方法及び装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3550890B2 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5029333B2 (ja) * | 2007-12-07 | 2012-09-19 | 日本電気株式会社 | コンピュータシステム、仮想記憶制御方法、及びプログラム |
JP4729611B2 (ja) | 2008-10-30 | 2011-07-20 | 株式会社エヌ・ティ・ティ・ドコモ | イベントキュー管理装置及びイベントキュー管理方法 |
KR102276345B1 (ko) * | 2019-12-18 | 2021-07-12 | 주식회사 쏘마 | 컴퓨터 내 행위 이벤트 축약 방법 |
-
1996
- 1996-06-17 JP JP17544396A patent/JP3550890B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPH103393A (ja) | 1998-01-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2983167B2 (ja) | ネットワーク・インタフェース装置およびネットワーク・インタフェースにおけるパケット処理方法 | |
Amir et al. | Membership algorithms for multicast communication groups | |
US6256634B1 (en) | Method and system for purging tombstones for deleted data items in a replicated database | |
JP2656708B2 (ja) | 結合式データ処理システム用の方法および装置 | |
US6871226B1 (en) | Method of searching servers in a distributed network | |
JPH09505713A (ja) | 広帯域ネットワークにおけるデータ伝送の並列アセンブリのためのシステム | |
CN110740145B (zh) | 消息消费方法、装置、存储介质及电子设备 | |
JP2003288283A (ja) | 静的エンドツーエンド再送装置および方法 | |
CN116501783A (zh) | 一种分布式数据库数据导入方法及系统 | |
JP3550890B2 (ja) | イベント送受信方法及び装置 | |
US7917476B2 (en) | Device management system using log management object and method for generating and controlling logging data therein | |
US6240065B1 (en) | Bit clearing mechanism for an empty list | |
Ahn et al. | A causal message logging protocol for mobile nodes in mobile computing systems | |
US20110302375A1 (en) | Multi-Part Aggregated Variable in Structured External Storage | |
US8880963B2 (en) | Message processing device and method thereof | |
JP2002077204A (ja) | ネットワーク通信システム | |
JPH11288408A (ja) | 分散処理システムおよび障害解析情報の保存方法 | |
JP2002057712A (ja) | パケットメモリのメモリリーク復旧方法およびバッファ処理装置 | |
KR0171038B1 (ko) | 고속 병렬 컴퓨터에서 크로스바 네트웍 라우터의 수신부에 대한 소프트웨어 애뮬레이션 방법 | |
JP3056348B2 (ja) | ブリッジ装置および記憶手段管理方法 | |
EP0622927B1 (en) | Data transmission apparatus and a communication path management method therefor | |
JPH1097447A (ja) | 電文制御システム及び電文制御プログラムを格納した記憶媒体 | |
JP2619518B2 (ja) | データ通信方式 | |
JPH0348315A (ja) | タイマ管理方式 | |
CN115622961A (zh) | 一种数据通信芯片报文转发的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20031222 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040330 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040412 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080514 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090514 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090514 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100514 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |