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

2001. 5. 31 Compiled by Rhee, Taik-heon

Contents

IntroductionTabiCanOverview of e-Marketplace MiddlewareAgent Scheduling MechanismPerformance EvaluationConclusion

Multi-Agent System

studied for many yearsvarious types of systems

e.g) distributed artificial intelligent system

singleproblem

small problem

small problem

small problem

solveproblem

Introduction

Agent Technology

Applied to e-commerce areaExamplesAuctionBots(http://auction.eecs.umich.edu)

uses agents that have user prefenceWebCompass(http://www.quaterdeck.com)

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 informationby interacting with all shop agents

Overview of TabiCan SystemTabiCan

WebBrowser

e-Marketplace A

e-Marketplace BShopAgent 2

ShopAgent 1

DirectoryService

ConsumerAgent

Matched with your request!Narita-Honolulu

Japanese AirLinesPrice = $900

Cheaper one!! Why don’t you buy?

Narita-HonoluluUnited AirLines

Price = $600E-Marketplace B is

another travel market.

ConsumerAgent Shop

Agent 3

We have a discount executive class ticket!

Narita-HonoluluNorth-West AirLines

Executive ClassPrice = $1200

Do you have..?Narita-Honolulu

Japanese AirLinesPrice <= $1000

Visit

Link

Role of Agents

Shop Agents live during server runs

Consumer Agents live for two days in serverremoved when lifetime is overmultiple access is available while

alive

TabiCan

History

1st phase(Dec. 1997): for single servers2nd phase(Aug. 1998): for multiple servers3rd phase(Dec. 1998): for multiple sites

TabiCan

Overview of e-Maketplace Middleware

Aglet System Development Kit(ASDK)(http://aglets.trl.ibm.co.jp)developed atIBM’s

Tokyo Research Lab.provides

mobile agent fn.and multi-agent fn.

Agent Interaction(1/2)

Sessiona sequence of message

viewed as state transitionstate

state-1: initialstate-2~99: intermediatestate-100: final

link indicate transition

Overview of Middleware

Agent Interaction(2/2)

Message Monitor registers all interaction protocolsdelivers all msg. to agentsverifies every msg.

if invalid, remove the messagewatch for processing of agent’s msg.

if time-out, terminate interactionand ask “AgentSchduler” to stop processing

Overview of Middleware

Agent Control(1/2)

In TabiCan, 2000 consumer agents were created in server30KB * 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)

AgentSchedulercontrol the amount of memory

by keeping agents in secondary storagecontrol the number of thread

by scheduling activities of agents

Overview of Middleware

Agent Scheduling Mechanism

Controlled by AgentScheduler

Memory ControlThread ControlScheduling Policy

Memory Control(1/3)

Swap-in and swap-out mechanismSimilar with OSDeactivation if the number of agnets exceeds limits,

some agents are stored as memory imagesin 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 Usedalgorithm (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.inispecifies the parameters for agentse.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.confspecifies scheduling policiese.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 SystemTest 2: Two-Server System

Test 1: Single-Server System

Throughput of searches Turnaround time of searches Throughput of searchesagainst # 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 constantto an increase in # of consumer agents