1 / 25

TabiCan: Massive Multi-Agent System

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. Introduction TabiCan

hien
Download Presentation

TabiCan: Massive Multi-Agent System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Introduction Multi-Agent System • 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. Introduction Agent Technology • 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. 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. Visit Do you have..? Narita-Honolulu Japanese AirLines Price <= $1000 TabiCan Overview of TabiCan System 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

  7. TabiCan 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

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

  9. Overview of e-Maketplace Middleware • Aglet System Development Kit(ASDK)(http://aglets.trl.ibm.co.jp) • developed atIBM’sTokyo Research Lab. • providesmobile agent fn.and multi-agent fn.

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

  11. 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 interactionand ask “AgentSchduler” to stop processing

  12. 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!

  13. 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

  14. Agent Scheduling Mechanism • Controlled by AgentScheduler • Memory Control • Thread Control • Scheduling Policy

  15. Agent Scheduling Mechanism 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 imagesin secondary storage • Activation • if an agent needs to process a job,the agent is read from storage

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

  17. Agent Scheduling Mechanism Memory Control(3/3) • 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 Least Recently Used algorithm (LRU)

  18. Agent Scheduling Mechanism 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)

  19. 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”

  20. 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

  21. 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

  22. Performance Evaluation Test 1: Single-Server System Throughput of searches Turnaround time of searches Throughput of searches against # of shops

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

  24. 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

More Related