directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [replication] RFC 4533 implementation
Date Sun, 08 Feb 2009 16:36:58 GMT

some feedback on what we have done this week :
- the control codecs have been implemented (almost, the syncStateControl 
still has to be codec).

What we need now is some few more bricks :
- UUID from RFC 4530
- Injecting CSN and UUID in every entry

When we will have those guys, we will be ready to grasp the big 
remaining part ...

<note>I still have to read again the RFC to check if we need the 
changelog for deleted entries. IMO, it's a necessary part, as otherwise 
the protocol assume you transmit all the present UUID on the producer in 
order to do a diff and deduce what are the removed entries...</note>

I would suggest that we write a small client application (nothing 
serious, something very rough, not even a GUI) to send requests using 
those controls to an OpenLDAP server, as it supports RFC 4533 
(syncRepl), just in order to get the network layer whipped. As soon as 
this client will work, we will have to inject it into the server, as a 
part of the replication consumer. At this point, I would suggest we use 
MINA 2.0 Connector to deal with the connection.

When we will have the communication up and running, with all the 
protocol debugged, we will be able to move to the next stage : managing 
the injection of the incoming entries into the consumer base, after 
conflict resolution. It's the biggest part...

What else ? We will need a mechanism to recover the connection if it 
fails, that's for sure. We also will need to update the configuration.

Last, not least, OpenLdap has a delta syncrepl system which is much 
better that the standard SyncRepl, as it transmit only the changed 
attributes, instead of the full entry. We might want to study this.

Did I forgot something ?

cordialement, regards,
Emmanuel L├ęcharny

View raw message