Mobile Computing Models

Original notes by Sumi Helal

References

5.1: J. Jing, A. Helal, A. Elmagarmid, "Client-Server Computing in Mobile Environments," ACM Computing Surveys, June 1999. 5.2: B. Noble, M.Satyanarayanan, D. Narayanan, J. Tilton, J. Flinn, K. Walker "Agile ApplicationAware Adaptation for Mobility," Proceedings of the Sixteenth ACM Symposium on Operating Systems. 5.3: M. Ebling and M. Satyanarayanan, "On the Importance of Translucence for Mobile Computing," Proceedings of the 15th ACM Symposium on Operating Systems Principles, May 1998, , CO 5.4: A. Joseph and M. Kaashoek, "Building Reliable Mobile-Aware Applications using the Rover Toolkit," To appear in ACM Wireless Networks (WINET). 5.5: R. Gray, D. Kotz, S. Nog, D. Rus, and G. Cybenko, "Mobile Agents for Mobile omputing," Technical Report PCS-TR96-285, Dept. of Computer Science, Dartmouth College, May 1996. 5.6: B. Zenel and D. Duchamp, "A General Purpose Proxy Filtering Mechanism Applied to the Mobile Environment," Proceedings of the third annual ACM/IEEE Conference on Mobile Computing and Networking, Sept. 1997.

References


5.7 Data Dissemination:



5.7.1: S. Zdonik, M. Franklin, S. Acharya, and R. Alonso, "Are ``Disks in the Air'' Just Pie in the Sky?," Proceedings of the IEEE Workshop on Mobile Computing Systems Applications, Santa Cruz, CA, December 1994 5.7.2: S. Acharya, R. Alonso, M. Franklin and S. Zdonik,"Broadcast Disks: Data Management for Asymmetric Communication Environments," Proceedings of the ACM SIGMOD, Conference, San Jose, CA, May 1995. 5.7.3: S. Hameed and N. Vaidya, "Log-time Algorithms for Scheduling Single and Multiple Channel Data Broadcast," Proceedings of the third annual ACM/IEEE Conference on Mobile Computing and Networking, Sept. 1997. 5.8.1: J. Jing, A. Elmagarmid, A. Helal, and R. Alonso, Bit-Sequences, "An Adaptive Cache Invalidation Method in Mobile Client/Server Environments," the ACM-Baltzer Journal on Special Topics in Mobile Networks and Applications (MONET), Volume 2, Number 2, pp115-127, October 1997 5.8.2: H. Lei and D. Duchamp, "An analytical approach to file prefetching," USENIXAnnual Technical Conference, 1997.

5.8 Client/Server Caching:



Mobile Computing Models

 Hierarchy of Computing Models  Taxonomy of C/S

Adaptations  Unaware Client/Server Model  Client/Proxy/Server Model  Thin Client/Server Model  Disconnected Operation  Dynamic Client/Server Models  Mobile Agents

Hierarchy of Computing Models

Mobile Workflow
Ad-hoc Mobile Server

Mobile Transaction Mobile Query

Mobile Mobile Client Client
Client/Server

Fixed Network Servers and clients

Client/Server Computing

Cache Coherency:
- cache invalidation - update propagation
client cache server cache

Client State

Request

Server

Client
Sockets TLI RPC RMI

Reply

Sockets TLI

Fixed Network

RPC RMI

Client/Server Design
 Stateless/stateful client/server design  Caching and
  

cache invalidation

server invalidates client cache and/or client requests server to validate its cache. file system caching: writes => update propagation

 Connectionless/connection-oriented design  TCP/IP &

Interfaces  Other issues: multi-threading &deadlocks

Fixed Network C/S Assumptions

 Client Connectivity


Client is always connected with availability comparable to the servers. Server can always invalidate the client cache

 Server Availability
 

& Reliability

Server is highly available. Reliable if stateless (but state info is exchanged in every C/S interaction), or if implements recovery procedures (may require client availability) fast*, reliable*, BER < 10-6, bounded delay variance

 Network


Taxonomy of C/S Adaptations

 System-transparent, application-transparent


The conventional, unaware client/server model the client/proxy/server model the disconnected operation model dynamic client/server model the mobile agent (object) model

 System-aware, application-transparent
 

 System-transparent, application-aware
 

 System-aware, application-aware

The Unaware Client/Server Model

 Full client

on mobile host and full server on fixed network (SLIP/PPP C/S)  Client and Server are not mobility-aware  Client caching does not work as the client can be disconnected when the server invalidates the cache  Not reliable and of unpredictable performance  Requires special cache invalidation algorithms to enable caching despite long client disconnections

The Client/Proxy/Server Model

 Adding mobility-awareness between the client

and the server.

Client and server are not mobility-aware.  Proxy functions as a client to the fixed network server, and as a mobility-aware server to the mobile client  Proxy may be placed in the mobile host (Codas Venus), or the fixed network, or both (WebExpress)  Application- and user-dependent  One advantage: enables thin client design for resource-poor mobile computers

Thin Client/Server Model

Thin Client

Keyboard and mouse events

Server

Display events

     

Thin client fits in resource poor info appliances Bounded communication Requires at least weak connection CITRIX WinFrame and ICA thin client VNC client InfoPad

The Disconnected Operation Model

 Approach I:


Provide full client and a thin version of the server on the mobile platform. In addition, needed data is replicated into the mobile platform. Upon reconnection, updated replicas are synchronized with the home server. Conflict resolution strategies are needed (Coda/Venus & Oracle Lite) Provide a full client and a mobility agent that intercepts requests to the unreachable server, emulates the server, buffers the requests, and transmit them upon reconnection (Oracle Mobile Agents)

 Approach II:


The Dynamic Client/Server Model

thin versions) dynamically relocate between mobile and fixed hosts. Proxies created and relocated dynamically  A spectrum of design and adaptation possibilities  Dynamic availability/performance tuning
 Servers (or their

Dynamic Client/Server Model

 Mobile objects:


applications programmed with dynamic object relocation policies for adaptation (Rovers RDOs) disconnected mobile clients turns into a group of collaborating, mobile servers and clients connected via an ad-hoc net. (Bayou architecture)

 Collaborative Groups:


 Virtual Mobility of


Servers:

servers relocate in the fixed network, near the mobile host, transparently, as the latter moves.

The Mobile Agent Model

 Mobile agent programmed with

platform limitations and user profile receives a request; moves into the fixed network near the requested service  Mobile agent acts as a client to the server, or invokes a client to the server  Based on the nature of the results, experienced communication delays, and programmed knowledge, the mobile agent performs transformations and filtering.  Mobile agent returns back to mobile platform, when the client is connected.

Mobile Agents in the Mobile Environment

File System Proxy in Coda

 Disconnected

operation (Venus): hoarding, emulating, reintegrating  Weakly connected operation: both object and volume call-backs  Isolation-Only Transactions

Isolation-Only Transactions in Coda

Isolation-Only Transactions (ACID): no failure atomicity guarantees. Also Durability is guaranteed only conditionally.

The WebExpress Intercept Model

Wireless Web Browser in Mowgli

Thin Client InfoPad Architecture

Mobile Data Management in C/S Design

 Push/Pull data dissemination  Broadcast disks  Indexing on

air  Client caching strategies and cache invalidation algorithms

Push/Pull Data Dissemination

B/W

downstream
 

upstream

Pull data delivery: clients request (validate) data by sending uplink msgs to server Push data delivery: servers push data (and validation reports) through a broadcast channel,to a community of clients

Broadcast Disks

Periodic broadcast of one or more disks using a broadcast channel Each disk can be bcast at different speed Disk speed can be changed based on client access pattern

Indexing on Air

inx
inx

inx

inx

inx
inx

inx

inx

inx

inx

Server dynamically adjusts bcast hotspot  Clients read the index, enters into doze mode, and then perform selective tuning

 

Query Time: time taken from point a client issues a query until answer is received Listening Time: time spent by client listening to the channel.

Caching in Mobile Client/Server: Problems

 Cashing is

critical to many applications such as Web browsing and file and database systems  Classical cache invalidation techniques do not work effectively in the mobile environment because of:
 

client disconnection (call-backs do not work) slow and limited up-link bandwidth for client invalidation (detection approach is inefficient) very limited scalability for application servers with a large number of clients limited caching capacity due to client memory and power consumption limitations

Caching in Mobile Client/Server: Solutions

 Variable granularity of  Enabling ideas:


cache coherency (Coda)

Broadcast disks: periodic broadcast of disk-organized data; does not require upstream communication for disk reads Indexing on the air: broadcast of disk and its index; allows selective tuning; increases access time but reduces tuning time; allows dormant state

 Cache cache
 

invalidation:

Broadcasting Timestamps [Barbar et al] Bit Sequence [Jing et al]

Varied Granularity of Cache Coherency in Coda

 Server maintains version

stamps for each object and its containing volume. When an object is updated, the server updates its version stamp and that of its containing volume.  In anticipation of disconnection, clients cache volume version stamps  Upon reconnection, clients present volume version stamps to server for validation  If valid, so is every object cached at the client, otherwise, cached objects are invalidated individually

Cache Invalidation Reports

Time Window

id, ts id, ts id, ts id, ts id, ts

Broadcast period

  

Server bcast invalidation report showing all items updated within preceding w seconds Client connected: invalidation is straightforward Clients must invalidate their entire cache if their disconnection period exceeds w seconds.

The Bit-Sequences Caching Strategy

 Addresses invalidation
 

report size optimizations:

bit-sequence naming (each bit in a BS represents one data object) update aggregation (one timestamp for a group of updates)

 Effectiveness of invalidation

report: accuracy of validating the status of cached data items w.r.t. invalidation report size report effectiveness for clients with unpredictable disconnection time


 Addresses invalidation

hierarchical structure of BSs (clients with different disconnection times can use different BSs in the structure)

Basic Bit-Sequences Method

Server: Bit-Sequences construction algorithm Client: cache invalidation algorithm Design: different bitmapping strategies Report size: L= 2N+bTlog(N)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 DB

1 0 0 0 1 1 110 1 0 1 0 0 0 1

TS(B4) 50

0 0 0 1 1 01 1

TS(B3) 140
TS(B2) 16 0 TS(B1) time 200

B2

0 110 10

B1

Bit-Sequences Invalidation Precision

UPDATE UPDATE

UPDATE

x x xx x
TS(Bk) Td TS(Bk-1)

xx
TS(Bk- )

Scenario 1
UPDATE UPDATE UPDATE

x x xx x
TS(Bk) Td TS(Bk-1)

xx
TS(Bk- )

Scenario

Case Studies
Bayou Odyssey Rover

Case Study1: Bayou

 Main Features  Novel Aspects  Bayou architecture  Bayou application-specific conflict  Bayou replication management

resolution

 http://www.parc.xerox.com/csl/projects/bayou/

Main Features of Bayou

 Replicated, weakly

consistent storage system for collaborative

applications  Ad-hoc network of portable computers participate in managing a mobile, replicated storage system  Suitable for a group of collaborators, all mobile and disconnected from fixed network, sharing (reading/writing) appointment calendars, meeting notes, evolving design documents, etc.

Novel Aspects of Bayou

Support for application-specific detection and resolution of update conflicts

dependency checks client-provided, per-write conflict resolution (merge procedures)

Eventual replica convergence through a peer--wise anti-entropy process Per-client consistency guarantees Roll-back and undo capabilities

The Bayou Architecture

Application Bayou API Client Stub

Storage System

Storage System

Server State

Client

Read or Write

Anti-entropy

Server State

Server
Storage System

Server

Application Server State Bayou API Client Stub Read or Write

Storage System

Server

Server State

Client Server

Application-Specific Conflict Resolution in Bayou

 Along with


desired update, a write operation includes a dependency check:

server query & expected query results

 As a

pre-condition to performing the write operation, the dependency check must succeed  A conflict is detected if query, when run against server data, does not produce same results.

Application-Specific Conflict Resolution in Bayou

 If dependency check
   

fails, write is not performed and server runs a merge procedure:

also submitted along with the write operation templates or rules written in a high-level interpretive language uses server data and application-specific data to resolve the conflict when run, produces a revised update request

 Write operations are atomic

Conflict Resolution in Bayou

Example (Application-specific):
Write { reserve an hour time slot by meeting room sched application; dependency_check: (list of previously scheduled meetings that overlap with requested time slot, NULL); merge_procedure: (); }

Others:
 

detect read/write conflicts detect write/write conflicts

Replication Management in Bayou

 Clients send

their writes to only one server (weak

consistency)  Bayou servers propagate their writes during pair-wise contacts. This process is called Anti-entropy and results on the two server agreeing on the writes and their order.  Eventually all writes will reach all servers (eventual consistency)

Bayou: Summary

Applications

Adaptation

Model Mobile Data

Non-real time collaborative applications: meeting room scheduler and bibliographic database, appointment calendars, evolving design documents, news bulletin boards. Application-specific adaptation to disconnection and intermittent connectivity; applications are permitted to make trade-off of replicated data consistency and availability by using individually selectable session guarantees. Disconnected collaborative group; full (or disconnected) client architecture. System support for detection of update conflicts, application-specific resolution of update conflicts, eventual replica convergence through a peer-wise anti-enthropy process, and per-client consistency guarantees.

Case Study 2: Odyssey

 Odyssey client

architecture  Odyssey system components  Odyssey applications:

 

Video player Web browser

Odyssey Client Architecture

Viceroy Generic Support Wardens Type-Specific Support

Applications

Cache Manager

API Extensions (Kernel)

Main Features of Odyssey

Application-aware adaptation approach Odyssey monitors

system resources and notifies applications of relevant changes Applications decide when and how to adapt, to maintain certain level of fidelity General support for adaptation: Viceroy Type-specific support: Warden Caching support

Odyssey System Components

 Odyssey Objects  Client API
   

to allow applications to:

operate on Odyssey objects express resource needs (expectations) be notified when needed resources are no longer available respond by changing levels of fidelity

Odyssey API

Request( in path, in resource_descriptor, out request_id) Cancel(in request_id)

Resource Negotiation Operations

Resource_id lower bound upper bound name of upcall handler

Resource Descriptor Fileds

Network Bandwidth Network Latency Disk cache Space CPU Battery Power Money bytes/second microseconds Kilobytes SPECCint95 minutes cents

Handle( in request_id, in resource_id, in resource-level)

Upcall Handler

Generic Resources in Odyssey

Tsop( in path, in opcode, in insize, in inbuf, in out outsize, out outbuf)

Type-specific Operations

Video Player in Odyssey

Web Browser in Odysset

Odyssey: Summary

Applications Adaptation

Model Mobile Data

File system access, video playing, and Web browsing. Application-aware adaptation with the system support that provides resource monitoring, notifies applications of resource changes, and enforces resource allocation decisions. Classic client-server architecture. Distilled server data delivery based on the client Feedbacks.

Case Study 3: Rover

 Basic features of

Rover  Novel features of Rover  Rover system components  Constructing mobile applications using Rover  Rover applications

Basic Features of Rover

 Rover is a

ToolKit for developing applications that can be used in both the fixed and mobile environment  Supports both application-transparent and applicationaware adaptations  Supports the dynamic client/server model  Can build Rover apps from scratch or migrate existing apps (with some effort) to be mobile

Novel Features of Rover

 Support for:
  

Mobile objects disconnected operation dynamic client/server Relocatable Dynamic Objects (RDO) Queued Remote Procedure Calls (QRPC)

 Mixed communication/computation modes:

 

 Applications decide

to use RDO or QRPC

Relocatable Dynamic Objects (RDO)

relocated from the fixed network to the mobile computer. Client applications then interacts directly with the local copy of the RDA  If cached RDO is updated it can be tentatively considered the primary copy and is exported back to the fixed network  Advantages: Performance (under weak connectivity) and functionality (under disconnections)
 Objects can be

Queued RPC (QRPC)

 Non-blocking remote procedure calls,

even when fixed host is

disconnected  Client applications use QRPC to fetch RDOs. Upon connection, or when an RDO arrives, the requesting client is called back  QRPC is also used to commit updates made to RDOs  Non-executed QRPCs are kept in an operation log  As network connection comes and goes, the operation logs are flushed back to the servers

Rovers Relocatable Dynamic Object (RDO) Architecture

Rover Component Architecture

erver

Constructing Mobile Applications in Rover

 Split

the application into clients and servers modules  Decide where each module resides initially (mobile host or fixed network)  Encapsulate each module as an RDO  Add application-specific semantics to RDOs  Add application-specific conflict resolution procedures.

Rover Applications
 Application-transparent adaptation


Rover NNTP proxy and Rover HTTP proxy Rover Exmh (mail browser), Rover Webcal (distributed calendar system), Rover Irolo (graphical Rolodex tool), and Rover stock market watcher

 Application-aware adaptation


Rover: Summary

Applications Adaptation

odel obile ata

-mails, appointments, to do lists, reminders, calendars; and eb pages and images. Application-a are adaptation ith the use o Rover Toolkits that deal ith intermittent and lo bandwidth connection and resource-poor clients; application-transparent adaptation by using Rover proxies. ynamic client-server architecture with the use o R Os. Asynchronous and disconnected operations with the support o RP .