Pawn: Enabling PeertoPeer Interactions on the Grid

1
Pawn Enabling Peer-to-Peer Interactions on the
Grid

• Vincent Matossian
• Spring 2003

The Applied Software Systems Laboratory
2
Peer-to-peer computing
centralized
decentralized
3
Motivation

• Move towards decentralized computing
• Decentralized systems build on common layers of
  protocols and mechanisms
• The Grid community is addressing low-level
  requirements and specification such as security,
  resource allocation and management.
• Grid applications require high-level peer-to-peer
  interactions which remain an open problem

4
Autonomic Computational Collaboratory on the Grid
- Enabling Global Scientific Investigation
5
Problem statement

• Define the requirements and semantics of a
  messaging substrate enabling application
  interactions on the Grid
• Identify and implement the corresponding services
  and mechanisms
• Deploy and evaluate such a messaging substrate

6
Decentralized systems a lot of issues ?

• Naming How to map a resource name to a
  location?
• Discovery How to discover and publish a
  resource?
• Routing How to route information from a source
  to a destination address?
• Coordination How to maintain ordering of
  messages arriving from distributed nodes ?
• Fault-tolerance How to cope with nodes failing
  spontaneously in the network?
• Security How to guarantee authentication,
  integrity, confidentiality of messages and peers?

Those issues have been addressed Naming
Discovery ? DNS Routing ? OSPF Coordination ?
Timestamp algorithms Fault-tolerance ?
Replication Security ? Public Key Infrastructure
7
Our focus

• Engineer a peer-to-peer messaging substrate that
  extends existing solutions to enable high-level
  interactions for scientific applications

8
Contributions

• We argue that building large-scale scientific
  collaborations benefits from a purely
  peer-to-peer architecture as opposed to a
  client/server architecture.
• We define the design requirements of a
  peer-to-peer messaging middleware.
• We implement and deploy Pawn, a peer-to-peer
  messaging that allows building interoperable,
  adaptive, and autonomic applications
• We evaluate the performance of Pawn in a
  real-world application

9
Talk overview

• Background related work
• Messaging systems,
• Peer-to-peer and collaborative problem solving
• Pawn Design and Implementation
• Architecture
• Components
• Interactions
• Services
• Application Scenario Autonomic optimization of
  oil reservoir simulation
• Experimental evaluation
• Communications
• Stress tests
• Costs (memory processing)
• Conclusions and future work

10
Messaging systems

• 4 broad categories of messaging systems

• 2 broad architectures
• Point to-point (e.g. email)
• Publisher/Subscriber (mailing list)

11
Messaging middleware publish/subscribe systems

• MOM such as Java Message Service, IBM MQSeries,
  LeSubscribe can
• Embed message transaction mechanisms in simple to
  use API
• Provide flexible delivery and transfer guarantees
• Use queues to store and forward messages between
  hosts
• Perform Content-based routing
• Enable event notification across WAN
• Messaging for Grid Applications such as GridRPC,
  XEvents/XMessages
• Support for messaging across virtual
  organizations
• P2P Messaging for Grid Applications such as
  NaradaBrokering
• Wide area event brokering targeting large scale
  collaborations in education and science
• Grid middleware such as ICENI
• Enables component-based application composition
  for e-Science
• Pawn is a publish/subscribe system
• Combines properties from messaging and P2P
  messaging on the Grid to provide
  publisher/subscriber functionalities (push, pull,
  request/response, transactions).
• Focuses on interaction services to support
  application monitoring and steering,
  collaboration, and application execution on the
  Grid.
• Extends JXTA pipe and resolver services to
  provide guaranteed application-level message
  delivery.
• Messages contain state information, that allow
  the system to recover from failure.

12
P2P collaboratories requirements

• Benefit from a peer-to-peer architecture
• Group formation Collaboration
• Messaging
• Flexible delivery and transport guarantees
  transparent to the user
• Network architecture Communication models
• Synchronous communication for real-time
  information transfers
• Asynchronous communications for storing
  information when offline
• But certain issues remain open problems
• Security and trust
• Distributed data archival

13
Pawn Overview

• Provides messaging mechanisms to enable
  interactions on the Grid
• Provides publish/subscribe mechanisms across
  peer-to-peer domains
• Builds high-level messaging semantics on top of
  low-level interaction modalities
• PUSH e.g. dynamic data injection
• PULL e.g. monitoring
• REQUEST/RESPONSE e.g. data interrogation
• TRANSACTION e.g. steering
• FILTERED MULTICAST e.g. group collaboration
• Built on top of Project JXTA

14
JXTA a framework for p2p apps

• SUN Introduced JXTA in April 2001
• Motivation is provided a common platform for p2p
• Project JXTA defines
• 6 Concepts
• 6 core Protocols
• A Network Architecture
• Communication models (unicast, propagate)

15
Project JXTA Concepts

• Peer
• Any compute-capable device that understands a
  subset of the common protocols
• PeerGroup
• A group of peers that share similar interests
• Pipe
• Communication channels between peers
• Module
• A general behavior described by a peer or a
  peergroup. JXTA separates the definition of the
  behavior from its implementation.
• Advertisement
• A published neutral document XML describing a
  resource
• Security
• Using secure sockets for every transmission.
• Enforcing membership policies at every peer

16
Project JXTA Protocols

• PDP (Peer discovery protocol) used by peers to
  advertise their own resources
• PIP (Peer Information protocol) monitoring
  peers status and load
• PBP (Pipe Binding Protocol) to establish a
  virtual communication channel between peers
• PRP (Peer Resolver Protocol) sending and
  receiving queries and responses
• RVP (Rendezvous Protocol) to propagate messages
  in a peer group
• ERP (Endpoint Routing Protocol) to find routes
  from a source to a destination

17
From JXTA to Pawn

• JXTA Provides core capabilities
• Publication
• endpoints publish uniquely identified messages.
• Advertisement
• Language-independent document describing a
  resource
• Caching
• RV peers cache advertisements made by every
  endpoint and maintain consistent replicas.
• Routing
• path to destination is determined by the nearest
  rendezvous peer using the endpoint router
  protocol
• Pawn extends JXTA to provide
• Distributed object Interactions on top of a
  peer-to-peer substrate
• Serialization of Objects to XML streams
• Method invocation on remote objects RMC
• Interest Subscription
• Content-based information dissemination. Every
  message carries metadata allowing peers to
  register interest on an attribute basis.

18
Pawn conceptual overview

• Pawn enables and defines every part of the
  figure on the right. This figure can be read as
• Peers compose messages handled by services
  through specific interaction modalities

19
Pawn components
20
Pawn Components

• Client Peer
• Deploy applications for monitoring and steering
• Collaborate with other peers
• Rendezvous Peer
• All peers are connected to rendezvous for
  discovery.
• Rendezvous cache messages.
• Dynamic message aggregation
• Application Peer
• Provides an interface to the application controls
• May act as a proxy for relaying queries and
  responses

21
Pawn Interactions

• JXTA communication enabled through
• Pipes
• Synchronous blocking
• Asynchronous non blocking
• Resolver
• End-to-End messaging
• TCP Stream
• Datagram packets
• Filtered multicast
• Group distribution
• Pawn services build on these communication
  mechanisms

22
Pawn Services

• Application Execution AEX
• Start, stop and get status of Applications
• Application Monitoring and Steering AMS
• Application querying and management
• Application Runtime and Control ARC
• Publishes application responses and status
• Remote Method Calls RMC
• Provides synchronous/asynchronous RPC calls in a
  platform and language independent manner
• Group communication
• Handles text messages between groups of clients

23
Pawn AMS, AEX, Group communication Services

• Build on JXTAs Resolver service
• XML Messages contain
• Destination, source, application id, queryID,
  queryType, unique Handler name
• Reliability provided by caching
• ARC provides API to
• announceApplication
• sendAppResponse
• publishUpdateMessage
• notifyEndApplication
• AMS provides API for
• sendAppRequest

24
Pawn ARC and RMC Services

• RMC builds on non-blocking JXTA pipes
• Defines an XML interface to the remote method
  call
• Uses message queues for ordering
• Messages carry unique identifiers to maintain
  consistent, coordinated application events

25
Scenario Autonomic oil reservoir optimization
26
Scenario Actors

• IPARS
• parallel reservoir simulation framework
• IPARSFactory
• configures instances of IPARS simulations
• deploys them on resources on the Grid
• manages their execution
• VFSA Optimization
• Optimize the placements of wells and the inputs
  (pressure, temperature) to IPARS simulations.
• Economic Modeling Service
• Uses IPARS simulations outputs and current market
  parameters (oil prices, costs, etc.) to compute
  estimated revenues for a particular reservoir
  configuration.
• DISCOVER Client Portals
• Provide the experts (scientists, engineers) with
  collaborative access to the other peers.

27
Scenario Peer Deployment

• Client authenticates to the DISCOVER Server
  running Globus toolkit using GSI
• Once authenticated Clients can deploy
  IPARSFactory and VFSA optimization peers using
  Globus GRAM protocol on available machines

28
Scenario Peer Discovery

• Peers publish advertisements describing their
  identity and functionalities
• Using underlying JXTA Discovery services, peers
  discover the advertisements and can start
  interacting

29
Scenario Optimization Process

• VFSA sends a well position guess to IPARSFactory
• IPARSFactory checks in Database if guess has
  already been run
• If guess found, result is returned clients and
  new guess from VFSA is generated
• If not found an IPARS instance is run
• IPARS returns the normalized revenue value to
  VFSA Optimization

30
Scenario Production Run for Monitoring and
Steering

• Experts use client portals to collaboratively
  connect to the running application, for
  monitoring and steering

31
Experimental setup and hosts configurations

• LAN experiments

• Hosts Configurations

• WAN experiments

32
Results Round Trip Time LAN

• Application peer pushes a response using ARC
• 20 client peers acknowledge the response using
  AMS
• The difference between 2 peers and 20 peers
  remains consistent over the varying message sizes
  evaluated
• The system is scalable

33
Results Response to load

• Comparing core JXTA rendezvous to Pawn Rendezvous
  using Message Queues
• Results show that JXTA drops messages when
  receiving over 100 simultaneous messages
• Pawn uses a queue to store and send messages

34
Results JXTA pipe and Pawn Remote Method Call

• Pawn Remote Method Call functionality adds
  overhead to core JXTA pipes
• This time overhead is associated to the time
  spent in the remote call and the time to marshal
  and unmarshal the invoked messages.

35
Results Memory

• Additional services do not add severe overhead
  compared to core JXTA load in memory
• Note that Client overhead is due to loading the
  portal graphical components

36
Conclusions and future work

• Collaboratories require P2P messaging in order to
  scale and be truly dynamic
• Pawn is a p2p messaging that provides interaction
  for monitoring and steering
• Presented design requirements in terms of
  services and mechanisms
• Presented the use of Pawn for the oil reservoir
  optimization process
• We are looking at extending this initial effort
  towards an autonomic computing framework

37
web links

• Pawns web page
• http//www.caip.rutgers.edu/vincentm/Pawn
• Project JXTA
• http//www.jxta.org
• OReilly p2p web site
• http//www.openp2p.com
• Brendon Wilsons book on JXTA
• http//www.brendonwilson.com