Fair enough on "helpers"
I am looking for some more clarification.
Is there particular stages (kind of state machine) of different
"*chain* of handlers".
How does we come to know which handlers need to "USE"
Could you explain me a little bit about the "handler concept"
Thanks and Best Regards,
Sanjay Kumar
Dave Shield wrote:
2009/4/9 sanjaykumar <sanjay.ku...@globaledgesoft.com>:
Now we can go ahead with "Helpers" concept.
OK. It's time for your history lesson....
Way back in the mists of time, when the first Net-SNMP release
was made, one of the most obvious changes from the previous
UCD (v4) code was the introduction of "MIB handlers".
At first sight, these seemed broadly similar to the earlier
"var_xxx()" API - this is the routine that's called to process
a request for a particular group of MIB objects (a table,
group of scalars, whatever). But there were a couple of
significant differences between the two styles.
The more visible change was that the v5 handler would be passed
*all* of the relevant varbinds from the request, rather than dealing
with these one at a time.
But the more deeply significant change was that the handler
processing actually invoked a *chain* of handlers - each one
performing some set of actions, and then passing the request
on to the next handler in the chain (similar to the idea of a
Unix pipeline of commands). The visible "MIB handler" is
simply the last link in this chain.
The preceeding handlers are each designed to take core of a
certain aspect of the overall processing - handling it automatically
before the request reaches the eventual MIB handler. This helps
by removing functionality (and hence code) from the stuff that the
MIB implementor needs to worry about. These intermediate
handlers are typically called "helpers" (to distinguish them from
the main MIB handlers)
For example - there is a helper ("table") which deals with table
indexes. It knows what index types are used for that table, and will
unpick the incoming OID to extract the various index values. These
are then made available to handlers further down the chain - they can
work with the index values directly, without having to decode the OID.
As another example, there are several handlers (including the
container-based 'table_tdata' helper) that hold a list of which rows
are valid within the table. They can therefore look at a GET or
GETNEXT request, and identify which is the appropriate row to
use (if any).
All subsequent handlers can then work with that row directly.
They don't need to worry about whether the row is valid or not,
or whether this was a GET or GETNEXT request. That's been
handled by the table_tdata (or similar) helper.
Note that table_tdata doesn't know anything about what values
might actually be in this table (or even details of the data structure
that's used to store the values of each row). It simply holds a
collection of "black box" data structures - one for each row. It
knows enough to decide which of these boxes is appropriate for
a given request - it's then up to the later handlers (particularly the
end MIB handler) to do something sensible with it.
As a third example, there a helper which is purely concerned with
managing caches and cache timeouts. For each incoming request,
it decides whether the cache is sufficiently recent to be useful, and
calls a suitable (user-provided) "load" routine if necessary.
It doesn't care what might be in that cache, where the information
comes from, or what MIB objects it will be used for. It doesn't even
care whether this relates to a table, or to scalar object(s). It's
simply concerned with whether or not to re-load the cache contents.
The MIB-specific code *does* need to know how to load the cache,
and how to interpret the contents. But it doesn't need to worry about
*when* to reload the cache - this is dealt with by the cache helper.
I will admit to being somewhat sceptical about this framework when
Wes first proposed it. I was concerned that the processing overheads
of passing requests down the handler chain might be too great.
But time has proved me wrong - the mechanism has turned out to
be extremely powerful, and has made it *so* much easier to implement
new MIB modules.
Does that explanation make sense?
Dave
|
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
