1. 1 Slides from Richard Yang with minor modification Peer-to-Peer Systems: DHT and Swarming

2. 2 Recap: Objectives of P2P r Share the resources (storage and bandwidth) of individual clients to improve scalability/robustness r Find clients with resources! Internet

3. Recap: The Lookup Problem Internet N1N1 N2N2 N3N3 N6N6 N5N5 N4N4 Publisher Key=“title” Value=data… Client Lookup(“title”) ? find where a particular document is stored

4. Recap: The Lookup Problem r Napster (central query server) r Gnutella (decentralized, flooding) r Freenet (search by routing) 4

5. 5 Recap: Kleinberg’s Result on Distributed Search r Question: how many long distance links to maintain so that distributed (greedy) search is effective? r Assume that the probability of a long link is some (  ) inverse-power of the number of lattice steps r Distributed algorithm exists only when probability is proportional to (lattice steps) -d, where d is the dimension of the space

6. 6 Recap: Distributed Search r In other words, a node connects to roughly the same number of nodes in each region A1, A2, A4, A8, where A1 is the set of nodes who are one lattice step away, A2 is those two steps away, …

7. 7 DHT: API

8. 8

9. Key Issues in Understanding a DHT Design r How does the design map keys to internal representation (typically a metric space)? r Which space is a node responsible? r How are the nodes linked? 9

10. 10 Outline  Admin. and review  P2P  the lookup problem  Napster (central query server; distributed data server)  Gnutella (decentralized, flooding)  Freenet (search by routing)  Content Addressable Network

11. 11 CAN r Abstraction m map a key to a “point” in a multi-dimensional Cartesian space m a node “owns” a zone in the overall space m route from one “point” to another

12. 12 CAN Example: Two Dimensional Space r Space divided among nodes r Each node covers either a square or a rectangular area of ratios 1:2 or 2:1 1

13. 13 CAN Example: Two Dimensional Space r Space divided among nodes r Each node covers either a square or a rectangular area of ratios 1:2 or 2:1 1 2

14. 14 CAN Example: Two Dimensional Space r Space divided among nodes r Each node covers either a square or a rectangular area of ratios 1:2 or 2:1 1 2 3

15. 15 CAN Example: Two Dimensional Space r Space divided among nodes r Each node covers either a square or a rectangular area of ratios 1:2 or 2:1 1 2 3 4

16. 16 CAN Example: Two Dimensional Space r Space divided among nodes r Each node covers either a square or a rectangular area of ratios 1:2 or 2:1

17. 17 CAN Insert: Example (1) node I::insert(K,V) I

18. 18 CAN Insert: Example (2) node I::insert(K,V) (1) a = h x (K) b = h y (K) I x = a y = b Example: Key=“Matrix3” h(Key)=60

19. 19 CAN Insert: Example (3) node I::insert(K,V) (1) a = h x (K) b = h y (K) (2) route(K,V) -> (a,b) I x = a y = b

20. 20 CAN Insert: Routing r A node maintains state only for its immediate neighboring nodes r Forward to neighbor which is closest to the target point m a type of greedy, local routing scheme

21. 21 CAN Insert: Example (4) node I::insert(K,V) (1) a = h x (K) b = h y (K) (2) route(K,V) -> (a,b) (3) (K,V) is stored at (a,b) I x = a y = b

22. 22 CAN Retrieve: Example node J::retrieve(K) J

23. 23 CAN Retrieve: Example node J::retrieve(K) (1) a = h x (K) b = h y (K) (2) route “retrieve(K)” to (a,b) J x = a y = b

24. 24 CAN Insert: Join (1) 1) Discover some node “J” already in CAN J 2) pick a random point (p,q) in space new node

25. 25 CAN Insert: Join (2) 3) J routes to (p,q), discovers node N J new node N

26. 26 CAN Insert: Join (3) 4) split N’s zone in half… new node owns one half J new node N Inserting a new node affects only a single other node and its immediate neighbors

27. 27 CAN Evaluations r Guarantee to find an item if in the network r Load balancing m hashing achieves some load balancing m overloaded node replicates popular entries at neighbors r Scalability m for a uniform (regularly) partitioned space with n nodes and d dimensions m storage: per node, number of neighbors is 2d m routing average routing path is (dn 1/d )/3 hops (due to Manhattan distance routing, expected hops in each dimension is dimension length * 1/3) a fixed d can scale the network without increasing per-node state

28. 28 Outline  Admin. and review  P2P  the lookup problem  Napster (central query server; distributed data server)  Gnutella (decentralized, flooding)  Freenet (search by routing)  Content addressable networks  Chord (search by routing/consistent hashing)

29. 29 Chord r Space is a ring r Consistent hashing: m bit identifier space for both keys and nodes m key identifier = SHA-1(key), where SHA-1() is a popular hash function, Key=“Matrix3”  ID=60 m node identifier = SHA-1(IP address) IP=“198.10.10.1”  ID=123

30. 30 Chord: Storage using a Ring r A key is stored at its successor: node with next higher or equal ID N32 N10 N123 N90 Circular 7-bit ID Space K11, K20 K125, K5, K10 K60 K101 IP=“198.10.10.1” Key=“Matrix 3” N55

31. 31 How to Search: One Extreme r Every node knows of every other node r Routing tables are large O(N) r Lookups are fast O(1)

32. 32 How to Search: the Other Extreme r Every node knows its successor in the ring r Routing tables are small O(1) r Lookups are slow O(N)

33. 33 Chord Solution: “finger tables” r Node K knows the node that is maintaining K + 2 i, where K is mapped id of current node m increase distance exponentially N80 K+64 K+32 K+16 K+8 K+4 K+2 K+1

34. 34 Joining the Ring r use a contact node to obtain info r transfer keys from successor node to new node r updating fingers of existing nodes

35. DHT: Chord Node Join r Assume an identifier space [0..8] r Node n1 joins 0 1 2 3 4 5 6 7 i id+2 i succ 0 2 1 1 3 1 2 5 1 Succ. Table

36. DHT: Chord Node Join r Node n2 joins 0 1 2 3 4 5 6 7 i id+2 i succ 0 2 2 1 3 1 2 5 1 Succ. Table i id+2 i succ 0 3 1 1 4 1 2 6 1 Succ. Table

37. DHT: Chord Node Join r Node n6 joins 0 1 2 3 4 5 6 7 i id+2 i succ 0 2 2 1 3 6 2 5 6 Succ. Table i id+2 i succ 0 3 6 1 4 6 2 6 6 Succ. Table i id+2 i succ 0 7 1 1 0 1 2 2 2 Succ. Table

38. DHT: Chord Node Join r Node n0 starts join 0 1 2 3 4 5 6 7 i id+2 i succ 0 2 2 1 3 6 2 5 6 Succ. Table i id+2 i succ 0 3 6 1 4 6 2 6 6 Succ. Table i id+2 i succ 0 7 1 1 0 1 2 2 2 Succ. Table

39. DHT: Chord Node Join r After Nodes n0 joins 0 1 2 3 4 5 6 7 i id+2 i succ 0 2 2 1 3 6 2 5 6 Succ. Table i id+2 i succ 0 3 6 1 4 6 2 6 6 Succ. Table i id+2 i succ 0 1 1 1 2 2 2 4 6 Succ. Table i id+2 i succ 0 7 0 1 0 0 2 2 2 Succ. Table

40. DHT: Chord Insert Items r Nodes: n1, n2, n0, n6 r Items: f7, f1 0 1 2 3 4 5 6 7 i id+2 i succ 0 2 2 1 3 6 2 5 6 Succ. Table i id+2 i succ 0 3 6 1 4 6 2 6 6 Succ. Table i id+2 i succ 0 1 1 1 2 2 2 4 0 Succ. Table Items 17 i id+2 i succ 0 7 0 1 0 0 2 2 2 Succ. Table

41. 7 DHT: Chord Routing r Upon receiving a query for item id, a node: r checks whether stores the item locally r if not, forwards the query to the largest node in its successor table that does not exceed id 0 1 2 3 4 5 6 7 i id+2 i succ 0 2 2 1 3 6 2 5 6 Succ. Table i id+2 i succ 0 3 6 1 4 6 2 6 6 Succ. Table i id+2 i succ 0 1 1 1 2 2 2 4 0 Succ. Table Items 1 i id+2 i succ 0 7 0 1 0 0 2 2 2 Succ. Table query(7)

42. 42 Chord/CAN Summary r Each node “owns” some portion of the key-space m in CAN, it is a multi-dimensional “zone” m in Chord, it is the key-id-space between two nodes in 1-D ring r Files and nodes are assigned random locations in key-space m provides some load balancing probabilistically equal division of keys to nodes r Routing/search is local (distributed) and greedy m node X does not know of a path to a key Z m but if it appears that node Y is the closest to Z among all of the nodes known to X m so route to Y

43. 43 There are other DHT algorithms r Kadmelia r Tapestry (Zhao et al) –Keys interpreted as a sequence of digits –Incremental suffix routing »Source to target route is accomplished by correcting one digit at a time »For instance: (to route from 0312  1643) »0312  2173  3243  2643  1643 –Each node has a routing table r Skip Graphs (Aspnes and Shah)

44. 44 Summary: DHT r Underlying metric space. r Nodes embedded in metric space r Location determined by key r Hashing to balance load r Greedy routing r Typically m O(log n) space at each node m O(log n) routing time

45. Summary: the Lookup Problem  Unstructured P2P design  Napster (central query server)  Gnutella (decentralized, flooding)  Freenet (search by routing) r Structured P2P design (search by routing) m Chord (a ring) m CAN (zones) 45

46. 46 Outline  Recap  P2P  the lookup problem  Napster (central query server; distributed data server)  Gnutella (decentralized, flooding)  Freenet (search by routing)  Content Addressable Network (virtual zones)  Chord (search by routing on a virtual ring)  the scalability problem

47. An Upper Bound on Scalability r Assume m need to achieve same rate to all clients m only uplinks can be bottlenecks r What is an upper bound on scalability? 47 server C0C0 client 1 client 2 client 3 client n C1C1 C2C2 C3C3 CnCn

48. The Scalability Problem  Maximum throughput R = min{C 0, (C 0 +  C i )/n}  The bound is theoretically approachable 48 server C0C0 client 1 client 2 client 3 client n C1C1 C2C2 C3C3 CnCn

49. Theoretical Capacity: upload is bottleneck  Assume c 0 > ( C 0 +  C i )/n r Tree i: server  client i: c i /(n-1) client i  other n-1 clients r Tree 0: server has remaining c m = c0 – (c1 + c2 + … cn)/(n-1) send to client i: cm/n 49 C0C0 C1C1 C2C2 CiCi CnCn c0c0 cici c1c1 c2c2 cncn c i /(n-1) c m /n R = min{C 0, (C 0 +  C i )/n}

50. Why not Building the Trees? 50 servers C0C0 client 1 client 2 client 3 client n C1C1 C2C2 C3C3 CnCn  Clients come and go (churn): maintaining the trees is too expensive

51. Key Design Issues r Robustness m Resistant to churn and failures r Efficiency m A client has content that others need; otherwise, its upload capacity may not be utilized r Incentive: clients are willing to upload m 70% of Gnutella users share no files, m nearly 50% of all responses are returned by the top 1% of sharing hosts r Lookup problem 51 servers C0C0 client 1 client 2 client 3 client n C1C1 C2C2 C3C3 CnCn

52. Discussion: How to handle the issues? r Robustness r Efficiency r Incentive 52 servers/ seeds C0C0 client 1 client 2 client 3 client n C1C1 C2C2 C3C3 CnCn

53. 53 Outline  Recap  P2P  the lookup problem  the scalability problem  BitTorrent

54. BitTorrent r A P2P file sharing protocol r Created by Bram Cohen in 2004 r A peer can download pieces concurrently from multiple locations 54

55. 55 File Organization Piece 256KB Block 16KB File 42 1 3 Incomplete Piece Piece: unit of information exchange among peers Block: unit of download

56. 56 Outline  Recap  P2P  the lookup problem  the scalability problem  BitTorrent  Lookup

57. BitTorrent r Mostly tracker based r Tracker-less mode; based on the Kademlia DHT 57

58. 58 BitTorrent: Initialization webserver user HTTP GET MYFILE.torrent http://mytracker.com:6969/ S3F5YHG6FEB FG5467HGF367 F456JI9N5FF4E … MYFILE.torrent

59. Metadata File Structure r Meta info contains information necessary to contact the tracker and describes the files in the torrent m announce URL of tracker m file name m file length m piece length (typically 256KB) m SHA-1 hashes of pieces for verification m also creation date, comment, creator, …

60. 60 Tracker Protocol tracker webserver user “register” ID1 169.237.234.1:6881 ID2 190.50.34.6:5692 ID3 34.275.89.143:4545 … ID50 231.456.31.95:6882 list of peers Peer 40 Peer 2 Peer 1 …

61. Tracker Protocol r Communicates with clients via HTTP/HTTPS r Client GET request m info_hash: uniquely identifies the file m peer_id: chosen by and uniquely identifies the client m client IP and port m numwant: how many peers to return (defaults to 50) m stats: e.g., bytes uploaded, downloaded r Tracker GET response m interval: how often to contact the tracker m list of peers, containing peer id, IP and port m stats

62. 62 Outline  Recap  P2P  the lookup problem  the scalability problem  BitTorrent  Lookup  Robustness

63. Robustness r A swarming protocol m Peers exchange info about other peers in the system m Peers exchange piece availability and request blocks from peers 63

64. 64 Peer Protocol (Over TCP) Local PeerRemote Peer ID/Infohash Handshake BitField 1001

65. Peer Protocol r Unchoke: indicate if a allows b to download r Interest/request: indicate which block to send from b to a 65 requests/ interests

66. Optional Slides 66

67. 67 Skip List