How It Works
The synchronization engine relies on a set of data schemas to handle synchronization. Any application that wants its data to be synchronized needs to publish a schema with the truth database. This schema tells the database what data will be synced, how to uniquely identify that data, and how all the pieces of that data are related. After the schema is published, any application can access that data by connecting to the truth database and registering as being able to read the data, write the data, or both.
When an application needs to update either its own copy of the data being synced or needs to notify the truth database of a data change it will initiate a sync session. The truth database then attempts to connect any other application that is interested in this data to the same session. This enables all the applications to be notified of any changes all at once. There are time-outs involved in this connectivity, so if any one application fails to respond it will not stop the session from occurring. Because Sync Services knows the difference between an application, a server, and a device, it handles each of them differently—so the session starts very quickly.
The truth database remembers each client individually and keeps track of when they last synced. Therefore, when a client joins or initiates a sync session it will be sent all of the changes since its last sync, no matter how long it has been since a sync took place.
After the session begins, it goes through several phases, as discussed in the following sections.
The first phase that a session goes through is the push phase. In this phase, the application will push all the changes that it has to the truth database. Also during this phase, the truth database might request that the application do a "slow sync," whereby all the data in the application is pushed to the truth database and not just the changes. This enables the truth database to decide how much data it needs from the application to keep everyone in sync.
After all the applications that are involved in the sync have pushed their changes, the truth database will attempt to merge the changes. If the changes do not collide, there is no issue. If there is a collision, the truth database attempts to resolve the issue internally. If that fails, the database will ask the user which copy of the data to use and which to throw away.
The final phase of the session is to pull down any changes from the truth database. These changes include those made on other computers, on other devices (such as PDAs), and from other applications. If there were any collisions in the mingling phase, those changes will also be included in the pull. During the pull phase, the truth database might request that the application replace all its data with what is being pulled. This enables the truth database to either update an application that is just coming online or to completely refresh one that is far out of sync.
For instance, if I have not synced my PDA in several months, the truth database might decide that it is more efficient to simply replace all the data on the device instead of sending it just the changes.
At the end of the pull phase, the client then commits all changes and notifies the truth database that it has committed them. If the changes are not committed, they will be presented to the application again during the next sync session.
An application can also "reject" a change, which does not cause the change to be refused by any other application, but merely notifies the truth database that the application is not interested in that change. The truth database will then note that refusal and will not send any more changes on that piece of data to that application. This is useful, for instance, if an application is pushing its contacts to the Address Book and is interested only in changes to its contacts, but not interested in other contacts added to the Address Book. Said application could then accept changes to the contacts it cares about and can reject changes to any other contact (thereby ignoring any contacts but its own).