Well, it seems there are actually about six "sparse" tables in my MIB which are
extensions of Table1, so I will need to look into this a bit more to figure out
how to approach this correctly.
Now, it would be great to hear from Robert on this issue since he is familiar
with the MfD configuration, but in the meantime, perhaps you could recommend
another configuration file in which you are familiar which would provide me the
base to make the changes you are recommending.
The only reason why I chose the MfD configuration is because this was the only
one which came with a complete tutorial explaining how the code functioned as
well as which area of the code was required to be updated. If there is another
widely used configuration file then I would like to play around with that one
as well to get a better feeling of different kinds of approaches which can be
used in NetSNMP.
If you do recommend another configuration file, perhaps you could give a one
paragraph description indicating which procedures need to be updated to perform
certain functions.
Dave Shield <[EMAIL PROTECTED]> wrote: On 30/05/07, Need Help wrote:
> Table1 is the "main table" while Table2 is a "sparse" table. Table2 can be
> thought of as providing additional column information to extend Table1 and
> Table2 is indexed by the same table index defined by Table1.
>
> What would be the best way to store this information within NetSNMP?
I wouldn't want to claim that this necessarily the "best" way, but there
two approaches spring to mind. Which one I'd choose would depend
on how sparse the second table was (and the size/overheads of the
two tables).
The first approach would be to have a single data structure to represent
the combined row - containing fields for the column objects from both tables,
and a flag or similar mechanism to indicate whether this particular row
was valid in the second table.
The same internal representation could then be used for both tables,
with the table-specific code selecting the appropriate fields from the
common row structure. This involves some overheads - both unused
fields in the data structure for the sparse rows, and additional processing
to skip these "gaps" in the second table. But it's probably the simpler
concept.
The other approach is to have two separate representations for the two
tables, with distinct per-row data strucutes. So as far as the agent is
concerned, they are effectively two completely independent tables.
But the two tables would share a common "load" routine, which would
populate both tables at the same time (from the same underlying data).
That's actually sufficient to report a consistent view of the two tables.
> Currently, I am using the "mib2c.mfd.conf" configuration file to generate
> code using mib2c.
I have no idea how this would be implemented in the MfD framework.
I'll leave it to Robert to provide specific advice on that mechanism.
> Also, knowing that Table1 and Table2 are defined separately, but are
> related, then should the "snmpwalk" command display all data defined in
> Table1 and Table2 at the same time by issuing only one "snmpwalk" command
> ...... or should an "snmpwalk" command be issued for Table1 and then again
> for Table2 separately?
That up to the person issuing the command.
The snmpwalk command doesn't actually know anything about the
structure of the individual tables - let alone that they are linked.
Snmpwalk simply does a repeated GETNEXT until it runs off the
end of the requested subtree.
If you issue "snmpwalk Table1; snmpwalk Table2", then this
will walk the two table individually.
If you issue "snmpwalk myGroup', then this will walk the subtree
rooted at "myGroup", including both tables (plus anything else in
that subtree).
But snmpwalk doesn't care either way.
Dave
---------------------------------
Looking for a deal? Find great prices on flights and hotels with Yahoo!
FareChase.-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
