Content Synchronization Content Synchronization March 2nd 2005 - - PowerPoint PPT Presentation

Jukka Honkola T-110.456

Content Synchronization Content Synchronization

March 2nd 2005

Jukka Honkola T-110.456

Synchronization Synchronization

• Needed whenever multiple copies of an object may

be updated independently

• After synchronization objects should be in same state
• Conflict resolution
• Domain specific solutions
• Can be often automated

Jukka Honkola T-110.456

Different types of synchronization Different types of synchronization

• One way or two way
• Slow
• Transmit all information
• Slow
• Fast
• Transmit only changes
• Devices need to keep track of all changes

Jukka Honkola T-110.456

Issues with mobile devices Issues with mobile devices

• The usual suspects:
• Electric power, computing power, slow

connections, limited data storage

• Divide the synchronization workload asymmetrically
• Client / server, server doing most of the work
• Client still needs to track changes
• Standard solution: SyncML
• Defines data representation and synchronization

protocol

Jukka Honkola T-110.456

SyncML SyncML -

• Overview

Overview

• Can be used with different bearers
• Radio, Bluetooth, Infrared, WLAN...
• Messages are in XML
• WBXML used to save bandwidth
• Synchronization protocol
• Initialization
• Negotiate capabilities between client & server
• Negotiate sync type
• Authentication
• Data transfer

Jukka Honkola T-110.456

Example synchronization Example synchronization

Jukka Honkola T-110.456

SyncML SyncML -

• synchronization types

synchronization types

• Seven different synchronization types
• Slow / fast two-way
• Slow / fast one-way from client to server
• Slow / fast one-way from server to client
• Server initiated sync
• Normally, client always initiates sync
• Server can request initiation from client
• The two-way syncs are required by the standard,
• thers are optional

Jukka Honkola T-110.456

SyncML SyncML -

• message structure

message structure

• Information is transferred in packages
• Packages can consist of multiple messages
• Message size can be limited by the bearer
• Large objects may be sent in multiple messages
• Package contains related information
• e.g. client modifications, initialization

Jukka Honkola T-110.456

SyncML SyncML -

• conflict resolution

conflict resolution

• SyncML does not define how conflicts are resolved
• Out of scope as resolving is domain-specific
• Mechanism for reporting conflicts and actions taken
• Status codes for different types of conflicts
• delete, update
• Status codes for outcomes
• Server win, client win, merge, copy
• Conflicts are resolved in the server

Jukka Honkola T-110.456

SyncML SyncML -

• mappings

mappings

• Server identifiers are typically long while mobile

terminals will benefit from shorter identifiers

• SyncML uses two sets of identifiers:
• GUID: Globally Unique IDentifier
• LUID: Locally Unique IDentifier
• Client always uses LUIDs, and server maintains a

mapping between LUIDs and GUIDs.

Jukka Honkola T-110.456

Example ID mapping Example ID mapping

Jukka Honkola T-110.456

SyncML SyncML -

• device capabilities

device capabilities

• There is a DTD defining the device capability

description

• Exchanging capability information is useful
• Server can avoid sending information that the

client can not use

• Removes possible sources of ambiguity
• For example, if client sends a contact entry without a

picture, was the picture deleted deliberately or discarded because client does not support pictures

Jukka Honkola T-110.456

SyncML SyncML -

• miscellaneous

miscellaneous

• Sync anchors next and last
• Provides a way to see if an attempt failed
• Some error cases require slow sync
• If database contains large items, such as

photographs, this can be wasteful as also unchanged data is transmitted

• In some cases message digests could be used to

save bandwidth

Jukka Honkola T-110.456

Using digests to save bandwidth Using digests to save bandwidth

• General idea:
• Client sends digests of all items to server
• Server compares received digests to stored information and

deduces the changes made by client

• Server sends changed items to client and requests changed

items from client

• Server reconstructs the change log regarding changed items in
• rder to avoid sending unchanged information
• Not supported in the standard
• Utility depends on many factors
• Frequency errors requiring slow sync
• Amount of large items in databases