Re: get-next question

Dave Shield <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <CAKoMtGY3eaQcO2RcMBLvip2UjZ3FuFWpDxey9mM31JHa6yzPcw@mail.gmail.com>
On 19 October 2012 18:50, Joan Landry <[email protected]> wrote:
> When I walk a column in one table, and that table is empty I see that net-snmp is
> calling handlers for tables that are next in the oid table sequence.

That is correct.


> Is there a reason why net-snmp goes to the next table - when a next
> was requested for a given column in one table.

No - a GetNext request was issued for a given OID
(which just happens to fall within a particular table).

The defined behaviour of the GetNext request is that
it will return the next valid instance that the agent supports.
Not the next instance within a particular range or within the
same table - the next valid instance.
   The agent is working as expected.

   The SNMP protocol has no idea about the logical structure
of MIB information - that's why it can work even without MIB
files being available.
  (That's also why "snmpwalk" will always issue one "extra"
GetNext request, and discard the result)


> This can take a long time to respond if the subsequent
> tables are also empty.

If a table is empty, then processing requests for it ought
to be quick, surely?   If that's taking a long time, then this
is probably the thing to address.

Dave

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.