A question

[Alex Finogenov]

Frank,

Why? RFC1905 in Section 4.2.2 states:

...
If the processing of any variable binding fails for a reason other
   than listed above, then the Response-PDU is re-formatted with the
   same values in its request-id and variable-bindings fields as the
   received GetNextRequest-PDU, with the value of its error-status field
   set to `genErr', and the value of its error-index field is set to the
   index of the failed variable binding.

I believe that the failures I am describing fall under this category, so it
is OK to return GenErr. It is obviously an agent's implementation detail
what the agent does after sending the GenErr reply.

Thanks,
Alex



> -----Original Message-----
> From: Frank.Fock____t-online.de [mailto:Frank.Fock____t-online.de]
> Sent: Monday, November 19, 2001 3:16 PM
> To: Alex Finogenov
> Cc: agentpp-dl____agentpp.com
> Subject: Re: A question
> 
> 
> Alex,
> 
> Caution! Please note that an agent MUST NOT return any error on a
> GETNEXT or GETBULK operation! This is a requirement of SNMP.
> Thus, it is perfectly correct, how your agent is currently operating.
> 
> The extra CPU time has to be spend for be compliant to the SNMP
> standard. It would make much trouble in a management system, if you
> return an error in a walk. How should the management system guess
> the next OID that it can use to proceed successfully in a walk? This
> will take much more time in the management system than skipping those
> objects you cannot retrieve within your update method.
> 
> Best regards,
> Frank
> 
> 
> Alex Finogenov wrote:
> 
> > Frank,
> >
> > The problem is mostly with GETNEXT & GETBULK, and I do 
> believe that a lot of
> > CPU time and other resources are wasted. The reason for 
> this is that if the
> > process of accessing persistent values in the overloaded 
> MibTable::update()
> > fails and the respective table rows are not populated, the 
> agent continues
> > to walk the MIB through other tables until it either 
> succeeds in loading a
> > table, or hits the EndOfMib. This will potentially involve 
> retrieving
> > database objects that have nothing to do with a particular 
> SNMP request, and
> > thus will result in pure waste of all resources (CPU. 
> network, etc.) In case
> > of access failure to the entire database (i.e. subsequently 
> to every table),
> > this may slow down the agent's response time significantly. 
> Thus I think it
> > is important to be able to quit after a failure in the 
> update() ASAP.
> >
> > A similar MibTable::update() failure for a SET request is 
> not a matter of
> > concern, because as you mentioned, in MibTable::update() I 
> set the error and
> > check it in my implementation of the overloaded
> > MibTable::prepare_set_request(), whose interface DOES allow 
> to return an
> > error. Even in the worst case this situation may not result 
> in any serious
> > waste of resources.
> >
> > Maybe it does make sense to have a "way out" in 
> MibTable::update() to return
> > a failure, at least for the sake of GETNEXT and GETBULK?
> >
> > Thanks,
> > Alex
> 
>