Re: (ITS#6807) syncrepl sends incomplete sync cookie in MMR

[hyc@symas.com]

hyc@OpenLDAP.org wrote:
> Full_Name: Howard Chu
> Version: HEAD/RE24
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (76.94.188.8)
> Submitted by: hyc
>
>
> In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is.
> If the provider is stopped and restarted, this same cookie will be sent back on
> the next refresh attempt. In refreshAndPersist mode the cookies sent from the
> provider will only contain a single CSN; CSNs from other MMR servers are
> omitted. During a restart, because the consumer sends a cookie with only one
> CSN, the provider will consider the consumer out of date.
>
> A fix is coming shortly.

For the record...

I spent some time considering whether this should actually be fixed in the 
provider or the consumer. I decided on fixing in the consumer for the sake of 
network bandwidth/efficiency - in persist mode, a cookie may be sent with 
every single write operation. Generally only one CSN will be relevant for any 
given write op, so it would be a waste to send all of the other unchanged CSNs 
every time.

On the consumer side, the consumer must always send all of the context info it 
has available. This might involve more volume in a request but ordinarily the 
actual consumer request is only a tiny fraction of the total network traffic.

Purists might say that this goes against RFC4533 which states that consumers 
should treat sync cookies as opaque items, but the OpenLDAP implementation has 
always relied on exact knowledge of the sync cookie format; this was always 
required in order to support cascaded replication if nothing else. Also this 
ITS is specific to MMR, which is not addressed at all in RFC4533.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/