EE 122: Peer-to-Peer Networks

Transcription

1 EE 122: Peer-to-Peer Networks Ion Stoica (and Brighten Godfrey) TAs: Lucian Popa, David Zats and Ganesh Ananthanarayanan (Materials with thanks to Vern Paxson, Jennifer Rexford, and colleagues at UC Berkeley) 1 How Did it Start? A killer application: Naptser (1999) Free music over the Internet Key idea: share the storage and bandwidth of individual (home) users Internet 2 1

2 Model Each user stores a subset of files Each user has access (can download) files from all users in the system E F D A B C 3 Main Challenge Find where a particular file is stored E F D E? A B C 2

3 Other Challenges Scale: up to hundred of thousands or millions of machines Dynamicity: machines can come and go any time 5 Napster Assume a centralized index system that maps files (songs) to machines that are alive How to find a file (song) Query the index system return a machine that stores the required file Ideally this is the closest/least-loaded machine ftp the file Advantages: Simplicity, easy to implement sophisticated search engines on top of the index system Disadvantages: Robustness, scalability (?) 6 3

4 Napster: Example m5 m6 E F E? E E? m5 m1 A m2 B m3 C m D m5 E m6 F m D m1 A m2 B m3 C 7 The Aftermath Recording Industry Association of America (RIAA) Sues Music Startup Napster for $2 Billion December 1999 Napster ordered to remove copyrighted material March 21 Main legal argument: Napster owns the index system, so it is directly responsible for disseminating copyrighted material 8

5 Gnutella (2) Distribute file location Idea: broadcast the request How to find a file? Send request to all neighbors Neighbors recursively multicast the request Eventually a machine that has the file receives the request, and it sends back the answer Advantages: Totally decentralized, highly robust Disadvantages: Not scalable; the entire network can be swamped with requests (to alleviate this problem, each request has a TTL) 9 Gnutella: Example Assume: m1 s neighbors are m2 and m3; m3 s neighbors are m and m5; m5 m6 E F E E? E? m D E? E? m1 A m2 B m3 C 1 5

6 Two-Level Hierarchy Current Gnutella implementation, KaZaa Leaf nodes are connected to a small number of ultrapeers (suppernodes) Query A leaf sends query to its ultrapeers If ultrapeers don t know the answer, they flood the query to other ultrapeers More scalable: Flooding only among ultrapeers Oct 23 Crawl on Gnutella Ultrapeer nodes Leaf nodes 11 Skype (23) Peer-to-peer Internet Telephony Two-level hierarchy like KaZaa Ultrapeers used to route traffic between NATed end-hosts (see next slide) plus a login server to authenticate users ensure that names are unique across network B A login server Messages exchanged to login server Data traffic (Note*: probable protocol; Skype protocol is not published) 12 6

7 BitTorrent (21) Allow fast downloads even when sources have low up-link capacity How does it work? Seed (origin) site storing the file to be downloaded Tracker server maintaining the list of peers in system Split each file into pieces (~ 256 KB each), and each piece into sub-pieces (~ 16 KB each) The loader loads one piece at a time Within one piece, the loader can load up to five subpieces in parallel 13 BitTorrent: Join Procedure 1) Peer contacts tracker responsible for file it wants to download 2) Tracker returns a list of peer (2-5) downloading same file 3) Peer connects to peer in the list Tracker Seed (origin server) join peer list 1 7

8 BitTorrent: Download Algorithm Download consists of three phases: Start: get a piece as soon as possible Select a random piece Middle: spread all pieces as soon as possible Select rarest piece next End: avoid getting stuck with a slow source, when downloading the last sub-pieces Request in parallel the same sub-piece Cancel slowest downloads once a sub-piece has been received (For details see: Minute Break Questions Before We Proceed? 16 8

9 Distributed Hash Tables Problem: Given an ID, map to a host Challenges Scalability: hundreds of thousands or millions of machines Instability Changes in routes, congestion, availability of machines Heterogeneity Latency: 1ms to 1ms Bandwidth: 32Kb/s to 1Mb/s Nodes stay in system from 1s to a year Trust Selfish users Malicious users 17 Content Addressable Network (CAN, 22) Associate to each node and item a unique id in a d-dimensional space Properties Routing table size O(d) Guarantees that a file is found in at most d*n 1/d steps, where n is the total number of nodes 18 9

10 CAN Example: Two Dimensional Space Space divided between nodes All nodes cover the entire space Each node covers either a square or a rectangular area of ratios 1:2 or 2:1 Example: Assume space size (8 x 8) Node n1:(1, 2) first node that joins cover the entire space n CAN Example: Two Dimensional Space Node n2:(, 2) joins space is divided between n1 and n n1 n

11 CAN Example: Two Dimensional Space Node n2:(, 2) joins space is divided between n1 and n n n1 n CAN Example: Two Dimensional Space Nodes n:(5, 5) and n5:(6,6) join n3 n n n1 n

12 CAN Example: Two Dimensional Space Nodes: n1:(1, 2); n2:(,2); n3:(3, 5); n:(5,5);n5:(6,6) 7 Items: f1:(2,3); f2:(5,1); f3:(2,1); f:(7,5); 6 5 n3 n n5 f n1 f1 f3 n2 f CAN Example: Two Dimensional Space Each item is stored by the node who owns its mapping in the space n3 n n5 f n1 f1 f3 n2 f

13 CAN: Query Example Each node knows its neighbors in the d-space 7 Forward query to the neighbor that is closest to the query id 6 5 n3 n n5 f Example: assume n1 queries f n1 f1 f3 n2 f Chord (22) Associate to each node and item a unique id in an uni-dimensional space..2 m -1 Key design decision Decouple correctness from efficiency Properties Routing table size O(log(N)), where N is the total number of nodes Guarantees that a file is found in O(log(N)) steps 26 13

14 Identifier to Node Mapping Example Node 8 maps [5,8] Node 15 maps [9,15] 58 8 Node 2 maps [16, 2] 15 Node maps [59, ] 2 Each node maintains a pointer to its successor Lookup Each node maintains its successor Route packet (ID, data) to the node responsible for ID using successor pointers 58 node= lookup(37)

15 Joining Operation Each node A periodically sends a stabilize() message to its successor B Upon receiving a stabilize() message, node B returns its predecessor B =pred(b) to A by sending a notify(b ) message Upon receiving notify(b ) from B, if B is between A and B, A updates its successor to B otherwise, A doesn t do anything 29 Joining Operation Node with id=5 joins the ring Node 5 needs to know at least one node already in the system succ=nil pred=nil Assume known node is 15 5 succ= pred= succ=58 pred=

16 Joining Operation Node 5: send join(5) to node 15 Node : returns node 58 Node 5 updates its successor to 58 succ=58 succ=nil pred=nil 58 5 succ= pred= 58 join(5) 8 15 succ=58 pred= Joining Operation Node 5: send stabilize() to node 58 Node 58: update predecessor to 5 send notify() back succ=58 pred=nil notify(pred=5) 5 succ=58 pred=35 succ= pred= pred=5 stabilize()

17 Joining Operation (cont d) Node sends a stabilize pred=5 message to its successor, node Node 58 reply with a notify message Node updates its stabilize() successor to 5 succ=58 pred=nil 5 notify(pred=5) succ= 8 15 succ=5 succ=58 pred= Joining Operation (cont d) Node sends a stabilize message to its new successor, node 5 Node 5 sets its predecessor to node succ= pred= succ=58 pred= pred=nil 5 Stabilize() 15 succ=5 pred=

18 Joining Operation (cont d) This completes the joining operation! pred= succ=58 pred= 5 15 succ= Achieving Efficiency: finger tables Finger Table at 8 i ft[i] ( ) mod 2 7 = Say m=7 i m ith entry at peer with id n is first peer with id >= n + 2 (mod 2 ) 36 18

19 Achieving Robustness To improve robustness each node maintains the k (> 1) immediate successors instead of only one successor In the notify() message, node A can send its k-1 successors to its predecessor B Upon receiving notify() message, B can update its successor list by concatenating the successor list received from A with A itself 37 Discussion Query can be implemented Iteratively Recursively Performance: routing in the overlay network can be more expensive than in the underlying network Because usually there is no correlation between node ids and their locality; a query can repeatedly jump from Europe to North America, though both the initiator and the node that store the item are in Europe! Solutions: Tapestry takes care of this implicitly; CAN and Chord maintain multiple copies for each entry in their routing tables and choose the closest in terms of network distance 38 19

20 Conclusions The key challenge of building wide area P2P systems is a scalable and robust directory service Solutions covered in this lecture Naptser: centralized location service Gnutella: gossip-based decentralized location service CAN, Chord, Tapestry, Pastry: intelligent-routing decentralized solution Guarantee correctness Tapestry, Pastry provide more efficient routing, but more complex 39 2