[ First - *please* don't mail me privately, without copying
any responses to the mailing list. I don't have the time
or inclination to offer private, unpaid, SNMP consultancy.
Keep discussions to the list, where others can both learn
and offer advice. Thanks. ]
On 01/08/06, Martin Pasdzierny <[EMAIL PROTECTED]> wrote:
> Dave Shield wrote:
> > A couple of questions:
> > How dynamic is the structure of your table? Is the number (and
> > indexes) of the table rows fairly stable, or are rows being added and
> > removed all the time?
>
> Not 'all the time'.
> We could accept the agent not to work (?) properly while rows are added or
> removed.
It's not really a question of the agent "not working".
It's whether it would be acceptable for a walk to fail to report a
just-created row for some (short-ish) period. Something like:
$ snmpwalk myTable
nyRow.1 = only row
$ create_row 2 "new row"
$ snmpwalk myTable
nyRow.1 = only row
$ sleep 10
$ snmpwalk myTable
nyRow.1 = only row
nyRow.2 = new row
If that sort of behaviour is acceptable, then it's a lot easier to
implement the module. If the agent needs to respond with up-to-date
information immediately, then that has implications as to how the
module should be implemented. (With ramifications regarding
efficiently, particularly for large tables).
Recognising the deletion of a row is less of a problem - if you ask
the underlying system for data from a non-existent row, then it can
simply report back this information. But if the agent has a list of
"all current" rows, then it won't know to ask for data from the
just-created row.
Obviously, this cache would need to time out and be refreshed at some
point - and the cache timeout can be tweaked to match your
requirements. There's no difference in principle between a 1-second
timeout, and a 1-year one. It's just a balance between efficiency
and responsiveness.
> > How "real-time" does the agent need to be (particularly in relation
> > to the rows of the table)?
>
> That's difficult to answer. We don't have precise requirements here.
> We naively thought until now: real-time is never bad :-)
>
> We explicitly *need* externally stored counters, since these are incremented
> *very* often.
That's OK - it's quite feasible to retrieve the current data for a
given row as part of the module handler. I'm more concerned with how
the agent knows which rows currently exist in the table, and whether
this can be cached.
> > If the table is reasonably stable (or you're happy to accept a certain
> > delay before recognising new rows), then one approach would be to use
> > the 'table_tdata' (or similar) helper to cache details of the rows in
> > the table. This could be a complete cache (including all the data for
> > each row), or a "structure cache" where you retrieve the information
> > for a given row at the time of the request.
>
> Is table_tdata similar to table_data ?
Yes - it just uses a more efficient internal mechanism for storing the
table (and provides a cleaner interface to it). In fact, the
'mib2c.table_data.conf' template now uses the tdata helper instead.
Most of what I'm discussing can be applied to the MfD framework as
well. The code is organised in a very different way, and the
nitty-gritty internals are somewhat different too, but the basic
principles are broadly similar. I understand the tdata helper much
better, so am much happier with that framework. But you could
probably use the same ideas with the MfD framework - I'm sure Robert
would be happy to advise you on that.
> How does this caching work ?
If you run
mib2c -Scache=1 -c mib2c.table_data.conf' MY-MIB::myTable
that should give a suitable starting template. The basic idea is
that the module has one routine (myTable_load) which retrieves a list
of the current rows, and builds an internal representation of the
table based on this. The agent then knows what rows exist, and can
decide which row is required for any given request - in both GET and
GETNEXT cases.
The main handler routine is passed the entry for this row, and
retrieves the appropriate column value (either from the cached
information, or directly from the underlying system).
When the agent decides that the cached information is too old to be
useful, it calls 'myTable_free' to release this internal
representation. The next incoming request will then trigger
'myTable_load' to build a fresh copy, and things continue as before.
> Do You mean sth. generic ?
> Or do You mean to explicitly and manually code each copy of the variables
> values
> into some caching structure ?
The mib2c.table_data.conf framework assumes that the cache will hold
all of the data from the underlying table. But it doesn't have to
work that way. As long as the cached structure contains sufficient
information to identify the corresponding row in the underlying
system, then the handler can use this to retrieve the most up-to-date
values for that row.
So at its simplest, the cached table might *only* contain the
indexes and lookup information, with everything else being retrieved
dynamically.
Or you could use a combined approach - with the cached table
including some (relatively static) column information populated by the
myTable_load routine, and other (more dynamic) values being retrieved
at request time.
> We planned (and do so for table_iterator) to use C++.
> To my understanding all that indexing stuff is moreless trivially done by a
> proper use of std::map<my_index_type, my_row_type>.
>
> my_index_type is sth. like an IPADDRESS with a proper 'less' function
> (operator)
> implemented.
OK - then this sort of semi-cached approach is probably well worth
investigating further. If you had a simple compact integer-indexed
table, then it might be easier to forget about caching completely, and
handle the GETNEXT processing yourself. But if it's a relatively
sparse, complex-index table, then I'd be inclined to let the Net-SNMP
helpers deal with that,
and concentrate on providing the appropriate column values.
> my_row_type is sth. like a bunch of references pointing to counters residing
> somewhere else in the application.
Hmmm...
Is this going to be implemented as an AgentX subagent, embedded within
your application? Or is there some form of external API to this
information?
> I send You our current table_iterator based demo to demonstrate the
> integration
> and use of std::map as an attachment.
I'm afraid that I don't really have time to look at your code at the
moment. We're beginning to gear up towards preparing for the new
academic year, and that's really got to take precedence. The
University does pay my salary, after all :-)
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
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
