A Progressive Fault Tolerant Mechanism in Mobile Agent Systems

Transcription

1 A Progressve Fault Tolerant Mechansm n Moble Agent Systems Mchael R. LYU and Tsz Yeung WONG Computer Scence & Engneerng Department The Chnese Unversty of Hong Kong Shatn, Hong Kong flyu,tywongg@cse.cuhk.edu.hk Abstract We present the approach of deployng cooperatng agents to detect falures as well as recover servces n a moble agent system. In addtonal to server falure detecton, we use cooperatng agents to handle agent falure detecton. Two types of agents are nvolved. One s the agent performng the computaton delegated by the owner, whch we call the actual agent. Another s the agent that montors the actual agent, namely the wtness agent. We ntroduce a protocol by usng a message passng mechansm between these two knds of agents to detect agent falures and recover agent servces. Ths approach can handle server falures, agent falures, and falures n message passng. It s capable of detectng and recoverng most falure scenaros n moble agent systems. We descrbe the desgn of our wtness agent approach to moble agent systems, and conduct relablty evaluaton for our approach. The evaluaton results show our approach s a promsng technque n achevng moble agent system relablty. Keywords: Software Agents, Fault Tolerance, Recovery, Modelng, Measurement. INTRODUCTION Moble agents are autonomous objects capable of mgratng from one server to another server n a computer network []. When an agent travels to another server, the agent s code, data as well as executon state are captured and transferred to the next server. It s re-nstantated after arrval at the next server. The ablty to roam the net s provded by a mddle-ware platform, a moble agent executon envronment (e.g. Aglets [2], Concorda [3] and Mole [4]). Relablty as well as fault-tolerance are vtal ssues for the deployment of a moble agent system. A number of research work s done n these areas. Some researchers adopt the use of replcaton as well as maskng [5, 6]. The dea s to use replcated servers to mask the falures. When one server s down, we can stll use the results from other servers n order to contnue the computaton. The advantage of ths approach s that the computaton wll not be blocked when a falure happens. However, ths fault-tolerance scheme s expensve snce we have to mantan multple physcal servers for just one logcal server. Snce a falure s a rare event, t s not cost-effectve to mantan multple servers. Moreover, every replcated server has ts own data, and the data n all the replcated servers must be consstent among themselves. On the other hand, the computaton on dfferent servers may not produce the same and correct result. Thus, t s a tough task n preservng server consstency, especally when the servers are wdely separated, snce the latency of the network wll affect the speed of consstency checkng as well as preservaton. Alternatvely, our approach focuses on the agent falure detecton and recovery. Our approach s rooted from the approach suggested n [7]. We dstngush two types of agents. One type s performng the requred computaton for the user. We name t the actual agent. Another type s to detect and recover the actual agent. We call t the wtness agent. These two types of agents communcate by usng a peer-to-peer messages passng mechansm. In addton to the ntroducton of the wtness agent and the messages passng mechansm, we also need to log the actons performed by the actual agent snce when falures happen, we need to abort uncommtted actons when we perform rollback recovery [8]. We also use checkponted data [9] to recover the lost agent. The key dfference between the protocol suggested n [7] and our protocol s that the former depends on a relable broadcast, whle we allow the network to be unrelable. That s, we can handle the falures n transmsson of messages as well as the lost of the agent n the network, for example n network parttonng. In [7], the protocol uses message broadcastng wth a lot of redundant messages. Our message passng mechansm, on the other hand, s a peerto-peer one, so we can save a lot of redundant messages. Moreover, our protocol handles the falures of the wtness agents.

2 2 SERVER FAILURE DETECTION AND RECOVERY Agent Communcaton Channel Agent The server falure s much easer to be detected and recovered than the agent falure. Nevertheless, server falure detecton as well as recovery are mportant ssues n the desgn of a relable moble agent system. An agent requres a server to be hosted and an envronment to execute. If the hostng server fals, the agent wll be lost as an agent s just a pece of runnng program. On the other hand, the agent has manpulated objects (or data) n the server. These objects n the server wll become nconsstent f the modfcatons done by the agents are not handled properly. We have to tackle ths nconsstency problem. Moreover, f the server to whch the agent mgrates fals, the agent cannot travel to that server. Snce a server hosts an agent and the agent manpulates objects on the server, we have to log every acton of the agent nvolvng the modfcatons of the objects n the server. If a falure happens, all the uncommtted transactons done by the agent should be aborted. Hence, whle the server s restartng, we have to nspect the log on the permanent storage, and undo all the uncommtted changes. Durng the recovery of the server, we cannot recover any lost agents snce t s mpossble for a server to re-nstantate an agent that s foregn to t. If the agent cannot detect whether the target server s avalable or not, we may lose t when sendng t to a faled server. Therefore, we have to mplement the ablty to detect the avalablty of a server for the moble agent. We have mplemented a method smlar to png for ths purpose. Wth ths mplementaton, an agent decdes to wat n the current server f the target server ahead s faled. The agent contnues watng untl the target server becomes avalable. In ths mplementaton, the agent can contnue ts tnerary. However, whle the agent s watng, there s a chance that a falure happens to the server where the agent resdes. In ths case, we requre an agent falure detecton and recovery mechansm. Ths s covered n Secton 3.3 Our mechansm to detect and recover a server falure s to launch a daemon n a machne, whch s not error-prone. Ths daemon s to montor the avalablty of all the servers. We name ths daemon the server montor. The server hostng ths daemon s not a server responsble for recevng and executng any agent; t s an ndependent server whch s not vulnerable to falures. The advantage of ths approach s that t s easy to mplement. However, we may encounter the problem of sngle pont falure. In order to ease ths problem, we can ntroduce more backup worker servers. The worker servers wll montor the prmary server. If the prmary one fals, one of the workers wll replace the prmary one, by launchng the daemon and replacng the prmary server. Messages Checkpont Messages Checkpont Server S Server S + Fgure. The server desgn 3 AGENT FAILURE DETECTION AND RECOVERY 3. System Archtecture In our agent system desgn, n order to detect the falures of an actual agent as well as recover the faled actual agent, we desgnate another type of agents, namely the wtness agent, to montor whether the actual agent s alve or dead. In addton to the wtness agent, we have to desgn a communcaton mechansm between both types of agents. In our desgn, agents are capable of sendng messages to each other. We call ths type of messages the drect messages. The drect message s a peer-to-peer message. Snce a wtness agent always lags behnd the actual agent, the actual agent can assume that the wtness agent s at the server that the actual agent just prevously vsted. Moreover, the actual agent always knows the address of the prevously vsted server. Therefore, the peer-to-peer message passng mechansm can be establshed. There are cases that the actual agent cannot send a drect message to a wtness agent for several reasons, e.g., the wtness agent s on the way to the target server. Then, there should be a malbox at each server that keeps those unattended messages. We call ths type of messages the ndrect messages. These ndrect messages wll be kept n the permanent storage of the target servers. Every server has to log the actons performed by an agent. The loggng actons are nvoked by the agent. The nformaton logged by the agent s vtal for falure detecton as well as recovery. Also, the hostng servers have to log whch objects have been updated. Ths log fle s requred when performng the rollback recovery. Last but not the least, when a server falure happens, we have to recover the lost agent due to the falure. However, an agent has ts nternal data, whch may be lost due to the falure. Moreover, f we allow the agent to start computng from the startng pont of the tnerary, the exactly-once [] property wll be volated. Therefore, we have to checkpont the data of an agent as well as rollback the computaton when necessary [8]. We requre a permanent storage to store the checkponted data n the server. Moreover, we log messages n the log of the server n order to perform rollback of executons. The overall desgn of the server archtecture s shown n Fgure.

3 3.2 Protocol Desgn (2) Our protocol s based on message passng as well as message loggng to acheve falure detecton. Assume that, currently, the actual agent s at server S whle the wtness agent s at server S ;. Both the actual agent and the wtness agent have just d at S and S ;, respectvely. We label the actual agent as, and the wtness agent as! ;. We dscuss the behavor of the actual agent frst. The actual agent plays an actve role n ths protocol. After has d at S, t mmedately logs a message, log,on the permanent storage n S. The purpose of ths message s to let the comng wtness agent know that has successfully landed on ths server. Next, nforms! ; that t has d at S safely by sendng a message, msg,to! ;. performs the computatons delegated by the owner on S. When t fnshes, t mmedately checkponts ts nternal data to the permanent storage of S. Then, t logs a message log n S. The purpose of ths message to let the comng wtness agent know that has completed ts computaton, and t s ready to travel to the next server S +. In the next step, sends! ; a message, msg, n order to nform! ; that s ready to S. At last, s S and travels to S +. On the other hand, the wtness agent s more passve than the actual agent n ths protocol. It wll not send any messages to the actual agent. Instead, t only lstens to the messages comng from the actual agent. We assume that the wtness agent,! ;, s at S ;. Before! ; can advance further n the network, t wats for the messages sent from. When! ; s n S ;, t expects recevng two messages: one s msg and another one s. msg If the messages are out-of-order, msg wll be kept n the permanent storage of S ;. That s, msg s consdered as unattended, and becomes an ndrect message un- tl! ; receves msg. When! ; has receved both msg and,tspawns anewwtness agent msg called!. The reason of spawnng a new agent nstead of lettng! ; mgrate to S s that orgnally! ; s wtnessng the avalablty of. If a server falure happens just before! ; mgrates to S, then no one can guarantee the avalablty of the actual agent. More detals about ths problem wll be dscussed n Secton 3.3. Note that the new wtness agent knows where to go,.e. S, because msg or contans nformaton about the locaton of S where has just vsted. msg Fgure 2 shows the flow of the protocol. The actual agent s at S and the wtness agent! ; also s at S ;. Frst, logs the message log n S [Step ()]. Then, sends the message msg to! ; [Step (2)]. then performs the computaton. After has fnshed all the tasks, t checkponts ts data n S [Step (3)]. We assume that the checkpontng acton s one of the computatons of the actual agent. That s, f the checkpontng acton fals, the actual agent wll abort the whole transacton. Ths s an Checkpont Wtness (5) Checkpont Agent Server S - Server S () log message (2) send message (3) after computaton, checkpont the data. (4) log message (5) send message log msg log msg Fgure 2. Steps n the wtness protocol. mportant step snce ths property guarantees that the checkponted data wll be avalable f the actual agent has already fnshed computng. Also, t s mportant for the recovery of the lost actual agent. Then, logs the message msg n S [Step (4)]. Before s S, t sends the message msg to! ; [Step (5)]. Fnally, s S and travels to S +. Upon recevng msg,! ; spawns!, and! travels to S. The procedure goes on untl reaches the last destnaton n ts tnerary. 3.3 Falure and Recovery Scenaros The purpose of the logs and the messages s to guarantee the actual agent has fnshed up to a certan pont of the executon of the actual agent. If a server falure occurs n between a log and a message, we can determne when and where the actual agent fals. We assume that there wll be no hardware falures such that the log message cannot be recorded n a the permanent storage. However, other knds of falures lke the software faults n the moble agents or n the moble agent platforms can happen. In followng subsectons, we wll cover dfferent knds of falures ncludng the loss of the actual agents, and the loss of the wtness agents. We descrbe several scenaros as follows. 3.3.! ; fals to receve msg The reasons that! ; fals to receve msg can be:. The message s lost due to an unrelable network; 2. The message s after the tmeout perod of! ;; 3. s dead when t s ready to S ;; 4. s dead when t has just d at S wthout loggng; or 5. s dead when t has just d at S wth loggng. For the frst two reasons,.e., the actual agent does not de, and the message logged n S, log, can help solvng ths problem, as log s a proof for the exstence (3) () (4)

4 Wtness () (2) (4) Probe (3) to S n the same network, they suffer from more or less the same network latency. Although there may be many routes from S ; to S, we can set the tmeout of! ; to be large enough to overcome the dfference of speeds among these routes. Checkpont Checkpont Server S - Server S 3.3.2! ; fals to receve msg () wtness agent spawn a probe. The probe travels to S (2) probe s carryng the checkponted data (3) probe nspects the n S (4) f the n S has log then the probe re-transmt t. (5) If not, recover the agent by usng the checkpont data Fgure 3.! ; fals to receve msg of nsde S. The wtness agent can send out a probe, another agent, to search for log n S. If found, can re-transmt msg n order to recover the lost messages. If! ; fals to receve msg because of the loss of the actual agent, we may have the problem of mssng detecton when, n the ffth case, the probe wll wrongly determne that the actual agent s stll alve. Ths cases wll be dscussed n the next subsecton. If the falure s caused by the thrd or the forth cases, the probe wll not be able to fnd log n S. Then, we can use the checkponted data stored n S ; to recover the lost actual agent. Therefore, the probe s requred to carry along the checkponted data when t travels to S. Fgure 3 shows the executon steps of the probe to detect agent falures when the wtness fals to receve log.! ; wats for the message, msg, for a tmeout perod. If the tmeout perod s reached, t creates the probe. then travels to S [Step ()]. Snce t may be requred to recover a lost agent, t travels wth the checkponted data [Step (2)]. Upon arrvng at S,t searches the log fle n S for the message log [Step (3)]. If log s found, t re-transmts msg n order to recover the lost message [Step (4)]. However, mss- ng detecton may happen at ths step. If the log message s not found, wll recover n S by usng the checkponted data [Step (5)]. At last, re-transmts the message msg. Note that we recover the lost actual agent n S nstead of S ; because when detects that a recovery s requred, we can mmedately recover that actual agent n S. If we perform the recovery n S ;, has to send a message to S ; n order to nform! ; that a recovery s requred. There s a rsk of losng such message. In the meanwhle,! ; wats for another tmeout perod. Ths s mportant snce the message that s re-transmtted from S ; may be lost agan. Or, another falure may strke S. Such a falure may termnate both the probe and the just-recovered actual agent. Therefore,! ; should wat untl the message msg s. Note that t s possble that reaches S whle s stll on the way. However, the occurrence probablty of ths case should be low. Snce both and have to travel from S ; The reasons that! ; fals to receve msg can be:. The message s lost due to an unrelable network; 2. The message s after the tmeout perod of! ;; 3. s dead when t has just sent the message msg ; or 4. s dead when t has just logged the message log. As t s mentoned n the prevous subsecton, the ffth case of the prevous subsecton wll be nvestgated here. Ths case wll result n mssng detecton and the probe wll re-transmt the expected message, msg, agan regardless of the avalablty of the actual agent. Thus, we can ex- pect that the wtness agent s not able to receve msg. Therefore, the last case of the prevous subsecton can be categorzed as the thrd case of ths subsecton. If the falure happens because of the frst two reasons, t can be solved by the smlar way as the prevous subsecton.! ; can send a probe, agan, to search for log n the log fle of S. However, we may also have the problem of mssng detecton f the reason of the falures s the fourth or the ffth cases. That s, the actual agent s dead but we have not detected t. These two cases can be covered. When re-transmts msg,! ; assumes that has successfully left S. Therefore,! ; spawns!, and, eventually,! travels to S. However,! wll never receve msg + from snce s already dead and does not exst n S +. Consequently, we can successfully detect the agent falure by the thrd case of the prevous subsecton. For the thrd case, we can handle t by detectng f log exsts. Snce s absent, ths mples that log the actual agent s lost whle t s performng ts computaton. In ths case, snce the actual agent s lost, the partally completed task by the actual agent should be undone. Therefore, t s requred to rollback those operatons by the method proposed n [8] n order to preserve the data consstency n S. We treat the whole computaton process as a sngle transacton. Snce the transacton s not commtted, we have to abort all the uncommtted actons. We can use the log n S to recover the data nsde S. The rollback recovery s not done by the probe,. Instead, t s performed durng the recovery of the server. Therefore, when the probe cannot fnd the log message log, t can mmedately use the checkponted data to recover the actual agent. After the recovery s completed, the recovered actual agent can start performng ts computaton n S. The executon steps of the probe when log s mssng s very smlar to the steps n Fgure 3. Note the recovery

5 () Server S -2 Server S - Server S (3) (4) Wtness (2) Probe Wtness Wtness Agent (3) (4) () (2) Checkpont Checkpont Server S - Server S () Falure strkes server S - () wtness agent spawn a probe. The probe travels to S (2) probe s carryng the checkponted data (3) probe nspects the n S (4) f the n S has log then the probe re-transmt t. (5) If not, recover the agent by usng the checkpont data Fgure 4.! ; fals to receve msg of the actual agent takes place on the server where the actual agent s expected to be hosted,.e., n S. Moreover, when the actual agent s recovered, t mmedately performs the computaton n S regardless of the state before the falure occurs. Ths smplfes the mplementaton of the agent falure detecton mechansm Falures of wtness agent and recovery scenaros Before the actual agent completes ts tnerary, there are wtness agents spawned along the tnerary of actual agent. The youngest (.e., the most recently created) wtness agent s wtnessng the actual agent. On the other hand, the elder wtness agents are nether dle nor termnated; they have another mportant responsblty: an earler wtness agent montors the wtness agent that s just one server closer to the actual agent n ts tnerary. That s :!!!!! 2! :::!!! where! represents the montorng relaton. We name the above dependency the wtnessng dependency. Ths dependency cannot be broken. For nstance, f s n S.! ; s montorng, and! ;2 s montorng! ;. Assumng we have the followng falure sequence : S ; crushes and then S crushes. Snce S ; crashes,! ; s lost, hence no one montorng. If no one recovers! ; n S ;, then no one can recover after S has crushed. Ths s not desrable. Therefore, we need a mechansm to montor and to recover the faled wtness agents. Ths s acheved by the preservng the wtnessng dependency: the recovery of! ; can be performed by! ;2, so that can be recovered by! ;. Fgure 5 llustrates ths scenaro. Note that there are other more complex scenaros, but as long as the wtnessng dependency s preserved, agent falure detecton and recovery can always be acheved. In order to preserve the wtnessng dependency, the wtness agents that are not montorng the actual agent receve message from the wtness agent that s montorng t. That s,! sends a perodc message to! ; n order to let! ; knows that! s alve. We label ths message msg. alve When! ; cannot receve msg from! alve, the reasons can be: Wtness dependency s broken (2) Falure strkes server S Actual agent s termnated (3) Wtness agent at S recovers Wtness agent at S -2 - (4) Wtness agent at S recovers the actual agent - Fgure 5. Wtness agent falure scenaro. The network s congested or unrelable; 2. The system load of S s hgh; or 3.! s dead. No matter what the reason of the falure s,! ; can always assume that! s dead.! ; wll spawn a new wtness agent, namely!, n order to replace the lost wtness agent n S. Snce there s no specal data stored n the wtness agent, only ntalzng the states of the new wtness agent s requred (see Fgure??). When! s at S,t re-transmts the message msg to! alve ;. If t s a falsedetecton,.e., the message s lost, but the wtness agent s stll n S, we can prohbt multple nstances of! from executng by exchangng messages between 2 nstances of! Catastrophc falures The wtness agent protocol cannot guarantee that all falures are detected and recovered. Frst of all, the wtnessng dependency cannot be always preserved. The weakness s at the head of the wtness dependency,!, whch s not montored by any agents. Hence, when S fals,! cannot be recovered. Ths wll shorten the wtness dependency. Secondly, f the above shortenng process goes on, the whole wtnessng dependency wll collapse when a seres of falures completely destroy the wtnessng dependency. Though the possblty of such falure seres s extremely small, f t happens, the protocol wll fal. In order to handle ths falure seres, the owner of the actual agent can send a wtness agent to the frst server, S, n the tnerary of the agent wth a tmeout mechansm. The effect of sendng ths wtness agent s smlar to the case when a wtness agent,!, fals to receve msg +. alve Ths method can recover! and the wtness dependency effectvely wth an approprate tmeout perod.

6 3.3.5 Smplfcaton Note the wtnessng dependency s useful only when several servers fal n a short perod of tme. However, ths dependency uses a lot of resources along the tnerary of the actual agent. If we assume that no two or more servers can fal at the same perod of tme, we can smplfy our mechansm by shortenng the wtnessng dependency. The dependency then becomes:! ;!!! where! represents the montorng relaton. Snce no two servers can fal smultaneously, two wtness agents are suffcent to guarantee the avalablty of the actual agent. When a falure occurs n S,! ; can recover! after the server s recovered. When a falure happens n S ;, we can let the dependency to be further shortened. It s because when travels to S +2, a new dependency nvolvng!,! +, and wll be formed, and the smplfed protocol resumes. Fnally, when! spawns! +, we can termnate! ; by sendng a message from S to S ;. 4 RELIABILITY EVALUATION The relablty evaluaton of our protocol s conducted by Stochastc Petr Net smulaton [, 2] usng SPNP [3] as well as agent code mplementaton by usng Concorda [3]. Relablty n our experment s measured by the successful rato of actual agents n completng ther scheduled round-trp travels n a network of agent servers. We ntroduce a server called home,.e., the machne of the agent owner. The home server s responsble for transmttng agents when the agents start travelng as well as for recevng agents when they fnsh travelng on the network. We carry out the experment by usng dfferent tnerares wth varous lengths. We assume that the home s errorfree whle the other servers are error-prone. We nject falures nto every server. In each server, we create a daemon runnng together wth the agent server (or the agent platform). The daemon wll randomly kll the process of the agent server. When the server montor, another daemon that montors all the servers, dscovers that an agent server s dead, t restarts the agent server process wthn a specfed tme. 4. Server Falure Detecton Analyss Fgure 6 shows the Stochastc Petr Net that models the server falure detecton mechansm for one server. The shaded part on the left descrbes the states of an agent nsde a server. The transtons on that part are manly tmed transtons. They model the tme spent on travelng between two servers and the tme requred for the computaton of an agent. The shaded regon on the rght s the server montor. It also contans tmed transtons. These transtons model the tme spent on detectng the avalablty of a server and T-_ atnode_ T_ jobdone_ T_ T_2 aval_ Agent Itnerary T_3 T_4 T_7 Falure_ T_6 recover_ montor_ Server montor T_5 guard arc nput/output arc nhbtor arc Fgure 6. A server model wth server falure detecton Successful Percentage Level and Level Mechansms Analyss Level (Concorda) Level (Concorda) Level (Smulaton) Level (Smulaton) Fgure 7. Evaluaton result of server falure detecton the tme requred to perform a recovery. The non-shaded place n the mddle states the avalablty of the server. When a token s nsde that place, the server s avalable. However, f there s no token nsde that place, the server fals, and all agents nsde the server are lost. Fgure 6 only shows the model of one server. We can put several servers together to form a chan. That chan represents the tnerary of the agent. Our experment s carred out by connectng dfferent numbers of these modules to represent dfferent numbers of servers n the agent tnerary. The results of usng both the Concorda mplementaton and the SPNP smulaton are shown n Fgure 7. The experment compares two scenaros, one wthout server falure detecton (Level ) and the other wth server falure detecton (Level ). Ths experment llustrates how much the relablty s mproved by the server detecton and recovery mechansm wth a gven server falure rate. The result shows that the successful percentage of an agent wth server falure detecton and recovery drops much slower than an agent wthout ths mplementaton. Wth the measurement of 2 servers n the agent tnerary, the successful rato of the agents wth fault-tolerance server mplementaton falls

7 Relablty Improvement of Level Mechansm over Level Level and Level 2 Mechansms Smulaton Analyss 8 7 Relablty Improved (%) Successful Percentage Fgure 8. Relablty mprovement wth server falure detecton between 55 and 6 percents. The successful percentage of agent wthout fault-tolerance server mplementaton, on the other hand, falls below percent for both smulaton and Concorda mplementaton. Fgure 8 shows the overall mprovement of the fault-tolerance server mplementaton (Level ) versus the non-fault-tolerance mplementaton (Level ). The ncreasng slope mples that the advantage of the fault-tolerance mplementaton becomes more sgnfcant as the number of servers ncreases. The result measured by usng smulaton shows a monotonc ncreasng relaton between the successful rato and the number of servers. As the number of servers ncreases, the number of successful round-trp-travels decreases progressvely. It s reasonable snce the chance of watng for the recovery of a faled server ncreases, the probablty of the agent loss whle t s watng wll also ncrease. 4.2 Agent Falure Detecton Analyss We perform the same experment for the evaluaton of the agent falure detecton and recovery. In the prevous subsecton, we can observe that wth the server falure detecton and recovery, the system stll suffers from the loss of agents. Therefore, the goal of the agent falure detecton and recovery mechansm s to ncrease the percentage of successful round-trp travels by wtness agent mechansm. We construct the Stochastc Petr Net that models both the falure detecton and recovery for both servers and agents. Our experment s carred out by smulaton wth up to 2 servers, whch s shown n Fgure 9. The prmary result ndcates that the successful percentage of a roundtrp travel n our fault-tolerance mechansm (Level 2, whch further ncorporates the wtness agents) s further mproved wth respect to that wth only the fault-tolerance server mplementaton (Level ). Our fault-tolerance mechansm can always recover faled agents,.e., we have a % recovery. Fgure, depcts the relablty mprovement of the agent/server fault-tolerance mechansm (Level 2) over the server-only fault-tolerance mechansm (Level ). The result shows that the relablty s further enhanced. It reaches about 8% wth an tnerary of twenty servers. However, Fgure 9. Server vs. smulaton result. Relablty Improved (%) Level Smulaton Level 2 Smulaton agent falure detecton Relablty Improvement of Level 2 Mechansm over Level Mechansm Fgure. Relablty mprovement wth agent falure detecton and recovery one sde effect s that whenever we have recovered an agent, the new agent may encounter another falure. Ths generates many extra agents. Fgure shows the results of the number of extra agents (n percentage) per successful round-trp travel aganst the number of servers. It ndcates that as the tnerary becomes longer, more extra agents wll be requred, and consequently the complexty of the system s ncreased. 5 CONCLUSION In ths paper, we propose an approach to enhance moble agent systems wth better relablty. We also analyze dfferent falure scenaros that may happen n the moble agent systems, and desgn a progressve fault-tolerance scheme that can detect the server and the agent falures. We further dscuss the mechansm, whch uses a global daemon, communcaton messages, and checkpontng technques, that enables us to detect and recover these falures by employng cooperatve wtness agents. We conduct relablty evaluaton of the proposed mechansm for server falures and agent falures. The result shows that, under the condton

8 4 Extra Agents Requred Applcatons and Technques of Web Agents (3) (Baltzer Scence Publshers, 998), pp Extra agent (%) Fgure. Extra agent per successful roundtrp travel. for up to 2 servers, wth the server falure detecton only, we acheve a sgnfcant mprovement for the successful rato of the agent round-trp travels. In addton to the server falure detecton, we further mprove the relablty by usng the agent falure detecton over server falure detecton. However, the cost becomes hgher when we want to acheve a hgher level of fault-tolerance. Quanttatve results for trade-off study between cost and relablty of the proposed scheme are provded n ths paper. 6 ACKNOWLEDGMENT The work descrbed n ths paper was fully supported by a grant from the Research Grants Councl of the Hong Kong SAR, Chna (Project No. CUHK493/E). References [] Anthony H.W. Chan, T.Y. Wong, Cars K.M. Wong, and Mchael R. Lyu. Desgn, Implementaton and Expermentaton on Moble Agent Securty for Electronc Commerce Applcatons. Proceedngs of the Internatonal Conference on Parallel and Dstrbuted Processng Technques and Applcatons. pp [2] D. Lange and M. Oshma. Moble agents wth java: the aglet API. Specal Issue on Dstrbuted World Wde Web Processng: Applcatons and Technques of Web Agents (3) (Baltzer Scence Publshers, 998), pp.-2. [3] D. Wong, N. Pacorek, T. Walsh, J. DCele, M. Young, and B. Peet, Concorda: an nfrastructure for collaboratng moble agents, n Moble Agents, Proceedngs of st Internatonal Workshop, MA 97, Lecture Notes n Computer Scence 29, pp [5] Stefan Plesh and Andre Schper. Modelng Fault- Tolerant Moble Agent Executon as a Sequence of Agreement Problems. Proceedngs of the 9th IEEE Symposum on Relable Dstrbuted System 2 (SRDS-2), pp.-2 [6] Stefan Plesch and Andre Schper. FATOMAS - A Fault Tolerant Moble Agent System Based on the Agent-Dependent Approach. The Internatonal Conference on Dependable Systems and Networks, 2, pp [7] Dag Johansen, Keth Marzullo, Fred B. Schneder, Kjetl Jacobsen, and Dmtrl Zagorodnov. NAP: Practcal Fault-Tolerance for Itnerant Computatons. Proceedngs of the 9th IEEE Internatonal Conference on Dstrbuted Computng Systems, 999., pp [8] Markus Strasser and Kurt Pothernel. System Mechansms for Partal Rollback of Moble Agent Executon. Proceedngs of 2th Internatonal Conference on Dstrbuted Computng Systems 2, pp [9] Vctor F. Ncola. Checkpontng and the Modelng of Program Executon Tme. Software Fault Tolerance, M. Lyu (ed.), John Wley & Sons, 994, pp [] Kurt Rothermel and Markus Stasser. A Fault- Tolerant Protocol for Provdng the Exactly-Once Property of Moble Agents. Proceedngs of 7th IEEE Symposum on Relable Dstrbuted Systems 998, pp.-8. [] Lorre Tomek and K.S. Trved. Analyses Usng Stochastc Reward Nets. Software Fault Tolerance, M. Lyu (ed.), John Wley & Sons, 994, pp [2] Danxang Xu and Y Deng. Modelng Moble Agent Systems wth Hgh Level Petr Nets. IEEE Systems, Man, and Cybernetcs, 2, pp [3] C. Hrel, B. Tuffn, and K.S. Trved. SPNP: Stochastc Petr Nets, Verson 6.. th Internatonal Conference of Computer performance evaluaton: Modelng tools and technques. Schaumburg, Il., USA, B. Haverkort, H. Bohnenkamp, C. Smth(eds.), Lecture Notes n Computer Scence 786, Sprnger Verlag, 2. [4] J. Baumann, F. Hohl, K. Rothermel and M. Strasser. Mole - concepts of a moble agent system. Specal Issue on Dstrbuted World Wde Web Processng: