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

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

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

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

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

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

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

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

9. 1 Feet View Architecture Slave Component Agent A g e n t P l a t f o r m Slave Component Master Component DF Update DF A G E N T P L A T F O R M Query Master Leader Election Start Up Keep Alive

10. 1 Feet View (Cont..) Master Component Meta DF Meta DF Update Keep Alive Query Component SlaveMeta Peer A G E N T P L A T F O R M

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

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

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