Mobile ComputingMobile Computing

Panos Papadimitratos

Wireless Networks Lab

Department of Electrical Engineering

Cornell University

Problem ContextProblem Context

Mobile Computing Mobile Computing EnvironmentEnvironment

Limited BandwidthHigh LatencyIntermittent ConnectivityLower ReliabilityLow Physical SecurityLower Processing CapabilityHigher Degree of Heterogeneity

Despite the adversity..Despite the adversity..

Run Distributed ApplicationsProvide Distributed ServicesShare DataRemain ConsistentRemain Efficient

Why are things more difficult?Why are things more difficult?

Connectivity is NOT continuous– Topological Changes

Less Resources

Consequently:– Lower Availability– Potential Inconsistencies

Two aspectsTwo aspects

“…Replicated, Highly Available, Weakly Consistent Storage System…”

“Develop Mobile Applications … minimize the dependence upon continuous connectivity…”

BayouBayou

Distributed Data Storage SystemDesigned for a Mobile Computing EnvironmentNon-TransparentWeakly-Consistent ReplicationApplication-Specific Mechanisms to Detect &

Resolve ConflictsLow Usage of the Network

Previous WorkPrevious Work Theory of Epidemics

– Eventual Consistency

Coda– Disconnected Operation– Optimistic Replication– Consistency

Application-specific resolvers Conflicts resolution based on file type Log unresolved conflicts, create error message

Ficus Notes, Oracle, MS Access

System ModelSystem Model

Client/Server Architecture -Transactional System

Data are replicated to a set of serversApplications run as clientsTwo Basic Operations: Read and WriteReplication is Weakly Consistent

– Read-Any-Write-Any Model

System ModelSystem Model

ApplicationBayou APIClient Stub

Server State

Storage System

Server State

Storage System

Read or Write

Anti-Entropy

Storage System

Server State

ApplicationBayou APIClient Stub

Conflict Detection & ResolutionConflict Detection & Resolution

Application-Specific– Notion of Conflict

Semantics Granularity – example: Scheduling Application

– Resolution Policy Semantics

Automated Mechanisms– Dependency Checks– Merge Procedures

Dependency ChecksDependency Checks

Application-Supplied Query & Expected ResultQuery is Run at the Server against its current dataIf Check Fails, invoke Merge procedure

Merge ProceduresMerge Procedures

High-level programs with application-specific knowledge

Run by the ServerPerformed Atomically as part of WritesAttempt to Resolve the ConflictProduce a Revised Update to Apply

Handling Conflicts – An ExampleHandling Conflicts – An Example

Basic Anti-EntropyBasic Anti-Entropy

Goal: the reconciliation of replicas’ dataPair-wise mannerOne-way OperationPropagate Write OperationsAccept-Order ConstraintPrefix PropertyVersion Vectors

Basic Anti-EntropyBasic Anti-Entropy (continued)(continued)

S

R

R.V Version Vector

All Writes unknown to R

For each w in S.Write_logif (R.V(w.server_ID) < w.accept_stamp)

SendWrite(R,w)

A More Reasonable ApproachA More Reasonable Approach

Without an ever-growing Write Log– Need a method for Truncating the Write Log

Idea: An Update that is received by all Replicas need not be logged any more.

Allow for an independent, aggressive pruning by each Replica

The notion of Stable or Committed Write is pivotal in the pruning process

Write StabilityWrite StabilityStable Write: iff it has been executed for the last

time by a server. Intuitively equivalent to Confirmation or

Commitment Primary Commit Scheme

– Designate a Replica as Primary– Primary determines the order (position) of a Write

when it first receives it. – Stable Order

Any Non-Committed Write is called Tentative

Anti-Entropy Anti-Entropy (Revisited)(Revisited)

S

R

First, All Committed Writes unknown to R

if R.CSN < S.CSN for each w in S.Write_log if (w.accept_stamp < R.V(w.server_ID))

SendCommitNotification(…) else

SendWrite(…)

R.V Version Vector

R.CSN Highest Commit Sequence Number

Second, All Tentative Writes unknown to R

For each w in S.Write_logif (R.V(w.server_ID) < w.accept_stamp)

SendWrite(R,w)

Write-Log TruncationWrite-Log Truncation

Stable Order maintains the Prefix Property– Replicas can truncate any stable prefix from their

Write Logs

Incremental Reconciliation may not be possibleEach Replica needs to remember the omitted

Write OperationsFull-Database Transfer

‘‘Extended’ Anti-EntropyExtended’ Anti-EntropySession Guarantees

– Causal Order – Accept Stamp– Reduce Client-Observed inconsistencies

Eventual Consistency– Define a Total Order using the Server ID and

the Causal Order– Propagate Updates in this Total Order– Provide Guarantees on the ‘quality’ of the

Replicas Data Content

Other issuesOther issues

Light-Weight Server CreationSecurityUpdate through transportable storage

media, i.e. floppy disksLink quality determines the frequency of

the performed anti-entropies

ExperimentsExperiments

Measurements on a modified EXMH (e-mailer) that uses Bayou for storing messages – Only Committed Writes are propagated– Measure the execution time for an Anti-Entropy

(100 Writes) over different network links

Network TransferInserting Newly Received Writes

Experiments - IIExperiments - II

Bayou - SummaryBayou - Summary

Support for Arbitrary Communication TopologiesOperation over Low-Bandwidth NetworksIncremental ProgressEventual ConsistencyEfficient Storage ManagementPropagation through Transportable MediaLight-weight Management of Dynamic Replica SetsArbitrary Policy Choices

Rover ToolkitRover Toolkit

Set of Software Tools for Development of Mobile Applications

Two approaches:–Mobile-Transparent Applications–Mobile-Aware Applications

Goals:Goals: Minimize Dependence on

– Continuous Connectivity– Remotely Stored files

Optimize Utilization of Bandwidth Dynamic Division of Work

Previous WorkPrevious Work Cedar

– Check-in Check-out Data Sharing

Locus– Type-specific Conflict Resolution

Coda – Optimistic Concurrency Control– Pre-Fetching

Bayou – Tentative Data– Session Guarantees

Toolkit DesignToolkit Design

Client-Server architectureMobile Communication Support

– Re-locatable Dynamic Objects (RDO) Reduce Client/Server communication Update Shared Objects Code Shipping

– Queued Remote Procedure Call (QRPC) Non-Blocking Calls When Disconnected

Toolkit DesignToolkit Design

Application code & data are RDOsRover-Applications Interface Primary Functions

– Create Session – Import– Invoke– Export

RDOs are cahcedRDOs are lazily fetched

Toolkit DesignToolkit Design

Mobile Host Server

Client-SideApplication Rover

Library

NetworkScheduler

RDO Cache

QRPC Log

Import RDO

Export Log

RDO

Resolved Log

Object Conflict?

Modify/Resolve

Design IssuesDesign IssuesCommunication Scheduling Computation Relocation

– Separate application from data– Move computation/data: client server

Object Replication – Pre-fetchingConsistency

– Primary Copy, Tentative-Update Optimistic Concurrency Control

– Type-Specific Concurrency Control

ArchitectureArchitecture

Mobile Host Server

Network

App 1

Access Manager

ObjectCache

OperationLog

App3App 2

Network Scheduler

App 1

Access Manager

ObjectCache

OperationLog

App 2

Network Scheduler

App3

Rover starts as a minimal kernelFailure Recovery – Access ManagerLog SizeBatching of QPRCsPromises – Callback User NotificationApplication-Specific Conflict Resolution

Implementation IssuesImplementation Issues

Single Server, Multiple ClientsDifferent Network OptionsTCP over wireless linksThree setups:

– Compressed or Batched QRPCs– Mobile-Transparent Application – Mobile-Aware Applications

ExperimentsExperiments

Experiments - IIExperiments - II

05

10152025303540

Tim

e (

ms

ec

)

Ethernet WaveLAN

ISDN(128)

ISDN (64) 19.2CSLIP

9.6Cellular

Average time for 1 Null QRPCCompressed batched

Compressed single

UncomppressedoverlappedUncompressed single

Experiments - IIIExperiments - III

0

100

200

300

400

500

Tim

e (

se

c)

Ethernet WaveLAN

ISDN(128)

ISDN (64) 19.2CSLIP

9.6Cellular

(Mobile-Transparent) Time to Display 10 Web Pages

Netscape Netscape+Rover

-2

0

2

4

6

8

Sp

ee

d U

p

Ethernet WaveLAN

ISDN(128)

ISDN (64) 19.2CSLIP

9.6Cellular

(Mobile-Aware Applications) Speed up

Rover Irolo Rover Webcal Rover Exmh

Experiments - IVExperiments - IV

QRPC benefits: – RPCs are scheduled, batched, compressed– Increased Network Performance

RDOs migrate functionality – Minimize Data Transfer

Porting of Applications to Rover is relatively easy

Measurements show significant improvement from both approaches

Rover - SummaryRover - Summary

Topics for DiscussionTopics for DiscussionAre there ‘missing’ features?

– What if the semantics are not that ‘strong’?– Or, if the uncertainty about data values is not

accepted?– Should Rover support some replication service?

Do we really know what should be an ‘interesting’ mobile application ?

Topics for Discussion - IITopics for Discussion - II

In other words, are the assumptions made reasonable ?

How secure are these architectures ? How about the ‘mobile’ data ?

Nomadic Computing: Can these schemes support Nomads ?

Other peer-to-peer models? E.g. Sensor Networks?