Regarding option 2, I can't see how can I cache only the indexes.
Consider the following scenario:
- Caching the indexes.
- The internal module data changes (The dynamic indexes change too).
- Getting a request from NMS station.
- Trying to fetch index that is no longer exist ???
I suppose when dealing with tables with dynamic indexes, there are two options:
1. Algorithm 1:
- Exclude mutual access to the internal data (resource) being managed/monitored. (e.g obtaining a mutex).
- Examine the data and find the next index (for get-next) or see if index exists (for get, set).
- Perform operation on the desired index if valid.
- Release the resource
This can be done by using the iterate helper that Robert suggested. But it seems to be inefficient because of the large amount of processing for every request. Also it maybe unpractical at all because of the need to hold the resource for the large amount of time.
2. Algorithm 2:
Using a copy (cache) of the indexes and the data.
Update the cache when you receive some signal from the module that the data was changed (when available) or on a time basis. (Hold access to data while refreshing the cache and assure data is valid).
I suppose this can be done with the mfd scheme.
(Do I have an option to reload the cache without using a timer event?)
This option will force me to cache all the data, but I suppose it is probably better for me than option 1.
Please reply if you have comments.
Also I would like to know if there is a way to use a scheme that generates a cache driven code but without all this code mass that is produced by the mfd option.
Thank you,
Michael.
On 1/9/06, Robert Story <[EMAIL PROTECTED]> wrote:
On Sun, 8 Jan 2006 16:06:32 +0200 Michael wrote:
MG> I would like to implement a mib table.
MG> I want to save some memory, and I don't want to keep the table in memory
MG> all the time. I want to fetch (from some other module) and retrieve the
MG> needed information for the specific object when I will be asked to do so.
MG> Please recommend me the suitable mib2c option.
You have a few basic options:
1) use the iterate helper. For each request you will have to fetch all the
data from the other module to find the right row for the request. This will be
very inefficient. A little memory for caching can reduce the IO to the module,
but searching will still be relatively inefficient.
2) use the MFD helper, but only cache the index information. You will have to
fetch all the data from the module whenever the cache is reloaded
(configurable), but searching while the cache is fresh will be fast. If you
can get add/delete info from the module, you can keep the cache fresh w/out
having to constantly fetch all the data.
3) use any container based helper with a custom container to only retrieve the
minimal amount of data. This will be the most efficient method, but will only
work under certain conditions (depending on the indexes and the api to the
module with the data).
I'd recommend trying 2 first, and seeing if index caching uses more memory
than you want. Then try 1, and see if it's too slow.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
Robert Story; NET-SNMP Junkie
Support: < http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders >
You are lost in a twisty maze of little standards, all different.
