3.2.5.2 Managing the ICS State on the Server

By using the ICS state properties specified in section 2.2.1.1, the server only downloads information that is relevant to the client, and the same information is only downloaded once. The ICS state is produced by the server, and sent to the client as part of the final ICS state, but the ICS state properties are not persisted on the server.

The server receives the ICS state properties from the client using the ROPs specified in section 2.2.3.2.2 immediately after the client configures the synchronization context for download or upload. The server uses the ICS state properties and the synchronization scope, as defined during initialization of the synchronization download context, to determine the set of differences to download to the client. At the end of the synchronization operation, the server sends the client a new ICS state, commonly referred to as the final ICS state, using the state element, as specified in section 2.2.4.3.25. For more details about how the server determines what data to download, see section 3.2.5.3.

ICS state properties are not persisted on the server and are only present as data in the FastTransfer stream and in the fields of ROPs that support synchronization. Typically, the server modifies the ICS state properties and sends them back to the client in the FastTransfer stream or ROP responses. Another method of sending state information back to the client is client side checkpointing, as specified in section 3.3.5.6.

Note that for the purposes of reducing the wire size of the ICS state by enabling compacting of regions, as specified in section 3.1.5.5, and optimizing for performance of determining a set of differences to be downloaded to clients, servers can include extra IDs in IDSET structures that represent CNSET structures, as specified in section 2.2.2.4, as long as that never affects the sets of differences that are downloaded to clients.