On 07/11/2007 <[EMAIL PROTECTED]> wrote: > What's the best way to store data in net-snmp?
That's a very general question, and it's impossible to answer. The best way to store data depends on all sorts of factors, including the style and characteristics of the data that you are working with, the particular helpers that you are using, and your personal preferences. > I assume it would be best to > save the data associated with its relevant mib node in the mib tree. Not normally - no. The MIB tree (i.e. 'tree_head' etc in snmplib/mib.c) holds a representation of the MIB objects that are known by the library. It's really only used for translating between names and OIDs, plus simple syntax checking and formatting of output values. There is another tree - the 'agent_registry' which is specific to the agent, and holds a list of which handler routines (or handler chains) should be used for particular OIDs. But even this isn't really the right place for holding the actual data. That's typically handled within the code files that actually implement each particular OID subtree (e.g. a set of scalars, or a table, etc). > notice that there is void pointer my_reg_void inside > netsnmp_handler_registration data structure, not sure if that's the best > place to save the data value for that mib variable, You *could* do things that way, I suppose, but it's not really ideal. It would be more common to have a structure within the code file itself to hold the table, or whatever you are implementing. I suggest that you spend some time looking at some of the existing MIB implementations, and get a feel for the various approaches that are currently being used. > Due to the architecture > already > in place, what I need to do is that I create certain storage space for > anyone that register with the subagent I am running, and pull data regularly > from them after the registration, and update the data in storage > correspondingly. You can either update this data regularly, or you can update it "on-request" (i.e. whenever a request comes in). Or if this is likely to be too time consuming, you can update the data when it's first needed, but then cache it for any subsequent requests. There's a 'cache_handler' module specifically designed to aid this way of working - with various examples in the Net-SNMP agent. The automatic update approach is illustrated in the latest 'hardware/cpu' statistics handling - see 'ucd-snmp/vmstat.c' for the MIB interface. The pure "on-request" approach is fairly common through many of the MIB modules - particularly the older ones, as it's typically the easiest style to implement. But have a look at the current code, and get a feel for that before trying to implement your own MIB. Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ 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
