Introduction to Peer-to-Peer Networks

Transcription

1 Introduction to Peer-to-Peer Networks The Story of Peer-to-Peer The Nature of Peer-to-Peer: Generals & Paradigms Unstructured Peer-to-Peer Systems Structured Peer-to-Peer Systems Chord CAN 1 Prof. Dr. Thomas Schmidt

2 A Peer-to-Peer system is a self-organizing system of equal, autonomous entities (peers) which aims for the shared usage of distributed resources in a networked environment avoiding central services. Andy Oram 2 Prof. Dr. Thomas Schmidt

3 The Old Days NetNews (nntp) DNS Usenet since 1979, initially based on UUCP Exchange (replication) of news articles by subscription Group creation/deletion decentralised Distributed delegation of name authorities: file sharing of host tables Name Servers act as peers Hierarchical information space permits exponential growth Systems are manually configured distributed peers 3 Prof. Dr. Thomas Schmidt

4 Distributed Computing Search for Extraterrestrial Intelligence (SETI) Analyse radio signals from space Globally shared computing res. Idea 1995 First version Mio clnt E.g. Screensaver From Anderson et. al.: SETI@home, Comm. ACM, 45 (11), Nov ongoing 4 Prof. Dr. Thomas Schmidt

5 Napster MAY 1999: Disruption of the Internet community First Generation of File sharing: Introduction of Napster Users not only consume and download, but also offer content Users establish a virtual network, entirely independent from physical network and administrative authorities or restrictions Basis: UDP and TCP connections between the peers Napster provides centralised indexing Clients upload their file list to Napster Server Clients query Index Server and receive full provider list Data exchange directly between peers 5 Prof. Dr. Thomas Schmidt

6 Napster December 1999: RIAA files a lawsuit against Napster Inc. March 2000: University of Wisconsin reports 25 % of its IP traffic is Napster traffic February 2001: 2.79 billion files per month exchanged via Napster July 2001: Napster Inc. is convicted Target of the RIAA: the central lookup server of Napster Napster has to stop the operation of the Napster server Napster network breaks down Napster failed (technically & legally) at its single server point. 6 Prof. Dr. Thomas Schmidt

7 Gnutella File sharing fully decentralised Open source software March 2000: Release 0.4 with network flooding Spring 2001: Release 0.6 improved scalability 7 Prof. Dr. Thomas Schmidt

8 Gnutella 0.4 Pure P2P system no central indexing server Operations: 1. Connect to at least one active peer (address received from bootstrap) 2. Explore your neighborhood (PING/PONG) 3. Submit Query with a list of keywords to your neighbors (they forward it) 4. Select best of correct answers (which we receive after a while) 5. Connect to providing host/peer Scaling Problems due to network flooding 8 Prof. Dr. Thomas Schmidt

9 Gnutella 0.4: How Does It Work 9 Prof. Dr. Thomas Schmidt

10 Gnutella 0.6 Hybrid P2P System Introduction of Superpeers Improved scalability: signalling reduced to Superpeers Election mechanism decides which node becomes a Superpeer or a Leafnode (depending on capabilities (storage, processing power) network connection, the uptime of a node, ) Leafnodes announce their shared content to the Superpeer they are connected to Superpeers carry local routing tables 10 Prof. Dr. Thomas Schmidt

11 Gnutella 0.6: How Does It Work From: J. Eberspächer, R. Schollmeier: First and Second Generation Peer-to-Peer Systems, in LNCS Prof. Dr. Thomas Schmidt

12 The Gnutella Network Measurements from May 2002 From: J. Eberspächer, R. Schollmeier: First and Second Generation Peer-to-Peer Systems, in LNCS Prof. Dr. Thomas Schmidt

13 Skype VoIP conferencing system Released 2003 Central login server Hybrid P2P system otherwise Main focuses: Detect users Traverse NAT & Firewalls (STUN) Elects Superpeers according to network connectivity Uses Superpeers as relays 13 Prof. Dr. Thomas Schmidt

14 Impacts of P2P at the Abilene Backbone Unidentified + data_transfers + file_sharing causes 90% of the traffic Unidentified traffic and data_transfers increased significantly Parts of P2P is hidden (port hopping, ) Some P2P applications use port 80 data_transfers Traffic portions in % per week 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Prof. Dr. Thomas Schmidt Unidentified Data_Transfers File_Sharing Core of Internet2 infrastructure, connecting 190 US universities and research centers Possible data transfers Only Signaling Data source:

15 The Nature of P2P P2P Networks overlay network infrastructure Implemented on application layer Overlay Topology forms a virtual signaling network established via TCP connects Peers are content provider +content requestor +router in the overlay network Address: General Unique ID 15 Prof. Dr. Thomas Schmidt

16 P2P & Distributed Systems Paradigm Coordination among equal components Decentralised & self organising Independence of individual peers Scalability over tremendous ranges High dynamic from volatile members Fault resilience against infrastructure & nodes Incentives instead of control 16 Prof. Dr. Thomas Schmidt

17 P2P & Internetworking Paradigm Loose, stateless coupling among peers Serverless & without infrastructural entities Dynamic adaptation to network infrastructure Overcome of NATs or port barriers Client-Server principle reduced to communication programming, not an application paradigm anymore Somewhat Back to the Internet roots : Freedom of information Freedom of scale But: Freedom of Internet infrastructure & regulation 17 Prof. Dr. Thomas Schmidt

18 P2P Application Areas File sharing Media Conferencing Resource Sharing: Grids Collaborative Communities Content based networking: e.g. Semantic Nets Business Applications: e.g. Market Management Ubiquitous Computing: e.g. Vehicular Communication 18 Prof. Dr. Thomas Schmidt

19 Psychoacoustics From: J. Eberspächer, R. Schollmeier: First and Second Generation Peer-to-Peer Systems, in LNCS Prof. Dr. Thomas Schmidt

20 The Challenge in Peer-to-Peer Systems? I have item D. Where to place D? D? Data item D distributed system I want item D. Where can I find D?? peer-to-peer.info berkeley.edu planet-lab.org Location of resources (data items) distributed among systems Where shall the item be stored by the provider? How does a requester find the actual location of an item? Scalability: limit the complexity for communication and storage Robustness and resilience in case of faults and frequent changes 20 Prof. Dr. Thomas Schmidt

21 Unstructured P2P Revisited Basically two approaches: Centralized Simple, flexible searches at server (O(1)) Single point of failure, O(N) node states at server Decentralized Flooding Fault tolerant, O(1) node states Communication overhead O(N 2 ), search may fail But: No reference structure between nodes imposed 21 Prof. Dr. Thomas Schmidt

22 Unstructured P2P: Complexities Flooding Communication Overhead O(N) O(log N) O(1) Bottleneck: Communication Overhead False negatives? Scalable solution between both extremes? Bottlenecks: Memory, CPU, Network Availability Central Server O(1) O(log N) O(N) 22 Prof. Dr. Thomas Schmidt

23 Idea: Distributed Indexing Initial ideas from distributed shared memories (1987 ff.) Nodes are structured according to some address space Data is mapped into the same address space Intermediate nodes maintain routing information to target nodes Efficient forwarding to destination (content not location) Definitive statement about existence of content H( my data ) = ? Prof. Dr. Thomas Schmidt

24 Scalability of Distributed Indexing Communication effort: O(log(N)) hops Node state: O(log(N)) routing entries Routing in O(log(N)) steps to the node storing the data H( my data ) = ? Nodes store O(log(N)) routing information to other nodes berkeley.edu planet-lab.org peer-to-peer.info Prof. Dr. Thomas Schmidt

25 Distributed Indexing: Complexities Communication Overhead O(N) O(log N) O(1) Flooding Bottleneck: Communication Overhead False negatives Distributed Hash Table Scalability: O(log N) No false negatives Resistant against changes Failures, Attacks Short time users Bottlenecks: Memory, CPU, Network Availability Central Server O(1) O(log N) Node State 25 Prof. Dr. Thomas Schmidt O(N)

26 Fundamentals of Distributed Hash Tables Desired Characteristics: Flexibility, Reliability, Scalability Challenges for designing DHTs Equal distribution of content among nodes Crucial for efficient lookup of content Permanent adaptation to faults, joins, exits of nodes Assignment of responsibilities to new nodes Re-assignment and re-distribution of responsibilities in case of node failure or departure Maintenance of routing information 26 Prof. Dr. Thomas Schmidt

27 Distributed Management of Data 1. Mapping of nodes and data into same address space Peers and content are addressed using flat identifiers (IDs) Nodes are responsible for data in certain parts of the address space Association of data to nodes may change since nodes may disappear 2. Storing / Looking up data in the DHT Search for data = routing to the responsible node Responsible node not necessarily known in advance Deterministic statement about availability of data 27 Prof. Dr. Thomas Schmidt

28 Addressing in Distributed Hash Tables Step 1: Mapping of content/nodes into linear space Usually: 0,, 2 m -1 à number of objects to be stored Mapping of data and nodes into an address space (with hash function) E.g., Hash(String) mod 2 m : H( my data ) 2313 Association of parts of address space to DHT nodes ( ) 2 m -1 0 H(Node Y)=3485 Data item D : H( D )=3107 Y 28 Prof. Dr. Thomas Schmidt X H(Node X)=2906 Often, the address space is viewed as a circle.

29 Mapping Address Space to Nodes Each node is responsible for part of the value range Often with redundancy (overlapping of parts) Continuous adaptation Real (underlay) and logical (overlay) topology so far uncorrelated Node 3485 is responsible for data items in range 2907 to 3485 (in case of a Chord-DHT) Logical view of the Distributed Hash Table Mapping on the real topology 29 Prof. Dr. Thomas Schmidt

30 Routing to a Data Item? Step 2: Locating the data (content-based routing) Routing to a Key-Value-pair H( my data ) = 3107 Start lookup at arbitrary node of DHT Routing to requested data item (key) recursively according to node tables Key = H( my data ) Node 3485 manages keys , Initial node (arbitrary) (3107, (ip, port)) 30 Prof. Dr. Thomas Schmidt Value = pointer to location of data

31 Routing to a Data Item (2) Getting the content K/V-pair is delivered to requester Requester analyzes K/V-tuple (and downloads data from actual location in case of indirect storage) H( my data ) = Get_Data(ip, port) In case of indirect storage: After knowing the actual Location, data is requested? Node 3485 sends (3107, (ip/port)) to requester 31 Prof. Dr. Thomas Schmidt

32 DHT Algorithms Lookup algorithm for nearby objects (Plaxton et al 1997) Before P2P later used in Tapestry Chord (Stoica et al 2001) Straight forward 1-dim. DHT Pastry (Rowstron & Druschel 2001) Proximity neighbour selection CAN (Ratnasamy et al 2001) Route optimisation in a multidimensional identifier space Kademlia (Maymounkov & Mazières 2002) 32 Prof. Dr. Thomas Schmidt

33 Chord: Overview Early and successful algorithm Simple & elegant easy to understand and implement many improvements and optimizations exist Main responsibilities: Routing Flat logical address space: l-bit identifiers instead of IPs Efficient routing in large systems: log(n) hops, with N number of total nodes Self-organization Handle node arrival, departure, and failure 33 Prof. Dr. Thomas Schmidt

34 Chord: Topology Hash-table storage put (key, value) inserts data into Chord Value = get (key) retrieves data from Chord Identifiers from consistent hashing Uses monotonic, load balancing hash function E.g. SHA-1, 160-bit output 0 <= identifier < Key associated with data item E.g. key = sha-1(value) ID associated with host E.g. id = sha-1 (IP address, port) 34 Prof. Dr. Thomas Schmidt

35 Chord: Topology Keys and IDs on ring, i.e., all arithmetic modulo (key, value) pairs managed by clockwise next node: successor successor(1) = 1 successor(6) = Chord Ring 2 2 successor(2) = X Identifier Node Key 35 Prof. Dr. Thomas Schmidt

36 Chord: Topology Topology determined by links between nodes Link: knowledge about another node Stored in routing table on each node Simplest topology: circular linked list Each node has link to clockwise next node Prof. Dr. Thomas Schmidt

37 Routing on Ring? Primitive routing: Forward query for key x until successor(x) is found Return result to source of query Pros: Simple Little node state Cons: Poor lookup efficiency: O(1/2 * N) hops on average (with N nodes) Node failure breaks circle 37 Prof. Dr. Thomas Schmidt Node 0 Key 6?

38 Improved Routing on Ring? Improved routing: Store links to z next neighbors, Forward queries for k to farthest known predecessor of k For z = N: fully meshed routing system Lookup efficiency: O(1) Per-node state: O(N) Still poor scalability in linear routing progress Scalable routing: Mix of short- and long-distance links required: Accurate routing in node s vicinity Fast routing progress over large distances Bounded number of links per node 38 Prof. Dr. Thomas Schmidt

39 Chord: Routing Chord s routing table: finger table Stores log(n) links per node Covers exponentially increasing distances: Node n: entry i points to successor(n + 2 i ) (i-th finger) finger table i start succ. keys finger table i start succ keys finger table i start succ. keys Prof. Dr. Thomas Schmidt

40 Chord: Routing Chord s routing algorithm: Each node n forwards query for key k clockwise To farthest finger preceding k Until n = predecessor(k) and successor(n) = successor(k) Return successor(n) to source of query i 2^i Target Link i 2^i 40 43Target 42 45Link lookup (44) (44) = Prof. Dr. Thomas Schmidt

41 Chord: Self-Organization Handle changing network environment Failure of nodes Network failures Arrival of new nodes Departure of participating nodes Maintain consistent system state for routing Keep routing information up to date Routing correctness depends on correct successor information Routing efficiency depends on correct finger tables Failure tolerance required for all operations 41 Prof. Dr. Thomas Schmidt

42 Chord: Failure Tolerance in Storage Layered design Chord DHT mainly responsible for routing Data storage managed by application persistence consistency Chord soft-state approach: Nodes delete (key, value) pairs after timeout Applications need to refresh (key, value) pairs periodically Worst case: data unavailable for refresh interval after node failure 42 Prof. Dr. Thomas Schmidt

43 Chord: Failure Tolerance in Routing Finger failures during routing query cannot be forwarded to finger forward to previous finger (do not overshoot destination node) trigger repair mechanism: replace finger with its successor Active finger maintenance periodically check fingers fix_fingers replace with correct nodes on failures trade-off: maintenance traffic vs. correctness & timeliness 43 Prof. Dr. Thomas Schmidt

44 Chord: Failure Tolerance in Routing Successor failure during routing Last step of routing can return node failure to source of query -> all queries for successor fail Store n successors in successor list successor[0] fails -> use successor[1] etc. routing fails only if n consecutive nodes fail simultaneously Active maintenance of successor list periodic checks similar to finger table maintenance stabilize uses predecessor pointer crucial for correct routing 44 Prof. Dr. Thomas Schmidt

45 Chord: Node Arrival New node picks ID Contact existing node (known from bootstrapping) Initiates search on personal ID -> successor returned Retrieve (key, value) pairs from successor Construct finger table via standard routing/lookup() finger table i start succ keys finger table i start succ keys 1 finger table i start succ keys finger table i start succ keys 2 45 Prof. Dr. Thomas Schmidt

46 Chord: Node Departure Deliberate node departure clean shutdown instead of failure For simplicity: treat as failure system already failure tolerant soft state: automatic state restoration state is lost briefly invalid finger table entries: reduced routing efficiency For efficiency: handle explicitly notification by departing node to successor, predecessor, nodes at finger distances copy (key, value) pairs before shutdown 46 Prof. Dr. Thomas Schmidt

47 Chord: Summary Complexity Messages per lookup: O(log N) Memory per node: O(log N) Messages per management action (join/leave/fail): O(log² N) Advantages Theoretical models and proofs about complexity Simple & flexible Disadvantages No notion of node proximity and proximity-based routing optimizations Chord rings may become disjoint in realistic settings Many improvements published e.g. proximity, bi-directional links, load balancing, etc. 47 Prof. Dr. Thomas Schmidt

48 CAN: Overview Maps node IDs to regions, which partition d-dimensional space correspondingly are coordinate points in a ddim. torus: <k1,, kd> Keys Routing from neighbour to neighbour neighbourhood enhanced in high dimensionality d 48 tuning parameter of the system Prof. Dr. Thomas Schmidt

49 CAN: Space Partitioning Keys mapped into [0,1] d (or other numerical interval) Node s regions always cover the entire torus Data is placed on node, who owns zone of its key Zone management is done by splitting / re-merging regions Dimensional ordering to retain spatial coherence 49 Prof. Dr. Thomas Schmidt

50 CAN Routing Each node maintains a coordinate neighbour set (Neighbours overlap in (d-1) dim. and abut in the remaining dim.) Routing is done from neighbour to neighbour along the straight line path from source to destination: Forwarding is done to that neighbour with coordinate zone closest to destination 50 Prof. Dr. Thomas Schmidt

51 CAN Node Arrival The new node 1. Picks a random coordinate 2. Contacts any CAN node and routes a join to the owner of the corresponding zone 3. Splits zone to acquire region of its picked point & learns neighbours from previous owner 4. Advertises its presence to neighbours 51 Prof. Dr. Thomas Schmidt

52 Node Failure / Departure Node failure detected by missing update messages Leaving gracefully, a node notifies neighbours and copies its content On node s disappearance zone needs re-occupation in a size-balancing approach: Neighbours start timers invers. proportional to their zone size On timeout a neighbour requests takeover, responded only by those nodes with smaller zone sizes 52 Prof. Dr. Thomas Schmidt

53 CAN Optimisations Redundancy: Multiple simultaneous coordinate spaces - Realities Expedited Routing: Cartesian Distance weighted by network-level measures Path-length reduction: Overloading coordinate zones Proximity neighbouring: Topologically sensitive construction of overlay (landmarking) 53 Prof. Dr. Thomas Schmidt

54 CAN: Summary Complexity Messages per lookup: O(N 1/d ) Messages per mgmt. action (join/leave/fail): O( d/2 N 1/d )/O(2 d) Memory per node: O(d) Advantages Performance parametrisable through dimensionality Simple basic principle, easy to analyse & improve Disadvantages Lookup complexity is not logarithmically bound Due to its simple construction, CAN is open to many variants, improvements and customisations 54 Prof. Dr. Thomas Schmidt

55 References Andy Oram (ed.): Peer-to-Peer, O Reilly, R. Steinmetz, K. Wehrle (eds.): Peer-to-Peer Systems and Applications, Springer LNCS 3485, C.Plaxton, R. Rajaraman, A. Richa: Accessing Nearby Copies of Replicated Objects in a Distributed Environment, Proc. of 9th ACM Sympos. on parallel Algor. and Arch. (SPAA), pp , June I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan: Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications. Proc. of the 2001 ACM SigComm, pp , ACM Press, S. Ratnasamy, P. Francis, M. Handley, R. Karp: A Scalable Content-Addressable Network. Proc. of the 2001 ACM SigComm, pp , ACM Press, Prof. Dr. Thomas Schmidt