The PMDF-DIRSYNC product uses e-mail to transport directory information. This means that it doesn't matter whether the directories being synchronized reside on the same machine, or on different continents. However it means that the strategy for synchronizing data must be able to handle non-delivery and duplicate delivery of directory updates. There are two obvious ways to handle this problem: to impose a sequence numbering mechanism on all the directory synchronization agents, or to use complete databases centrally to determine changes. PMDF-DIRSYNC uses a combination of these two approaches, sending complete directories to a central point and returning differences. Duplicate updates are detected by a simple "cookie" mechanism that is far less complicated than a sequence number scheme.

With PMDF-DIRSYNC, directory information passes through a number of processes including the central differencer before the updates are returned to the originating directory. Figure 37-1 shows a schematic view of PMDF-DIRSYNC processing.

Figure 37-1 PMDF-DIRSYNC Processing

First the directory agent extracts the full contents of, or the portion of interest from, a directory, and formats it as an LDIF (Lightweight Directory Interchange Format) file. LDIF format is little more than a sequence of attribute/value pairs for each directory entry. This LDIF file is then mailed to the local directory synchronization robot (DIRBOT).

The DIRBOT then converts this data, which will contain attributes and values specific to the original directory, into another LDIF file, this time expressed in some canonical form. This process is called cooking and is controlled by a recipe written in a language based on the Sieve mail filtering language with a number of extensions specifically designed for this purpose. The cooking process will also identify directory entries authoritatively held by a directory and mark them by adding an authoritative=1 attribute to those entries in the LDIF file. The resulting cooked LDIF file is then mailed to a central DIRBOT.

The central DIRBOT performs a number of actions on the incoming LDIF files. The only step it can perform on each LDIF file individually is to go though them and copy the authoritative entries into another file. This process is called sifting, and results in two files: the original LDIF file which will be needed later, and a partial authoritative LDIF file. Figure 37-2 shows an example of sifting. Once LDIF files have been received from all the directories to be synchronized, these partial authoritative LDIF files can be concatenated to produce a complete authoritative directory. At this point the DIRBOT can move on to the next phase of the directory synchronization processing, differencing.

Figure 37-2 Sifting the Incoming Entries

Differencing involves taking each of the LDIF files in turn and comparing them with the authoritative LDIF file. The result of this is another file which is similar to the input LDIF files in format, but which contains update instructions on what records to add, delete or modify to change the original directory to bring it up to date. These updates are then sent back to the remote DIRBOT for further processing. Some directories are limited in their ability to accept updates, and to cater for such directories the central DIRBOT can be instructed to send the complete authoritative database out to remote DIRBOTs to be prepared for updating such directories.

The reason that the directory differences are sent to a remote DIRBOT rather than directly to a directory agent is simple: the data is still expressed in the canonical form rather then being expressed in a form specific to the target directory. Another step is needed to convert the data back into the directory specific form. This step is called serving, which undoes the canonicalization performed in the cooking step to produce a directory specific format of the updated information, and is the final step before the differences are given to a directory agent to be applied to a directory.

At each step, a cookie created by the originating agent accompanies the directory. This cookie is remembered by the agent, and accompanies the differences which are sent back. The agent checks the received cookie against the remembered cookie, and if they are not the same it will not apply the directory updates. Once the agent has received a valid cookie it deletes the saved cookie. This protects directory updates from being applied twice as a result of mail being delivered twice. If a directory update is delayed a long time (days) another directory synchronization cycle can have started. In this case the old updates will be discarded when (if) they are finally delivered: they will have the wrong cookie. But the newer updates will be accepted. Missing an update is not a problem: because PMDF-DIRSYNC uses complete directories up to the differencing step the updates are not cumulative.

In addition, a signature calculated from the directory data and a shared secret is sent with the LDIF data at each step. This makes it difficult for people accidentally or maliciously to assault the directory synchronization process.