I have been following the endianness discussion with some interest, having
been bitten myself by the problems when I had to implement a MIB table
with IpAddress in the index. I have studied the current implementation
and must agree that any solution is complex and not something you wish to
do immediately before a release.
But I do want to urge you to reconsider the conclusion you are about to
reach:
On Fri, 21 Oct 2005, Robert Story wrote:
>
> DS> It would be quite reasonable to decide to use either style of
> DS> representation for an IP address:
> DS>
> DS> - treat it as an integer
> DS> (and convert to/from the string format
> DS> when working with low-level SNMP packets)
>
> We also have to decide here if the integer is host or network byte order. My
> preference would be network, since that what most of the routines that work
> with sockaddr_in, in_addr, etc expect and return.
>
> DS> or
> DS> - treat it as a four-byte string
> DS> (and convert to/from the integer form
> DS> when working with in_addr_t variables)
> DS>
> DS> My gut reaction is that it would probably be simpler in the
> DS> long run to hold such addresses internally in the natural
> DS> form (i.e. as an integer), and convert them to the string
> DS> equivalent when building or parsing SNMP packets.
>
> I'll second that.
I will urge you heavily to not decide upon an internal representation of
an integer. There is absolutely nothing "natural" about integer as a
representation of an IPv4 address. IPv4 addresses are sequences of bytes,
period. That a few socket-releated system calls (those using struct
in_addr) in UNIX historically has used an integer for the IPv4 addresses
is a misdesign that should be contained, not used as inspiration.
Recall that the unsigned integer member s_addr in
typedef uint32_t in_addr_t;
struct in_addr
{
in_addr_t s_addr;
};
is in network byte order; this means that as an integer it will look
different on a PowerPC and on an i386, even when you store the same IPv4
address in it. Conclusion: it is not the least interesting as an integer
- it really just is a sequence of bytes.
Recall that as far as SNMP is concerned, the IpAddress datatype is an
OCTET STRING (SIZE(4)), with the extra facility that when used as table
index, it is encoded as four sub-identifiers. Again - nothing about
integers here.
Recall that IPv6 is coming - in a few years the struct in_addr is
deprecated and all socket programming will be done using the API described
in RFC 3493 and RFC 3542 - IPv6 addresses are definitely sequences of
bytes, not integers:
struct in6_addr {
uint8_t s6_addr[16]; /* IPv6 address */
};
You don't want to end in a situation where v4 and v6 is treated that
differenly internally.
Recall also that socket programming is only one source for IP addresses in
an agent. I have coded agent extension that takes IP address from NETLINK
buffers, for example - again, what you get here is a sequence of bytes.
Just my two cent's worth
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 SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
