Peter Nørlund <[email protected]> writes: > It seems that the better the API become, the more complex the > underlying implementation becomes.
Yep, when you make APIs simpler that usually means you're doing a lot more work under the hood. Unless you're getting reuse through that work (which I'd argue you may be a lot of the time), the code size definitely goes up. And if you're not using all the APIs, then it certainly is wasted space. > Even NET-SNMP, with 20 years of experience, haven't managed to make > SNMP a pleasant thing to work with. It's akin to trying to make someone easily work with BGP when they have no knowledge of it and don't understand the protocol. The problem with any protocol is that you can use the APIs without understanding them well. Take TCP, for example, everyone (including me) just uses the default socket options. But I *know* there are much better options to turn on in certain situations, given the type of the connection, but I have no idea how to do it and what flags to use because I'm not using it as an expert. SNMP is very similar: you can use it badly, or you can learn. But who wants to learn to be an expert in a protocol they're only using because they have to (most of the time I don't *want* to care about TCP, I'm only interested in the layer above and any time spent learning about good tcp options that have come out in the last 3 years is not time spent on doing what I want.) Err, um, rant-off I guess :-) > I guess that simplest, least demanding way to actually achieve support > for notifications, is to do SNMPv2 notifications directly (no > AgentX/SMUX), which I guess is better than nothing. There probably > wouldn't be SNMPv3 support (needs crypto), and you would have to specify > the notification receivers in the BIRD configuration (as opposed to > through the SNMP agent). > I am very interested to hear which other SNMP libraries, you are > thinking about. I know of one for C++ and a couple for other languages, > but when it comes to C everyone seems to point at NET-SNMP. Notifications are much more likely to be implemented correctly if you do them yourself. If all you care about is notifications, I doubt you want or need the overhead of AgentX (please don't use SMUX; it's a dead protocol). In terms of libraries, the base net-snmp library is not as large as a full agent and you can send v1/v2c/v3 notifications with it (and there are configuration options that can help you reduced the code print size for small devices). But it wouldn't be that hard or bad to roll your own SNMP trap either (unlike rolling your own agent). As far as other choices, Net-SNMP is the most popular on the C side, I agree. I can't point you to many other things as I'm much more familiar with Net-SNMP than anything else myself. > IPFIX, at least in theory, sounded like a much nicer way to export > information [...] Yeah, it's a better way to go. But there is a lot less support for using it out there with open tools, I agree. It's a newer kid on the block. You could also send netconf notifications too, but there isn't much integrated support for that too on the receiving side. There are tools you can use, but it's not likely to be the norm. If you want the norm for receiving data then snmp is definitely it. Netconf is being to be used more and more for configuration, but that'd be a large project in itself to get working within bird. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/
