Difference between revisions of "Template:FAQ:Coding 16"
m (5.4 release synchronisation) |
m (Latest FAQ revision - preparing for 5.5 release) |
||
| Line 6: | Line 6: | ||
--> | --> | ||
The first thing to realise is that the <CODE>'get_first'</CODE> and <CODE>'get_next'</CODE> | The first thing to realise is that the <CODE>'get_first'</CODE> and <CODE>'get_next'</CODE> | ||
| − | hook routines are concerned with processing a single request, not | + | hook routines are concerned with processing a single SNMP request, not |
with walking the whole table. A full <CODE>"snmpwalk"</CODE> command will typically | with walking the whole table. A full <CODE>"snmpwalk"</CODE> command will typically | ||
involve a series of individual 'GetNext' requests, and every one of | involve a series of individual 'GetNext' requests, and every one of | ||
Latest revision as of 19:49, 20 July 2009
The first thing to realise is that the 'get_first' and 'get_next'
hook routines are concerned with processing a single SNMP request, not
with walking the whole table. A full "snmpwalk" command will typically
involve a series of individual 'GetNext' requests, and every one of
these will trigger a separate 'get_first/get_next/get_next/....' cycle.
It's usually more efficient to use 'snmptable' which will
walk each column in parallel (as well as displaying the results in a
more natural manner).
Secondly, the iterator helper was originally designed to handle
unsorted data, so will look at every row of the internal table for
each request. If the data is actually held in the correct order,
then it's worth setting the NETSNMP_ITERATOR_FLAG_SORTED flag:
iinfo = SNMP_MALLOC_TYPEDEF(netsnmp_iterator_info); iinfo->flags |= NETSNMP_ITERATOR_FLAG_SORTED;
This will help the situation somewhat.
But the iterator helper is inherently a relatively inefficient mechanism, and it may be worth looking at one of the other helpers, particularly if the data will be held within the agent itself.
