On 30/05/07, Need Help <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- 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
