[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE: Comments on ldup-replica-req-00.txt
Alan wrote :
> Yes its a requirement - in X.500 the time limit for searches
> when provided by users is "seconds" when propagated in DSP > its UTC time + seconds for obvious reasons - this means that
> DSAs when performing distributed searches need some
> synchronised time source if time limit is to be honoured.
> ditto goes with replication, if trying to maintain integrity of deletes and renames in multimaster mode - see previous mail re value judgment.
I agree with the comments and would like to generalize the
requirement to capture the notion of QoS in general with the
directory operations, besides time synchronization, specially, wrt
searches, replication and synchronizations it is important. This
would then possibly raise other issues, like notification support,
etc. beside the time-synchronization.
For e.g., the replication requirement can state, atomic guaranteed
delivery to various replicas to ensure consistency and for that we
may require DSAs to support time-synchronization as well as some
sort of notification support.
Would appreciate inputs.
Thanks & regards
Anurag
Architect, Novell India
>>> Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx> 04/24/98 04:40AM >>>
> -----Original Message-----
> From: Russel Weiser [SMTP:RWEISER@xxxxxxxxxx]
> Sent: Friday, April 24, 1998 1:48 AM
> To: owner-ietf-ldup@xxxxxxx; merrells@xxxxxxxxxxxx;
> USRINIVA@xxxxxxxxxxxxx
> Cc: ietf-ldup@xxxxxxx; alan.lloyd@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: Comments on ldup-replica-req-00.txt
>
> John and Uppili
>
> A couple of things here that are of interest and 'd like to ducuss
> further.
> My comments are below
>
snip -
> Something that hasn't
> been discussed yet it the TIME Synchronization between servers
> participating in a replication.
> This is something that should be addressed in the requirements I
> guess.
>
Yes its a requirement - in X.500 the time limit for searches
when provided by users is "seconds" when propagated in DSP its UTC time
+ seconds for obvious reasons - this means that DSAs when performing
distributed searches need some synchronised time source if time limit is
to be honoured.
ditto goes with replication, if trying to maintain integrity of
deletes and renames in multimaster mode - see previous mail re value
judgment.
regards alan
> cheers
> RFW
> >
> > can you explain the scalability problem here?
> >
> > -Uppili Srinivasan
> >
> ______________________________________________________________________
> ______
> > Oracle Corporation |
> > Box 659510 |Phone: (650)506-3039 Internet:
> usriniva@xxxxxxxxxxxxx
> >
> > 500 Oracle Pkwy |Fax: (650)506-7122
> > Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate;
> s=usriniva
> >
> > CA 94065 |
> >
> ___________________|__________________________________________________
> ______
> >
> >
> >
> >
> >
> ----------------------------------------------------------------------
> ----------------------------------------------------------
> >
> > Subject: Re: Comments on ldup-replica-req-00.txt
> > Date: 21 Apr 98 11:56:00
> > From: "John Merrells" <merrells@xxxxxxxxxxxx>
> > Organization: Netscape Communications
> > To: Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>
> > CC: ietf-ldup@xxxxxxx
> > References: <>
> >
> > 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
>
>
>
> --
> John Merrells
> Netscape Communications
> Directory Server
> Software Engineer
>
> http://people.netscape.com/merrells
>