On Thu, 2005-12-22 at 20:17 +0200, Makavy, Erez (Erez) wrote:
> 1) in the table_handler function (generated by mib2c.iterate.conf):
> within the case MODE_GET: it goes over the requests list:
> What is in this list: variable_bindings of the same GET request?
Yes.
> 2) How come I don't see any variableN structures registered
> (like in the old ucd API)?
> How does the engine know the types of the columns
It doesn't.
In general, the new v5 APIs typically register a root OID,
and are telling the main agent driving code:
"I'm happy to look after everything that lies in this subtree"
The main SNMP engine does not know which OIDs within that subtree
are valid and which are not - let alone the type(s) of individual
column objects. That's the task of handlers further down the chain.
The "table" helper takes a list of the valid column subidentifiers,
so has some idea about which OIDs might possibly be valid (though
it can't recognised valid/invalid index subidentifiers). But again,
it has no idea about the correct types.
It's basically a pipeline - each helper looks after one aspect
of processing the request, and then passes the requests down the
chain for the bits it doesn't know about.
> 3) When are the (generated) function createEntry and removeEntry called?
> does the iterator already support Row-Create? (guess not?)
The iterator helper itself does not - no.
That's handled by the table-specific handler.
But the template code generated by recent 'mib2c.iterate.conf'
(i.e. 5.2 and 5.3 lines) should include the RowStatus framework.
> 4) I think I finally understood the basis of how this table_iterator
> works, so let ME explain,
> tell me if I'm wrong (please be passiant):
> ------------------
> - The iterator gets a GET request for a specific OID, say OID=X.Y
> (where x is the leaf and y is the suffix/instance).
> - The iterator uses get_first_data_point and get_next_data_point ,
> to iterate through my data structure until it find the request Y.
Yes - that's correct.
This entry is then passed to the (table-specific) handler which
supplies the actual value.
> - for a GET_NEXT request, the iterator HAS to iterate through all the
> entries, and return the instance which is (closest to && higher
> than) the requested Y.(if it exists)
Basically yes.
There's actually a registration flag that can indicate if the
iteration is done in the correct order (i.e. a sorted table).
In which case, the iterator doesn't have to go through *all*
the entries - the first greater one is the one that's needed.
But you've got the basic idea.
Once again, the entry is then passed to the (table-specific)
handler to supply the actual value. As far as this handler is
concerned, it appears to be a GET request in either case.
> - The function that does all this is the
> netsnmp_extract_iterator_context.
No.
All of this searching is done *before* the handler routine is
called, and the relevant rows are squirreled away in private
data structures. The "netsnmp_extract_iterator_context()" call
is used to retrieve this saved row - not to search for it.
But you've definitely grasped the basic idea of this helper.
Dave
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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
