A question

[Frank Fock]

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