On 1 June 2011 23:03, Wes Hardaker <[email protected]> wrote:
> 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.
A possible alternative approach would be to use a simple text string,
and apply your own internal parsing of the value.
For example, you could represent a sequence of integer values
using a string such as
"1,1,2,3,5,8,13,21"
As far as SNMP is concerned, this is a single string value.
Splitting it up into the separate values would be up to the
client application.
But it has the advantage over an OPAQUE encoding,
of being meaningful to the human operator looking at the
raw data. Never underestimate the utility of this!
Dave
------------------------------------------------------------------------------
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
