On 11/11/2010 05:32 AM, Robert Story wrote: > TT> Now, I'm asking which is better, and if there's any existing example > TT> code (so I can fix the arp_linux.c): > TT> > TT> 1) Dynamically listen Linux netlink events and add/delete/update > TT> entries on the snmpd's copy of ARP table? > TT> > TT> -or- > TT> > TT> 2) On request to specific IP-address (specific MIB entry with IP > TT> address part of the request OID), request the kernels for up-to-date > TT> information on that specific IP-address and dynamically create the result? > > I'd vote for 2. You'd just have to disable the cache reload at the higher > levels (there are some flags that can be set when the cache is created) and > keep the cache consistent via netlink.
Looks like the corrent code works like: 1) arp_common/arp_linux returns a container with snapshot of the kernel cache 2) inetNetToMediaTable is the only MIB using arp code, and it refreshes the cache by doing full ARP dump with arp_common.c call and finally updates the associated cache So, this likely needs a bit of rework so that the dynamic updates become possible. I was actually wondering if option 1, or some sort form of it would be the best. See below. (Sounds like option 2 would require reimplementing the MIB with to be direct access style.) > There is already some code in net-snmp that is using netlink grep should help > your find where that is. just make sure that you are using the agent's main > select loop to monitor the netlink socket. Yes, I found them. But none of them seem to dynamically refresh themselves. All are implementations doing periodic snapshots. > If the code was configurable at runtime, that would be ideal. People who > aren't monitoring/using the arp module might not want the overhead of an > unused cache being constantly updated. Right. I'd assume the RightThing(tm) is to on first MIB request to do full load and start listening changes, and after a timeout stop listening changes. We'd have then fully dynamically working system. I'm wondering if I can do the following with the cache_handler: 1) on container_load we do full dump as usual, but also register for the netlink events for changes (using register_readfd() external fd handling) and finally a timer to unload cache/stop listening netlink 2) on each of _get operations reset the "monitoring stop timer" 3) on netlink socket callback just go and directly update the local cache container using the regular CONTAINER_* 4) on "monitoring stop timer" kill the netlink socket and release resources Namely about the step 3 I'm unsure: can I go and modify the cache container contents outside container_load() call? - Timo ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
