ChordNet: A Chord-based self-organizing super-peer network Dennis - - PDF document

University of Kaiserslautern Department of Computer Science Integrated Communication Systems ICSY http://www.icsy.de

ChordNet: A Chord-based self-organizing super-peer network

Dennis Schwerdel, Matthias Priebe, Paul Müller

Dennis Schwerdel

• Introduction
• Overlay structure
• Improvements

Outline

3 Dennis Schwerdel, University of Kaiserslautern

Introduction

Peer to peer overlay network Based on Chord DHT

Inherits basic structure Lots of improvements

General purpose

Not only for searching/locating content Also for transfering content

4 Dennis Schwerdel, University of Kaiserslautern

Chord

Peer to peer overlay

For storing key/value pairs (DHT)

All peers arranged in a ring sorted by IDs

Connections to predecessor and successort Shortcuts to nodes with ID + 2^n (”Fingers”)

Routing to an ID uses farest finger preceeding

the destination ID

Keys are mapped to IDs using hash functions

Nodes store all key/value pairs for Ids between them

and their successor

5 Dennis Schwerdel, University of Kaiserslautern

Chord: Example

6 Dennis Schwerdel, University of Kaiserslautern

Chord Summary

Efficient message delivery

O(log n) Only unicast, no multicast, no broadcast

Scales well with millions of nodes All nodes must be reachable

Problems with Firewalls/NAT

Does not consider latency

7 Dennis Schwerdel, University of Kaiserslautern

ChordNet Structure

Separation: Super-Peers/Edge-

Peers

Super-Peer

Reachable Inside the Chord ring Has list of its edge-peers

Edge-Peer

Behind Firewall/NAT, not reachable Connected to preceding and

succeeding super-peer

Communicates through its super-

peers

8 Dennis Schwerdel, University of Kaiserslautern

ChordNet routing

Only considering super-peers d Fingers in both directions

Finger i to nearest node to (ID2^(i-1)) mod N Successor is Finger 1, Predecessor is Finger -1 Only slightly increases connection count

Routing in both directions possible

Routing can overshoot

When fingers are optimal

Average case: log(n)/3 hops (33% reduction) Worst case: log(n)/2 hops (50% reduction)

9 Dennis Schwerdel, University of Kaiserslautern

Multicast/Broadcast

Multicast destination = ID list Broadcast destination = ID range Routing

split list/range at each hop when needed Global broadcast has n-1 messages

10 Dennis Schwerdel, University of Kaiserslautern

Routing improvements

Chord: Routing only based on IDs

Routing will take expensive hops because of ID gain

Better: Calculate routing gain (PRS)

Latency can measured on connections Formula: gain = (old-dist – new-dist) / latency-costs Even better: gain = (1/new-dist – 1/old-dist) / latency-costs

Chord: Decision is made by looking at own fingers Better: Look at finger tables of finger peers

2-Hop greedy routing (NoN) Additional messages needed for finger table exchange

Both improvements can be combined

11 Dennis Schwerdel, University of Kaiserslautern

Routing improvement impact

12 Dennis Schwerdel, University of Kaiserslautern

Maintenance method

Chord searches for fingers with routed requests Better: exchange finger-table with peers

• Needed for NoN rounting anyway

Allows for quick start

Combine predecessor and successor finger tables

13 Dennis Schwerdel, University of Kaiserslautern

Shortcut connections

Problem: multiple hops are inefficient for big

data transfers

• DHTs have no data transfers, new problem
• Traffic influences latencies, automatic load

balancing with PRS

Idea: establish shortcut connections

Nodes detect high traffic routes using a traffic-

matrix

When HTR is detected, notification is sent to

both peers

Peers establish shortcut connection Shortcut connections are treated as fingers

Result: HTR path length reduces

automatically

HTR peers are connected directly after a short

while

14 Dennis Schwerdel, University of Kaiserslautern

Shortcut impact

15 Dennis Schwerdel, University of Kaiserslautern

ChordNet status

Protocol specification Reference implementation in Java

Able to run in simulation mode

Addition features (work in progress)

Publish/Subscribe API MessageQueue API Datagram API TCP-like API

• !"#

$%&%'

• ()

*"#+!,% -.!'$.%" /) *"#+!,% -.!'$ !'% 0) (123$3 ) ()44111