On Tue, Apr 24, 2012 at 01:49:55PM +0100, Dave Shield wrote: > > Noted. Shall I post your response to the list for the next person to > > see? I'll be happy to do so but just want to make sure that is OK > > with you. I'll include the above so the new next newbie will know that too. > > Errr.... my response _was_ copied to the list. > So it's already both out there, and archived for the future. > > (And the above text is my standard addition for whenever anyone > contacts me direct - if you check the list archives, you'll find > plenty of examples of this. It fluctuates, but there have been > around 40 in the last twelve months)
I'm posting this to the list too. I was insufficiently clever before in not noticing that your first reponse was Cc'd to the list. I posted my response to your reponse too: hopefully some other newbie will learn this point too! > > I still have to understand how the agent knows periodically to > > check them > > There are two basic mechanisms - on demand, or periodic. > > The most common approach is for the agent to retrieve the > relevant data when a request comes in - either for _every_ > request, or holding it in a local cache, and checking whether > the data is "too old" and needs to be refreshed. Again, there > are plenty of examples of this in the code base, and explanations > on the mailing list. > > The alternative approach is for the agent to regularly reload > the data automatically (perhaps in a separate thread, or a separate > process that populates an external cache). That way the data > is always available for processing a request, and doesn't need > to be loaded explicitly. > This is particularly useful when loading the data will take a > long time, and the client application may time out and resend > the requests. It's less common, but the 'cache_handler' helper > does provide support for this too. > > Have a browse through the mail archives - you ought to find > mention of both approaches. Ah, that explains the references to an external cache when running mib2c. There's a lot to learn here. I'll get to it. (I'm thinking: this makes sense under V1/V2c, but under V3 if a separate process maintains an external cache, or if the agent has to spend its time fetching outside information instead of only responding to requests, why not let snmpset change counters and restrict the privilege to specific outside processes using V3 authentication, and avoid the overhead of an external cache or of the agent doing non-SNMP-related work? So now I have to go understand why that doesn't make sense.) Thanks again! ------------------------------------------------------------------------------ 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-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
