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 Pawns 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. Isnt
  this an unfair comparison with JXTA?