130 likes | 138 Views
This presentation discusses a scalable peer-to-peer agent architecture, exploring cluster-based approaches, issues, implementation details, and future work. It covers related work on Jini, service discovery, P2P models like Napster and Gnutella, and introduces a cluster-based FIPA agent system. Key topics include leader election, query routing, and agent components for a dynamic environment. The presentation highlights the system's advantages like quick response times and scalability while noting challenges such as bottleneck issues and single points of failure.
E N D
CMSC 691BMulti-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
I n t r o d u c t i o n • 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
R e l a t e d W o r k • 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 • P2P • Napster Model • Same as Jini but no renewing of lease • Same advantage & disadvantage as Jini
R e l a t e d W o r k ( C o n t . . . ) • P2P (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
Agent Slave Component Master Component A g e n t P l a t f o r m Start Up DF Update Query Master Leader Election Keep Alive DF A G E N T P L A T F O R M 1 Feet View • Architecture • Slave Component
Meta DF Meta DF Update Query Component Keep Alive Slave Meta Peer A G E N T P L A T F O R M 1 Feet View (Cont..) • Master Component
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
I m p l e m e n t a t i o n • 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 Questions ?