> 3) generate a huge database that can handle ip-by-ip listings.
>
> 3 isn't practical because the hardware requirements. SORBS has to be a
real-time
> query, and if every query has to search a database with 4 billion
individual IP
> entries in it, it's going to be slow.
Matt, just to be pickey this really shouldn't be a problem at all with a
properly designed database structure. Now I grant that it may not be
possible to do this using SQL, although mainframe DBMs could do this decades
ago:
For IPV4 there are a maximum of 2^32 ip addresses. If the only question is
whether it is dynamic or not, this is a binary decision. That takes exactly
one bit for storage. You don't need any fancy hashing or other clever
lookup tricks. Convert the IP back into a 32 bit index and use it to access
a bit vector. Pull out the one bit you care about and report that as a
boolean result.
The data isn't even huge - 4Gb is is only 500MB. That will fit on a pretty
average disk these days, and on many database servers would even fit in
memory.
If you want 8 bits worth of information about the address, it is still only
4GB of data, which also fits easily on a disk and has for most of a decade.
For that matter, it will fit in memory on a large server, and has for years.
Now, I grant IPV6 is a different problem. But this particular case should
be trivially solvable if anyone felt it was worth solving.
Loren
