On 10 April 2011 16:46, Zimmer Hu <[email protected]> wrote:
> Right, I took it for granted that the varbinds for "each requests" is for
> the columns of "each row". There may be holes in table so this may not be
> the case. Nevertheless, is this assertion true for the "full-filled" table
> (a varbind in one requests list == a request ==a column in a row)?
Not necessarily.
The list of varbinds in the incoming request depends purely
on what the original client application asked for.
It is perfectly possible for the client to request two column values
from one row of a table, another column value from a different
row of the same table, a value from a completely different table
and a scalar instance - all in the same request.
I can't think *why* the client should send such a strange
assortment of values - but that doesn't matter. It's not for
the agent to restrict what it's prepared to report. It should
simply provide the values requested.
So in the case (for example) of
snmpget .... myName.1 myNumber.3 myEmail.1
the iterator helper would work through the list of rows in myTable,
and associate the data structure for row 1 with the first and
third varbinds, and associate the data structure for row 3
with the second varbind.
The MIB handler can then retrieve this associated row data
structure from each 'request' link in the chain, and be confident
that this contains the relevant data for that varbind.
It doesn't matter how many other column objects there are,
or whether there are holes in the table. The 'request' list
is purely concerned with the varbinds from the incoming request.
Dave
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
