View
220
Download
1
Category
Preview:
Citation preview
© Oxford University Press 2007. All rights reserved. 1
Data Synchronization in Mobile Computing Systems
Lesson 10SyncML Protocols
© Oxford University Press 2007. All rights reserved. 2
SyncML provisions for an open standard
• Representation protocol • Synchronization protocol• Ways of formatting the document • Ways of description of architecture for
synchronization ─ Ways for binding an application with the
well known transport protocols
© Oxford University Press 2007. All rights reserved. 3
Ways of binding
• SyncML codes bind the WAP, Bluetooth, or IrDA protocols and a mobile application run for synchronization and synchronize with Bluetooth, WAP 2.0, or IrDA level 5 connection using a SyncML client and engine
© Oxford University Press 2007. All rights reserved. 4
SyncML provisions for an open standard
• Interfaces for binding the programming languages which are very common, for example, Java, C, and C++.
• Prototype implementation for using the SyncML
© Oxford University Press 2007. All rights reserved. 5
SyncML programming
• Based on two protocols─the SyncML representation protocol and the SyncML synchronization protocol
• The SyncML representation protocol defines the representation format of SyncML messages which are in XML
• It gives details about the inner working of the SyncML framework
© Oxford University Press 2007. All rights reserved. 6
SyncML Message
• SyncML protocol specifies that a message has SyncHdr and SyncBody, with meta info as well as device info present within SyncHdr
• Meta info is placed between the start and end tags <MetInf> and </MetInf> and device info between <DevInfo> and </DevInfo>
© Oxford University Press 2007. All rights reserved. 7
Universal Resource Identifier (URI)
• A full path specification for a device resource
• Assume a PIM data structured like a tree
© Oxford University Press 2007. All rights reserved. 8
Universal Resource Identifier (URI)
• The parent PIM data object is the root object
• At the branches of the root object, there are objects called daughter data record copies, these are calendar, address_book, and tasks_to_do
© Oxford University Press 2007. All rights reserved. 9
Address_book object
• Has the branches having the contacts. Each of the contacts object has branches and daughter objects which may be leaves
• The leaves are name, office, home, mobile and fax numbers, home and office addresses, web addresses, and email IDs
© Oxford University Press 2007. All rights reserved. 10
Root object of device PIM data dev_PIM_data
• Assume that the root object of device PIM data dev_PIM_data
• Server PIM data PIM_data• The root PIM_data hierarchy at the
server— PIM_data → address_book →contacts → Raj Kamal → telNum_RK
© Oxford University Press 2007. All rights reserved. 11
PIM data object address_book branches
• Further has the object Contacts• Contacts has the object Raj Kamal• Raj Kamal object has a leaf, the resource
telephone number, telNum_RK
© Oxford University Press 2007. All rights reserved. 12
PIM data object address_book
• telNum_RK contains the telephone number data in digits, where resource refers to an entity used in the computations or for synchronization
• For an API, the resource is at the leaf during computations using the telNum_RK
© Oxford University Press 2007. All rights reserved. 13
Protocol specification of the URI
• Used to identify any resource at the object
• PIM_data/address_book/contacts/RajKamal is URI for identifying a resource at the Contacts at the server
• PIM_data/address_book/contacts/RajKamal/telNumRK is URI for the resource at the leaf telNum_RK
© Oxford University Press 2007. All rights reserved. 14
Protocol specification of the URI
• If the object Raj Kamal has two branches, telNum_RK and address_RK, then the URI for the leaf object address_RK will be PIM_data/contacts/Raj Kamal/address_RK, where address_RKhas the text of address
© Oxford University Press 2007. All rights reserved. 15
Commands
• Create, Delete, Add, Update, Sync, Alert, Atomic, Search, Read, Get, Exec, Put, Copy, Results, Map, and Status
• Refer Table 9.1 for the meaning of the commands
• Alert command is a special SyncML feature by which the server alerts the client
© Oxford University Press 2007. All rights reserved. 16
Sample Code
<SyncBody><Status><Cmd>SyncHdr</Cmd> <CmdRef>0</CmdRef>
<MsgRef>1</MsgRef><TargetRef> IMEI:49…………800</TargetRef><SourceRef> http://www.syncml.org/sync-server
</SourceRef><Data>212</Data> </Status>
© Oxford University Press 2007. All rights reserved. 17
Sample Code
<Status><Cmd>Alert</Cmd> <CmdRef>1</CmdRef>
<MsgRef>1</MsgRef><!- - Assume that Device contact data object at
the device is dev_contacts, which was the target defined at the header and assume that new contact added at the server is URI ./contacts/Raj Kamal and Alert is sent to client device - - >
© Oxford University Press 2007. All rights reserved. 18
Sample Code
<TargetRef>./dev_contacts</TargetRef><SourceRef>./contacts/ Raj Kamal
</SourceRef><Data>200</Data></Status>
</SyncBody>
© Oxford University Press 2007. All rights reserved. 19
Security
• For secure synchronization of messages between source and destination, a message M sent from a source to destination needs verification of its integrity and authenticity of the source
© Oxford University Press 2007. All rights reserved. 20
keyed hash message authentication code (HMAC)
• HMACsource of message M sent along with M
• Generated after computations at the source
• At the destination, the HMACdest is regenerated
© Oxford University Press 2007. All rights reserved. 21
Keyed hash message authentication code (HMAC)
• If the HMACdest computed at the destination matches with the received HMACsource, the integrity of M stands verified
© Oxford University Press 2007. All rights reserved. 22
Computations for HMAC
• Done using M, a secret key S and an iterative hash function
• Iterative function is a function repeatedly operated on the operand
• Two of the several iterative hash functions can be used
• SHA-1 (secure hash algorithm-1) and MD-5 (message digest algorithm-5)
© Oxford University Press 2007. All rights reserved. 23
Handling Large Objects Using <MoreData> tag
• Wireless transmission, there are interruptions
• Therefore, a large data object should be broken into many chunks
• <MoreData> tag for transmitting large object data in chunks
© Oxford University Press 2007. All rights reserved. 24
Handling Large Objects Using <MoreData> tag
• Using <MoreData> tag, a large object can be exchanged by dividing it into data chunks. Each chunk has a start tag <MoreData> and an end tag </Moredata>
© Oxford University Press 2007. All rights reserved. 25
Handling Large Objects Using <MoreData> tag
• This indicates that next chunk expected in next session
• The receiving objects join the chucks to recreate a large object
© Oxford University Press 2007. All rights reserved. 26
Use of status codes in case of Errors
• SyncML protocol defines error codes in the event of data conflict, incomplete document, and other errors that occur during synchronization
• Status codes between 500 and 599 are received for response from the receiver
• For example,Code 511 which implies server failure
© Oxford University Press 2007. All rights reserved. 27
Example of status codes
• For example, assume that a status code sent by the receiver of SyncML message is error code 501
• This implies that the command could not be implemented at the receiver because the SyncML client or server did not support it for any of the resources
© Oxford University Press 2007. All rights reserved. 28
Setup and Synchronization phases
• SyncML DM protocol specifies a standard method for set up and synchronization
• Device management─ one-way synchronization of the device from the server
© Oxford University Press 2007. All rights reserved. 29
Setup and Synchronization phases
• The server sets and updates the data on the client device
• It also requests for the device data, for example, data for enabling device authentication by it
© Oxford University Press 2007. All rights reserved. 30
Setup and Synchronization phases
• Data exchange occurs in phases using packages 0–4
• A package is a SyncML message containing XML document
• Phases of data exchanges in packages 0–2 are called setup phases
• Phases of data exchanges in packages 3 and 4 are called synchronization or management phases
© Oxford University Press 2007. All rights reserved. 32
Summary
• Representation protocol • Synchronization protocol• Ways of formatting the document • Ways of description of architecture for
synchronization• Interfaces for Binding• Prototype implementation
…
© Oxford University Press 2007. All rights reserved. 33
… Summary
• Universal resource Identifier by full path from root to leaf
• Commands for message exchanges for synchronization and client-server exchanges
• HMAC security…
© Oxford University Press 2007. All rights reserved. 34
… Summary
• <MoreData> for handling large objects• Four phases for set-up and
synchronization
Recommended