On 18 June 2012 00:53, Ricardo Hillbrecht <[email protected]> wrote: > Gentlemen, please, I'm still stuck at this
Sorry for the delay - I was doing other things this weekend, and haven't had any time for SNMP support. > I don't know how to obtain data from different tables > inside the net-snmp client. I presume by "client" you actually mean the MIB module implementation code within the agent? There are essentially three ways for an agent to retrieve data from another MIB module: a) Issue an "internal" query to retrieve that information. This has the advantage that it's independent of the target table, and the same code will work for retrieving data from any other part of the agent. This is how things like the DisMan Event MIB operates, and is really the only "general purpose" API for retrieving information from elsewhere in the agent. The disadvantages are that you receive the information as a series of individual SNMP varbinds, so would have to reconstruct the table structure yourself. You would also need to be careful about possible deadlocks - particularly when processing a SET request. b) Access the data structures from the target table directly. This will inevitably require examining the code of the target MIB module to see how things are handled. It may also require some tweaks to that code, in order to make the data accessible. It has the advantage of being efficient, and providing access to the information in a readily useable form. The main caveat would be in the handling of locally cached data - if the target table is using a local cache, this cache might not actually be valid when the second table tries to access it. c) Alternatively, you can always look at accessing the raw data from the underlying subsystem. Very few MIB modules are concerned with the state of the agent itself - more commonly, the agent is reporting information from the computer that things are running on. (e.g. The list of active processes, or network traffic statistics, etc). You don't need to talk to the other MIB code in order to retrieve this data - you could always get it direct from source. The advantages of this is that it avoids any dependency on another MIB module, and gives access to the current state (rather than cached slightly-stale information). The main disadvantage is that it requires two sets of essentially-identical code to retrieve this data, with the accompanying maintenance headaches. One approach that is starting to be more widely used is to separate the MIB module implementation code from the data access aspects. The MfD framework has used this model for quite a while, typically having a separate 'data_access' directory, containing the code for retreiving the data from the underlying subsystem. In principle, this could be used by a second MIB code implementation, to report the same (or related) data in a different way. In practise, I get the impression that the two halves are fairly tightly integrated, so I'm not sure how feasible it would be to use this elsewhere, particularly with anything other than another MfD-based implementation. But I'm no expert on this particular framework, so I'll leave Robert to comment more fully. However we've also been using the same basic idea to introduce more stand-alone data access implementation modules. These provide a single means of retrieving the data for a particular aspect of the computer's operation, which can then be used by any MIB module that needs this information. Most of these are found under the 'agent/mibgroup/hardware' code subtree. So the UCD disk table, and the Host Resources equivalent, both now rely on 'hardware/fsys' to provide information about local filestore configuration and usage. Local caching and timeouts are handled by the data access module, rather than the MIB table code - so there's no problems with accessing stale data, and all relevant MIB modules are guaranteed to provide consistent information (since they're all working with the same data cache) This last approach would be my personal preference for sharing data between two or more separate MIB module implementations. Hope this helps Dave ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
