ＳＮＭＰエージェント通信装置
【課題】ＳＮＭＰマネージャ通信装置とＳＮＭＰエージェント通信装置と間におけるＭＩＢ不整合を確実に防止する。
【解決手段】ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）は、ＳＮＭＰマネージャ通信装置１１から送られてくる要求パケットを解析し、上位アプリケーション３１へ通知する。上位アプリケーション３１は、要求パケットの解析結果に基づき、指定されたオブジェクトＩＤに従って所定の処理を実行し、その後、ＭＩＢ３２５、３２６に対するＳＥＴ／ＧＥＴの要求処理を実施する。上位アプリケーション３１は、要求パケットがＧＥＴ（取得）要求であった場合は、ＭＩＢ３２５、３２６をアクセスして現在の情報を取得し、ＳＮＭＰ３２１へ送る。ＳＮＭＰ３２１は、上位アプリケーション３１を経由して取得した情報を応答パケットとして通信回線２５を経由してＳＮＭＰマネージャ通信装置１１へ送る。
【解決手段】ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）は、ＳＮＭＰマネージャ通信装置１１から送られてくる要求パケットを解析し、上位アプリケーション３１へ通知する。上位アプリケーション３１は、要求パケットの解析結果に基づき、指定されたオブジェクトＩＤに従って所定の処理を実行し、その後、ＭＩＢ３２５、３２６に対するＳＥＴ／ＧＥＴの要求処理を実施する。上位アプリケーション３１は、要求パケットがＧＥＴ（取得）要求であった場合は、ＭＩＢ３２５、３２６をアクセスして現在の情報を取得し、ＳＮＭＰ３２１へ送る。ＳＮＭＰ３２１は、上位アプリケーション３１を経由して取得した情報を応答パケットとして通信回線２５を経由してＳＮＭＰマネージャ通信装置１１へ送る。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＮＭＰ（Simple Network Management Protocol）エージェント機能を有するルータ（Router）やハブ（HUB）等の通信装置に係り、特にＳＮＭＰマネージャ機能を有する通信装置とエージェント機能を有する通信装置間で管理するオブジェクト（MIB：Management Information Base）定義の整合性をＳＮＭＰエージェント側で保持するＳＮＭＰエージェント通信装置に関する。
【背景技術】
【０００２】
ＳＮＭＰに基づいて通信を行なうネットワークは、従来から一般に知られている（例えば、特許文献１参照。）。
図１は、本発明の対象とするネットワークシステムの全体の概略構成を示すシステム構成図である。図１において、１１はマネージャ機能を有するＳＮＭＰマネージャ通信装置（管理ステーション）で、このＳＮＭＰマネージャ通信装置１１には、ネットワーク１２を介してエージェント機能を有する複数のＳＮＭＰエージェント通信装置（被管理対象）１３ａ〜１３ｎが接続される。上記ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、例えばルータ（Router）やハブ（HUB）等の通信装置を指すが、ＳＮＭＰを用いて管理される通信装置であれば、特に限定されるものではない。
【０００３】
上記ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、ＳＮＭＰマネージャ通信装置１１によりＭＩＢ（Management Information base）定義に基づき遠隔管理されるものであり、ＳＮＭＰマネージャ通信装置１１から要求されるＭＩＢ定義情報のＳＥＴ（更新）処理及びＧＥＴ（取得）処理を実行する。
【０００４】
図６は、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）におけるＳＮＭＰパケットフロー図であり、（１）〜（１１）の破線矢印で示した流れが実際のＳＮＭＰパケットの流れを示している。
【０００５】
従来のＳＮＭＰマネージャ通信装置１１′は、図６に示すように上位アプリケーション（上位ＡＰ）２１、プロトコル（Protocol）スタック部２２、ドライバ／ＯＳ部２３からなっている。上記プロトコルスタック部２２は、ＳＮＭＰ２２１、ＵＤＰ（User Datagram Protocol）２２２、ＴＣＰ（Transmission Control Protocol）２２３、ＩＰ（Internet Protocol）２２４を備えると共に、揮発ＲＡＭからなる第１のＭＩＢ（Management Information base：データベース）２２５、及び不揮発ＲＡＭからなる第２のＭＩＢ２２６を備えている。
【０００６】
また、上記ドライバ／ＯＳ部２３は、ドライバ（Driver）２３１及びＯＳ（Operating System）２３２を備えている。
また、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）は、上位アプリケーション（上位ＡＰ）３１、プロトコル（Protocol）スタック部３２、ドライバ／ＯＳ部３３からなっている。上記プロトコルスタック部３２は、ＳＮＭＰ３２１、ＵＤＰ（User Datagram Protocol）３２２、ＴＣＰ（Transmission Control Protocol）３２３、ＩＰ（Internet Protocol）３２４を備えると共に、揮発ＲＡＭからなる第１のＭＩＢ（Management Information base）３２５、及び不揮発ＲＡＭからなる第２のＭＩＢ３２６を備えている。また、ドライバ／ＯＳ部３３は、ドライバ（Driver）３３１及びＯＳ（Operating System）３３２を備えている。
【０００７】
そして、上記ＳＮＭＰマネージャ通信装置１１′とＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）との間は、通信回線２５により接続される。
【０００８】
以下、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）がＳＮＭＰマネージャ通信装置１１′から要求されるＭＩＢ定義情報のＳＥＴ（更新）及びＧＥＴ（取得）処理を行なう場合のＳＮＭＰパケットフローについて、図６を参照して説明する。
【０００９】
（１）ＳＮＭＰマネージャ通信装置１１′は、ＳＮＭＰ２２１の管理に基づいて、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）が持っている現在の機器の情報を取得するためのＳＥＴ（更新）／ＧＥＴ（取得）処理の要求パケットをドライバ／ＯＳ部２３から送信する。
【００１０】
（２）ＳＮＭＰマネージャ通信装置１１′から出力される要求パケットは、通信回線２５を経由してＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）へ送られる。
【００１１】
（３）ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）は、受信した要求パケットをＳＮＭＰ３２１に入力して解析を実施する。
【００１２】
（４）ＳＮＭＰ３２１は、解析結果に基づき、ＳＮＭＰマネージャ通信装置１１′で指定されたオブジェクトＩＤに従って、ＭＩＢ３２５、３２６におけるＭＩＢを更新する。
【００１３】
（５）また、上記要求パケットがＧＥＴ（取得）要求であった場合は、ＭＩＢ３２５、３２６をアクセスして現在の情報を取得し、この取得した情報によりＳＮＭＰマネージャ通信装置１１′からの要求パケットのデータエリアを更新する。
【００１４】
（６）ＳＮＭＰ３２１は、取得した情報を応答パケットとしてドライバ／ＯＳ部３３から送信する。
【００１５】
（７）また、上記ＳＮＭＰ３２１は、上記応答パケットを送信した後、上位アプリケーション３１に対し、ＳＮＭＰマネージャ通信装置１１′へ情報を送信した旨の通知を行なう。上位アプリケーション３１は、上記ＳＮＭＰ３２１からの通知を受けて所定の処理を実行する。
【００１６】
（８）上記ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）から出力される応答パケットは、通信回線２５を経由してＳＮＭＰマネージャ通信装置１１′へ送られる。
【００１７】
（９）ＳＮＭＰマネージャ通信装置１１′は、受信した応答パケットをＳＮＭＰ２２１に入力して解析を実施する。
【００１８】
（１０）ＳＮＭＰ２２１は、上記応答パケットの解析結果に基づいてＭＩＢ２２５、２２６をアクセスして情報を更新する。
【００１９】
（１１）また、ＳＮＭＰ２２１は、ＭＩＢ２２５、２２６の更新情報に基づいて処理が必要な場合、その処理を実施する。
【００２０】
図７は、上記ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）のソフトウェア制御図である。
ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）は、起動すると同時にＳＮＭＰエージェントメインタスクが生成され、ＳＮＭＰマネージャ通信装置１１′から送られてくるＳＥＴ（更新）／ＧＥＴ（取得）要求パケットの入力待ちの状態となる（ステップＡ１）。この状態で、ＳＮＭＰマネージャ通信装置１１′からのＳＥＴ／ＧＥＴの要求パケットを受信すると、ＳＮＭＰにて規定されているパラメタチェックを行ない（ステップＡ２）、正常であればオブジェクトＩＤ毎の処理関数ＣＡＬＬを行ない、対象のオブジェクトＩＤでのＭＩＢ情報の更新／取得、応答パケットの作成を行なう（ステップＡ３）。そして、上記作成した応答パケットをＳＮＭＰマネージャ通信装置１１′へ送信する（ステップＡ４）。その後、上位アプリケーション３１に対し、ＳＮＭＰマネージャ通信装置１１′へ情報を送信した旨の通知を行なって所定の処理を実行する（ステップＡ５）。上記上位アプリケーション３１への通知を行なった後は、ステップＡ１に戻り、再びＳＮＭＰパケットの入力待ちの状態となる。
【特許文献１】特開２０００−１８１８２７号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
上記従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）では、上記（６）のステップで応答パケットをＳＮＭＰマネージャ通信装置１１′へ送信した後、（７）のステップにて上位アプリケーション３１に対する通知を行なっているので、上位アプリケーション３１の処理結果における可否については、ＳＮＭＰマネージャ通信装置１１′へ送信する応答パケットに反映されないという問題がある。
【００２２】
ＳＮＭＰマネージャ通信装置１１′においては、応答パケットに含まれる制御結果に応じてＭＩＢ２２５、２２６のＭＩＢ情報を更新するが、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）にて上記（７）のステップで発生する上位アプリケーション３１の処理が異常終了した場合、ＳＮＭＰマネージャ通信装置１１′で保持／管理しているＭＩＢ情報を別の値にて更新あるいは制御前の状態に戻す場合が発生する。このような状況が発生した場合、ＳＮＭＰマネージャ通信装置１１′とＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）でのＭＩＢ値が異なってしまう可能性がある。
【００２３】
上記のようにＳＮＭＰマネージャ通信装置１１′とＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）との間でＭＩＢ不整合が発生した場合の対処の一つとして、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）の状態変化をＳＮＭＰマネージャ通信装置１１′へ通知するＴＲＡＰパケットによる処理がＳＮＭＰでサポートされている。
【００２４】
しかし、上記ＴＲＡＰパケット通知により、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）の状態変化をＳＮＭＰマネージャ通信装置１１′に通知した場合でも、ＳＮＭＰマネージャ通信装置１１′では応答パケットをトリガとして該当処理を開始するため、ＴＲＡＰパケットによる通知で該当処理を中断若しくは終了させたとしても、システムとして一時的にＭＩＢ情報の不整合による不安定な状況になると考えられる。
【００２５】
また、ＳＮＭＰマネージャ通信装置１１′によって複数のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）を管理及び制御するシステムにおいては、ＳＮＭＰマネージャ通信装置１１′からＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）に対する要求パケット（ＳＥＴ／ＧＥＴ処理の要求パケット）が応答パケットとは非同期で、且つバースト的に発生する可能性がある。例えばＳＮＭＰマネージャ通信装置１１′に該当するプリンタサーバからＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）に該当するプリンタ本体へのインク残量の問い合わせがプリンタサーバを利用しているユーザから一斉に行なわれた場合等が考えられる。
【００２６】
上記のような状況が発生した場合、図７で示したようなソフトウェア制御構造では、その処理性能上、上記要求パケットに対する応答パケットが破棄されるか大幅に遅延する恐れがある。このため上記したようにシステムとして一時的にＭＩＢの不整合による不安定な状況が発生し、若しくはＳＮＭＰマネージャ通信装置１１′からの要求パケット再送処理に伴う通信トラフィックの増大が懸念される。
【００２７】
本発明は上記の課題を解決するためになされたもので、ＳＮＭＰマネージャ通信装置からＳＮＭＰエージェント通信装置に対する要求パケットが応答パケットとは非同期で、且つバースト的に発生した場合であっても、上記両通信装置間におけるＭＩＢ不整合を確実に防止し得るＳＮＭＰエージェント通信装置を提供することを目的とする。
【課題を解決するための手段】
【００２８】
第１の発明は、ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットを上位アプリケーションへ通知し、該上位アプリケーションからＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行し、前記要求パケットが取得要求であった場合に前記上位アプリケーションがＭＩＢから取得した情報を応答パケットとして前記ＳＮＭＰマネージャ通信装置へ送信することを特徴とする。
【００２９】
第２の発明は、ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットに対する処理を行なうタスクを処理パケット毎に分散させ、選択されたタスクにおいて前記要求パケットに対する処理要求メッセージを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段と、前記要求パケットを上位アプリケーションへ通知した際、該上位アプリケーションから応答メッセージが出力されるまでの時間を監視タイマにより監視し、前記応答メッセージが規定時間以上出力されなかった場合に前記要求パケットを異常処理し、待ち状態となっている新規の更新／取得処理の要求パケットを動作させる手段とを具備することを特徴とする。
【００３０】
第３の発明は、ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、該要求パケットを解析して軽負荷の要求パケットの優先度を高く設定する優先度設定手段と、前記優先度設定手段により設定された優先度の高い要求パケットを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段とを具備することを特徴とする。
【発明の効果】
【００３１】
本発明によれば、ＳＮＭＰエージェント通信装置側で受信したＭＩＢ定義情報の更新／取得処理の要求パケットを上位アプリケーションへ通知し、上位アプリケーションからＭＩＢへのアクセスを行なわせることにより、上位アプリケーションでの処理結果を反映した情報をＳＮＭＰマネージャ通信装置へ送信することが可能となり、ＳＮＭＰマネージャ通信装置とＳＮＭＰエージェント通信装置との間におけるＭＩＢ不整合を確実に防止することができる。
【００３２】
また、ＳＮＭＰマネージャ通信装置からのバースト的なパケット入力に対しても、複数のタスクに分散して処理することにより、過負荷に対する処理正常性の向上を図ることができる。更に、要求パケットに処理優先度を設定し、軽負荷のパケット処理を優先させることで、負荷に対する処理性能を更に向上することができる。
【発明を実施するための最良の形態】
【００３３】
以下、図面を参照して本発明の一実施形態を説明する。
本発明は、上記図１で説明したようにマネージャ機能を有するＳＮＭＰマネージャ通信装置（管理ステーション）１１と、このＳＮＭＰマネージャ通信装置１１にネットワーク１２を介して接続されるエージェント機能を有する複数のＳＮＭＰエージェント通信装置（被管理対象）１３ａ〜１３ｎからなるネットワークシステムを対象としている。
【００３４】
上記ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、ＳＮＭＰマネージャ通信装置１１によりＭＩＢ（Management Information base）定義に基づき遠隔管理されるものであり、ＳＮＭＰマネージャ通信装置１１から要求されるＭＩＢ定義情報のＳＥＴ（更新）処理及びＧＥＴ（取得）処理を実行する。
【００３５】
図２は、本発明の一実施形態に係るＳＮＭＰエージェント通信装置１３ａ〜１３ｎにおけるＳＮＭＰパケットフロー図であり、（１）〜（１２）の破線矢印で示した流れが実際のＳＮＭＰパケットの流れを示している。
【００３６】
上記ＳＮＭＰマネージャ通信装置１１は、従来のＳＮＭＰマネージャ通信装置１１′と同様の構成であり、上位アプリケーション２１、プロトコル（Protocol）スタック部２２、ドライバ／ＯＳ部２３からなっている。
【００３７】
また、ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）と同様の構成であり、上位アプリケーション３１、プロトコル（Protocol）スタック部３２、ドライバ／ＯＳ部３３からなっている。
【００３８】
以下、上記ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）がＳＮＭＰマネージャ通信装置１１から要求されるＭＩＢ定義情報のＳＥＴ（更新）／ＧＥＴ（取得）を行なう場合のＳＮＭＰパケットフローについて、図２を参照して説明する。
【００３９】
（１）ＳＮＭＰマネージャ通信装置１１は、ＳＮＭＰ２２１の管理に基づいて、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）が持っている現在の機器の情報を取得するためのＳＥＴ／ＧＥＴの要求パケットをドライバ／ＯＳ部２３から出力する。
【００４０】
（２）ＳＮＭＰマネージャ通信装置１１から出力される要求パケットは、通信回線２５を経由してＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）へ送られる。
【００４１】
（３）ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）は、受信した要求パケットをＳＮＭＰ３２１に入力して解析を実施する。
【００４２】
（４）ＳＮＭＰ３２１は、受信したＳＥＴ／ＧＥＴの要求パケットを上位アプリケーション３１へ通知する。
【００４３】
（５）上位アプリケーション３１は、要求パケットの解析結果に基づき、ＳＮＭＰマネージャ通信装置１１で指定されたオブジェクトＩＤに従って所定の処理を実行し、その後、ＭＩＢ３２５、３２６に対するＳＥＴ／ＧＥＴの要求処理を実施する。
【００４４】
（６）上位アプリケーション３１は、上記要求パケットがＧＥＴ（取得）要求であった場合は、ＭＩＢ３２５、３２６をアクセスして現在の情報を取得する。
【００４５】
（７）上記上位アプリケーション３１がＭＩＢ３２５、３２６から取得した情報は、ＳＮＭＰ３２１へ送られる。
【００４６】
（８）ＳＮＭＰ３２１は、上位アプリケーション３１を経由して取得した情報を応答パケットとしてドライバ／ＯＳ部３３から出力する。
【００４７】
（９）上記ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）から出力される応答パケットは、通信回線２５を経由してＳＮＭＰマネージャ通信装置１１へ送られる。
【００４８】
（１０）ＳＮＭＰマネージャ通信装置１１は、受信した応答パケットをドライバ／ＯＳ部２３からＳＮＭＰ２２１に入力して解析を実施する。
【００４９】
（１１）ＳＮＭＰ２２１は、上記応答パケットの解析結果に基づいてＭＩＢ２２５、２２６をアクセスして情報を更新する。
【００５０】
（１２）また、ＳＮＭＰ２２１は、ＭＩＢ２２５、２２６の更新情報に基づいて処理が必要な場合は、その処理を実施する。
【００５１】
上記のようにＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）側で受信したＭＩＢ定義情報の更新／取得処理の要求パケットを上位アプリケーション３１へ通知し、上位アプリケーション３１からＭＩＢ３２５，３２６へのアクセスを行なわせることにより、上位アプリケーション３１での処理結果を反映した情報をＳＮＭＰマネージャ通信装置１１へ送信することが可能となり、ＳＮＭＰマネージャ通信装置１１とＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）との間におけるＭＩＢ不整合を確実に防止することができる。
【００５２】
図３は、上記ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）のソフトウェア制御図である。
まず、ソフトウェア全体の構成として、従来ではＳＮＭＰエージェントメインタスクのみによって行なっていた処理を、本実施形態ではＳＮＭＰエージェント子タスクにて処理することを特徴としている。また、ＳＮＭＰエージェント子タスクは、システムで規定する制限値まで、受信するＳＮＭＰ要求パケットの負荷に応じて生成することが可能である。つまり、ＳＮＭＰエージェントメインタスクでは、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケット受信とパラメタチェック、ＳＮＭＰエージェント子タスクの生成が主な機能となり、ＳＮＭＰエージェント子タスクでは実際のＳＥＴ／ＧＥＴ要求パケット処理が主な機能となる。
【００５３】
以下、図３に従って詳細な処理シーケンスを説明する。
ＳＮＭＰエージェントメインタスクは、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）が起動すると同時に生成／動作し、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケット入力待ちの状態となる（ステップＢ１）。ＳＮＭＰエージェントメインタスクは、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケットを受信すると、ＳＮＭＰにて規定されているパラメタチェックを行ない（ステップＢ２）、正常であればＳＮＭＰエージェント子タスクを起動させるための前処理として受信したＳＥＴ／ＧＥＴ要求パケットに対して、ＳＮＭＰエージェント子タスクにて処理中である旨のフラグを設定する（ステップＢ３）。その後、ＳＮＭＰエージェント子タスクを生成し、ＳＮＭＰエージェントメインタスクは無限ループにて、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケットの入力待ちの状態となる。
【００５４】
ＳＮＭＰエージェント子タスクは、タスク生成後に既に起動している他のＳＮＭＰエージェント子タスクの起動総数が、システムにて規定される子タスク生成の制限値を超えていないかをチェックする（ステップＣ１）。本チェックにて、システムにて規定されている子タスク生成の制限値を超えている場合には、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）の処理性能以上の負荷が発生しているか、あるいはＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）に重大な問題が発生し、処理が不可能な状態であるかのどちらかである。しかし、何れの場合でもＳＮＭＰマネージャ通信装置１１に対して、応答パケットを送信しなければならないため、制御ＮＧにて応答パケットを送信する。なお、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）に重大な欠陥が発生しているか否かについては、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケットを一時中断して再開した場合、正常な応答パケットが送信されるかどうかで判定可能である。また、このような重大な問題が発生する可能性を低減させるため、詳細を後述するように上位アプリケーション３１側でタイマ監視による制御を導入している。
【００５５】
一方、ＳＮＭＰエージェント子タスク起動時に、システムに規定される子タスク生成の制限値を超えていない場合は、子タスク生成数をインクリメントし、ＳＥＴ／ＧＥＴ要求パケット情報テーブルのセマフォ（以下、ＰＫＴテーブルセマフォと略称する）を取得する（ステップＣ２）。上記ＳＥＴ／ＧＥＴ要求パケット情報テーブルは、ＳＮＭＰエージェント子タスク群にて共有するリソースであるため、あるＳＮＭＰエージェント子タスクがＰＫＴテーブルセマフォを取得している間は、他のＳＮＭＰエージェント子タスクにてＰＫＴテーブルセマフォを取得しようとした場合でも待ち行列につながれ、タスク状態としてはセマフォ待ちの状態となる。
【００５６】
従って、本実施形態では、一つのＳＮＭＰエージェント子タスクがＰＫＴテーブルセマフォを取得している場合の新規ＳＮＭＰエージェント子タスクの生成は制限値まで可能であるが、生成されたＳＮＭＰエージェント子タスクが動作できるのは、１タスクのみとなる。ＰＫＴテーブルセマフォを取得したＳＮＭＰエージェント子タスクは、ＳＮＭＰマネージャ通信装置１１から発生したＳＥＴ／ＧＥＴ要求パケットに含まれる制御対象のオブジェクトＩＤが複数含まれていた場合でも、上位アプリケーション３１とＩ／Ｆ（インターフェイス）との要求／応答回数を最低限に抑えるため１メッセージで上位アプリケーション３１にＳＥＴ／ＧＥＴ要求メッセージを送信するための処理、すなわちＩＰＤＵ化処理を行なう（ステップＣ３）。その後、上位アプリケーション３１へ要求メッセージを送信し、応答メッセージ待ちの状態となる（ステップＣ４）。
【００５７】
上位アプリケーション３１は、ＳＥＴ／ＧＥＴ要求メッセージに従ってＭＩＢ２２５、２２６に対する処理を行ない、応答メッセージを出力する。
【００５８】
上記ステップＣ４の応答メッセージ待ちの状態において、上位アプリケーション３１からの応答メッセージを受信すると、受信メッセージの整合性をチェックし、上位アプリケーション３１から通知された制御内容を応答パケットに反映させる処理、すなわちオブジェクトＩＤ毎の処理関数ＣＡＬＬを行なう（ステップＣ５）。全てのオブジェクトＩＤに関して、反映する処理が終了した場合、ＳＮＭＰマネージャ通信装置１１に対する応答パケットを送信する（ステップＣ６）。
【００５９】
その後、動作中取得していたＰＫＴテーブルセマフォを解放し（ステップＣ７）、タスク処理を終了する（ステップＣ８）。このタスク処理の終了と同時に子タスク生成数をデクリメントする。そして、ＰＫＴテーブルセマフォ待ち状態となっているＳＮＭＰエージェント子タスクは、待ち行列状態となっている最古のＳＮＭＰエージェント子タスクの待ち状態が解除され、以上で示した同様の手順にて処理が行なわれる。
【００６０】
上記のようにＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）に入力される要求パケットに対し、要求パケットを処理するタスクを処理パケット毎に分散させ、一時的に処理できない状態が発生する場合にはキューイングすることにより、ＳＮＭＰマネージャ通信装置１１からバースト的な要求パケットが入力された場合でも、過負荷に対する処理正常性の向上を図ることができる。
【００６１】
次に、上述したソフトウェア制御方法により発生する懸念のある重大な問題に対しての改善方法を説明する。
上記図３で説明したように、本実施形態におけるソフトウェア制御方法では、ＰＫＴテーブル情報のセマフォ解放のトリガを上位アプリケーション３１からの応答メッセージとしている。このため上位アプリケーション３１からの応答メッセージがＳＮＭＰエージェント子タスクにて受信されない限り、その他全ての待ち状態となっているＳＥＴ／ＧＥＴ要求パケットが解消されない。このため一旦本状態に陥った場合には、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）全体のリセットを行なわなければ復旧不可能な状態となる。
【００６２】
上記のような状態に陥るのを可能な限り避けるため、上位アプリケーション３１に対して応答メッセージに対するタイマによる監視制御を行ない、規定時間以上、上位アプリケーション３１からの応答メッセージが到着しない場合には、タイムアウト処理の中で、ＳＮＭＰマネージャ通信装置１１に対する応答パケットを送信し、待ち状態となっている新規のＳＥＴ／ＧＥＴ要求パケットを動作させる異常処理を行なう。
【００６３】
すなわち、図４のソフトウェア制御図に示すように、上記図３で説明したＳＮＭＰエージェント子タスク処理において、ステップＣ３でＩＰＤＵ化処理を行なった際、上位アプリケーション（上位ＡＰ）３１へ要求メッセージを送出する（ステップＤ１）。このとき監視タイマをセットし（ステップＤ２）、応答メッセージ待ちの状態となる（ステップＣ４）。この応答メッセージ待ちの状態では、上位アプリケーション３１からの応答メッセージの有無を判定し（ステップＤ３）、応答メッセージがなければ上記監視タイマによる計測時間が予め設定した規定時間を経過したかどうかを判定する（ステップＤ４）。上記監視タイマによる計測時間が規定時間を経過していなければステップＣ４へ戻り、応答メッセージ待ちの状態となる。
【００６４】
そして、上記規定時間を経過する前に上位アプリケーション３１から応答メッセージが送られてきた場合は、上記監視タイマをリセットし（ステップＤ５）、上記図３に示したステップＣ５の処理（オブジェクトＩＤ毎の処理関数ＣＡＬＬ）に進む。
【００６５】
また、上記ステップＤ４で監視タイマによる計測時間が規定時間を経過したと判定された場合には、当該ＳＥＴ／ＧＥＴ要求パケットをエラー処理し（ステップＤ６）、待ち状態となっている新規のＳＥＴ／ＧＥＴ要求パケットを動作させる（ステップＤ７）。
【００６６】
上記の異常処理により、上位アプリケーション３１からの応答メッセージが送信されない場合でも、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）全体を異常状態とさせずに、当該ＳＥＴ／ＧＥＴ要求パケットのみをエラーとすることで、システム全体の安定性を向上させることが可能となる。
【００６７】
次に、上述したソフトウェア制御方法により発生する懸念のある重大な問題に対しての他の改善方法について説明する。
この改善方法は、ソフトウェア制御アルゴリズムの一つとして受信したＳＥＴ／ＧＥＴ要求パケットに処理優先度を設け、軽負荷のＳＥＴ／ＧＥＴ要求パケット処理を優先させることで、待ち行列につながれるＳＮＭＰエージェント子タスク数を低減し、処理優先度を設けない場合よりも応答パケットがエラーとなる可能性を低減したものである。
【００６８】
本発明におけるソフトウェア制御方法のクリティカルセクション（上位アプリケーション３１へ要求メッセージを送出してから応答メッセージを受信するまで）を如何に短縮できるかが、本ソフトウェア制御方法を導入したＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）の性能を大きく左右する要素となっている。ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）は、その性質上、ＳＥＴ／ＧＥＴ要求パケットに対して処理負荷に差が生じる。例えばＳＥＴ／ＧＥＴ要求パケットについてあるＧＥＴ要求パケットは、ＭＩＢ３２５、３２６で管理している一つの情報を取得するだけの場合もあり、装置状態や条件によって、その都度計算や上位アプリケーション３１間で問い合わせが必要な場合もある。これらＳＥＴ／ＧＥＴ要求パケットの種類と組み合わせについては、ＳＮＭＰマネージャ通信装置１１間で既に規定されているので、ＳＥＴ／ＧＥＴ要求パケットの内容を解析することによって、処理負荷の大きさを判定することが可能である。
【００６９】
図５は、上記のように処理優先度を考慮したＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）のソフトウェア制御図（ＳＮＭＰエージェント子タスク）の一例を示したものである。
【００７０】
ＳＮＭＰエージェント子タスクは、図３で説明したようにタスク生成後に既に起動している他のＳＮＭＰエージェント子タスクの起動総数が、システムにて規定される子タスク生成の制限値を超えていないかをチェックする（ステップＣ１）。
【００７１】
次いで、受信した要求パケットを解析し、処理負荷が高い要求パケットは、別領域にキューイングする（ステップＥ１）。その後は、上記図３で説明したように、子タスク生成数のインクリメント及びＰＫＴテーブルセマフォの取得処理（ステップＣ２）、ＩＰＤＵ化処理（ステップＣ３）、上位アプリケーション３１への要求メッセージ送信、上位アプリケーション３１からの応答メッセージ待ち（ステップＣ４）、オブジェクトＩＤ毎の処理関数ＣＡＬＬ（ステップＣ５）、ＳＮＭＰマネージャ通信装置１１に対する応答パケットの送信（ステップＣ６）、ＰＫＴテーブルセマフォ解除（ステップＣ７）、等の処理を行なう。
【００７２】
以上の処理を行ない、子タスク生成数が「０」であれば、上記ステップＥ１で別領域にキューイングしていた要求パケットを解放する（ステップＥ２）。以上でタスク処理を終了し（ステップＣ８）、タスク終了と同時に子タスク生成数をデクリメントする。
【００７３】
上記したようにＳＮＭＰマネージャ通信装置１１から送られてきたＳＥＴ／ＧＥＴ要求パケットに処理優先度を設け、軽負荷のＳＥＴ／ＧＥＴ要求パケット処理を優先させることで、待ち行列につながれるＳＮＭＰエージェント子タスク数を低減し、処理優先度を設けない場合よりも応答パケットがエラーとなる可能性を低減することができる。
【００７４】
なお、上述したシステムにて規定される子タスク生成の制限値、上位アプリケーション３１における応答メッセージの応答時間を監視するタイマの値、更には要求パケットの処理優先度を考慮する際の判定条件については、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）の性能に大きな影響があるため、個々の通信装置において性能に合わせて設定する。
【図面の簡単な説明】
【００７５】
【図１】本発明の対象とするネットワークシステムの全体の概略構成を示すシステム構成図である。
【図２】本発明の一実施形態に係るＳＮＭＰエージェント通信装置のＳＮＭＰパケットフロー図である。
【図３】同実施形態におけるＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【図４】本発明のタイマによる監視制御機能を備えたＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【図５】本発明の処理優先度を考慮したＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【図６】従来のＳＮＭＰエージェント通信装置におけるＳＮＭＰパケットフロー図である。
【図７】従来のＳＮＭＰエージェント通信装置におけるＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【符号の説明】
【００７６】
１１…ＳＮＭＰマネージャ通信装置、１２…ネットワーク、１３ａ〜１３ｎ…ＳＮＭＰエージェント通信装置、２１…上位アプリケーション（上位ＡＰ）、２２…プロトコルスタック部、２２１…ＳＮＭＰ、２２２…ＵＤＰ、２２３…ＴＣＰ、２２４…ＩＰ、２２５、２２６…ＭＩＢ、２３…ドライバ／ＯＳ部、２３１…ドライバ、２３２…ＯＳ、２５…通信回線、３１…上位アプリケーション（上位ＡＰ）、３２…プロトコルスタック部、３２１、３２２…ＳＮＭＰ、３２３…ＴＣＰ、３２４…ＩＰ、３２５、３２６…ＭＩＢ、３３…ドライバ／ＯＳ部、３３１…ドライバ、３３２…ＯＳ。
【技術分野】
【０００１】
本発明は、ＳＮＭＰ（Simple Network Management Protocol）エージェント機能を有するルータ（Router）やハブ（HUB）等の通信装置に係り、特にＳＮＭＰマネージャ機能を有する通信装置とエージェント機能を有する通信装置間で管理するオブジェクト（MIB：Management Information Base）定義の整合性をＳＮＭＰエージェント側で保持するＳＮＭＰエージェント通信装置に関する。
【背景技術】
【０００２】
ＳＮＭＰに基づいて通信を行なうネットワークは、従来から一般に知られている（例えば、特許文献１参照。）。
図１は、本発明の対象とするネットワークシステムの全体の概略構成を示すシステム構成図である。図１において、１１はマネージャ機能を有するＳＮＭＰマネージャ通信装置（管理ステーション）で、このＳＮＭＰマネージャ通信装置１１には、ネットワーク１２を介してエージェント機能を有する複数のＳＮＭＰエージェント通信装置（被管理対象）１３ａ〜１３ｎが接続される。上記ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、例えばルータ（Router）やハブ（HUB）等の通信装置を指すが、ＳＮＭＰを用いて管理される通信装置であれば、特に限定されるものではない。
【０００３】
上記ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、ＳＮＭＰマネージャ通信装置１１によりＭＩＢ（Management Information base）定義に基づき遠隔管理されるものであり、ＳＮＭＰマネージャ通信装置１１から要求されるＭＩＢ定義情報のＳＥＴ（更新）処理及びＧＥＴ（取得）処理を実行する。
【０００４】
図６は、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）におけるＳＮＭＰパケットフロー図であり、（１）〜（１１）の破線矢印で示した流れが実際のＳＮＭＰパケットの流れを示している。
【０００５】
従来のＳＮＭＰマネージャ通信装置１１′は、図６に示すように上位アプリケーション（上位ＡＰ）２１、プロトコル（Protocol）スタック部２２、ドライバ／ＯＳ部２３からなっている。上記プロトコルスタック部２２は、ＳＮＭＰ２２１、ＵＤＰ（User Datagram Protocol）２２２、ＴＣＰ（Transmission Control Protocol）２２３、ＩＰ（Internet Protocol）２２４を備えると共に、揮発ＲＡＭからなる第１のＭＩＢ（Management Information base：データベース）２２５、及び不揮発ＲＡＭからなる第２のＭＩＢ２２６を備えている。
【０００６】
また、上記ドライバ／ＯＳ部２３は、ドライバ（Driver）２３１及びＯＳ（Operating System）２３２を備えている。
また、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）は、上位アプリケーション（上位ＡＰ）３１、プロトコル（Protocol）スタック部３２、ドライバ／ＯＳ部３３からなっている。上記プロトコルスタック部３２は、ＳＮＭＰ３２１、ＵＤＰ（User Datagram Protocol）３２２、ＴＣＰ（Transmission Control Protocol）３２３、ＩＰ（Internet Protocol）３２４を備えると共に、揮発ＲＡＭからなる第１のＭＩＢ（Management Information base）３２５、及び不揮発ＲＡＭからなる第２のＭＩＢ３２６を備えている。また、ドライバ／ＯＳ部３３は、ドライバ（Driver）３３１及びＯＳ（Operating System）３３２を備えている。
【０００７】
そして、上記ＳＮＭＰマネージャ通信装置１１′とＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）との間は、通信回線２５により接続される。
【０００８】
以下、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）がＳＮＭＰマネージャ通信装置１１′から要求されるＭＩＢ定義情報のＳＥＴ（更新）及びＧＥＴ（取得）処理を行なう場合のＳＮＭＰパケットフローについて、図６を参照して説明する。
【０００９】
（１）ＳＮＭＰマネージャ通信装置１１′は、ＳＮＭＰ２２１の管理に基づいて、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）が持っている現在の機器の情報を取得するためのＳＥＴ（更新）／ＧＥＴ（取得）処理の要求パケットをドライバ／ＯＳ部２３から送信する。
【００１０】
（２）ＳＮＭＰマネージャ通信装置１１′から出力される要求パケットは、通信回線２５を経由してＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）へ送られる。
【００１１】
（３）ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）は、受信した要求パケットをＳＮＭＰ３２１に入力して解析を実施する。
【００１２】
（４）ＳＮＭＰ３２１は、解析結果に基づき、ＳＮＭＰマネージャ通信装置１１′で指定されたオブジェクトＩＤに従って、ＭＩＢ３２５、３２６におけるＭＩＢを更新する。
【００１３】
（５）また、上記要求パケットがＧＥＴ（取得）要求であった場合は、ＭＩＢ３２５、３２６をアクセスして現在の情報を取得し、この取得した情報によりＳＮＭＰマネージャ通信装置１１′からの要求パケットのデータエリアを更新する。
【００１４】
（６）ＳＮＭＰ３２１は、取得した情報を応答パケットとしてドライバ／ＯＳ部３３から送信する。
【００１５】
（７）また、上記ＳＮＭＰ３２１は、上記応答パケットを送信した後、上位アプリケーション３１に対し、ＳＮＭＰマネージャ通信装置１１′へ情報を送信した旨の通知を行なう。上位アプリケーション３１は、上記ＳＮＭＰ３２１からの通知を受けて所定の処理を実行する。
【００１６】
（８）上記ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）から出力される応答パケットは、通信回線２５を経由してＳＮＭＰマネージャ通信装置１１′へ送られる。
【００１７】
（９）ＳＮＭＰマネージャ通信装置１１′は、受信した応答パケットをＳＮＭＰ２２１に入力して解析を実施する。
【００１８】
（１０）ＳＮＭＰ２２１は、上記応答パケットの解析結果に基づいてＭＩＢ２２５、２２６をアクセスして情報を更新する。
【００１９】
（１１）また、ＳＮＭＰ２２１は、ＭＩＢ２２５、２２６の更新情報に基づいて処理が必要な場合、その処理を実施する。
【００２０】
図７は、上記ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）のソフトウェア制御図である。
ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）は、起動すると同時にＳＮＭＰエージェントメインタスクが生成され、ＳＮＭＰマネージャ通信装置１１′から送られてくるＳＥＴ（更新）／ＧＥＴ（取得）要求パケットの入力待ちの状態となる（ステップＡ１）。この状態で、ＳＮＭＰマネージャ通信装置１１′からのＳＥＴ／ＧＥＴの要求パケットを受信すると、ＳＮＭＰにて規定されているパラメタチェックを行ない（ステップＡ２）、正常であればオブジェクトＩＤ毎の処理関数ＣＡＬＬを行ない、対象のオブジェクトＩＤでのＭＩＢ情報の更新／取得、応答パケットの作成を行なう（ステップＡ３）。そして、上記作成した応答パケットをＳＮＭＰマネージャ通信装置１１′へ送信する（ステップＡ４）。その後、上位アプリケーション３１に対し、ＳＮＭＰマネージャ通信装置１１′へ情報を送信した旨の通知を行なって所定の処理を実行する（ステップＡ５）。上記上位アプリケーション３１への通知を行なった後は、ステップＡ１に戻り、再びＳＮＭＰパケットの入力待ちの状態となる。
【特許文献１】特開２０００−１８１８２７号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
上記従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）では、上記（６）のステップで応答パケットをＳＮＭＰマネージャ通信装置１１′へ送信した後、（７）のステップにて上位アプリケーション３１に対する通知を行なっているので、上位アプリケーション３１の処理結果における可否については、ＳＮＭＰマネージャ通信装置１１′へ送信する応答パケットに反映されないという問題がある。
【００２２】
ＳＮＭＰマネージャ通信装置１１′においては、応答パケットに含まれる制御結果に応じてＭＩＢ２２５、２２６のＭＩＢ情報を更新するが、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）にて上記（７）のステップで発生する上位アプリケーション３１の処理が異常終了した場合、ＳＮＭＰマネージャ通信装置１１′で保持／管理しているＭＩＢ情報を別の値にて更新あるいは制御前の状態に戻す場合が発生する。このような状況が発生した場合、ＳＮＭＰマネージャ通信装置１１′とＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）でのＭＩＢ値が異なってしまう可能性がある。
【００２３】
上記のようにＳＮＭＰマネージャ通信装置１１′とＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）との間でＭＩＢ不整合が発生した場合の対処の一つとして、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）の状態変化をＳＮＭＰマネージャ通信装置１１′へ通知するＴＲＡＰパケットによる処理がＳＮＭＰでサポートされている。
【００２４】
しかし、上記ＴＲＡＰパケット通知により、ＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）の状態変化をＳＮＭＰマネージャ通信装置１１′に通知した場合でも、ＳＮＭＰマネージャ通信装置１１′では応答パケットをトリガとして該当処理を開始するため、ＴＲＡＰパケットによる通知で該当処理を中断若しくは終了させたとしても、システムとして一時的にＭＩＢ情報の不整合による不安定な状況になると考えられる。
【００２５】
また、ＳＮＭＰマネージャ通信装置１１′によって複数のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）を管理及び制御するシステムにおいては、ＳＮＭＰマネージャ通信装置１１′からＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）に対する要求パケット（ＳＥＴ／ＧＥＴ処理の要求パケット）が応答パケットとは非同期で、且つバースト的に発生する可能性がある。例えばＳＮＭＰマネージャ通信装置１１′に該当するプリンタサーバからＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）に該当するプリンタ本体へのインク残量の問い合わせがプリンタサーバを利用しているユーザから一斉に行なわれた場合等が考えられる。
【００２６】
上記のような状況が発生した場合、図７で示したようなソフトウェア制御構造では、その処理性能上、上記要求パケットに対する応答パケットが破棄されるか大幅に遅延する恐れがある。このため上記したようにシステムとして一時的にＭＩＢの不整合による不安定な状況が発生し、若しくはＳＮＭＰマネージャ通信装置１１′からの要求パケット再送処理に伴う通信トラフィックの増大が懸念される。
【００２７】
本発明は上記の課題を解決するためになされたもので、ＳＮＭＰマネージャ通信装置からＳＮＭＰエージェント通信装置に対する要求パケットが応答パケットとは非同期で、且つバースト的に発生した場合であっても、上記両通信装置間におけるＭＩＢ不整合を確実に防止し得るＳＮＭＰエージェント通信装置を提供することを目的とする。
【課題を解決するための手段】
【００２８】
第１の発明は、ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットを上位アプリケーションへ通知し、該上位アプリケーションからＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行し、前記要求パケットが取得要求であった場合に前記上位アプリケーションがＭＩＢから取得した情報を応答パケットとして前記ＳＮＭＰマネージャ通信装置へ送信することを特徴とする。
【００２９】
第２の発明は、ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットに対する処理を行なうタスクを処理パケット毎に分散させ、選択されたタスクにおいて前記要求パケットに対する処理要求メッセージを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段と、前記要求パケットを上位アプリケーションへ通知した際、該上位アプリケーションから応答メッセージが出力されるまでの時間を監視タイマにより監視し、前記応答メッセージが規定時間以上出力されなかった場合に前記要求パケットを異常処理し、待ち状態となっている新規の更新／取得処理の要求パケットを動作させる手段とを具備することを特徴とする。
【００３０】
第３の発明は、ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、該要求パケットを解析して軽負荷の要求パケットの優先度を高く設定する優先度設定手段と、前記優先度設定手段により設定された優先度の高い要求パケットを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段とを具備することを特徴とする。
【発明の効果】
【００３１】
本発明によれば、ＳＮＭＰエージェント通信装置側で受信したＭＩＢ定義情報の更新／取得処理の要求パケットを上位アプリケーションへ通知し、上位アプリケーションからＭＩＢへのアクセスを行なわせることにより、上位アプリケーションでの処理結果を反映した情報をＳＮＭＰマネージャ通信装置へ送信することが可能となり、ＳＮＭＰマネージャ通信装置とＳＮＭＰエージェント通信装置との間におけるＭＩＢ不整合を確実に防止することができる。
【００３２】
また、ＳＮＭＰマネージャ通信装置からのバースト的なパケット入力に対しても、複数のタスクに分散して処理することにより、過負荷に対する処理正常性の向上を図ることができる。更に、要求パケットに処理優先度を設定し、軽負荷のパケット処理を優先させることで、負荷に対する処理性能を更に向上することができる。
【発明を実施するための最良の形態】
【００３３】
以下、図面を参照して本発明の一実施形態を説明する。
本発明は、上記図１で説明したようにマネージャ機能を有するＳＮＭＰマネージャ通信装置（管理ステーション）１１と、このＳＮＭＰマネージャ通信装置１１にネットワーク１２を介して接続されるエージェント機能を有する複数のＳＮＭＰエージェント通信装置（被管理対象）１３ａ〜１３ｎからなるネットワークシステムを対象としている。
【００３４】
上記ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、ＳＮＭＰマネージャ通信装置１１によりＭＩＢ（Management Information base）定義に基づき遠隔管理されるものであり、ＳＮＭＰマネージャ通信装置１１から要求されるＭＩＢ定義情報のＳＥＴ（更新）処理及びＧＥＴ（取得）処理を実行する。
【００３５】
図２は、本発明の一実施形態に係るＳＮＭＰエージェント通信装置１３ａ〜１３ｎにおけるＳＮＭＰパケットフロー図であり、（１）〜（１２）の破線矢印で示した流れが実際のＳＮＭＰパケットの流れを示している。
【００３６】
上記ＳＮＭＰマネージャ通信装置１１は、従来のＳＮＭＰマネージャ通信装置１１′と同様の構成であり、上位アプリケーション２１、プロトコル（Protocol）スタック部２２、ドライバ／ＯＳ部２３からなっている。
【００３７】
また、ＳＮＭＰエージェント通信装置１３ａ〜１３ｎは、従来のＳＮＭＰエージェント通信装置１３ａ′（〜１３ｎ′）と同様の構成であり、上位アプリケーション３１、プロトコル（Protocol）スタック部３２、ドライバ／ＯＳ部３３からなっている。
【００３８】
以下、上記ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）がＳＮＭＰマネージャ通信装置１１から要求されるＭＩＢ定義情報のＳＥＴ（更新）／ＧＥＴ（取得）を行なう場合のＳＮＭＰパケットフローについて、図２を参照して説明する。
【００３９】
（１）ＳＮＭＰマネージャ通信装置１１は、ＳＮＭＰ２２１の管理に基づいて、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）が持っている現在の機器の情報を取得するためのＳＥＴ／ＧＥＴの要求パケットをドライバ／ＯＳ部２３から出力する。
【００４０】
（２）ＳＮＭＰマネージャ通信装置１１から出力される要求パケットは、通信回線２５を経由してＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）へ送られる。
【００４１】
（３）ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）は、受信した要求パケットをＳＮＭＰ３２１に入力して解析を実施する。
【００４２】
（４）ＳＮＭＰ３２１は、受信したＳＥＴ／ＧＥＴの要求パケットを上位アプリケーション３１へ通知する。
【００４３】
（５）上位アプリケーション３１は、要求パケットの解析結果に基づき、ＳＮＭＰマネージャ通信装置１１で指定されたオブジェクトＩＤに従って所定の処理を実行し、その後、ＭＩＢ３２５、３２６に対するＳＥＴ／ＧＥＴの要求処理を実施する。
【００４４】
（６）上位アプリケーション３１は、上記要求パケットがＧＥＴ（取得）要求であった場合は、ＭＩＢ３２５、３２６をアクセスして現在の情報を取得する。
【００４５】
（７）上記上位アプリケーション３１がＭＩＢ３２５、３２６から取得した情報は、ＳＮＭＰ３２１へ送られる。
【００４６】
（８）ＳＮＭＰ３２１は、上位アプリケーション３１を経由して取得した情報を応答パケットとしてドライバ／ＯＳ部３３から出力する。
【００４７】
（９）上記ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）から出力される応答パケットは、通信回線２５を経由してＳＮＭＰマネージャ通信装置１１へ送られる。
【００４８】
（１０）ＳＮＭＰマネージャ通信装置１１は、受信した応答パケットをドライバ／ＯＳ部２３からＳＮＭＰ２２１に入力して解析を実施する。
【００４９】
（１１）ＳＮＭＰ２２１は、上記応答パケットの解析結果に基づいてＭＩＢ２２５、２２６をアクセスして情報を更新する。
【００５０】
（１２）また、ＳＮＭＰ２２１は、ＭＩＢ２２５、２２６の更新情報に基づいて処理が必要な場合は、その処理を実施する。
【００５１】
上記のようにＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）側で受信したＭＩＢ定義情報の更新／取得処理の要求パケットを上位アプリケーション３１へ通知し、上位アプリケーション３１からＭＩＢ３２５，３２６へのアクセスを行なわせることにより、上位アプリケーション３１での処理結果を反映した情報をＳＮＭＰマネージャ通信装置１１へ送信することが可能となり、ＳＮＭＰマネージャ通信装置１１とＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）との間におけるＭＩＢ不整合を確実に防止することができる。
【００５２】
図３は、上記ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）のソフトウェア制御図である。
まず、ソフトウェア全体の構成として、従来ではＳＮＭＰエージェントメインタスクのみによって行なっていた処理を、本実施形態ではＳＮＭＰエージェント子タスクにて処理することを特徴としている。また、ＳＮＭＰエージェント子タスクは、システムで規定する制限値まで、受信するＳＮＭＰ要求パケットの負荷に応じて生成することが可能である。つまり、ＳＮＭＰエージェントメインタスクでは、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケット受信とパラメタチェック、ＳＮＭＰエージェント子タスクの生成が主な機能となり、ＳＮＭＰエージェント子タスクでは実際のＳＥＴ／ＧＥＴ要求パケット処理が主な機能となる。
【００５３】
以下、図３に従って詳細な処理シーケンスを説明する。
ＳＮＭＰエージェントメインタスクは、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）が起動すると同時に生成／動作し、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケット入力待ちの状態となる（ステップＢ１）。ＳＮＭＰエージェントメインタスクは、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケットを受信すると、ＳＮＭＰにて規定されているパラメタチェックを行ない（ステップＢ２）、正常であればＳＮＭＰエージェント子タスクを起動させるための前処理として受信したＳＥＴ／ＧＥＴ要求パケットに対して、ＳＮＭＰエージェント子タスクにて処理中である旨のフラグを設定する（ステップＢ３）。その後、ＳＮＭＰエージェント子タスクを生成し、ＳＮＭＰエージェントメインタスクは無限ループにて、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケットの入力待ちの状態となる。
【００５４】
ＳＮＭＰエージェント子タスクは、タスク生成後に既に起動している他のＳＮＭＰエージェント子タスクの起動総数が、システムにて規定される子タスク生成の制限値を超えていないかをチェックする（ステップＣ１）。本チェックにて、システムにて規定されている子タスク生成の制限値を超えている場合には、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）の処理性能以上の負荷が発生しているか、あるいはＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）に重大な問題が発生し、処理が不可能な状態であるかのどちらかである。しかし、何れの場合でもＳＮＭＰマネージャ通信装置１１に対して、応答パケットを送信しなければならないため、制御ＮＧにて応答パケットを送信する。なお、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）に重大な欠陥が発生しているか否かについては、ＳＮＭＰマネージャ通信装置１１からのＳＥＴ／ＧＥＴ要求パケットを一時中断して再開した場合、正常な応答パケットが送信されるかどうかで判定可能である。また、このような重大な問題が発生する可能性を低減させるため、詳細を後述するように上位アプリケーション３１側でタイマ監視による制御を導入している。
【００５５】
一方、ＳＮＭＰエージェント子タスク起動時に、システムに規定される子タスク生成の制限値を超えていない場合は、子タスク生成数をインクリメントし、ＳＥＴ／ＧＥＴ要求パケット情報テーブルのセマフォ（以下、ＰＫＴテーブルセマフォと略称する）を取得する（ステップＣ２）。上記ＳＥＴ／ＧＥＴ要求パケット情報テーブルは、ＳＮＭＰエージェント子タスク群にて共有するリソースであるため、あるＳＮＭＰエージェント子タスクがＰＫＴテーブルセマフォを取得している間は、他のＳＮＭＰエージェント子タスクにてＰＫＴテーブルセマフォを取得しようとした場合でも待ち行列につながれ、タスク状態としてはセマフォ待ちの状態となる。
【００５６】
従って、本実施形態では、一つのＳＮＭＰエージェント子タスクがＰＫＴテーブルセマフォを取得している場合の新規ＳＮＭＰエージェント子タスクの生成は制限値まで可能であるが、生成されたＳＮＭＰエージェント子タスクが動作できるのは、１タスクのみとなる。ＰＫＴテーブルセマフォを取得したＳＮＭＰエージェント子タスクは、ＳＮＭＰマネージャ通信装置１１から発生したＳＥＴ／ＧＥＴ要求パケットに含まれる制御対象のオブジェクトＩＤが複数含まれていた場合でも、上位アプリケーション３１とＩ／Ｆ（インターフェイス）との要求／応答回数を最低限に抑えるため１メッセージで上位アプリケーション３１にＳＥＴ／ＧＥＴ要求メッセージを送信するための処理、すなわちＩＰＤＵ化処理を行なう（ステップＣ３）。その後、上位アプリケーション３１へ要求メッセージを送信し、応答メッセージ待ちの状態となる（ステップＣ４）。
【００５７】
上位アプリケーション３１は、ＳＥＴ／ＧＥＴ要求メッセージに従ってＭＩＢ２２５、２２６に対する処理を行ない、応答メッセージを出力する。
【００５８】
上記ステップＣ４の応答メッセージ待ちの状態において、上位アプリケーション３１からの応答メッセージを受信すると、受信メッセージの整合性をチェックし、上位アプリケーション３１から通知された制御内容を応答パケットに反映させる処理、すなわちオブジェクトＩＤ毎の処理関数ＣＡＬＬを行なう（ステップＣ５）。全てのオブジェクトＩＤに関して、反映する処理が終了した場合、ＳＮＭＰマネージャ通信装置１１に対する応答パケットを送信する（ステップＣ６）。
【００５９】
その後、動作中取得していたＰＫＴテーブルセマフォを解放し（ステップＣ７）、タスク処理を終了する（ステップＣ８）。このタスク処理の終了と同時に子タスク生成数をデクリメントする。そして、ＰＫＴテーブルセマフォ待ち状態となっているＳＮＭＰエージェント子タスクは、待ち行列状態となっている最古のＳＮＭＰエージェント子タスクの待ち状態が解除され、以上で示した同様の手順にて処理が行なわれる。
【００６０】
上記のようにＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）に入力される要求パケットに対し、要求パケットを処理するタスクを処理パケット毎に分散させ、一時的に処理できない状態が発生する場合にはキューイングすることにより、ＳＮＭＰマネージャ通信装置１１からバースト的な要求パケットが入力された場合でも、過負荷に対する処理正常性の向上を図ることができる。
【００６１】
次に、上述したソフトウェア制御方法により発生する懸念のある重大な問題に対しての改善方法を説明する。
上記図３で説明したように、本実施形態におけるソフトウェア制御方法では、ＰＫＴテーブル情報のセマフォ解放のトリガを上位アプリケーション３１からの応答メッセージとしている。このため上位アプリケーション３１からの応答メッセージがＳＮＭＰエージェント子タスクにて受信されない限り、その他全ての待ち状態となっているＳＥＴ／ＧＥＴ要求パケットが解消されない。このため一旦本状態に陥った場合には、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）全体のリセットを行なわなければ復旧不可能な状態となる。
【００６２】
上記のような状態に陥るのを可能な限り避けるため、上位アプリケーション３１に対して応答メッセージに対するタイマによる監視制御を行ない、規定時間以上、上位アプリケーション３１からの応答メッセージが到着しない場合には、タイムアウト処理の中で、ＳＮＭＰマネージャ通信装置１１に対する応答パケットを送信し、待ち状態となっている新規のＳＥＴ／ＧＥＴ要求パケットを動作させる異常処理を行なう。
【００６３】
すなわち、図４のソフトウェア制御図に示すように、上記図３で説明したＳＮＭＰエージェント子タスク処理において、ステップＣ３でＩＰＤＵ化処理を行なった際、上位アプリケーション（上位ＡＰ）３１へ要求メッセージを送出する（ステップＤ１）。このとき監視タイマをセットし（ステップＤ２）、応答メッセージ待ちの状態となる（ステップＣ４）。この応答メッセージ待ちの状態では、上位アプリケーション３１からの応答メッセージの有無を判定し（ステップＤ３）、応答メッセージがなければ上記監視タイマによる計測時間が予め設定した規定時間を経過したかどうかを判定する（ステップＤ４）。上記監視タイマによる計測時間が規定時間を経過していなければステップＣ４へ戻り、応答メッセージ待ちの状態となる。
【００６４】
そして、上記規定時間を経過する前に上位アプリケーション３１から応答メッセージが送られてきた場合は、上記監視タイマをリセットし（ステップＤ５）、上記図３に示したステップＣ５の処理（オブジェクトＩＤ毎の処理関数ＣＡＬＬ）に進む。
【００６５】
また、上記ステップＤ４で監視タイマによる計測時間が規定時間を経過したと判定された場合には、当該ＳＥＴ／ＧＥＴ要求パケットをエラー処理し（ステップＤ６）、待ち状態となっている新規のＳＥＴ／ＧＥＴ要求パケットを動作させる（ステップＤ７）。
【００６６】
上記の異常処理により、上位アプリケーション３１からの応答メッセージが送信されない場合でも、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）全体を異常状態とさせずに、当該ＳＥＴ／ＧＥＴ要求パケットのみをエラーとすることで、システム全体の安定性を向上させることが可能となる。
【００６７】
次に、上述したソフトウェア制御方法により発生する懸念のある重大な問題に対しての他の改善方法について説明する。
この改善方法は、ソフトウェア制御アルゴリズムの一つとして受信したＳＥＴ／ＧＥＴ要求パケットに処理優先度を設け、軽負荷のＳＥＴ／ＧＥＴ要求パケット処理を優先させることで、待ち行列につながれるＳＮＭＰエージェント子タスク数を低減し、処理優先度を設けない場合よりも応答パケットがエラーとなる可能性を低減したものである。
【００６８】
本発明におけるソフトウェア制御方法のクリティカルセクション（上位アプリケーション３１へ要求メッセージを送出してから応答メッセージを受信するまで）を如何に短縮できるかが、本ソフトウェア制御方法を導入したＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）の性能を大きく左右する要素となっている。ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）は、その性質上、ＳＥＴ／ＧＥＴ要求パケットに対して処理負荷に差が生じる。例えばＳＥＴ／ＧＥＴ要求パケットについてあるＧＥＴ要求パケットは、ＭＩＢ３２５、３２６で管理している一つの情報を取得するだけの場合もあり、装置状態や条件によって、その都度計算や上位アプリケーション３１間で問い合わせが必要な場合もある。これらＳＥＴ／ＧＥＴ要求パケットの種類と組み合わせについては、ＳＮＭＰマネージャ通信装置１１間で既に規定されているので、ＳＥＴ／ＧＥＴ要求パケットの内容を解析することによって、処理負荷の大きさを判定することが可能である。
【００６９】
図５は、上記のように処理優先度を考慮したＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）のソフトウェア制御図（ＳＮＭＰエージェント子タスク）の一例を示したものである。
【００７０】
ＳＮＭＰエージェント子タスクは、図３で説明したようにタスク生成後に既に起動している他のＳＮＭＰエージェント子タスクの起動総数が、システムにて規定される子タスク生成の制限値を超えていないかをチェックする（ステップＣ１）。
【００７１】
次いで、受信した要求パケットを解析し、処理負荷が高い要求パケットは、別領域にキューイングする（ステップＥ１）。その後は、上記図３で説明したように、子タスク生成数のインクリメント及びＰＫＴテーブルセマフォの取得処理（ステップＣ２）、ＩＰＤＵ化処理（ステップＣ３）、上位アプリケーション３１への要求メッセージ送信、上位アプリケーション３１からの応答メッセージ待ち（ステップＣ４）、オブジェクトＩＤ毎の処理関数ＣＡＬＬ（ステップＣ５）、ＳＮＭＰマネージャ通信装置１１に対する応答パケットの送信（ステップＣ６）、ＰＫＴテーブルセマフォ解除（ステップＣ７）、等の処理を行なう。
【００７２】
以上の処理を行ない、子タスク生成数が「０」であれば、上記ステップＥ１で別領域にキューイングしていた要求パケットを解放する（ステップＥ２）。以上でタスク処理を終了し（ステップＣ８）、タスク終了と同時に子タスク生成数をデクリメントする。
【００７３】
上記したようにＳＮＭＰマネージャ通信装置１１から送られてきたＳＥＴ／ＧＥＴ要求パケットに処理優先度を設け、軽負荷のＳＥＴ／ＧＥＴ要求パケット処理を優先させることで、待ち行列につながれるＳＮＭＰエージェント子タスク数を低減し、処理優先度を設けない場合よりも応答パケットがエラーとなる可能性を低減することができる。
【００７４】
なお、上述したシステムにて規定される子タスク生成の制限値、上位アプリケーション３１における応答メッセージの応答時間を監視するタイマの値、更には要求パケットの処理優先度を考慮する際の判定条件については、ＳＮＭＰエージェント通信装置１３ａ（〜１３ｎ）の性能に大きな影響があるため、個々の通信装置において性能に合わせて設定する。
【図面の簡単な説明】
【００７５】
【図１】本発明の対象とするネットワークシステムの全体の概略構成を示すシステム構成図である。
【図２】本発明の一実施形態に係るＳＮＭＰエージェント通信装置のＳＮＭＰパケットフロー図である。
【図３】同実施形態におけるＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【図４】本発明のタイマによる監視制御機能を備えたＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【図５】本発明の処理優先度を考慮したＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【図６】従来のＳＮＭＰエージェント通信装置におけるＳＮＭＰパケットフロー図である。
【図７】従来のＳＮＭＰエージェント通信装置におけるＳＮＭＰエージェント通信装置のソフトウェア制御図である。
【符号の説明】
【００７６】
１１…ＳＮＭＰマネージャ通信装置、１２…ネットワーク、１３ａ〜１３ｎ…ＳＮＭＰエージェント通信装置、２１…上位アプリケーション（上位ＡＰ）、２２…プロトコルスタック部、２２１…ＳＮＭＰ、２２２…ＵＤＰ、２２３…ＴＣＰ、２２４…ＩＰ、２２５、２２６…ＭＩＢ、２３…ドライバ／ＯＳ部、２３１…ドライバ、２３２…ＯＳ、２５…通信回線、３１…上位アプリケーション（上位ＡＰ）、３２…プロトコルスタック部、３２１、３２２…ＳＮＭＰ、３２３…ＴＣＰ、３２４…ＩＰ、３２５、３２６…ＭＩＢ、３３…ドライバ／ＯＳ部、３３１…ドライバ、３３２…ＯＳ。
【特許請求の範囲】
【請求項１】
ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットを上位アプリケーションへ通知し、該上位アプリケーションからＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行し、前記要求パケットが取得要求であった場合に前記上位アプリケーションがＭＩＢから取得した情報を応答パケットとして前記ＳＮＭＰマネージャ通信装置へ送信することを特徴とするＳＮＭＰエージェント通信装置。
【請求項２】
ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットに対する処理を行なうタスクを処理パケット毎に分散させ、選択されたタスクにおいて前記要求パケットに対する処理要求メッセージを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段と、前記要求パケットを上位アプリケーションへ通知した際、該上位アプリケーションから応答メッセージが出力されるまでの時間を監視タイマにより監視し、前記応答メッセージが規定時間以上出力されなかった場合に前記要求パケットを異常処理し、待ち状態となっている新規の更新／取得処理の要求パケットを動作させる手段とを具備することを特徴とするＳＮＭＰエージェント通信装置。
【請求項３】
ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、該要求パケットを解析して軽負荷の要求パケットの優先度を高く設定する優先度設定手段と、前記優先度設定手段により設定された優先度の高い要求パケットを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段とを具備することを特徴とするＳＮＭＰエージェント通信装置。
【請求項１】
ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットを上位アプリケーションへ通知し、該上位アプリケーションからＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行し、前記要求パケットが取得要求であった場合に前記上位アプリケーションがＭＩＢから取得した情報を応答パケットとして前記ＳＮＭＰマネージャ通信装置へ送信することを特徴とするＳＮＭＰエージェント通信装置。
【請求項２】
ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、この要求パケットに対する処理を行なうタスクを処理パケット毎に分散させ、選択されたタスクにおいて前記要求パケットに対する処理要求メッセージを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段と、前記要求パケットを上位アプリケーションへ通知した際、該上位アプリケーションから応答メッセージが出力されるまでの時間を監視タイマにより監視し、前記応答メッセージが規定時間以上出力されなかった場合に前記要求パケットを異常処理し、待ち状態となっている新規の更新／取得処理の要求パケットを動作させる手段とを具備することを特徴とするＳＮＭＰエージェント通信装置。
【請求項３】
ＳＮＭＰエージェント機能を有し、ネットワークで接続されたＳＮＭＰマネージャ通信装置によるＭＩＢ定義に基づいて遠隔管理されるＳＮＭＰエージェント通信装置において、前記ＳＮＭＰマネージャ機能を有する管理装置から要求されるＭＩＢ定義情報の更新／取得処理の要求パケットを受信した際、該要求パケットを解析して軽負荷の要求パケットの優先度を高く設定する優先度設定手段と、前記優先度設定手段により設定された優先度の高い要求パケットを上位アプリケーションへ通知する通知手段と、該通知を受けた上位アプリケーションによりＭＩＢにアクセスしてＭＩＢ定義情報の更新／取得処理を実行して応答メッセージを出力する手段と、前記上位アプリケーションから出力される応答メッセージに基づいて応答パケットを前記ＳＮＭＰマネージャ通信装置へ送信する手段とを具備することを特徴とするＳＮＭＰエージェント通信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００７−６０２８２（Ｐ２００７−６０２８２Ａ）
【公開日】平成１９年３月８日（２００７．３．８）
【国際特許分類】
【出願番号】特願２００５−２４３０４３（Ｐ２００５−２４３０４３）
【出願日】平成１７年８月２４日（２００５．８．２４）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【Ｆターム（参考）】
【公開日】平成１９年３月８日（２００７．３．８）
【国際特許分類】
【出願日】平成１７年８月２４日（２００５．８．２４）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【Ｆターム（参考）】
[ Back to top ]