[ANN] rwhoisd-1.5.9.5 and rwhoisd-1.5.10-pre5

[David Blacka]

Kris Deugau wrote:
> David Blacka wrote:
> 
>>On Jun 7, 2005, at 7:08 PM, Joe Pruett wrote:
>>
>>>because the output of ni_to_addrstring gets fed back to inet_addr,
>>>it can't do thinks like zero pad, or inet_addr may return an octal
>>>interpretation or error for things like 098.  i have tweaked
>>>ni_to_addrstring to just use %hu instead of %03hu and now it looks
>>>happy
>>>for all my queries so far.
>>
>>The index values *must* be zero padded, or you get, um, interesting
>>search anomalies.
> 
> 
> Is this something that would have changed between 1.5.7 and 1.5.9?
> 
> 1.5.7 seems to work fine for me using the same source data.

I don't remember exactly.  I think the zero padding was lost somewhere 
after 1.5.7 and I sort of fixed it after 1.5.9.1.  "sort of" means that 
I obviously made a few errors when I commited the fix.

I'll explain the issue a little better.  The rwhois database code (MKDB) 
  is doing binary searches on indexes of *strings* in lexicographical 
order.  When searching a CIDR index, however, the server is really 
looking for a number (an IP number), and thus the index needs to be in 
numerical order.  If you zero-fill the IP addresses (v4 or v6), 
lexicographical order is the same as numerical order, so it works.

The search algorithm is very sensitive to order differences.  Much older 
versions of rwhoisd had subtle bugs caused by /bin/sort ordering things 
slightly differently than strncmp() -- this was a locale issue, IIRC.

Order differences cause some search keys to be unfindable in some 
situations.  It is hard to predict, however, which keys will be 
unfindable.  Modifying the index file (say, by adding a new record) can 
change the result.  Basically, it makes search unpredictable.  I think 
that for very small indexes, the probability of triggering the bug must 
diminish somewhat, so it is quite possible that many of you would not 
have experienced the bugginess.

We will have to fix addrstring_to_ni to work correctly with the output 
from ni_to_addrstring (as you might expect).

-- 
David Blacka    <davidb at verisignlabs.com>
Sr. Engineer    Verisign Applied Research