CMSC 691 B MultiAgent System A Scalable Architecture

CMSC 691 B Multi-Agent System A Scalable Architecture for Peer to Peer Agent by Naveen Srinivasan

Overview of presentation • Introduction • Related Work • Cluster Based Architecture – 100 Feet View – 1 Feet View • Issues • Implementation • Future Work and Conclusion

Introduction • Future of Agent – Adapting to Agent-oriented solution – Standardization of Agent by FIPA • Service Discovery – Coordination and Cooperation – Simple example Contract-Net Protocol • Existing Approaches – Central repository – Gnutella model • Cluster-Based architecture

Related Work • Jini – – – Service Discovery Protocol developed by Java Central server hold the service list nodes which offers service registers itself ( lease ) to central server User query the central server Nodes may renew their lease period Advantage • Quick Response • Scalable – Disadvantage • Single point of failure • Bottleneck • P 2 P – Napster Model • Same as Jini but no renewing of lease • Same advantage & disadvantage as Jini

Related Work(Cont. . . ) • P 2 P (Cont. . ) – Gnutella model • Distribute model - Each node know few other nodes in the network which in turn know few other node and so on • Advantage – No single point of failure • Disadvantage – Not scalable due to huge amount of traffic generated – Poor query response time • Brokering and Matchmaking • Agent Location

Cluster Based Architecture • FIPA notion of Agent • Assumptions – Platform may enter and leave the network ( i. e. Environment is Dynamic Nature ) – Platform stay in the network for considerable amount of time – Directory Server – All agent platform expresses describes itself , its preference and other requires details in a Profile that is exchanged.

100 Feet View • Idea behind the protocol is forming groups in the network and electing a leader to represent the group • Each node when entering the network does the following – – – Gets few agent platform addresses profile the directory server Contacts the agent platform and gets the list of leaders profile ( Meta Peers) Choose one Meta Peer and joins that group Sends the DF information to the Meta peer Sends Queries to Meta peer Starts the leader election component

100 Feet View (Cont. . ) • Meta Peer – – – It receives DF s from the slave agent platform Returns them the profiles of the agent platform in that group Collects list of other Meta Peers Receives query from slave agents and route it to other Meta Peers Starts a keep-alive mechanism • Leader Election Behaviour – Once the slave agents finds that the leader is dead it start the leader election process – Each agent will look into profile of other agents it has and chooses leader depending on the preference to be Meta Peer field – New Leader is selected and all peers register themselves to the new leader

1 Feet View • Architecture Slave Component Agent Master Component Agent Platform • Slave Component Start Up DF DF Update Query Master Leader Election Keep Alive AGENT PLATFORM

1 Feet View (Cont. . ) • Master Component Meta DF Update Query Component Slave Meta Peer Keep Alive AGENT PLATFORM

Issues • Leader Election Procedure – Static in Nature – Dynamic in Nature • Group Size – Ideal Number – Ideal grouping depending on location, content etc… • Searching Meta – DF – Pattern Matching – Semantic Matching • Handoff – Best case of Leader Election – Efficient DF transfer

Implementation • Agent Framework – Jade – RDF for ontologies • Directory server • Total no. of agents 10 – 2 leader – 8 slaves ( two groups of 4) • • Start Up considered as special case Tested how a new agent platform adapts to existing network Query routing between Meta-Peers Simple Leader Election procedure implemented

Future work & Conclusion • Future Work – Try to implement sophisticated leader election algorithm – Collect experimental results – Make the system adaptable to network load & platform load • Conclusion – Proposed Scalable Peer to Peer agent architecture – Convinced with the performance of the system