Download Mobile IP

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
Application-Aware 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 Client/Server Caching:


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.
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
Request
Client
Reply
Sockets
server
cache
Client
State
Server
Sockets
TLI
TLI
Fixed Network
RPC
RMI
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
server’s.
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)
 Network

fast*, reliable*, BER < 10-6, bounded delay variance
Taxonomy of C/S Adaptations
 System-transparent,

The conventional, “unaware” client/server model
 System-aware,


application-transparent
the client/proxy/server model
the disconnected operation model
 System-transparent,


application-transparent
application-aware
dynamic client/server model
the mobile agent (object) model
 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 (Coda’s Venus),
or the fixed network, or both (WebExpress)
 Application- and user-dependent
 One advantage: enables thin client design for resourcepoor 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

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)
 Approach

I:
II:
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)
The Dynamic Client/Server Model
 Servers
(or their 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
Dynamic Client/Server Model
 Mobile

objects:
applications programmed with dynamic object relocation
policies for adaptation (Rover’s RDOs)
 Collaborative

disconnected mobile clients turns into a group of collaborating,
mobile servers and clients connected via an ad-hoc net.
(Bayou architecture)
 Virtual

Groups:
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 cache coherency (Coda)
 Enabling ideas:


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
 Addresses
invalidation report effectiveness for clients
with unpredictable disconnection time

hierarchical structure of BS’s (clients with different
disconnection times can use different BS’s 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
B4
1 0 0 0 1 1 110 1 0 1 0 0 0 1
TS(B4)
50
B3
0 0 0 1 1 01 1
B2
0 110
B1
10
TS(B3)
140
TS(B2)
16
0
TS(B1)
time 200
Bit-Sequences Invalidation Precision
UPDATE UPDATE
UPDATE
x x xx x
xx
TS(Bk)
Td
TS(Bk-1)
TS(Bk-2)
Scenario 1
TS(Bk)
UPDATE UPDATE
UPDATE
x x xx x
xx
Td
TS(Bk-1)
Scenario 2
TS(Bk-2)
Case Studies
Bayou
Odyssey
Rover
Case Study1: Bayou
 Main
Features
 Novel Aspects
 Bayou architecture
 Bayou application-specific conflict resolution
 Bayou replication management
 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
Storage
System
Storage
System
Application
Bayou API
Client Stub
Server State
Client
Read
or
Write
Anti-entropy
Server State
Server
Server
Storage
System
Application
Server State
Storage
System
Bayou API
Client Stub
Read
or
Write
Server
Server State
Client
Server
Application-Specific Conflict Resolution in
Bayou
 Along
with desired update, a write operation includes a
dependency check:

 As
server query & expected query results
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
Resource_id
lower bound
upper bound
name of upcall handler
Request( in path, in resource_descriptor, out request_id)
Cancel(in request_id)
Resource Negotiation Operations
Resource Descriptor Fileds
Handle( in request_id, in resource_id, in resource-level)
Upcall Handler
Network Bandwidth
Network Latency
Disk cache Space
CPU
Battery Power
Money
bytes/second
microseconds
Kilobytes
SPECCint95
minutes
cents
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
application-aware 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



Mobile objects
disconnected operation
dynamic client/server
 Mixed


for:
communication/computation modes:
Relocatable Dynamic Objects (RDO)
Queued Remote Procedure Calls (QRPC)
 Applications
decide to use RDO or QRPC
Relocatable Dynamic Objects (RDO)
 Objects
can be 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)
Queued RPC (QRPC)
 Non-blocking remote
procedure calls, even when fixed
host is disconnected
 Client applications use QRPC to fetch RDO’s. Upon
connection, or when an RDO arrives, the requesting client
is called back
 QRPC is also used to commit updates made to RDO’s
 Non-executed QRPC’s are kept in an operation log
 As network connection comes and goes, the operation
logs are flushed back to the servers
Rover’s 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
 Application-aware adaptation

Rover Exmh (mail browser), Rover Webcal (distributed calendar
system), Rover Irolo (graphical Rolodex tool), and Rover stock
market watcher
Rover: Summary
Applications
Adaptation
Model
Mobile Data
E-mails, appointments, to do lists, reminders,
calendars; and web pages and images.
Application-aware adaptation with the use of Rover
Toolkits that deal with intermittent and lowbandwidth connection and resource-poor clients;
application-transparent adaptation by using Rover
proxies.
Dynamic client-server architecture with the use of
RDO’s.
Asynchronous and disconnected operations with the
support of QRPC.