Pawn: A peertopeer collaboratory

1
Pawn A peer-to-peer collaboratory

• Vincent Matossian
• 20020620

The Applied Software Systems Laboratory
2
objective

• Two main objectives
• Understand the needs of scientific collaboration
• tools
• communication mechanisms
• Deploy and evaluate such a collaborative problem
  solving environment

3
Isnt that a lot of issues ?

• including
• 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, Multicast
Backbone Coordination ? Lamports ordering
algorithm Fault-tolerance ? Replication Security
? Public Key Infrastructure
4
our focus

• among those issues we focus on the coordination
  and routing parts
• ? Messaging service
• we rely on other solutions JXTA for Discovery,
  Security mechanisms

5
talk overview

• Introduction to p2p and the JXTA framework
• Identification of collaborative problem solving
  requirements
• Scenario
• Related Work
• Status

6
client/server a picture
7
peer-to-peer a picture
8
JXTA a framework for p2p apps

• Project JXTA defines
• 6 Concepts
• Peers, groups, advertisements, modules, pipes
  security
• 6 core Protocols
• Discovery, Resolver, Information, Endpoint
  Routing, Rendezvous, Pipe Binding
• A Network Architecture
• Communication models (unicast, propagate)

9
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
• 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
• Pipe
• Communication channels between peers
• Security
• Using secure sockets for every transmission.
• Enforcing membership policies at every peer

10
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

11
network service

• Services provide functionality that peers can
  engage to perform useful work on a remote peer.
  This work may include transferring a file,
  providing status information, performing a
  calculation, or basically anything that you might
  want a peer in a P2P network to be capable of
  doing. Services are the motivation for gathering
  devices into a P2P network.
• Brendon Wilson

12
okaywhat can JXTA do ?

• Find other peers on the network with dynamic
  discovery across firewalls Discovery Service
• Easily share documents with anyone across the
  network Resolver or Pipe Service
• Find content at network sites Advertisements
• Create a group of peers that provide a service
• Monitor peer activities remotely Information
  service
• Securely communicate with other peers on the
  network

13
from JXTA to Pawn

• So far
• defined end-goal a p2p messaging for CPSE
• introduced p2p concepts
• introduced and defined JXTA
• Next
• define the requirements of CPSEs
• Why can JXTA be used to solve the problem
• What needs to be done, defining services and
  tools

14
collaborative problem solving

• Form collaborations btw
• Scientists
• Lab scientists
• Field engineers
• Resources
• Data
• Applications
• Instruments

15
peer-to-peer knowledge dissemination

• In solving a problem each peer contributes in a
  group by providing
• Ideas
• As text or voice messages Chat or Instant
  Messaging
• Information Results
• Raw data from previous or current simulation
• Interpreted data
• This material can be expressed to a group using a
  set of tools, such as
• Sharing
• Manipulating Annotating
• viewing

16
CPSE requirements

• Group formation Collaboration
• Each peer should be able to join/create a group
• Membership service controls access and guarantees
  integrity of the system
• tools for peers to chat. share and annotate
  results
• Message Propagation
• Every endpoint-generated message should flow
  through the network transparently to the user via
  optimal path.
• Use aggregation and filtering for messages of
  collaborative nature.
• Network architecture Communication models
• Synchronous communication for real-time
  information transfers
• Asynchronous communications storing information
  when offline
• Security
• Confidentiality, authenticity, Integrity,
  non-refutability
• Data archival
• Access to Logged information to avoid reiterating
  computations

17
messaging service

• Publication
• endpoints publish uniquely identified messages.
• Advertisement
• Every endpoint advertises its resources
• 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
• Logging
• Messages are logged at replicated stable storage
  sites for future access
• Interest Subscription
• Content-based message routing. Every message
  carries metadata allowing peers to register
  interest on an attribute basis.

18
pawn diagram
19
peer services

• application peer services
• locking controls are given to only one user
• object monitoring peers can receive updated
  results from an application object
• object steering peers can set object parameters
  if they possess the lock
• client peer services
• Presence status of the user (online, offline
  etc)
• Chat send and receive text messages
• Whiteboard send and receive graphical messages
• rendezvous peer services
• routing find a route from a source to a
  destination peer

20
example locking service

• Application maintains lock to grant control to a
  user
• LockQueryMsg 2 parameters
• QueryType
• LockRequesterID peerID
• Service offers several functionalities
• checkLockStatus status,peerID
• requestLock request,peerID
• releaseLock release,peerID
• getLockHistory history,peerID

21
example locking service contd

• LockResponseMsg
• QueryType
• LockRequesterID
• Response
• Response can be
• status response available or unavailable
• Lock granted lock owner changed
• Lock released lock is available again
• Lock history history of lock owners and times

22
scenario application peer

• Application advertises its existence as a new
  group
• When app generates new information it advertises
  an Application Advertisement
• every application message has a unique identifier

23
scenario client to application

• Advertises its existence to the group
• Discovers applications advertisements (possibly
  filtering its discovery using attribute-based
  strings)
• Joins applications of interest by authenticating
  to membership service
• sends query to application to receive objects
  list
• periodically discovers application advertisements
  allowing dynamic application configuration
• sends query to application from object list to
  retrieve responses
• caches responses

24
scenario client to client

• Presence service monitors clients in group
• Chat and whiteboard provide communication tools
• Sharing application responses referenced by
  unique message ID.
• peer may have cached message ID
• peer may need to request application for specific
  message ID.

25
rendezvous peers

• all peers are connected to rendezvous for
  discovery.
• rendezvous cache messages.
• dynamic message aggregation
• rendezvous exchange load and status information
• if subscriber peers have similar interests there
  connections are directed to similar rendezvous
• peers maintain a list of rendezvous
  advertisements
• in case of a rendezvous failure, peers connect to
  next rendezvous in list

26
related work

• Instant Messengers
• MSN,
• File sharing applications
• Kazaa, LimeWire
• P2P Distributed Computing applications
• Folding_at_Home
• Grid computing
• Globus toolkit, Access grid
• Event notification
• Siena, Elvin, Gryphon
• Overlay Networks
• RON, Mesh-based XML routing

27
status

• Implementation in Java 1.4
• Using JXTA platform build 49b, 02-08-2002
• Implemented
• locking, monitoring, steering and chat services
• advertisement mechanisms are in place
• Ongoing
• message aggregation and filtering (need several
  nodes)
• whiteboard service (will keep it simple)
• membership service for access control
• logging mechanism

28
my schedule

• deploy and demo mid-august

29
links

• Pawns web page
• http//www.caip.rutgers.edu/vincentm/pawn
• Project JXTA
• http//www.jxta.org