>>>>> On Tue, 31 May 2011 12:07:48 +0200, Leo Cacciari <[email protected]> >>>>> said:
LC> I asked the same question on the user list, but I got (almost) no LC> answer, hoping it was due to the bad choice of LC> the list to post to, I ask it again here. The people that volunteer their time to answer questions on the lists can't always promise a rapid turn around for answers. Many do it in their spare time, in fact, on weekends and in the evenings. That combined with the fact that your question was about a topic not many understand means a lot of waiting :-/ LC> First, am I talking sense above? :) Yep. That's fundamentally it. Internally to the library and agent, the data is treated as an arbitrary blob. In reality you actually just need to return a string (char *) and the length of the string and say "it's an opaque" and off it goes. Ditto on receiving it. LC> Second, how about using the internal asn_* routines to implements LC> encoders/decoders? Is this ok or are they too "internals" for safe use LC> in a production application? Or are there other reasons why I LC> shouldn't use them? Yep, you can use them if you like. That's a fairly common way to do things like what you're talking about. There are actually some other mechanisms that use encoded BER inside of a OCTET STRING instead. In fact the SNMPv3 security parameters field is actually an OCTET STRING containing BER data, as is the (potentially encrypted) SCOPED PDU. -- Wes Hardaker Please mail all replies to [email protected] ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
