a hybrid topology architecture for p2p systems l.
Skip this Video
Download Presentation
A Hybrid Topology Architecture for P2P Systems

Loading in 2 Seconds...

play fullscreen
1 / 25

A Hybrid Topology Architecture for P2P Systems - PowerPoint PPT Presentation

  • Uploaded on

A Hybrid Topology Architecture for P2P Systems. Ling Liu lingliu@cc.gatech.edu. Aameek Singh aameek@cc.gatech.edu. College of Computing Georgia Institute of Technology. Road Ahead …. Introduction Structured and Unstructured Overlays Routing and Lookups, Anonymity, Data Placement

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'A Hybrid Topology Architecture for P2P Systems' - wyatt

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a hybrid topology architecture for p2p systems

A Hybrid Topology Architecture for P2P Systems

Ling Liu


Aameek Singh


College of Computing

Georgia Institute of Technology

ICCCN 2004

road ahead
Road Ahead …
  • Introduction
    • Structured and Unstructured Overlays
    • Routing and Lookups, Anonymity, Data Placement
  • Hybrid Topology Design
  • Performance Analysis
  • Conclusions and Future Work
  • Questions?

ICCCN 2004

  • Advent of Peer-to-Peer (P2P) Systems
    • Seti@Home → Napster → Gnutella → Chord/Pastry
  • Overlay Networks
    • Data sharing
    • Data dissemination e.g. Application-level Multicast
    • Security
    • Voice over IP (VoIP)
  • Distinguishing Features
    • Overlay Topologies
    • Routing and Lookup
    • Level of Anonymity

ICCCN 2004

our system
Our System
  • Decentralized Mutually Anonymous System
  • Maintains all “nice” DHT properties
    • Scalable & guaranteed lookup
  • Add-on unstructured topologies (Clouds)
    • Protect service requester and service provider
    • Use the underlying DHT routing in-between
  • To follow:
    • Identification of Topology Design Features
    • Design and Performance Analysis

ICCCN 2004

what gives us anonymity
What gives us anonymity?
  • Iterative Chord
    • Peers only give next-hop address
    • Querying peer revealed!
    • Also, Replying peer revealed to querying peer!
  • Recursive Chord
    • Follows Message Forwarding
    • Looks like Gnutella
    • Anonymous?


ICCCN 2004

clouds over dht
Clouds over DHT

DHT- Query Items mapped to Peers- Combine information from routing tables to identify the service provider

Our System- Query Items map to Clouds- Local Knowledge in clouds provides anonymity

ICCCN 2004

  • Each cloud has a unique string name
  • Rendezvous Node
    • Entry Points
    • Node responsible for cloudname
    • There always exists one RN
      • Dynamics Handling
  • Issues
    • Reliability
    • Initial anonymity

ICCCN 2004

  • Multi-phase mix
  • Gnutella like Routing in Clouds
    • Message Forwarding and Broadcasts
    • Provides Privacy
  • DHT routing between various clouds
    • For Guaranteed & Scalable Lookup
  • Appropriate linking of clouds to services
  • Limit size of clouds to prevent exponential costs

ICCCN 2004

mapping services to clouds
Mapping Services to Clouds
  • Semantic
    • Clouds where services offered are semantically linked
    • E.g. music sharing system – clouds containing files of one artist
  • Discovery of Service
    • Availability of a discovery of service mechanism
    • E.g. centralized directory
  • Dynamic
    • Infeasible to have a discovery mechanism
    • High performance applications with peers contributing resources
    • E.g. decentralized web crawling

ICCCN 2004

r rings motivation
R-Rings - Motivation
  • Membership based mapping?
  • Peers are too dynamic!
  • Mapping based on clouds?
  • Cloudname is static

ICCCN 2004

r rings
  • Take a RN from each cloud and create new DHT ring
  • Always one representative per cloud at the same position
  • How to make its position static?
    • Each RN occupies position hquery(cloudname)

ICCCN 2004

routing protocol
Routing Protocol
  • Three phases
    • Query forwarding in QueryCloud
    • Ring Phase: DHT lookup (Main/R-Ring)
    • Reply cloud broadcast
  • Crossover peers
    • Cross over from the first phase to the ring-phase
    • Should be unique
    • Equal distribution of load
  • Random walks

Querying Peer Anonymity

Scalable Routing

Replying Peer Anonymity

ICCCN 2004

routing protocol14
Routing Protocol

Query with TTL 4

Get First-Hop Address

DHT Phase (Query R-Ring)

Initiate Reply

Broadcast Query in ReplyCloud

ICCCN 2004

limiting size of clouds
Limiting Size of Clouds
  • Prevent exponential costs
  • System Parameters
    • R-diameter: Maximum distance from a RN (length dim)
    • Degree (m): Maximum number of neighbors (breadth)
  • Enforcing system parameters
    • In every ping cycle, peers exchange their distance vectors
    • Recursively evaluation of distance
    • Converges to the actual values
    • Temporary aberrations tolerated

ICCCN 2004

  • Add-on unstructured topologies – Clouds
  • Map services to clouds
  • Routing
    • Random walk in query cloud
    • Crossover onto the ring
    • Broadcast in response cloud
  • Limit size of clouds

ICCCN 2004

performance scalability
Performance: Scalability

- System is as scalable as popular DHT based systems in terms of both number of hops and aggregate messages transmitted - The messaging costs are higher because of broadcast in the response cloud

ICCCN 2004

effect of system parameters
Effect of System Parameters



ICCCN 2004

security analysis
Security Analysis
  • Passive-logging Model
    • No online malicious behavior like protocol manipulation
    • Only offline sharing of logs
    • Goal: Identify origin/destination of messages
  • Prevention
    • Only one good edge required
  • Attack
    • Malicious Nodes need to surround the good node
  • Need more – the knowledge of it !

ICCCN 2004

  • How to get the knowledge?
    • Saturate all m slots
    • Distance vectors information
    • Ping/Pong information
  • Best Attack Scenario
  • 1 bad node per good node
  • Requires extensive online manipulation – Not permissible

ICCCN 2004

cloud creation attack
Cloud-creation Attack
  • Malicious nodes start a cloud and join en-masse
  • Effects vary with m
  • Greater m causes more compromises
  • Efficiency of attack decreases as more good nodes enter the cloud
    • Remember - 1 Good Edge

ICCCN 2004

block attack
Block Attack
  • Malicious nodes join in groups, interspersing between good node arrivals
  • Find out intervals from historical analysis
  • Good nodes welcomed by one group of bad nodes and surrounded by another group

ICCCN 2004

  • Group strategy
    • Tough to achieve because bad nodes are indistinguishable
  • Get A Buddy Along
    • Join with a trusted friend and keep one edge with him/her
    • Trust
      • Only not to share logs
      • No privacy information revealed
  • Connect to RNs
  • Connect to peers from distinct domains only

ICCCN 2004

  • Hybrid Topology – best from the unstructured & structured topologies
  • Scalable Routing, Mutual Anonymity, Guaranteed Lookups
  • Data Placement Benefits
  • Security Analysis – Anonymity compromising attacks
  • Securing the whole system – DHT vulnerabilities …

ICCCN 2004



ICCCN 2004