Re: 'Inter-Tables indexing' and perl

On Sun, 2005-10-16 at 22:28 +0200, Turbo Fredriksson wrote:

> > SNMP (or strictly SMI) ordering is defined to walk tables in
> > column-major order...
> That I have to keep at hand and experiment with, because I
> didn't _see_ it if you know what I mean...

OK - Consider a simple table, with three columns and two rows.
The column numbers are fixed, but you don't know what the
row indexes are.

How would you retrieve the first row of the table?  (just using
GET and GETNEXT requests)  And then the second row?


With row-major ordering, a step-by-step walk would report
	myTable.row1.column1
	myTable.row1.column2
	myTable.row1.column3
	myTable.row2.column1
	myTable.row2.column2
	myTable.row2.column3

In order to retrieve the first row, you'd need two requests:

   - GETNEXT on 'myTable'
        which would give you the index 'row1'
           and the value for column1
   - GET on 'myTable.row1.column2', 'myTable.row1.column3'
        (using the row index you've just found)
           to retrieve the other two column values.

You'd need the same to retrieve the second row:

   - GETNEXT on 'myTable.row1.column1'
        which would give you the index 'row2'
           and the value for column1
   - GET on 'myTable.row2.column2', 'myTable.row2.column3'

So that's four requests - two GETNEXT and two GET



With the column-major order of SNMP, a step-by-step walk gives:

	myTable.column1.row1
	myTable.column1.row2
	myTable.column2.row1
	myTable.column2.row2
	myTable.column3.row1
	myTable.column3.row2

You can retrieve the first row with a single GETNEXT request:

   GETNEXT myTable.column1 myTable.column2 myTable.column3
      will return the three required values (plus the index 'row1')

These results can then be used for another GETNEXT request:

   GETNEXT myTable.c1.r1  myTable.c2.r1  myTable.c3.r1

which will return the three required values (plus the index 'row2')

And so on.
Each row can be retrieved using a single request, and the
results can be used as the input for the next request.


OK?




> > Walking an SNMP table would *not* (normally) display the index
> > values.
> 
> That was a little of a surprise though. I was hoping it would...

Why?
The index values are included in the OIDs anyway:

	GETNEXT myTable.col1
	RESULT  myTable.col1.row1 = value1

gives you *both* the index ("row1") *and* the value ("value1")
at the same time.  Two values for the price of one.

If the index were defined as an accessible column, then this would
become:
	GETNEXT myTable.index
	RESULT  myTable.index.row1 = row1

So you've now got the same index information ("row1") *twice*.
Once in the OID, and once as the value.   That's a waste.

OK - it does mean that the application developer has got to
look at the OID in order to extract the index value.  But that's
not too difficult, and saves network traffic in the long run.
Don't be so damn lazy!  :-)


Dave

PS: Glad you got the bogus table results sorted out OK.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users