HI,

I'm concerned a little over the use of different terms
that mean essentially the same thing, since this may confuse
many people. That is, I've seen "alarm", "alert", etc.

In all cases, it appears to me, that you are trying
to find an efficient coding technique to determine
when to generate an "event report" (which is called
a notification in SNMP). In general, code can poll
(repeatably query) a "resource manager" for status
or statistics to determine if an event has occured,
or "subscribe" to a resource manager to be notificated
via a message or callback when something of interest
occurs. If the resource manager does not support
subscriptions, or provide other mechanisms for
independent processes to determine the occurance
of events, then the implementation is stuck with
polling. In general, in such a situation, I suggest
that the developers of the resource manager
be requested to extend it instead of doing
a quick and dirty patch (which typically
results in the functionality provided, but
at a high cost in resources to the system).

I can't point you at a document that will help with the
concepts, terms, etc. But please, try to provide
a higher level description of what you are trying
to accomplish to help readers. 

On Fri, 24 Feb 2006, Dave Shield wrote:
> On Fri, 2006-02-24 at 10:29 +0100, Peder Chr. Norgaard wrote:
> > The monitoring solution is inherently a terrible inefficient way of
> > generating data for what is basically an alarm:  you face an unholy choice
> > between heavy load even when everything is OK, and large delay in being
> > told that something is wrong.
> 
> Agreed.
> 
> I recently suggested to Robert that he should incorporate the detection
> of linkUp/Down events directly into his new if-mib data access routines.
> Strictly speaking, that's still a monitoring solution, but is much
> more focused (and more efficient) than the more general DisMan-based
> mechanism.
> 
> But I'm not sure whether Robert has had a chance to investigate this
> possibility yet, and it's certainly not part of any released version.
> (Which is why I didn't mention it to Siddesh)
> 
> An alert-driven approach (e.g. netlink) would perhaps be worth
> investigating as well.   Robert, are you listening?
> 
> Dave
> 
Regards,
/david t. perkins



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to