PEER-TO-PEER NETWORKS

The contents of this presentation is mostly taken from the course slides of Dr. Chunming Qiao, University Of Buffalo

2

WHAT IS P2P SYSTEMS? Clay Shirkey:

P2P refers to applications that take advantage of resources (storage, cycles, content, human presence) available at the edges of the internet

The “litmus test:” Does it allow for variable connectivity and temporary network addresses? Does it give the nodes at the edges of the network significant autonomy?

P2P Working Group (A Standardization Effort):

P2P computing is: The sharing of computer resources and services by direct exchange

between systems. Peer-to-peer computing takes advantage of existing computing power

and networking connectivity, allowing economical clients to leverage their collective power to benefit the entire enterprise.

3

WHAT IS P2P SYSTEMS?

Multiple sites (at edge) Distributed resources Sites are autonomous (different owners) Sites are both clients and servers (“servent”) Sites have equal functionality

4

P2P BENEFITS

Efficient use of resources Scalability:

Consumers of resources also donate resources Aggregate resources grow naturally with utilization

Reliability Replicas Geographic distribution No single point of failure

Ease of administration Nodes self organize No need to deploy servers to satisfy demand Built-in fault tolerance, replication, and load balancing

5

NAPSTER

was used primarily for file sharing NOT a pure P2P network=> hybrid system Ways of action:

Client sends server the query, server ask everyone and responds to client

Client gets list of clients from serverAll Clients send ID’s of the data they hold to the server

and when client asks for data, server responds with specific addresses

peer downloads directly from other peer(s)

6

NAPSTER

Further services:Chat program, instant messaging service,

tracking program,… Centralized system

Single point of failure => limited fault toleranceLimited scalability (server farms with load

balancing) Query is fast and upper bound for duration

can be given

7

NAPSTER

central DB6

5

1 2

4

3

1. Query2. Response

3. DownloadRequest

4. File

Peer

8

GNUTELLA

pure peer-to-peer very simple protocol no routing "intelligence" Constrained broadcast

Life-time of packets limited by TTL (typically set to 7) Packets have unique ids to detect loops

9

GNUTELLA - PING/PONG

1 52

4

3

6

7

8

Ping 1

Ping 1

Ping 1

Ping 1

Ping 1

Ping 1

Ping 1Known Hosts:2

3,4,5

6,7,8

Pong 2

Pong 4

Pong 3

Pong 5Pong 3,4,5

Pong 6,7,8 Pong 6

Pong 7

Pong 8

Pong 6,7,8

Query/Response analogous

10

FREE RIDING

File sharing networks rely on users sharing data

Two types of free ridingDownloading but not sharing any dataNot sharing any interesting data

On Gnutella15% of users contribute 94% of content63% of users never responded to a query

Didn’t have “interesting” data

11

GNUTELLA:SUMMARY

Hit rates are high High fault tolerance Adopts well and dynamically to changing peer

populations High network traffic No estimates on duration of queries No probability for successful queries Topology is unknown => algorithm cannot exploit it Free riding is a problem

A significant portion of Gnutella peers are free riders Free riders are distributed evenly across domains Often hosts share files nobody is interested in

12

GNUTELLA DISCUSSION

Search types: Any possible string comparison

Scalability Search very poor with respect to number of messages Probably search time O(logn) due to small world property Updates excellent: nothing to do Routing information: low cost

Robustness High, since many paths are explored

Autonomy: Storage: no restriction, peers store the keys of their files Routing: peers are target of all kind of requests

Global knowledge None required

13

IMESH, KAZAA

Hybrid of centralized Napster and decentralized Gnutella

Super-peers act as local search hubs Each super-peer is similar to a

Napster server for a small portion of the network

Super-peers are automatically chosen by the system based on their capacities (storage, bandwidth, etc.) and availability (connection time)

Users upload their list of files to a super-peer

Super-peers periodically exchange file lists

Queries are sent to a super-peer for files of interest

14

STRUCTURED OVERLAY NETWORKS / DHTS

Keys of ValuesKeys of Values

Keys of NodesSet of Nodes

…

Chord, Pastry, Tapestry, CAN, Kademlia, P-Grid, Viceroy

Node IdentifierValue Identifier

Hashing

Hashing

Common Identifier Space

ConnectThe nodesSmartly

15

THE PRINCIPLE OF DISTRIBUTED HASH TABLES A dynamic distribution of a hash table onto a set of cooperating

nodesKey Value

1 Algorithms

9 Routing

11 DS

12Peer-to-Peer

21 Networks

22 Grids

• Basic service: lookup operation • Key resolution from any node

• Each node has a routing table • Pointers to some other nodes• Typically, a constant or a logarithmic number of pointers

node A

node D

node B

node C

→Node D : lookup(9)

16

DHT DESIRABLE PROPERTIES

Keys mapped evenly to all nodes in the network

Each node maintains information about only a few other nodes

Messages can be routed to a node efficiently

Node arrival/departures only affect a few nodes

17

CHORD [MIT]

consistent hashing (SHA-1) assigns each node and object an m-bit ID

IDs are ordered in an ID circle ranging from 0 – (2m-1).

New nodes assume slots in ID circle according to their ID

Key k is assigned to first node whose ID ≥ k successor(k)

18

CONSISTENT HASHING - SUCCESSOR NODES

6

1

2

6

0

4

26

5

1

3

7

2identifier

circle

identifier

node

X key

successor(1) = 1

successor(2) = 3successor(6) = 0

19

CONSISTENT HASHING – JOİN AND DEPARTURE

When a node n joins the network, certain keys previously assigned to n’s successor now become assigned to n.

When node n leaves the network, all of its assigned keys are reassigned to n’s successor.

20

CONSISTENT HASHING – NODE JOİN

0

4

26

5

1

3

7

keys1

keys2

keys

keys

7

5

21

CONSISTENT HASHING – NODE DEP.

0

4

26

5

1

3

7

keys1

keys2

keys

keys6

7

22

SCALABLE KEY LOCATİON – FİNGER TABLES

To accelerate lookups, Chord maintains additional routing information.

This additional information is not essential for correctness, which is achieved as long as each node knows its correct successor.

Each node n’ maintains a routing table with up to m entries (which is in fact the number of bits in identifiers), called finger table.

The ith entry in the table at node n contains the identity of the first node s that succeeds n by at least 2i-1 on the identifier circle.

s = successor(n+2i-1). s is called the ith finger of node n, denoted by n.finger(i)

23

SCALABLE KEY LOCATİON – FİNGER TABLES

0

4

26

5

1

3

7

124

130

finger tablestart succ.

keys1

235

330

finger tablestart succ.

keys2

457

000

finger tablestart succ.

keys6

0+20

0+21

0+22

For.

1+20

1+21

1+22

For.

3+20

3+21

3+22

For.

24

CHORD KEY LOCATION

Lookup in finger table the furthest node that precedes key

-> O(log n) hops

25

NODE JOİNS AND STABİLİZATİONS The most important thing is the successor pointer. If the successor pointer is ensured to be up to date,

which is sufficient to guarantee correctness of lookups, then finger table can always be verified.

Each node runs a “stabilization” protocol periodically in the background to update successor pointer and finger table.

26

NODE JOİNS AND STABİLİZATİONS

“Stabilization” protocol contains 6 functions:create() join()stabilize()notify() fix_fingers()check_predecessor()

When node n first starts, it calls n.join(n’), where n’ is any known Chord node.

The join() function asks n’ to find the immediate successor of n.

27

NODE JOİNS – STABİLİZE()

Each time node n runs stabilize(), it asks its successor for the it’s predecessor p, and decides whether p should be n’s successor instead.

stabilize() notifies node n’s successor of n’s existence, giving the successor the chance to change its predecessor to n.

The successor does this only if it knows of no closer predecessor than n.

28

NODE JOINS – JOİN AND STABILIZATION

np

su

cc(n

p)

= n

s

ns

n

pre

d(n

s)

= n

p

n joins predecessor = nil n acquires ns as successor via some n’

n runs stabilize n notifies ns being the new

predecessor ns acquires n as its predecessor

np runs stabilize

np asks ns for its predecessor (now n)

np acquires n as its successor

np notifies n

n will acquire np as its predecessor

all predecessor and successor pointers are now correct

fingers still need to be fixed, but old fingers will still work

nil

pre

d(n

s)

= n

su

cc(n

p)

= n

29

NODE FAILURES Key step in failure recovery is maintaining correct successor

pointers

To help achieve this, each node maintains a successor-list of its r nearest successors on the ring

If node n notices that its successor has failed, it replaces it with the first live entry in the list

Successor lists are stabilized as follows: node n reconciles its list with its successor s by copying s’s

successor list, removing its last entry, and prepending s to it.

If node n notices that its successor has failed, it replaces it with the first live entry in its successor list and reconciles its successor list with its new successor.

30

CAN - MOTIVATION

Primary scalability issue in peer-to-peer systems is the indexing scheme used to locate the peer containing the desired content Content-Addressable Network (CAN) is a scalable

indexing mechanism Also a central issue in large scale storage management

systems

31

CAN - BASIC DESIGN

Basic Idea:

A virtual d-dimensional Coordinate space

Each node owns a Zone in the virtual space

Data is stored as (key, value) pair

Hash(key) --> a point P in the virtual space

(key, value) pair is stored on the node within whose Zone the point P locates

32

AN EXAMPLE OF CAN

1

33

AN EXAMPLE OF CAN (CONT)

1 2

34

AN EXAMPLE OF CAN (CONT)

1

2

3

35

AN EXAMPLE OF CAN (CONT)

1

2

3

4

36

AN EXAMPLE OF CAN (CONT)

37

AN EXAMPLE OF CAN (CONT)

I

38

AN EXAMPLE OF CAN (CONT)

node I::insert(K,V)

I

39

AN EXAMPLE OF CAN (CONT)

(1) a = hx(K)

x = a

node I::insert(K,V)

I

40

AN EXAMPLE OF CAN (CONT)

(1) a = hx(K)

b = hy(K)

x = a

y = b

node I::insert(K,V)

I

41

AN EXAMPLE OF CAN (CONT)

(1) a = hx(K)

b = hy(K)

(2) route(K,V) -> (a,b)

node I::insert(K,V)

I

42

An

h L

e +

Tu

on

g N

gu

yen

AN EXAMPLE OF CAN (CONT)

Oct. 4

(2) route(K,V) -> (a,b)

(3) (a,b) stores (K,V)

(K,V)

node I::insert(K,V)

I(1) a = hx(K)

b = hy(K)

43

AN EXAMPLE OF CAN (CONT)

(2) route “retrieve(K)” to (a,b) (K,V)

(1) a = hx(K)

b = hy(K)

node J::retrieve(K)

J

44

IMPORTANT THING….

Important note:

Data stored in CAN is addressable by name (ie key) not by location (ie IP address.)

45

CONCLUSION ABOUT CAN Support basic hash table operations on key-value

pairs (K,V): insert, search, delete CAN is composed of individual nodes Each node stores a chunk (zone) of the hash table

A subset of the (K,V) pairs in the table Each node stores state information about neighbor

zones

46

REFERENCE Kien A. Hua, Duc A. Tran, and Tai Do, “ZIGZAG: An Efficient Peer-to-Peer

Scheme for Media Streaming”, INFOCOM 2003. RATNASAMY, S., FRANCIS, P., HANDLEY, M., KARP, R., AND SHENKER,

S. A scalable content-addressable network. In Proc. ACM SIGCOMM (San Diego, CA, August 2001)

Mayank Bawa, Brian F. Cooper, Arturo Crespo, Neil Daswani, Prasanna Ganesan, Hector Garcia-Molina, Sepandar Kamvar, Sergio Marti, Mario Schlosser, Qi Sun, Patrick Vinograd, Beverly Yang” Peer-to-Peer Research at Stanford”

Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan, Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications, ACM SIGCOMM 2001

Prasanna Ganesan, Qixiang Sun, and Hector Garcia-Molina, YAPPERS: A Peer-to-Peer Lookup Service over Arbitrary Topology, INFOCOM 2003.