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

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

4

Paradigms of Mobile Client-Server Computing

Mobile Aware Adaptation Response to change in environment Necessary system services that can be utilized

Extended Client-Server Model Various Architectures that enables functional

participation of applications between client and servers

Mobile data Access Deals with issues like data transfer and consistency of

Client cache

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.

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.

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

Server Files pre-fetched into Mobile Computers Emulating

Upon Disconnection updates are logged Log optimization is done to improve performance

Reintegrating Synchronizes cache with the server

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

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

10

Application-Aware Adaptation

It can be divided into three different categories

Client- based Application adaptation Client-server Application adaptation Proxy-based Application adaptation

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

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

13

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

Proxy-Based Application Adaptation

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

15

Extended Client-Server Model

Thin client architecture

Full client architecture

Flexible client architecture

16

Thin client architecture

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

18

Flexible Client-Server Architecture

Generalizes both thin client and full client architecture

Connection between client and server can be dynamically established

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

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

21

Flexible Client-Server Architecture

Application specific proxy Proxy acts an intermediary between clients and

server Allows legacy and other non-standard clients to

interoperate with existing servers Virtual mobility of servers

Achieved by replication

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

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

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

Disconnected Operationin 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 transparent

to users

27

2. Overview of Coda File System

Design optimized for the access and sharing patterns typical of academic and research environments

Server replication

volume storage group (VSG) accessible VSG (AVSG) callback-based caching

Disconnected operation venus services by

relying on its cache

hoarding

emulationreintegration

disconnection

reconnection

sync

hron

ized

HDB

Client modifylog

28

3. Implementation Status1990 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

•performance tuning and bug-fixing

•about 30 users, of whom about 20 use on a regular basis

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 - AFS

25 laptops : mostly 386-based IBM PS2/L40 completely dependent on Coda

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

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 : the command applies to immediate

children d : the command applies to all descendants + : the command applies to all future

32

reference spying 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 hoard walking foreground cache equilibration

invoked before voluntary disconnecting

33

4.2. Server emulation transparency

high degree of transparency attribute to a single client agent supporting both connected and disconnected operation

cache misses experienced no cache misses

hoarding most disconnections were voluntary

when disconnected misses occur block processes switch to another task

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

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

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

5.2. Disk space requirements

High-water mark : the maximum cache space in use until current time

37

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

operation

Reintegration Latency

38

5.4. Value of log optimizations

Optimized vs. Unoptimized Cache Space High-Water Marks

Optimized vs. Unoptimized Space Usage

39

6. Work in Progress

Exploiting weak connectivity rapid cache validation

large granularity callbacks trickle reintegration

log optimization with aging user-assisted miss handling

patience threshold status walk & data walk

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