Re: Comments on ldup-replica-req-00.txt

["John Merrells" <merrells@xxxxxxxxxxxx>]

Alan Lloyd wrote:

>         Of course - its just that these servers just become "normal"
> users of the directory that must be authenticated and if one changes the
> credentials of a server in one server - how does that get into the
> second - unless servers need to use their old credentials depending if
> they have replicated them or not... is this chicken and egg stuff.

That hasn't been raised as a requirement either.  An administrator's
intention may indeed be to permanently or temporarily deny access to
some other server.  In any case, the administrators should sort it out.

> > >         Does this mean changes to the LDAP RFC?
> >
> > Probably, in the form of new controls, and possibly extended
> > operations.
> >
> > >         You see replication needs to be initated by either server
> > and
> > > replicas transferred in either direction so its either a
> > bi-directional
> > > LDAP server to server with transaction control and server based
> > > management and a lot of Gods help (this is not a religious statement
> > > ;-))
> >
> > It could be a session in each direction.
>         With God in most cases it seems to be simplex - but I realise it
> is bothways with LDAP :-) see above.

Alan, you've lost me with the God acronym.

An LDAP Replication session could be implemented as one bi-directional
session, or two uni-directional sessions.

>         Protocol fields  are easy to
> write down . eg ip6 address is just 16 bytes - now try and deploy it and
> make it work as a global network.

Um, LDAP Replication might require some extra controls to definethe start and end of a replcation session.

>         Want to ask Oracle, Ingres or Sybase about transaction locking
> systems and deadlock issues?

No, I've got a book all about it.

An LDAP Replication protocol specifiction could mandate the use of
transactions, but it's probably not essential that it does.

>         If they stay like DISP there is a chance of success - : -) ..
> existance proof is good.

Is that documented in X.525?

Are there any documents that address using DISP for multi-master
directory topologies?

> > So far, no one's suggested this as a requirement.
> >
>         May I suggest a feature which.........................

Are you suggesting identifying an entry as a master/shadow as arequirement then?

> > I'd wonder though... that if your application has real-time
> > constraints then
> > you probably don't want to store your data in some loosly consistent
> > store.
>         X.500 permits inconsistencies - but leaves the ops people to
> sort that out- but X.500 provides the services to always get the master
> entry just in case the ops people dont make it.

Who are ops people?

'One of the master copies', seems no better than 'One of the replica copies'.

> > Also... if an entry is mastered by many servers... then you won't know
> > which server holds the 'correct' value anyway.  So it doesn't sound
> > like
> > this buys you much.
> >
>         In X.500 one does via the information being tagged as copies
> (internally in the DSA because it arrived via DISP) - and with the
> knowledge information in the replication agreements the replica DSA
> knows of the master - and the via DSP (distribution again - an LDAP
> deficiency) I can request of the replica I am connected to to go to the
> master via DSP to get it by specifying Dont Use Copy - all seamlessly to
> the user - you see replication and distribution in X.500 work together.
> In LDAP land all the parts arn't there yet. So replication on its own is
> very limited....

I think you're missing my point. Which of the master copies is the onetrue correct copy? You'll just never know.

>         through replication agreements and using op attrs.
>
>         The replication scaling problem is reduced with distributed
> directories in the first place.

Reduced, but not elliminated. Say you have a set of N masters for an entry.Each server maintains an increasing counter which is
used to tag attribute
values as they're updated.  These tags are then used to determine which
values are communicated to each of its peers. The question is: 'How do
you avoid each server having to know the highest tag value sent from
each other server?'  This seems to be the big scalability problem for
multi-master directories.  How does X.500 solve this?

John

--
John Merrells
Netscape Communications
Directory Server
Software Engineer

http://people.netscape.com/merrells