Mobile and Wireless Access for Pervasive Computing

1
Mobile and Wireless Access for Pervasive Computing

• Krithi Ramamritham
• IIT Bombay

2
Outline

• Motivating Example
• Issues Mobility, Wireless Communication,
  Portability
• Adaptability and Mobile Client-Server Models
• Location Management
• Broadcast data dissemination
• Disconnected database operations
• Mobile Access to the Web
• Mobility in Workflow Systems
• State of Mobile DB Industry and Research Projects
• Unsolved Problems

3
Mobile and Wireless Computing

• Goal Access Information Anywhere, Anytime,
  and in Any Way.
• Aliases Mobile, Nomadic, Wireless, Pervasive,
  Invisible, Ubiquitous Computing.
• Distinction
• Fixed wired network Traditional distributed
  computing.
• Fixed wireless network Wireless computing.
• Wireless network Mobile Computing.
• Key Issues Wireless communication, Mobility,
  Portability.

4
Mobile Network Architecture
5
Mobile Applications

• Expected to create an entire new class of
  Applications
• new massive markets in conjunction with the Web
• Mobile Information Appliances - combining
  personal computing and consumer electronics
• Applications
• Vertical vehicle dispatching, tracking, point of
  sale
• Horizontal mail enabled applications, filtered
  information provision, collaborative computing

6
Broadcast Data Dissemination

• business data, e.g., Vitria, Tibco
• election coverage data
• stock related data
• traffic information
• sportscasts, e.g., Praja
• Datatacycle Herman
• Broadcast disks

7
Wireless Communication

• Cellular - GSM (Europe), TDMA CDMA (US)
• FM 1.2-9.6 Kbps Digital 9.6-14.4 Kbps
  (ISDN-like services)
• Public Packet Radio - Proprietary
• 19.2 Kbps (raw), 9.6 Kbps (effective)
• Private and Share Mobile Radio
• Wireless LAN - wireless LAN bridge (IEEE 802.11)
• Radio or Infrared frequencies 1.2 Kbps-15 Mbps
• Paging Networks typically one-way communication
• low receiving power consumption
• Satellites wide-area coverage (GEOS, MEOS,
  LEOS)
• LEOS 2.4 Kbps (uplink), 4.8Kbps (downlink)

8
Future Wireless Communication

• Source Rysavy Research, 1999

9
Wireless characteristics

• Variant Connectivity
• Low bandwidth and reliability
• Frequent disconnections
• predictable or sudden
• Asymmetric Communication
• Broadcast medium
• Monetarily expensive
• Charges per connection or per message/packet
• Connectivity is weak, intermittent and expensive

10
Portable Information Devices

• PDAs, Personal Communicators
• Light, small and durable to be easily carried
  around
• dumb terminals InfoPad, ParcTab projects,
• palmtops, wristwatch PC/Phone, walkstations
• will run on AA /Ni-Cd/Li-Ion batteries
• may be diskless
• I/O devices Mouse is out, Pen is in
• wireless connection to information networks
• either infrared or cellular phone
• specialized HW (for compression/encryption)

11
Portability Characteristics

• Battery power restrictions
• transmit/receive, disk spinning, display, CPUs,
  memory consume power
• Battery lifetime will see very small increase
• need energy efficient hardware (CPUs, memory) and
  system software
• planned disconnections - doze mode
• Power consumption vs. resource utilization

12
Portability Characteristics

• Resource constraints
• Mobile computers are resource poor
• Reduce program size interpret script languages
  (Mobile Java?)
• Computation and communication load cannot be
  distributed equally
• Small screen sizes
• Asymmetry between static and mobile computers

13
Mobility Characteristics

• Location changes
• location management - cost to locate is added to
  communication
• Heterogeneity in services
• bandwidth restrictions and variability
• Dynamic replication of data
• data and services follow users
• Querying data - location-based responses
• Security and authentication
• System configuration is no longer static

14
Recurrent Themes

• Handling disconnections (planned failures?)
• caching strategies
• managing inconsistencies
• Delayed write-back and prefetch use network idle
  times
• increases memory requirements
• Buffering/batching allows bulk transfers
• Partitioning and replication
• triggered by relocation
• Compression increase effective BW
• increases battery power requirements
• Receiving needs less power than sending

15
Issues in Information Provision

• tariff
• scalability massive users accessing read-only
  data
• security (of data and user profiles/location)
• impersonation, theft, trust
• consuming resources in a foreign environment
• damage to fixed hosts?
• approximate answers
• consistency, autonomy, recovery
• PDAs are unreliable
• prioritization of actions upon reconnection
• providing uniform access in a heterogeneous
  environment
• design of human-computer interfaces (pen-based
  computing)

16
Mobility in Db Applications

• Need to adapt to constantly changing environment
• network connectivity
• available resources and services
• By varying and (re)negotiating
• the partition of duties between the mobile and
  static elements
• the quality of data available at the mobile host
• Example Fidelity (degree to which a copy of data
  matches the reference copy at the server)

17
Adaptive Applications

• Need
• Measurement of QoS and communication with
  application
• A mechanism to monitor the level and quality of
  information and inform applications about
  changes.
• Programmer Interface for Application-Aware
  Adaptation
• Applications must be agile able to reveive
  events in an asynchronous manner and react
  appropriately
• A central point for managing resources and
  authorizing any application-initiated request.

18
C-SA-C Server-side Agent

• C-SA-C The Client/Server-side Agent/Server
  Model
• Splits the interaction between the mobile client
  and server client-agent and agent-server
• different protocols for each part of the
  interaction
• each part may be executed independently of the
  other

19
Responsibilities of the Agent

• Messaging and queying
• Manipulate data prior to their transmission to
  the client
• perform data specific compression
• batch together requests
• change the transmission order

20
Role of the Agent

• Surrogate or proxy of the client
• Any communication to/from the client goes through
  the agent
• Offload functionality from the client to the
  agent
• Application (service) specific
• provides a mobile-aware layer to specifc services
  or applications (e.g., web-browsing or database
  access)
• handles all requests from mobile clients
• Filters
• provide agents that operate on protocols
• E.g., an MPEG-agent or a TCP-agent

21
C-CA-S Client-side Agent

• C-SA-S The Client/Client-side Agent/Server Model
• caching
• background prefetching and hoarding
• various communication optimizations

22
C-I-S Client Server Agents
Wireless Link
Fixed Network
Agent
Client
Server
Agent
Mobile Host

• C-I-S Client/Intercept/Server Model
• Caching, prefetching etc
• various communication optimizations at both ends
• E.g., asynchronous queued RPC
• relocate computation between the agents
• Client interoperability

23
Mobile Agents

• Mobile agents are migrating processes associated
  with an itinerary
• dynamic code and state deployment
• Implement the agents of the previous
  architectures as mobile agents, E.g.,
• server-side agents can relocate during handoff
• client-side agent dynamically move on and off the
  client
• Relocatable dynamic objects (RDO) Rover
• Implement the communication using mobile agents
• clients submit/receive mobile agents to/from the
  server
• E.g., Compacts Pro-Motion

24
Outline

• Motivating Example
• Issues Mobility, Wireless Communication,
  Portability
• Adaptability and Mobile Client-Server Models
• Location Management
• Broadcast data dissemination
• Disconnected database operations
• Mobile Access to the Web

25
Locating Moving Objects

• Example of moving objects
• mobile devices (cars, cellular phones, palmtops,
  etc)
• mobile users (locate users independently of the
  device they are currently using)
• mobile software (e.g., mobile agents)
• How to find their location - Two extremes
• Search everywhere
• Store their current location everywhere
• Searching vs. Informing

26
Architectures of Location DBs

• Two-tier Schemes (similar to cellular phones)
• Home Location Register (HLR) store the location
  of each moving object at a pre-specified location
  for the object
• Visitor Location Register (VLR) also store the
  location of each moving object mo at a register
  at the current region
• Hierarchical Schemes
• Maintain multiple registries

27
Two-tier Location DBs

• Search
• Check the VLR at your current location
• If object not in, contact the objects HLR
• Update
• Update the old and new VLR
• Update the HLR

28
Hierarchical Location DBs
Maintain a hierarchy of location registers
(databases) A location database at a higher level
contains location information for all objects
below it

29
Hierarchical Location DBs
Call
caller
30
Hierarchical Location DBs
Move
new location
old location
31
Hierarchical vs. Two-tier
() No pre-assigned HLR () Support
Locality (-) Increased number of operations
(database operations and communication
messages) (-) Increased load and storage
requirements at the higher-levels
32
Locating Moving Objects
Partitions
P3
P4
P5
P1
P2
User x
User x
33
Locating Moving Objects

• Caching
• cache the callees location at the caller
• (large Call to Mobility Ratio)
• Replication
• replicate the location of a moving object at its
  frequent callers (large CMR)
• Forwarding Pointers
• do not update the VLR and the HLR, leave a
  forwarding pointer from the old to the new VLR
  (small CMR)
• When and how forwarding pointers are purged?
• Concurrency, coherency and recovery/checkpointing
  of location DBs

34
Querying Moving Objects

• Besides locating moving objects, answer more
  advanced queries, e.g.,
• find the nearest service
• send a message to all mobile objects in a
  specific geographical reafion
• Location queries spatial, temporal or
  continuous
• Issues representation, evaluation and
  imprecision

Most current research assumes a centralized
location database
35
Querying Moving Objects

• How to model the location of moving objects?
• Dynamic attribute (its value change with time
  without an explicit update) e.g., in MOST
• For example, dynamic attribute A with three
  sub-attributes A.value, A.updatetime and
  A.function
• (function of a single variable t that has value
  0 at time t0)
• The value of A at A.updatetime is A.value
• at time A.updatetime t0 is A.value
  A.function(t0)

36
Querying Moving Objects

• How to represent and index moving objects?
• Spatial indexes do not work well with
  dynamically changing values
• Value-time representation
• An object is mapped to a trajectory Kollios
  99

37
Outline

• Motivating Example
• Issues Mobility, Wireless Communication,
  Portability
• Adaptability and Mobile Client-Server Models
• Location Management
• Broadcast data dissemination
• Disconnected database operations
• Mobile Access to the Web

38

Broadcast

• Broadcast as an air-cache for storing frequently
  requested data
• Continoulsy adjust the broadcast content to
  match the database hot-spot
• How? By observing the broadcast misses -
  requests for data not on the broadcast

39

Information
Dissemination

• Goal Maximize query capacity of servers,
  minimize energy per query at the client.
• Focus Read-only transactions (queries).
• Clients send update data to server
• Server resolves update conflicts, commits updates
• 1. Pull PDAs demand, servers respond.
• backchannel (uplink) is used to request data and
  provide feedback.
• poor match for asymmetric communication.

40
Information Dissemination

• 2. Push Network servers broadcast data, PDA's
  listen.
• PDA energy saved by needing receive mode only.
• scales to any number of clients.
• data are selected based on profiles and
  registration in each cell.

41
Information Dissemination

• 3. Combinations Push and Pull (Sharing the
  channel).
• Selective Broadcast Servers broadcast "hot"
  information only.
• "publication group" and "on-demand" group.
• On-demand Broadcast Servers choose the next item
  based on requests.
• FCFS or page with maximum of pending requests.

42
Organization of Broadcast data

• Flat broadcast the union of the requested data
  cyclic.
• Skewed (Random)
• broadcast different items with different
  frequencies.
• goal is that the inter-arrival time between two
  instances of the same item matches the clients'
  needs.

43
Broadcast Disks

• Multi-Disks Organization Acharya et. al,
  SIGMOD95
• The frequency of broadcasting each item depends
  on its access probability.
• Data broadcast with the same frequency are viewed
  as belonging to the same disk.
• Multiple disks of different sizes and speeds are
  superimposed on the broadcast medium.
• No variant in the inter-arrival time of each item.

A B A C
44

Selective
Tuning

• Basic broadcast access is sequential
• Want to minimize client's access time and tuning
  time.
• active mode power is 250mW, in doze mode 50µW
• What about using database access methods?
• Hashing broadcast hashing parameters h(K)
• Indexing index needs to be broadcast too
• "self-addressable cache on the air"
• () "listening/tuning time" decreases
• (-) "access time" increases

45
Access Protocols

• Two important factors affect access time
• Size of the broadcast
• Directory miss factor - you tune in before your
  data but after your directory to the data!
• Trade-Off ? Size means ? Miss factor
• Trade-Off ? Size means ? Miss factor

46
Indexing

• (1,M) Indexing
• We broadcast the index M times during one version
  of the data.
• All buckets have the offset to the beginning of
  the next index segment.
• Distributed Indexing
• Cuts down on the replication of index material
• Divides the index into
• replicated top L levels, non-replicated bottom
  4-L levels
• Flexible Indexing
• Broadcast divided into p data segments with
  sorted data.
• A binary control index is used to determine the
  data segment
• A local index to locate the specific item within
  the segment

47

Caching in
Broadcasting

• Data are cache to improve access time
• Lessen the dependency on the server's choice of
  broadcast priority
• Traditionally, clients cache their "hottest" data
  to improve hit ratio
• Cache data based on PIX
• Probability of access (P)/Broadcast
  frequency (X).
• Cost-based data replacement is not practical
• requires perfect knowledge of access
  probabilities
• comparison of PIX values with all resident pages
• Alternative LIX, LRU with broadcast frequency
• pages are placed on lists based on their
  frequency (X)
• lists are ordered based on L, the running avg. of
  interaccess times
• page with lowest LIX L/X is replaced

48
Prefetching in Broadcasting

• Client prefetch page in anticipation of future
  accesses
• No additional load to the server and network
• Prefetching instead of waiting for page miss can
  reduce the cost of a miss
• PT prefetching heuristic Archarya et al. 96
• - pt Access Probability (P) period (T) before
  page appears next
• - A broadcast page b replaces the cached page c
  with lowest pt value
• Team tag - Teletext approach Ammar 87
• Each page is associated with a set of pages most
  likely to be requested next
• When p is requested, D (Dcache size) associated
  pages are prefetched
• Prefetching stops when client submit a new
  request

49

Cache
Invalidation Techniques

• When?
• Synchronous send invalidation reports
  periodically
• Asynchronous send invalidation information for
  an item as soon as its value changes E.g., Bit
  Sequences Jing 95
• To whom?
• Stateful server to affected clients
• Stateless server broadcast to everyone
• What?
• invalidation only which items were updated
• propagation the values of updated items are sent
• aggregated information/ materialized views

50

Synchronous
Invalidation

• Stateless servers are assumed.
• Types of client Workalcholic and sleepers
  Barbara Sigmod 94
• Strategies
• Amnestic Terminals broadcast only the
  identifiers of the items that changed since the
  last invalidation report
• abort T, if x ? RS(T) appears in the
  invalidation report
• Timestamp Strategy broadcast the timestamps of
  the latest updates for items that have occurred
  in the last w seconds.
• abort T, if ts(x) gt
  tso(T)
• Signature Strategy broadcast signatures.
• A signature is a compressed checksum similar to
  the one used for file comparison.

51

Consistency and
Currency

• Only committed data are included in the broadcast
• Does a client read current and consistent data?
• Currency interval is the fraction of bcycle that
  updates are reflected
• Span(T) is the of currency intervals from which
  T read data
• if Span(T) 1, the T is correct (read consistent
  data)
• else ?
• ... several consistency models

52
Consistency Criteria

• Latest value clients read the most recent value
  of a data item Garcia-Molina TODS82, Acharya
  VLDB96
• Serializability Certification reports Barbara
  ICDCS97
• Update consistency clients commit of their reads
  are not invalidated read mutually consistent
  data
• F-Matrix method Shanmugasundaram SIGMOD99
• 2-level serializability Each client is
  serializable with respect to the server
• SGT method PitouraChrysanthis ICDS99
• Multiversion PitouraChrysanthis VLDB99

53
Currency in Multiversion Schemes

Multiversioning with invalidation
Versioning Multiversioning
Invalidation
begin (first read)
first invalidation
commit
Ts lifetime
10
VLDB 1999
54
Adaptive Hybrid Broadcast

• Cycle-based, bidirectional hybrid broadcast
  server
• Issues
• Dynamic computation of bandwidth allocated to
  each broadcast mode
• Dynamic classification of data items (periodic
  vs. on-demand)
• Scheduling periodic and on-demand broadcasts

55
An Approach

• After each broadcast cycle, items classified as
  periodic or on-demand, depending on bandwidth
  savings expected
• Periodic broadcast occupies up to BWThreshold
• Periodic broadcast program is computed to satisfy
  all deadlines of periodic data
• On-demand broadcast uses on-line EDF
• (Earliest Deadline First) algorithm batching

56
Outline

• Motivating Example
• Issues Mobility, Wireless Communication,
  Portability
• Adaptability and Mobile Client-Server Models
• Location Management
• Broadcast data dissemination
• Disconnected database operations
• Mobile Access to the Web
• Mobility in Workflow Systems
• State of Mobile DB Industry and Research Projects
• Unsolved Problems

57
Database Systems Issues

• Issues
• Battery power restrictions
• Resource restrictions
• Bandwidth restrictions and variability
• Frequent/planned disconnections
• Solutions
• Power conservation techniques
• Wireless broadcast, broadcast disks
• Disconnected operations
• Hoarding, caching, prefetching, consistency
  management
• Programmer Interface for Application-aware
  Adaptation.

58
Disconnected Operations

• Issues
• Cache misses are more expensive in mobile
  environments.
• Data availability for disconnected operation
• Data consistency given that global communication
  is costly
• Autonomy vs. Consistency
• Solutions
• Caching
• Prefetching
• Hoarding
• Eventual consistency
• Assumption simultaneous sharing other than
  read is rare.
• Update conflict detection/resolution

59
Caching for Disconnection

• What to cache?
• Entire files, directories, tables, objects
• Portions of files, directories, tables, objects
• When to cache? Is simple LRU sufficient?
• LRU captures an aspect of temporal locality
• Predictive/semantic caching based on the
  semantics distance between data/request
• E.g., clustering of queries Ren 99

60
Prefetching

• Online strategy to improve performance
• prepaging
• prefetching of file
• prefetching of database objects
• What to fetch?
• access tree (semantic structure)
• probabilistic modeling of user behavior
• Old idea that can be used during network idle
  times
• Combine delayed writeback and prefetch

61
Hoarding

• Planned and Accidental disconnections are not
  considered failures.
• New idea - Hoarding
• a technique to reduce the cost of cache misses
  during disconnection.
• That is, load before disconnect and be ready.
• How to do hoarding?
• user-provided information (client-initiated
  disconnection)
• explicitly specify which data
• Implicitly based on the specified application
• access structured-based (use past history)
• E.g., tree-based in file systems, access paths
  (joins) in DBs

62
Hoarding in DB Systems

• Granularity of Hoarding
• RDBMS ranges from tables, set of tables, whole
  relations
• OO OR DBMS objects, set of objects or class
• Hoard by issuing queries or materialized views
• User may explicit issue hoarding queries
• E.g., Create View with Update-On clause Lauzac
  98
• OO query to describe hoarding profiles
  Gruber 94
• History of past references both queries and data
  objects
• Hoard Keys - an extended database organization
  Badrinath 98
• hoard keys are used to partition a relation in
  disjoint logical horizontal fragments

63
Processing the Log

• What information to keep in the log for effective
  reintegration and log optimization?
• Data values, timestamps, operations
• Goal Keep the log size small to
• Save memory
• Reduce cost for update propagation and
  reintegration
• When to optimize the log
• Incrementally each time a new operation is added
• Before propagation or integration
• Optimizations are system specific
• E.g., keep last write record, drop records of
  inverted operations

64
Cache Coherence/Data Consistency

• "Lazy" or weak consistency promises high
  availability
• Consider some conflicts (e.g., write-write
  conflicts)
• Read-any/Write-any
• Other schemes are costly
• Pessimistic replication schemes/Quorum schemes
• Server-initiated callbacks for cache invalidation
  (e.g., Leases).
• Optimistic replication schemes
• System support for
• detection of conflicts version vector,
  timestamps
• automatic resolution or manual resolution (tools)

65
Techniques to Increase Autonomy

• Mobile Database Consistency
• When a mobile database M shares a data item with
  another database D, it is involved in a global
  integrity constraint C.
• Transactions on both M and D may suffer
  unbounded and unpredictable delays - No local
  commitment.
• What about localizing the constraints no global
  constraints?
• Localization
• reformulates C so that M accepts a local
  constraint C instead
• Local transactions remain local.
• When C is violated at a node, it requests the
  others for re-localization, i.e., a dynamic
  readjustment of C.
• No need for a distributed transaction.
• No inconsistency from concurrent requests

66
Localization of Constraints

• Simple Example
• Let x and y be two data items at two nodes.
• C J.x K.y gt D is a global constraint.
• Localization yields two local constraints
• x gt L1 and y gt L2
• where L1 and L2 are constants chosen such that
  J.L1 K.L2 gt D
• Re-localization L1, L2 can be changed node y
  increases L2 before node x decreases L1

67
Localization Methods

• Escrowing Logically partitions aggregated items
• Escrow transactions ONeil 86
• Demarkation protocol Barbara 91
• Geormetric Method Mazumdar 99 Enhanced
  Escrowing
• It tackles quadratic inequalities
• Fragmentation Walborn 95 Physically
  partitions item with constraints localized within
  the individual fragments
• Fragmentable objects fragments are merged to the
  originating position
• Reorderable Objects fragments can be
  re-organized during the merging

68
Two-tier Transaction Models

• Tentatively Committed Transactions
• Transactions tentatively commit on a mobile unit
• Make their results locally visible leading to
  abort dependencies
• Certification based on application or system
  defined criteria
• invalidated trans. are aborted, reconcile, or
  compensated
• Isolation-Only Transactions Lu 94
• First-class transactions for connected operations
• immediately commit at the server, globally
  serializable
• Second-class transactions for disconnected
  operations
• tentatively commit, locally serializable, no
  failure atomicity
• validation criteria global serializability,
  global certifiability
• invalidated trans. are aborted, reexecuted, or
  compensated.

69
Two-tier transaction Models

• Two-tier Replication Gray 95
• Base transactions and Tentative transactions
  (disconnected)
• Upon reconnection, tentative transactions are
  reprocessed as base transactions on master data
  version
• Application semantics are used to increase
  concurrency and acceptance (e.g., commutative
  operations)
• (Mobile) Escrow Transactions
• Transactions are validated locally by localizing
  constraints
• Local commitment ensures global commitment

70
Mobile Transactions

• Distributed transactions involving both mobile
  and fixed hosts.
• Traditional approaches are too restrictive.
• Mobile Open Nested Transactions Chrysanthis 93
• Goals sharing of partial results while in
  execution,
• maintaining computation state on a fixed
  host,
• moving transactions on/off a mobile host
  and across fixed hosts.
• Components Atomic transactions, Compensatable
  transaction, Reporting transactions and
  Co-transactions.
• Properties Component isolation, semantic
  atomicity Components may commit/abort
  independently

71
Mobile Transactions

• Kangaroo Transactions Dunham 97
• Transaction relocation is achieved by splitting
  the transaction during hand-off. One Joey
  transaction per cell.
• The Clustering Model Pitoura 95
• A distributed database is divided into weak and
  strict clusters
• Data in a cluster are mutually consistent
• Inconsistency between clusters is bounded and
  resolved by merging them either
• during transaction commitments, or
• when connectivity improves
• A mobile transaction is decomposed into Strict
  and Weak transactions based on consistency
  requirements
• Only strict transactions ensure durability and
  currency of reads

72
Failure Recovery

• Emphasis has been on recording global checkpoints
• Periodically store the state of a distributed
  application with mobile components.
• DB Failure Recovery Logging and checkpointing
• Failures can be soft or hard
• Soft failure can be recovered from the locally
  stored log and checkpoint
• Hard failure require hard checkpoints stored in
  the fixed network.
• Issues
• When to propagate the log and create a hard
  checkpoint?
• Where to store hard checkpoints to speed up
  recovery and reduce its cost?

73
Outline

• Motivating Example
• Issues Mobility, Wireless Communication,
  Portability
• Adaptability and Mobile Client-Server Models
• Location Management
• Broadcast data dissemination
• Disconnected database operations
• Mobile Access to the Web
• Mobility in Workflow Systems
• State of Mobile DB Industry and Research Projects
• Unsolved Problems

74
Database Interface

• Desirable features
• Semantic simplicity formulation of queries
  without special knowledge
• Interaction with a pointing device
• Disconnected query specification
• QBI (Query By Icons) Massari-Chrysanthis 95
• Iconic language requiring minimum typing
• Semantic data model that hides details
• Metaquery tools for query formulation during
  disconnections

75
Mobile Access to the Web

• Three-tier Architectures Client - Web Server -
  Data Server
• Web Server can act like a server-side agent
• Prefetching at its cache can hide some latency
• Scripts at the Web server can perform
  user-specified filtering and processing.
• Most solutions use a Web proxy to avoid any
  changes to the browsers and servers.
• Pythia Fox96
• Mobile Browser (MOWSER) Joshi 96
• Distillation highly lossy, real-time,datatype
  specific compression that preserves semantic
  content
• WebExpress Housel 97

76
WebExpress

• Utilizes the C-I-S Model
• Goals reduce traffic volume and reduce latency
• Intercept any http request and perform four
  optimizations
• Caching at both CSA SSA of graphics and html
  objects
• Differencing only changes are communicated
• Long-live TCP/IP Connection CSA SSA use a
  single TCP connection
• Header reduction SSA includes the required
  browser capabilities. They are not sent by the
  CSA.
• While disconnected (off-line mode) uses CSA cache

77
Advances in Mobile Web Servers

• W4 for Wireless WWW bartlett 94 Mosaic on PDA
• Dynamic Documents Tcl scripts that execute
  within the mobile browser to customize the html
  documents
• Dynamic URLs Mobisaic 94 They support mobile
  web servers and work with active pages.
• IPiC Shrinivasan 99 A match head sized web
  server

78
Mobility in Workflows

• Workflows are automated business processes.
• involve coordinated execution of multiple
  long-running tasks or activities
• Workflow system coordinates the workflow
  execution.
• Processing entities (clients) are where the
  activities are executed and can be mobile.
• disconnections among procesing entities (clients)

79
Workflow Disconnected Operations

• A pessimistic approach Exotica
• Prior to disconnection, each client
• reserves the activities it plans to work by
  locking
• hoards the relative to the activities data
  (requests from the server the input containers of
  the activities)
• During disconnection,
• stores results in its local stable memory
• Upon reconnection,
• the results are reported back to the server

80
Mobile Agents in Workflows

• A Mobile Agent Workflow Model INCAS
• No centralized workflow server
• Each workflow process is model as a mobile agent
  called Information Carrier (INCA). Each INCA
• encapsulates the private data of the workflow
• carries a set of rules that control the flow
  between the activities of the INCA computation
• maintains the history (log) of its execution
• Each INCA is initially submitted to a procesisng
  entity (client) and roams among processing
  entities to achieve its goal

81
Outline

• Motivating Example
• Issues Mobility, Wireless Communication,
  Portability
• Adaptability and Mobile Client-Server Models
• Location Management
• Broadcast data dissemination
• Disconnected database operations
• Mobile Access to the Web
• Mobility in Workflow Systems
• State of Mobile DB Industry and Research Projects
• Unsolved Problems

82
Mobility Middleware in the Market

• Most middleware market are based on TCP/IP and
  socket-oriented connections
• Wireless-friendly TCP versions have been proposed
  but no major products adopted it
• Microsofts Remote Access supports cellular
  communication by integrating Shivas PPP suite
• Shivas PPP (Point-to-Point protocol) suit
  provide a remote access client to either wired or
  mobile servers
• E.g., mobile clients can access Tuxedo
  transaction services
• MobileWare Office Server An agent-based
  middleware that supports Lotus Notes, Web access,
  database replication, etc.
• Connection profiles, checkpointing,compression,
  security

83
State of Mobile DB Industry

• Sybase SQL Remote (Sybase SQL AnyWhere)
• MobiLink Centralized model to control
  replication
• Application-specific bi-directional
  synchronization using scripts
• UltraLite in-memory dbms (50KB)
• ORACLE
• Oracle Mobile Agents middleware
• Oracle 8 Lite supports bi-directional
  replication between a client and a server
  (50-750KB)
• Oracle Replication Manager supports replication
  across multiple servers based on the peer-to-peer
  model
• MS SQLServer
• Merge replication and conflict resolution
• Alternative clients Outlook and MS ACCESS
• IBM DB2 Everywhere (100KB)

84
Case Study Coda

• Client-Server System with two classes of
  replication w.r.t. consistency
• Disconnected vs. Weakly connected
• Hoarding, Caching/Server callback, No Prefetching
• During connections Allows AFS clients (Venus)
  to hoard files.
• hierarchical, prioritized cache management ?
  equilibrium.
• track dependencies, bookmarks
• During disconnections Venus acts as (emulates)
  a server
• generates (temp) fids, services request to
  hoarded files.
• On reconnection, Venus integrates locally
  changed files to servers.
• Considers only write-write conflicts - no notion
  of atomicity
• User conflict resolution/ Application-aware
  adaptation Odyssey
• Use optimistic replication technique

85
Coda Client Space Management

• Space requirements - 10MB
• space for hoarding applications
• space use during Emulation (in particular
  logging)
• space for Recoverable Virtual Memory (cache
  directory, symbolic link, status of block etc.)
• Free disk space techniques
• compression of file cache and RVM (space vs.
  computation time)
• abort updates made by users (reduce log space)
• allow file cache and RVM to be copy to flush
  cards/floppy disks.

86
Case Study Consistency in Bayou

• A bottom-up approach to specific design problems
• more distributed than coda, more emphasis on
  "small" clients
• Key features
• read-any/write-any to enhance availability
• anti-entropy protocol for eventual consistency
• dependency checks on each write
• dependency set
• If queries (run at server) do return the expected
  results
• Application-specific resolution of update
  conflicts
• Primary server to commit writes and set order
• Session consistency guarantees
• How effective is anti-entropy?

87
Anti-entropy Protocol

• Server propagates write among copies.
• Eventual all copies "converge" towards the same
  state.
• Eventual reach identical state if no new updates.
• Pair-to-peer anti-entropy
• each server periodically selects another server
• exchange writes and agree on the performed order
• reach identical state after performing the same
  writes in the same order.

88
Case Study Rover

• Rover Joseph 97 provides an environment for the
  development of mobile applications
• Applications are split into client and server
  part communicating with Queued RPCs
• Application code and data are encapsulated within
  Relocatable Dynamic Objects (RDOs)
• Access Managers at client and server handle RDOs
• Clients operational log is lazily transfer to
  the server
• Disconnections are supported by the local cache
• Some support for primary copy, optimistic
  consistency

89
Case Study Pro-Motion

• Pro-Motion Chrysanthis 97 is designed for the
  development of mobile database applications.
• It shares similar architecture as Rover with a
  multi-tier C-I-S model.
• Compact is the unit of caching and hoarding
• It encapsulates cached data, methods, consistency
  rules and obligations (e.g., deadlines).
• Supports both tentatively committed transactions
  
• and two-tier replication.

90
Case Study Rome

• Rome Fox 99 goals is the timely and in context
  delivery of information
• Information should be received when and where it
  is needed
• Its fundamental building block are the triggers
• pieces of data bundled with contextual
  information
• Condition (location ? R) ? (time ? t) ? action
• It is similar to active databases but with
  decentralized management
• It provides an extensible framework and building
  blocks leveraging on internet service.

91
Unsolved Problems

• Integration and evaluation of algorithms with
  applications
• Broadcast disks
• Information update/consistency and data temporal
  coherence - meet time constraints of requests
• Relation between server broadcasting and client
  caching.
• Multiple broadcast channels and multiple database
  access
• Efficient, scalable, adaptive mechanisms
• Location handling
• Trigger management
• Programmer Interface for Application-aware
  adaptation
• Data fidelity vs. consistency
• Semantic consistency needs metadata/requirements
• Multimedia and QoS

92
To Recap

• Mobile and wireless computing attempts to deliver
  todays and tomorrows applications on
  yesterdays hardware and communication
  infrastructure!

93
Summary

• need for mutual consistency currency
• need efficient, scalable, adaptive mechanisms
• semantic consistency needs metadata
• temporal consistency needs user req.
• weak consistency with caches
• many open issues

94
Outline

• broadcast environments
• issues in reading consistent data --
  on time
• semantic consistency
• correctness criteria
• mechanisms for disseminating (control) data
• exploiting caches
• temporal consistency

95
Client-Server Communication Model

• Asymmetric communication environments
• Server broadcasts data to clients using
  high bandwidth broadcast links
• Clients listen to the broadcast to fetch data
• Clients communicate with the server using
  low bandwidth upstream links
• Update handling
• Clients send update data to server
• Server resolves update conflicts, commits
  updates, and broadcasts updates to clients

96
Semantic Consistency
Update x and z
TrBegin
TrEnd
time (broadcast cycles)
Are x, y, and z mutually consistent?
97
Time Constrained Broadcasts
98
Temporal Consistency

• Meet data temporal coherence
• improve currency of data read by clients
• attach validity interval for each broadcast data
  object
• Meet time constraints (deadlines) of requests

99
Outline

• broadcast environments
• issues in reading consistent data on time
• semantic consistency
• correctness criteria
• mechanisms for disseminating (control) data
• exploiting caches
• temporal consistency

100
Serializability in Bcast Env.

• Serializability a global property
• dynamic conflict resolution gt excessive comm.
• e.g., locking
• acquiring read locks by client transactions
• server swamped with lock requests
• client uses precious uplink bandwidth
• avoid potential conflicts
• clients must be conservative
• unilaterally disallow certain correct
  executions
• unnecessary aborts

101
Serialization Orders
T2 T4
T4T1T2
T2T3T4
But, global history is not serializable
102
Serializability?
all read-only transactions 1. required to see the
same serial order of update
transactions -- even if executing at different
clients 2. required to be serializable w.r.t.
all the update transactions -- even if
updates do not affect the values read
unnecessary and inappropriate
103
Broadcast Data Requirements

• Mutual consistency
• -- server maintains
• mutually consistent data
• -- clients read mutually consistent data
  
• Currency
• -- clients see data that is current

104
A Sufficient Criterion

• All update transactions are serializable.
• Each read-only transaction is serializable
  with respect to the update transactions it
  (directly or indirectly) reads from.

105
Implications
If clients know update schedule
read-only transactions need not contact the
server. gt addresses the primary problems with
serializability
106
Summary

• need for mutual consistency currency
• need efficient, scalable, adaptive mechanisms
• semantic consistency needs metadata
• temporal consistency needs user req.
• weak consistency with caches
• many open issues

107
Field Computing
108

Assumptions for
Broadcast Disks

• Wireless data broadcasting can be viewed as
  "storage on the air".
• Periodic broadcast - broadcast cycles or bcycles
• Bucket logical unit of broadcast
• Each bucket has an address or sequence number
  within the broadcast.
• Data changes often
• Each successive broadcast may differ in size and
  content
• No updates during a particular broadcast.
• Client has no prior knowledge of the structure
  or content of the broadcast.
• Clients are interested in fetching a particular
  record identified by a key.
• Access time avg time elapsed between the
  beginning of the search for an item to the
  reading of it from the broadcast channel
• Listening/Tuning time the amount of time spent
  listening to the broadcast channel

109

Access protocol

• Index buckets hold the directory, data buckets
  hold data.
• User tunes in to find out when a needed index
  bucket is broadcasted.
• Synchronize by accessing a pointer that tells the
  user when to tune in for the data.
• After you synchronize you must access the data in
  the same broadcast.
• Tune in to the data at the right time.

110

(1,M) Indexing

• We broadcast the index M times during one version
  of the data.
• After broadcasting 1/M of the file we broadcast
  the index.
• All buckets have the offset to the beginning of
  the next index segment.
• Data access protocol for record with key Q
• Listen to current bucket.
• Read the offset.
• Go to sleep till the next index segment
• From the index determine when Q arrives.
• (May have to follow several levels of
  indexes.)
• Tune in again to pick up record.

111

Distributed
Indexing

• Goal Let's cut down on the replication of index
  material
• Solution It is sufficient to broadcast only the
  portion of the index which describes the data
  segment that follows. No replication.
• Problem with the no replication approach.
• User can't determine when relevant indexing is
  coming!
• Number of probes grows linearly with number of
  levels in tree, and
• the number of pointers in an index bucket. Very
  bad.
• New Solution Distributed indexing. Divide the
  index into
• replicated top l levels
• non-replicated bottom 4-l levels
• Result Index overhead vs. tuning time

112

Flexible Indexing

• broadcast divided into p data segments.
• data items are assumed sorted
• a control index is associated with each segment
• binary control index to determine the data
  segment
• local index to locate the specific item within
  the segment

113

Mobility

• bandwidth restrictions and variability
• bursty network activity - during connections
• handling disconnections (planned failures?)
• caching strategies
• managing inconsistencies

114

What Needs to be Reexamined?

• Operating systems
• File systems
• Data-based systems
• Communication architecture and protocols
• Hardware and architecture
• Real-Time, multimedia, QoS
• Security
• Application requirements and design
• PDA design Interfaces, Languages
•