Re: snmp agent tree updation : chicken and egg question

[Omer S. A. <osa...@un...>]

Dave,

> One aim I've had for some time now is to provide a simple mechanism
> for caching this sort of data, and only re-reading it if the cached
> version is "too old".
>   But that's something for the future.

I've been thinking along the same lines in fact. I'm planning to create a
hash table as a cache, and serve getnext requests _only_ from this cache
until a predefined timer expires.

thus
1. user does an snmpgetnext on an OID.
2. agent assumes this is going to be an snmpwalk on the OIDs depth
thus fgets each line into a cache.
3. the next getnext request comes around, time t1 is noted, and if it
matches the depth (of original oid) the result is served from cache
4. all subsequent requests are checked for time. if t2-t1 < CACHE_TIMER,
the info is served from the cache.
5. the moment a getnext request comes around where t2-t1 > CACHE_TIMER,
another fopen on the /proc file is done and the cache cycle starts again.

what do you think?

Omer

> > (b) how is the TcpConnState "set" in linux?
>

I noticed that too! I still plan to support invalidating arp entries in my
little daemon. (dont know if net-snmp does that for the ipNetToMediaTable)
via ioctl's.


cheers
Omer