Вы находитесь на странице: 1из 9

UNIT-3 RD

DATA MANAGEMENT IN MOBILE COMPUTING

Most mobile technologies physically support broadcast data management mechanism and a server can take advantage of push to disseminate information to all mobile clients in its cell. On the other hand, in pull-based scheme, clients only access data when needed. These two facts introduce new mechanisms for data management different from the traditional algorithms proposed for traditional client-server distributed database systems Mobile Data Management 1. Global Data Management (network level): Location Addressing Replication Broadcasting, etc. 2. Local Data Management (end user level): Energy efficient data access Management of disconnection Query processing

The various issues in data management are: Broadcast Data Management Architecture Cache Consistencies and Data Replication Location Data Management (Location specific queries) Issues in sensor data processing and pervasive computing Location and context aware computing Disconnection (Voluntary, Involuntary) Wireless Medium . Broadcasting and Data Mgmt Portability . Speed of wireless link Scalability . Limited by battery power Wireless Security Issues . Mobility Handoff . Transaction Management Broadcast Data Management Architecture: what is broadcasted trade-off periodicity of broadcast divergence of the cached copies that can be tolerated The more the inconsistency tolerated the less often the updates need to be broadcasted Cache coherence preservation Large communication delay increases the cost of validation of cached objects only validates on demand could reduce validation frequency but this approach would worsen consistency since it increases the possibility of some old objects being accesses while disconnected Cache Consistency Caching is useful during frequent relocation and connection to different areas. alleviate the performance and availability limitations during weak-connections and disconnections reduce contention on the small bandwidth wireless network improve query response time, and to support disconnected or weakly connected operations May request different levels of cache consistency Hampered by disconnection and mobility of clients. Solutions: Periodically broadcasting the actual data.

Control information such as lock tables or logs.

Cache Preservation for Disconnection Codas file system allows the cached objects in the mobile host to be updated without any co-ordination. When it is connected, the system propagates the modifications and detects update conflicts. Coda proposed three states: Hoarding Client cache manager relies on server replication, always on alert for possible disconnection, ensures the critical objects are cached when disconnected. Emulation (upon disconnection) Relies solely on the contents of the cache. Reintegration (upon reconnection) Revalidate all cached objects before use to detect updates at the server. Data Replication in Mobile Computing Replication is the process of sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, fault-tolerance, or accessibility. It could be data replication if the same data is stored on multiple storage devices, or computation replication if the same computing task is executed many times. A computational task is typically replicated in space, i.e. executed on separate devices, or it could be replicated in time, if it is executed repeatedly on a single device. It is common to talk about active and passive replication in systems that replicate data or services. Active replication is performed by processing the same request at every replica. In passive replication, each single request is processed on a single replica and then its state is transferred to the other replicas. If at any time one master replica is designated to process all the requests, then we are talking about the primary-backup scheme (master-slave scheme) predominant in high-availability clusters. On the other side, if any replica processes a request and then distributes a new state, then this is a multi-primary scheme (called multi-master in database field) Backup is different from replication, since it saves a copy of data unchanged for a long period of time. Replicas on the other hand are frequently updated and quickly lose any historical state. Data Replication Goals: 1. Higher availability 2. Better performance Areas of usage: Distributed Systems and Databases Data Replication Issues How to manage data replication? How to locate objects of interest? When do we need to replicate the data on a mobile site? How users moves affect the replication scheme? Is mobile environment requiring dynamic replication schemes? Do we need new replication algorithms? Bandwidth Considerations and Data Transfer Rates Frequent Network Failures MUs often have limited battery-life. Wireless communication is expensive! Locality Migration: If a MU has initiated a transaction, and moves, the location of the MU within the network must be found prior to completing the transaction Frequent Planned Disconnections Recovery Services: Where are we going to store the recovery logs? Consistency Semantics: If process is frequently interrupted, they may leave data objects in an inconsistent state. Security Human interface: How do we pose queries from a handheld device

Replication Schemes For Mobile Environment Eager Replication: It attains replication by keeping all replicas exactly synchronized at all nodes. This in turn is achieved by updating all replicas in one transaction. No concurrency anomalies occur since eager replication gives serializable execution. Eager replication is not a proper choice for a mobile environment since eager replication reduced update performance with extra updates, and in a mobile environment the nodes are normally disconnected. Lazy Replication: These algorithms are more suited to the mobile environment . The synchronization occurs after the updating transactions commits. That is, replication is asynchronous in nature. The problem with lazy replication is that it may allow a transaction to see a very old committed value. Several replication schemes for mobile environments have been proposed are in use. Some of those are : 1. Replication achieved through dynamic data allocation 2. Adaptive Data Replication 3. Active Replication 4. Optimistic Replication 5. User Profile Replication Mobile Transaction Processing May have to split their computations into sets of operations. Require computations and communications to be supported by stationary hosts. When MU moves, the execution continues at the new cell. Partially completed transactions may be continued at the fixed local host. The states of transaction, states of accessed data objects and the location information move with the mobile hosts. Long-lived due to the mobility of users and data, and frequent disconnections. Should support concurrency, recovery, disconnection and mutual consistency for the replicated data objects. Wireless Security Issues 250K PDAs were lost in US airports during 2002.(Gartner report) Handhelds are frequently used in hostile environments like hotspots, customer sites, business partner offices, and industry conferences. Attackers are drawn to locations where business travelers gather, because targets are more plentiful and it is easier to go unnoticed. Handhelds are also potentially vulnerable to viruses, worms, Trojans, and spy ware. Most are Win32 viruses that can be spread from unprotected handhelds to desktops through synchronization, email, or file shares. Self-replicating worms like Bugbear, Klez, and Spida flood email and file servers, delete registry keys, kill processes, disable software, and carry Trojans. Trojans can log keystrokes, launch denial of service (DoS) zombies, or let attackers assume remote control of infected hosts. Spy ware in cookies and programs like Kazaa are not overtly malicious, but leak potentially sensitive information about your computing behavior. Mobile phones that can download games, ring tones, and other software have opened a new avenue for hackers to exploit. Practical Security Strategies for Security Set power-on passwords. According to Gartner, the biggest risk associated with Pocket PCs is that no poweron password is required by default. Use mobile firewall to block unauthorized handheld network activity Defends against port scans, unauthorized requests, unwanted peer-to-peer connections, denial of service floods, and other network-borne attacks. Encrypt sensitive values, database records, key files and folders, or entire compact flash cards..

Protect traffic sent and received by handhelds. Consider encrypted, authenticated VPN tunnels to ensure the privacy and integrity of communication between handhelds and connected networks. If credentials must be saved on a handheld, encrypt them. Detect and eradicate viruses. Backup handheld data regularly. Frequent backups can reduce loss of data and downtime when a Pocket PC is lost, stolen, wiped clean, or damaged beyond repair.

Pervasive Computing Technology View Computers everywhere embedded into fridges, washing machines, door locks, cars, furniture, people intelligent environment Mobile portable computing devices Wireless communication seamless mobile/fixed User View Invisible implicit interaction with your environment Augmenting human abilities in context of tasks Ubiquitous = mobile computing + intelligent environment Context Awareness Context defined by: Current location Need location detection eg GPS or base station Indoors radio beacon, IR User activity Walking, driving a car, running for a bus how to detect this? Ambient environment In theatre, alone, in meeting Local resources or services available Device capabilities Screen, input, processing power, battery life . Current QoS availability particularly for radio links
Characteristics of wireless communications

Limited resources: Limited memory Limited computational power Small screen Limited battery life Relatively unreliable Variability in resources Frequent location updated

Characteristics of mobile elements Network Disconnections Voluntary or forced Predictable or sudden. Short disconnections and long Disconnected operation Frequent disconnections Predictable disconnections Physical support for broadcast

Asymmetry Monetarily expensive Relatively unreliable High bandwidth variability Low bandwidth

Portability Network Disconnections Voluntary or forced Predictable or sudden. Short disconnections and long Disconnected operation Adaptive Clustering For Mobile Wireless Networks In the proposed network architecture, nodes are organized into non overlapping clusters. The clusters are independently controlled and are dynamically reconfigured as nodes move. This network architecture has three main advantages. First, it provides spatial reuse of the bandwidth due to node clustering. Secondly, bandwidth can be shared or reserved in a controlled fashion in each cluster. Finally, the cluster algorithm is robust in the face of topological changes caused by node motion, node failure and node insertion/removal. File System (Motivation Goal efficient and transparent access to shared files within a mobile environment while maintaining data consistency Problems limited resources of mobile computers (memory, CPU, ...) low bandwidth, variable bandwidth, temporary disconnection high heterogeneity of hardware and software components (no standard PC architecture) wireless network resources and mobile computer are not very reliable standard file systems (e.g., NFS, network file system) are very inefficient, almost unusable Solutions replication of data (copying, cloning, caching) data collection in advance (hoarding, pre-fetching) File systems - consistency problems THE big problem of distributed, loosely coupled systems are all views on data the same? how and when should changes be propagated to what users? Weak consistency many algorithms offering strong consistency (e.g., via atomic updates) cannot be used in mobile environments invalidation of data located in caches through a server is very problematic if the mobile computer is currently not connected to the network occasional inconsistencies have to be tolerated, but conflict resolution strategies must be applied afterwards to reach consistency again Conflict detection content independent: version numbering, time-stamps content dependent: dependency graphs

File systems for limited connectivity Symmetry Client/Server or Peer-to-Peer relations support in the fixed network and/or mobile computers one file system or several file systems one namespace for files or several namespaces Transparency hide the mobility support, applications on mobile computers should not notice the mobility user should not notice additional mechanisms needed Consistency model optimistic or pessimistic Caching and Pre-fetching single files, directories, sub trees, partitions, ... permanent or only at certain points in time Data management management of buffered data and copies of data request for updates, validity of data detection of changes in data Conflict solving application specific or general errors Several experimental systems exist Coda (Carnegie Mellon University), Little Work (University of Michigan), Ficus (UCLA) etc. Many systems use ideas from distributed file systems such as, e.g., AFS (Andrew File System) Coda file System Coda is a network file system developed as a research project at Carnegie Mellon University since 1987 under the direction of Mahadev Satyanarayanan. It descended directly from an older version of AFS (AFS-2) and offers many similar features. The InterMezzo file system was inspired by Coda. Coda is still under development, though the focus has shifted from research to creating a robust product for commercial use. Coda has many features that are desirable for network file systems, and several features not found elsewhere. disconnected operation for mobile computing is freely available under a liberal license high performance through client side persistent caching security model for authentication, encryption and access control continued operation during partial network failures in server network network bandwidth adaptation good scalability well defined semantics of sharing, even in the presence of network failures Offers two different types of replication 1) Server replication 2) Caching on clients disconnected operation for mobile clients reintegration of data from disconnected clients bandwidth adaptation Failure Resilience read/write replication servers resolution of server/server conflicts handles of network failures which partition the servers handles disconnection of clients client Performance and scalability

client side persistent caching of files, directories and attributes for high performance write back caching Security kerberos like authentication access control lists (ACL's) Well defined semantics of sharing Freely available source code

File systems - Coda I Application transparent extensions of client and server changes in the cache manager of a client applications use cache replicates of files extensive, transparent collection of data in advance for possible future use (Hoarding) Consistency system keeps a record of changes in files and compares files after reconnection if different users have changed the same file a manual reintegration of the file into the system is necessary optimistic approach, coarse grained (file size) Hoarding user can pre-determine a file list with priorities contents of the cache determined by the list and LRU strategy (Last Recently Used) explicit pre-fetching possible periodic updating Comparison of files asynchronous, background system weighs speed of updating against minimization of network traffic Cache misses modeling of user patience: how long can a user wait for data without an error message? function of file size and bandwidth Structure of a Coda Client

How Coda Works To understand how Coda can operate when the network connections to the server have been severed, let's analyze a simple file system operation. Suppose we type: ``cat /coda/tmp/foo'' display the contents of a Coda file. What actually happens? The cat program will make a few

to

system calls in relation to the file. A system call is an operation through which a program asks the kernel for service: for example, when opening the file the kernel will want to do a lookup operation to find the inode of the file and return a file handle associated with the file to the program. The inode contains the information to access the data in the file and is used by the kernel, the file handle is for the opening program. The open call enters the virtual file system (VFS) in the kernel, and when it is realized that the request is for a file in the /coda file system it is handed to the Coda file system module in the kernel. Coda is a pretty minimalistic file system module: it keeps a cache of recently answered requests from the VFS, but otherwise passes the request on to the Coda cache manager, called Venus. Venus will check the client disk cache for tmp/foo, and in case of a cache miss, it contact the servers to ask for tmp/foo. When the file has been located, Venus responds to the kernel, which in turn returns the calling program from the system call. When the kernel passes the open request to Venus for the first time, Venus fetches the entire file from the servers, using remote procedure calls to reach the servers. It then stores the file as a container file in the cache area (currently/usr/coda/venus.cache/). The file is now an ordinary file on the local disk, and read-write operations to the file do not reach Venus but are (almost) entirely handled by the local file system (ext2 for Linux). Coda read-write operations take place at the same speed as those to local files. If the file is opened a second time, it will not be fetched from the servers again, but the local copy will be available for use immediately. Directory files (remember: a directory is just a file) as well as all the attributes (ownership, permissions and size) are all cached by Venus, and Venus allows operations to proceed without contacting the server if the files are present in the cache. If the file has been modified and it is closed, then Venus updates the servers by sending the new file. Other operations which modify the file system, such as making directories, removing files or directories and creating or removing (symbolic) links are propagated to the servers also.

File systems - Little Work Only changes in the cache manager of the client Connection modes and use

File systems - further examples Mazer/Tardo file synchronization layer between application and local file system caching of complete subdirectories from the server Redirector responses to requests locally if necessary, via the network if possible periodic consistency checks with bi-directional updating Ficus not a client/server approach optimistic approach based on replicates, detection of write conflicts, conflict resolution use of gossip protocols: a mobile computer does not necessarily need to have direct connection to a server, with the help of other mobile computers updates can be propagated through the network MIo-NFS (Mobile Integration of NFS) NFS extension, pessimistic approach, only token holder can write connected/loosely connected/disconnected Disconnected operation Three states of Venus Hoarding Network is connected Collect crucial files Emulation Offline mode

Venus simulate server Reintegration Network is connected Sync of files It only provides access to data that was cached. When disconnected operation ends, modified files and directories from disconnected volumes are propagated to the AVSG. It is important to avoid cache misses during disconnected operation. Coda allows a user to specify a prioritized list of files and directories that venus should strive to retain in the cache. Disconnected operation can also be entered voluntarily. A version vector mechanism is used by Coda to detect inconsistencies

Application of CODA Web server Shared files: in, e.g., Beowulf cluster or across an enterprise especially where NFS is inadequate mobile/disconnected operation WAN Database systems in mobile environments Request processing power conserving, location dependent, cost efficient example: find the fastest way to a hospital Replication management similar to file systems Location management tracking of mobile users to provide replicated or location dependent data in time at the right place (minimize access delays) example: with the help of the HLR (Home Location Register) inGSM a mobile user can find a local towing service Transaction processing mobile transactions can not necessarily rely on the same models as transactions over fixed networks (ACID: atomicity, consistency, isolation, durability) therefore models for weak transaction

Вам также может понравиться