Re: syncrepl ramblings again

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:05 PM 8/28/2004, Howard Chu wrote:
>As for syncrepl itself: from seeing all the traffic during the startup of a consumer, it would be nice to avoid step 1.

Syncrepl, using LDAPsync, can avoid this through use of
history information.  Our implementation uses sessionlogs
as its history mechanism.

>What was the motivation for not keeping tombstones around?

Tombstones, in general, don't hold enough information for
the provider to determine whether or not a delete message
has been sent to a prticular client, resulting in need to
send extra deletes messages.  Sessionlogs, on the other
hand, track exactly which deletes a client needs to see.  

Note that the question the provider has to answer is
subtlely different than "what entries were deleted since
the client last sync'ed?" but "what delete messages does
the client need in order to sync?".  Sessionlogs are better
at answering that question.

Only when history information is inadequate, unavailable,
or unusable does one have to resort to 'present' mode.
Note that one of cases where history information is generally
unusable is in sync'ing off of replicas.  LDAP's consistency
model doesn't guarantee that two replicas would have
identical history information (and non-identical history
information is unusable).

>It seems a small price to pay, compared to the traffic overhead every time a consumer starts up. 

Sessionlogs also have a small price.

Kurt