Re: cdi server (mirroring ideas)

Neil Muller (neil nospam at zeta.mth.uct.ac.za)
Thu, 1 Apr 1999 11:43:02 +0200

> > 1) Receive a duplicate, but not the same record from a peer
> > 2) Toss the duplicate into a 'conflict bin' and save it for later.
> > 3) Next time we receive this record from a peer we scan through the
> > conflict bin to see if we already have a conflict for this record. If
> > so, compare the newly received record, any records in the conflict bin,
> > and the record in the DB. Accept the 'correct record' as determined by
> > majority rule.

(start of my 2 cents)

We can (hopefully) assume that the only source of error will be typos.
It is hightly unlikely that somebody will mistype every track, so it
might make sense to keep a track by track score. We can even present
cases where there's a conflict to the next query of the database and
get an additional vote that way.

> kind of...
>
> Ok, I'll try to explain what I mean about the maj. rule problems.
>
> take a simple server setup. 3 servers, A, B & C. each peers with the others.
>
> server A gets a correct entry for a CD, server B gets an incorrect entry.
> Server C pulls from server B first. Now server B & C have the incorrect entry.
> Server A pulls from B, sees the conflict, throws it in the conflict bin to
> deal with later. Then it pulls from C and checks the conflict bin. It sees
> that there are more servers that have the other record, and replaces it's
> correct entry, with the incorrect one.

However, it should be trivial to mark a new record with a time stamp and
originating server. Thus C would know that it has 2 copies of the same
record and act appropriately.

It would be difficult implement any voting scheme without some method of
recording the origin of the record for precisely the reasons you mentioned.
Probably the easiest is just a server id, but a additional timestamp would
be useful in cases where someone corrects the entry on the original
server.

> I propose this:
> Each server is going to have an admin (at least one). Conflicting records
> are put in a report to that admin. The admin can then manually update
> the record if they see fit. After they compare it to a few other servers or

In general, I would imagine that most people running a server would want the
minimum amount of hassle. Anything we can automate should be automated, so
that human intervention is as rare as possible.

> And no matter what we choose, I'd suggest that each server have at least
> 2 peers. 1 peer servers run the risk of being orphans.
Agree wholeheartedly.

-- 
Neil Muller
neil nospam at zeta.mth.uct.ac.za


A gentleman is somebody who knows how to play the bagpipes
  and doesn't


I see no reason to concern myself with the medical professions neurotic
hang-ups about food.