Discussion:
Large MIB table - do not want cache or copy
(too old to reply)
Joe Lorenz
2015-12-15 14:44:41 UTC
Permalink
I'm trying to implement a MIB defining a very large (read-only) table
(~250k rows).
My data source API already provides get/get-next in correct order and
data format. I expected it to be straightforward to map the appropriate
handler actions, but I'm struggling with the details.

It seemed like mib2c.raw-table.conf would be the right way to go,
avoiding any caching or copying of the entire set of table data (which
is a requirement). What I've been unable to find is any actual example
that uses this mib2c config. I'm lost on what needs to be done with the
various structures (indexes, etc.) especially for the get-next.

The table is read-only. I have no need to implement row add/remove.
I'm using version 5.7.2.1 of the software collection.

If anyone can point me to an example or otherwise provide some hints,
that would be most helpful.

Many thanks,
-Joe

------------------------------------------------------------------------------
Joe Lorenz
2015-12-16 14:59:32 UTC
Permalink
OK, I finally figured it out on my own. I'll post my findings here
for reference by my future self (who will undoubtedly forget) and
anyone else it might aid.

---

Using mib2c.raw-table.conf for a large table you have ordered access
to but don't want copied or cached into memory.
--------------------------------------------------------------------

- I didn't need to handle row create/remove, so I have no notes on
that (sorry).
Your table index is handed over in the 'indexes->val' union,
and size in 'indexes->val_len'. Suppose your defined table
index is an OCTET STRING of size 6 (MAC address). Then
'indexes->val_len' should be 6 and 'indexes->val.string' array
has your requested index.
If your defined table has multiple indexes, then the second one
will be in 'indexes->next_variable' and so on.

(the rest is for getnext only:)
If a table walk is happening, no index is passed and
'indexes->val_len' will be 0. This means retrieve the first
row. Once you do, be sure to set 'indexes->val_len' to the
right size and populate 'indexes->val' with the index of the
retrieved row (if there was one retrieved). You'll need to do
that for any row retrieved (not just the first).
You do not need to worry about memory storage for
'indexes->val'. Those members are pre-loaded to point to the
'buf' array in indexes. That array is 40 bytes. If your index
is larger than that... I'm not sure what you do.

- Once you've retrieved your row data, you need to allocate the
struct the stub code defined for you (something like
'myFooTable_entry') with:

row = SNMP_MALLOC_STRUCT(myFooTable_entry);
netsnmp_assert(row);

Fill that in with your retrieved data and return the 'row' pointer
(or NULL if no row could be retrieved).
You need to
SNMP_FREE(table_entry);
after each
switch(table_info->colnum)
statement. Otherwise you'll leak memory.
In the MODE_GETNEXT case, the stub code sets error
SNMP_NOSUCHINSTANCE if there was no 'table_entry' returned.
This is apparently wrong. I had to change this to set error
SNMP_ENDOFMIBVIEW for all columns.

---------
I'm trying to implement a MIB defining a very large (read-only) table
(~250k rows).
My data source API already provides get/get-next in correct order and
data format. I expected it to be straightforward to map the appropriate
handler actions, but I'm struggling with the details.
It seemed like mib2c.raw-table.conf would be the right way to go,
avoiding any caching or copying of the entire set of table data (which
is a requirement). What I've been unable to find is any actual example
that uses this mib2c config. I'm lost on what needs to be done with the
various structures (indexes, etc.) especially for the get-next.
The table is read-only. I have no need to implement row add/remove.
I'm using version 5.7.2.1 of the software collection.
If anyone can point me to an example or otherwise provide some hints,
that would be most helpful.
Many thanks,
-Joe
------------------------------------------------------------------------------
Loading...