[
https://issues.apache.org/jira/browse/DIRSERVER-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094858#comment-13094858
]
Howard Chu commented on DIRSERVER-1651:
---------------------------------------
That's probably the easiest thing to do. Sorry for this; OpenLDAP clearly
deviated from the intention of RFC4533 here. I.e., the cookie was meant to be
an opaque value that is not interpreted by the consumers. I believe in the
usual case, a consumer that needed to "know" the replication state was
supposed to generate its own private state, independent of the cookie that the
provider sent.
Unfortunately this intention simply doesn't work in the real world. The view
of entities as being only providers or only consumers is too simplistic. Even
when syncrepl was first being developed, we had the notion of cascaded
replication, where a consumer was itself a provider to other downstream
consumers. When you have multiple entities participating in replication, it's
important to be able to see that each one's notion of the replication state
agrees with everyone else's. It's also important to be able to determine this
without knowing in advance whether an entity is a provider or a consumer.
Particularly since in cascading or multi-master replication, the entity is both.
So in OpenLDAP we abandoned the notion that consumers could just stash the
provider's cookie without peeking inside, and could generate their own cookies
independently if they were going to serve as providers to other servers.
I believe we could have made it work correctly, with each server generating
its own state and leaving received cookies as opaque values, but then it would
have been impossible to do a simple query to see if two entities are in sync.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
> rfc 4533 implementation differences between openldap and apacheDS
> -----------------------------------------------------------------
>
> Key: DIRSERVER-1651
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1651
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 2.0.0-M2
> Reporter: Hajo Kliemeck
> Labels: 4533, openldap, syncrepl
>
> Tthere is an incompatibility between the RFC 4533 implementation of apacheDS
> and openldap.
> openldap uses the cookie structure "rid=<replicaId>" (initial) or
> "rid=<replicaId>,csn=<Csn value>" (update) while apacheDS is using NULL for
> the initial state and the structure "<replicaId>;<Csn value>" for the update
> state. in the RFC its said:
> {quote}
> The absence of a cookie or an initialized synchronization state in a cookie
> indicates a request for initial content.....
> {quote}
> first is apacheDS like, second is openldap like
> It should be possible to adapt the structure or the behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
