Peer-to-Peer Networking

Credit slides from J. Pang, B. Richardson, I. Stoica

2

Why Study P2P

Huge fraction of traffic on networks today >=50%!

Exciting new applications Next level of resource sharing

Vs. timesharing, client-server E.g. Access 10’s-100’s of TB at low cost.

3

Share of Internet Traffic

4

Number of Users

Others includeBitTorrent, eDonkey, iMesh,Overnet, Gnutella

BitTorrent (and others) gaining sharefrom FastTrack (Kazaa).

5

What is P2P used for?

Use resources of end-hosts to accomplish a shared task Typically share files Play game Search for patterns in data (Seti@Home)

6

What’s new?

Taking advantage of resources at the edge of the network Fundamental shift in computing capability Increase in absolute bandwidth over WAN

7

Peer to Peer

Systems: Napster Gnutella KaZaA BitTorrent Chord

8

Key issues for P2P systems

Join/leave How do nodes join/leave? Who is allowed?

Search and retrieval How to find content? How are metadata indexes built, stored,

distributed? Content Distribution

Where is content stored? How is it downloaded and retrieved?

9

4 Key Primitives

• Join– How to enter/leave the P2P system?

• Publish– How to advertise a file?

• Search• how to find a file?

• Fetch– how to download a file?

10

Publish and Search

Basic strategies: Centralized (Napster) Flood the query (Gnutella) Route the query(Chord)

Different tradeoffs depending on application Robustness, scalability, legal issues

11

Napster: History

In 1999, S. Fanning launches Napster Peaked at 1.5 million simultaneous

users Jul 2001, Napster shuts down

12

Napster: Overiew

Centralized Database: Join: on startup, client contacts central

server Publish: reports list of files to central

server Search: query the server => return

someone that stores the requested file Fetch: get the file directly from peer

13

Napster: Publish

I have X, Y, and Z!

Publish

insert(X, 123.2.21.23)...

123.2.21.23

14

Napster: Search

Where is file A?

Query Reply

search(A)-->123.2.0.18Fetch

123.2.0.18

15

Napster: Discussion

Pros: Simple Search scope is O(1) Controllable (pro or con?)

Cons: Server maintains O(N) State Server does all processing Single point of failure

16

Gnutella: History

In 2000, J. Frankel and T. Pepper from Nullsoft released Gnutella

Soon many other clients: Bearshare, Morpheus, LimeWire, etc.

In 2001, many protocol enhancements including “ultrapeers”

17

Gnutella: Overview

Query Flooding: Join: on startup, client contacts a few

other nodes; these become its “neighbors”

Publish: no needSearch: ask neighbors, who as their

neighbors, and so on... when/if found, reply to sender.

Fetch: get the file directly from peer

18

I have file A.

I have file A.

Gnutella: Search

Where is file A?

Query

Reply

19

Gnutella: Discussion

Pros: Fully de-centralized Search cost distributed

Cons: Search scope is O(N) Search time is O(???) Nodes leave often, network unstable

20

Aside: Search Time?

21

Aside: All Peers Equal?

56kbps Modem

10Mbps LAN

1.5Mbps DSL

56kbps Modem56kbps Modem

1.5Mbps DSL

1.5Mbps DSL

1.5Mbps DSL

22

Aside: Network Resilience

Partial Topology Random 30% die Targeted 4% die

from Saroiu et al., MMCN 2002

23

KaZaA: History

In 2001, KaZaA created by Dutch company Kazaa BV

Single network called FastTrack used by other clients as well: Morpheus, giFT, etc.

Eventually protocol changed so other clients could no longer talk to it

Most popular file sharing network today with >10 million users (number varies)

24

KaZaA: Overview

“Smart” Query Flooding: Join: on startup, client contacts a

“supernode” ... may at some point become one itself

Publish: send list of files to supernode Search: send query to supernode,

supernodes flood query amongst themselves.

Fetch: get the file directly from peer(s); can fetch simultaneously from multiple peers

25

KaZaA: Network Design

“Super Nodes”

26

KaZaA: File Insert

I have X!

Publish

insert(X, 123.2.21.23)...

123.2.21.23

27

KaZaA: File Search

Where is file A?

Query

search(A)-->123.2.0.18

search(A)-->123.2.22.50

Replies

123.2.0.18

123.2.22.50

28

KaZaA: Discussion

Pros: Tries to take into account node heterogeneity:

• Bandwidth• Host Computational Resources• Host Availability (?)

Rumored to take into account network locality Cons:

Mechanisms easy to circumvent Still no real guarantees on search scope or search time

29

P2P systems

Napster Launched P2P Centralized index

Gnutella: Focus is simple sharing Using simple flooding

Kazaa More intelligent query routing

BitTorrent Focus on Download speed, fairness in sharing

30

BitTorrent: History

In 2002, B. Cohen debuted BitTorrent Key Motivation:

Popularity exhibits temporal locality (Flash Crowds) E.g., Slashdot effect, CNN on 9/11, new movie/game

release Focused on Efficient Fetching, not Searching:

Distribute the same file to all peers Single publisher, multiple downloaders

Has some “real” publishers: Blizzard Entertainment using it to distribute the beta of

their new game

31

BitTorrent: Overview

Swarming: Join: contact centralized “tracker” server,

get a list of peers. Publish: Run a tracker server. Search: Out-of-band. E.g., use Google to

find a tracker for the file you want. Fetch: Download chunks of the file from

your peers. Upload chunks you have to them.

32

33

BitTorrent: Sharing Strategy

Employ “Tit-for-tat” sharing strategy “I’ll share with you if you share with me” Be optimistic: occasionally let freeloaders download

• Otherwise no one would ever start!• Also allows you to discover better peers to download

from when they reciprocate

34

BitTorrent: Summary

Pros: Works reasonably well in practice Gives peers incentive to share resources;

avoids freeloaders Cons:

Central tracker server needed to bootstrap swarm (is this really necessary?)

35

DHT: History

In 2000-2001, academic researchers said “we want to play too!”

Motivation: Frustrated by popularity of all these “half-baked” P2P

apps :) We can do better! (so we said) Guaranteed lookup success for files in system Provable bounds on search time Provable scalability to millions of node

Hot Topic in networking ever since

36

DHT: Overview

Abstraction: a distributed “hash-table” (DHT) data structure: put(id, item); item = get(id);

Implementation: nodes in system form a distributed data structure Can be Ring, Tree, Hypercube, Skip List, Butterfly

Network, ...

37

DHT: Overview (2)

Structured Overlay Routing: Join: On startup, contact a “bootstrap” node and integrate

yourself into the distributed data structure; get a node id Publish: Route publication for file id toward a close node id

along the data structure Search: Route a query for file id toward a close node id.

Data structure guarantees that query will meet the publication.

Fetch:• P2P fetching

Tapestry: a DHT-based P2P system focusing on fault-tolerance

Danfeng (Daphne) Yao

39

A very big picture – P2P networking Observe

Dynamic nature of the computing environment

Network Expansion Require

Robustness, or fault tolerance Scalability Self-administration, or self-organization

40

Goals to achieve in Tapestry

Decentralization Routing uses local data

Efficiency, scalability Robust routing mechanism

Resilient to node failures An easy way to locate objects

41

IDs in Tapestry

NodeID ObjectID IDs are computed using a hash function

The hash function is a system-wide parameter

Use ID for routing Locating an object Finding a node

A node stores its neighbors’ IDs

42

Tapestry routing: 03254598

Suffix-based routing

43

Each object is assigned a root node

Root node: a unique node for object O with the longest matching suffix Root knows where O is

rootId = O

Copy of O

Publish: node S routes a msg <objectID(O), nodeID(S)> to root of O Closest location is stored if exist multiple copies Location query: a msg for O is routed towards O’s root How to choose the root node for an object?

S

44

Surrogate routing: unique mapping without global knowledge

Problem: how to choose a unique root node of an object deterministically

Surrogate routing Choose an object’s root (surrogate) node

such that whose nodeId is the closest to the objectId

Small overhead, but no need of global knowledge

The number of additional hops is small

45

Surrogate example: find the root node for objectId = 6534

2234

1114

2534

6534

object

root

7534

7534

6534 empty

7534

6534 empty…….

46

Tapestry: adaptable, fault-resilient,self-management

Basic routing and location Backpointer list in neighbor map Multiple <objectId(O), nodeId(S)> mappings

are stored More semantic flexibility: selection operator

for choosing returned objects

47

A single Tapestry node

Neighbor MapFor “1732” (Octal)

1234

xxx1

1732

xxx0

xxx3

xxx4

xxx5

xxx6

xxx7

xx02

1732

xx22

xx32

xx42

xx52

xx62

xx72

x032

x132

x232

x332

x432

x532

x632

1732

0732

1732

2732

3732

4732

5732

6732

7732

Object locationPointers<objectId, nodeId>

Hotspot monitor<objId, nodeId, freq>

Object store

48

Fault-tolerant routing: detect, operate, and recover Expected faults

Server outages (high load, hw/sw faults) Link failures (router hw/sw faults) Neighbor table corruption at the server

Detect: TCP timeout, heartbeats to nodes on backpointer list

Operate under faults: backup neighbors Second chance for failed server: probing msgs

49

Fault-tolerant location: avoid single point of failure Multiple roots for each object

rootId = f(objectId + salt) Redundant, but reliable

Storage servers periodically republish location info Cached location info on routers times out New and recovered objects periodically

advertise their location info

50

Dynamic node insertion

Populate new node’s neighbor maps Routing messages to its own nodeId Copy and optimize neighbor maps

Inform relevant nodes of its entries to update neighbor maps

51

Dynamic deletion

Inform relevant nodes using backptrs Or rely on soft-state (stop heartbeats) In general, Tapestry expects small

number of dynamic insertions/deletions

52

Fault handling outline

Design choice Soft state for graceful fault recovery

Soft-state Caches: updated by periodic refreshment msgs, or

purged if receiving no such msgs Faults are expected in Tapestry

Fault-tolerant routing Fault-tolerant location Surrogate routing

53

Tapestry Conclusions

Decentralized location and routing Distributed algorithms for object-root

mapping, node insertion/deletion Fault-handling with redundancy Per node routing table size: bLogb(N)

• N = size of namespace Find object in Logb(n) overlay hops

• n = # of physical nodes