[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-users
Subject:    Re: How to access data from other tables
From:       Ricardo Hillbrecht <ricardohillb () gmail ! com>
Date:       2012-06-18 16:35:03
Message-ID: CAG_Rr=2BLsq9ThmLTV8aOW+XyZoKYVtEn9QX5D70hhaKOxE68A () mail ! gmail ! com
[Download RAW message or body]

I've adopted the approach in "c", pulling code from other table
data_access method to the table I'm currently working on. Now I have a
section of duplicated code, but at least I'm not stuck anymore.

Thanks Dave

-Ricardo


2012/6/18, Dave Shield <D.T.Shield@liverpool.ac.uk>:
> On 18 June 2012 00:53, Ricardo Hillbrecht <ricardohillb@gmail.com> 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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
[prev in list] [next in list] [prev in thread] [next in thread]