Hi David, I am looking seriously at this possibility. I still have some
questions:
You suggest I will change the following call:
netsnmp_extract_table_row_data(request);
With a call to the external DB to retrieve the information. So this means
that the indexes for that call should be retrieved from request:
Which has the type:
typedef struct netsnmp_request_info_s {
/**
* variable bindings
*/
netsnmp_variable_list *requestvb;
I suspect that I have to look to the variable bindings to extract the tables
indexes.
However as far as I now a single request may have several var binds. How can
I tell which var-bind one should the indexes be retrieved from?
(If at this stage each request has only one var bind then I am all set).
Thanks,
Shuki
-----Original Message-----
From: Dave Shield [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 29, 2005 5:53 AM
To: sasson, shuki
Cc: [email protected]
Subject: Re: Cannot find an adquest mib2c configuration file for travesing
lar ge tables.
On Wed, 2005-09-28 at 16:23 -0400, sasson, shuki wrote:
> I need a template that will supply me the required index as a
> parameter for get_next. So for example if a getNext request for index
> 3 is queried one should be able to retrieve the next data point from
> the external DB. It will be a single function all instead hundred of
> thousands as it is with the MFD and the Iterator.
You are exaggerating somewhat, methinks.
The iterator framework has just three relevant functions
(although it's not particularly efficient, so wouldn't
be a good choice for this scenario).
Even the MfD framework doesn't have "hundereds of thousands"
of functions. I'm not the greatest fan of this helper, but
the number of distinct functions is linked to the number of
column objects, rather than the number of rows.
> Questions:
>
> 1. Do you know of an existence of such a template (where the get_next
> routine will be supplied with the index)? And where can I find it?
There isn't a mib2c template that precisely matches your requirements.
The best suggestion I can make is to start with one of the existing
ones, and strip it down a bit.
Personally, I'd suggest using either 'mib2c.container.conf' or
'mib2c.table_data.conf', and adjust it as follows:
init_myTable():
- delete mention of 'netsnmp_create_table_data' or
'netsnmp_container_find'
- register the table using 'netsnmp_register_table()'
(instead of the table_data/container versions)
handle_tzIntTable():
- replace the call to 'netsnmp_extract_table_row_data' or
'netsnmp_container_table_extract_context' with a query
of the underlying subsystem for the specified row.
- duplicate the MODE_GET block with a similar MODE_GETNEXT
block, using the appropriate query of the underlying system
(Similarly for the SET handling, if appropriate).
If you need to support row creation/deletion, you'd need to adjust
the {create,remove}Entry routines as well, to interface with
the underlying subsystem.
> 2. Do you have any idea how to deal with such large external tables
> using Net-SNMP?
See above.
That'll probably be as efficient an approach as you can get
with this agent.
Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
