Toolkits for Building Mobile Systems

3/28/2002

Michael Ferguson(mpf7@cornell.edu)

Problem Mobile computing environments

have Limited network bandwidth Long periods of disconnection

Data is still stored on servers Mobile users still want to modify

their documents when they are disconnected!

Solutions? Coda filesystem Isolation Only Transactions Rover Toolkit

Prior Work - Coda Coda is a network filesystem Uses standard UNIX file interface to insulate

application from changes in network availability

Uses a cluster of servers to meet the goal of “high availability”

Uses optimistic concurrency control We can all change the files at once Conflicts are handled after the fact by file-type

specific handlers Allows “Disconnected Operation”

Coda Terms First-class replicas of data are on

servers Second-class replicas are the

client’s cached copies Optimistic vs. pessimistic

concurrency control

Coda’s Disconnected Operation “Hoard” data by priority when

connected Users modify local copies of the

files while disconnected Coda “reintegrates” with servers

upon reconnection; conflicts are handled by ASRs (application-specific resolvers)

Hoarding in Coda What if the data isn’t in the hoard?

Coda returns an error, butcan be set to block until connected

again Users must create “hoard profiles”

to describe what data should be available should they become disconnected

Example Hoard Profile

# Venus source files# (shared among Coda developers)a /coda/project/coda/src/venus

100:c+a /coda/project/coda/include 100:c+a /coda/project/coda/lib c-

Isolation Only Transactions What if include old data in my new

file? Add IOT to Coda Applications can modified to use it

to have better consistency during a network outage

IOT Terms First-class transactions are

transactions when there are no partitioned accesses

Second-class transactions are all other transactions

IOT transaction states

IOT Guarantees Serializability for first class

transactions Local serializability for second class

transactions Global serializability for second class

transactions* Global Certification Order for second

class transactions*

Remember: Serializability = equivalent to serial execution

Global Serializability Would a pending second-class

transaction be globally serializable if committed?

Can be tested when network is reconnected

Use a resolution strategy if not

Global Certification Order Is a pending transaction

Global Serializable and Serializable after all committed

transactions? Again, test once network is

reconnected. Use a resolution strategy if not

IOT Resolution Strategies Re-execute the transaction with the

current server files (make example) Invoke an application specific

resolver (calendar example) Abort the transaction (makes sense

for load sharing) Notify the user

IOT implementation Still use optimistic concurrency

control, even for first-class transactions

Check for global serializability by looking for cycles in a precedence graph

Log transactional history

Coda & IOT – Pros and ConsPros Works well with existing

applications (without IOT) UNIX file accesses are

almost always separate Worked for disconnected

operation of about a day without hitches

Transactions provide other ways to resolve conflicts using history

Cons Coda is a filesystem – it has

only per-file granularity It was “not intended for

applications that exhibit highly concurrent, fine granularity data access”*

Application involvement is limited – apps lose information with only a read/write interface (eg mobile host added, or server deleted record?)

Requires user involvement on filesystem level

Applications that read/write files for synchronization may fail

*From Disconnected Operation in the Coda File System

Rover Toolkit approach “Application knows best” Make all communication explicitly

asynchronous

Rover Toolkit Relocatable dynamic objects

(RDOs) Distribute objects and processing to

reduce communication requirements Queued remote procedure calls

(QRPCs) Applications can make QRPCs without

blocking even when disconnected

Rover Operation Import objects onto client machine Invoke methods on those objects Export logs of method invocations

to servers Reconcile client data with server

data

Rover Operation

Rover Architecture Access manager

Maintains RDOs and logs their modification Recovers from local failures

Network Scheduler Sends requests from QRPC log Groups operations for each server to amortize connection setup Compresses headers (and data if application does not) Chooses transport protocol and medium

HTTP over TCP/IP SMTP over IP or non-IP networks

Object Cache Local, private cache for application, and Global shared cache within access manager

Operation log Incrementally sent to server Applications can compact the log/overwrite entries

Rover Architecture

Rover RDOs Objects which encapsulate all data

the application and the data it manipulates

QRPC used to lazily fetch RDOs Updates to cached RDOs are tentatively

committed Operations are sent to server where they

change primary copies Application decides which RDOs to fetch

and when

RDO Pros and ConsPros Minimize amount of data on

network Client GUIs can be run even

when disconnected

Cons Must split up functionality

into client and server objects

Rover QRPC Requests are queued Applications are notified by

callback (or can block) when the request has completed

Non-FIFO delivery enables prioritization

QRPC Pros and ConsPros Increase network

performance through scheduling, batching, and compressing

Stable log increases reliability and reduces retransmission requests

Only adds 1% latency on slowest link with Flash RAM

Cons Recording every QRPC in a

stable log decreases network performance

Adds 50-300ms to latency

Consistency Control Primary method is primary-copy, tentative-update,

optimistic Rover also supports other methods, including

pessimistic locking and serializability Results of reconciliation always override tentative

commits All conflicts are detected and resolved by server Applications decide when conflicts exist and how to

handle them, although Rover provides version vectors Uses method invocations instead of new values; eg

Debit, credit, and balance methods Updating the value would require locking

Rover Applications Mobile-Transparent Proxies

NNTP Proxy HTTP Proxy

Mobile-Aware Applications Rover Exmh Rover Webcal Rover Irolo Rover Stock Market Watcher

Rover Server Standalone TCP/IP server, or CGI plugin to httpd Implemented for UNIX (Linux and

SunOS)

Experimental Results - Apps

Experimental Results - QRPC

Experimental Results - Proxy

Rover Pros and ConsPros Porting requires only small

effort (person-weeks to months)

Using rover for mobile-transparent applications increased performance by about 17% on low-bandwidth links

Mobile-aware applications performed up to 7 times better on low-bandwidth links

Rover can still use TCP/IP wireless links prone to error

Rover meets its goal of enabling disconnected operation

Cons Applications must be ported Rover makes performance

slightly worse on ethernet RDOs may present security

problems Don’t know how to handle

errors sent back to client applications which are not running

Performance studies did not include cost of starting application and loading data

Summary Coda & IOT create a highly available

filesystem Disconnected operation is an extra Works well in the home-directory environment Does not sacrifice performance over fast

networks Rover allows applications and users to

make high-level decisions about replication Improves cellular performance but reduces

performance over fast links Fits a highly collaborative environment