Hi Robert:
Thanks for the enlighten information.
It looks like the third approach is feasible. The MIB may not released
yet. Since my agent works for the basic (for the case of index=1 if an index of
that table is added in the MIB). My agent currently returns value for each
table entry for snmpwalk - only one set of data. What is the possible approach
to enhance the current agent to return multiple "set" of data in one walk? The
table is defined as variable4 {}. I think to define the multiple sets of data
for that table, I need to add the "abcTableSetIndex" in that variable. This
number is variant - meaning it depends on how many set of data the agent will
poll out from the share memory. How do I specify the oid for each table entry
for each different set of data, since the number of set is unknown at the time
this variable is defined? These sets of data will be fetched from a link list
in the share memory do I add an iteration outside the current var_abcTable()
routine or use an existing snmp library to handle the iteration? My net-snmp
version is 5.0.6. Thanks in advance for the direction.
Thanks,
Jim
-----Original Message-----
From: Robert Story (Users) [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 18, 2004 9:51 PM
To: Jim Su
Cc: [EMAIL PROTECTED]
Subject: Re: multiple set of table handling
On Thu, 18 Nov 2004 14:28:15 +0800 Jim wrote:
JS> The process supplied me one
JS> "set" of value for that table at one time. Now the number of application
JS> (and results) increased so there are many different "set" of values for
JS> that table are generated (said x "set" values for that table) and my
JS> agent need to response to the query (of snmpwalk) to show all the x
JS> "set" values for that same table.
Ahhh, gotcha. Well, I'm sorry to say that the agent won't be able to do what
you want.
The closest you can get would be to register the table for multiple contexts.
This means that:
(a) you need to know the number of contexts ahead of time. Theoretically you
could register and deregister them automatically, but that might get messy.
(b) you will need to issue a separate snmpwalk command for each context.
The alternative would be to re-design the table (if the MIB hasn't already been
released), or define a new table with an additional index to differentiate the
sets of data. Then a single walk would work for all the data.
--
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-users>
You are lost in a twisty maze of little standards, all different.
