Thanks Dave. That really helped.
Observed another weird agent behavior.
The agent seems to call GET for each column with the same instance ID even
when the first call failed to return an instance.
For example, the SET request was sent for adding 4th row to the table,
which doesn't exist. So the agent called GET for exampleTableEntryRS.4
, exampleName.4,
and exampleId.4 even though my set request is as follows:
>snmpset -Ir -c private -v2c localhost exampleName.4 s "str"
>exampleTableEntryRS.4
i 4
I expected the agent to stop issuing GET requests for other columns as soon
as it knows that the instance didn't exist (which is what I returned from
my var_get* routine).
Thanks Dave. Much appreciated.
Pal
On Tue, Jan 1, 2013 at 5:02 AM, Dave Shield <d.t.shi...@liverpool.ac.uk>wrote:
> On 31 December 2012 19:34, pal snmp <pals...@gmail.com> wrote:
> > I create a final row in the back-end when the ACTION method for
> > exampleTableEntryRS is invoked. However, the ACTION method for
> exampleName
> > is not getting invoked until after the ACTION method for entryRS is
> invoked.
>
> That's quite possible.
> The order in which varbinds are passed to the handler routines is
> implementation dependent. It probably depends on the order in
> which they are specified in the incoming request, but since SET
> requests must be handled "as if simultaneously", ypu cannot rely
> on this.
>
> If you look at the description of SET handling in the file AGENT.txt,
> you'll see that this suggests processing the "create row" varbind in
> the RESERVE2 pass (and hence releasing it in both FREE and UNDO)
> for exactly this reason - so that the data structure for the new row is
> available for the other column variable(s) in the ACTION pass.
>
> Alternatively, one of the changes introduced with the new v5 helper-based
> model, was for all the varbinds for a particular table to be processed
> together, so that the MIB handler routine could work through the full list
> of (relevant) varbinds as required. For example, go through once looking
> for row creation requests, and setting up the necessary data structures.
> And then process the list again to apply the new assigned values.
>
>
> > Is this really expected? Why would the agent not call ACTION methods for
> the
> > preceding columns before calling the entryRS column?
>
> How do you define "preceding columns"?
> How is the main agent processing code (which doesn't really know
> much about individual OIDs, other than what code should be called
> to process them), meant to know which OIDs refer to a RowStatus
> object, and hence should be processed first?
> Or to another object that might serve a similar purpose in a particular
> table?
>
>
> The table-specific processing belongs in the MIB handler code,
> so this needs to be ready to accept varbinds arriving in any order.
>
> Dave
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
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
