HI Peder Chr. Norgaard, I believe we pretty are much in agreement that what was done in many of the access routines and event reporing routines in NET-SNMP can and should be updated.
The note was to help other readers with understanding that the change was not to add any new capabilities to NET-SNMP, but to change the mechanism used to report link up and link down events. Note, on terminology, I really wish there was a good reference, since I believe that in telco speak there are two types of alarms - one for "standing conditions" and one for (I forgot the actual term) "instance events" (for example, a failed login attempt). If you have a good reference, please send me a citation. Regards, /david t. perkins On Tue, 28 Feb 2006, Peder Chr. Norgaard wrote: > On Fri, 24 Feb 2006, David T. Perkins wrote: > > > 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). > > OK, what I wrote was "what is basically an alarm". This is because I am > really an Internet guy who for the last seven years have been employed by > the telecom world (Ericsson) - that colors my language somewhat :-) In > the telecom world an "alarm" is (roughly) something that can be reset - in > that language the ifUp/ifDown pair constitutes an "alarm". And that is > what we are talking about here. > > > > 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. > > Here is where I find that the concept of an "alarm" is useful: The > polling technique only works *because* the ifUp/ifDown pair is an "alarm": > A binary status in the managed system (oops, that was another telecom > term...), and the purpose of the exercise is to mirror that binary status > to the NMS, as efficient, quickly and trustworthy as possible. The > polling techique may be efficient (it isn't in the case of the originator > of this thread); it is neither quick nor fully trustworthy (it can > overlook a status change that is more short-lived than the polling time). > But it is trustworthy to the extent, that a long-living true status in the > managed system will be mirrored as a long-living status in the NMS. > > > 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). > > Yes, but in this situation the "resource manager" (the linux kernel) does > "support subscriptions". The mechanism is called netlink! Modifying > net-snmp to employ that support instead of polling, thus gaining lower > load on managed system, immediate event issuing and no loss of short-lived > link-downs or link-ups - that cannot possibly be described as "a quick and > dirty patch". > > best regards > > -- > Peder Chr. N?rgaard Senior System Developer, M. Sc. > Ericsson Denmark A/S, Telebit Division > Skanderborgvej 232 tel: +45 30 91 84 31 > DK-8260 Viby J, Denmark fax: +45 89 38 51 01 > e-mail: [EMAIL PROTECTED] > (old e-mail 2000-2003: [EMAIL PROTECTED]) > (old e-mail 1992-2000: [EMAIL PROTECTED]) > ---------------------------------------------------------------- > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we > only send and receive e-mails on the basis that we are not liable for > any such corruption, interception, amendment, tampering or viruses or > any consequences thereof. > > > ------------------------------------------------------- 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&kid0944&bid$1720&dat1642 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
