TabiCan: Massive MultiAgent System

1
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

2
Contents

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

3
Multi-Agent System
Introduction

• studied for many years
• various types of systems
• e.g) distributed artificial intelligent system

small problem
single problem
solve problem
small problem
small problem
4
Agent Technology
Introduction

• Applied to e-commerce area
• Examples
• AuctionBots(http//auction.eecs.umich.edu)
• uses agents that have user prefence
• WebCompass(http//www.quaterdeck.com)
• uses a search agent to obtain info. from WWW
• Not Multi-agent System!

5
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

6
(No Transcript)
7
Overview of TabiCan System
TabiCan
e-Marketplace A
We have a discount executive class
ticket! Narita-Honolulu North-West
AirLines Executive Class Price 1200
ShopAgent 1
ShopAgent 2
DirectoryService
e-Marketplace B
Link
ConsumerAgent
ConsumerAgent
ShopAgent 3
Web Browser
8
Role of Agents
TabiCan

• 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

9
History
TabiCan

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

10
Overview of e-Maketplace Middleware

• Aglet System Development Kit(ASDK)(http//aglets.
  trl.ibm.co.jp)
• developed atIBMsTokyo Research Lab.
• providesmobile agent fn.and multi-agent fn.

11
Agent Interaction(1/2)
Overview of Middleware

• Session
• a sequence of messageviewed as state transition
• state
• state-1 initial
• state-299 intermediate
• state-100 final
• link
• indicate transition

12
Agent Interaction(2/2)
Overview of Middleware

• Message Monitor
• registers all interaction protocols
• delivers all msg. to agents
• verifies every msg.
• if invalid, remove the message
• watch for processing of agents msg.
• if time-out, terminate interactionand ask
  AgentSchduler to stop processing

13
Agent Control(1/2)
Overview of Middleware

• 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!

14
Agent Control(2/2)
Overview of Middleware

• AgentScheduler
• control the amount of memory
• by keeping agents in secondary storage
• control the number of thread
• by scheduling activities of agents

15
Agent Scheduling Mechanism

• Controlled by AgentScheduler
• Memory Control
• Thread Control
• Scheduling Policy

16
Memory Control(1/3)
Agent Scheduling Mechanism

• Swap-in and swap-out mechanism
• Similar with OS
• Deactivation
• 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

17
Memory Control(2/3)
Agent Scheduling Mechanism

• Sequence of msg. delivery

18
Memory Control(3/3)
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 gt state 2 gt state 3 gt state 4
• Deactivation Priority
• state 4 gt state 3 gt state 2

Least Recently Used algorithm (LRU)
19
Thread Control
Agent Scheduling Mechanism

• 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)

20
Scheduling Policy(1/2)
Agent Scheduling Mechanism

• 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

21
Scheduling Policy(2/2)
Agent Scheduling Mechanism

• schedule.conf
• specifies scheduling policies
• e.g CONSUMER
• limit of consumer agents in memory is 200
• limit of threads for consumer agents is 10

22
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

23
Test 1 Single-Server System
Performance Evaluation
Throughput of searches
Turnaround time of searches
Throughput of searches against of shops
24
Test 2 Two-Server System
Performance Evaluation
Throughput of searches
25
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