0% found this document useful (0 votes)
100 views87 pages

Mobile Computing: Unit Iv Recommended Books

The document discusses mobile computing and mobile code. It defines mobile code as software that can travel across networks and automatically execute on different devices. Well-known examples of mobile code include Java applets, SQL queries, and documents with executable content. The document also discusses the advantages of mobile code, common needs like security and portability, and representative programming languages used for mobile code like Java. It then covers topics like mobile agents, differences between applets and agents, process migration, object migration, and various mobile code system designs including client-server, remote evaluation, code on demand, and mobile agents.

Uploaded by

Tia Charms
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
100 views87 pages

Mobile Computing: Unit Iv Recommended Books

The document discusses mobile computing and mobile code. It defines mobile code as software that can travel across networks and automatically execute on different devices. Well-known examples of mobile code include Java applets, SQL queries, and documents with executable content. The document also discusses the advantages of mobile code, common needs like security and portability, and representative programming languages used for mobile code like Java. It then covers topics like mobile agents, differences between applets and agents, process migration, object migration, and various mobile code system designs including client-server, remote evaluation, code on demand, and mobile agents.

Uploaded by

Tia Charms
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 87

MOBILE COMPUTING

Atul Bhardwaj
Lecturer
CSE & IT Dept. R.G.E.C. Meerut
UNIT IV
Recommended Books:
1. J. Schiller, Mobile Communications, Addison
Wesley
2. A. Mehrotra, GSM System Engineering
3. M.V.D. Heijden, M. Taylor, Understanding
WAP, Artech House
4. Charles Perkins, Mobile IP, Addison Wesley
5. Charles Perkins, Ad-hoc Networks, Addison
Wesley.
12/09/21 1
Mobile Code
• “Mobile code” defined as “software that travels on a
heterogeneous network, crossing protection domains,
and automatically executed upon arrival at the
destination”
• protection domains – corporate network or PDA
• excludes cases where code is
– loaded from a shared disk
– downloaded (manually) from the Web
• Mobile code supports a flexible form of distributed
computation where the desired nonlocal computations
need not be known in advance at the execution site
• Advantages
Efficiency
Simplicity and flexibility
Storage

12/09/21 2
Mobile Code
• Well-known examples of Mobile Code
1. PostScript
2. Database technology – SQL
3. Documents with embedded executable contents transmitted on the network
= Java (applet)
4. Inferno developed by Lucent – a mobile-code-enabled network OS
• Common needs of mobile code in terms of programming languages
– Portability
– Safety
– Security
• Confidentiality
• Integrity
• Availability
• Authenticity
– Efficiency
• Representative programming languages for mobile code
– Java
– Limbo
– Objective Caml
– Obliq
– Telescript
– Safe-Tcl
12/09/21 3
Mobile Code
• Mobile code – a technique where code is transferred from the
computer system that stores the codes file to the computer system
that executes the code. Java Applets are well-known example of
mobile code which are small programs available in a portable and
interpretable byte code format and are transferred from a Web
server to a Web browser in order to be executed as part of an HTML
page.
• Mobile agent – a special type of mobile code or a program that can
migrate from a starting host to many other hosts in a network of
heterogeneous computer systems and fulfill a task specified by its
owner. During the self-initiated migration, the agent carries all its
code and data, and in some systems also some kind of execution
state.

12/09/21 4
Differences between Java Applets
and Mobile Agents
• MAs initiate the migration process; migration of
Java applets is initiated from other software
components (e.g. Web browser)
• Java applets migrate only from a server to a
client, do not leave the client to another client or
back to the server
• Applet’s lifetime bound to that of the Web page,
dies when browser terminates or another Web
page requested; MA usually migrate more than
once
12/09/21 5
Process Migration
• Transfer of OS process from one m/c to other
• Migration mechanisms handle bindings
between
– process and execution environment (e.g. open fds,
env variables)
• Provide for load balancing
• Most of these facilities provide transparent
process migration
• Other like Locus provide for some control
– like external signal or migrate( ) system call
12/09/21 6
Object Migration
• Makes possible to move objects among
address spaces
– finer grained mobility with respect to
processes
– e..g Emerald system : Different granularity
levels - small to complex objects
• does not provide complete transparency
– COOL (oo extension of Chorus OS) allows
total transparent migration

12/09/21 7
Mobile Code Systems
• Code mobility is exploited on Internet Scale
– Large scale, heterogeneous hosts, technologies
– Strong v/s weak mobility
• Mobility is location aware
– Programming language
• provides mechanisms and abstractions that enable shipping/
fetching of code to/from nodes
– Underlying run-time
• supports marshalling (In computer programming, marshalling is
the process of gathering data from one or more application s or
non-contiguous sources in computer storage, putting the data
pieces into a message buffer , and organizing or converting the
data into a format that is prescribed for a particular receiver or
programming interface) , code, check in , security etc
• no knowledge of migration policies
• Applications
– load balancing
– E-commerce, distributed information retrieval, workflow…
12/09/21 8
Mobile Code Systems: Design
• Several Paradigms:
– Client Server
– Remote Evaluation
– Code on Demand
– Mobile Agent
• Example:
– Two friends Ajay and Anil
– interact to make a cake (results of service)
– recipe is needed (know-how about service)
– also ingredients (movable resources)
– oven to bake (hard to move resource)
– a person to mix ingredients as per recipe
(computational component responsible for execution
of code)
– prepare the cake (execute the service)
– where the cake is prepared (site of execution)
12/09/21 9
Client-Server: CS
• Ajay would like to have chocolate cake:
– He does not know the recipe
– He does not have the required ingredients nor an oven

• Ajay knows that Anil (who likes baking cakes)


– knows the recipe
– has a well supplied kitchen

• Ajay calls Anil asking:


– “Can you make me a chocolate cake please?”

• Anil makes the cake and delivers it back to Ajay

12/09/21 10
Remote Evaluation: REV
• Ajay would like to have chocolate cake:
– He knows the recipe
– He does not have the required ingredients nor an oven

• Ajay knows that Anil (who likes baking cakes)


– has a well supplied kitchen
– does not know the recipe

• Ajay calls Anil asking:


– “Can you make me a chocolate cake please? Here is the
recipe…”

• Anil makes the cake and delivers it back to Ajay


12/09/21 11
Code on Demand : COD
• Ajay would like to have chocolate cake:
– He has the required ingredients and an oven
– He does not know the recipe

• Ajay knows that Anil


– knows the recipe (and is willing to share it)

• Ajay calls Anil asking:


– “Can you tell me the recipe for making chocolate cake please?”

• Anil tells him the recipe and Ajay makes the cake

12/09/21 12
Mobile Agent: MA
• Ajay would like to have chocolate cake:
– He has the recipe and the required ingredients
– He does not have an oven

• Ajay knows that Anil


– has an oven (and is willing to share it)

• Ajay could
– prepare the batter
– go to Anil’s place
– bake the cake

• Several other variations are also possible

12/09/21 13
parameters RPC
client data server

procedure
server REV
client Results

Agent migration Mobile agents


S1 S2
Agent migration
Agent dispatch

Agent migration
client S3

12/09/21 14
What is an agent?
• A program that acts on behalf of a user
• Represents the user into the network
• Migrates autonomously in the network
• Performs computations on behalf of the user
• Path of the agent
– Predetermined
– Agents determine dynamically
• Reduce n/w use
• Increase asynchrony between clients & servers
• Add client specified functionally to servers
• Introduce concurrency
• Agents typically possess several (or all ) of the following Characteristics:
1. Autonomous 2. Adaptive / learning 3. Mobile
4. Persistent 5. Goal oriented6. Flexible
7. Communicative /Collaborative 8. Active / proactive

12/09/21 15
What is mobile agent?
• Mobile agents are defined as active objects (or clusters of
objects) that have behavior, state and location.
– Mobility: Agents that can travel in network
– Autonomy: Agent itself decides when and where to
migrate next

• Self-contained and identifiable computer programs, bundled


with their code, data, and execution state, that can move
within a heterogeneous network of computer systems.

• Can suspend their execution on an arbitrary point and


transport themselves to another computer system.

• During this migration the agent is transmitted completely, i.e.,


as a set of code, data, and execution state.

• At the destination, execution is resumed at exactly the point


12/09/21 where it was suspended. 16
Mobile agents
• Client can maintain its own interface at the server node – a
mobile agent serves as a proxy
• A given task can be divided into multiple tasks and
distributed among mobile agents – achieve parallelism
• Mobile agent paradigm can be used
– For low level system management
– For middleware user-level applications

RPC for controlling a device/instrument?


parameters
client data server

Back and forth several time


12/09/21 17
The Mobile Agent Model

1. Mobile agent receives client request


2. Mobile agent moves into fixed network
3. Mobile agent acts as a client to the server
4. Mobile agent performs transformations and
filtering
5. Mobile agent returns back to mobile
platform, when the client is connected

12/09/21 18
Comparison of 3 Network computing
paradigm
• Client-Server Paradigm Code-on-Demand Paradigm
Download
Server (Applet) Know
Server
Client Client how
Know- Know-
how how

Mobile Agent Paradigm

Agent Agent
Network
Know- how Know- how

Host Host
12/09/21 19
A Mobile Agent Dissected
• A mobile agent contains the following 3 components:

– Code - the program (in a suitable language) that defines the


agent's behavior. Some kind of executable representation of
computer programs. It Can be :
• Source code, in the case of scripting languages such as Perl or
Tcl
• Byte code, in the case of Java
• Executable machine language, in the case of C

– State - the agent's internal variables etc., which enable it to resume


its activities after moving to another host. Might be quite complete
info from within the underlying (virtual) machine about
• Call stack
• Register values
• Instruction pointers
– Attributes - information describing the agent, its origin and owner,
its movement history, resource requirements, authentication keys
etc. Part of this may be accessible to the agent itself, but the agent
must not be able to modify the attributes. All variables of the agent
(in OO languages, set of all attributes of the corresponding object)
12/09/21 20
Agent States and Lifecycle
• At any point in its lifecycle, an agent resides in one of the
following three states:
– Active: Agent enters this state on creation; in this state, agent is
executing inside the live() method (agent thread running); after
the live() method completes, the agent is still active, and can
have its methods invoked by other agents
– Suspended: Agent thread suspended; a suspended agent
cannot have its methods invoked by other agents, and can
resume itself
– Flushed: Agent’s data state (persistently) stored, but agent
instance is removed from the agency; a flushed agent re-
activated (indirectly) by other agents invoking methods on the
flushed agent

12/09/21 21
Agent States and Lifecycle
creation flushing
active reactivation flushed

suspension resumption

deletion
suspended

There are methods to change the state of an agent:


e.g., FlushAgent(), suspendAgent( ), resumeAgent()
12/09/21 22
Events in Mobile Agent’s life-time
• Creation: A brand new agent is born and its state is
initialized.
• Dispatch: an agent travels to a new host.
• Cloning: a twin agent is born and the current state of the
original is duplicated in the clone.
• Deactivation: an agent is put to sleep and its state is saved
in persistent storage.
• Activation: a deactivated agent is brought back to life and
its state is restored from persistent storage.
• Retraction: an agent is brought back from a remote host
along with its state to the home machine.
• Disposal: an agent is terminated and its state is lost forever.
• Communication: Notifies the agent to handle messages
incoming from other agents , which is the primary means of
inter-agent correspondence

12/09/21 23
MA System Architecture
• The main components include
– mobile agents (defined before)
– places
• supports the execution of particular procedures and provides
access to local resources.
– agent systems
• Places inside an agent system may share resources, code, or
security mechanisms and, in general, have a privileged
relationship with each other and less expensive mobility.
– Regions
• Agent systems may be grouped in regions. A region represents
a security domain where network-wide resources are accessed
following a uniform policy.
– Principals
• Agents, places, agent systems, and regions are associated with
a number of principals that represent real-world entities such as
a person, an organization, or a company.
12/09/21 24
12/09/21 25
Requirement of a MAS
– Agent Execution Support,
– Management Support,
– Security Support,
– Mobility Support,
– Unique Identification of Agents Support,
– Transaction Support, and
– Communication Support.
Why study agents?
• Integrate many diverse disciplines of computer
science
– Objects technology
– Distributed object architectures
– AI
– Security

12/09/21 26
Stationary VS Mobile
• Stationary agent
– Can just sit there and communicate with its
environment through conventional means (RMI &
message passing)
– Executes only on the system on which it begins
execution
• Mobile agent
– Free to travel among the hosts in the network
– Transport is state and code with it

12/09/21 27
Mobility concepts for mobile agents
• Remote Execution
– The agent program is transferred before its activation to some
remote node, where it runs until to its termination
• Remote Evaluation
– An operation (a procedure + parameters) is transferred to a remote
site, where it is performed entirely.
• Code on demand
– The destination itself initiates the transfer of the program code.
(ActiveX , Java Applets)
• Code mobility (Remote execution and Code on
Demand) – Mobile Code
– transfer agent programs before their activation.
• Agent mobility – Mobile Agent
– May migrate from node to node in a network

12/09/21 28
• Alternatives to mobile agent: Almost everything you can do with MAs
could be done with some other, more traditional technology.
• Message passing
– Sockets
– HTTP/CGI
– Servlets
• Remote Function Call
– RMI
– RPC
• Middleware
– Corba
– DCOM
• 7 reasons for choosing Mobile agent
– They reduce the network load
– They overcome network latency
– They encapsulate protocols
– They execute asynchronously and autonomously
– They adapt dynamically
– They are heterogeneous
– They are robust and fault-tolerant
12/09/21 29
Agent application
• Low level
– Network maintenance
– Testing and fault diagnosis
– Installation and software upgrade
• Middleware – user applications
– Electronic market place
– Active mail messages
Agent Server
• Agent code execution
• Primitive operations
– Migrate
– Communicate
– Access resources
– Application specific services
12/09/21 30
What application domains do mobile
agents have potential deployment?
1. Data-intensive applications where the data is remotely
located, is owned by the remote service provider, and the
sure has specialized needs.
2. Agents are launched by an appliance – i.e. limitation
computing power and memory
3. Mobile client - Cellular phone and PDAs.
4. Extensible servers, where a user can ship and install an
agent representing him more permanently on a remote
server.
 Personalized e-commerce
5. Disconnected computing.
6. Information retrieval situations
 Can sent a agent to the large data source and filter
through the data locally.
12/09/21 31
Application Areas for Mobile Agents

• Data collection from many places


• Searching and filtering
• Monitoring
• Negotiating
• Bartering
• Parallel processing
• Entertainment
• Targeted information dissemination
• Distributor may send software updates
and versions to the user.
12/09/21 32
Applications of Agent Systems
• E- Commerce – Agents act and negotiate on behalf of the user. Example:
Auctions, service negotiations, etc.
• Personal Assistant – acts like a remote assistant. For example, can search
and book airline ticket depending on a search criteria.
• Secure Brokering - Mobile agents meet and collaborate on mutually agreed
secure host.
• Distributed information retrieval - Agent are dispatched to remote
information sources and they can perform extended searches not restricted
by working hours or connectivity.
• Information distribution – works on the push model. Software
• Parallel processing – agents can execute concurrently in a distributed
system. A single task can be decomposed amongst multiple agents.
• Network Security testing - Agents can be used in network intrusion
detection.
• Database searches – It is efficient to send out an agent to perform a
specialized search on a large database than to move big chunks of data to
the client using up enormous amount of bandwidth.

12/09/21 33
Potential usage for mobile client
• Mobile clients’ feature:
– They only intermittently connected to a network,
– Even when connected they have limited bandwidth
– They have limited storage and processing
capability
• Mobile agents’ feature:
– Reduction of Network traffic
– Asynchronous interaction
– Remote searching and filtering
12/09/21 34
Concordia Architecture
Concordia
Server
Event Service
Agent External
Manager Bridge Service

Directory
Persistence Agent
Manager Manger
Manager
Networ
k

Password DB
Queue
Manager Security
Concordia Server Manager

Concordia Remote Administration API Permission DB


Server
Password DB
12/09/21 Administrator 35
Permission DB
Advantages of Mobile Agents
• Some advantages which mobile agents have over
conventional agents:
• Computation bundles - converts computational client/server
round trips to relocatable data bundles, reducing network
load.
• Parallel processing -asynchronous execution on multiple
heterogeneous network hosts
• Dynamic adaptation - actions are dependent on the state of
the host environment
• Tolerant to network faults - able to operate without an active
connection between client and server
• Flexible maintenance - to change an agent's actions, only
the source (rather than the computation hosts) must be
updated
• One particular advantage for remote deployment of software
includes increased portability thereby making system
requirements less influential.
12/09/21 36
Concordia:-A framework for mobile agents
• Concordia is a full – featured framework for development and management of n/w
efficient mobile agent applications. Concordia consists of multiple components (all
written wholly in Java), which combine together to provide a complete, robust
environment for applications.
• Concordia Architecture:
• A Concordia system is made up of a
– JVM (Java Virtual Machine)
– a Concordia server
– at least one agent
• JVM – It is a standard environment, it can be on any machine.
• Concordia server- It is a java program, which runs there $ at any other nodes on
the n/w where agents may need to travel.
• Agent – It is also a java program, which the Concordia server manages including
its code, data and movement.
• There are many Concordia server; The Concordia server are aware of one another
and connect on demand to transfer agents in a secure and reliable fashion. The
agent initiates the transfer by invoking the Concordia server’s methods. After being
transferred, the agent is queued or execution on the receiving node. The work that
the agent performs depends on its purpose, i.e. the code, which it was
programmed to execute. To have a reliable guarantee of agent transfer: = (RAT)
while transferring the agent, agent, Concordia servers suspend the agent and
create a persistent image of it to be transferred. The Concordia server inspects an
object called the Itinerary, created and owned by each agent, to determine the
appropriate destination. That destination is contacted and the agent’s image is
transferred, where it is again stored persistently. In this way the agent is given a
reliable guarantee of transfer. In all the cades, the Concordia agent is autonomous
12/09/21and self- determining in its operation. 37
Concordia:-A framework for mobile agents
• Concordia components: = The Concordia system is made up of numerous components, each of
which integrates together to create the full Mobile agent framework. The Concordia server is the
major building block, inside which the various Concordia managers reside-
• Note- All Concordia components are coded completely in Java language.
1. Concordia server – It provides the communications infrastructure that allows for agents to be
transmitted from and received by nodes on the n/w. It also manages the life cycle of the agent. It
provides for agent creation and destruction and also provides an environment in which the agents
execute.
2. Administration Manager – It manages all of the services provided by Concordia, including
Concordia servers, security managers, event manager etc. the administration manager supports
remote administration from a control location, so only one Administration manager is required in
the Concordia n/w.
3. Security manager – It is responsible for identifying uses, authenticating their agents, protecting
server resources and ensuring the security and integrity of agents and their accumulated data
objects as the agent moves among systems.
4. Persistence Manager – It maintains the state of agents in transit around the n/w. It also allows
for the checkpoint and restart of agents in the event of system failure.
5. Event Manager – It handles the registration, posting and notification of events to and from
agents. The events manager can pass event notification to agents on any node in the Concordia
n/w. The event manager works in conjunction with the Concordia server, to distribute events as
needed. It also supports Concordia agent collaboration.
6. Queue Manager – It is responsible for scheduling and retrying the movement of agents n/w
Concordia systems. It also provides the mechanism for prioritizing and managing the execution of
agents on entry to Concordia nodes. (Retrying – necessary when Concordia systems are
disconnected from the n/w. Maintaining persistent state, as they enter and leave a system.)
7. Agent Tool Library – The ATL is a library, which provides all the classes needed to develop
Concordia mobile agents.

12/09/21 38
Concordia:-A framework for mobile agents
• Uses of Concordia Agents:-
– Process data at the data source
– All data with them as they travel i.e. they “Learn”
– Can literally run anywhere: Web, desktop, palmtop etc.
– Enable highly scaleable $ parallel programming.
– Hide the n/w transport from application, developer and user
– Hide distribution, scale, and parallelism from application.
• Uses of Concordia Systems:-
– Offer rapid prototyping with easy paths to production
– Offer robust operation via persistent agents
– Provide security and integrity
– Support off- line and/ or disconnected operation
– Provide for heterogeneous database access
– Are a natural for s/w distribution: agent carry code to remote platforms
• Uses of Concordia:-
– Enables mobilization of legacy applications
– Is a great way to program mobile devices as clients of applications
– Breaks client/server barriers
– Integrates with distributed objects e.g. CORBA
– Integrates with legacy systems e.g. databases
– Easily run standalone.

12/09/21 39
Concordia:-A framework for mobile agents

• Advantages of Concordia
• Concordia is written in Java, therefore it is portable, even
ubiquitous
• Concordia agents provide for mobile applications, Agent
support mobile computing as well as off- line processing and
disconnected operation.
• Concordia agents are secure, each agent carries the identity
of the user that created it, and the operations the agent
requests are subjected to the same user’s permissions.
• Concordia agents are reliable; All Concordia agents are check
pointed before execution by the persistence manager.
• Concordia agents can collaborate, It can divide a task into
suitable pieces and these pieces can be carried out in the
most appropriate places. The results of these sub- tasks are
then assembled by collaboration.
12/09/21 40
Security

• Agent Privacy and integrity


– Part of the agent system may be sensitive
– Agent may not trust all servers
– Selective – servers
– Security breaches in the code – hard to prevent but
detectable
– Secure communication
• Agent and server authentication
– Identity – digital signatures
• Authorization and access control
• charging and payment mechanisms

12/09/21 41
Classification of Security threats in an Mobile Agent System

1. Security between 2 agents


2. Security between agents and hosts
3. Security between host
4. Security between hosts and unauthorized third parties

12/09/21 42
Classification of Security threats in an Agent
System
•Agents attacking Hosts - Malicious agents can steal or modify the data
on the host. Lack of sufficient authentication and access control
mechanisms lead to these attacks. If resource constraints are not set, they
can also commit Denial of Service( DoS ) attacks by exhausting
computational resources and denying platform services to other agents
(Masquerading, Denial-of-Service, Unauthorized service).
•Hosts attacking the Agents – A malicious host can attack the agent, by
stealing or modifying its data, corrupting or modifying its code or state,
deny requested services, return false system call values, reinitialize the
agent or even terminate it completely. It can also masquerade the agent by
delaying the agent until the task is no more relevant. The Host may also
analyze and reverse engineer the agent( Masquerading, Denial-of-Service,
Eavesdropping, Alteration).
•Malicious Agent attacking another agent – A malicious agent may
invoke public methods of another agent to interfere with its work
(Masquerading, Denial-of-Service, Unauthorized service, Repudiation).
•Attack by other entities – Some other entity in the network may
manipulate or eavesdrop on agent communication (Masquerading, Denial-
12/09/21
of-Service, Unauthorized service, Copy or Replay). 43
Between two agents
• Attacks :
– code and data manipulation by having physical access to the
code and data areas
– Masking of agents (I.e. faking a wrong identity)
– Cheating (e.g. using a service without paying for it)
– Denial-of-service (e.g. by filling a message pool, message
booming)
– Mechanism that prevent such attacks:
• Authentication: Authenticity requires that the sender can validate
the source of a message.
• Secrecy: An intruder can’t find out the plain text for a given cipher
text and should not be able to reconstruct the key by examining the
cipher text for a known plain text.
• Integrity: It is the ability of an assurance that an information has not
been modified accidentally or deliberately by insertion, deletion, or
replacement.
• Resource / Access Control: Limited resource and runtime
restrictions.

12/09/21 44
Security Measures
Security in Agent System is based on the principle of trust. A
set of security policies and protocols establish the trust
relationship between the entities.
It is assumed that the agent trusts the Home platform that
dispatches it.
Agent attacking the Host environment
•Traditional methods such as authentication, access control,
sand-boxing techniques, cryptography can be used to secure
the Host.
• Authentication and access control mechanisms – This is the
first line of defense against a malicious agent. If the Host can
authenticate the agent and in turn the device that dispatched
the agent, it can apply authorization and access control.
•Safe Code Interpretation – Due to the necessity for the
agents to run on heterogeneous computer , interpreted
scripting or programming languages are used. This produces
intermediate code that is executed by a virtual machine that
sits on top of the native processor and OS. This virtual
machine can enforce additional security.
12/09/21 45
• Path Histories - An agent could reach the host by making a
number of hops. During this transit a malicious host could have
morphed the agent into a malicious agent. By storing the log of the
travel of the agent, the current host can determine the route taken by
the agent. . Each host platform to which the agent travels to,
appends a signed entry to the path. This entry indicates the hosts
identity as well as the identity of the next host the agent intends to
visit. The platform has to judge by looking at the log if the previous
platforms can be trusted.
• State Appraisal – The author of the agent supplies a state appraisal
function called maximum function. This function calculates,
depending on the state of the agent, the maximum set of permissions
to be granted to the agent. This function is packaged together with
the agent. The user/owner of the agent also supplies another state
appraisal function called the request function. This calculates the
permissions the user wants the agent to have during execution. The
host platform uses these state functions to verify the correct state of
the agent and hence determines the privileges to give to the agent
depending on its state. This ensures that the agent has not turned
12/09/21 malicious due to alterations of its states. 46
Host Platform attacking the Agents

•Providing security against the attacks by the host is difficult due to the
fact that the host needs to have the full knowledge of the code and the
state in order to execute the agent. Traditional mechanisms are not
sufficient to protect an agent from the attack of malicious hosts.
•Mobile Cryptography – Cryptography is used to maintain code and data
privacy and integrity. Both code and data can be encrypted.
Encrypted Functions – For the host to execute the agent, it has to
have full control over the code. As prevention, the function of the agent is
encrypted according to some conversion algorithm. This encrypted
function is implemented as a cleartext program. Even though the host is
able to read the program it won’t understand what the program does i.e.
the “program’s function”. The disadvantage of this technique is finding the
encryption schemes to transform the arbitrary functions.
Encrypted Data - The agent data is encrypted and sent to host for
computation. The data that the agent needs for its computation may have
to be decrypted again and again at the host platform. For this reason, the
agent will have to carry the decryption key making it that much vulnerable.
12/09/21 47
• Obfuscated code – A “blackbox” agent is generated from the agent
specification wherein the agent’s code and data cannot be read or
modified. Only its input and output can be observed. The algorithm
that creates the agent is called “mess-up or obfuscating algorithm”. To
prevent dictionary attacks the algorithm, that converts the agent specs
into an agent, uses some random parameters. These parameters allow
creation of number of different agents out of the same specification.
The agents differ in code and data representation but give the same
results.
• Secure Routing - An agent can be programmed to have a routing
policy such that it migrates only to certain servers. Since a malicious
host can tamper with the agent’s itinerary and also computation
results, which can propagate, some fault tolerance is needed to ensure
that the agent reaches its destination and perform its job correctly.
Replication and voting can be used to achieve fault tolerance. The
agent is replicated at each stage and run on hosts. The results from
these computations are compared (i.e. voted). Then the correct result is
sent out as output.
12/09/21 48
•Detecting attack using Dummy data –In this technique, dummy data
items called detection objects are used. This dummy data is stored in
the database of the agent and it will not be modified while the agent
performs its functions. After the agents return, if the detection objects
have not been modified, then one can have reasonable confidence that
legitimate data also has not been corrupted. This technique requires
that the dummy data should not adversely affect the results of the
query.
• Using Trusted Hardware - This technique uses tamper proof trusted
hardware to encapsulate the entire agent execution environment in
which the agent executes, thus isolating the agent from the malicious
host. The whole agent is not visible to the host environment. The agent
in this system will interact with the Host environment through
messages. Each Host in the Mobile Agent System is equipped with this
hardware. The hardware can be in form of PC Cards, Smartcards,
Integrated Circuits, etc. PC Cards are powerful and allow the whole
agent code to be loaded into the card. Smartcards are limited in their
capabilities. Only a part of agent code can be loaded on the card. The
agent carries rest of the code along with it. The code that the agent
12/09/21
carries is encrypted. 49
Security Approaches
1. Conventional Encryption Algorithm( Data
Encryption Algorithm, Tripple data Encryption
Algorithm, Advanced Encryption Standard)
2. Public Key Algorithm (RSA, DSS)
3. WAP supports WTLS ( Wireless transport Layer
Security)
4. Wireless Security Standards ( Biometrics, OMAP-
Open Multimedia Protocol developed by Texas, MET-
Mobile Electronic Transactions formed by Ericsson,
Nokia, Motorola and Siemens)
5. Protecting the Server (Sandbox Model, Code
Signing, Firewall, Proof carrying code)

12/09/21 50
Examples of Mobile Agent Systems
• TACOMA(Tux) - Mobile Agent System. Operating System
Support for mobility. Tromosø and Cornell Moving Agents
(TACOMA) is a joint project between the University of Tromosø,
Norway and Cornell University,USA. It is primarily focused on
providing operating system support for agents.

• Telescript- developed by General Magic, includes an object


oriented,type-safe language for agent programming.

• Agent TCL is a mobile agent system created at Dartmouth


College. agents are written in the Tool Command Language
(Tcl), which is an embeddable scripting language that is highly
portable and freely available.

• Aglets is a Java based system developed by IBM. Agents are


called aglets in this System.

12/09/21 51
Advantages of an Agent System
•Reduces network load and latency – There is usually no
transmission of intermediate result. This conserves the network
bandwidth.
•Asynchronous – Since the agents are autonomous, the mobile
device that dispatches the agent need not be connected all the
time.
• Fault Tolerant – If one of the host is down, the agent can be
transferred to another host for execution. The agents can be
programmed to adapt dynamically to the network conditions.
•Can be customized according to the needs.
•Can be deployed in a heterogeneous environment, as only
the execution environment is of concern not the specifics of
12/09/21 52
the Host Platform.
Disadvantages Of using Mobile Agents

• Mobile agent tools are still new and may have security
bugs and vulnerabilities that are yet unknown.
• Network test suites tend to be relatively large.
Managing many lightweight agents introduces additional
communication and control overhead.
• MA are not a mature technology and most agent
development tools are alpha or beta versions.
• Although an agent’s ability to travel throughout the
N/W introduces fault-tolerant properties to the security
tool, it also exposes the agents to new security
threats and risks that host-based security tools do not
encounter.

12/09/21 53
Fault Tolerance
• Fault tolerance is the ability of a system to perform its function
correctly even in the presence of internal faults. The purpose of
fault tolerance is to increase the dependability of a system. A
complementary but separate approach to increasing
dependability is fault prevention. This consists of techniques,
such as inspection, whose intent is to eliminate the
circumstances by which faults arise.
• A failure occurs when an actual running system deviates from
his specified behavior. The cause of a failure is called an error.
An error represents an invalid system state, one that is not
allowed by the system behavior specification. The error itself is
the result of a defect in the system or fault. In other words, a
fault is the root cause of a failure. That means that an error is
merely the symptom of a fault. A fault may not necessarily result
in an error, but the same fault may result in multiple errors.
Similarly, a single error may lead to multiple failures.

12/09/21 54
General Fault Tolerance Procedure

• Error detection is the process of identifying that


the system is in an invalid state. This means that
some component in the system has failed. To
ensure that the effects of the error are limited, it is
necessary to isolate the failed component so that its
effects are not propagated further. This is known as
damage confinement. In the error recovery phase,
the error and -- more importantly -- its effects, are
removed by restoring the system to a valid state.
Finally, in fault treatment, we go after the fault that
caused the error so that it can be isolated. In other
words, we first treat the symptoms and then go after
the underlying cause. While it may seem more
appropriate to go after the fault immediately, this is
often not practical, since diagnosing the true cause
of an error can be a very complex and lengthy
process. In a software system, it is typical for a
single fault to cause many cascading errors that are
reported independently. Correlating and tracing
through a potential multitude of such error reports
often requires sophisticated reasoning.
12/09/21 55
General Fault Tolerance Procedure
• Error Detection
• The most common techniques for error detection are:
• Replication checks -- In this case, multiple replicas of a component perform the same service
simultaneously. The outputs of the replicas are compared, and any discrepancy is an indication
of an error in one or more components. A particular form of this that is often used in hardware
is called triple-modular redundancy (TMR), in which the output of three independent
components is compared, and the output of the majority of the components is actually passed
on. In software, this can be achieved by providing multiple independently developed
realizations of the same component. This is called N-version programming.
• Timing checks -- This is used for detecting timing faults. Typically a timer is started, set to
expire at a point at which a given service is expected to be complete. If the service terminates
successfully before the timer expires, the timer is cancelled. However, if the timer times out,
then a timing error has occurred. The problem with timers is in cases where there is variation
in the execution of a function. In such cases, it is dangerous to set the timer too tightly, since it
may indicate false positives. However, setting it too loosely would delay the detection of the
error, allowing the effects to be propagated much more widely.
• Run-time constraints checking -- This involves detecting that certain constraints, such as
boundary values of variables not being exceeded, are checked at run time. The problem is that
such checks introduce both code and performance overhead. A particular form is robust data
structures, which have built-in redundancy (e.g., a checksum). Every time these data
structures are modified, the redundancy checks are performed to detect any inconsistencies.
Some programming languages also support an assertion mechanism.
• Diagnostic checks -- These are typically background audits that determine whether a
component is functioning correctly. In many cases, the diagnostic consists of driving a
component with a known input for which the correct output is also known.
12/09/21 56
Damage Confinement
• This consists of first determining the extent to which an
error has spread (because time may have passed
between the time the error occurred and the time it is
detected). It requires understanding the flow of information
in a system and following it -- starting from a known failed
component. Each component along such flows is checked
for errors, and the boundary is determined. Once this
boundary is known, that part of the system is isolated until
it can be fixed.
• To assist with damage confinement, special "firewalls" are
often constructed between components. This implies a
loose coupling between components so that components
outside of the firewall can be easily de-coupled from the
faulty components inside and re-coupled to an alternative,
error-free redundant set. The cost of this is system
overhead, both in performance (communication through a
firewall is typically slower) and memory
12/09/21 57
Error Recovery

• To recover from an error, the system needs to be restored to a valid


state. There are two general approaches to achieving this. In
backward error recovery, the system is restored to a previous
known valid state. This often requires checkpointing the system
state and, once an error is detected, rolling back the system state to
the last checkpointed state. Clearly, this can be a very expensive
capability. Not only is it necessary to keep copies of previous states,
but also it is necessary to stop the operation of the system during
checkpointing to ensure that the state that is stored is consistent. In
many cases, this is not viable, since it may not be possible to restore
the environment in which the system is operating to the state that
corresponds to the checkpointed state.
• For such cases, forward error recovery is more appropriate. This
involves driving the system from the erroneous state to a new valid
state. It may be difficult to do unless the fault that caused the error is
known precisely and is well isolated, so that it does not keep
interfering. Because it is tricky, forward error recovery is not used
often in practice.
12/09/21 58
Fault Treatment
• In this phase, the fault is first isolated and then repaired. The repair procedure
depends on the type of fault. Permanent faults require that the failed component be
replaced by a non-failed component. This requires a standby component. The
standby component has to be integrated into the system, which means that its state
has to be synchronized with the state of the rest of the system. There are three
general types of standby schemes:
• Cold standby -- This means that the standby component is not operational, so that
its state needs to be changed fully when the cutover occurs. This may be a very
expensive and lengthy operation. For instance, a large database may have to be fully
reconstructed (e.g., using a log of transactions) on a standby disc. The advantage of
cold standby schemes is that they do not introduce overhead during the normal
operation of the system. However, the cost is paid in fault recovery time.
• Warm standby -- In this case, the standby component is used to keep the last
checkpoint of the operational component that it is backing up. When the principal
component fails, the backward error recovery can be relatively short. The cost of
warm standby schemes is the cost of backward recovery discussed earlier (mainly
high overhead).
• Hot standby -- In this approach, the standby component is fully active and
duplicating the function of the primary component. Thus, if an error occurs, recovery
can be practically instantaneous. The problem with this scheme is that it is difficult to
keep two components in lock step. In contrast to warm standby schemes, in which
synchronization is only performed during checkpoints, in this case it has to be done
on a constant basis. Invariably, this requires communications between the primary
and the standby, so that the overhead of these schemes is often higher than the
overhead for warm standby.

12/09/21 59
Characteristics of Fault Tolerance
• The basic characteristics of fault tolerance
require:
• No single point of failure
• No single point of repair
• Fault isolation to the failing component
• Fault containment to prevent propagation
of the failure
• Availability of reversion modes
12/09/21 60
Fault Classifications

12/09/21 61
Fault Classifications
• Based on duration, faults can be classified as transient or permanent. A transient fault
will eventually disappear without any apparent intervention, whereas a permanent
one will remain unless it is removed by some external agency. While it may seem that
permanent faults are more severe, from an engineering perspective, they are much
easier to diagnose and handle. A particularly problematic type of transient fault is the
intermittent fault that recurs, often unpredictably.
• A different way to classify faults is by their underlying cause. Design faults are the
result of design failures, like our coding example above. While it may appear that in a
carefully designed system all such faults should be eliminated through fault
prevention, this is usually not realistic in practice. For this reason, many fault-tolerant
systems are built with the assumption that design faults are inevitable, and theta
mechanisms need to be put in place to protect the system against them. Operational
faults, on the other hand, are faults that occur during the lifetime of the system and
are invariably due to physical causes, such as processor failures or disk crashes.
• Finally, based on how a failed component behaves once it has failed, faults can be
classified into the following categories:
• Crash faults -- the component either completely stops operating or never returns to a
valid state;
• Omission faults -- the component completely fails to perform its service;
• Timing faults -- the component does not complete its service on time;
• Byzantine faults -- these are faults of an arbitrary nature.

12/09/21 62
Fault Tolerance
• Checkpointing is a fault tolerance technique
widely used in various types of computer
systems. In checkpointing, an important issue is
how to achieve a good trade-off between the
recovery cost and the system performance.
Excessive checkpointing would result in the
performance degradation due to the high costly
I/O operations during checkpointing. Equidistant
and equicost are two well-known checkpointing
strategies for addressing this issue.
12/09/21 63
Common Transaction
• Traditional Transaction Processing
IBM

Database Server 2
HEWLETT
PACKARD

Database Server 1

Router
3Com

Base Station 0

Router
3Com

IDC

Database Server 0 3Com

Base Station 3
Client

Base Station 1

Base Station 2

12/09/21 64
Common Transaction
• Known database (Typically one)
• Bounded duration (Compared to long
transactions)
• Few or no interactions with other
concurrent events
• ACID properties easy to achieve

12/09/21 65
TRANSACTION CONCEPT FOR MOBILE COMPUTING:-
• Transaction Processing is a type of computer processing in which the computer
responds immediately to user requests. Each request is considered to be a
transaction. In other words, Transaction Processing is into processing that is divided
into individual, indivisible operations called, transactions. Each transaction must
succeed or fail as a complete unit; it can not remain in an intermediate state i.e. during
transaction processing either all operation carried out successfully or all cancelled
successfully. A computation processing is considered as a transaction, if it satisfies
ACID properties: =
• Atomicity – Program when finally terminate, has one initial state & one final state, then
this program satisfy the atomicity property; & said to be committed otherwise it is
aborted or rollback.
• Consistency – If a program produces consistent result.
• Isolation – If a program is executing as if it is an only single program.
• Durability – If a program reaches its final state & the result is made available to the
outside world then this result is made permanent.
• Programming model of a Transaction: =
• Begin-transaction ()
• Execution of transaction program
• If (reach- final- state)
• Then
• Commit – work (final- state)
• Else
• Rollback- work (initial- state)

12/09/21 66
Forms of Transaction
• Forms of Transaction: - The simplest form of transaction is flat transaction. A flat
transaction can be considering as a sequential computer program. Its disadvantage is
that it cannot support for long transaction efficiently coz if failure happens during its
execution then it has to rollback to is initial state & wastes all of useful computation.
• Nested Transaction is a more flexible transaction mode. This model is a tree of
transaction is refined into many smaller flat transaction called sub transactions. These
sub transactions can execute concurrently.
• We define a model that ensure consistency account for mobility & provide for recovery.
The user of mobile host need to have an idea of the validity of the data they read,
some assurance that their updates will be saved & understanding of the into of their
work with the work of the other concurrently accessing the same data.
• Modeling Transaction: - A mobile transaction is a distributed transaction where some
part of the computation are executed on mobile & some part on non-mobile host.
• Wireless connection are expensive. Finally mobile computation is more error prone
because of frequent disconnection & because mobile host are more susceptible to
accident than fixed host. Traditionally transaction are modeled as a sequence of read
& write operation which have a structure with a single begin & a single abort or commit
points. In mobile environment, transaction model are complex, long-lived activities that
involves multiple & heterogeneous database.
• We model a transaction using an open-nested model-
• Transaction Composed of
• No. of dependences related No. of user defined Sub transaction
• Example – Transaction that are executed as alternative when a specified transaction
fail to commit.

12/09/21 67
• Transaction Structure:- Traditionally, transaction satisfy the ACID properties. Each transaction
is atomic when either all or none of its operations are executed. Isolated, when it dose not
observe the partial result of any other transaction. Durable & consistency operations are also
very strict. Mobile transaction may read out data (local data) while they are disconnected.
• Data Consistency:- It is crucial to allow a mobile host to operate even while it is disconnected.
Furthermore, since n/w bandwidth is a scarce & expensive resource in a mobile environment,
semantically related or closely located data are grouped together to form a “cluster”. While full
consistency is required for all data inside a cluster; degree of consistency are defined for
replicated data located at different Clusters.
• The degree may depend on-
• Availability of bandwidth
• User may tolerate higher degree of inconsistency. The cluster configuration is dynamic clusters
are defined or merged as mobile user enter new cell or connect to & disconnect from the rest of
the n/w. consistency among the clusters is reshared when cluster are merged. User can access
locally consistent data by issuing weak transaction & globally consistent data using strict
transaction.
• Example- A weak read operation reads the local available copy; A weak write operation write
the locally available copy; This update is later propagated to other cluster & is being committed
only if it does not conflict with other strict writes.
• Transaction Relocation:- It may be necessary to relocate part of the computation that is being
executed on fixed host to another fixed host to minimize comm. Cost & improve response time
by minimizing the physical distance b/w the host or by changing n/w load & availability or for
security consideration.
• Example- A base station may not be willing to support computation initiated by the user that are
not any more in the geographical area covered by it. Finally, transaction relocation may be
initiated to satisfy load balancing condition among the base station as result of n/w or server
failure. This information is necessary for the new host to continue the execution of the
transaction.
• Recovery: - Connection through wireless connection is more unreliable than connection through
wired link. Thus, ensuring durability of computation performed in mobile distributed environment.
Concept of Proxy Transaction is used. A proxy transaction is a sub transaction of original
transaction.
12/09/21 68
Mobile Computing Model
Mobile Workflow
Ad-hoc
Mobile Mobile
Server Transaction
Mobile
Query
Mobile
Mobile
Client
Client

Client/Server

Fixed Network Servers and clients

12/09/21 69
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.

12/09/21 70
• 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.

12/09/21 71
• Techniques – Some of the techniques developed to apply in mobile transactions are-
• 2PC protocol
• Caching mechanism need to be extended.
• Make intermediate state of mobile transactions available to others.
• The initiator of a transaction takes the role of the coordinator, which in the first phase collects the
votes about the result of transaction from different partners. In the second phase, it transmits the
result, (Commit: makes result of transaction permanent or Rollback: discard all changes) to other
partner, which subsequently confirm the receipt thus, the 2PC is quite robust for the commn in
distributed system.
• 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
• Issues in Mobile Transaction Processing:=/ Challenges
• Mobile Transactions are-
• Long-lived
• Bound to many diff. types of mobile devices
• Involved in heterogeneous database & n/w
• Execution time is varying

12/09/21 72
• 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).

12/09/21 73
• 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.

12/09/21 74
• The benefits to secure agent system architecture brings are-
• Security for the host:= With the secure architecture agent system an agent
is only introduced in the system by a trusted user & can only followed on a
chain of trusted hosts. In case of break of trust by the agent, the originator of
the agent can be informed & called to account for the actions of his agent.
• Indirect security can be achieved by using safe languages like safe-python-
• Security for the agent:= Besides the scope of trusted hosts, no other
instance has access to the agent due to the encryption methods used. So.
No untrusted third party can copy, modify, destroy or rob the agent, if one
system can track this break of trust & similar to the host security case, call
the responsible person to account.
• Agent Control & Management:= With the information about the agent & its
itinerary at the trust service, suitable control & Mgnt functions can be
implemented. The owner of an agent can every time locate it & give new
instructions to it also a control of its time& goals can be achieved.
• Fault Tolerance & reliable agent transfer:= The agent can neither be
duplicated nor be lost. During the critical phase of the transport of the agent,
the 2PC protocol guarantees the preservation of a consistent state of the
whole system.
• In case of error situations & host crashes, the recovery & rollback
mechanisms of the DTP system responsible for a reliable & consistent
resumption of the agent transport.
• E-Commerce enhancement for mobile agets:=An agent can cope with
money transaction. In case of an error, the money transaction will be refused.

12/09/21 75
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.

12/09/21 76
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.

12/09/21 77
Transaction Models
• Transaction Models:- / Mobile transaction Mgmt. Models
• Maintaining full consistency among all distributed sites can bear huge overheads on the
mobile distributed databases due to disconnections & low copacity wireless links.
• Some models propose a consistency model:-
• Clustered Model
• Kangaroo Model
• Manet Model
• Tcot protocol
• Deno Model
• Pro- Motion model
• Pre- serialization transaction mgt. model.
• CLUSTERED MODEL:-
• In this sites are grouped in clusters if they are connected by strong n/w links.
• In a cluster, full consistency is always enforced; however over the cluster, a bounded
inconsistency is permitted.
• A site can be a member of a cluster or leave one dynamically, based on the n/w
conditions. Eg. A mobile host forms a cluster itself when it is disconnected.
• Mobile Transaction are grouped into two-
– Strict transactions (Strict transaction can only access data that is accessed by a strict transaction
or globally committed weak transaction . They are not allowed to access inconsistent data.)
– Weak Transactions (Weak Transactions access data in the same cluster & they have two commit
points ( In cluster & in global))
• Global Commit can only be made after clusters merge.

12/09/21 78
• 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.

12/09/21 79
• 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.

12/09/21 80
Example Scenario
IBM

Database Server 2
HEWLETT
PACKARD

Database Server 1

Router
3Com

Base Station 0

Router
3Com

IDC

Database Server 0 3Com

Base Station 3

Base Station 1

Base Station 2

12/09/21 81
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

12/09/21 82
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
12/09/21 83
• ACID (?)
MT Approaches
• No consensus on accepted approach
• MU may not have primary copy of data
– Transaction Proxy: MU does no transaction processing
– Read Only Transaction: MU only reads data
– Weak Transaction: Read and update cached data; Must
synchronize updates with primary copy on FN.
• MU may have primary copy of data
• MU may access data on other MUs
• First class and second class transactions

12/09/21 84
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

12/09/21 85
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)

12/09/21 86
12/09/21 87

You might also like