3 ms·

why would you ever store a 32-bit ip address on disk or memory in anything other than a 32-bit word

ars 17y ago
Because of IPv6. You'll need a 128bit word for that. Plus some bignum math libraries for 32 machines that don't do 128 bits natively. (Do 64 bit machines handle 128 bits natively?) Also watch out that you use an unsigned int. In PHP for example (and probably most other dynamic languages that don't do bignum as well) all ints are signed. So you'll have to work with the number as a string.
- dpifke 17y ago
  I'd be curious if matching 128 bit words is slower or more painful than variable-length string comparisons in any RDBMS. I would bet not. Plus, you can't do CIDR operations on strings, making it a pain to i.e. match all addresses within a given /27.
  - audidude 17y ago
    You will often have to do a page-fault for both, so loading wont be too much an issue. However, you have to get it into an integer to compare it to begin with. So the string method is purely overhead.
    - tptacek 17y ago
      A page fault, because you touched a 4 byte word, a 16 byte string, or a 16 byte binary address? We're talking about data types that fit in a single L1 cache line.
    - audidude 17y ago
      Something has to load it from disk into the cache line ..
- deleted 17y ago
  [deleted]
ori_b 17y ago
Compatibility with other addressing formats (hostname? ipv6? $OTHER_THING?) or human readability.
- audidude 17y ago
  Read my post again. I said store. There is no reason to store in a compiled format for humans.
  - tptacek 17y ago
    You mean, besides the fact that storing binary IP addresses breaks "grep", and basically all of the rest of Unix too.
    - audidude 17y ago
      Thats fair. I was a bit narrow sighted in my vision of high-performance scenarios.
lucumo 17y ago
Because it's easy. CGI scripts usually retrieve the IP address in dotted quad notation from the environment. Converting it can be a waste of time if the space doesn't matter that much.

ars 17y ago

Because of IPv6. You'll need a 128bit word for that. Plus some bignum math libraries for 32 machines that don't do 128 bits natively. (Do 64 bit machines handle 128 bits natively?) Also watch out that you use an unsigned int. In PHP for example (and probably most other dynamic languages that don't do bignum as well) all ints are signed. So you'll have to work with the number as a string.

dpifke 17y ago
I'd be curious if matching 128 bit words is slower or more painful than variable-length string comparisons in any RDBMS. I would bet not. Plus, you can't do CIDR operations on strings, making it a pain to i.e. match all addresses within a given /27.
- audidude 17y ago
  You will often have to do a page-fault for both, so loading wont be too much an issue. However, you have to get it into an integer to compare it to begin with. So the string method is purely overhead.
  - tptacek 17y ago
    A page fault, because you touched a 4 byte word, a 16 byte string, or a 16 byte binary address? We're talking about data types that fit in a single L1 cache line.
  - audidude 17y ago
    Something has to load it from disk into the cache line ..
deleted 17y ago
[deleted]

ori_b 17y ago

Compatibility with other addressing formats (hostname? ipv6? $OTHER_THING?) or human readability.

audidude 17y ago
Read my post again. I said store. There is no reason to store in a compiled format for humans.
- tptacek 17y ago
  You mean, besides the fact that storing binary IP addresses breaks "grep", and basically all of the rest of Unix too.
  - audidude 17y ago
    Thats fair. I was a bit narrow sighted in my vision of high-performance scenarios.

lucumo 17y ago

Because it's easy. CGI scripts usually retrieve the IP address in dotted quad notation from the environment. Converting it can be a waste of time if the space doesn't matter that much.