RE: Applicability of LDAP Content Sync to loosely coupled replica sets
"Jeff Parham" <[email protected]> Fri, 6 Jun 2003 12:52:08 -0700
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <6BA5A5D4255F564BBF4BF9E413BF53B801789812@WIN-MSG-05.wingroup.windeploy.ntdev.microsoft.com> |
> -----Original Message----- > From: Kurt D. Zeilenga [mailto:[email protected]] > Sent: Friday, June 06, 2003 10:29 AM > To: Jeff Parham > Cc: [email protected] > Subject: RE: Applicability of LDAP Content Sync to loosely coupled replica > sets > > At 06:36 PM 6/5/2003, Jeff Parham wrote: > >> >Is LDAP Content Sync intended to be applicable in this case? > >> > >> Likely (but I'd have to think about it more). I note that since > >> LDAP Sync supports both updates+present and update+delete > >> incremental synchronization mechanisms, if LCUP is applicable > >> then likely so is LDAP Sync. > > > >I'm not sure I agree there. The key difference between LCUP and LDAP > >Content Sync is the ability to assert the "member objects" without > >forcing a reload. The implication is that an incremental sync can force > >the client to drop previous knowledge, which seems to be the heart of > >the problematic example I illustrated. LCUP doesn't have such a > >mechanism; knowledge is lost only on a full reload. > > LCUP not only support an incremental sync mechanism (updates+deletes) > to drop previous knowledge, servers are to use those mechanism to ensure > eventual convergence. If they cannot ensure eventual convergence, they > are to force a reload. > > LDAP Sync provides two incremental sync mechanisms (updates+deletes > and update+present), but has the same eventual convergence requirements. By "lost knowledge", I'm referring to knowledge the client did have and should have in the future, but now does not. In the example in http://www.imc.org/ietf-ldup/mail-archive/msg01792.html, a client that should in the fullness of time have a copy of the new object created on DSA1 first gets that object from DSA1, then is forced to drop it after performing an LDAP Content Sync against DSA2. This is what I refer to as "lost knowledge", as opposed to the case where synchronization indicates to the client that an object that the client synced in the past e.g. has moved out of the subtree being synchronized by the client. How does LDAP Content Sync detect and recover from this lost knowledge phenomenon? If it does so by discouraging or eliminating the mechanism that diffs the full set of objects by entryUUID, then LDAP Content Sync essentially becomes the same proposal as LCUP. In short, I would love to see a solution that requires little or no history information on the DSA and simultaneously guarantees convergence, but I'm having trouble seeing how the differences in LDAP Content Sync over LCUP actually enable this in loosely coupled deployments. Thanks, -J