2010/8/25 Dave Shield <d.t.shi...@liverpool.ac.uk>
> On 25 August 2010 09:40, AC. <achuan...@gmail.com> wrote:
> >> > I see that the command "snmptable" use the "getnext" to retrive the
> >> > information,
> >> > but is that correct cause I don't need the information of table B?
> >>
> >> Please consider the following question:
> >> - How does the snmptable command know when it has
> >> received the last row of table A?
> >
> > I also think so, but It is a waste of resource, especilly in my
> condition.
>
> It's not a question of "waste of resources".
> This is fundamental to how walking SNMP tables works.
> You will *ALWAYS* run off the end of one table, and
> on to the next. That's the only way that the client command
> knows that it has reached the end of the table.
>
>
>
> > There are 3 main contact function in my code.
> > 1. handler
> > 2. get_first_data_point: It wll get all the data of the table
> > 3. get_next_data_point
> > When I typed "snmptable" to get table information, I find the handler was
> > contacted servel times,
>
> Yes - once for GETNEXT request.
> (Which is typically once for each row of the table)
> *ALL* table handlers work this way - they are inevitably
> called once for each incoming request. You cannot
> get away from that.
>
>
> But you've suddenly changed the question.
> You are no longer talking about switching from the table A
> helper to table B. You now seem to be concerned about
> how often the table A code is being called.
>
>
The cause I change the question suddenly is
1. My tables are big sometimes.
(e.g. The table of disks, there are min. 0 to max. 192 disks in my system,
and there are 20 collumn in one row.)
2. When the table B was the big one and I wanna get table A,
it wastes time and resource to get a *BIG* table B that I don't neet it.
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
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
