Hi Robert, Dave, and the rest of the list, Thanks for the additional information. I'm feeling that I'm starting to get to grips with NetSNMP. I found very helpful seeing the calls' flow by running snmpd -Dverbose:tableName -f and seeing how the agent obtains the data and then process it to answer the query.
I think at present the way I'm handling the acquisition of the data is a little inefficient: my data lives in a memory database and I obtain it every time an snmp request comes though by doing a SELECT * FROM TABLE. Of course this data gets cached at the agent. What I haven't figured out is how to tell the agent to fetch the row from the database that contains the snmp requested data. Database table data is indexed by row numbers starting from 0. So if somebody looks for tableAttribute.10 I haven't worked out how to get the snmp code to fetch only the specific row from the database table (i.e. SELECT * FROM DB_TABLE WHERE rowNum = snmpRequestedRowNum) instead of doing the SELECT *. At present it doesn't matter as my Database is in memory and the size of the tables is small. But I'll research it some more for the sake of not writing dumb code :-) I'm attaching an archive, which may get dropped by something in the way, that contains a very, very simple table example with 3 read only columns of integers. I understand this is oversimplified but it may help people who were in similar positions like me: not experts, a bit overwhelmed but wanted to learn more. The archive contains a small MIB and a html file with the procedure I followed. There may be inaccuracies there since I'm not an NetSNMP expert (I can't stress that point enough!). But I'll submit it here and if people find it inaccurate can hopefully let me know. Guys, once again many thanks for answering the posts and pointing out the right direction. Your help is much appreciated. Thanks again, --a On Tue, Jul 20, 2010 at 9:44 AM, Dave Shield <d.t.shi...@liverpool.ac.uk> wrote: > 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 >
netSnmp_tables_for_dummies.tar.bz2
Description: BZip2 compressed data
------------------------------------------------------------------------------ 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
