Hi, Dave

I've implement the code using mib2c.table_data.conf. Another question,
If the data is not belong to the agent, I mean the data will change 
dynamically, is there any chance to reload the data again when I want to get 
the data?

-----邮件原件-----
发件人: [email protected] [mailto:[email protected]] 代表 Dave 
Shield
发送时间: 2009年4月2日 16:23
收件人: Kang Chen
抄送: [email protected]
主题: Re: 答复: code size generating by mib2c.mfd.conf

2009/4/2 Kang Chen <[email protected]>:
> I used to use mib2c.iterate.conf, but I found the efficiency of this 
> framework is too slow.
> So, how about the efficiency of mib2c.table_data.conf?

Regardless of the template that you choose,  there are two (or possibly
three) basic approaches to processing a table request.

One is to search through all the rows of the table, until you find
the appropriate row for the request being processed.   This is the
approach used by mib2c.iterate.conf (and the iterative style of MfD).
It has the advantage that the underlying subsystem doesn't
need to know anything about the indexing used for the MIB.
It has the disadvantage that it's relatively inefficient.

The second is to hold an internal cached representation of the table
within the agent.   This is the approach used by mib2c.table_data.conf
(and the non-iterative style of MfD).
    Because the agent knows exactly which rows are valid, it can
determine the appropriate row directly, and so is much faster.
The main disadvantage is that the agent is working with a cached
version of the table data, which is inherently somewhat stale.

(The third approach is to have the underlying subsystem return
the appropriate "next row" for each request.   This is of comparable
efficiency to the internal cache approach, but does require the
subsystem to know about the MIB index ordering).

OK?

Dave

------------------------------------------------------------------------------
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to