JPH08328983A - Network managing information retrieving system - Google Patents
Network managing information retrieving systemInfo
- Publication number
- JPH08328983A JPH08328983A JP7131719A JP13171995A JPH08328983A JP H08328983 A JPH08328983 A JP H08328983A JP 7131719 A JP7131719 A JP 7131719A JP 13171995 A JP13171995 A JP 13171995A JP H08328983 A JPH08328983 A JP H08328983A
- Authority
- JP
- Japan
- Prior art keywords
- index
- entry
- management information
- request
- message processing
- 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.)
- Pending
Links
Landscapes
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
【0001】[0001]
【産業上の利用分野】本発明はネットワーク管理情報検
索方式に関し、特にネットワーク管理プロトコルSNM
P(Simple Network Management Protocol)を用いて管
理情報ベース(MIB:Management Information Base
)テーブルの検索処理を行うネットワーク管理情報検
索方式に関する。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network management information retrieval system, and more particularly to a network management protocol SNM.
Management Information Base (MIB) using P (Simple Network Management Protocol)
) It relates to a network management information search method for performing table search processing.
【0002】[0002]
【従来の技術】ネットワーク管理のための仮想的な管理
情報であるMIBは、被管理オブジェクトのツリー状の
集合体である。これらのオブジェクトは、それ自体は単
なる属性(“形”,template)の規定のみであり、実際
にネットワーク管理プロトコルによって操作される実体
は、オブジェクトの持つそれぞれのインスタンスであ
る。2. Description of the Related Art MIB, which is virtual management information for network management, is a tree-shaped collection of managed objects. These objects are merely definitions of attributes (“shapes”, templates) themselves, and the entities actually operated by the network management protocol are the respective instances of the objects.
【0003】テーブル中のオブジェクトは、1つのオブ
ジェクトがそのテーブルのエントリ数と同じ数の複数の
インスタンスを持つ。例として、文献「K. McCloghrie,
M.Rose, Management Information Base for Network M
anagement of TCP/IP-basedinternets: MIB-II, Networ
k Working Group Request for Comments: 1213, March
1991」において、インターネット標準MIBであるMI
B−IIにおいて定義されているテーブルの内、「ip
RoutingTable」を考える。Objects in a table have a plurality of instances, each object having the same number as the number of entries in the table. As an example, the document “K. McCloghrie,
M.Rose, Management Information Base for Network M
anagement of TCP / IP-based internets: MIB-II, Networ
k Working Group Request for Comments: 1213, March
1991 ”, MI, which is an Internet standard MIB
Of the tables defined in B-II, "ip
"RoutingTable".
【0004】図16はMIB−IIに定義されているテ
ーブルの一例を示す図である。テーブル「ipRout
ingTable」は図示のような内容を有していると
する。なお、「ipRouteDest」、「ipRo
uteIfIndex」および「ipRouteNex
tHop」以外のオブジェクトは省略してある。このと
き、たとえばオブジェクト「ipRouteDest」
は、インスタンスとして各エントリに「192.33.
4.0」、「0.0.0.0」および「192.33.
5.0」の3つの値を持っている。同様に、オブジェク
ト「ipRouteIfIndex」は、インスタンス
として「1」、「1」、「2」の値を持っている。FIG. 16 is a diagram showing an example of a table defined in MIB-II. Table "ipRout
The “ingTable” has the contents shown in the figure. In addition, "ipRouteDest", "ipRo
uteIfIndex ”and“ ipRouteNex
Objects other than "tHop" are omitted. At this time, for example, the object "ipRouteDest"
For each entry as an instance of "192.33.
4.0 "," 0.0.0.0 "and" 192.33.
It has three values of "5.0". Similarly, the object “ipRouteIfIndex” has values of “1”, “1”, and “2” as instances.
【0005】また、テーブルでは、そのテーブルの中で
インデックスとなるオブジェクトが必ず規定され、テー
ブル内を検索するときのエントリの順番は、そのテーブ
ルの中でインデックスとなるオブジェクトの辞書的順番
の大小により決定される。図示のテーブル「ipRou
tingTable」では、「ipRouteDes
t」がインデックスとなるオブジェクトである。したが
って、このテーブルの検索の順番は「ipRouteD
est」のインスタンスの辞書的順番の大小により決定
される。In addition, in a table, an object that serves as an index in the table is always defined, and the order of entries when searching the table depends on the size of the dictionary order of the objects that serve as the index in the table. It is determined. The illustrated table "ipRou
In "tingTable", "ipRouteDes"
"t" is an object that serves as an index. Therefore, the search order for this table is "ipRouteD
It is determined by the size of the lexical order of the instance of "est".
【0006】ネットワーク管理プロトコルSNMPにお
いては、すべての管理操作はオブジェクトの個々のイン
スタンスに対してしか行うことができない。すなわち、
テーブル全体やテーブルの中のあるエントリといった単
位での管理操作は行うことができない。したがって、テ
ーブルを検索する際には、テーブル中のすべてのインス
タンスを指定して値を取得する必要がある。In the network management protocol SNMP, all management operations can only be performed on individual instances of an object. That is,
Management operations cannot be performed in units of the entire table or certain entries in the table. Therefore, when searching the table, it is necessary to specify all the instances in the table to obtain the values.
【0007】SNMPによるテーブル検索として一般的
に行われている方法は、「GetNext−Reque
st」中において1エントリ中のオブジェクトインスタ
ンスをすべて指定して、指定したエントリの次のエント
リ中にあるオブジェクトインスタンスを取得し、これを
テーブル中の全エントリに対して検索が終了するまで繰
り返す、というものである。The method generally used as the table search by SNMP is "GetNext-Request".
In "st", all the object instances in one entry are specified, the object instance in the entry next to the specified entry is acquired, and this is repeated until the search is completed for all the entries in the table. It is a thing.
【0008】テーブル検索の具体例として、「ipRo
utingTable」の検索例が文献「THE SIMPLE B
OOK, An Introduction to Management of TCP/IP-based
Internets, Marshall T. Rose, Prentice-Hall Intern
ational Editions」の5.3.1節“The Powe
rful Get−Next Operator”に挙
げられている。As a concrete example of the table search, "ipRo
"The SIMPLE B"
OOK, An Introduction to Management of TCP / IP-based
Internets, Marshall T. Rose, Prentice-Hall Intern
Section 5.3.1 of "ational editions""The Powe
rful Get-Next Operator ”.
【0009】この例によれば、「GetNext−Re
quest」によりテーブル全体のオブジェクトインス
タンスを取得する際には、リクエスト中に指定されたイ
ンスタンスの次に辞書的順番の大きいインスタンスをイ
ンデックスとして持つエントリの検索を、テーブルに含
まれているインスタンスの数と同じ回数だけ行ってい
る。According to this example, "GetNext-Re
When acquiring the object instance of the entire table by "quest", the search for the entry having the instance with the next largest lexicographical order as the index of the instance specified in the request is performed as the number of instances included in the table. Do the same number of times.
【0010】また、被管理機器の管理情報を高速に読み
書きすることを目的とした従来技術として、特開平6−
97934号公報がある。この公報によれば、目的とす
るオブジェクトを検索する処理を高速化するため、目的
とするオブジェクトをMIBツリーのルートから順次た
どっていくのではなく、連想記憶装置を用いて一気に探
し出すことにより、検索に要する時間を短縮するもので
ある。Further, as a conventional technique for reading and writing management information of a managed device at high speed, Japanese Patent Laid-Open No. 6-
There is a 97934 publication. According to this publication, in order to speed up the process of searching for an object of interest, the object of interest is searched for all at once by using an associative storage device, instead of sequentially following the root of the MIB tree. It shortens the time required for.
【0011】[0011]
【発明が解決しようとする課題】上述のように、「Ge
tNext−Request」によりテーブル全体のオ
ブジェクトインスタンスを取得する際には、リクエスト
中に指定されたインスタンスの次に辞書的順番の大きい
インスタンスをインデックスとして持つエントリの検索
が、テーブルに含まれているインスタンスの数と同じ回
数だけ行わなければならない。このため、「GetNe
xt−Request」中に複数のインスタンスが指定
され、それらが同一のインデックスを持つような場合に
も、その同じエントリを探すためのサーチ処理を何度も
繰り返す必要がある。また、このようなエントリ検索の
ためには、テーブルのすべてのエントリを参照しなけれ
ばならない可能性があるため、複数オブジェクトに対し
ては、同じテーブル全体を何度も検索することになる。SUMMARY OF THE INVENTION As described above, the "Ge
When acquiring the object instance of the entire table by “tNext-Request”, the search for the entry having the instance with the next largest lexicographic order as the index of the instance specified in the request is performed for the instances included in the table. Must be done as many times as there are numbers. Therefore, "GetNe
Even when a plurality of instances are specified in “xt-Request” and they have the same index, it is necessary to repeat the search process for searching the same entry many times. Further, in order to search for such an entry, it may be necessary to refer to all the entries in the table, so that the same entire table is searched many times for a plurality of objects.
【0012】また、上記公報に記載の技術では、高速化
の工夫が及ぶ範囲はテーブルに含まれるオブジェクトの
検索までであり、オブジェクトが持つインデックスの検
索を高速化する手段は含まれていない。したがって、テ
ーブル検索を行う場合に、エントリの検索に要する時間
は短縮されない、という問題点があった。Further, in the technique described in the above publication, the device for speeding up is limited to the search of the object contained in the table, and the means for speeding up the search of the index of the object is not included. Therefore, there is a problem that the time required to search the entry is not shortened when the table is searched.
【0013】本発明はこのような点に鑑みてなされたも
のであり、テーブルオブジェクトに対する「GetNe
xt−Request」の処理を高速化し、ひいてはテ
ーブル全体の検索処理を高速化するネットワーク管理情
報検索方式を提供することを目的とする。The present invention has been made in view of such a point, and "GetNe" for a table object is performed.
It is an object of the present invention to provide a network management information search method that speeds up the process of “xt-Request”, and thus speeds up the process of searching the entire table.
【0014】[0014]
【課題を解決するための手段】本発明では上記課題を解
決するために、被管理機器毎に管理情報ベーステーブル
に登録されているネットワーク管理情報を検索するネッ
トワーク管理情報検索方式において、マネージャとの通
信時にネットワーク管理プロトコルのプロトコル処理を
行うメッセージ処理手段(10)と、被管理オブジェク
トのインスタンスが登録され、インデックスとなるオブ
ジェクトのインスタンスをキーとしてエントリが辞書的
順番にソートされている管理情報ベーステーブル記憶部
(21)、および前記メッセージ処理手段から通知され
たリクエスト中に指定されているインデックスと前記メ
ッセージ処理手段への応答に用いたエントリの順番と前
記メッセージ処理手段への応答に用いたエントリのイン
デックスとを検索毎に保持しておくインデックス・エン
トリ対応関係保持部(22)を有する管理情報ベーステ
ーブル処理手段(20)と、を備えていることを特徴と
するネットワーク管理情報検索方式が提供される。According to the present invention, in order to solve the above problems, in a network management information search method for searching network management information registered in a management information base table for each managed device, A message processing means (10) for performing protocol processing of a network management protocol at the time of communication and an instance of a managed object are registered, and a management information base table in which entries are sorted in a lexicographical order using the instance of the object serving as an index as a key The storage unit (21), the index specified in the request notified from the message processing unit, the order of the entries used for the response to the message processing unit, and the entry used for the response to the message processing unit. Search with index A management information base table processing means having a index entry correspondence holding unit to hold (22) (20), the network management information retrieval system, characterized in that it comprises a are provided.
【0015】[0015]
【作用】上述の手段によれば、管理情報ベーステーブル
記憶部(21)のテーブルオブジェクトに対する最初の
リクエストの処理の際に、管理情報ベーステーブル全体
をインデックスでソートして作成し、記憶しておく。そ
の上で、作成した管理情報ベーステーブルに対してエン
トリをサーチ後、管理情報ベーステーブル処理手段(2
0)のインデックス・エントリ対応関係保持部(22)
に、リクエスト中のインデックスとリクエストに対する
応答に用いたエントリの順番とリクエストに対する応答
に用いたエントリのインデックスとを記憶しておく。According to the above means, when the first request for the table object in the management information base table storage unit (21) is processed, the entire management information base table is created by sorting by index and stored. . Then, after searching the created management information base table for an entry, the management information base table processing means (2
0) Index / entry correspondence holding unit (22)
The index in the request, the order of the entries used for the response to the request, and the index of the entry used for the response to the request are stored.
【0016】次のリクエストの処理のときには、メッセ
ージ処理手段(10)から渡されたインデックスとイン
デックス・エントリ対応関係保持部(22)にあるリク
エスト中のインデックスとを比較し、一致した場合に
は、インデックス・エントリ対応関係保持部(22)に
あるリクエストに対する応答に用いたエントリの順番と
リクエストに対する応答に用いたエントリのインデック
スとを使用して、その順番のエントリのオブジェクトイ
ンスタンスを取得し、再び、インデックス・エントリ対
応関係保持部(22)を更新して応答に用いるオブジェ
クトインスタンスとその値とをメッセージ処理手段(1
0)へ通知する。At the time of processing the next request, the index passed from the message processing means (10) is compared with the index in the request stored in the index / entry correspondence holding unit (22). Using the order of the entries used for the response to the request and the index of the entry used for the response to the request in the index / entry correspondence holding unit (22), the object instance of the entry of the order is acquired, and again, The message processing means (1) updates the index / entry correspondence holding unit (22) to obtain the object instance used for the response and its value.
Notify 0).
【0017】メッセージ処理手段(10)から渡された
インデックスとインデックス・エントリ対応関係保持部
(22)にあるリクエスト中のインデックスとが一致し
ない場合には、メッセージ処理手段(10)から渡され
たインデックスとインデックス・エントリ対応関係保持
部(22)にあるリクエストに対する応答に用いたエン
トリのインデックスとを比較し、一致した場合には、リ
クエストに対する応答に用いたエントリの順番の次のエ
ントリをサーチする。If the index passed from the message processing means (10) and the index in the request stored in the index / entry correspondence holding unit (22) do not match, the index passed from the message processing means (10). And the index of the entry used in the response to the request in the index / entry correspondence holding unit (22) are compared, and if they match, the next entry in the order of the entries used in the response to the request is searched.
【0018】メッセージ処理手段(10)から渡された
インデックスとインデックス・エントリ対応関係保持部
(22)にあるリクエストに対する応答に用いたエント
リのインデックスとが一致しない場合には、これらのイ
ンデックスの辞書的順番を比較し、その大小に応じて、
インデックス・エントリ対応関係保持部(22)にある
リクエストに対する応答に用いたエントリを、サーチ範
囲の上限または下限エントリとする。When the indexes passed from the message processing means (10) and the indexes of the entries used in the response to the request in the index / entry correspondence holding unit (22) do not match, these indexes are dictionary-like. Compare the order, and according to the size,
The entry used in the response to the request in the index / entry correspondence holding unit (22) is the upper or lower limit entry of the search range.
【0019】これにより、同一のインデックスを持つ複
数のオブジェクトインスタンスへのリクエスト処理で
は、エントリをサーチするのは最初だけであるので、同
一エントリ中のオブジェクトの個数が多いほど、エント
リ全体のオブジェクトインスタンスを取得するのに要す
る時間を短縮することができる。As a result, in the request processing for a plurality of object instances having the same index, the entry is searched only at the beginning, so that the larger the number of objects in the same entry, the more the object instances of the entire entry are searched. The time required to acquire can be shortened.
【0020】また、管理情報ベーステーブル記憶部(2
1)の管理情報ベーステーブルはインデックスとなるオ
ブジェクトのインスタンスをキーとしてエントリがソー
トされて記憶されているので、リクエスト中で指定され
たインデックスがインデックス・エントリ対応関係保持
部(22)に記憶されているエントリのインデックスと
同じである場合には、目的のエントリは記憶されている
エントリの次のエントリであることをサーチすることな
く判断することができる。The management information base table storage unit (2
In the management information base table of 1), the entries are sorted and stored using the instance of the object to be the index as a key, so the index specified in the request is stored in the index / entry correspondence holding unit (22). If it is the same as the index of the existing entry, it can be determined without searching that the target entry is the next entry of the stored entry.
【0021】さらに、管理情報ベーステーブルはソート
して記憶されているので、リクエスト中で指定されたイ
ンデックスがインデックス・エントリ対応関係保持部
(22)に記憶されているリクエスト中のインデックス
や記憶されているエントリのインデックスのいずれにも
一致しない場合には、エントリを決めるためのサーチ範
囲をテーブル全体の内、リクエスト中で指定されたイン
デックスまたは記憶されているエントリのインデックス
より辞書的順番が大きいまたは小さい方向のみとするこ
とができ、サーチ効率を上げることができる。Further, since the management information base table is sorted and stored, the index specified in the request is stored in the index / entry correspondence holding unit (22) or stored in the request. If it does not match any of the index of the existing entry, the search range for determining the entry is in a dictionary order higher or lower than the index specified in the request or the index of the stored entry in the entire table. Only the direction can be used, and the search efficiency can be improved.
【0022】[0022]
【実施例】以下、本発明の一実施例を図面に基づいて説
明する。図1は本発明のネットワーク管理情報検索方式
の構成例を示す図である。An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing a configuration example of a network management information search method of the present invention.
【0023】図に例示したネットワーク管理情報検索方
式は、図示しない管理システムのマネージャとの間でS
NMPのプロトコル処理を行うSNMPメッセージ処理
部10と、ネットワーク管理情報を処理するMIBテー
ブル処理部20とから構成され、MIBテーブル処理部
20はMIBテーブル21aを記憶するMIBテーブル
記憶部21と、リクエスト中のインデックスを保持する
領域22a、「Get−Response」に用いたエ
ントリの順番を保持する領域22b、および「Get−
Response」に用いたエントリのインデックスを
保持する領域22cを有するインデックス・エントリ対
応関係保持部22とを備えている。また、MIBテーブ
ル処理部20には、リソース情報記憶部30のリソース
情報を元にオブジェクトインスタンスからなるMIBテ
ーブル21aを作成し、このときエントリをインデック
スによりソートする機能を持ったMIBテーブル作成部
40が接続されている。さらに、MIBテーブル処理部
20には、リソース情報記憶部30のリソース情報に変
化が発生したかどうかを監視して変化が発生した場合に
は、MIBテーブル記憶部21およびインデックス・エ
ントリ対応関係保持部22の内容をクリアするリソース
状態監視部50が接続されている。The network management information retrieval method illustrated in the figure is executed by the S of the management system manager (not shown).
It is composed of an SNMP message processing unit 10 for performing NMP protocol processing and an MIB table processing unit 20 for processing network management information. The MIB table processing unit 20 has a MIB table storage unit 21 for storing an MIB table 21a and a requesting request. Area 22a for holding the index of “Get-Response”, area 22b for holding the order of the entries used for “Get-Response”, and “Get-Response”.
An index / entry correspondence holding unit 22 having an area 22c for holding the index of the entry used for "Response". Further, in the MIB table processing unit 20, a MIB table creating unit 40 having a function of creating an MIB table 21a composed of object instances based on the resource information of the resource information storage unit 30 and sorting the entries by an index at this time is provided. It is connected. Further, the MIB table processing unit 20 monitors whether or not a change has occurred in the resource information of the resource information storage unit 30 and, if a change occurs, the MIB table storage unit 21 and the index / entry correspondence holding unit. A resource status monitoring unit 50 that clears the contents of 22 is connected.
【0024】SNMPメッセージ処理部10は、メッセ
ージの送受信、エンコード/デコード、リクエストメッ
セージの解析、レスポンスメッセージの構築、MIBツ
リー上でのオブジェクトの検索、オブジェクト間の辞書
的順番の大小関係の検索などの処理を行っている。The SNMP message processing unit 10 performs message transmission / reception, encoding / decoding, request message analysis, response message construction, object search on the MIB tree, search of lexicographical order relation between objects, and the like. It is processing.
【0025】リソース情報記憶部30のリソース情報
は、被管理機器が持っている状態や構成といった情報で
ある。MIBは仮想情報であるため、そのインスタンス
の値を決定する際には、必ず被管理機器が持っている情
報との対応を取らなければならない。つまり、リソース
情報は、被管理機器が持っているMIBの元情報のこと
であり、図示のリソーステーブル30aのように、MI
Bテーブル21aの元になるテーブル形式のデータも含
まれる。The resource information in the resource information storage section 30 is information such as the status and configuration of the managed device. Since the MIB is virtual information, when determining the value of the instance, it is necessary to take a correspondence with the information held by the managed device. That is, the resource information is the original information of the MIB held by the managed device, and is the MI as shown in the resource table 30a in the figure.
The data in the table format that is the basis of the B table 21a is also included.
【0026】リソース状態監視部50では、リソース情
報記憶部30のリソース情報の状態変化を監視する方法
として常時監視またはポーリングによる監視の方法があ
る。また、リソース情報記憶部30に状態変化をイベン
トとして通知する機能があれば、そのイベントを用いた
イベントドリブンによる状態変化の監視方法もある。こ
こでは、リソース情報の変化を判断することができれ
ば、いずれの方法でもよい。In the resource status monitoring unit 50, there are a continuous monitoring method or a polling monitoring method as a method for monitoring the status change of the resource information in the resource information storage unit 30. Further, if the resource information storage unit 30 has a function of notifying a state change as an event, there is also an event driven method of monitoring the state change using the event. Here, any method may be used as long as the change in resource information can be determined.
【0027】MIBテーブル処理部20のMIBテーブ
ル記憶部21はMIBテーブル作成部40にて作成され
たMIBテーブル21aを記憶するが、このMIBテー
ブル21aには、最後に処理した「GetNext−R
equest」に対する「Get−Response」
で使用されたオブジェクトインスタンスを含むテーブル
がインデックスによりソートされた形で記憶されてい
る。The MIB table storage unit 21 of the MIB table processing unit 20 stores the MIB table 21a created by the MIB table creating unit 40. This MIB table 21a contains the last processed "GetNext-R".
"Get-Response" for "request"
The table containing the object instances used in is stored sorted by index.
【0028】インデックス・エントリ対応関係保持部2
2は、領域22aに最も新しく処理した「GetNex
t−Request」に指定されていたオブジェクトイ
ンスタンスの中のインデックスの値を、領域22bには
その「GetNext−Request」に対する「G
et−Response」中に用いたテーブルのエント
リの位置を、さらに領域22cにはそのエントリのイン
デックスの値の対応関係をそれぞれ記憶している。した
がって、ここに記憶される対応関係は、MIBテーブル
記憶部21に記憶されているMIBテーブル21aに対
するものとなる。Index / entry correspondence holding unit 2
2 is the latest processed "GetNex" in the area 22a.
The value of the index in the object instance specified in "t-Request" is displayed in the area 22b as "G" for the "GetNext-Request".
The position of the entry of the table used in "et-Response" is stored, and the area 22c stores the correspondence between the index values of the entry. Therefore, the correspondence relationship stored here is for the MIB table 21 a stored in the MIB table storage unit 21.
【0029】次に、上記構成のネットワーク管理情報検
索方式の作用について説明する。図2はMIBテーブル
処理部の処理の流れを示すフローチャート(その1)で
あり、図3はMIBテーブル処理部の処理の流れを示す
フローチャート(その2)であり、図4はMIBテーブ
ル処理部の処理の流れを示すフローチャート(その3)
であり、図5はMIBテーブル処理部の処理の流れを示
すフローチャート(その4)である。Next, the operation of the network management information retrieval system having the above configuration will be described. 2 is a flow chart (No. 1) showing the flow of processing of the MIB table processing unit, FIG. 3 is a flow chart (No. 2) showing the flow of processing of the MIB table processing unit, and FIG. 4 is that of the MIB table processing unit. Flowchart showing the flow of processing (Part 3)
5 is a flowchart (No. 4) showing the flow of processing of the MIB table processing unit.
【0030】まず、SNMPメッセージ処理部10にお
いて、マネージャより受信したSNMPメッセージがテ
ーブルに対する「GetNext−Request」で
あると認識されると、MIBテーブル処理部20の処理
が開始される。First, when the SNMP message processing unit 10 recognizes that the SNMP message received from the manager is "GetNext-Request" for the table, the processing of the MIB table processing unit 20 is started.
【0031】MIBテーブル処理部20は、まず、SN
MPメッセージ処理部10より通知されたテーブルはM
IBテーブル記憶部21に存在するかどうかを判定する
(ステップS1)。MIBテーブル記憶部21にテーブ
ルが存在すれば、そのテーブルはSNMPメッセージ処
理部10より通知されたテーブルと同一かどうかが判断
される(ステップS2)。The MIB table processing section 20 firstly detects the SN.
The table notified by the MP message processing unit 10 is M
It is determined whether or not it exists in the IB table storage unit 21 (step S1). If the MIB table storage unit 21 has a table, it is determined whether the table is the same as the table notified by the SNMP message processing unit 10 (step S2).
【0032】ここで、同一と判断されると、次に、イン
デックス・エントリ対応関係保持部22に対応関係デー
タがあるかどうかが判定され(ステップS11)、対応
関係データがあると、SNMPメッセージ処理部10か
ら渡されたインデックスとインデックス・エントリ対応
関係保持部22の領域22aにあるリクエスト中のイン
デックスとが比較され(ステップS12)、対応関係デ
ータがなければ、MIBテーブル21a全体をサーチ範
囲とする(ステップS13)。If it is judged that they are the same, it is then judged whether or not there is correspondence data in the index / entry correspondence holding unit 22 (step S11). If there is correspondence data, the SNMP message processing is performed. The index passed from the unit 10 is compared with the index in the request in the area 22a of the index / entry correspondence holding unit 22 (step S12). If there is no correspondence data, the entire MIB table 21a is set as the search range. (Step S13).
【0033】ステップS12において、比較の結果、両
インデックスが一致した場合には(ステップS14)、
目的のエントリは「Get−Response」に用い
たエントリの順番が記憶されているインデックス・エン
トリ対応関係保持部22の領域22bの値のエントリと
し、インデックスは領域22cの「Get−Respo
nse」に用いたエントリのインデックスとする(ステ
ップS15)。In step S12, if both indexes match as a result of the comparison (step S14),
The target entry is the entry of the value of the area 22b of the index / entry correspondence holding unit 22 in which the order of the entries used for "Get-Response" is stored, and the index is the "Get-Response" of the area 22c.
nse ”is used as the index of the entry used (step S15).
【0034】また、両インデックスが一致しない場合に
は、インデックス・エントリ対応関係保持部22にある
領域22cの「Get−Response」に用いたエ
ントリのインデックスとSNMPメッセージ処理部10
から渡されたインデックスとを比較する(ステップS1
6)。ここで、一致した場合には(ステップS17)、
インデックス・エントリ対応関係保持部22にある領域
22bの「Get−Response」に用いたエント
リの順番の次のエントリがあるかどうかを判断する(ス
テップS18)。If the two indexes do not match, the index of the entry used for "Get-Response" in the area 22c in the index / entry correspondence holding section 22 and the SNMP message processing section 10
It is compared with the index passed from (step S1
6). If they match (step S17),
It is determined whether or not there is the next entry in the order of the entries used for "Get-Response" in the area 22b in the index / entry correspondence holding unit 22 (step S18).
【0035】ステップS17で一致しなかった場合に
は、インデックス・エントリ対応関係保持部22にある
領域22cの「Get−Response」に用いたエ
ントリのインデックスと、SNMPメッセージ処理部1
0から渡されたインデックスとの辞書的順番を比較する
(ステップS19)。ここで、「Get−Respon
se」に用いたエントリのインデックスの方がSNMP
メッセージ処理部10から渡されたインデックスより辞
書的順番が大きい場合には(ステップS20)、サーチ
範囲の下限エントリをインデックス・エントリ対応関係
保持部22にある領域22bの「Get−Respon
se」に用いたエントリの順番のエントリとし(ステッ
プS21)、「Get−Response」に用いたエ
ントリのインデックスの方がSNMPメッセージ処理部
10から渡されたインデックスより辞書的順番が小さい
場合には、サーチ範囲の上限エントリをインデックス・
エントリ対応関係保持部22にある領域22bの「Ge
t−Response」に用いたエントリの順番のエン
トリとする(ステップS22)。そして、サーチ範囲で
のエントリをサーチする(ステップS23)。If they do not match in step S17, the index of the entry used for "Get-Response" in the area 22c in the index / entry correspondence holding unit 22 and the SNMP message processing unit 1
The dictionary order with the index passed from 0 is compared (step S19). Here, "Get-Response
The index of the entry used for “se” is SNMP
If the lexicographical order is larger than the index passed from the message processing unit 10 (step S20), the lower limit entry of the search range is set to “Get-Response” in the region 22b in the index / entry correspondence holding unit 22.
If the index of the entry used for “Get-Response” has a smaller lexical order than the index passed from the SNMP message processing unit 10, Index the highest entry in the search range
In the area 22b in the entry correspondence holding unit 22, "Ge
The entries are in the order of the entries used for “t-Response” (step S22). Then, the entry within the search range is searched (step S23).
【0036】ここで、ステップS1およびステップS2
において、MIBテーブルが存在しなかったり、MIB
テーブルが同一でなかった場合には、MIBテーブル作
成部40にてインデックスとなるオブジェクトインスタ
ンスをキーとしてエントリが辞書的順番でソートされた
MIBテーブルを作成し(ステップS31)、MIBテ
ーブル記憶部21に作成されたMIBテーブルを記憶す
る(ステップS32)。次に、SNMPメッセージ処理
部10より通知されたインデックスの次に辞書的順番の
大きいエントリをサーチする(ステップS33)。Here, step S1 and step S2
In the, the MIB table does not exist,
If the tables are not the same, the MIB table creation unit 40 creates a MIB table in which the entries are sorted in a lexicographical order using the object instance serving as an index as a key (step S31), and the MIB table storage unit 21 is created. The created MIB table is stored (step S32). Next, the entry having the next largest lexicographical order after the index notified by the SNMP message processing unit 10 is searched (step S33).
【0037】ステップS18、ステップS23およびス
テップS33の処理の次は、辞書的順番の大きいエント
リは存在したかどうかが判断される(ステップS4
1)。ここで、辞書的順番の大きいエントリが存在した
場合と、ステップS15の処理の後は、インデックス・
エントリ対応関係保持部22に、SNMPメッセージ処
理部10より通知されたインデックスの値と、サーチ結
果のエントリの順番と、そのエントリのインデックスの
値との対応関係を記憶し(ステップS42)、「Get
−Response」に用いるオブジェクトインスタン
スの名前およびその値をSNMPメッセージ処理部10
に通知する(ステップS43)。一方、ステップS41
の判断において、辞書的順番の大きいエントリが存在し
ない場合には、「Get−Response」に用いる
オブジェクトインスタンスは存在しない旨をSNMPメ
ッセージ処理部10に通知する(ステップS44)。After the processing of steps S18, S23 and S33, it is determined whether or not there is an entry having a large lexicographical order (step S4).
1). Here, if there is an entry having a large lexicographical order, and if there is an index
The entry correspondence holding unit 22 stores the correspondence between the index value notified by the SNMP message processing unit 10, the order of the search result entries, and the index value of the entry (step S42).
-The name of the object instance used for "Response" and the value thereof
(Step S43). On the other hand, step S41
If there is no entry having a large lexicographical order in the determination of No., the SNMP message processing unit 10 is notified that there is no object instance used for “Get-Response” (step S44).
【0038】図6はリソース状態監視部の処理の流れを
示すフローチャートである。リソース状態監視部50は
リソース情報記憶部30のリソース情報の状態変化を監
視しており、そのため、まず、MIBテーブル記憶部2
1に記憶されているMIBテーブル21aに対応したリ
ソース情報を取得する(ステップS51)。リソース情
報に変化があると判断されると(ステップS52)、M
IBテーブル記憶部21に記憶されているMIBテーブ
ル21aを抹消し(ステップS53)、インデックス・
エントリ対応関係保持部22に記憶されている対応関係
を抹消する(ステップS54)。FIG. 6 is a flow chart showing the flow of processing of the resource status monitoring unit. The resource status monitoring unit 50 monitors the status change of the resource information in the resource information storage unit 30. Therefore, first, the MIB table storage unit 2
The resource information corresponding to the MIB table 21a stored in No. 1 is acquired (step S51). If it is determined that the resource information has changed (step S52), M
The MIB table 21a stored in the IB table storage unit 21 is deleted (step S53), and the index
The correspondence relationship stored in the entry correspondence relationship holding unit 22 is deleted (step S54).
【0039】ここで、MIB−IIで定義されているテ
ーブル「ipAddrTable」の検索処理の具体的
な例を示す。なお、MIBテーブル記憶部21およびイ
ンデックス・エントリ対応関係保持部22の記憶内容
は、リソース状態監視部50により、リソース情報の状
態が変化した際に抹消されているとする。Here, a specific example of the search processing of the table "ipAddrTable" defined in MIB-II will be shown. It is assumed that the storage contents of the MIB table storage unit 21 and the index / entry correspondence holding unit 22 are deleted by the resource status monitoring unit 50 when the status of the resource information changes.
【0040】SNMPによりテーブルの検索を行う際、
マネージャは最初、インスタンスを指定せず、オブジェ
クト名のみを指定した「GetNext−Reques
t」を発行する。ここで、SNMPメッセージ処理部1
0は、最初のテーブルに対する「GetNext−Re
quest」として、以下のようなリクエストを受けた
ものとする。When searching a table by SNMP,
Initially, the manager does not specify the instance, but only the object name, "GetNext-Requests".
t "is issued. Here, the SNMP message processing unit 1
0 means "GetNext-Re" for the first table.
It is assumed that the following request is received as "quest".
【0041】 SNMPメッセージ処理部10では、「GetNext
−Request」に指定されているオブジェクトイン
スタンスを順番に処理する。まず、最初の「ipAdE
ntAddr」についての処理を開始し、受信したメッ
セージが「ipAddrTable」に対する「Get
Next−Request」であると認識されると、M
IBテーブル処理部20が起動される。この際、SNM
Pメッセージ処理部10はMIBテーブル処理部20に
対して、以下のようなデータを渡す。[0041] In the SNMP message processing unit 10, “GetNext” is displayed.
-Process the object instances specified in "Request" in order. First, the first "ipAdE
ntAddr ”is started and the received message is“ GetAdd ”to“ ipAddrTable ”.
Next-Request "is recognized, M
The IB table processing unit 20 is activated. At this time, SNM
The P message processing unit 10 passes the following data to the MIB table processing unit 20.
【0042】図7はSNMPメッセージ処理部からMI
Bテーブル処理部へ渡されるデータ例を示す図である。
図示のデータ61の例によれば、テーブル名は「ipA
ddrTable」、リクエスト中に指定されていたイ
ンデックスは、オブジェクト名しか指定されていないの
で、「なし」となっている。FIG. 7 shows MI from the SNMP message processing unit.
It is a figure which shows the example of data passed to a B table processing part.
According to the example of the illustrated data 61, the table name is “ipA
"ddrTable", the index specified in the request is "none" because only the object name is specified.
【0043】MIBテーブル処理部20は、MIBテー
ブル記憶部21にテーブル「ipAdEntAddr」
が存在するかどうかの判断を行う(図2中のS1)。今
は、起動されて最初のテーブルに対する「GetNex
t−Request」の処理中であるので、MIBテー
ブル記憶部21にはデータは存在しない。したがって、
MIBテーブル作成部40によりMIBテーブルを作成
することになる。MIBテーブル作成部40では、リソ
ース情報記憶部30からリソース情報を取得してMIB
のオブジェクトインスタンスからなるテーブルを作成
し、さらにインデックスによる辞書的順番にソートが行
われる(図4中のS31)。ここで、リソース情報の取
得方法には、たとえばUNIXマシンであれば、UNI
Xのシステムコールなどを使用する。この結果、次のよ
うな内容のMIBテーブルが作成されたとする。The MIB table processing unit 20 stores the table “ipAdEntAddr” in the MIB table storage unit 21.
Is determined (S1 in FIG. 2). Now for the first table that has been launched, "GetNex
Since the “t-Request” is being processed, no data exists in the MIB table storage unit 21. Therefore,
The MIB table is created by the MIB table creating unit 40. The MIB table creation unit 40 acquires the resource information from the resource information storage unit 30 to obtain the MIB.
A table including the object instances of is created, and sorting is further performed in the dictionary order by the index (S31 in FIG. 4). Here, as a method of acquiring resource information, for example, if it is a UNIX machine, UNI
X system call is used. As a result, assume that the MIB table having the following contents is created.
【0044】図8は作成されたMIBテーブルの内容例
を示す図である。図示の内容例によれば、テーブル62
の「ipAddrTable」では、インデックスとな
るオブジェクトは「ipAdEntAddr」である。
したがって、このテーブル62は、「ipAdEntA
ddr」のオブジェクトインスタンスの辞書的順番の大
小によってソートされていることになる。FIG. 8 is a diagram showing an example of the contents of the created MIB table. According to the illustrated content example, the table 62
In “ipAddrTable”, the object serving as an index is “ipAdEntAddr”.
Therefore, this table 62 shows “ipAdEntA
They are sorted according to the size of the lexicographical order of the object instances of "ddr".
【0045】次に、作成されたテーブル62はMIBテ
ーブル記憶部21にMIBテーブル21aとして記憶す
る(図4中のS32)。そして、図7に示されたインデ
ックスの次に辞書的順番の大きいインデックスを持った
エントリをサーチする(図4中のS33)。サーチの方
法としては、たとえば二分検索法などがある。なお、図
7のデータ61では、インデックスの指定がないので、
サーチ結果のエントリは図8のテーブル62中で辞書的
順番が最少のインデックスを持つエントリ、すなわち、
1番目のエントリとなる。Next, the created table 62 is stored in the MIB table storage section 21 as the MIB table 21a (S32 in FIG. 4). Then, the entry having the index having the next largest lexicographic order after the index shown in FIG. 7 is searched (S33 in FIG. 4). As a search method, there is a binary search method, for example. In the data 61 of FIG. 7, since no index is specified,
The entry of the search result is the entry having the index with the smallest lexicographical order in the table 62 of FIG.
This is the first entry.
【0046】サーチが終了し、エントリが見つかると、
インデックス・エントリ対応関係保持部22の領域22
aには、SNMPメッセージ処理部10より通知された
インデックスの値が記憶され、領域22bには、サーチ
結果のエントリの順番が記憶され、領域22cには、そ
のエントリのインデックスの値が記憶されて、インデッ
クス・エントリの対応関係が記憶される(図5中のS4
2)。When the search is completed and an entry is found,
Area 22 of index / entry correspondence holding unit 22
The value of the index notified from the SNMP message processing unit 10 is stored in a, the order of the entry of the search result is stored in the area 22b, and the index value of the entry is stored in the area 22c. , The correspondence between index entries is stored (S4 in FIG. 5).
2).
【0047】図9はインデックス・エントリ対応関係保
持部の内容例を示す図である。図示の例によれば、イン
デックス・エントリ対応関係保持部22のデータ63
は、図8のテーブル62に対して図7のデータ61がS
NMPメッセージ処理部10より通知された際には、領
域22aに相当するリクエスト中のインデックスとし
て、「なし」が記憶され、領域22bに相当する「Ge
t−Response」に用いたエントリの順番とし
て、「1」が記憶され、領域22cに相当する「Get
−Response」に用いたエントリのインデックス
として、「129.249.1.1」が記憶されてい
る。FIG. 9 is a diagram showing an example of the contents of the index / entry correspondence holding unit. According to the illustrated example, the data 63 of the index / entry correspondence holding unit 22
Of the data 61 of FIG. 7 to the table 62 of FIG.
When notified by the NMP message processing unit 10, "none" is stored as the index in the request corresponding to the area 22a, and "Ge" corresponding to the area 22b is stored.
"1" is stored as the order of the entries used for "t-Response", and "Get" corresponding to the area 22c is stored.
“129.249.1.1” is stored as the index of the entry used for “Response”.
【0048】このような手順で、「ipAdEntAd
dr」に対応した、「Get−Response」に用
いるオブジェクトインスタンス「ipAdEntAdd
r.129.249.1.1」とその値「129.24
9.1.1」とが、SNMPメッセージ処理部10へと
渡される(図5中のS43)。In this way, "ipAdEntAd
object instance “ipAdEntAdd” used for “Get-Response” corresponding to “dr”
r. 129.249.1.1 ”and its value“ 129.24
9.1.1 ”is passed to the SNMP message processing unit 10 (S43 in FIG. 5).
【0049】「ipAdEntAddr」の処理が終了
すると、SNMPメッセージ処理部10では、「ipA
dEntIfIndex」に対する処理を開始する。こ
のときも、SNMPメッセージ処理部10からMIBテ
ーブル処理部20へ図7に示したデータ61と同じ内容
のデータが渡される。When the processing of "ipAdEntAddr" is completed, the SNMP message processing unit 10 sets "ipA
The process for “dEntIfIndex” is started. Also at this time, the data having the same content as the data 61 shown in FIG. 7 is passed from the SNMP message processing unit 10 to the MIB table processing unit 20.
【0050】今度は、MIBテーブル記憶部21には図
8に示したテーブル62の内容が記憶され、インデック
ス・エントリ対応関係保持部22には図9に示したデー
タ63が記憶されている。したがって、SNMPメッセ
ージ処理部10より通知されたテーブルがMIBテーブ
ル記憶部21に存在することになる(図2中のS1、S
2がともに肯定)。SNMPメッセージ処理部10から
渡されたインデックスとインデックス・エントリ対応関
係保持部22にあるリクエスト中のインデックスとはと
もに「なし」で一致するため、インデックス・エントリ
対応関係保持部22にある「Get−Respons
e」に用いたエントリの順番「1」と「Get−Res
ponse」に用いたエントリのインデックス「12
9.249.1.1」とを使用し(図3中のS11、S
12、S14、S15)、SNMPメッセージ処理部1
0へ渡されるオブジェクトインスタンスおよびその値
は、それぞれ「ipAdEntIfIndex.12
9.249.1.1」および「3」となる。This time, the contents of the table 62 shown in FIG. 8 are stored in the MIB table storage unit 21, and the data 63 shown in FIG. 9 is stored in the index / entry correspondence holding unit 22. Therefore, the table notified by the SNMP message processing unit 10 exists in the MIB table storage unit 21 (S1, S in FIG. 2).
2 is both positive). Since both the index passed from the SNMP message processing unit 10 and the index in the request stored in the index / entry correspondence holding unit 22 match with “none”, “Get-Responses” in the index / entry correspondence holding unit 22 is matched.
The order of the entries used for “e” is “1” and “Get-Res
The index of the entry used for "response""12
9.249.1.1 ”(S11, S in FIG. 3
12, S14, S15), the SNMP message processing unit 1
The object instance passed to 0 and its value are "ipAdEntIfIndex.12".
9.249.1.1 ”and“ 3 ”.
【0051】「ipAdEntIfIndex」に対す
る処理と同様の処理を、「GetNext−Reque
st」に指定された他のオブジェクトについても繰り返
すと、上記リクエスト(1)に対する「Get−Res
ponse」の内容は以下のようになる。A process similar to the process for "ipAdEntIfIndex" is performed by "GetNext-Request".
Repeating for other objects designated as “st”, “Get-Res” for the above request (1)
The contents of "ponse" are as follows.
【0052】 ipAdEntAddr.129.249.1.1=129.249.1.1, ipAdEntIfIndex.129.249.1.1=3, ipAdEntNetMask.129.249.1.1=255.255.255.0, ipAdEntBcastAddr.129.249.1.1=129.249.1.0, ipAdEntReasmMaxSize.129.249.1.1=1500 …(2) このように、「GetNext−Request」に指
定されたオブジェクトの数は5つであり、これらのエン
トリのサーチはそれぞれ5回必要なところが1回で済ん
でいる。したがって、4回のサーチの時間分、処理に要
する時間を短縮することができる。IpAdEntAddr.129.249.1.1 = 129.249.1.1, 129.249.1.1 = 3, ipAdEntNetMask.129.249.1.1 = 255.255.255.0, ipAdEntBcastAddr.129.249.1.1 = 129.249.1.0, ipAdEntReasmMaxSize.129.249.1.1 = 1500… ( 2) As described above, the number of objects specified in “GetNext-Request” is five, and each of these entries needs to be searched five times, but only once. Therefore, the time required for processing can be shortened by the time required for four searches.
【0053】上記(2)の内容の「Get−Respo
nse」を受けて、次に予想される「GetNext−
Request」の内容は以下のようになる。 get-next ( ipAdEntAddr.129.249.1.1, ipAdEntIfIndex.129.249.1.1, ipAdEntNetMask.129.249.1.1, ipAdEntBcastAddr.129.249.1.1, ipAdEntReasmMaxSize.129.249.1.1 ) …(3) 前記(1)の「GetNext−Request」を受
けたときと同様に、SNMPメッセージ処理部10は、
「ipAdEntAddr」から順に処理を行う。オブ
ジェクトインスタンス「ipAdEntAddr.12
9.249.1.1」に対して、SNMPメッセージ処
理部10からMIBテーブル処理部20へ渡されるデー
タは以下のようになる。[Get-Respo] of the contents of the above (2)
"GetNext-" expected next time
The contents of "Request" are as follows. get-next (ipAdEntAddr.129.249.1.1, ipAdEntIfIndex.129.249.1.1, ipAdEntNetMask.129.249.1.1, ipAdEntBcastAddr.129.249.1.1, ipAdEntReasmMaxSize.129.249.1.1) (3) Receives "GetNext-Request" in (1) above. The SNMP message processing unit 10
Processing is performed in order from "ipAdEntAddr". The object instance “ipAdEntAddr.12
9.249.1.1 ”, the data passed from the SNMP message processing unit 10 to the MIB table processing unit 20 is as follows.
【0054】図10はSNMPメッセージ処理部からM
IBテーブル処理部へ渡されるデータ例を示す図であ
る。図示のデータ64の例によれば、テーブル名は「i
pAddrTable」、リクエスト中に指定されてい
たインデックスは「129.249.1.1」となって
いる。FIG. 10 shows M from the SNMP message processing unit.
It is a figure which shows the example of data passed to an IB table processing part. According to the example of the illustrated data 64, the table name is “i
pAddrTable ”, and the index specified in the request is“ 129.249.1.1 ”.
【0055】このデータ64を受けたMIBテーブル処
理部20では、渡されたテーブルがMIBテーブル記憶
部21にあるものと同一なので、インデックス・エント
リ対応関係保持部22の対応関係を参照する。インデッ
クス・エントリ対応関係保持部22の内容は、図9のと
おりなので、SNMPメッセージ処理部10から渡され
たインデックス「129.249.1.1」と、インデ
ックス・エントリ対応関係保持部22にあるリクエスト
中のインデックス「なし」は一致しない(図3中のS1
4が否定)。これを受けて、次に、「Get−Resp
onse」に用いたエントリのインデックス「129.
249.1.1」と、SNMPメッセージ処理部10か
ら渡されたインデックス「129.249.1.1」と
を比較する。ここでは、これらインデックスは一致する
ので、「Get−Response」に用いるエントリ
の順番は、インデックス・エントリ対応関係保持部22
にある「1」の次、すなわち、「2」となる。ここで、
2番目のエントリが存在するかどうかをMIBテーブル
記憶部21にあるMIBテーブル21aを参照して判断
する(図3中のS17、S18)。In the MIB table processing unit 20 that has received this data 64, the passed table is the same as that in the MIB table storage unit 21, so the correspondence relation of the index / entry correspondence relation holding unit 22 is referred to. Since the content of the index / entry correspondence holding unit 22 is as shown in FIG. 9, the index “129.249.1.1” passed from the SNMP message processing unit 10 and the request in the index / entry correspondence holding unit 22 are stored. The index "none" in the table does not match (S1 in FIG. 3).
4 is denied). In response to this, next, "Get-Resp
index of the entry used for “onse” is “129.
249.1.1 ”is compared with the index“ 129.249.1.1 ”passed from the SNMP message processing unit 10. Here, since these indexes match, the order of the entries used for “Get-Response” is the index / entry correspondence holding unit 22.
It becomes the next of "1" in "2", that is, "2". here,
It is determined whether or not the second entry exists by referring to the MIB table 21a in the MIB table storage unit 21 (S17 and S18 in FIG. 3).
【0056】今、MIBテーブル記憶部21にあるMI
Bテーブル21aには、図9に示したように、2番目の
エントリが存在する。したがって、インデックス・エン
トリ対応関係保持部22の内容は、以下のように更新さ
れる。The MI currently stored in the MIB table storage unit 21
As shown in FIG. 9, the B table 21a has a second entry. Therefore, the contents of the index / entry correspondence holding unit 22 are updated as follows.
【0057】図11はインデックス・エントリ対応関係
保持部の更新内容例を示す図である。図示の例によれ
ば、インデックス・エントリ対応関係保持部22のデー
タ65は、SNMPメッセージ処理部10より通知され
た際のインデックスは「129.249.1.1」なの
で、リクエスト中のインデックスとして、「129.2
49.1.1」が記憶され、「Get−Respons
e」に用いたエントリの順番としては、「2」が記憶さ
れ、「Get−Response」に用いたエントリの
インデックスとしては、「129.249.1.11」
が記憶されている。FIG. 11 is a diagram showing an example of updated contents of the index / entry correspondence holding unit. According to the example shown in the figure, the data 65 of the index / entry correspondence holding unit 22 has the index “129.249.1.1” when notified by the SNMP message processing unit 10. "129.2
49.1.1 ”is stored, and“ Get-Responses ”is stored.
“2” is stored as the order of the entries used for “e”, and “129.249.1.11” is stored as the index of the entry used for “Get-Response”.
Is remembered.
【0058】その後、「Get−Response」に
用いられるオブジェクトインスタンス「ipAdEnt
Addr.129.249.1.11」とその値「12
9.249.1.11」とがSNMPメッセージ処理部
10へ渡される。After that, the object instance "ipAdEnt" used for "Get-Response"
Addr. 129.249.1.11 ”and its value“ 12
9.249.1.11 ”is passed to the SNMP message processing unit 10.
【0059】上記リクエスト(3)に対する「Get−
Response」の内容は以下のようになる。 ipAdEntAddr.129.249.1.11=129.249.1.11, ipAdEntIfIndex.129.249.1.11=1, ipAdEntNetMask.129.249.1.11=255.255.255.0, ipAdEntBcastAddr.129.249.1.11=129.249.1.0, ipAdEntReasmMaxSize.129.249.1.11=1500 …(4) 他のオブジェクトインスタンスの処理は、更新されたイ
ンデックス・エントリ対応関係保持部22の内容を使用
し、同様にして繰り返し実行される。"Get-" for the above request (3)
The contents of "Response" are as follows. ipAdEntAddr.129.249.1.11 = 129.249.1.11, = ipAdEntIfIndex.129.249.1.11 = 1, ipAdEntNetMask.129.249.1.11 = 255.255.255.0, ipAdEntBcastAddr.129.249.1.11 = 129.249.1.0, ipAdEntReasmMaxSize.129.249.1.11 = 1500 ... (4) Other The processing of the object instance of is used repeatedly by using the updated contents of the index / entry correspondence holding unit 22.
【0060】このようにしてテーブルの検索が続行され
ると、このテーブルに対する最後の「GetNext−
Request」の内容は、以下のようになる。 get-next ( ipAdEntAddr.129.249.1.61, ipAdEntIfIndex.129.249.1.61, ipAdEntNetMask.129.249.1.61, ipAdEntBcastAddr.129.249.1.61, ipAdEntReasmMaxSize.129.249.1.61 ) …(5) テーブル検索の「GetNext−Request」を
順次処理してきたとすると、このときのインデックス・
エントリ対応関係保持部22の内容は以下のようになっ
ている。When the search of the table is continued in this way, the last "GetNext-" for this table is
The contents of "Request" are as follows. get-next (ipAdEntAddr.129.249.1.61, ipAdEntIfIndex.129.249.1.61, ipAdEntNetMask.129.249.1.61, ipAdEntBcastAddr.129.249.1.61, ipAdEntReasmMaxSize.129.249.1.61) ... (5) “GetNext-Request is processed sequentially” for table search. If so, the index at this time
The contents of the entry correspondence holding unit 22 are as follows.
【0061】図12はインデックス・エントリ対応関係
保持部の内容例を示す図である。図示の例によれば、イ
ンデックス・エントリ対応関係保持部22のデータ66
は、リクエスト中のインデックスが「129.249.
1.51」、「Get−Response」に用いたエ
ントリの順番が「7」、「Get−Response」
に用いたエントリのインデックスが「129.249.
1.61」になっている。FIG. 12 is a diagram showing an example of the contents of the index / entry correspondence holding unit. According to the illustrated example, the data 66 of the index / entry correspondence holding unit 22
Indicates that the index in the request is "129.249.
The order of the entries used for "1.51", "Get-Response" is "7", "Get-Response"
The index of the entry used for is "129.249.
It is 1.61 ".
【0062】上記(5)の「GetNext−Requ
est」中のオブジェクトインスタンス「ipAdEn
tAddr.129.249.1.61」に対して、S
NMPメッセージ処理部10からMIBテーブル記憶部
21へ渡されるデータは以下のようになる。In the above (5), "GetNext-Request"
object instance "ipAdEn in est"
tAddr. 129.249.1.61 ”for S
The data passed from the NMP message processing unit 10 to the MIB table storage unit 21 are as follows.
【0063】図13はSNMPメッセージ処理部からM
IBテーブル処理部へ渡されるデータ例を示す図であ
る。図示のデータ67の例によれば、テーブル名は「i
pAddrTable」、リクエスト中に指定されてい
たインデックスは「129.249.1.61」となっ
ている。FIG. 13 shows an M from the SNMP message processing unit.
It is a figure which shows the example of data passed to an IB table processing part. According to the example of the illustrated data 67, the table name is “i
pAddrTable ”, and the index specified in the request is“ 129.249.1.61 ”.
【0064】前記(3)の「GetNext−Requ
est」を受けたときと同様、まず、SNMPメッセー
ジ処理部10から渡されたインデックス「129.24
9.1.61」と、インデックス・エントリ対応関係保
持部22にあるリクエスト中のインデックス「129.
249.1.51」とを比較する。これらインデックス
は一致しないので、、次に、「Get−Respons
e」に用いたエントリのインデックス「129.24
9.1.61」と、SNMPメッセージ処理部10から
渡されたインデックス「129.249.1.61」と
を比較する。これらインデックスは一致するので、「G
et−Response」に用いたエントリの順番は、
インデックス・エントリ対応関係保持部22にある
「7」の次、すなわち、「8」となる。しかし、図8に
例示のテーブル62には、8番目のエントリは存在しな
い。したがって、MIBテーブル処理部20は、「Ge
t−Response」に用いるオブジェクトインスタ
ンスは存在しない旨を、SNMPメッセージ処理部10
へ通知する(図5中のS41、S44)。このとき、イ
ンデックス・エントリ対応関係保持部22の内容は更新
されない。In the above (3), "GetNext-Request"
Similarly to the case of receiving the “est”, first, the index “129.24” passed from the SNMP message processing unit 10 is received.
9.1.61 ”and the index“ 129.
249.1.51 ". Since these indexes do not match, the next step is "Get-Responses".
The index “129.24” of the entry used for “e”
The “9.1.61” is compared with the index “129.249.1.61” passed from the SNMP message processing unit 10. Since these indexes match, "G
The order of the entries used for "et-Response" is
It is next to "7" in the index / entry correspondence holding unit 22, that is, "8". However, the table 62 illustrated in FIG. 8 does not have the eighth entry. Therefore, the MIB table processing unit 20 determines that “Ge
The SNMP message processing unit 10 indicates that the object instance used for “t-Response” does not exist.
To (S41, S44 in FIG. 5). At this time, the contents of the index / entry correspondence holding unit 22 are not updated.
【0065】SNMPメッセージ処理部10では、MI
Bツリー上で「ipAdEntAddr」の次に辞書的
順番の大きいオブジェクトである「ipAdEntIf
Index」を検索し、「ipAdEntIfInde
x」に対してインデックス「なし」の状態、すなわち、
図7に示したデータと同じ内容のデータを渡して、再度
MIBテーブル処理部20を起動する。インデックスは
「なし」なので、MIBテーブル処理部20はテーブル
中最少のエントリの順番とインデックスとを用いてオブ
ジェクトインスタンス「ipAdEntIfInde
x.129.249.1.1」とその値「3」とをSN
MPメッセージ処理部10へ渡し、インデックス・エン
トリ対応関係保持部22の内容を更新する。更新された
結果は、図9に示したデータと同じ内容になる。In the SNMP message processing unit 10, the MI
"IpAdEntIf", which is the object with the next largest lexicographical order after "ipAdEntAddr" on the B-tree
Search for "Index" and search for "ipAdEntIfInde
The state of the index “none” for x ”, that is,
The data having the same content as the data shown in FIG. 7 is passed, and the MIB table processing unit 20 is activated again. Since the index is “none”, the MIB table processing unit 20 uses the order of the smallest entry in the table and the index to determine the object instance “ipAdEntIfInde.
x. 129.249.1.1 ”and its value“ 3 ”are SN
It is passed to the MP message processing unit 10 and the contents of the index / entry correspondence holding unit 22 are updated. The updated result has the same contents as the data shown in FIG.
【0066】このように、インデックス・エントリ対応
関係保持部22の内容を利用することにより、エントリ
を決めるためのサーチが不要になるので、最初のエント
リを除くエントリ数6×オブジェクト数5=30回のサ
ーチ時間分、処理に要する時間を短くすることができ
る。As described above, by using the contents of the index / entry correspondence holding unit 22, a search for determining an entry is not required, so the number of entries excluding the first entry 6 × the number of objects 5 = 30 times. It is possible to shorten the time required for processing by the search time.
【0067】次に、SNMPメッセージ処理部10から
のリクエストに、インデックス・エントリ対応関係保持
部22にあるリクエスト中のインデックスと「Get−
Response」に用いたエントリのインデックスと
のいずれにも該当しないインデックスが指定されていた
場合について考える。Next, in the request from the SNMP message processing unit 10, the index in the request stored in the index / entry correspondence holding unit 22 and "Get-
Consider a case where an index that does not correspond to any of the indexes of the entries used for “Response” is specified.
【0068】今、MIBテーブル記憶部21に図8のテ
ーブル62と同じ内容が記憶され、また、インデックス
・エントリ対応関係保持部22には、以下のような内容
が記憶されていたとする。Now, it is assumed that the same contents as the table 62 of FIG. 8 are stored in the MIB table storage unit 21, and the following contents are stored in the index / entry correspondence holding unit 22.
【0069】図14はインデックス・エントリ対応関係
保持部の内容例を示す図である。図示の例によれば、イ
ンデックス・エントリ対応関係保持部22のデータ68
は、リクエスト中のインデックスが「129.249.
1.31」、「Get−Response」に用いたエ
ントリの順番が「5」、「Get−Response」
に用いたエントリのインデックスが「129.249.
1.41」になっているものとする。FIG. 14 is a diagram showing an example of contents of the index / entry correspondence holding unit. According to the illustrated example, the data 68 of the index / entry correspondence holding unit 22 is
Indicates that the index in the request is "129.249.
The order of entries used for "1.31", "Get-Response" is "5", "Get-Response"
The index of the entry used for is "129.249.
1.41 ”.
【0070】これらの状態で、SNMPメッセージ処理
部10がたとえば以下の「GetNext−Reque
st」を受けたとする。 get-next ( ipAdEntAddr.129.249.1.25 ) …(7) このとき、SNMPメッセージ処理部10からMIBテ
ーブル処理部20へ渡されるデータは以下のようにな
る。In these states, the SNMP message processing unit 10 may use, for example, the following "GetNext-Request".
st ”is received. get-next (ipAdEntAddr.129.249.1.25) (7) At this time, the data passed from the SNMP message processing unit 10 to the MIB table processing unit 20 is as follows.
【0071】図15はSNMPメッセージ処理部からM
IBテーブル処理部へ渡されるデータ例を示す図であ
る。図示のデータ69の例によれば、テーブル名は「i
pAddrTable」、リクエスト中に指定されてい
たインデックスは「129.249.1.25」となっ
ている。FIG. 15 shows an M message from the SNMP message processing unit.
It is a figure which shows the example of data passed to an IB table processing part. According to the example of the illustrated data 69, the table name is “i
pAddrTable ”, and the index specified in the request is“ 129.249.1.25 ”.
【0072】MIBテーブル処理部20では、MIBテ
ーブル記憶部21に「ipAdEntAddr」が記憶
されているので、インデックス・エントリ対応関係保持
部22のデータを参照する。しかし、このとき、SNM
Pメッセージ処理部10から渡されたインデックス「1
29.249.1.25」は、インデックス・エントリ
対応関係保持部22にあるリクエスト中のインデックス
「129.249.1.31」、「Get−Respo
nse」に用いたエントリのインデックス「129.2
49.1.41」のいずれとも一致しない。In the MIB table processing unit 20, since “ipAdEntAddr” is stored in the MIB table storage unit 21, the data in the index / entry correspondence holding unit 22 is referred to. However, at this time, SNM
The index “1” passed from the P message processing unit 10
“29.249.1.25” is the index “129.24.91.31” and “Get-Respo” in the request stored in the index / entry correspondence holding unit 22.
The index of the entry used for “nse” is “129.2.
49.1.41 ”.
【0073】よって、「Get−Response」に
用いるエントリをテーブル全体からサーチすることが必
要となる。ここで、MIBテーブル記憶部21にあるテ
ーブルはインデックスの辞書的順番によってソートされ
ているので、インデックス・エントリ対応関係保持部2
2にあるリクエスト中のインデックスと、SNMPメッ
セージ処理部10から渡されたインデックスとの辞書的
順番の大小により、サーチ範囲を決めることができる。Therefore, it is necessary to search the entire table for the entry used for "Get-Response". Here, since the table in the MIB table storage unit 21 is sorted according to the lexical order of the indexes, the index / entry correspondence holding unit 2
The search range can be determined based on the size of the lexicographical order of the index in the request in 2 and the index passed from the SNMP message processing unit 10.
【0074】SNMPメッセージ処理部10から渡され
たインデックス「129.249.1.25」は、イン
デックス・エントリ対応関係保持部22にあるリクエス
ト中のインデックス「129.249.1.31」より
も辞書的順番が小さい。したがって、「Get−Res
ponse」に用いるエントリは、テーブル中、順番が
最小のエントリ、すなわち、1番目のエントリと、イン
デックス・エントリ対応関係保持部22にある「Get
−Response」に用いたエントリ、すなわち、5
番目のエントリとの間でサーチすればよい(図3中のS
22、S23)。The index “129.249.1.25” passed from the SNMP message processing unit 10 is a dictionary rather than the index “129.249.1.31” in the request in the index / entry correspondence holding unit 22. The target order is small. Therefore, "Get-Res
The entry used for “response” is the entry with the smallest order in the table, that is, the first entry and “Get” in the index / entry correspondence holding unit 22.
-The entry used for "Response", that is, 5
Search with the th entry (S in FIG. 3)
22, S23).
【0075】その結果、「Get−Response」
に用いるエントリは、インデックスが「129.24
9.1.31」、すなわち、4番目のエントリとなる。
後は、すでに述べた場合と同様に、インデックス・エン
トリ対応関係保持部22の内容が更新され、「Get−
Response」に用いられるオブジェクトインスタ
ンスとその値が、SNMPメッセージ処理部10へと渡
される。As a result, "Get-Response"
The entry used for the index is "129.24.
9.1.31 ”, that is, the fourth entry.
After that, as in the case already described, the content of the index / entry correspondence holding unit 22 is updated to "Get-
The object instance used for “Response” and its value are passed to the SNMP message processing unit 10.
【0076】このように、インデックス・エントリ対応
関係保持部22の内容を利用することにより、サーチ範
囲を狭めることができ、インデックスの辞書的順番の大
小を比較する処理時間を、5〜7番目のエントリ、すな
わち、3エントリ分短くすることができるようになる。As described above, by using the contents of the index / entry correspondence holding unit 22, the search range can be narrowed, and the processing time for comparing the lexicographical order of the indexes is the fifth to the seventh. It becomes possible to shorten the number of entries, that is, three entries.
【0077】なお、上述の実施例では、MIBテーブル
記憶部およびインデックス・エントリ対応関係保持部に
1つのテーブル分の内容だけを記憶している場合を示し
たが、これらを複数記憶しておくようにすることもでき
る。これにより、複数のテーブルに対する「GetNe
xt−Request」を非連続的に受けた場合の全体
的な処理時間を短縮することが可能である。これは、複
数のSNMPマネージャから同時にアクセスされる可能
性の高いSNMPエージェントにおいて、特に有効であ
る。In the above embodiment, the MIB table storage unit and the index / entry correspondence holding unit store only the contents of one table, but a plurality of these may be stored. You can also This allows "GetNe for multiple tables.
It is possible to reduce the overall processing time when the "xt-Request" is received discontinuously. This is particularly effective for an SNMP agent that is likely to be simultaneously accessed by multiple SNMP managers.
【0078】[0078]
【発明の効果】以上説明したように本発明では、テーブ
ル全体をインデックスでソートして記憶し、さらに、
「GetNext−Request」中のインデックス
と、サーチしたエントリの順番と、そのエントリのイン
デックスとの組み合わせによるインデックス・エントリ
対応関係を記憶しておくように構成したことにより、以
下のような効果がある。As described above, according to the present invention, the entire table is sorted by index and stored.
The following effects can be obtained by storing the index-entry correspondence relationship based on the combination of the index in "GetNext-Request", the order of the searched entry, and the index of the entry.
【0079】(a)同一のインデックスを持つ複数のオ
ブジェクトインスタンスへの「GetNext−Req
uest」の処理で、エントリのサーチは最初の1回の
みでよく、次回からはインデックス・エントリ対応関係
を参照するだけでよいので、エントリ中のオブジェクト
の個数が多いほど、エントリ全体のオブジェクトインス
タンスを取得するのに要する時間は短くなる。(A) "GetNext-Req" for a plurality of object instances having the same index
In the process of “uest”, the entry search only needs to be performed once at the beginning, and from the next time, it is only necessary to refer to the index / entry correspondence. It takes less time to get.
【0080】(b)テーブルはソートされているため、
「GetNext−Request」中のオブジェクト
インスタンスを持つインデックスが、記憶されているエ
ントリのそれと同じであった場合には、テーブル全体で
はなく、記憶されているエントリの次のエントリをサー
チすればよいので、エントリのサーチ時間を短縮するこ
とができる。(B) Since the table is sorted,
If the index having the object instance in "GetNext-Request" is the same as that of the stored entry, the next entry of the stored entry may be searched instead of the entire table. The entry search time can be shortened.
【0081】(c)テーブルはソートされているため、
「GetNext−Request」中に指定されたイ
ンデックスが、記憶されている「GetNext−Re
quest」中のインデックスやサーチしたエントリの
インデックスのいずれにも一致しない場合には、テーブ
ル全体のうち、エントリのサーチは、記憶されているイ
ンデックスおよびサーチしたエントリのインデックスよ
り辞書的順番の大きい方向または小さい方向のどちらか
のみのでサーチを行えばよく、サーチ効果を向上させる
ことができる。(C) Since the table is sorted,
The index specified in "GetNext-Request" is stored in "GetNext-Re".
If it does not match any of the index in “quest” or the index of the searched entry, the search of the entry in the entire table is performed in a direction having a larger lexicographical order than the stored index and the index of the searched entry, or It suffices to perform the search only in one of the smaller directions, and the search effect can be improved.
【0082】実際に上記効果が現れる状況例としては、
以下のような場合が考えられる。通常、テーブルの検索
は、1エントリを単位として「GetNext−Req
uest」の発行と「Get−Response」の受
信の繰り返しにより行われる。このとき、テーブルは複
数のオブジェクトによって構成されるのが一般的であ
る。よって、1つの「GetNext−Reques
t」は、同一エントリ中の複数のオブジェクトインスタ
ンスが含まれた形で発行される。これが、上記(a)の
効果が現れる状況になる。As an example of a situation in which the above effect actually appears,
The following cases are possible. Normally, the table is searched by "GetNext-Req" in units of one entry.
It is performed by repeatedly issuing the "uest" and receiving the "Get-Response". At this time, the table is generally composed of a plurality of objects. Therefore, one "GetNext-Requests"
The “t” is issued in a form in which a plurality of object instances in the same entry are included. This is the situation in which the effect of (a) above appears.
【0083】「GetNext−Request」に対
する「Get−Response」には、「GetNe
xt−Request」中に指定されていたインデック
スの次に辞書的順番の大きいエントリが格納される。
「Get−Response」を受け取ったマネージャ
では、「Get−Response」に格納されたエン
トリのインデックスを用いて、新たな「GetNext
−Request」を発行し、これをテーブル全体の検
索が終了するまで繰り返す。したがって、指定されてい
るインデックスが辞書的順番として単調増加しながら、
「GetNext−Request」は繰り返し発行さ
れる。これが、上記(b)の効果が現れる状況になる。"Get-Response" for "GetNext-Request" contains "GetNe."
The entry having the next largest lexicographical order after the index designated in “xt-Request” is stored.
The manager receiving the "Get-Response" uses the index of the entry stored in the "Get-Response" to create a new "GetNext".
-Request "is issued and this is repeated until the search of the entire table is completed. Therefore, the specified index increases monotonically as a lexicographical order,
“GetNext-Request” is repeatedly issued. This is the situation where the effect of (b) above appears.
【0084】さらに、エージェントは複数のマネージャ
から管理されている場合がある。このとき、複数のマネ
ージャが同時に同一のテーブルを検索開始した場合に
は、受信する「GetNext−Request」に指
定されたインデックスが上記のように辞書的順番として
単調増加するとは限らず、指定されているエントリがラ
ンダムに変化する可能性がある。これが、上記(c)の
効果が現れる状況になる。Further, the agent may be managed by a plurality of managers. At this time, when a plurality of managers start searching the same table at the same time, the index specified in the received "GetNext-Request" does not always increase monotonically in the lexicographical order as described above, but is specified. Entries may change randomly. This is the situation where the effect of (c) above appears.
【図1】本発明のネットワーク管理情報検索方式の構成
例を示す図である。FIG. 1 is a diagram showing a configuration example of a network management information search method of the present invention.
【図2】MIBテーブル処理部の処理の流れを示すフロ
ーチャート(その1)である。FIG. 2 is a flowchart (No. 1) showing the flow of processing of the MIB table processing unit.
【図3】MIBテーブル処理部の処理の流れを示すフロ
ーチャート(その2)である。FIG. 3 is a flowchart (part 2) showing the flow of processing of the MIB table processing unit.
【図4】MIBテーブル処理部の処理の流れを示すフロ
ーチャート(その3)である。FIG. 4 is a flowchart (No. 3) showing the flow of processing of the MIB table processing unit.
【図5】MIBテーブル処理部の処理の流れを示すフロ
ーチャート(その4)である。FIG. 5 is a flowchart (No. 4) showing the flow of processing of the MIB table processing unit.
【図6】リソース状態監視部の処理の流れを示すフロー
チャートである。FIG. 6 is a flowchart showing a processing flow of a resource status monitoring unit.
【図7】SNMPメッセージ処理部からMIBテーブル
処理部へ渡されるデータ例を示す図である。FIG. 7 is a diagram showing an example of data passed from an SNMP message processing unit to an MIB table processing unit.
【図8】作成されたMIBテーブルの内容例を示す図で
ある。FIG. 8 is a diagram showing an example of the contents of a created MIB table.
【図9】インデックス・エントリ対応関係保持部の内容
例を示す図である。FIG. 9 is a diagram showing an example of contents of an index / entry correspondence holding unit.
【図10】SNMPメッセージ処理部からMIBテーブ
ル処理部へ渡されるデータ例を示す図である。FIG. 10 is a diagram showing an example of data passed from the SNMP message processing unit to the MIB table processing unit.
【図11】インデックス・エントリ対応関係保持部の更
新内容例を示す図である。FIG. 11 is a diagram showing an example of updated contents of an index / entry correspondence holding unit.
【図12】インデックス・エントリ対応関係保持部の内
容例を示す図である。FIG. 12 is a diagram showing an example of contents of an index / entry correspondence holding unit.
【図13】SNMPメッセージ処理部からMIBテーブ
ル処理部へ渡されるデータ例を示す図である。FIG. 13 is a diagram showing an example of data passed from the SNMP message processing unit to the MIB table processing unit.
【図14】インデックス・エントリ対応関係保持部の内
容例を示す図である。FIG. 14 is a diagram showing an example of contents of an index / entry correspondence holding unit.
【図15】SNMPメッセージ処理部からMIBテーブ
ル処理部へ渡されるデータ例を示す図である。FIG. 15 is a diagram showing an example of data passed from the SNMP message processing unit to the MIB table processing unit.
【図16】MIB−IIに定義されているテーブルの一
例を示す図である。FIG. 16 is a diagram showing an example of a table defined in MIB-II.
10 SNMPメッセージ処理部 20 MIBテーブル処理部 21 MIBテーブル記憶部 21a MIBテーブル 22 インデックス・エントリ対応関係保持部 30 リソース情報記憶部 40 MIBテーブル作成部 50 リソース状態監視部 10 SNMP Message Processing Section 20 MIB Table Processing Section 21 MIB Table Storage Section 21a MIB Table 22 Index / Entry Correspondence Holding Section 30 Resource Information Storage Section 40 MIB Table Creation Section 50 Resource Status Monitoring Section
Claims (6)
に登録されているネットワーク管理情報を検索するネッ
トワーク管理情報検索方式において、 マネージャとの通信時にネットワーク管理プロトコルの
プロトコル処理を行うメッセージ処理手段と、 被管理オブジェクトのインスタンスが登録され、インデ
ックスとなるオブジェクトのインスタンスをキーとして
エントリが辞書的順番にソートされている管理情報ベー
ステーブル記憶部、および前記メッセージ処理手段から
通知されたリクエスト中に指定されているインデックス
と前記メッセージ処理手段への応答に用いたエントリの
順番と前記メッセージ処理手段への応答に用いたエント
リのインデックスとを検索毎に保持しておくインデック
ス・エントリ対応関係保持部を有する管理情報ベーステ
ーブル処理手段と、 を備えていることを特徴とするネットワーク管理情報検
索方式。1. In a network management information search method for searching network management information registered in a management information base table for each managed device, message processing means for performing protocol processing of a network management protocol during communication with a manager, An instance of a managed object is registered, and a management information base table storage unit in which entries are sorted in a lexicographical order using an instance of an object serving as an index, and is specified in a request notified from the message processing unit. Management information having an index / entry correspondence holding unit that holds, for each search, an index that is present, the order of the entries used to respond to the message processing unit, and the index of the entry used to respond to the message processing unit. Network management information retrieval system, characterized in that it comprises a base table processing means.
は、前記メッセージ処理手段から通知されたリクエスト
中に指定されているインデックスと前記インデックス・
エントリ対応関係保持部に保持されているリクエスト中
のインデックスとを比較して一致した場合に、前記イン
デックス・エントリ対応関係保持部に保持されている応
答に用いたエントリの順番を検索対象のエントリの順番
とするよう構成されていることを特徴とする請求項1記
載のネットワーク管理情報検索方式。2. The management information base table processing means includes the index specified in the request notified from the message processing means and the index.
When the comparison is made with the index in the request held in the entry correspondence holding unit, the order of the entries used in the response held in the index / entry correspondence holding unit is compared with that of the entry to be searched. 2. The network management information search method according to claim 1, wherein the network management information search method is configured in order.
は、前記メッセージ処理手段から通知されたリクエスト
中に指定されているインデックスが前記インデックス・
エントリ対応関係保持部に保持されているリクエスト中
のインデックスと一致しないが前記インデックス・エン
トリ対応関係保持部に保持されている応答に用いたエン
トリのインデックスとは一致する場合に、前記インデッ
クス・エントリ対応関係保持部に保持されている応答に
用いたエントリの順番を検索対象のエントリの順番とす
るよう構成されていることを特徴とする請求項1記載の
ネットワーク管理情報検索方式。3. The management information base table processing means is characterized in that the index specified in the request notified from the message processing means is the index.
If it does not match the index in the request held in the entry correspondence holding unit but matches the index of the entry used in the response held in the index / entry correspondence holding unit, the index / entry correspondence 2. The network management information search method according to claim 1, wherein the order of the entries used for the response held in the relationship holding unit is set as the order of the entries to be searched.
は、前記メッセージ処理手段から通知されたリクエスト
中に指定されているインデックスが前記インデックス・
エントリ対応関係保持部に保持されているリクエスト中
のインデックスおよび応答に用いたエントリのインデッ
クスのいずれにも一致しない場合に、前記メッセージ処
理手段から通知されたリクエスト中に指定されているイ
ンデックスと前記インデックス・エントリ対応関係保持
部に保持されている応答に用いたエントリのインデック
スとの辞書的順番を比較して、前記インデックス・エン
トリ対応関係保持部に保持されている応答に用いたエン
トリを検索範囲の限界エントリとするよう構成されてい
ることを特徴とする請求項1記載のネットワーク管理情
報検索方式。4. The management information base table processing means uses the index specified in the request notified from the message processing means as the index.
The index specified in the request notified from the message processing means and the index when the index held in the entry correspondence holding unit and the index of the entry used for the response do not match -Compare the lexicographical order with the index of the entry used for the response held in the entry correspondence holding unit and compare the entries used for the response held in the index-entry correspondence holding unit with the search range. The network management information retrieval system according to claim 1, wherein the network management information retrieval system is configured to be a limit entry.
ッセージ処理手段から通知された検索対象の管理情報ベ
ーステーブルが存在しない場合に、リソース情報を元に
管理情報ベーステーブルを作成する管理情報ベーステー
ブル作成手段をさらに備えていることを特徴とする請求
項1記載のネットワーク管理情報検索方式。5. A management information base table creation for creating a management information base table based on resource information when the search target management information base table notified from the message processing means does not exist in the management information base table storage unit. The network management information retrieval system according to claim 1, further comprising means.
憶されている管理情報ベーステーブルに対応したリソー
ス情報の変化を監視して前記リソース情報に変化があっ
た場合に、前記管理情報ベーステーブル記憶部に記憶さ
れている管理情報ベーステーブルおよび前記インデック
ス・エントリ対応関係保持部に保持されている対応関係
を抹消するリソース状態監視手段をさらに備えているこ
とを特徴とする請求項1記載のネットワーク管理情報検
索方式。6. The management information base table storage unit when a change in resource information corresponding to a management information base table stored in the management information base table storage unit is monitored and there is a change in the resource information. 2. The network management information according to claim 1, further comprising a resource status monitoring unit that deletes the correspondence relationship held in the management information base table and the index / entry correspondence relationship holding unit stored in. Search method.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP7131719A JPH08328983A (en) | 1995-05-30 | 1995-05-30 | Network managing information retrieving system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP7131719A JPH08328983A (en) | 1995-05-30 | 1995-05-30 | Network managing information retrieving system |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH08328983A true JPH08328983A (en) | 1996-12-13 |
Family
ID=15064608
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP7131719A Pending JPH08328983A (en) | 1995-05-30 | 1995-05-30 | Network managing information retrieving system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH08328983A (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004302532A (en) * | 2003-03-28 | 2004-10-28 | Fujitsu Ltd | Snmp agent device |
KR100770920B1 (en) * | 2001-05-26 | 2007-10-26 | 삼성전자주식회사 | Method for managing simple network management protocol based network system using management information base array |
CN112966166A (en) * | 2021-02-07 | 2021-06-15 | 白腊梅 | Method and device for generating and matching indexes of request statement and response statement |
-
1995
- 1995-05-30 JP JP7131719A patent/JPH08328983A/en active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100770920B1 (en) * | 2001-05-26 | 2007-10-26 | 삼성전자주식회사 | Method for managing simple network management protocol based network system using management information base array |
JP2004302532A (en) * | 2003-03-28 | 2004-10-28 | Fujitsu Ltd | Snmp agent device |
CN112966166A (en) * | 2021-02-07 | 2021-06-15 | 白腊梅 | Method and device for generating and matching indexes of request statement and response statement |
CN112966166B (en) * | 2021-02-07 | 2023-09-05 | 白腊梅 | Method and device for generating and matching indexes of request sentences and answer sentences |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6085237A (en) | User-friendly interface for setting expressions on an SNMP agent | |
JP4132441B2 (en) | Data management device for managed objects | |
US6751627B2 (en) | Method and apparatus to facilitate accessing data in network management protocol tables | |
US7409401B2 (en) | Method and system for supporting multivalue attributes in a database system | |
JP4509916B2 (en) | SNMP-based network management apparatus and method | |
US20040078457A1 (en) | System and method for managing network-device configurations | |
US20050160090A1 (en) | Method and system for accessing database objects in polyarchical relationships using data path expressions | |
CN1552139A (en) | Using link state information to discover IP network topology | |
US20020124079A1 (en) | System for inference of presence of network infrastructure devices | |
US20020078005A1 (en) | Apparatus for indirect directory searches and method therefor | |
CN1859216A (en) | SNMP communication system and method | |
WO2016107397A1 (en) | System and method for model-based search and retrieval of networked data | |
US6996553B2 (en) | Fast policy classification for strings | |
US8201144B2 (en) | Method and system for distributing software components | |
US20040158625A1 (en) | System and method for efficient master agent utilization | |
US7272836B1 (en) | Method and apparatus for bridging service for standard object identifier based protocols | |
US10394771B2 (en) | Use of search templates to identify slow information server search patterns | |
JPH08110912A (en) | Device and method for retrieving moving image | |
JP4031947B2 (en) | Query optimization processing device, query optimization processing method, program for causing computer to execute the method, and recording medium storing program | |
JPH08328983A (en) | Network managing information retrieving system | |
CN109101595B (en) | Information query method, device, equipment and computer readable storage medium | |
US6550055B1 (en) | Method and apparatus for cheating an information report resulting from a diagnostic session | |
CN108616385A (en) | The querying method of Simple Network Management Protocol agency, MIB traversal of tree method and system | |
US20060173907A1 (en) | Configuration management system and method using representative object instances | |
JP3520714B2 (en) | Information resource collection method and system |