“Enabling Peer-to-Peer Interactions for Scientific Applications on the Grid”, V. Matossian and M. Parashar

1. “Enabling Peer-to-Peer Interactions for Scientific Applications on the Grid”, V. Matossian and M. Parashar Presenter: Selim Kalayci Agnostic: Srilakshmi Medam

2. Outline • Background • Motivation • What is PAWN? • JXTA • Design and Implementation of PAWN • A Prototype Application • Conclusion • Agnostic Questions

3. Peer-to-Peer Networks Source: Enabling Peer-to-Peer Interactions on the Grid ,Vincent Matossian, Masters Thesis, Rutgers Graduate School, May 2003

4. Grid Computing • “Grid computing is an emerging computing model that provides the ability to perform higher throughput computing by taking advantage of many networked computers to model a virtual computer architecture that is able to distribute process execution across a parallel infrastructure. Grids use the resources of many separate computers connected by a network (usually the Internet) to solve large-scale computation problems. “ Source: www.wikipedia.org

5. Motivation • Similarities between P2P and Grid: • Underlying Decentralized Network Infrastructure • Dynamic Discovery of Resources • Aggregation of Distributed Resources • The need for System Integrity and Security Guarantees

6. Motivation • Global and Autonomic Scientific Investigation requires: • Continuous, Seamless, Secure Interactions where • Application Components, Grid Services, Resources and Data (archives, sensors) Interact as PEERS. Why Peers? • Argument: Large-scale scientific collaborations benefits from a purely peer-to-peer architecture as opposed to a client/server architecture.

7. PAWN • Pawn (Peer AWare Networking) is a publisher/subscriber messaging framework that offers interaction services for: • Distributed object management, monitoring and steering • Group formation • Collaboration through guaranteed, flexible and stateful messaging

8. PAWN • Provides Advanced Messaging Semantics: • Guaranteed Message Delivery • Push, Pull Mechanisms • Transactions • Request/Response Interaction Modalities • Synchronous/Asynchronous Communication • Coordination through Message Ordering • Remote Procedure Calls

9. JXTA • General Purpose Peer-to-Peer Framework introduced by SUN Microsystems in April 2001. • Provide Developers with an Open, Platform and Language Agnostic Framework for deploying Interoperable Peer-to-Peer Applications and Services.

10. JXTA Concepts • Peers • Peergroups • Advertisements • Modules • Pipes • Unicast, Propogate • Blocking, Non-Blocking • Rendezvous • Security

11. JXTA Protocols Source: Enabling Peer-to-Peer Interactions on the Grid ,Vincent Matossian, Masters Thesis, Rutgers Graduate School, May 2003

12. PAWN Design “Peers compose messages handled by services through specific interaction modalities” Source: Enabling Peer-to-Peer Interactions on the Grid ,Vincent Matossian, Masters Thesis, Rutgers Graduate School, May 2003

13. Fundamental Pawn Services • Application Execution Service: to remotely start, stop or get the status of an application • Application Monitoring and Steering Service: handles peers outgoing messages. It is responsible for adding semantic information to every message. • Application Runtime Control: to announce the existence of an application to a peergroup, or return application responses • Group communication Service: In order to exchange text messages between individual or a group of peers.

14. Peers in PAWN • Source: http://www.caip.rutgers.edu/TASSL/

15. PAWN Implementation • Builds on current Java implementation of JXTA protocols • JXTA defines: • Unicast pipe • Propogate pipe • Resolver Service (Asynchronous Comm.) • Pawn extends these to realize 4 fundamental services

16. PAWN Implementation • Stateful Messages • through Payload • Message Guarantees • using per-message Acknowledgement Table • Synchronous/Asynchronous Communication • Dynamic Data Injection • Remote Method Calls (PawnRPC)

17. Autonomic Oil Reservoir Optimization Source: Enabling Peer-to-Peer Interactions on the Grid ,Vincent Matossian, Masters Thesis, Rutgers Graduate School, May 2003

18. CONCLUSION • Pawn: Peer-to-Peer messaging framework • Purpose is to provide Peer-to-Peer interactions for scientific applications on Grid. • Application components, Grid services, Resources and Data interact as Peers. • Pawn implementation is based on JXTA

19. Question 1 • Statement: Section 1: “Pawn focuses on interaction services to support application monitoring and steering, collaboration, and application execution on the Grid.” • Question: In what way is the focus on interaction services advantageous in a distributed environment? Are there any other services which would be equally important to focus on?

20. Question 2 • Statement: Section 2: “IPARS simulation interacts with the Economic model to determine current revenues, and discovers and interacts with the VFSA service when it needs optimization. VFSA provides IPARS Factory with optimized well information, which then launches new UPARS simulations.” • Question: It appears that the optimization of network processes and parameters is dependent on a feedback mechanism between IPARS and VFSA. How fast is IPARS? No results exhibit the advantages of using IPARS or dependence on its execution.

21. Question 3 • Statement: Section 3: “Typical roles for a peer are client, application or rendezvous.” • Question: Are these roles sufficient for a peer? They appear to be very broad roles. Can any comments be made on their roles being more specific and quantifiable? For example, “rendezvous” role appears specific and well-defined. However, “client” and “application” roles do not.

22. Question 4 • Statement: Section 3.1: “In Pawn, network services are application-centric and provide the mechanisms to query,…” • Question: Why is it an advantage for services to be application-centric? Assume that this question is not confined to network services alone. To me it appears that application centric nature will actually make a system more centralized and prone to single points of failure, nullifying the very reason we use Grid and its services.

23. Question 5 • Statement: Section 3.2: “Pawn implements application-level communication guarantees by combining stateful messages and a per-message acknowledgement table maintained at every peer.” • Question: What is novel about Pawn’s statefulness at the application layer to provide communication guarantees? While defining its messaging requirements, it appears that Pawn uses a rehash of simple window based protocol with a large window.

24. Question 6 • Is per-message acknowledgement fast? For a system with large number of peers exchanging messages, this procedure does not appear to be very efficient.

25. Question 7 • Statement: Section 3.2: “Upon receiving an RPC message, a peer locally checks the credentials of the sender, and if the sender is authorized, the peer invokes…” • Question: How is the credentials’ list generated? Is there a distributed mechanism to obtain this information?

26. Question 8 • Statement: Section 5, Figure 4: “Effectiveness of Message queuing.” • Question 8: It does not appear that Pawn has any novel advantage compared to JXTA for message queuing. JXTA appears to use TCP for message queuing which by default has a small window size (typically 32), and is a best effort delivery mechanism. Pawn simply moves the responsibility of message delivery to the application layer, and increases the window size considerably. Isn’t this an unfair comparison with JXTA?