Client server computing in mobile environments. Versatile, Message based, Modular Infrastructure intended to improve usability, flexibility, interoperability and scalability as compared to Centralized, Mainframe, time sharing computing. Intended to reduce Network Traffic. Communication is using RPC or SQL

1. Client-Server Computing
in Mobile Environments

2. Client-Server Architecture
 Versatile,
Message based, Modular
Infrastructure intended to improve usability,
flexibility, interoperability and scalability as
compared to Centralized, Mainframe, time
sharing computing.
 Intended to reduce Network Traffic.
 Communication is using RPC or SQL
2

3. Mobile Computing and Issues
in Client-Server Environment
 Mobile
Computing a new Paradigm
 Issues


Mobility of Users and their computers
Mobile Resource constraints


Wireless Bandwidth
Limited Battery Life
3

4. Paradigms of Mobile ClientServer Computing
 Mobile


Aware Adaptation
Response to change in environment
Necessary system services that can be utilized
 Extended

Various Architectures that enables functional
participation of applications between client and
servers
 Mobile

Client-Server Model
data Access
Deals with issues like data transfer and consistency of
Client cache
4

5. Mobile-Aware Adaptation
 Dynamically
adjusting the functionality
between the mobile and stationary host to
cater changes like


Variations and changes in Network Conditions
Local resource availability
 Computations
of Clients and Servers should
be adaptive in response to change in mobile
environment.
5

6. Mobile-Aware Adaptation
 Application



Transparent Adaptation
Applications work with no modification in mobile
environment
System shield or proxy is provided which hides
the differences between the stationary and mobile
environments from Applications
The proxy / System shield mitigates to the change
in environment and the change is transparent to
the applications.
6

7. Application Transparent
Adaptation

E.G. File System Proxy (CODA)




File System Proxy hides mobile issues from applications and
emulate file server services on the mobile device.
Proxy Log
Concurrency control after reconnection
Three phases

Hoarding


Emulating



Server Files pre-fetched into Mobile Computers
Upon Disconnection updates are logged
Log optimization is done to improve performance
Reintegrating

Synchronizes cache with the server
7

8. Application Transparent
Adaptation
 Drawbacks
of this approach

Performance is an issue

It may be sometimes very hard for the system
Some manual user intervention may be needed
8

9. Application-Aware Adaptation
 Allows
Applications or their extensions to
react to mobile resource changes
 How?



Collaboration between System and individual
Applications
System monitors resource levels and notifies
applications of relevant changes
Application then adapts to the change
9

10. Application-Aware Adaptation
 It
can be divided into three different
categories



Client- based Application adaptation
Client-server Application adaptation
Proxy-based Application adaptation
10

11. Client- based Application
Adaptation
 In
the Collaborative adaptation ,System
provides mechanisms of adaptation, while
applications are free to specify adaptation
policy
 Application changes or adaptation is done
only on client side
11

12. Client-Server Application
Adaptation





The Rover toolkit supports the application aware
adaptation through the use of RDO
http://www.pdos.lcs.mit.edu/rover/
RDOs are relocatable dynamic objects
RDOs are defined for the data types manipulated by
the application and for the data transported between
client and server
Programmers Task
Benefits to Application Designers


Application designers have semantic knowledge
Can tightly couple data with program code and manage
resources
12

13. Proxy-Based Application
Adaptation
 The
application specific proxy has been
proposed as an intermediary between client
and server
 It performs storage intensive and
computation intensive tasks
 Proxy reduces Bandwidth demands and allow
legacy and non standard client to
communicate with the server
13

14. Extended Client-Server Model
 Classic
client-server systems assume that
the location of client and server hosts do not
change and also the connection among them
does not change
 Functionality between client and server is
statically partitioned
 Extended Client server Architecture thus
deals with these inconsistencies in network
connections and location specifics
14

15. Extended Client-Server Model
 Thin
 Full
client architecture
client architecture
 Flexible
client architecture
15

16. Thin client architecture
16

17. Full-Client Architecture
 Can
support disconnected or weakly
connected client
 The full client architecture supports
emulations of functions of server at client
host
 Light weight servers or proxy
 E.G CODA , WebExpress
17

18. Flexible Client-Server
Architecture


Generalizes both thin
client and full client
architecture
Connection between
client and server can be
dynamically established
18

19. Mobile Objects
 Programming
entities that can freely roam the
network
 Mobile objects allow clients to download the
server code to mobile host for execution
 They can maintain state information and
make intelligent decisions
 Challenge in using mobile objects?

Frequently disconnected or weak environment
19

20. Collaborative Groups
 Division
of members into groups
 Members can access data for the group
 A client is able to access data residing on
server to which it is communicating and
conversely any machine holding the copy of
the database, including personal laptop,
should be willing to server read and write
requests from nearby machines
 E.G Bayou system
20

21. Flexible Client-Server
Architecture
 Application


Proxy acts an intermediary between clients and
server
Allows legacy and other non-standard clients to
interoperate with existing servers
 Virtual

specific proxy
mobility of servers
Achieved by replication
21

22. Mobile Data Access


Mobile data access enables the delivery of server
data and the maintenance of client-server data
Data Access strategies in mobile environment can
be characterized by




Data delivery
Data organization
Consistency requirement
Server Data Delivery Modes



Client –pull
Server-push
Hybrid delivery
22

23. Server Data Dissemination
 Asymmetrical
communication between clients
and server
 Scalability problems for applications with
asymmetrical communication
 Solution: Broadcast –based dissemination
 Broadcast disk
 Indexing on air


Increases query time
Decreases Listening time
23

24. Client Cache Management
 Caching
reduces contention and improves
query response time
 Cache data can support disconnected
operations
 Automated Hoarding
 Varied Granularity of Cache coherence


Callback Approach
Detection Approach
24

25. Disconnected Operation
in a Mobile Computing
Environment

26. 1. Introduction
 Key
requirement of portable computers
→ the ability to access critical data
regardless of location
 Constraints of mobile elements



resource-poor
more prone to loss, destruction, and subversion
must operate under a much broader range of
networking conditions
 Ideally,
mobility should be completely
26
transparent to users

27. 2. Overview of Coda File
System
 Design
optimized for the access and
sharing patterns typical of academic and
research environments
HDB
 Server



replication
ni
ro
ch
yn
s
volume storage group (VSG)
accessible VSG (AVSG)
reintegration
callback-based caching
 Disconnected

hoarding
operation
venus services by
relying on its cache
dis
c
d
ze
on
ne
c
tio
n
emulation
reconnection
Client modify
log
27

28. 3. Implementation Status
1990
1991
1992
1993
October
•minimal functionality
was demonstrated
•a more complete version
•began to be used regularly by
members of the Coda group
•almost all of the functionality
•user community had expanded
outside the Coda group
•about 30 users,
of whom about 20
use on a regular basis
•performance tuning and
bug-fixing
28

29. 3. Implementation Status
(cont’d)
 Server


three DECStation 5000/200 with 2GB HDD
150 volumes



25% - user volumes
65% - project volumes
10% - system volumes
 Clients

15 desktops : DECStation 5000/200, Sun
Sparcstation, IBM RT

user and project volumes - Coda / system volumes 29
AFS

30. 4. Qualitative Evaluation
 The


nature of testbed environment
voluntary disconnected operation of mobile user
involuntary disconnection of desktop user when
Coda server crash
4.1. Hoarding

substantially improved the usefulness of disconnected
operation
 hoard


profiles
common method of user/HDB interactions
little direct sharing of profiles among users
30

31.  multi-level

hoard priorities
only a single level of hoard priority in earliest Coda
design
→ an object was either sticky or not



much more time and effort
reduce the ability of users to hoard effectively
frequent disconnected misses
 meta-expansion

reduce the verbosity of hoard profiles and simplify
their maintenance



c
d
+
: the command applies to immediate children
: the command applies to all descendants
: the command applies to all future
31

32.  reference

spy program

record all file references observed by Venus
 periodic

hoard walking
background equilibration of the cache


guard a user who forgets to demand a hoard walk
before voluntary disconnecting
prevents a huge latency hit if and when a walk
demanded
 demand

spying
hoard walking
foreground cache equilibration

invoked before voluntary disconnecting
32

33. 4.2. Server emulation
 transparency

high degree of transparency attribute to a single
client agent supporting both connected and
disconnected operation
 cache

experienced no cache misses



misses
hoarding
most disconnections were voluntary
when disconnected misses occur


block processes
switch to another task
33

34. 4.3. Reintegration
 performance


taken less than a minute to complete (mainly 5~20
seconds)
reintegration storm


server returns a busy message
break operation logs into independent parts
 detected


failures
very rare, however, due to bugs rather than update
conflicts
Venus writes out the operation log and related
container files to a local file called a closure
34

35. 4.4. Other observations
 optimistic replication

vs. pessimistic protocol
 security


no detected violations of security in use of Coda
Coda servers demand to see a user’s credentials
on every client request
 public


workstations
never a primary goal to support disconnected
operation in this domain
not well suited to public access conditions


security problem
hoarding latency
35

36. 5. Quantitative Evaluation



How large a local disk does one need?
How noticeable is reintegration?
How important are optimizations to the operation log?
5.1. Methodology


trace-replay all reference to Coda, AFS or the
local file system
five 12-hour workdays and five week-long
activities
High-water mark : the maximum cache space
in use until current time
5.2. Disk space requirements
36

37. 5.3. Reintegration latency

Back-fetching : the transfer of data from client to server representing disconnected file store
operation
Reintegration Latency
37

38. 5.4. Value of log optimizations
Optimized vs. Unoptimized Cache Space High-Water Marks
Optimized vs. Unoptimized Space Usage
38

39. 6. Work in Progress
 Exploiting

rapid cache validation


large granularity callbacks
trickle reintegration


weak connectivity
log optimization with aging
user-assisted miss handling


patience threshold
status walk & data walk
39

40. 7. Conclusion
 Disconnected
operation is the newer concept
and central to solving the mobile computing
problem
 Importance of server replication
 None of the shortcomings exposed are fatal
 They all point to desirable ways in which the
system should evolve
 Actively refining the Coda system
40