Hacker News Reader

Comment by yagibear | Hacker News Reader

Compatibility with IPv6 is much more important than saving a couple of bytes, IMHO. Better to keep as a string.

Storing the address as a string doesn't implicitly give you any better ipv6 compatibility than storing it as an integer.

I would think that integers would allow for better compatibility seeing as a numbers a number no matter what just expand that data type size of the column. The fact that ipv6 allows you to write the same address in multiple ways using the :: notion to denote a single span of zeros means there are a multitude of string representations of the same address.

Huh? Littering your code with u_int32_t declarations and comparisons against magic numbers like "3232235520" doesn't hurt IPv6 compatibility? Pants are shirts!

Maybe that's the way you'd do it. I was thinking more along the lines of...

inet_addr_t some_var = inet_aton("123.456.789.123");

The way you represent constants in code doesn't have to be a direct correlation with the way you store their representation.

I don't know what language this is in, but if it's C, you meant to say inet_aton(string, &addrstruct), and that string is probably more valuable than struct in_addr. Since C doesn't offer a 128 bit scalar type, I'm not sure how inet_addr_t helps you any more than u_int32_t.

pseudo code, the language isn't important. Point is, because there are a number of ways to write the same ipv6 address (assuming it contains runs of zeros longer than 4 or multiple runs of zeros) you are going to have to normalize your string input no matter what so why not normalize to an integer/byte representation which is more compact.

The conversation is about portability, and the observation is that the code you're talking about still assumes an address is a scalar variable, which effectively means it assumes IPv4 addressing. That's all.

I'm not super thrilled to debate the performance merits of optimizing 16-byte strings vs. 4-byte integers. I use whatever is most convenient. It's slightly easier to convert a charstar to a u_int32_t, but it's much easier to index a u_int32_t.

The conversation is about compatibility, not portability. ie: what is the best way to store ipv4 addresses so that they are compatible with ipv6 addresses when you need to start supporting those.

At any rate we are talking about two different things.

if you have the ipv6 address 1234:0000:5678:0000:0000:9212... you can write it a number of different ways, using the :: abbreviation for the various runs of zeros. ipv4 really doesn't have that pit fall in the string representation of its addresses.

So, if you store it as a string one way and then latter when you get input that has the same address written another way you are going to have problems if you don't normalize. Since we are talking about storing in a database, as the parent to this chain was you would likely want to normalize to the most compact representation to save space in your database. The precise type semantics of your language of choice are irrelevant.

Python has socket.inet_pton, which also supports IPv6:

http://docs.python.org/library/socket.html#socket.inet_pton

Edit: Ooh, and Py3k has the ipaddr module:

http://docs.python.org/dev/py3k/library/ipaddr.html

Compatibility with IPv6 does not mean you need to store addresses as strings -- most IP address ADTs support both IPv4 and IPv6 in some way. But in reality, IPv6 is still not worth worrying about for the vast majority of software (YAGNI).

Reply on news.ycombinator.com