> And the MfD framework is a completely different beast altogether.
>The description above is really only aimed at the handler-based
>iterator approach.
Thanks Dave for your explanation.
As you can see, I do get confused by those examples and my code (mfd). What
I tried to do is to merge these codes together to have them work which is
due this week. I'm reading source code try to finger out how
netsnmp_table_iterator_helper_handler works and why mfd works in another way
(inject_before)? Interesting, I will follow up this thread when I have my
project done.
On Thu, Apr 7, 2011 at 4:05 AM, Dave Shield <[email protected]>wrote:
> On 7 April 2011 00:48, Zimmer Hu <[email protected]> wrote:
> > So, could somebody tell me what exactly netsnmp_extract_iterator_context
> > returns?
>
> You need to take a step back, and think about the general principles
> of how the agent processes a request for a table entry.
>
> There are essentially two tasks involved:
> - identifying the relevant row of the table for a given request,
> - and then looking at the particular column field(s) for that row.
>
> Most of the table-related helpers are concerned with the first
> aspect of this processing. They will identify the appropriate
> row, and pass this in some way to the main handler routine,
> which looks after the second part.
>
> In the case of the iterator helper, the call
> 'netsnmp_extract_iterator_context'
> is that "some way" mentioned above. This is the mechanism provided
> for the handler to retrieve the appropriate row for this request.
>
> The value is whatever was returned from the 'get_first' and
> 'get_next' hook routines via the 'data_context' parameter.
>
>
>
> > From code in nsVacmAccessTable.c and nsLogging.c:
> > I see first insert data_context into cache handler in SET
> > and then extract it in GET.
>
> That's not strictly accurate.
> In particular, it's not "first SET, then GET".
>
> Remember that the MIB handler will be called for each incoming request.
> So the style (and ordering) of these calls will depend on what requests
> are sent to it.
>
> If the agent receives a GET (or GETNEXT) request, then it will
> identify the appropriate row (using the 'get-first'/'get_next' hook
> routines), and then invoke the handler in GET mode.
> The handler uses 'netsnmp_extract_iterator_context' to retrieve
> the relevant row structure, and returns the appropriate column
> value(s).
>
> If the agent receives a SET request for an existing row, then it will
> again identify the appropriate row (using the 'get-first'/'get_next'
> hook routines), and invoke the handler in SET mode.
> The handler uses 'netsnmp_extract_iterator_context' to retrieve
> the relevant row structure, and updates the appropriate column
> value(s).
>
> But if the agent receives a SET request to create a *new* row,
> then the 'get_first'/'get_next' hook routines won't find an
> appropriate (existing) row. The handler is still invoked in SET
> mode, but 'netsnmp_extract_iterator_context' will return nothing.
> The row is only created as part of processing the RowStatus column.
>
>
> Now, remember that SET is a multi-pass process:
> Reserve1, Reserve2, Action, Commit
> (ignoring the error handling for now).
> The get_first/next hook searching is only done once (during Reserve1),
> since the row involved isn't going to change. The following passes
> all use the same 'data_context' value from the hook routines.
>
> But when creating a new row, the hook routines didn't return a
> 'data_context'
> value - the row structure was created by the RowStatus column code.
> So it's now *this* code which needs to make sure that the newly created
> row is made available to the following passes.
> Hence calling netsnmp_insert_iterator_context()
>
> If you check the nsVacmAccessTable and nsLogging code, you'll
> see that this routine is *only* invoked as part of processing
> CreateAndGo or CreateAndWait assignments.
>
> The netSnmpHostsTable uses a different mechanism for
> passing the data between Reserve1 and the following passes,
> so only uses netsnmp_extract_iterator_context() in the GET
> and Reserve1 passes. Reserve2, etc don't call this routine,
> so the row creation code doesn't need to associate the new row
> structure with the request in this way.
> And the MfD framework is a completely different beast altogether.
> The description above is really only aimed at the handler-based
> iterator approach.
>
>
> OK?
>
> 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
