Locating Mobile Agents in Distributed Computing Environment

Locating Mobile Agents in
Distributed Computing
Environment
Reference
[1] A. Di Stefano, and C. Santoro, “Locating
Mobile Agents in a Wide Distributed
Environment,” IEEE T-PDS, vol 13, no. 8,
Aug 2002, p. 844 – 864.
Problem Context
• Agents are mobile
• Agents work with other agents
– Cooperation, coordination, competition,..
• Agents must find other agents
– Addressing technique for unique identification
– Applications use names not identifiers
– Naming scheme, that permits programmers
autonomous name selection
Static vs Mobile Agents
• Static entities
– Binding protocol that binds names to addresses
– Address includes the current location of the addressed
entity
• Mobile
– Dynamic nature of the agents increases complexity
– Discover the location
– Additional problem: agents can be created, cloned, and
terminated quite easily
– Need dynamic naming scheme
Dynamic Naming
• Agent name must indicate the start of the
search process
• Name space structure
– Closely related to location protocol
– Transparency, scalability, reliability,
efficiency,….
– In general, the approaches meet some of these
properties
Naming Scheme Properties
• What does the Agent Name represent?
– May be follow the internet convention
• Service.organization.domain
• www.gmu.edu
• Existing schemes can be classified using the following
properties:
– Transparency – to achieve transparency the agent name should
NOT contain site specific information
• cs.gmu.edu/~cs365 is not transparent, but CS365 is transparent.
– Location independence – name does not include info regarding
current position
• Database location + agent name, is location independent but not
transparent.
– Selectability – a naming scheme is selectable if a programmer can
autonomously select a name.
Implications of Properties
• Transparency – non-transparent systems require
that the user have complete knowledge of the
distributed system. Need to know the agent birth
node.
• Locating independence – facilitates agent
interaction without knowing where the agent is
located. Requires a location protocol.
• Selectability – ensures interaction with the parent
and child agent without system wide publication.
Requires an approach to binding.
Finding an Agent Location
• Name and Location Base (NLB)
• Tuple (m, a, l), where name (m), agent (a), current
location(l)
• Four operations on the NLB
– Bind (m, a, l) performed when a name is assigned to agent. Tuple
added to NLB.
– Newloc (m, a, l `) l ` is the new location. In NLB (m, a, l `)
replaces (m, a, l).
– Find (m) extracts a from the NLB.
– Unbind (m) when agent name is no longer used – remove from
NLB.
• Locating a mobile agent requires implementation of NLB
and the 4 operations.
Implementation Issues
• Centralized NLB?
– Scalable, reliable, efficient???
• Each implementation approach must assess the
scalability, reliability and efficiency of the
operations
– Binding at the beginning and end – so less important
– Newloc and Find – repeated use – so more important
– Find may require repetitive application
• Location finding + agent catching
• For rapidly moving agents, repeat the process several times
Implementation Performance Measures
• Availability
A = (MTTF)/(MTTF+MTTR)
• Scalability
• Migration overhead
Qm = (tnewloc)/(tmigr + tnewloc)
tmigr = duration of agent migration
tnewloc = time to execute newloc
• Interaction overhead
Qi = (tcatch)/(tcatch + tinteract)
tcatch = time for finding and catching phase
tinteract = time for interaction
• Scheme should optimize all these!! Utility function!
Multiple objectives leads to compromise
Internet like Naming Scheme [1]
• Human Readable
• Agent location is characterized by
– Birth location
– Current location
• Divide the environment into:
– Places – context where agents can execute
– Agent Systems
– Regions
• Address (Global Location Identifier – GLI) is a combination of Place,
Agent System, Region.
• BGLI (Birth GLI), CGLI (Current GLI)
• Agent name m :: = “agent:” localname “@” BGLI.region
– BGLI.region = region of birth; localname = assigned by programmer
• Unique names are required.
– Some “authority” ensures uniqueness of region name.
– Require a binding protocol to register the new agent and ensure
uniqueness of the “localname”.
Naming Scheme [1] Properties
• Location independence
– Points to birth GLI
• Selectability
– Programmer is able to select a local unique
name
• Transparency
– Limited. Birth place is include in name
• Similar to wireless naming approach
Naming Schemes - Comparison
Scheme
Example
Transparency
(Independence from
network addresses)
Location
Independence
(Independence from
the current place)
Selectability
(Autonomously
assigned by
programmer)
Current place + id
(Aglets)
Myhost:40/28e29d
No
(requires network
info)
No
(depends on current
place)
No (assigned by
system when agent is
spawned)
Current place + name
(AgentTCL,
Grasshopper, MOA)
Myhost:40/myAgent
No
(requires network
info)
No
(depends on current
place)
Yes (programmer can
select name
autonomously)
Reference host +
name (AgentTCL,
Grasshopper, MOA)
Refhost:40/myAgent
No
(requires network
info)
Yes
(depends on reference
place from which
search starts)
Yes (programmer can
select name
autonomously)
Name + birth region
([1])
myAgent@myRegion
Partial
(birth place included
in address)
Yes
(depends on birth
place from which
search starts)
Yes (programmer can
select name
autonomously)
Location Technique – Database Logging
(Objective: Find the current agent location)
Location
database
server
Site 3
Migration
Site 1
Site2
Location Db
Update
At each agent migration, the new location info is sent to db server.
Given agent name, location db server provides agent current location.
Adv: Only one access to the db.
Disadv: Failure at server. Delays when the source and destination are
far from the server.
Location Technique – Path proxies
(Objective: Find the current agent location)
Migration
Proxy Reference
Site 1
Site 2
Site 3
As each agent leaves a site, a proxy object is created that points to the destination site.
Locate agents by following the proxy path.
Adv: Communication between neighboring – distance between server and source /
destination sites is not important.
Disadv: Access time can be long – catching up to the agent. Many “hops”.
Improvement: After time out, Nth proxy object sends info about N+1 proxy object to the
N-1 proxy object, and Nth proxy object is deleted. Reduces number of hops.
Mobile Agents vs Mobile Hosts (Wireless Networks)
• Wireless network incorporate the ability to locate
the mobile host
– The mobile hosts attachment point (base station) is
changing
• Mobile Agents – networks are fixed, agent is
moving
• Protocol related differences
– In the mobile host case, the location protocols are
handled in the network layer
– Mobile agent location is done at a higher level –
transportation or even the application layer
Mobile Agents vs Mobile Hosts (Wireless Networks)
• Distance and speed constraints
– Mobile host speeds are limited. Limited region of
mobility. Location limited to a “neighborhood”.
• Possibly broadcast paging messages in neighboring cells.
• Hierarchical view of the network: cellssubnetsregions….
– Mobile agents migrate at the speed of light. Regions of
operation are more widespread
• Hierarchical approach may work, but for long distances, will
require traversal of several layers. This leads to inefficiencies
Framework of Proposed Solution
• Each region has a site acting as Agent Name
Server (ANS) and on each location there is a Site
Agent Register (SAR)
• ANS
–
–
–
–
Manages the Region Agent Register (RAR) db
Each entry in RAR is (m, l): agent m at location l
l is a GLI or GLI.region
Each RAR entry indicates an agent that is in the region
or has transited through the region
– ANS permits remote access to RAR db, but rules of
concurrency must be maintained
• Mutual exclusion between concurrent requests
Framework of Proposed Solution - 2
• SAR
– An SAR on each location
• Agents at the site or transited through the site
• Entry form (m, a, l):
– Agent a with name m at location l
– a is the agent identifier
– l is a GLI (agent found or transited location),
» GLI.region (agent found or transited region), or
» nil (agent is at the same location as the SAR)
Figure 3: RAR/SAR tuple
meaning
Search-by-Path-Chase Protocol
• For each SAR (similarly for RAR)
– If agent m reaches location at tl, then query to
SAR at tq (tq >= tl) will yield
• Agent if it at l
• If agent has migrated then the location (region)
reached at the next migration after tl.
– This implies that at tq by following a visited location
before tq we can catch up with m.
– Since there could be many hops, SPC design is focused on
reducing the chase.
Steps to Locate an Agent
• Extract birth location from m.
• Contact the relevant RAR.
– If in the RAR, find the SAR. RAR will point to SAR.
• If the resulting tuple has an identifier (a ) then we are done,
else start the search again.
– If not in RAR, contact the ANS of the new region.
– Register always contains a pointer, unless there was a
crash.
• Locks are used to ensure concurrency and correct
updates.
 al