On 13 July 2010 16:06, Robert Story <rst...@freesnmp.com> wrote:
> I'm sure Dave will chime in and defend some of the other options
> real soon now. :-)
Sorry for not chipping in earlier, and I'm glad to hear that you've
managed to get things working. To echo Robert - yes, please
do write up your experiences.
We are acutely aware that the documentation for this project
is a major weakness, and the more information there is for those
needing to develop private MIBs, the better.
My thoughts on the choice of table framework to use are probably
a little late for you now, but I'll post them anyway - if only so that
these musings are available for those who come after.
I'd want to separate the question of what framework to use when
implementing a MIB table into two - how to hold the data that
should be reported, and how to package this data into an SNMP response.
These are essentially the interfaces between the agent and the
underlying system being managed, on the one hand, and between
the agent and the SNMP manager on the other.
This can also be looked at another way - there are two basic
tasks involved in processing an SNMP request for a MIB table object.
These are identifying which row of the table is required, and
returning (or updating) the relevant column value for that row.
Much of the work of the agent-subsystem interface is typically
concerned with identifying the appropriate row, and this usually
returns the full set of data for that row.
For most code frameworks, this is handled by the chosen table
helper, and the MIB-specific code simply needs to extract the
particular column value(s) for the current request.
Looking at the task of identifying the appropriate row first,
there are three basic approaches:
- hold a local copy of the table within the agent,
and let the helper choose the row.
This is the most efficient, but using a local cache
typically means that the data is slightly out-of-date.
- provide the helper with a list of current rows,
and let it choose the appropriate one.
This can give more timely information, but is significantly
less efficient - particularly for large tables.
- pass the request through to the MIB-specific handler,
and let this (or the underlying subsystem) choose the row.
This is the most flexible, but involves more work (and code!)
within the MIB handler itself.
In terms of single-handler frameworks, these correspond to the
mib2c templates table_data, iterate, and raw-table respectively.
The distinction between these three and Robert's MfD framework,
lies primarily in the second task - extracting the requested
column(s). These three frameworks generate a single handler
routine, which is provided with the relevant row structure(s)
for a given SNMP request, and should return the appropriate
column value(s).
With the MfD framework (which can use either a local cache or the
iterator approach to the agent-subsystem interface)), looping
through the list of varbinds and identifying the appropriate
column is handled by automatically generated (MIB-specific) code.
The implementor-visible code is essentially a series of individual
routines - each responsible for returning the value for a given
column. So these routines will typically be very very simple -
possibly only a couple of lines of code.
Operationally, the choice of agent-subsystem interface style
is the more significant one. Whether you use a single handler
(table_data,iterator), or a collection of simple routines (MfD)
is more of a stylistic preference
[Robert - I hope you feel that's fair and accurate.
Feel free to correct my more blatant misrepresentations]
Dave
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
