JP2003018165A - ネットワーク情報通知方法 - Google Patents

Abstract

(57)【要約】 【課題】計算機ネットワークシステムにおいて、停電復
旧などにおいて一斉にセンタに通知が集中するとセンタ
の処理負荷が増大する。 【解決手段】親子関係にあるネットワーク要素に対し
て、グループ内代表ノードを予め定めておく。各ノード
は親ノードに直接通知せずに、グループ内代表ノードに
通知する。代表ノードでは、最初に通知を受信してから
一定期間や一定受信数，グループ内からの通知を受信待
ちし、複数の子供ノードからの通知を集約して親ノード
に通知する。 【効果】子供ノードから親ノードに対して一斉に情報通
知が発生するような場合でも、代表ノードが複数の通知
をまとめて親ノードに通知するので、親ノードにおける
通信負荷を抑制することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は計算機ネットワーク
に関し、特に親子関係にあるネットワーク要素におい
て、子供にあたる計算機から親にあたる計算機に情報を
通知する場合の通知方式に関する。

【０００２】

【従来の技術】多数の端末とそれを管理するセンタシス
テムから構成されるネットワークシステムの形態は、従
来、階層的なツリー構造とし、センタシステムと端末シ
ステムの間に複数段の通信制御ノードを配置している。
このような構成は「日経コンピュータ ９８年２月２日
号掲載 日立オープンミドルウェア ユーザ事例」に詳
しい。

【０００３】このような階層的構成の場合、中間ノード
は上位ノードからの指令を下位ノードへ伝達する、ある
いは下位ノードからの通知を上位ノードへ伝達する、と
いう役割を果たす。

【０００４】もし、端末から一斉に通知が発信されるよ
うな場合、（例えば、停電復旧の場合に端末からセンタ
に復旧通知を送る場合）、センタがこれらを個別に受信
すると、センタの負荷が一時的に跳ね上がり、センタ処
理に支障をきたしかねない。この場合、中間ノードで子
ノードからの通知を複数束ねてから上位ノードに通知す
ることにより、最終的にセンタの負荷上昇を抑えること
が可能となる。

【０００５】又、端末から一斉に通知する問題に関する
他の従来技術として通知を順番に行う技術である特開２
０００−１８８６０７号や、同時発生イベント数を考慮
し蓄積送信する特開平１１−１７７５５１号がある。

【０００６】

【発明が解決しようとする課題】階層型ネットワーク構
成の場合、センタ，中間ノード，端末といった情報制御
装置が物理的に階層配置されており、それぞれ階層にお
いて果たすべき機能が異なる。中間ノードでは端末が備
えるべき機能を備える必要はなく、基本的に端末の管理
機能が必要となる。端末では中間ノードが備えるべき端
末管理機能は備える必要がない。

【０００７】いま、段階的に端末が増えていくようなネ
ットワークシステムを考える。端末数が少ないときは中
間ノードなしでセンタと端末を直結するネットワークで
問題がない。端末が増えてくると端末からの一斉通知な
どの際に、センタ負荷が上昇するという問題が発生して
くる。その対応として中間ノードを挿入した階層型ネッ
トワークに移行することも考えられるが、ネットワーク
の再構築が必要、中間ノード用のハードウェア資源を別
途調達する必要がある、などの理由により、階層型ネッ
トワークへの移行が常に可能であるとは限らない。

【０００８】本発明の目的は、センタと端末からなるネ
ットワークシステムに代表される、親子関係にある計算
機ネットワークシステム要素において、子供ノードが増
えてもネットワーク再構築や新たなハードウェア資源の
追加を行わずに、親ノードの通信負荷上昇を抑えること
にある。

【０００９】

【課題を解決するための手段】上記目的を達成するため
に、子供ノードをいくつかのグループに予め分けてお
き、そのグループ内に代表ノードを決めておく。個々の
ノードは親ノードに直接通知せずにグループ内の代表ノ
ードに通知し、代表ノードからグループ内の通知をまと
めて親ノードに通知するようにする。

【００１０】

【発明の実施の形態】以下、本発明の実施例を図１によ
り説明する。

【００１１】代表端末１００、および非代表端末１１０
は同一のグループに属するものとする。端末１００や１
１０で発生するセンタへの通知情報は、一旦代表端末１
００に通知される。代表端末１００では、グループ内で
発生したセンタへの通知を集約し、センタ１２０に送ら
れる。

【００１２】代表端末１００および非代表端末１１０
は、通知に関わる手段としてほぼ同じ機能を有する。通
知データ発生部１０１では、停電復旧などのイベントが
発生する。通知発生制御部１０２では、通知を代表端末
またはセンタに通知する。通知受信部１０３では、グル
ープ内代表端末登録情報をセンタから受信する。また、
代表端末１００の通知受信部１０３では、本来端末から
センタに通知すべきデータを受信する。通知データ集約
部１０４は、代表端末に必要な機能であり、グループ内
からの通知情報を集約する機能を有する。非代表端末１
１０に通知データ集約部１０４が具備されていても何ら
問題なく、通知データ集約部が非稼動状態になっていれ
ばよい。

【００１３】センタ１２０は、端末グループ情報を発信
するための機能（端末グループ管理部１２１，グループ
情報発信部１２２）と、端末からの通知情報を受信・管
理するための機能（通知データ受信部１２３，通知デー
タ分解部１２４，通知データ管理部１２５）からなる。

【００１４】次に図２〜図７を用いて、本発明における
情報通知方法の動作フローを説明する。

【００１５】図２は、各端末に対して代表端末を指示す
るためのセンタ側フローである。センタでは予め端末を
幾つのグループに分けるか、どの端末同士を同一グルー
プとするか、グループ内の代表端末をどれにするか、な
どを定めておく（ステップ２０１，２０２）。これらの
情報は端末グループ管理部１２１にて管理する。次に、
グループ内の全端末に対して、グループ内の代表端末お
よびセンタのＩＰアドレスを通知しておく（ステップ２
０３）。さらに代表端末に対しては、各端末からの通知
を集約する必要があるので、通知集約処理の起動要求を
行っておく(ステップ２０４)。ステップ２０３，２０４
の処理はグループ情報発信部１２２で行う。代表端末情
報は端末設置時に静的に設定することも可能であるが、
この代表端末の指示をセンタ側から行うことにより、グ
ループ情報と代表端末の一元管理が行え、グループメン
バ変更や代表端末変更などに容易に対応できる。

【００１６】図２のフローに対応する端末側の処理を図
４に示す。センタから送られたセンタＩＰアドレス，代
表端末ＩＰアドレスを通知受信部１０３で受信する（ス
テップ４０１）。これらのＩＰアドレスを通知発信制御
部１０２で管理する代表端末テーブルに格納する（ステ
ップ４０２）。代表端末テーブルは優先度を示す数値と
ＩＰアドレスの組で記憶され、センタＩＰアドレスも最
も優先度が低い代表端末として登録しておく。

【００１７】代表端末テーブルには、複数のＩＰアドレ
スを登録することができ、これにより、優先度が最も高
い代表端末に通知できなければ、次の優先度の代表端末
への通知を試み、それでもダメなら次の優先度の代表端
末へと順番に接続を試み、最終的にグループ代表端末と
して登録されているどの端末にも通知できない場合、セ
ンタへ直接通知することを可能としている。

【００１８】代表端末の場合、センタから通知データ集
約部の起動要求がくるので、それに従い通知データ集約
部１０４の処理を起動する（ステップ４０３）。センタ
から通知データ集約部の起動要求は、グループ内の代表
端末全てに対して行う。つまり、各端末の代表端末テー
ブルに登録されている全ての代表端末は、非代表端末か
らの通知が受信可能な状態になっている。

【００１９】以上が、集約通知を行うためのセンタ側，
端末側の準備である。

【００２０】次に、実際の集約通信の処理フローを説明
する。

【００２１】図５は各端末からの通知データ発信処理フ
ローを示している。停電復旧のようなセンタへの通知情
報が通知データ発生部１０１で発生すると、通知発信制
御部１０２に送る（ステップ５０１）。通知発信制御部
１０２では、自分が管理している代表端末テーブルから
優先度の高い順に代表端末ＩＰアドレスを取出し、その
代表端末へ発信を試みる。応答タイムアウトや接続エラ
ーなどにより通信不能な場合、発信が成功するまで代表
端末ＩＰアドレスを変えながら、代表端末への発信を繰
り返す（ステップ５０２，５０３，５０４）。図５には
記載していないが、全ての代表端末への発信が失敗した
場合、優先度が最も高い代表端末から順に再度リトライ
しても良い。また、通知データ発生端末が代表端末自身
であっても、非代表端末での通知発生と全く同じフロー
で問題ない。さらに、グループ内に複数代表端末が受信
待ちしているが、通知発信側の処理では代表端末に対し
て順番に発信をトライし、成功した時点でトライを終了
するので、１つの端末からの発信情報が複数の代表端末
を経由して、二重，三重にセンタに通知されることはな
い。

【００２２】各端末から発信された通知を代表端末で処
理するフローを示したものが図６，図７である。代表端
末では通知受信部１０３において通知受信待ちをしてい
る（ステップ６０１）。通知を受信すると、受信データ
を通知データ集約部１０４でもつ受信バッファに追加格
納する（ステップ６０２）。そして、通知データ集約部
１０４における集約・発信プロセスを起動し、再び通知
受信待ち状態に戻る。もし、集約・発信プロセスが現在
起動中であれば、通知データを受信バッファに格納する
だけで、すぐに受信待ち状態に戻る（ステップ６０
３）。

【００２３】集約・発信プロセスでは、ある端末からの
通知を受信してから一定時間内に発生する他の端末から
の通知を集約するために、起動されてから一定時間スリ
ープ状態となり、受信バッファに溜まるのを待つ（ステ
ップ７０１）。スリープ状態解除後、受信バッファに溜
まっているデータを１つに集約データとしてまとめ、通
信発信制御部１０２へと集約データを送る（ステップ７
０２）。集約データには、集約データであることを通知
発信制御部で認識できるためのヘッダー情報を付加した
フォーマットとする。代表端末１００における通信発信
制御１０２では、データのヘッダ情報から集約データで
あることを判定し、代表端末テーブルからセンタＩＰア
ドレスを取出し、送信を行う（ステップ７０３）。受信
バッファのデータはセンタへの発信が完了したのでバッ
ファクリアを行い、次の受信に備える（ステップ７０
４）。なお、図６，図７の受信バッファに関連する処理
は排他制御が必要である。

【００２４】集約データのセンタ受信処理フローを示し
たのが図３のフローである。センタでは通知データ受信
部１２３において代表端末からの通知受信待ちを行って
いる（ステップ３０１）。受信したデータは通知データ
分解部１２４において各端末ごとの通報データとして分
解され（ステップ３０２）、通知データ管理部１２５に
端末毎通知データとして格納・管理する（ステップ３０
３）。

【００２５】上記説明において、センタと端末という関
係で本発明のネットワーク情報通知方式を説明したが、
親子関係にある計算機ネットワーク全般について当ては
まるのは自明である。

【００２６】また、実施例の代表ノードにおける通知デ
ータのバッファリングを一定時間に達するまで行うとし
て説明したが、受信通知数が一定値に達した時点で親ノ
ードに通知を行ってもよい。

【００２７】さらに、実施例では静的情報である優先順
位に基づき代表ノードを決定する方式を説明したが、い
つも同じ代表ノードが高負荷になる可能性が高いので、
センタノードを除く代表ノードテーブルから乱数を使っ
て代表ノードを選択しても良い（全ての非センタ代表ノ
ードへの通知が失敗した場合は、最終的にセンタノード
へ通知する）。

【００２８】また、実施例では代表ノードが通信可能な
限り代表ノードとしての役目を果たすとして説明した
が、各代表ノードが自分自身のＣＰＵ負荷率，メモリ使
用状況，スケジュール予約状況，通信トラフィック等を
監視しながら、通信不能でなくてもこれらの処理状態が
好ましくない場合、非代表ノードからの通知に対してエ
ラーリジェクトしても良い。これにより、結果的に処理
余裕のある他の代表端末で非代表端末からの通知を処理
することになる。

【００２９】

【発明の効果】本発明によれば、親子関係にある計算機
ネットワーク要素において、子供にあたる計算機から親
にあたる計算機に情報を通知する際に、停電復旧などの
場合のように、子供ノードから一斉に親ノードに通知を
行う場合でも、親ノードのマシン負荷を極端に上げるこ
となく、通知を受信することができる。また、子供ノー
ドから直接親ノードに対して通知していたシステムを代
表ノード通信方式に移行する場合でも、新たなハードウ
ェア資源をネットワーク上に追加する必要がない。

【図面の簡単な説明】

【図１】本発明の一実施例における、センタおよび代表
端末，非代表端末の機能構成である。

【図２】センタにおける、グループ内代表端末ＩＰアド
レスをグループ内全端末に発信する処理フローである。

【図３】センタにおける通知受信処理フローである。

【図４】端末における代表端末ＩＰアドレス受信処理フ
ローである。

【図５】端末における通知発信処理フローである。

【図６】代表端末における通知受信処理フローである。

【図７】代表端末における通知発信処理フローである。

【符号の説明】

１００…代表端末、１０１…通知データ発生部、１０２
…通知発信制御部、１０３…通知受信部、１０４…通知
データ集約部、１１０…非代表端末、１２０…センタ、
１２１…端末グループ管理部、１２２…グループ情報発
信部、１２３…通知データ受信部、１２４…通知データ
分解部、１２５…通知データ管理部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 和田 裕 茨城県日立市大みか町五丁目２番１号 株 式会社日立製作所情報制御システム事業部 内 Ｆターム(参考） 5K033 AA03 BA04 CB01 DA01 DA03 DB12 DB14 DB18 EA07

Claims (7)

【特許請求の範囲】
1. 【請求項１】計算機ネットワークシステム上で親子関係
   にある、親ノードと複数の子供ノード間のネットワーク
   情報通知方法において、 前記子供ノードは予め登録された代表子供ノードに対し
   てデータの送信を行い、 前記代表子供ノードは前記子供ノードから送信されたデ
   ータを受信し纏めて、前記纏めたデータを親ノードに送
   信し、 前記親ノードは前記送信されて纏めたデータを受信し分
   解することを特徴とするネットワーク情報通知方法。
2. 【請求項２】請求項１記載のネットワーク情報通知方法
   において、 前記代表子供ノードは予め設定する一定時間の間に受信
   したデータについて纏めることを特徴とするネットワー
   ク情報通知方法。
3. 【請求項３】請求項１記載のネットワーク情報通知方法
   において、 前記代表子供ノードは予め設定する一定受信数に達する
   まで受信したデータについて纏めることを特徴とするネ
   ットワーク情報通知方法。
4. 【請求項４】請求項１記載のネットワーク情報通知方法
   において、 前記子供ノードは代表ノードを複数登録し、前記登録さ
   れた代表子供ノードのいずれかにデータを送信すること
   を特徴とするネットワーク情報通知方法。
5. 【請求項５】請求項４記載のネットワーク情報通知方法
   において、 前記子供ノードは予め定められた代表子供ノードの優先
   順位に基づき、前記登録された代表子供ノードにデータ
   を送信することを特徴とするネットワーク情報通知方
   法。
6. 【請求項６】請求項４記載のネットワーク情報通知方法
   において、 前記子供ノードは前記代表子供ノードの処理状態を判定
   し、より効率の良い代表子供ノードへデータを送信する
   ことを特徴とするネットワーク情報通知方法。
7. 【請求項７】計算機ネットワークシステム上で親子関係
   にある、親ノードと、複数の子供ノードを有するネット
   ワーク情報通知システムにおいて、 前記子供ノードは代表子供ノードを登録する代表ノード
   登録テーブルを有し、前記代表子供ノードは前記子供ノ
   ードから送信されるデータを一つに纏める通信データ集
   約部を有し、 前記親ノードは前記代表子供ノードから送信される前記
   纏められたデータを分解する分解部を有することを特徴
   とするネットワーク情報通知システム。