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

Presenter: Selim KalayciAgnostic: Srilakshmi Medam

OutlineBackgroundMotivationWhat is PAWN?JXTADesign and Implementation of PAWNA Prototype ApplicationConclusionAgnostic Questions

Peer-to-Peer NetworksSource: Enabling Peer-to-Peer Interactions on the Grid , Vincent Matossian, Masters Thesis, Rutgers Graduate School, May 2003

Grid ComputingGrid 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

MotivationSimilarities between P2P and Grid:Underlying Decentralized Network InfrastructureDynamic Discovery of ResourcesAggregation of Distributed ResourcesThe need for System Integrity and Security Guarantees

MotivationGlobal and Autonomic Scientific Investigation requires:Continuous, Seamless, Secure InteractionswhereApplication 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.

PAWNPawn (Peer AWare Networking) is a publisher/subscriber messaging framework that offers interaction services for:Distributed object management, monitoring and steeringGroup formationCollaboration through guaranteed, flexible and stateful messaging

PAWNProvides Advanced Messaging Semantics:Guaranteed Message DeliveryPush, Pull MechanismsTransactionsRequest/Response Interaction ModalitiesSynchronous/Asynchronous CommunicationCoordination through Message OrderingRemote Procedure Calls

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

JXTA ConceptsPeersPeergroupsAdvertisementsModulesPipesUnicast, PropogateBlocking, Non-BlockingRendezvousSecurity

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

PAWN DesignPeers compose messages handled by services through specific interaction modalitiesSource: Enabling Peer-to-Peer Interactions on the Grid , Vincent Matossian, Masters Thesis, Rutgers Graduate School, May 2003

Fundamental Pawn ServicesApplication 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.

Peers in PAWNSource: http://www.caip.rutgers.edu/TASSL/

PAWN ImplementationBuilds on current Java implementation of JXTA protocolsJXTA defines:Unicast pipePropogate pipeResolver Service (Asynchronous Comm.)Pawn extends these to realize 4 fundamental services

PAWN ImplementationStateful Messagesthrough PayloadMessage Guaranteesusing per-message Acknowledgement TableSynchronous/Asynchronous CommunicationDynamic Data InjectionRemote Method Calls (PawnRPC)

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

CONCLUSIONPawn: 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

Question 1Statement: 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?

Question 2Statement: 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.

Question 3Statement: 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.

Question 4Statement: 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.

Question 5Statement: 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.

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

Question 7Statement: 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?

Question 8Statement: 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?