OogP2P Framework

1
OogP2P Framework
Sanjay Ginde David Goldberg Chris Zeiders
2
Overview

• Peer-to-Peer Systems
• Network Model/Communication Architecture
• Application Architecture
• Examples of Implementation and Experience
• Chord
• Pastry
• Stats

3
What is Peer-to-Peer

• Peer-to-peer is a communications model in which
  each party has the same capabilities and either
  party can initiate a communication session
  (whatis.com)

4
Origins of Our Project

• Wide variety of p2p programs popping up in all
  different fields
• File Sharing, Gambling, Chatting, Gaming
• Our Goal
• Easily implement new components
• Learn about p2p networking and object-oriented
  design

5
Uses of such a framework

• Educational Settings
• Instructors, Introductory Students
• Advanced Students
• Academic Uses
• Research
• Statistical tool
• Commercial Uses
• Source Control
• Simple testbed for P2P Features

6
Anyone Home in Frameworkville?

• JXTA
• JXTA- JXTA technology is a set of open protocols
  that allow any connected device on the network
  ranging from cell phones and wireless PDAs to PCs
  and servers to communicate and collaborate in a
  P2P manner
• Complicated API
• Even sample programs were not simple or trivial
  to implement
• Lot of code for little functionality.
• P2P frameworks is a rapidly developing field
• We wanted to build our own framework

7
Network Model

• Runs on top of TCP/IP protocol
• Java-based
• Network traffic consists of objects
• Simple Server
• Handles information requests from clients
• Simple Clients
• Requests information

8
Network Model (cont.)

• Peer nodes are both servers and clients
• Essentially, each can request and distribute
  information
• Same Capabilities
• All nodes are equal (no central server)
• True Peer-to-Peer

9
Peer Discovery

• Must find IP address of node already on the
  network
• Our system uses a host list file with IP
  addresses of nodes
• Area of research all its own

10
Communication Architecture Goals

• General interface/facade to the network model
• Polymorphic structure for simple filtering of
  information to specified applications
• General structure to allow for the development of
  a wide-range of peer-to-peer components

11
Client Administrator
Client Administrator
Network Model
Communication Architecture
Interface bool sendNettable(IP address,
Nettable object)
12
Communication Protocol
Nettable
InfoReceived
Information Processor
Information (Sender / Requester)
13
Nettables and InfoReceived

• Nettables
• Wrappers/Adapters of information
• All data over the network must extend from the
  Nettable object
• InfoReceived
• Parallel to Nettable
• Executes/processes information locally at a node

14
Nettable-InfoReceived Example
15
Simple Communication
User A
User B
Chat Init Nettable
Chat Init InfoReceived
Chat App
Chat App
Chat Init Info Nettable
Chat Init Info InfoReceived
16
Complex Communication
Node 1
Node 2
Node x
Chord Find File Nettable
Chord Find File InfoReceived
Chord Find File InfoReceived
Chord Find File Nettable
Can keep getting passed on to other nodes until
file location is found
Chord Found File InfoReceived
Chord Found File Nettable
Chord Found File Nettable
17
Application Architecture Goals

• No modification to existing network model
• No modification to other apps running on system
• Constant, O(1), amount of code added to framework
  for a new feature

18
Three Parts of an Application

• Classes for domain of Application
• Application-specific
• Classes to fit with frameworks Communication
  Architecture
• Nettables, InfoReceived objects
• Classes to fit with frameworks Application
  Protocol
• Factories
• Extension from base framework objects

19
Domain Classes

• Independent development
• Add classes to fit within framework

20
Classes for Comm. Architecture

• Determine the data that needs to be exchanged by
  peers
• Create a Nettable-InfoReceived pair for each
  piece of data
• Good design practice
• InfoReceived Factory
• Mediator

21
Application Object

• Base Application Object
• All Applications extend from this object
• Encapsulates all objects associated with
  particular application
• Major Responsibilities
• Can determine which Nettables it handles
• Can process such a Nettable

22
Application Layer
23
Benefits of Application Object

• Clear distinction
• No new bugs to existing code
• No effect to running of other applications
• Supports multiple, similar applications
• Nettable-Application is one-to-one
• No overlap
• Different peers can support different applications

24
Utilities Map

• Stores global properties
• ClientAdministrator
• Mediators
• Stored in main p2p.java class

25
Our Experiences

• Chord, Statistics, and Pastry

26
Chord

• Chord is a distributed searching algorithm that
  uses consistent hashing in order to look up a key
  and find the node in the network that tells the
  searching node where its desired resource is
  located
• We wrote own version of Chord

27
Domain Classes

• Created, debugged, and tested Chord functionality
  outside of framework
• ChordNode, ChordLocation objects
• FixKey and Stabilize Threads
• Testing for correct byte masking and key hashing

28
Fitting with Communication Architecture
29
Fitting with Application Architecture

• ChordApplication
• ChordFactory
• ChordAdministrator

30
Personal Experience

• Hard part was implementing logic of Chord
• Had some fun with synchronization issues
• All code created for Chord was new code
• Did not have to modify underlying framework
• Addition of Chord did not affect the two previous
  applications running on the system (Chat and
  FileSharing)

31
Statistics Possibilities

• Two Groups of Statistics
• Transit Statistics
• Maintained in each packet
• Examples Number of Hops, Return Time, IPs
  traveled to etc.
• Client Statistics
• Maintained in each Client
• Examples Throughput, Most Frequent Packet
  Types, Current Connections, Time To Process
  Packets etc.

32
Statistics Our Choice

• Prompted stats
• Not actively recording
• Transit statistics based in each of the packets

33
Statistics How we implemented our statistical
recording

• Stat object e.g. ChordStat
• Record statistics
• Keeps records from a bunch of packets (routing
  hops, timing)
• Can compute stats like Means, StdDev, Modes, etc.

34
Pastry

• A distributed hash table algorithm like Chord
• Scalable system
• Bounded routing hops
• Adapted an already existing implementation
• FreePastry from Rice University
• Why?
• To show another facet of the frameworks
  flexibility
• Chord-Pastry Comparison

35
OogP2P and Pastry

• Process
• Extract pertinent parts from FreePastry
• Modify slightly to work within the context of the
  framework
• Network communication in particular
• Encapsulate as an application
• No change to the frameworks network or
  communication model

36
Conclusion

• OogP2P
• Extensible
• Easy to use
• Flexible
• Fun and challenging project