Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Mobile Computing - Mobile Computing Model, Study notes of Mobile Computing

Summary about Mobile Computing Model, Characteristics of mobile computing, Mobile Transaction Processing , Requirements, Mobile Database, Secure agent System.

Typology: Study notes

2010/2011

Uploaded on 09/04/2011

amit-mohta
amit-mohta 🇮🇳

4.2

(152)

89 documents

1 / 18

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
11/25/14 1
Mobile Computing Model:
Mobile Computing Model: It consists of a set
of mobile computers & stationary hosts
consulted by a fixed n/w.
Mobile Transaction: Mobile computing is the
ability of user to access the database by means
of wireless devices.
There exist a stationary architecture that is a
backbone for a distributed mobile computing
system.
Stationary Host (SH) also called fixed host (FH) &
base station (BS).
The wireless device that issue the transaction
are called mobile station (MS).
Transaction is a set of database operation
(Insertion, Deletion, Updation, Retrival of data)
The transaction can be written in query
language such as SQL.
NOTE: A mobile transaction is a transaction
where at least one mobile host is involve in the
transaction.
Mobile Computing Environment:-
A mobile computing environment includes-
A wired n/w with fixed hosts (FH)
Mobile hosts (MH) and
Mobile support stations (MSS)
Connection b/w MH & MSS is wireless n/w. This
n/w is characterized by low bandwidth, error
prone & frequent disconnections.
MSS& FH communicate each other via reliable
high speed connection n/ws, which can be wired
n/w or wireless n/w .
The MSS is motionless. The role of MSS is not as
a processing element but it is acting as an
interface to MH getting contact with relevant FH.
Each MSS responds for an area (Cell) in which it
will support all MHs operating in this area.
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12

Partial preview of the text

Download Mobile Computing - Mobile Computing Model and more Study notes Mobile Computing in PDF only on Docsity!

Mobile Computing Model:

  • (^) Mobile Computing Model: It consists of a set of mobile computers & stationary hosts consulted by a fixed n/w.
  • Mobile Transaction: Mobile computing is the ability of user to access the database by means of wireless devices.
  • (^) There exist a stationary architecture that is a backbone for a distributed mobile computing system.
  • Stationary Host (SH) also called fixed host (FH) & base station (BS).
  • (^) The wireless device that issue the transaction are called mobile station (MS).
  • (^) Transaction is a set of database operation (Insertion, Deletion, Updation, Retrival of data)
  • The transaction can be written in query language such as SQL.
  • (^) NOTE: A mobile transaction is a transaction where at least one mobile host is involve in the transaction.
  • Mobile Computing Environment:-
  • (^) A mobile computing environment includes-
  • (^) A wired n/w with fixed hosts (FH)
  • Mobile hosts (MH) and
  • (^) Mobile support stations (MSS)
  • (^) Connection b/w MH & MSS is wireless n/w. This n/w is characterized by low bandwidth, error prone & frequent disconnections.
  • MSS& FH communicate each other via reliable high speed connection n/ws, which can be wired n/w or wireless n/w.
  • (^) The MSS is motionless. The role of MSS is not as a processing element but it is acting as an interface to MH getting contact with relevant FH.
  • Each MSS responds for an area (Cell) in which it will support all MHs operating in this area.
  • Characteristics of mobile computing:-
  • (^) Mobility- When MH is moving from one cell to another cell in wireless n/w, connection will need to be changed coz one MSS can only support MHs within its limited area. This causes frequent need of reconfiguration.
  • (^) Communication:- MH connects with MSS through wireless n/w.
  • (^) Heterogeneity- One MSS needs to support broad types of mobile devices, which are operating in its cell; when MH requests commn with other MH, the heterogeneity problem needs to be taken into account.
  • Portability- The availability of mobile devices depend on their power supply. Portability of mobile devices requires more sophisticated s/w applications.
  • Mobile Transaction Processing (also known as Distributed Transaction Processing)
  • (^) Mobile Transaction- A transaction submitted from a MH.
  • (^) The mobile host (MH) which issues transaction & the MH which received the result can be different. Eg. User Queries from his laptop computer & requests the answer will be sent to mobile phone via SMS msg.
  • (^) Requirements: Mobile Transaction has several requirements-
  • (^) Bcoz MH has less processing capacity than FH, so mobile transaction should be able to split into a set of smaller transactions.
  • (^) Bcoz of the commn overhead & frequent disconnections, the time required for exchanging data b/w MH& MSS is longer.
  • (^) Mobile transaction should be executable when MH is in mobility & disconnected.
  • (^) Mobile transaction being able to operate in distributed heterogeneous environment.
  • (^) Mobile Database : In mobile environment, the database resides, replicated & distributed on the fixed hosts in wired n/w however, the capacity of mobile computing device is expanding & a mobile host can became a host for data processing. Mobile host can become a host for data processing. In this case, the physical location of database system is changing. Identifying the location of the mobile hosts, which stores the required data, is one the major issue in mobile database.
  • (^) Service Hand-off : When a MH moves into a new cell, a new MSS is assigned to this MH. Information about current transaction state is saved & transferred from old MSS to next MSS. This operation sometimes is unnecessary bcoz not all the time MH requires assistant. Mobile host M is moving form cell A to cell C through cell B AS MH does not need any assistant from MSS in cell B. The information about transaction state should directly forward to MSS in cell C. So, if this information is stored at mobile host then the MH can become an active element, which can initiate a connection when needed. The Question is how a MH finds what MSS it should connect to. Currently, when a MH wants to exchange information with another MH then they have to rely on at least one MSS.
  • (^) Scheduling : Execution time of mobile transaction is varying. Mobile transaction can easy miss its required deadline due to its mobility & portability. Its is not applicable in mobile transaction if a missing deadline transaction is always aborted. Thus, mobile transaction requires flexible scheduling mechanism. Schedule in mobile transaction tames into account the mobility of MH in both location & time. Also mobile hosts should be able to reschedule its execution plan according to its physical state( commn bandwidth, power).
  • (^) Secure agent System: The usage of distributed transactions & the

2PC protocol contains some drawbacks; like bad performance of the

2PC protocol due to its blocking characteristics. DTP also introduces

implementation overhead & additional s/w components.

  • (^) Vogler built a DTP based enhancement of existing system for host

security as well as agent security, which additionally allows agent

mgmt. & control. They call their system secure agent system. It is

not possible to achieve full security with complete functionality for

the agent without trusting each other By aid of third party called a

trust service, which has information about all instances of the closed

system, a kind of trusted situation or contract can be achieved.

  • (^) This trust service is an extension to handle problems. The secure

agent system also offers the basis for agent control & management.

  • (^) The agent migration protocol is a combination of data logging,

encryption mechanisms & DTP.

  • (^) Benefits: The benefits that this architecture brings into a mobile

agent system are-

  • (^) Security for the host
  • (^) Security for the agent
  • (^) Fault tolerance & reliable agent transfer
  • (^) Agent control & management.

Issues in Mobile Transactions

  • (^) Issues in Mobile Transactions: Mobile transactions do not always strictly adhere to the ACIDity properties.
  • (^) Consistency is the property that is most aften lacking.
  • (^) Deadlocks- Deadlocks may cause delays to the processing of the transaction. So deadlock detection & prevention are important for successfully executing transactions. There is overhead needed to detect & resolve a deadlock if it does occur.
  • (^) Concurrency control: - Instead of single threading transaction, a system usually processes multiple transactions at one time its benefit is greater throughput.
  • (^) Consistency- i.e. the correctness of the database is a crucial concern for transactions.
  • (^) Fault Tolerance- Mobile database systems must content with a variety of failures including mobile & stationary hosts, transaction & connections. The level of tolerance for a specific failure needs to be determined as well as a recovery strategy.
  • (^) Fragmentation- It is partitioning a relation into two or more pieces the benefits to fragment relations is to maximize the access usage based on locality. Fragmentation can be used in conjunction with replication.
  • Security- Mobile computing has a no. of security concerns. No mobile host should be able to interfere with another. Multiple levels of security can be invoked to limit access for authorized mobile host users to specific aspects of the database through mandatory methods of granting security access.
  • (^) Replication: - It is the means by which the system maintains one or more identical copies of the data at different locations. Full or partial replications of a data in mobile computing systems provide higher availability. More replication also allows increased parallelism for database reads.

Issues in Mobile Transactions

  • (^) Recovery of Transactions: - If for any reason, a transaction fails, the operations within the transaction must be undone to preserve the atomicity of the transaction. Recovery is dependent on the atomicity of transaction the challenge that occurs is to ensure that for any schedule of transaction that the schedule is recoverable.
  • (^) N/w link issues: - Mobile hosts may loose a connection due to a disconnect, transmission noise or may be unable to connect due to utilization of the station. Continuous connections are not realistic due to the power consumption of the mobile host. Knowing how frequent you expect a device to connect & being able to plan for disconnections needs to be designed into a transaction model.
  • (^) Validation: - For databases where the frequency of read-only transaction is high, validation of these transaction leave the database in a consistent state. Validation of transactions that perform one or more write operations, adds overhead for validation; & can cause slower or delayed transaction processing due to this validation process. By choosing not to have a validation protocol, you risk having an inconsistent state.
  • (^) Mobile device constraints- Battery powers for mobile hosts are a limited resource. Energy efficient mobile hosts are desirable but connecting will use energy. We have two types of mobile hosts: LMH (large MH) & SMH (Small). The LMH has greater storage, processing power & battery life than SMH. Commn goes through the LMH so that the SMH can go into a sleeper mode to artificially extend the battery life of the device.
  • Kangaroo Model: A major difference of a mobile environment from a

fixed one is that- source of a transaction is not always the destination

of it. i.e. a mobile host can change locations while executing a

transaction. The kangaroo model captures the movement of the

mobile units. The model assumes a distribution model as follows-

  • (^) The mobile units are attached to the fixed n/w via mobile support

stations (MSS).

  • (^) A data access agent (DAA) runs on every MSS which takes care of the

transactions submitted by mobile units (MUs). DAA keeps track of the

execution status of the transactions & logs recovery information for

every uncommitted transaction submitted or forwarded to it.

  • (^) Deno: In Deno, a replicated object storage systems is designed for

use in mobile & weakly connected environment. Deno is designed to

support weak connections & limitations of mobile hosts, such as

limited processing power & limited coverage area. Thus, it is a light

weight, peer-to-peer, asynchronous system. A MU does not need to

know the other hosts but it needs to be in contact with atleast one

other node. Update transaction are always voted to commit after they

are committed locally on a node. In the case of planned disconnection,

e.g. sleep mode, a node can appoint a proxy for itself & transfers its

weight to that proxy. After returning to the n/w, formerly disconnected

node can claim its weight back. In case of an unplanned

disconnection, a proxy for the disconnected node is selected using the

voting scheme. if the proxy election is globally committed, the weight

of disconnected node is transferred to elected proxy.

  • (^) Promotion Model: = It is designed to support distributed transaction processing. The motivation is that, disconnected MUs can execute transaction. If they have the data & methods required. The fundamental building block is the compact which is the basic unit of data replication for caching & hoarding. A compact is not only a piece of data but it is a object which includes restrictions (allowable operations), obligations ( such as a expiration time) & methods. In other words, compact is a mini database which is moved to the local hosts upon requests. To allow the resources to be released in a timely manner, each compact is assigned a deadline. A MU can request an extension if the deadline had post. If the compact is free, then a new deadline is negotiated, if not this compact is marked invalid & all transactions accessed it are aborted. The valid compacts are resynchronized with the database.
  • (^) TCOT Protocol: (Timeout based commitment protocol) :TCOT, like Deno, is designed for weakly connected, less powerful MUs. TCOT tries to minimize the commn, since bandwidth is scarce & also MUs can disconnect unpredictably. It assumes that MU has a cache & transaction processing power. A coordinator is responsible of a transaction submitted by a MU. Coordinator is responsible of a transaction submitted by a MU. Coordinators are either base stations or a node on the fixed n/w. Coordinators distributes subtransaction to the fixed nodes on the n/w & starts its timer according to the values it received from the MU. MU extracts the subtransaction & sends extra information such as how long it will take to process the subtransaction.
  • Any node executing a sub transaction can request a time extension. But if coordinator does not receive a msg from the MU or other participating nodes, then it aborts the transaction & sends an abort msg to all of the nodes. Else if it receives commit msgs from all nodes & updates from MU, it does not send any further msgs. Since some nodes commit without a global commit, compensating transaction are necessary to undo the globally aborted but locally committed sub transactions. In this scheme, calculating timeout values, so that it minimizes extension msgs & transaction restarts, is important. MUs should be able to choose values for initial timeout values based on the n/w conditions, moreover they can request extensions. Coordinator should be able to reject an extension request if the system through put falls under desired value.

Problem Statement

  • (^) Transaction Processing in Mobile Computing Systems - (^) Distributed Environment - (^) Multiple Database Systems - (^) Heterogeneous Databases - (^) Mobile Users Why
  • (^) The state of single transaction spans to multiple base stations and databases. - (^) The client leaves one base station before a transaction finishes - (^) The client may need to commit or abort the operations or transactions that are not at current base station - (^) Recovery Problem

Mobile Transaction (MT)

  • (^) Database transaction requested from a MU. May execute in FN or MU
  • (^) Issues
    • (^) Disconnect/Handoff
    • Mobility
    • (^) Location Dependent Data
    • (^) Error Prone
    • MU Resources/ Power
    • (^) Recovery/Restart
    • (^) Management

MT Requirements

  • (^) Keep autonomy of local DBMS
  • (^) Interactive
  • (^) Advanced transaction models
    • (^) Nested
    • Multidatabase
  • (^) Request from MU
  • (^) Execute anywhere
  • (^) Capture movement
  • (^) ACID (?)

MT Recovery

  • (^) Transaction, site, media, network failure - More frequent than in wired network.
  • (^) Different types of failures (partial)
    • (^) Handoff
    • (^) Voluntary disconnection
    • (^) Battery problems
    • (^) Lose computer??
  • (^) Checkpoint data at MU to BS
  • (^) Checkpoint at handoff
  • (^) Database log plus transaction log
  • (^) May need compensating transactions

ACID for MT ??

  • (^) Atomicity
    • (^) Weaken or provide different types of atomicity
    • (^) May decompose transaction into subtransactions
    • (^) Global commit/Local Commit
  • (^) Consistency
    • (^) May divide data into clusters with consistency within clusters.
    • (^) Reintegration of updates after reconnect may cause many conflicts.
    • (^) May use bounded inconsistency
  • (^) Isolation
    • (^) May be too restrictive
    • (^) Can’t always do at MU (disconnection)
  • (^) Durability
    • (^) Durability for partial results
    • (^) Due to conflicts at reconnect, even durability of subtransactions may not be guaranteed.
    • (^) Local commit (mobile agent/ client ) vs. Global commit (mobile agent / server)