SRIRAM Peer-to-Peer Infrastructure

1
SRIRAM Peer-to-Peer Infrastructure

• Ashwin R. Bharambe
• Summer Internship
• _at_ IBM TJ Watson Research Center
• Joint Work with Sonesh Surana, UCB
• and Sambit Sahu, IBM

2
Motivation

• Every P2P application has its own
• Protocol
• Overlay construction and maintenance algorithms
• Caching policies, etc.
• Project goal
• Build common infrastructure for P2P applications
• Build an application on top of it as
  proof-of-concept

3
Outline

• Overlay Design
• Philosophy
• Construction and maintenance algorithms
• API
• Distributed Directory Search Application
• System Architecture
• Aggregation algorithm
• Future Work

4
P2P Overlay

• Basic objective
• Provide connectivity between peers
• Provide an API to the application for
• Exposing the overlay structure
• Providing useful communication primitives, e.g.
  flooding!
• Code-named SRIRAM
• Scalable Resilient Infrastructure using
  Replicated Autonomic Meshes

5
Overlay subsystem structure

• Overlay structure Tree
• Avoids loops without maintaining state
• But, not robust!
• Nodes with higher resources up in the tree
• Rank(child) gt Rank(parent)
• Semi-distributed construction
• Peers are too volatile
• Use some persistent infrastructure
• Provided by P2P service provider

6
Overlay structure (contd.)

• Root servers
• Always available
• Thickly connected
• Hint servers
• super-nodes
• Measure resources for incoming nodes
• Assign ranks
• Give hints on where to join

7
Overlay dynamics Illustrated
c,b
7
Attach-request
8
API

• SRIRAM provides the following facilities for the
  application
• Flood
• Get-parent
• Get-neighbours
• Sendto
• Sendto-neighbours
• Dumb applications can use the Flood primitive
• Smarter apps can use others for app-level routing

9
Distributed Directory SearchApplication

• Objective
• Connect directories in a P2P fashion
• Provide seamless access via standard protocols
• Viz., LDAP and DSML
• Utilize SRIRAM overlay for providing connectivity
• Perform application-level routing for efficiency

10
System Architecture
SRIRAM
DSML request
Client
11
Application-level routing

• Flooding for search requests is obviously
  sub-optimal
• Idea
• Utilize LDAPs semantics
• Records in LDAP are hierarchically arranged
• Aggregate records in the physical sub-tree and
  announce to the parent

12
Aggregation Scenario Example
rcseattle, oumicrosoft, cus
Overlay Links
Application Nodes
rcalmaden, ouibm, cus
rccambridge, oumicrosoft, cuk
rcwatson, ouibm, cus
rchawthorne, ouibm, cus
13
Conclusions and Future Work

• System building exercise
• Learnt some lessons
• JAVA, although really useful for preventing bugs,
  sucks for implementing protocols
• Threads are a pain! Non-blocking I/O is the way
  to go!
• JAVA serialization is heavy-weight
• Future work
• Deployment and experimentation for validating
  tree construction and aggregation algorithms
• Performance tuning ?