result in location updates, (iv) location updates are done at a subset of LSs, ... queried when a MA is to be located, (vi) the set of LSs, corresponding to a MA, ...
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
Locating Mobile Agents in a Wide Distributed System: A Dynamic Approach R. B. Patel Dept of Computer Engineering M. M. Engineering College, Mullana133203 Haryana, INDIA
Nikos Mastorakis Dept of Computer Science Military Inst. of University Education / Hellenic Naval Academy Terma Hatzikyriakou 18539, Piraeus, GREECE
Abstract: Managing location information of mobile agents (MAs) is an important issue in MA based mobile computing systems. There is a tradeoff between location update effort (when an agent moves) and agent finding effort. In this paper we present a dynamic location management strategy that has the following features: (i) all location servers (LSs) need not maintain location information of every MA, (ii) a coterie based approach is adopted for location update and find, (iii) every agent move does not result in location updates, (iv) location updates are done at a subset of LSs, (v) a subset of LSs are queried when a MA is to be located, (vi) the set of LSs, corresponding to a MA, for location update and find operations is dynamic, (vii) the dynamic nature of these sets helps alleviate situations of heavy burden on some LSs, when a large number of MAs are concentrated in a small geographical area. Thus, location management is done efficiently, and responsibility is shared fairly among LSs. Keywords: mobile computing, location management, mobile agent, Location Server, Base Host completely transparent to the migrated code, whereas with weak mobility, extra programming is required in order to save part of the execution state. Strong mobility is found in NOMADS [30], Ara [26], and D’Agents [31], requires that the entire state of the agent, including its execution stack and program counter [32], be saved before the agent is migrated to its new destination. Strong mobility is a complicated task to realize, and typical implementations of this functionality in mobile agent systems as mentioned above, provide platform specific solutions. As a consequence, interoperability between heterogeneous mobile agent systems is difficult, if not impossible, to realize. Many of the mobile agent systems support weak mobility viz., PMADE [33, 34] Ajanta [35] and Aglets [36]. Most of the agent systems are implemented on top of the Java Virtual Machine (JVM), which provides with object serialization basic mechanisms to implement weak mobility. The JVM does not provide mechanisms to deal with the execution state. The ability to locate MAs while they are migrating from one node to another is of great importance for the development of agent-based applications which have to work in geographically distributed environments [3, 4]. This issue becomes even
1 Introduction The ability of mobile agents (MAs) [1, 2] to autonomously move from one part of the network to another part in a MA based mobile computing system. The concept of an agent moving between network nodes gives it the ability to survive and to reach as many resources as possible. This is useful for mobile users [23], [20], [24] due to the fact that they can logon, launch an agent, logoff and check back later on its progress [22], [19]. MAs can be sent to a mobility gateway to pre-fetch Web information and convert the contained multimedia objects to the required transmission bandwidth by using compression techniques that involve data losses [21]. Unlike static networks, the network configuration and topology keep changing in mobile computing systems. The mobility of agents in the network raises interesting issues in the management of location information of these agents. A distinction can be drawn based on whether the execution state is migrated along with the unit of computation or not [25]. Systems providing the former option are said to support strong mobility, as opposed to systems that discard the execution state across migration, and are hence said to provide weak mobility. In systems supporting strong mobility, migration is
1
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
unduly burdened. We have used weak agent migration for the implementation. Rest of paper is organized as follows: Section 2 describes the MA based mobile computing system that is assumed in the rest of the paper. In Section 3, related work on location management is described. Some of the inadequacies of the previous schemes, which motivate our work, are enumerated in Section 4. In Section 5, we present system design for locating MAs. Search algorithm is described in Section 6. Section 7 describes how the LSs are selected for location updates and queries. In Section 8, we describe how the location management strategy handles fluctuations in location query rates of MAs. Overhead analysis of the system is analyzed in Section 9, and the conclusion is presented in Section 10.
more important when focus is shifted from distributed application limited in space, to distributed application whose environment is spread all over the Internet. None of the Javabased MA platform provides a comprehensive, effective location management system: in any case these mechanisms are strictly tied with the platform which they are designed for without exploiting existing techniques for searching or locating objects in the Internet. When a global environment such as the Internet is considered, a centralized naming scheme quickly becomes a bottleneck for the system, providing poor performance: distributed techniques and algorithms are often more effective even if their implementation is more difficult [5], [6]. Creating a fixed location directory of all the agents a priori is not a solution. The location directory has to be dynamically updated to account for the mobility of the MAs. The design of a location directory whose contents change dynamically raises important issues. Some of them are as follows: (i) when should the location directory be updated? If the updates are done each time an agent’s location changes, the directory will always have the latest location information, reducing the time and effort in locating an agent. However, such a policy imposes a heavy burden on the communication network and the location servers (LSs), i.e., systems that maintain the directory. (ii) Should the location directory be maintained at a centralized site, or should it be distributed? A central LS has problems with regard to robustness and scalability. Hence, a distributed directory server is preferable. This leads us to the next questions. (iii) How should the location information be distributed among the LSs? and (iv) Should location information about an MA be replicated across multiple LSs? It is not possible to a priori determine the variations in spatial distribution of MAs in the network, and the frequency with which agent location will be updated or queried. Hence, a location management strategy should address issues (iii) and (iv) so as to ensure fair distribution of responsibility among all the LSs, and be scalable. In this paper we propose a location management strategy in which the location directory is distributed among computers in the static network, such that all the LSs share the responsibility fairly. Also, fluctuations in query rates of MAs are accounted for, so that no LS is
2 System Model We have assumed that the global network environment is divided into network domains, regions (subnetworks) and agent hosts (local sites). Fig. 1 shows a logical view of an agent based mobile computing system. There is a domain management server (DMS) in each network domain which has information about all other DMSs in the global network. It also has information about all the regions in the network domain. It is responsible for maintaining uniqueness of names of regions, which are part of that network and helps to identify the region in which an agent is present. Each DMS maintains a Domain Agent Database (DAD), for information about the current location of all agents which were created in that domain or transited though it. DMS
Internet BH (Gateway) Site
Subnetwork/ Region Network Domain 3
Network Domain 2
AH
Network domain DAD Network Domain 1
Region RAD
Fig. 1. Structure of a Distributed Environment Each region has a base host (BH) it is similar to the mobile service station (MSS). The BHs are connected to each other by a fixed wire
2
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
target region, specifying the host in that region to which it is migrating.
network. A BH can be in wireless communication with the MAs in its region means an agent executing host is wireless mobile device. Every region maintains information about all AHs which are part of that region. An AH can be a member of an existing region or can start in a new region. In each region, a Region Agent Database (RAD) is present at an AH which runs at the BH (gateway) of a subnetwork. It contains location information about each agent which was created in that region or transited through it. This host acts as the Agent Name Server (ANS) [2], which manages the RAD. ANS is responsible for maintaining uniqueness of names of all MAs, created in that region. When a new agent is created, the user assigns a name to it by registering in the RAD of its birth region. The location of an agent can change with time. It may move from its present region to a neighboring region while participating in a communication session, or it may stop communicating with all agents for a period of time and then pop-up in another part of the network. An MA can communicate with other agents which are running on other mobile or static devices, only through the BH of the region in which it is present. If an agent (which is running on static or mobile device) wishes to communicate with an agent, first it has to determine the location of the MA (the region in which the MA is currently residing). This location information is stored at LSs. Depending on the frequency of location updates, this location information may be current, or out-ofdate. Once the location of the MA has been determined, the information is routed through the fixed wire network to the BH of the region in which the MA is present. Then the BH relays the information to the destination MA over a wireless channel. We assume that BHs act as LSs. Hence, all the BHs collectively maintain the location directory. Agent migration from one network domain to another is always accomplished through the DMS. During inter domain migration the agent has to update location information in the DAD of the present domain and register in the DAD of the target network domain. For intra region migration, it has to update its location information in the RAD of that region. This is an Intra Region Location Update. During inter region migration, the agent has to update the location information in the RAD of present region and register in the RAD of the
3 Related Work Once an agent has been launched its owner has no control over it. To give some control or useful information to an agent, it is necessary to locate it. Further, if any agent wants to communicate with another one, it must know its present location. Typically, locating an agent means invoking a function of the form “where_is_agent ( A) ” which returns agent A ’s current address. Various approaches for storing, updating, and locating MAs are addressed in [7], [9], [10], [11]. Updating the location directory each time an MA moves from one region to another can be very expensive. Three alternatives, namely, time-based, number of movements-based, and distance-based strategies for directory updates have been proposed in [8]. The location updates are done less often, and impose lower overheads. A simple solution to location tracking is to have a centralized LS. If the systems maintaining the directory crash, location information about all the systems becomes inaccessible. Also, a centralized directory is unable to exploit the geographical distribution of MAs in the system, and locality of reference patterns to minimize the cost of directory update and query operations. Stefeno et al [7] have developed Search-byPath-Chase (SPC) protocol. In this article authors have assumed that a network is divided into regions and then into sites. Two types of registers are used in which an agent has to register or update its location information, whenever it has to migrate from one site to another. This registering and location updates result in time and network overhead. It increases migration time and ultimately total trip time of the agent. SPC protocol mainly concentrated on providing increased interaction efficiency. Some systems use broadcasting or multicasting approaches to locate MAs. Location queries are broadcast to the entire network, or multicast to a specific group of hosts. Upon receiving such a request, each host checks registered agents and responds if the requested agent is found. This paradigm is mainly applicable to intranets and becomes inefficient in a large-scale network. Furthermore, the result of “where_is_agent ( A) ” is not accurate if A moves to another host
3
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
removed only if a returned message has been received by the corresponding virtual object. The advantage of this approach is that it could automatically track down moving agents. However, it could cause a lot of overhead and delay if remote objects involve frequent movements. Furthermore, a theoretical flaw is that messages might forever chase a frequently moving receiver. This technique does not involve any remote updating during migration, so this phase is not significantly influenced; however, when the agent has to be located, the chain to follow may be very long, thus degrading the performance of the interaction. Often, this technique is modified by adding a suitable timer to each secretary object (timed forward pointers), at the expiry of which, the link reference is sent to the previous secretary object, thus shortening the proxy path and increasing efficiency in location finding.
immediately after the result is returned, which makes message loss unavoidable. To solve this problem, a snapshot broadcasting strategy [14] was proposed. This scheme requires agent communication and migration through a strict FIFO channel, inhibits the movement of the located agent during message passing, and involves considerable system overhead. The following location techniques have been used in existing MASs. 1.
2.
3.
Database Logging (DL) [9], [15], where a fixed LS called Central Server, on a global network, is used to keep track of MA locations. In this mechanism, agents follow a triangular routing to communicate with each other, i.e., a message is first sent to the Central Server, which looks up the destination address and then simply forwards the message to the receiving agent. Unfortunately, the same problem remains. The address returned from the lookup ( A) ” is function “where_is_agent ambiguous: A might still reside at that address, or A might have moved to another host and its location updating packet is on the way to Central Server, or A might even have started to move at the same time a message is sent to its current location. This technique significantly affects the migration process, which could be delayed or aborted when either source or destination location are far from the LS, or a fault occurs in the network link with the host or in the host site itself. DL, however, does not introduce significant overhead during interaction, as location finding requires only a single remote database query. Mailbox [16], which is a set of MA tracking protocols. In this approach, each MA is assigned a mailbox to buffer incoming messages [17]. A mailbox is a mobile object and could be detached from its owner, but it is not an agent-like object in the sense that it cannot make any decisions. Forward pointers [14], [18], which does not depend on a “where_is_agent ( A) ” lookup function. Instead, each host keeps a reference for each moving agent. A virtual object keeps track of the remote object by its last known address. If the remote object moves from its last location, it leaves a secretary object behind to forward messages to its new location. The secretary object is
4 Motivation In most of the schemes described above, even though the location directory is distributed across several BHs, the responsibility of location tracking is not guaranteed to be shared equally. This is due to the following reasons: 1. The geographical distribution of MAs may change with time. Quite often a significant fraction of MAs are concentrated in a very small area, while there is a very low density of MAs in the rest of the network. For example, most of the MAs may be situated on the border area in night and other major security required area viz., atomic centers, army head quarters of a city during the morning and evening rush hour traffic, and most of the MAs may be concentrated in the business centers of the city during rest of the day. In such situations, the directory servers [7] and central servers [9,15] in the high density regions will be overburdened, while the directory servers and central servers in other regions will be comparatively lightly loaded. 2. Location of some MAs will be queried more often than others. So, even when the MAs are evenly distributed across the network, the LSs (directory servers in [7] and central servers in [9, 15]) for these MAs will be queried more often, increasing their load. If
4
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
the identity of such MAs were known a priori, appropriate actions could be taken to distribute the load. However, such is not the case. An MA that is hot (location queried frequently) may go cold (location queried infrequently), and vice versa.
which maps a BH to a set of BHs. Then, we can define a function g : MA → S BH to be
(
)
equivalent to g '' g ' (MA) . Given an MA, function g determines the LSs of the MA based on the region in which the MA is present. So, the LSs of an MA change as the MA’s location changes. However, determining the LSs of an MA based solely on the region in which that MA is present will lead to uneven distribution of responsibility. For example, when there is a high concentration of MAs in a region, all these MAs will be mapped to the same LSs which will be overburdened. Hence, it is desirable that the LSs storing the location information of an MA be a function of the identities of the MA as well as the region in which that MA is present. Such a function can be represented as follows: h : BHxMA → S BH . The LSs corresponding to an MA will change as the MA moves in the network. Also, MAs in the same region need not have the same set of LSs. Agents/BHs that wish to locate an MA should be able to access at least some of the LSs of the MA quickly, and in an inexpensive fashion. Broadcasting a query to the entire network is an expensive solution. Function h , described above, can also be employed to determine the set of LSs that should be queried when an MA is to be located. The set h(BH , MA) can represent the set of BHs that a node, in the region represented by BH, should query when it wishes to locate an agent. Thus, function h determines the write set for location updates when an MA moves, and the read set for querying the location of the MA. A naive implementation of the function h would be to have a lookup table with an entry for each (MA, BH ) pair. Each entry would store the
Hence, there is a need for a distributed location directory management scheme that can adapt to changes in geographical distribution of MA population in the network, and to changes in MA location query rate.
5 System Design for Locating MAs The problem at hand is as follows: given an MA, determine the LS(s) that will store the location of the MA. Storing the location information of an MA at only one BH is not desirable due to the following reasons: 1. MAs exhibit a spatial locality of reference: even though all agent hosting hosts in the system can potentially communicate with the network, bulk of the references originate from only a subset of them [29]. The agent hosting hosts in the working set may be clustered in different parts of the network. So, to reduce query costs, it is advisable to have LSs for the MA in the vicinity of such clusters. 2. Multiple LSs for an MA make the distributed directory tolerant to the failure of some of these servers. So, let there be a function F : MA → S BH , which gives the identity of an MA, determines the set of BHs that are the LSs for that MA. However, using only the MA’s identity to determine its LSs fails to exploit the locality of reference characteristics of mobile networks. Regardless of where the MA is located in the network, its location information will always be stored at the same hosts. Usually, an MA is more likely to be in communication with agents in its vicinity, than with agents at a greater distance. As a result the working set of an MA can change with its location. Therefore, associating a static set of LSs with each MA is not advisable. The above problem can be solved as follows: let there be functions (i) g : MA → BH , which maps an MA to the BH
corresponding S BH . The size of such a table will be large as there are a large number of MAs in an agent based mobile computing system. Even if the location directory were to be distributed across all BHs, each BH would have to store its share of the lookup table, having as many entries as the number of MAs in the system. In order to avoid the storage overheads incurred by such a table, there is a need for function h to be computationally inexpensive, mapping (MA, BH ) pairs to S BH . It will be desirable if the mapping is distributed over the
of its current region, and (ii) g : BH → S BH ,
5
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
range of BHs, for fairness. MAs that are hot will have their locations queried more frequently than other MAs. Agents/BHs querying the locations of hot MAs may be spread all over the network. Therefore, a greater number of LSs, spread throughout the network, should maintain location information about hot MAs. Fewer LSs need to maintain location information about cold MAs. For this purpose, alias (es), referred to as virtual MA identity, are assigned to each MA. A hot MA is assigned multiple virtual identities, while a cold MA is assigned a single virtual identity, i.e., the location management scheme considers a hot MA to be equivalent to multiple cold MAs. Determination of LSs for an MA involves three steps:
2. Given a BH _ id , denoting the region in which the MA is present, and a VMA _ id for that MA, we employ the principle of open addressing hash function, specifically the double hashing [12], as follows: h (BH _ id , VMA _ id ) =
1. Mapping the MA identity (MA _ id ) to a
spread over the range [0, m - 1], i.e., mapped uniformly over all the BHs in the network [12]. 3. Corresponding to each i = (BH_ id,VMA_ id) , there is a set S i of BHs with the following properties: (a) U mi=−01 S i = S , where S is the set of all BHs. (b) S i ⊄ S j , for 0 ≤ i , j ≤ m − 1 , i ≠ j .
⎛ h1 (BH _ id ) + ⎞ ⎜⎜ ⎟⎟ mod m ⎝ VMA _ idxh 2 (BH _ id )⎠ where m is the number of BHs in the network, and h1 and h2 are auxiliary hash
functions. Functions h1 and h2 are uniformly distributed over the range [0, m 1], and h2 (BH _ id ) is relatively prime to
m . Given a (BH _ id , VMA _ id ) pair, h(BH _ id , VMA _ id ) will be uniformly
virtual MA identity (VMA _ id ) : Let each MA _ id correspond to a non-negative integer. Non-negative integers are also used to represent VMA _ id . Let there be an integer constant x which is a parameter of the algorithm, and is determined a priori. If an MA is cold, its VMA _ id = MA _ id + x . If an MA is hot, then it is assigned multiple virtual identities. Solely for the purpose of explanation, we assumed that each hot MA is assigned at most two virtual identities: VMA _ id 1 = MA _ id + x , and
(c) S i I S j ≠ φ , for 0 ≤ i , j ≤ m − 1 . (d) S1 = ... S m −1 = K . (e) Any BH j , 0 ≤ j ≤ m − 1 , is contained in K , S i ’s, 0 ≤ i ≤ m − 1 .
VMA _ id 2 = an integer between 0 and x 1 (inclusive) that has not already been assigned as a virtual identity to some other hot MA. When a hot MA turns cold, it relinquishes its second virtual identity which is returned to the pool of available virtual identities, and can be assigned to hot MAs in the future. It is to be noted that the first virtual identity of each MA is assumed to be unique. Thus, the location management scheme can efficiently handle up to x hot MAs: each being assigned its second virtual identity from the range [0, x - 1] of integers. If there are more than x hot MAs, then the surplus hot MAs can be assigned only one virtual identity each, and are treated no different from cold MAs.
Properties (d) and (e) represent the equal effort and equal responsibility properties, respectively. Together they represent the symmetry property. So, if an MA with virtual identity VMA _ id , in the region corresponding to BH _ id , updates its location information, the update is done at all BH i ∈ S j : j = h(BH _ id ,VMA _ id ) . The set
Sj
of
BHs
is
the
(BH _ id ,VMA _ id )
write
set
for
the
pair. The value of j is
evenly distributed over the range [0, m − 1] . Hence, the responsibility for location tracking of all the virtual MAs (there are as many virtual MAs as the number of virtual identities assigned) is evenly distributed among the BHs.
6
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
assigned [0..x − 1] : Array of booleans. This is a global variable. The element assigned [i ] is set to TRUE if integer i has been assigned as a virtual identity, VMA _ id , to an MA that is hot.
The set S i of BHs is also referred to as a quorum. When a BH with identity BH _ id , or an MA inside the region corresponding to this BH wishes to locate an MA whose identity is MA _ id , following actions are taken by the BH:
Otherwise, it is FALSE. Each element of the array is initialized to FALSE.
location[MA _ id ] : Each BH maintains a cache
1. Determine all virtual identities, VMA _ id , for the MA with identity MA _ id . 2. query _ set ← φ . 3. (a) for all VMA _ id , compute
in which it stores its knowledge of the locations of some MAs queried by the BH recently. If there is a location entry for MA _ id in the cache, the BH first tries to find the target MA in the corresponding region. Otherwise, it queries the distributed location directory server, as described below. It is to be noted that the cache entries may be out-dated as the MA may have moved to another region.
j ← h(BH _ id , VMA _ id ) ; query _ set ← query _ set ∪ S j . OR
VMA _ id for the MA; compute j ← h(BH _ id , VMA _ id ) ; query _ set ← S j .
(b) select one
VMA _ id (MA _ id ) :
The set of virtual identities associated with an MA whose identity is MA _ id . This set is maintained, on behalf of the MA, by the BH of the region in which the MA is resident. When the MA moves from one region to another, the set is migrated from the BH of the old region to the BH of the new region.
4. Send query to all BH i ∈ query _ set to locate MA with identity MA _ id . The query set is similar to the read set, described earlier for the (BH _ id , VMA _ id ) pair. 5. If
a
queried
BH i contains location information about MA _ id , it sends this
Next we present pseudo-code for components of the location management scheme and that will be followed by detailed description of it.
information in its response. The significance of two different options in constructing the query set (using all VMA _ id ’s vs. only one VMA _ id ) will be discussed in Section 8. As S i ∩ S j ≠ φ for 0 ≤ i ; j ≤ m − 1 , the read
assign _ virtual _ ids (MA _ id )
{ int i; Boolean found;
VMA _ id (MA _ id ) ← {MA _ id + x} ; i ← 0;
and the write sets for every pair of tuples (BH 1 , MA _ id ) (BH 2 , MA _ id ) , and respectively, are bound to intersect. Therefore, if the latest updated location of an MA is stored at a set of BHs, S i then regardless of which region originates a location query for the MA, at least one BH belonging to S i will be probed (property (c)). So, all queries are guaranteed to return the latest location information of the MAs.
found ← false; while( i < x and not(found)) {
if (assigned [i ] = FALSE ) {
assigned [i ] = TRUE ; VMA _ id (MA _ id ) ←
VMA _ id (MA _ id ) ∪ {} i; found ← TRUE ;
6 Search Algorithm The data structures required by the location management algorithm are:
}
i ← i + 1;
}
7
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
send (BH i , QUERY , MA _ id ) ; wait(response from BH i );
}
transition _ hot _ to _ cold (MA _ id , BH )
{
if (response = YES) return(response.location); else delete (location (MA _ id )) from local cache; } i ← any virtual identity of MA _ id ;
int i, j, k; for all i ∈ VMA _ id (MA _ id ) do if (i ≠ MA _ id + x ) do { j ← h(BH , i ) ;
j ← h(BH , i ) ; for all k ∈ S j do
for all k ∈ S j do
send (BH k , delete, MA _ id , BH ) ; assigned [i ] ← FALSE ;
send (BH k , QUERY , MA _ id ) ; wait(positive response from any BH k ); location (MA _ id ) ← response.location ;
} }
transition _ cold _ to _ hot (MA _ id , BH )
if no positive response
send (broadcast , QUERY , MA _ id ) ;
{
}
int i, j, k;
assign _ virtual _ ids (MA _ id ); for all i ∈ VMA _ id (MA _ id ) do if (i ≠ MA _ id + x ) do {
Different states of algorithm are as under:
j ← h(BH , i ) ; for all k ∈ S j do
send (BH k , add , MA _ id , BH );
} }
location _ update(MA _ id , old _ BH , new _ BH )
{ int i, j, vma; for all vma ∈ VMA _ id (MA _ id ) do { i ← h(old _ BH , vma ) ;
State Transitions: When an MA makes a transition from a hot state to a cold state, the procedure transition hot to cold is invoked. Values of the hash function are computed with respect to the BH in which the MA is present, and each of the virtual identities of the MA, except for the native virtual identity of the MA: MA _ id + x . The result of each such
for all j ∈ S i do
send(BH j , delete, MA _ id , old _ BH ) ;
i ← h(new _ BH , vma ) ; for all j ∈ S i do
computation (an integer j ) indicates a set S j of
send (BH j , add , MA _ id , new _ BH ) ;
BHs that store the location information about the MA. All these BHs are requested to delete their information about the location of the MA. Only one set of BHs, corresponding to the pair (BH , MA _ id + x ) , maintains location information about the MA. The number of BHs that maintain location information about a cold MA is less than the number of BHs that maintain the corresponding information about a
} }
locate _ MA(MA _ id , BH ) { int i, j, k; if i = location(MA _ id ) ∈ local cache
(
Virtual Identity Determination: The procedure assign_virtual_ids() takes the identity of a hot MA as the input, and assigns at most two virtual identities to that MA. These virtual identities are stored in the set VMA _ id (MA _ id ) . If x is hot MA have already been assigned two virtual identities each, then any other MA that now becomes hot will be assigned only one virtual identity, which is equal to MA _ id + x : its native virtual identity.
)
{
8
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
hot MA. The converse is true when an MA makes a transition from a cold to a hot state. The procedure transition_cold_to_hot() is invoked. Multiples sets of BHs (at most two sets in the algorithm stated above) are requested to store location information about the hot MA. The reason for having a greater number of BHs store location information about a hot MA is as follows: the location of a hot MA is likely to be queried by a larger number of agents (both MA and static agent), and also more often, than the location of a cold MA. Also, these querying agents are likely to be located in different parts of the network. By having more BHs store the location information, the chances of a querying agent finding the required information at a nearby BH are higher. So, the response time of location queries is lower. Hence, the cost of locating a hot MA is expected to be less than the cost of locating a cold MA. Location Update: When an MA moves from one region to another, its location has to be updated at the appropriate BHs that act as the distributed LSs. The choice of the update strategy (time-based, number of movementsbased, or distance-based) is orthogonal to the location update procedure. The parameter old _ BH denotes the BH of the region in which the MA was resident when the last location update was done. The current region's BH is called the new _ BH . Out-dated location information is deleted from all the BHs that were the LSs with respect to the (old _ BH , MA _ id ) pair. New location information is stored at the BHs that are determined to be the LSs, by the hash function, with respect to the (new _ BH , MA _ id ) pair. These BHs correspond to the write set for location information. The state of the MA (hot or cold) is implicitly accounted for, in the location update procedure, as the hash function is computed for each element in the virtual identity set ( VMA _ id ) of the MA. Location Query: An MA in the region corresponding to BH, wishing to communicate with a target MA, first needs to know the location of the target BH. Let the target MA’s identity be MA _ id . To locate the target, the function locate_MA() is invoked. First, BH searches its cache for MA _ id ’s entry. If such
same region. If so, BH i returns its own location in the response. Otherwise, one of the virtual identities of MA _ id is arbitrarily selected. This virtual identity is used by the hash function to determine the set of BHs that should be queried about MA _ id ’s location (the read set for location information). If a queried BH, BH i , has the location of MA _ id in its directory, it is sent in the response. If no queried BH has the location of MA _ id , the query is broadcast over the network [28]. Once BH receives the location of the region in which MA _ id is present, the message is sent over the fixed wire network to the corresponding BH. If MA _ id has moved out of the region since the last location update, a sequence of forwarding pointers (depending on the path taken by MA _ id since it moved out of BH i ’s region) is
an entry is found, the corresponding BH, BH i ,
pairs, respectively. However, the only BH parameter in the
followed to the region in which MA _ id is currently present. Selection of Arbitrary Virtual Identity: As mentioned above, in the procedure locate_MA(), one of the virtual identities of the target MA is arbitrarily selected. Such a selection does not require each BH to store the virtual identities of all MAs. That would impose prohibitive storage overheads. In the simplest implementation, the virtual identity selected is the native virtual identity of the MA, i.e., MA _ id + x . Alternatively, the global array assigned [0..x − 1] could be an array of 2-tuples of the form (boolean, MA _ id ) . When a hot MA with identity MA _ id is assigned a virtual
identity i (0 ≤ i < x ) , assigned [i ] is set to (TRUE, MA _ id ). Therefore, to find all the possible virtual identities of an MA, and then arbitrarily select one, the BH only has to scan through the assigned array of x tuples. This array can be stored at a central site, or replicated at several sites for fault-tolerance. Simultaneous State Transition and Migration: Out-dated location information may be left at some BHs if location update and state transition have to be done at the same time. On state transitions, the add and delete messages should be sent to BHs determined with respect to the (new _ BH , MA _ id ) and
(old _ BH , MA _ id )
is probed to determine if MA _ id is still in the
9
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
transition procedures is the new _ BH . So, during transitions from a hot to a cold state, that happen concurrently with location changes, delete messages may be sent to some BHs that did not store the MA’s location, while some BHs that did store old location information about the MA may not receive such a message. To avoid such situations, first the location update should be done, followed by the execution of the state transition procedure. By doing this, it is ensured that out-dated location information is deleted from all the BHs before any new location information is stored.
grid points on the column passing through point i . Thus, the cardinality of each quorum S i is equal to 2 m − 1 . If m is not a square of an integer, a degenerate grid can be constructed with the outermost row/column being reduced in size. In such a case, while constructing S i , the partial row/column is complemented using grid points from another row/column. Therefore, the
( )
size of each read and write set is O m , where m is the number of BH in the network.
8 Handling Hot Mobile Agents As described earlier, MAs whose location is queried often have at least one, and often two write sets associated with them. So, the average distance between a MA querying the location of the hot MA and a BH containing the MA’s location is less than the situation if the location information was stored at BHs belonging to only one set. A querying MA probes BHs belonging to only one of its two possible read sets for the hot MA. There are two possible cases:
7 Read and Write Set Construction The performance of the location management and tracking scheme depends on the construction of the read and write sets (quorums), referred to as S i , S j , etc. as discussed earlier. Let the total number of BHs in the network be m . In order to minimize the communication overhead of the algorithm, it is necessary that the size of each quorum S i be kept as small as possible. Also, to distribute the responsibility of storing the distributed location directory in a fair manner among the BHs, the quorums should be symmetric. One approach to constructing such quorums is proposed in [27], and is described below:
1. Let a BH belong to both the read sets corresponding to a (querying MA, hot MA) pair. In that case, to the BH the hot BH appears to be equivalent to two cold virtual MAs (on account of the two virtual identities of the hot MA). By the symmetry property of read and write set construction, and the fact that the hashing function is uniformly distributed over all the BHs, it is implied that this BH stores location information of fewer MAs than a BH that stores location information only for cold MAs. 2. Let a BH belong to only one of the two read sets. In that case, as query messages are sent to only one arbitrarily selected read set, this BH will, on an average, receive only half the location queries for the hot MA.
Iterative approach: Initially, the quorums are trivially constructed, each containing just over m/2 BHs whose identities form a contiguous sequence. An iterative reduction of the quorum size is done. In each iteration, the quorum (sequence of BHs) is partitioned into three partitions of roughly the same size, and the middle partition is discarded. The other two partitions are further reduced in the next iteration. A set of BHs is not partitioned any further if its size plus one is not divisible by three, or its size is less than seven. This leads to the generation of symmetric quorums of size 0.97m 0.63 . Another approach to constructing quorums, similar to that proposed in [13] in the context of the mutual exclusion problem, is as follows:
Thus, a BH storing location information about a hot MA either stores location information about fewer MAs, and/or receives only half the queries corresponding to the hot MA. Hence, open addressing double hashing along with virtual MA identities ensures that:
Grid based scheme: Let m = l 2 for an integer l . Then an l * l grid is constructed. The grid points are numbered from 0 to m-1. The quorum S i consists of the grid points on the row and the
•
10
location information about MAs is fairly distributed among all the BHs constituting the distributed location directory,
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
•
an extreme of 8*108 Internet users (NUA estimates there were more than 605.60 million users online in the Internet on September 2002, [http://www.nua.com/surveys/how_many_onlin e]) each running 100 MAs simultaneously, about 20,000 BHs would be required to keep all entries. This is less than 0.0057% of the hosts in the Internet, according to ISC estimates (ISC estimates there were more than 350,000,000 hosts in the Internet in January 2005, [http://www.isc.org/ds]) at the time of writing. In the state transition procedures, add or delete messages are sent to at most one quorum of BHs. In the location update procedure, add and delete messages are sent to at most two quorums of BHs, each. When the location of an MA is to be determined, query messages are sent to only one quorum of BHs. Hence, the message complexity of each directory operation
irrespective of the geographical distribution of the MAs. the number of location queries received by each participating BH is fairly distributed regardless of whether it stores location information about only hot MAs, or only cold MAs, or a combination of both.
The performance can be further optimized if the hot MAs were not restricted to having only two virtual identities. Instead, the number of virtual identities of an MA could vary from 1 to n , for an integer n . The more frequently an MA is queried, the greater the number of virtual identities assigned to it. The determination of whether a MA is hot or cold is done by the BH of the region in which the MA is present. If at time t , the number of queries per unit time received by the BH on behalf of the MA, from agents outside the region, averaged over the interval [t − T , t ] , exceeds a predetermined threshold, the MA is hot. Otherwise, it is cold. T is a pre-selected constant. A small value of T makes the state transitions very sensitive to fluctuations in query rates. A large value of T , on the other hand, reduces the sensitivity, but also avoids state changes due to short lived aberrations in query patterns.
is O
(
Each message has a small size, consisting of at most two BH identities, one MA identity, and a flag indicating the nature of the message. Moreover, these messages are transmitted in the fixed wire network, which has a much higher bandwidth than the wireless MA-BH links. Assuming that x is a constant value and the number of MAs in the network is M , each BH has to store location information about
(
)
O M / m MAs for the grid based approach.
The location management and tracking algorithm imposes low computation and communication overheads. In order to assign virtual identities to a hot MA, the assigned array of x elements has to be traversed at most once. Hence, the computation complexity of this operation is O( x ) .
This is because the location information of each
( )
of the M MAs is replicated O m times in the directory, and the entire directory is distributed uniformly over m BHs acting as
(
)
LSs. Each of these O M / m pieces of information contains the BH _ id for the region in which the MA is present, which requires lg(m ) bits. Besides this directory information,
The auxiliary hash functions h1 and h2 usually employ a small, constant number of integer multiplication and division operations. Hence, determination of sets of BHs quorums to which location add or delete messages should be sent is computationally inexpensive. There are
(
)
O m 0.63 if the iterative approach is employed.
9 Overheads Analysis
( )
( m ) if the grid based scheme is used, and
(
)
each BH has to store an extra O m m entries,
each of size lg(m ) bits, indicating memberships of all the read and write sets: there are at most m read and write sets, each with a cardinality
)
O m or O m 0.63 elements in each quorum depending on the quorum construction strategy employed, where m is the total number of BHs in the network. Typically, m , the number of BHs, is a very small fraction of the total number of hosts in the global network. BH was able to hold up to 4*106 entries before the system ran out of memory {Fig. 1}. This means that, given
of O
( m ).
10 Conclusion As mobile agent technology mature, the number of MAs in the global network is bound to increase at a rapid pace. In order to keep track of these MAs, and to be able to interact with them,
11
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
[5]
it is important to store and update their location information efficiently. In this paper, we presented a distributed dynamic location management and tracking Scheme for MA. Location information about
( )
MAs is replicated at O m BHs, where m is the total number of BHs in the system. So, not all BHs need to store the location of every MA. MAs that are queried more often than others have their location information stored at a greater number of BHs. The set of BHs that store an MA’s location change dynamically as the agent moves from one part of the network to another. Also, BHs that store location information of frequently queried MAs store information about fewer agents than the BHs that only store location information of infrequently queried MAs. As a result, the location directory is fairly distributed over the global network, and no single BH is overburdened with the responsibility of responding to location queries. The distributed location management scheme imposes low computation, communication, and storage overheads. Moreover, MAs and the wireless links do not incur any of these overheads, which is a desirable feature as they are usually resource poor. The overheads are visible to the BHs and the fixed wireline network, which are comparatively resource rich.
[6]
[7]
[8]
[9]
References [1] G. P. Picco, Mobile Agents: An Introduction, Microprocessors and Microsystems, 25(2): 65-74, April 2001. [2] R. B. Patel, Design and Implementation of a Secure Mobile Agent Platform for Distributed Computing, PhD thesis, Department of Electronics and Computer Engineering, IIT Roorkee, India, 2004. [3] W. S. E. Chen, C.W.R. Leng, A Novel Mobile Agent Algorithm, in Proceedings of the first International workshop on Mobile Agents (MA97), K. Tothermel, R. Popecu-Celetin (eds.), LNCS 1219, Springer Verlag, Berlin, Germany, April 7-8, 1997, pp. 162-173. [4] R. J. Flower, The complexity of using forwarding address for decentralized object find, Proceedings of the fifth annual ACM symposium on Principles of distributed computing, Calgary, Alberta, Canada Aug. 11 - 13, 1986, pp. 108-120.
[10]
[11]
[12]
[13]
[14]
12
V. Roth and J. Peters, A Scalable and Secure Global Tracking Service for Mobile Agents, in Proceedings of the 5th International Conference on Mobile Agents (MA2001), Atlanta, Georgia, USA, G. Picco (Ed.), LNCS 2240, pp. 169-181, Springer Verlag, 2001. Sashi Lazar , Ishan P. Weerakoon, Deepinder P. Sidhu, A Scalable Location Tracking and Message Delivery Scheme for Mobile Agents, in Proceedings of the 7th Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE '98), Palo Alto, CAUSA, June 17-19, 1998, pp. 243-249, IEEE Computer Society. A. Di Stefano and C. Santoro, Locating Mobile Agents in a Wide Distributed Environment, IEEE Transaction on Parallel & Distributed Systems, 13(8): 844-864, Aug. 2002. A. Bar-Noy, I. Kessler, and M. Sidi. Mobile Users: To Update or not to Update? In Proceedings of The Conference on Computer Communications, Thirteenth Annual Joint Conference of the IEEE Computer and Communications Societies, Networking for Global Communications, June 12-16, 1994, Toronto, Ontario, Canada. IEEE, 1994, pp. 570-576. E. Pitoura and George Samaras, Locating objects in Mobile Computing, IEEE Transaction on Knowledge and Data Engineering, 13(4): 571–592, 2001. Andrew S. Tanenbaum and Maarten van Steen, Distributed Systems, Principles and Paradigms, Prentice-Hall, Upper Saddle River, New Jersey, first edition, 2002. Maarten van Steen, Franz J. Hauck, Philip Homburg and Andrew S. Tanenbaum, Locating Objects in Wide-Area Systems, IEEE Communications, 36(1): 104-109, Jan. 1998. T. H. Cormen, C. E. Leiserson, and R. L. Rivest. Introduction to Algorithms. MIT Press McGraw-Hill Book Company, 1990. M. Maekawa. A N Algorithm for Mutual Exclusion in Decentralized Systems. ACM Transactions on Computer Systems, pp.145-159, May 1985. S. Mishra, and Y. Huang, “Fault Tolerance in Agent-Based Computing Systems,” in Proceedings of the 13th
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
[15]
[16] [17]
[18]
[19]
[20]
[21]
[22]
[23] [24]
[25]
[26] H. Peine, Application and programming experience with the Ara mobile agent system, Software: Practice and Experience, 32(6): 515–541, May 2002. [27] W. K. Ng and C. V. Ravishankar, Coterie Templates: A New Quorum Construction Method, in Proceedings of the 15th International Conference on Distributed Computing Systems, Washington, DC, USA, 30 May-2 Jun 1995 pp. 92-99. [28] R. B. Patel, Nikos Mastorakis and K. Garg, Communication Model for Mobile Agent Systems, appear in WSEAS TRANSACTIONS on COMPUTERS Issue X, Volume X, 2005. [29] S. Rajagopalan and B. R. Badrinath, An Adaptive Location Management Strategy for Mobile IP, in Proceedings of the 1st annual international conference on Mobile computing and networking (MobiCom 95), Berkeley, California, United States, Nov. 1995, pp. 170 - 180. [30] N. Suri, J. M. Bradshaw, M. R. Breedy, P. T. Groth, G. A. Hill, R. Jeffers, T. S. Mitrovich, B. R. Pouliot, and D. S. Smith, Nomads: Toward a strong and safe mobile agent system, in Proceedings of the Fourth International Conference on Autonomous Agents, pp. 163–164, 2000. [31] R. S. Gray, G. Cybenko, D. Kotz, R. A. Peterson, and D. Rus, D’Agents: Applications and performance of a mobile-agent system, Software: Practice and Experience, 32(6): 543–573, May 2002. [32] K. A. Iskra, F. van der Linden, Z. W. Hendrikse, B. J. Overeinder, G. D. van Albada, and P. M. A. Sloot, The implementation of Dynamite: An environment for migrating PVM tasks, Operating Systems Review, 34(3): 40–55, July 2000. [33] R. B. Patel and K. Garg, “A New Paradigm for Mobile Agent Computing,” WSEAS Transaction on Computers, Issue 1, Vol. 3, Jan. 2004, pp. 57-64. [34] R. B. Patel and K. Garg, “PMADE – A Platform for Mobile Agent Distribution & Execution,” in Proceedings of 5th World MultiConference on Systemics, Cybernetics and Informatics (SCI2001) and 7th International Conference on Information System Analysis and Synthesis (ISAS 2001), Orlando, Florida,
ISCA International Conference on Parallel and Distributed Computing Systems, Las Vegas, NV, Aug. 2000. Gihwan Cho and Lindsay F. Marshal, “ An Efficient Location an Routing Scheme for Mobile Computing Environments,” IEEE Journal on Selected Areas in Communications 13(5): 868-879, June 1995. J. Cao et al, Mailbox-based scheme for mobile agent communications, IEEE Computer, 35(9): 54–60, 2002. John Vittal, Active Message Processing: Messages as Messengers, in R.P. Uhlig, (ed), Computer Message System, pp. 175195, North-Holland, 1981. D. Schmidt, M. Kircher and I. Pyarali, Location Forwarding, Available at http://www.cs.wustl.edu/~schmidt/ACE wrappers/TAO/docs/forwarding.html, 1998. Bellavista, P., Corradi, A., and Stefanelli, C., Mobile Agent Middleware for Mobile Computing, IEEE Computer, pp. 73-81, March 2001. Horvat, D., Cvetković D., Milutinović, D., Koćović, P., and Kovaćević, V., Mobile Agents and Java Mobile Agent Toolkits, in Proceedings of the 33rd Hawaii International Conference on System Sciences (HICSS 2000), Maui, Hawaii, USA, Jan. 4-7, 2000, pp. 3090-3099. E. Kovacs, K. Roehrle, and M. Reich, Integrating Mobile Agents into the Mobile Middleware, in K. Rothermel and F. Hohl (eds), Proceedings of the Second International Workshop on Mobile Agents (MA’98), Berlin, LNCS 1477, pp. 124135, Springer Verlag, Sept. 1998. S. Lipperts, and A. Park, An Agent Based Middleware: A Solution for Terminal and User Mobility,” Computer Networks, Sept. 1999, pp. 2053-2062. Milojicic, D., Trend Wars Mobile Agent Applications, IEEE Concurrency, 7(3): 80 -90, 1999. M. Ranganathan, A. Acharya, S. Sharma and Saltz J, Network-aware Mobile Programs, in Proceedings of the USENIX 1997 Annual Technical Conference, January 6-10, 1997, Anaheim Marriott Hotel, Anaheim, California, pp. 91-103. G. P. Picco, Mobile agents: An introduction, Microprocessors and Microsystems, 25(2): 65–74, Apr. 2001.
13
7th WSEAS Int. Conf. on MATHEMATICAL METHODS and COMPUTATIONAL TECHNIQUES IN ELECTRICAL ENGINEERING, Sofia, 27-29/10/05 (pp96-109)
USA, July 22-25, 2001, Vol. IV, pp. 287292. [35] A. Tripathi, N. Karnik, M. Vora, T. Ahmed, and R. Singh, Mobile agent programming in Ajanta, in Proceedings of the 19th International Conference on Distributed Computing Systems (ICDCS’99), Austin, TX, May 1999, pp. 190–197. [36] D. B. Lange, M. Oshima, G. Karjoth, and K. Kosaka, Aglets: Programming mobile agents in Java, in Worldwide Computing and Its Applications, LNCS 1274, pp. 253–266, Springer-Verlag, Berlin, Germany, 1997.
14
