JP2000181826A - ネットワークデバイス制御装置及び方法 - Google Patents

Abstract

(57)【要約】 【課題】エージェントにおけるエラー(tooBig)の発生を
防ぐ。 【解決手段】ユーザからの操作により要求されたＳＮＭ
Ｐメッセージが複数のオブジェクトを含むGetRequestで
あるかどうかを判断し（Ｓ１０２，Ｓ１０３）、送信を
要求されたGetRequestパケットに複数のオブジェクトに
関する情報が含まれていた場合、各オブジェクトのデー
タタイプを解析し、応答パケットのトータル長の最大値
を予測し（Ｓ１０５）、予測されたレングスの最大値が
所定長を超える場合、GetRequestパケットを分割し送信
する（Ｓ１０７，Ｓ１０８）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＳＮＭＰプロトコ
ルを用いたネットワーク管理ソフトウエアによるネット
ワークデバイス制御装置及び方法に関する。

【０００２】

【従来の技術】ネットワーク上のデバイスを管理するた
めの方法として、これまでにいくつかの試みが数多くの
標準機関でなされている。国際標準化機構（ＩＳＯ）は
開放型システム問相互接続（Open System Interconnect
ion，ＯＳＩ）モデルと呼ばれる汎用基準フレームワー
クを提供した。ネットワーク管理プロトコルのＯＳＩモ
デルは、共通管理情報プロトコル（Comon Management I
nformation Protocol，ＣＭＩＰ）と呼ばれる。ＣＭＩ
Ｐはヨーロッパの共通ネットワーク管理プロトコルであ
る。

【０００３】米国においては、より共通性の高いネット
ワーク管理プロトコルとして、簡易ネットワーク管理プ
ロトコル（Simple Network Managment Protocol，ＳＮ
ＭＰ）と呼ばれるＣＭＩＰに関連する一変種のプロトコ
ルがある。（「ＴＣＰ／ＩＰネットワーク管理入門実用
的な管理をめざして」Ｍ．Ｔ．ローズ＝著／西田竹志＝
訳（株）トッパン発行１９９２年８月２０日初版を参照
のこと）。

【０００４】ＳＮＭＰネットワーク管理技術によれば、
ネットワーク管理システムには、少なくとも１つのネッ
トワーク管理ステーション（ＮＭＳ）、各々がエージェ
ントを含むいくつかの管理対象ノード、及び管理ステー
ションやエージェントが管理情報を交換するために使用
するネットワーク管理プロトコルが含まれる。

【０００５】ユーザは、ＮＭＳ上でネットワーク管理ソ
フトウエア（以下、マネージャとも呼ぶ）を用いて管理
対象ノード上のエージェントソフトウエアと通信するこ
とにより、ネットワーク上のデータを取得および変更す
ることができる。

【０００６】エージェントとは、各々のターゲット装置
についてのバックラウンドプロセスとして走るソフトウ
エアである。これに対しＮＭＳ及びＮＭＳ上で動作する
ネットワーク管理ソフトウエアを一般的にマネージャと
呼ぶ。

【０００７】ユーザからの操作によりマネージャがネッ
トワーク上の装置に対して管理データを要求した場合、
マネージャはオブジェクト識別情報を管理パケットまた
はフレームに入れてターゲットエージェントへ送り出
す。エージェントは、そのオブジェクト識別情報を解釈
して、そのオブジェクト識別情報に対応するデータを取
り出し、そのデータをパケットに入れてマネージャに送
り返す。時には、データを取り出すために対応するプロ
セスが呼び出される場合もある。

【０００８】エージェントは、自分の状態に関するデー
タをデータベースの形式で保持している。このデータベ
ースのことを、ＭＩＢ(Management Information Base)
と呼ぶ。図６は、ＭＩＢの構造を示す概念図である。図
６に示すように、ＭＩＢは木構造のデータ構造をしてお
り、全てのノードが一意に番号付けされている。図６に
おいて、カッコ内に書かれている番号が、そのノードの
識別子である。

【０００９】例えば、図６においてノード６０１の識別
子は１である。ノード６０２の識別子は、ノード６０１
の下の３なので、１・３と表記される。同様にして、ノ
ード６０３の識別子は、１・３・６・１・２と表記され
る。

【００１０】このノードの識別子のことを、オブジェク
ト識別子(OBJECT IDENTIFIER)と呼ぶ。

【００１１】このＭＩＢの構造は、管理情報構造（ＳＭ
Ｉ：Structure of Management Informatilon）と呼ば
れ、RFC1155 Structure and Identificatlon of Manage
ment Information for TCP/IP-based Internetsで規定
されている。

【００１２】図６には、標準として規定されているＭＩ
Ｂのうち、一部のもののみを抜き出して記載してある。

【００１３】６０４は、ＳＮＭＰで管理される機器が標
準的に備えている標準ＭＩＢと呼ばれるオブジェクト群
の頂点になるノードであり、このノードの下のオブジェ
クトの詳細な構造については、RFC1213 Management Inf
ormation Base for NetworkManagement of TCP/IP-base
d internets:MIB-IIに規定されている。

【００１４】６０５は、ＳＮＭＰで管理されるプリンタ
が標準的に備えているプリンターＭＩＢと呼ばれるオブ
ジェクト群の頂点になるノードであり、このノードの下
のオブジェクトの詳細な構造については、RFC 1759 Pri
nter MIBで規定されている。さらに、６０６はプライベ
ートＭＩＢと呼ばれ、企業や団体などが独自のＭＩＢ定
義を行うための頂点となるノードである。６０７は企業
拡張ＭＩＢと呼ばれ、プライベートＭＩＢの中で企業が
独自の拡張を行うための頂点となるノードである。キヤ
ノン株式会社には、独自の定義を行うために企業番号と
して１６０２が割り当てられており、キヤノン独自のＭ
ＩＢであるキヤノンＭＩＢ（ＣａｎｏｎＭＩＢ）を定義
するための頂点ノード６０８が、企業を意味するノード
であるノード６０７の下に位置している。キヤノンＭＩ
Ｂの頂点ノードのオブジェクト識別子は、１・３・６・
１・４・１・１６０２である。

【００１５】また、ＳＮＭＰではエージェントのＭＩＢ
の変数を調べたり、設定したりするために、以下のメッ
セージを使用する。 ・GET REQUESTメッセージ（マネージャからエージェン
トへ） 指定されたＭＩＢ変数を読む ・GET NEXT REQUESTメッセージ（マネージャからエージ
ェントへ） ＭＩＢの順序に従い、指定されたＭＩＢ変数の次の値を
読む ・GET RESPONSEメッセージ（エージェントからマネージ
ャヘ） 要求(GET/GET NEXT/SET REQUEST)に対するエージェント
からの応答 ・SET REQUESTメッセージ（マネージャからエージェン
トヘ） ＭＩＢ変数に指定された値を設定する ・TRAPメッセージ（エージェントからマネージャへ） 異常や事象の発生をエージェントからマネージャに知ら
せる ＳＮＭＰメッセージは、バージョン番号・ＳＮＭＰコミ
ュニティ名・ＰＤＵ（Protocol Data Unit)より構成さ
れ、そのコーディング方法は、ＡＳＮ．１（Abstract S
yntax Notation 1)のＢＥＲ(Basic Encoding Rule)に従
っている。

【００１６】各メッセージに対応して以下の５つのＰＤ
Ｕを必須でサポートしなければならない。 ・GetRequest-PDU GET REQUESTメッセージのためのＰＤＵ ・GetNextRequest-PDU ＧET NEXT REQUESTメッセージのためのＰＤＵ ・GetResponse-PDU GET RESPONSEメッセージのためのＰＤＵ ・SetRequest-PDU SET REQUESTメッセージのためのＰＤＵ ・Trap-PDU TRAPメッセージのためのＰＤＵ なお、これらのＰＤＵのデータフォーマット（Trap-PDU
以外）を図２に示す。

【００１７】本図において２０１がＳＮＭＰメッセージ
であり、２０２がＳＮＭＰのバージョン情報が格納され
る領域であり、２０３がＳＮＭＰの管理対象となる１つ
のエージェントとそれを管理する１つ以上のマネージャ
をグループ化したコミュニティの名前（コミュニティ
名）を設定する領域である。エージェントは、自分の属
するコミュニティ名と比較し、一致する場合のみその要
求を受け付ける。２０４は各ＳＮＭＰのＰＤＵが格納さ
れる領域であり、２０５がＰＤＵを示す。ＳＮＭＰメッ
セージはＰＤＵのヘッダにそのメッセージの種別（GET
REQUEST，GET NEXT REQUEST，SET REQUEST）に関する情
報を格納している。

【００１８】２０６はGET REQUEST，GET NEXT REQUES
T，SET REQUESTの要求時にマネージャが設定するリクエ
ストＩＤが設定される。エージェントは、その応答のGE
T RESPONSEに同じ値を設定し、どの要求に対する応答か
をマネージャ側で判断できるようにする。２０７はエラ
ーステータスが格納される領域である。エラーステータ
スとはマネージャが要求したＳＮＭＰメッセージの中に
エラーがあったとき、エージェントからマネージャへの
通知(GET RESPONSE)に使用するものであり、要求時のＰ
ＤＵではnoErrorを設定する。なお、エージェントとし
て通知可能なエラーとして以下のものがある。 ・noError ： 正常（エラーなし）。 ・tooBig ： 結果としての応答をＳＮＭＰメッセ
ージにする際、そのエージェントでの長さの制限を越え
てしまった。 ・noSuchName： 指定されたオブジェクト名が見つか
らない。

【００１９】GET NEXT REQUESTの場合は、検索の最後に
なったとき、このエラーを返す。 ・badValue ： SET REQUESTで指定されたオブジェ
クトの長さ、タイプ、値が正しくない。 ・readOnly ： 読み出ししかできないオブジェクト
に対してSET REQUESTが要求された。 ・genErr ： 上記以外のエラーがエージェント側
で発生した。

【００２０】２０８は、要求されたＳＮＭＰメッセージ
上で何番目のオブジェクトにエラーのあったのかを示す
エラーインデックスが格納される領域である。

【００２１】２０９はオブジェクト名（２１０，２１
２）とその値（２１１，２１３）の対の配列(variable-
bindings)が格納される領域である。しがって、ＳＮＭ
Ｐメッセージは複数のオブジェクトに対する要求を１つ
のメッセージに格納することができる。

【００２２】図４はエージェントに対して１つのＳＮＭ
Ｐメッセージで複数のオブジェクト（ObjectA，Object
B，ObjectC）に設定された値(Value)を取得する場合の
シーケンス図である。

【００２３】同図において、４０１ではマネージャから
複数のオブジェクト、ObjectA，ObjectB，ObjectCに値
に設定された値を取得するためのGetRequestパケットが
送出される。

【００２４】これを受けて４０２ではエージェント側で
はそれぞれのオブジェクトに設定されている値Ｘ，Ｙ，
Ｚを通知するためGetResponseパケットをマネージャに
送信する。

【００２５】

【発明が解決しようとする課題】図５は、マネージャが
１つのGetRequestパケットによって複数のオブジェクト
（ObjectA，ObjectB，ObjectC）に設定された値(Value)
を取得する場合のシーケンス図である。なお、同図にお
いてエージェントが送信可能なパケットの最大レングス
をＲＦＣ１１５７で保証が推奨されている４８４オクテ
ットであるものとし、エージェント側においてObject
A，ObjectB，ObjectCに設定される値は、Ｘ，Ｙ，Ｚで
あり、これらの情報を含んだGetResponseパケットのト
ータルレングスは、４８４オクテット以上になると仮定
する。

【００２６】５０１ではマネージャから複数のオブジェ
クト、ObjectA，ObjectB，ObjectCの値を取得するため
のGetRequestパケットが送出される。５０２ではエージ
ェントに設定されたObjectA，ObjectB，ObjectCの値を
マネージャに通知するためGetResponseパケットの生成
がおこなわれるが、符号化の結果、GetResponseパケッ
トのトータルレングスが４８４オクテットを超え、エー
ジェント処理能力を超えるため、GetResponseパケット
によってマネージャにエラー(tooBig)が通知される。

【００２７】このように、GetRequestパケットによって
要求されるGetResponseパケットのデータレングスがエ
ージェントの処理能力を超えエラー(tooBig)を返すとい
ったことは、ＳＮＭＰプロトコルを利用したネットワー
ク管理において非常に一般的な障害である。

【００２８】上記従来のＳＮＭＰプロトコルを用いたネ
ットワークデバイス制御装置及び方法では、複数のオブ
ジェクトに対する情報の取得を１つのGetRequestパケッ
トで要求した場合、エージェント側で要求されたオブジ
ェクトの値を含むGetResponseパケットのトータルレン
グスがエージェントの処理能力を超え、エラー(tooBig)
を発生する可能性があり、ＳＮＭＰプロトコルによるネ
ットワーク管理の大きな障害となっていた。

【００２９】本発明は上記従来例に鑑みてなされたもの
で、エージェントにおけるエラー(tooBig)の発生を防ぐ
ことを目的とする。

【００３０】

【課題を解決するための手段】前記目的を達成するため
に本発明は継ぎのような構成から成る。すなわち、ネッ
トワークで接続されたデバイスからデータを読み出すた
めのネットワーク管理方法であって、前記デバイスに含
まれる複数のオブジェクトに対して、データの要求が生
じたか判定する第１の判定工程と、要求が生じたと判定
された場合、該デバイスからの応答データ長が、前記デ
バイスの扱えるデータ長の上限を越えるか予測する第２
の判定工程と、応答データ長が上限を越えると予測され
る場合には、前記データの要求を、オブジェクト単位で
分割し、それぞれの要求を前記デバイスに送信する工程
とを備える。

【００３１】また好ましくは、前記デバイスはプリンタ
装置である。

【００３２】あるいは、ユーザからの操作により要求さ
れたＳＮＭＰメッセージがGetRequestであるかどうかを
判断し、要求されたＳＮＭＰメッセージがGetRequestで
ある場合に、パケット内に複数のオブジェクトに関する
情報が含まれているかどうかを解析し、送信を要求され
たGetRequestパケットに複数のオブジェクトに関する情
報が含まれていた場合、各オブジェクトに設定される値
のデータタイプを解析し、解析されたデータタイプから
エージェントにおいて生成されるGetResponseパケット
のトータルレングスの最大値を予測し、予測されたレン
グスの最大値がＲＦＣ１１５７で最低限保証される４８
４オクテットを超える場合、GetRequestパケットを分割
し送信する

【発明の実施の形態】以下図面を用いて本発明によるＳ
ＮＭＰプロトコルを用いたネットワーク管理ソフトウエ
アを含むネットワークデバイス制御装置及び方法につい
て説明する。

【００３３】図９は、本実施の形態のプリンタをネット
ワークに接続するためのネットワークボード（ＮＥＢ）
１０１を、開放型アーキテクチャを持つプリンタ１０２
へつなげた場合を示す図である。ＮＥＢ１０１はローカ
ルエリアネットワーク（ＬＡＮ）１００へ、例えば、同
軸コネクタをもつイーサネット（登録商標）インターフ
ェース１０Ｂａｓｅ−２や、ＲＪ−４５を持つ１０Ｂａ
ｓｅ−Ｔ等のＬＡＮインターフェースを介して接続され
ている。

【００３４】ＰＣ１０３やＰＣ１０４等の複数のパーソ
ナルコンピュータ（ＰＣ）もまた、ＬＡＮ１００に接続
されており、ネットワークオペレーティングシステムの
制御の下、これらのＰＣ１０３，１０４はＮＥＢ１０１
と通信することができる。この状態で、ＰＣの一つ、例
えばＰＣ１０３を、ネットワーク管理部として使用する
ように指定することができる。またＰＣ１０３に、ＰＣ
１０４に接続されているプリンタ１０５のようなプリン
タを接続してもよい。

【００３５】また、ＬＡＮ１００にファイルサーバ１０
６が接続されており、これは大容量（例えば１００億バ
イト）のネットワークディスク１０７に記憶されたファ
イルへのアクセスを管理する。プリントサーバ(PSERVE
R)１０８は、接続されたプリンタ１０９ａ，１０９ｂ等
や、又は遠隔地にあるプリンタ１０５などのプリンタに
印刷を行わせる。

【００３６】また他の図示しない周辺機器をＬＡＮ１０
０に接続してもよい。

【００３７】更に詳しくは、図９に示すネットワーク
は、様々なネットワークメンバ間で効率良く通信を行う
ために、ノベル社やＵＮＩＸのソフトウェアなどのネッ
トワークソフトウェアを使用することができる。どのネ
ットワークソフトウェアを使用することも可能である
が、例えば、ノベル社のNetWare（ノベル社の登録商
標）ソフトウェアを使用することができる。このソフト
ウェアパッケージに関する詳細な説明は、NetWareパッ
ケージに同梱されているオンラインドキュメンテーショ
ンに記載されている。

【００３８】図９の構成について簡潔に説明すると、フ
ァイルサーバ１０６は、ＬＡＮメンバ間でデータのファ
イルの受信や、記憶、キューイング、キャッシング、及
び送信を行うファイル管理部としての役割を果たす。例
えば、ＰＣ１０３及びＰＣ１０４のそれぞれによって作
られたデータファイルは、ファイルサーバ１０６へ送ら
れ、ファイルサーバ１０６はこれらのデータファイルを
順に並べ、そしてプリントサーバ１０８からのコマンド
に従って、並べられたデータファイルをプリンタ１０９
へ送信する。

【００３９】またＰＣ１０３とＰＣ１０４はそれぞれ、
データファイルの生成や、生成したデータファイルのＬ
ＡＮ１００への送信や、また、ＬＡＮ１００からのファ
イルの受信や、更にそのようなファイルの表示及び／又
は処理を行うことのできる通常のＰＣで構成される。
尚、図９ではパーソナルコンピュータ機器が示されてい
るが、ネットワークソフトウェアを実行するのに適切で
あるような、他のコンピュータ機器を含んでもよい。例
えば、ＵＮＩＸのソフトウェアを使用している場合に、
ＵＮＩＸワークステーションをネットワークに含んでも
よく、これらのワークステーションは、適切な状況下
で、図示されているＰＣと共に使用することができる。

【００４０】通常、ＬＡＮ１００などのＬＡＮは、一つ
の建物内の一つの階又は連続した複数の階でのユーザグ
ループ等のローカルなユーザグループにサービスを提供
する。例えば、ユーザが他の建物や他県にいるなど、あ
るユーザが他のユーザから離れるに従って、ワイドエリ
アネットワーク（ＷＡＮ）を作ってもよい。ＷＡＮは、
基本的には、いくつかのＬＡＮを高速度サービス総合デ
ジタルネットワーク（ＩＳＤＮ）電話線等の高速度デジ
タルラインで接続して形成された集合体である。従っ
て、図１に示すように、ＬＡＮ１００とＬＡＮ１１０と
ＬＡＮ１２０とを、変調／復調（ＭＯＤＥＭ）／トラン
スポンダ（ＭＯＤＥＭ／ＲＯＵＴＥＲ）１３０及びバッ
クボーン１４０を介して接続されてＷＡＮを形成する。
これらの接続は、数本のバスによる単純な電気的接続で
ある。それぞれのＬＡＮは専用のＰＣを含み、また、必
ずしも必要なわけではないが、通常はファイルサーバ及
びプリントサーバを含む。

【００４１】従って図９に示すように、ＬＡＮ１１０
は、ＰＣ１１１と、ＰＣ１１２と、ファイルサーバ１１
３と、ネットワークディスク１１４と、プリントサーバ
１１５と、プリンタ１１６及びプリンタ１１７とを含
む。対照的に、ＬＡＮ１２０はＰＣ１２１とＰＣ１２２
のみを含む。ＬＡＮ１００と、ＬＡＮ１１０と、ＬＡＮ
１２０とに接続されている機器は、ＷＡＮ接続を介し
て、他のＬＡＮの機器の機能にアクセスすることができ
る。

【００４２】本実施の形態では、図９のネットワークシ
ステムには、それに接続されたデバイスを管理するため
の方法として、簡易ネットワーク管理プロトコル（Slmp
le Network Managment Protocol，ＳＮＭＰ）がインプ
リメントされる。

【００４３】＜＜ネットワークボード上へのエージェン
トの実装＞＞エージェントの実装例として、プリンタを
ネットワークに接続するためのネットワークボード上に
エージェントを実装することが考えられる。これによ
り、プリンタをネットワーク管理ソフトウェアによる管
理の対象とすることができる。ユーザは、ネットワーク
管理ソフトウェアを用いて制御対象のプリンタの情報を
得、また状態を変更することができる。より具体的に
は、例えばプリンタの液晶ディスプレイに表示されてい
る文字列を取得したり、デフォルトの給紙カセットを変
更したりすることができる。以下、エージェントを実装
したネットワークボード（ＮＥＢ）をプリンタに接続す
る例で説明する。

【００４４】図１０に示すように、好ましくは、ＮＥＢ
１０１は、プリンタ１０２の内部拡張Ｉ／Ｏスロットに
内蔵されており、ＮＥＢ１０１は、下に示す処理及びデ
ータ記憶機能を持つ「埋め込まれた」ネットワークノー
ドとなる。このＮＥＢ１０１の構成により、大きなマル
チエリアＷＡＮネットワークを統括及び管理するため
の、特徴的な補助機能を持つという利点をもたらす。こ
れらの補助機能は、例えば、ネットワーク上の遠隔地
（ネットワーク統括者の事務所など）からのプリンタ制
御及び状態観察や、各印刷ジョブ後の次のユーザのため
の保証初期環境を提供するためのプリンタ構成の自動管
理、及びプリンタの負荷量を特徴付け、あるいはトナー
カートリッジの交換スケジュールを組むためにネットワ
ークを通してアクセスできる、プリンタログ又は使用統
計を含む。

【００４５】このＮＥＢ設計において重要な要因は、共
有メモリ２００等の両方向インターフェースを介して、
ＮＥＢ１０１からプリンタ制御状態にアクセスする機能
である。共有メモリ以外に、ＳＣＳＩインターフェース
等のインターフェースを使用することもできる。これに
より、多数の便利な補助機能のプログラムができるよう
に、プリンタ操作情報をＮＥＢ１０１又は外部ネットワ
ークノードへ送出することができる。印刷画像データ及
び制御情報のブロックは、ＮＥＢ１０１上にあるマイク
ロプロセッサ３０１によって構成され、共有メモリ２０
０に記述され、そして、プリンタ１０２によって読み込
まれる。同様に、プリンタ状態情報は、プリンタ１０２
から共有メモリ２００へ送られ、そこからＮＥＢ上のマ
イクロプロセッサ３０１によって読み込まれる。

【００４６】図１０は、ＮＥＢ１０１をプリンタ１０２
にインストールした状態を示す一部破断図である。図１
０に示すように、ＮＥＢ１０１はネットワーク接続の為
のフェースプレート１０１ｂを設置した印刷回路ボード
１０１ａから構成されており、コネクタ１７０を介して
プリンタインターフェースカード１５０に接続されてい
る。プリンタインターフェースカード１５０は、プリン
タ１０２のプリンタエンジンを直接制御する。印刷デー
タ及びプリンタ状態コマンドは、ＮＥＢ１０１からコネ
クタ１７０を介して、プリンタインターフェースカード
１５０へ入力され、また、プリンタ状態情報はプリンタ
インターフェースカード１５０からやはりコネクター１
７０を介して得られる。ＮＥＢ１０１はこの情報を、フ
ェースプレート１０１ｂのネットワークコネクタを介し
て、ＬＡＮ１００上で通信する。同時に、プリンタ１０
２は、一般的なシリアルポート１０２ａ及びパラレルポ
ート１０２ｂから、印刷データを受信することもでき
る。

【００４７】図１１は、ＮＥＢ１０１とプリンタ１０２
とＬＡＮ１００との電気的接続を示すブロック図であ
る。ＮＥＢ１０１は、ＬＡＮ１００へはＬＡＮインター
フェースを介して、プリンタ１０２へはプリンタインタ
ーフェースカード１５０を介して直接接続されている。
ＮＥＢ１０１上にはＮＥＢ１０１を制御するためのマイ
クロプロセッサ（ＭＰＵ）３０１と、マイクロプロセッ
サ３０１の動作プログラムを格納するためのＲＯＭ３０
３と、マイクロプロセッサ３０１がプログラムを実行す
る上でワークとして用いるためのＲＡＭ３０２と、ＮＥ
Ｂ１０１とプリンタインタフェースカード１５０とが相
互にデータをやりとりするための共有メモリ２００があ
り、これらは内部バスを通じて相互に接続されている。
ＮＥＢ１０１がＳＮＭＰのエージェントとして動作する
ためのプログラムはＲＯＭ３０３に格納されている。マ
イクロプロセッサ３０１は、ＲＯＭ３０３に格納された
プログラムに従って動作し、ワークエリアとしてＲＡＭ
３０２を用いる。また、プリンタインターフェースカー
ド１５０と相互に通信するためのバッファ領域として共
有メモリ２００を用いる。

【００４８】プリンタインタフェースカード１５０上の
マイクロプロセッサ１５１はＮＥＢ１０１とのデータの
アクセスを、ＮＥＢ１０１に設置されている共有メモリ
２００を介して行う。プリンタインタフェースカード１
５０上のマイクロプロセッサ１５１は、実際に印刷機構
を動かすプリンタエンジン１６０とも通信する。

【００４９】＜＜ネットワーク管理プログラムを実行す
るＰＣの構成＞＞図７は、本発明によるネットワーク管
理ソフトウエアが稼動可能なＰＣの構成を示すブロック
図である。図７において、７０１は、ネットワーク管理
ソフトウエアが稼動するＰＣである。ＰＣ７０１は、Ｒ
ＯＭ７０３もしくはハードディスク（ＨＤ）７１２に記
憶された、あるいはフロッピー（登録商標）ディスクド
ライブ（ＦＤ）７１３より供給されるネットワーク管理
プログラムを実行するＣＰＵ７０２を備え、システムバ
ス７０５に接続される各デバイスを総括的に制御する。

【００５０】７０４はＲＡＭで、ＣＰＵ７０２の主メモ
リ、ワークエリア等として機能する。７０６はキーボー
ドコントローラ（ＫＢＣ）で、キーボード（ＫＢ）７１
０や不図示のポインティングデバイス等からの指示入力
を制御する。７０７はＣＲＴコントローラ（ＣＲＴＣ）
で、ＣＲＴディスプレイ（ＣＲＴ）７１１の表示を制御
する。７０８はディスクコントローラ（ＤＫＣ）で、ブ
ートプログラム、種々のアプリケーション、編集ファイ
ル、ユーザファイルそしてネットワーク管理プログラム
等を記憶するハードディスク（ＨＤ）７１２およびフロ
ッピーディスクコントローラ（ＦＤ）７１３とのアクセ
スを制御する。７０９はネットワークインタフェースカ
ード（ＮＩＣ）で、ＬＡＮ７００を介して、エージェン
トあるいはネットワーク機器と双方向にデータをやりと
りする。

【００５１】次に、本発明のネットワーク管理ソフトウ
エアの構成について説明する。

【００５２】本発明のネットワーク管理装置は、図７に
示したような従来のネットワーク管理装置を実現可能な
ＰＣと同様の構成のＰＣ上に実現される。ハードディス
ク（ＨＤ）７１２には、後述のすべての説明で動作主体
となる本願に係るネットワーク管理ソフトウエアのプロ
グラムが格納される。後述のすべての説明において、特
に断りのない限り、実行の主体はハード上はＣＰＵ７０
２である。

【００５３】一方、ソフトウエア上の制御の主体は、ハ
ードディスク（ＨＤ）７１２に格納されたネットワーク
管理ソフトウエアである。本実施例においては、ＯＳは
例えば、ウィンドウズ９５（マイクロソフト社製）を想
定しているが、これに限るものではない。

【００５４】なお本願に係るネットワーク管理プログラ
ムは、フロッピーディスクやＣＤ−ＲＯＭなどの記憶媒
体に格納された形で供給されても良く、その場合には図
７に示すフロッピーディスクコントローラ（ＦＤ）７１
３または不図示のＣＤ−ＲＯＭドライブなどによって記
憶媒体からプログラムが読み取られ、ハードディスク
（ＨＤ）７１２にインストールされる。

【００５５】図８は、本発明に係るネットワーク管理ソ
フトウエアのモジュール構成の一例を示すモジュール図
である。

【００５６】本発明に係るネットワーク管理ソフトウエ
アは、図７におけるハードディスク７１２に格納されて
おり、ＣＰＵ７０２によって実行される。その際、ＣＰ
Ｕ７０２はワークエリアとしてＲＡＭ７０４を使用す
る。

【００５７】図８において、８０１はデバイスリストモ
ジュールと呼ばれ、ネットワークに接続されたデバイス
を一覧にして表示するモジュールである。８０２は全体
制御モジュールと呼ばれ、デバイスリストからの指示を
もとに、他のモジュールを統括するモジュールである。
８０３はコンフィグレータと呼ばれ、エージェントのネ
ットワーク設定に関する特別な処理を行うモジュールで
ある。８０４は、探索モジュールと呼ばれ、ネットワー
クに接続されているデバイスを探索するモジュールであ
る。探索モジュール８０４によって探索されたデバイス
が、デバイスリスト８０１によって一覧表示される。８
０５は、プリントジョブの状況をNetWare API８１６を
用いてネットワークサーバから取得するNetWareジョブ
モジュールである。（なお、NetWare APIについては、
例えばＮｏｖｅｌｌ社から発行されている"NetWare Pro
grammer's Guide for C"等を参照のこと。この書籍はノ
ベル株式会社から購入可能である。）８０６および８０
７はデバイスの種別に応じてそれぞれのより詳細な情報
を表示するデバイス詳細ウィンドウを表示するためのＵ
Ｉモジュールであり、詳細情報を表示する対象機種毎に
ＵＩモジュールが存在する。８０８および８０９は制御
モジュールと呼ばれ、詳細情報を取得する対象機種に特
有の制御を受け持つモジュールである。ＵＩモジュール
と同様に、制御モジュールも詳細情報を表示する対象機
種毎に存在する。制御Ａモジュール８０８および制御Ｂ
モジュール８０９は、ＭＩＢハンドリングモジュール８
１０を用いて管理対象デバイスからＭＩＢデータを取得
し、必要に応じてデータの変換を行い、各々対応するＵ
ＩＡモジュール８０６またはＵＩＢモジュール８０７に
データを渡す。

【００５８】ＭＩＢハンドリングモジュール８１０は、
全体制御モジュール８０２、制御Ａモジュール、制御Ｂ
モジュールからの要求に応じてＳＮＭＰメッセージを生
成するために必要な情報（コミュニティ名、オブジェク
ト識別子など）をＳＮＭＰプロトコルモジュール８１１
に通知する。

【００５９】８１１はＳＮＭＰプロトコルモジュールと
呼ばれ、ＳＮＭＰパケットの送信と受信を行う。

【００６０】８１２は共通トランスポートモジュールと
呼ばれ、ＳＮＭＰデータを運搬するための下位プロトコ
ルの差を吸収するモジュールである。実際には、動作時
にユーザが選択したプロトコルによって、ＩＰＸハンド
ラ８１３かＵＤＰハンドラ８１４のいずれかがデータを
転送する役割を担う。なお、ＵＤＰハンドラは、実装と
してWinSock８１７を用いている。（WinSockについて
は、例えばWindows Socket APIvl.1の仕様書を参照のこ
と。このドキュメントは、複数箇所から入手可能である
が、例えばマイクロソフト社製のコンパイラであるVisu
al C++に同梱されている。）コンフィグレータ８０３が
用いる現在のプロトコル８１５というのは、動作時にユ
ーザが選択しているＩＰＸプロトコルかＵＤＰプロトコ
ルのいずれかのことを示す。

【００６１】図１は、本発明によるネットワーク管理ソ
フトウエアが１つのＳＮＭＰメッセージ(GetRequest)に
よってエージェントに対し複数のオブジェクトの設定値
の取得を要求した場合のフローチャートである。

【００６２】同図において、ステップＳ１０１ではユー
ザがＰＣ７０１でキーボード（ＫＢ）７１０、もしく
は、マウス等を使用してハードディスク（ＨＤ）７１２
に記憶された本発明によるネットワーク管理ソフトウエ
アを起動し、管理対象のネットワークデバイスに関する
情報を取得するよう操作する、この操作によりデバイス
リストモジュール８０１、ＵＩＡモジュール８０６、Ｕ
ＩＢモジュール８０７のいずれかのモジュールからＳＮ
ＭＰメッセージの送信要求が発生し、それに応じて全体
制御モジュール８０２、制御Ａモジュール８０８、制御
Ｂモジュール８０９のいずれかの制御モジュールからＭ
ＩＢハンドリングモジュール８１０のＡＰＩがコールさ
れる。

【００６３】ステップＳ１０２では、ステップＳ１０１
においてコールされたＭＩＢハンドリングモジュール８
１０のＡＰＩから要求されたＳＮＭＰメッセージの種別
を解析する。このステップＳ１０２において、要求され
たＳＮＭＰメッセージの種別がGetRequestパケットであ
る場合には、ステップＳ１０３に移行し、それ以外の場
合は、ステップＳ１０８に移行する。

【００６４】ステップＳ１０３では、ステップＳ１０２
においてコールされたＭＩＢハンドリングモジュール８
１０のＡＰＩのパラメータより、GetRequestにより情報
の取得を要求されたオブジェクトの数を解析し、単一の
オブジェクトに関する要求である場合には、ステップＳ
１０８に移行し、複数のオブジェクトへの要求である場
合には、ステップＳ１０４に移行する。

【００６５】ステップＳ１０４では、ステップＳ１０３
で解析した要求されたGetRequestに含まれるオブジェク
トの数が複数であった場合、ＭＩＢハンドリングモジュ
ール８１０が内部に持つデータベースから情報の取得を
要求された複数のオブジェクトのデータタイプを解析
し、最大データサイズとともにＳＮＭＰモジュールに通
知する。なお、ＲＦＣ１１５５では、ＭＩＢオブジェク
トのデータタイプとして定義可能な型を次のように定義
している。

【００６６】 INTEGER 整数（ＳＮＭＰでは通常３２ビット） OCTET STRING 可変長バイト列 NULL 空 OBJECT IDENTIFIER オブジェクト識別子 SEQUENCE/SEQUENCE OF 構造体のように、いく
つかのデータタイプを組み合わせたもの NetworkAddress/IpAddress ネットワーク層のアド
レス（現在はＩＰのみ） Counter ０〜２23−１の間の整
数で、増加のみ可能 Gauge ０〜２23−１の間の整
数で、増減が可能 TimeTIcks ０〜２23−１の間の整
数で、ある時点からの経過時間を１／１００秒で表す (10)Opaque 任意のデータタイプの
バイト列（ＳＮＭＰでは使われていない） 本発明によるネットワーク管理ソフトウエアでは、これ
らのデータタイプのうち、データサイズの最大値を特定
できないものに関しては、十分に大きなデフォルトサイ
ズを割り当てるものとする。

【００６７】ステップＳ１０５では、ステップＳ１０４
からＭＩＢハンドリングモジュール８１０から通知され
たデータタイプ、および、最大データサイズをもとに、
エージェントによって送出されるGetResponseパケット
の最大データサイズを算出し、ステップＳ１０６に移行
する。

【００６８】ステップＳ１０６では、ステップＳ１０５
でＳＮＭＰモジュール８１１において算出したGetReque
stパケットの最大サイズが４８４オクテットであるかど
うかの判断がおこなわれ、４８４オクテットを超える場
合にはステップＳ１０７に移行し、それ以外の場合はス
テップＳ１０８に移行する。

【００６９】ステップＳ１０７では、ステップＳ１０６
において予測されるGetResponseパケットの最大サイズ
が４８４オクテットを超える場合、ステップ１０１にお
いて送信の要求がおこなわれたGetRequestパケットのva
rlable-bindings２０９に含まれる複数のオブジェクト
から予測したGetRequestパケットの最大データレングス
が４８４オクテット以下になるようパケットを分割し、
ステップＳ１０８に移行する。

【００７０】ステップＳ１０８では、ステップＳ１０７
におてい分割され、適当なオブジェクトを含むGetReque
stパケットの送信をＳＮＭＰプロトコルモジュール８１
１に対して要求する。これを受けてＳＮＭＰプロトコル
モジュール８１１では、要求に応じたＳＮＭＰメッセー
ジを生成し、共通トランスポートモジュール８１２に通
知する。共通トランスポートモジュール８１２では、動
作時にユーザが選択したプロトコルによって、ＩＰＸハ
ンドラ８１３かＵＤＰハンドラ８１４のいずれかにデー
タを転送する。以上の様な動作の後、ＳＮＭＰメッセー
ジがネットワークインタフェースカード（ＮＩＣ）７０
９を経由してＬＡＮ７００送出される。

【００７１】以上説明したように、ステップＳ１０１に
おいて発生したＳＮＭＰメッセージをステップＳ１０２
で解析し、GetRequestに関する要求であった場合には、
ステップＳ１０３において複数のオブジェクトに対する
GetRequestであるかどうかの判断がなされ、複数のオブ
ジェクトに対する要求である場合には、ステップＳ１０
４で各オブジェクトのデータタイプを解析し、ステップ
Ｓ１０５において、エージェントで生成されるGetRespo
nseパケットの最大パケットサイズを予測し、最大パケ
ットサイズが４８４オクテットを超える場合には、ステ
ップＳ１０７において送信パケットを分割し、ステップ
Ｓ１０８においてパケットを送信することにより、GetR
equestパケット送信時にエージェントにおけるGetRespo
nseでのエラー(tooBig)の発生を完全に防止することが
できる。

【００７２】また、上記で説明した本発明に係るネット
ワーク管理ソフトウエアは、外部からインストールされ
るプログラムによって、ネットワーク管理ソフトウエア
が稼動可能なＰＣの構成を示すブロック図である図７に
おけるＰＣ７０１によって遂行されても良い。その場
合、そのプログラムはＣＤ−ＲＯＭやフラッシュメモリ
やフロッピーディスクなどの記憶媒体により、あるいは
電子メールやパソコン通信などのネットワークを介し
て、外部の記憶媒体からプログラムを含む情報群をＰＣ
７０１上にロードすることにより、ＰＣ７０１に供給さ
れる場合でも本発明は適用されるものである。

【００７３】図３は、記憶媒体の一例であるＣＤ−ＲＯ
Ｍのメモリマップを示す図である。３０３はディレクト
リ情報を記憶してある領域で、以降のインストールプロ
グラムを記憶してある領域３０２およびネットワーク管
理ソフトウエアを記憶してある領域３０１の位置を示し
ている。３０２は、インストールプログラムを記憶して
ある領域である。３０１は、ネットワーク管理ソフトウ
エアを記憶してある領域である。本発明のネットワーク
管理ソフトウエアがＰＣ７０１にインストールされる際
には、まずインストールプログラムを記憶してある領域
３０２に記憶されているインストールプログラムがシス
テムにロードされ、ＣＰＵ７０２によって実行される。
次に、ＣＰＵ７０２によって実行されるインストールプ
ログラムが、ネットワーク管理ソフトウエアを記憶して
ある領域３０１からネットワーク管理ソフトウエアを読
み出して、ハードディスク７１２に格納する。

【００７４】なお、本発明は、複数の機器（例えばホス
トコンピュータ、インタフェース機器、リーダなど）か
ら構成されるシステムあるいは統合装置に適用しても、
ひとつの機器からなる装置に適用してもよい。

【００７５】また、前述した実施形態の機能を実現する
ソフトウエアのプログラムコードを記録した記憶媒体
を、システムあるいは装置に供給し、そのシステムある
いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記
憶媒体に格納されたプログラムコードを読み出し実行す
ることによっても、本発明の目的が達成されることは言
うまでもない。

【００７６】この場合、記憶媒体から読み出されたプロ
グラムコード自体が本発明の新規な機能を実現すること
になり、そのプログラムコードを記憶した記憶媒体は本
発明を構成することになる。

【００７７】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピーディスク、ハードディ
スク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ，Ｃ
Ｄ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ
などを用いることができる。

【００７８】また、コンピュータが読み出したプログラ
ムコードを実行することによって、前述した実施形態の
機能が実現される他、そのプログラムコードの指示に基
づき、コンピュータ上で稼動しているＯＳなどが実際の
処理の一部または全部を行い、その処理によっても前述
した実施形態の機能が実現され得る。

【００７９】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張ボー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書き込まれた後、そのプログラムコードの指
示に基づき、その機能拡張ボードや機能拡張ユニットに
備わるＣＰＵなどが実際の処理の一部または全部を行
い、その処理によっても前述した実施形態の機能が実現
され得る。

【００８０】なお、本発明は、前述した実施形態の機能
を実現するソフトウエアのプログラムコードを記録した
記憶媒体から、そのプログラムをパソコン通信など通信
ラインを介して要求者にそのプログラムを配信する場合
にも適用できることは言うまでもない。

【００８１】

【発明の効果】以上説明したように、本発明によれば、
データ要求されたデバイスで発生するエラーの発生を防
ぎ、ネットワーク管理ソフトウエアのデータの取得効率
を飛躍的に向上させることが可能となる。

【図面の簡単な説明】

【図１】本発明によるネットワーク管理ソフトウエアが
１つのＳＮＭＰメッセージにより複数のオブジェクトに
対するデータの取得及び設定を要求した場合のフローチ
ャートである。

【図２】ＳＮＭＰメッセージのＰＤＵデータフォーマッ
ト（Trap-PDU以外）である。

【図３】記憶媒体の一例であるＣＤ−ＲＯＭのメモリマ
ップを示す図である。

【図４】マネージャが１つのＳＮＭＰメッセージによっ
て複数のオブジェクトに対するデータの設定を要求した
場合のシーケンス図である。

【図５】マネージャが１つのＳＮＭＰメッセージによっ
て複数のオブジェクトに対するデータの設定を要求した
場合のシーケンス図（エージェントが一部のオブジェク
トへの情報の設定を受け付けない場合）である。

【図６】ＭＩＢの構造を示す概念図である。

【図７】本発明によるネットワーク管理ソフトウエアが
稼動可能なＰＣの構成を示すブロック図である。

【図８】本発明よるネットワーク管理ソフトウエアのモ
ジュール構成図である。

【図９】ネットワークボード（ＮＥＢ）を開放型アーキ
テクチャを持つプリンタへつなげた図である。

【図１０】ＮＥＢをプリンタにインストールした状態を
示す一部破断図である。

【図１１】ＮＥＢとプリンタとＬＡＮとの電気的接続を
示すブロック図である。

【符号の説明】

２０１ ＳＮＭＰメッセージ（Ｔｒａｐ以外） ２０２ バージョン情報 ２０３ コミュニティ名 ７０４ データ ７０５ ＰＤＵ ７０６ リクエストＩＤ ７０７ エラーステータス ７０８ エラーインデックス ７０９ Vriable-bindings ７１０ オブジェクト名 ７１１ オブジェクト名７１０によって示されるオブジ
ェクトへの設定値 ７１２ オブジェクト名 ７１３ オブジェクト名７１２によって示されるオブジ
ェクトヘの設定値 ６０１ ＭＩＢのノードｉｓｏ（１） ６０２ ＭＩＢのノードｏｒｇ（３） ６０３ ＭＩＢのノードｍｇｍｔ（２） ６０４ ＭＩＢのノードｍｉｂ−２（１） ６０５ ＭＩＢのノードｐｒｉｎｔｍｉｂ（４３） ６０６ ＭＩＢのノードｐｒｉｖａｔｅ（４） ６０７ ＭＩＢのノードｅｎｔｅｒｐｒｉｓｅｓ（１） ６０８ ＭＩＢのノードｃａｎｏｎ（１６０２） ７００ ローカルエリアネットワーク（ＬＡＮ） ７０１ ネットワーク管理ソフトウエアが稼動するＰＣ ７０２ ＦＤ７１３より供給されるネットワーク管理プ
ログラムを実行するＣＰＵ ７０３ ＰＣ７０１のＲＯＭ ７０４ ＰＣ７０１のＲＡＭ ７０５ ＰＣ７０１のシステムバス ７０６ ＰＣ７０１のキーボードコントローラ（ＫＢ
Ｃ） ７０７ ＰＣ７０１のＣＲＴコントローラ（ＣＲＴＣ） ７０８ ＰＣ７０１のディスクコントローラ（ＤＫＣ） ７０９ ＰＣ７０１のネットワークインタフェースカー
ド（ＮＩＣ） ７１０ ＰＣ７０１のキーボード（ＫＢ） ７１１ ＰＣ７０１のＣＲＴディスプレイ（ＣＲＴ） ７１２ ＰＣ７０１のハードディスク（ＨＤ） ７１３ フロッピーディスクドライブ（ＦＤ） ８０１ デバイスリストモジュール ８０２ 全体制御モジュール ８０３ コンフィグレータ ８０４ 探索モジュール ８０５ NetWareジョブモジュール ８０６ ＵＩモジュールＡ ８０７ ＵＩモジュールＢ ８０８ 制御モジュールＡ ８０９ 制御モジュールＢ ８１０ ＭＩＢハンドリングモジュール ８１１ ＳＮＭＰプロトコルモジュール ８１２ 共通トランスポートモジュール ８１３ ＩＰＸハンドラ ８１４ ＵＤＰハンドラ ８１５ コンフィグレータ６０３が用いる現在のプロト
コル ８１６ NetWare API ８１７ WinSock

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ネットワークで接続されたデバイスから
   データを読み出すためのネットワーク管理方法であっ
   て、 前記デバイスに含まれる複数のオブジェクトに対して、
   データの要求が生じたか判定する第１の判定工程と、 要求が生じたと判定された場合、該デバイスからの応答
   データ長が、前記デバイスの扱えるデータ長の上限を越
   えるか予測する第２の判定工程と、 応答データ長が上限を越えると予測される場合には、前
   記データの要求を、オブジェクト単位で分割し、それぞ
   れの要求を前記デバイスに送信する工程とを備えること
   を特徴とするネットワーク管理方法。
2. 【請求項２】 前記デバイスはプリンタ装置であること
   を特徴とする請求項１に記載のネットワーク管理方法。
3. 【請求項３】 ネットワークで接続されたデバイスから
   データを読み出すためのネットワーク管理装置であっ
   て、 前記デバイスに含まれる複数のオブジェクトに対して、
   データの要求が生じたか判定する第１の判定手段と、 要求が生じたと判定された場合、該デバイスからの応答
   データ長が、前記デバイスの扱えるデータ長の上限を越
   えるか予測する第２の判定手段と、 応答データ長が上限を越えると予測される場合には、前
   記データの要求を、オブジェクト単位で分割し、それぞ
   れの要求を前記デバイスに送信する手段とを備えること
   を特徴とするネットワーク管理装置。
4. 【請求項４】 前記デバイスはプリンタ装置であること
   を特徴とする請求項３に記載のネットワーク管理装置。
5. 【請求項５】 ネットワークで接続されたデバイスから
   データを読み出すためのコンピュータプログラムを格納
   するコンピュータ可読の記憶媒体であって、前記プログ
   ラムによりコンピュータは、 前記デバイスに含まれる複数のオブジェクトに対して、
   データの要求が生じたか判定する第１の判定手段と、 要求が生じたと判定された場合、該デバイスからの応答
   データ長が、前記デバイスの扱えるデータ長の上限を越
   えるか予測する第２の判定手段と、 応答データ長が上限を越えると予測される場合には、前
   記データの要求を、オブジェクト単位で分割し、それぞ
   れの要求を前記デバイスに送信する手段として機能する
   ことを特徴とする記憶媒体。