TabiCan: Massive Multi- Agent System Reference: Architecture and Performance Evaluation of a Massive Multi-Agent System, G. Yamamoto and Y. Nakamura, Autonomous Agents ’ 99, Seattle Compiled by Rhee, Taik-heon

Contents Introduction TabiCan Overview of e-Marketplace Middleware Agent Scheduling Mechanism Performance Evaluation Conclusion

Multi-Agent System studied for many years various types of systems  e.g) distributed artificial intelligent system single problem small problem solve problem Introduction

Agent Technology Applied to e-commerce area Examples AuctionBots ( uses agents that have user prefence WebCompass ( uses a search agent to obtain info. from WWW  Not Multi-agent System! Introduction

TabiCan Commercial service site providing airline tickets and package tours Multi-agent system to obtain info. on internet different from DAI independently developed agents interact with each other user and shops have their own agents on server user agents obtains information by interacting with all shop agents

Overview of TabiCan System TabiCan Web Browser e-Marketplace A e-Marketplace B Shop Agent 2 Shop Agent 1 Directory Service Consumer Agent Matched with your request! Narita-Honolulu Japanese AirLines Price = $900 Cheaper one!! Why don’t you buy? Narita-Honolulu United AirLines Price = $600 E-Marketplace B is another travel market. Consumer Agent Shop Agent 3 We have a discount executive class ticket! Narita-Honolulu North-West AirLines Executive Class Price = $1200 Do you have..? Narita-Honolulu Japanese AirLines Price <= $1000 Visit Link

Role of Agents Shop Agents live during server runs Consumer Agents live for two days in server removed when lifetime is over multiple access is available while alive TabiCan

History 1 st phase(Dec. 1997): for single servers 2 nd phase(Aug. 1998): for multiple servers 3 rd phase(Dec. 1998): for multiple sites TabiCan

Overview of e-Maketplace Middleware Aglet System Development Kit(ASDK) ( developed atIBM ’ s Tokyo Research Lab. provides mobile agent fn. and multi-agent fn.

Agent Interaction(1/2) Session a sequence of message viewed as state transition state state-1: initial state-2~99: intermediate state-100: final link indicate transition Overview of Middleware

Agent Interaction(2/2) Message Monitor registers all interaction protocols delivers all msg. to agents verifies every msg. if invalid, remove the message watch for processing of agent ’ s msg. if time-out, terminate interaction and ask “ AgentSchduler ” to stop processing Overview of Middleware

Agent Control(1/2) In TabiCan, 2000 consumer agents were created in server 30KB * 2000 = 60 MB memory is required! Each agent has a thread If too many threads, system overload may occur Control mechanism for memory and threads is the key issues for server! Overview of Middleware

Agent Control(2/2) AgentScheduler control the amount of memory by keeping agents in secondary storage control the number of thread by scheduling activities of agents Overview of Middleware

Agent Scheduling Mechanism Controlled by AgentScheduler Memory Control Thread Control Scheduling Policy

Memory Control(1/3) Swap-in and swap-out mechanism Similar with OS Deactivation if the number of agnets exceeds limits, some agents are stored as memory images in secondary storage Activation if an agent needs to process a job, the agent is read from storage Agent Scheduling Mechanism

Memory Control(2/3) Sequence of msg. delivery Agent Scheduling Mechanism

State of agent execution State 1: processing a job State 2: waiting to move to another server or to be removed State 3: not processing but will soon receive msgs. State 4: not processing and cannot predict next msg. Activation Priority state 1 > state 2 > state 3 > state 4 Deactivation Priority state 4 > state 3 > state 2 Agent Scheduling Mechanism Memory Control(3/3) Least Recently Used algorithm (LRU)

Thread Control AgentScheduler queues requests for actions A thread fetch a request from the queue Fetch priority Priority 1: in state 1, 2 and 3 Priority 2: in state 4 kept in main memory Priority 3: in state 4 kept in secondary storage Same priority: First Come First Served(FCFS) Agent Scheduling Mechanism

Scheduling Policy(1/2) boot.ini specifies the parameters for agents e.g: [CLASS_emplaceappl.tabican.Consumer] indicates parameters needed by consumer agents whose class is “ emplaceappl.tabican.Consumer ” Agent Scheduling Mechanism

Scheduling Policy(2/2) schedule.conf specifies scheduling policies e.g: [CONSUMER] limit # of consumer agents in memory is 200 limit # of threads for consumer agents is 10 Agent Scheduling Mechanism

Performance Evaluation Desirable constant in relation to # of consumer agents inverse proportion to # of shop agents Test 1: Single Server System Test 2: Two-Server System

Test 1: Single-Server System Throughput of searchesTurnaround time of searchesThroughput of searches against # of shops Performance Evaluation

Test 2: Two-Server System Throughput of searches Performance Evaluation

Conclusion A mechanism for controlling memory and CPU in multi-agent systems where thousands of agents interact on a single server is described. Throughput is kept to a constant to an increase in # of consumer agents