Re: Reality Check and Ideas

Andreas Bogk (andreas nospam at andreas.org)
10 Mar 1999 15:38:47 +0100

Alan Cox <alan nospam at redhat.com> writes:

> > - incremental replication of the whole database
> Split the zone files. You notice I had aa.bb.cc.dd not aabbccdd. - thats
> how the in-addr.arpa domain works and it replicates fine.

What I want is being able to mirror the whole database, not just some
slice of it. There's no mirror of the whole in-addr.arpa domain, and I
think it would be infeasible.

> > - submission of entries
> I dont claim DNS does this. I claim NNTP does not because it doesn't solve
> the case where through partial connectivity and the fact its too slow to
> search the entire history for all time for missing entries some people dont
> get an entry. Nor does NNTP solve the case where two entries collide and
> are submitted from different sites.

Point taken. NNTP is out of the game.

> You want a central but relocatable sanity point. BTW - one thing that

You don't need to, when you have some kind of voting system on wether
an entry is correct or not. You could use a partial hash collision in
order to make voting computationally expensive, to cut down on abuse.

> > - central authorities (so who's going to be the primary for some subspace?
> > What if that server is temporarily unreachable?)
> The other mirror servers cover it transparently. DNS does that for free

Yes, querying continues to work. Submission will not.

> > NNTP solves all that. It lacks some way to ensure consistency after
> > data loss at some site, though.
> To me thats a long form of "doesnt work". Thats not to say it can't be made
> too. NNTP doesnt solve the querying or query caching. Maybe you use an NNTP
> like protocol to populate your DNS servers ?

Hm. One could extend the idea of organizing the data in tree form, by
adding hashes to the nodes that hash all the children of that
node. Then an update between two servers would work like that:

Server1: I have a hash of 23 for the whole tree
Server2: Nope, I have something different.
Server1: Ok then, there's subtree 1 with a hash of 42
Server2: Match.
Server1: Subtree 2 has a hash of 105.
Server2: No, that's different for me.
Server1: Ok, subtree 2 has an entry 17 with hash 69.
Server2: Yup.
Server1: And it has an entry 66 with hash 47.
Server2: I don't have that, give it to me!

and so on. So basically a traversal of the tree with cutoff using
hashes. The effect should be that of flood fill with sanity checks.

I think I'll write some perl prototype for that, but I won't have time
before weekend.

Andreas

-- 
"It is by caffeine alone I set my mind in motion. 
It is by the Beans of Java that thoughts acquire speed, 
the hands acquire shaking, the shaking becomes a warning. 
It is by caffeine alone I set my mind in motion." -- National Lampoon's "Doon"