Peer-to-Peer Data Management. Hans-Dieter Ehrich Institut für Informationssysteme Technische Universität Braunschweig

Transcription

1 Peer-to-Peer Data Management Hans-Dieter Ehrich Institut für Informationssysteme Technische Universität Braunschweig

2 7. Unstructured P2P Networks The transparencies of this chapter are based on the package Unstructured Peer-to-Peer Networks by Wolf-Tilo Balke and Wolf Siberski Original slides partially provided by Rüdiger Schollmeier Jörg Eberspächer 7-2/62

3 7. Unstructured P2P Networks History Overlay Network Characteristics Network Types Centralized P2P Pure P2P Hybrid P2P 7-3/62

4 Review: Driving Forces of P2P File Sharing Sharing of otherwise unused resources Storage Bandwidth (Processing) No central control No single point of failure No administrative efforts Difficult to attack with judicial means 7-4/62

5 Unstructured P2P Networks History Overlay Network Characteristics Network Types Centralized P2P Pure P2P Hybrid P2P 7-5/62

6 How It All Began: From Arpanet to Peer-to-Peer 1. How It All Began: From Arpanet to Peer-to-Peer 2. The Napster Story 3. Gnutella and its Relatives: Fully Decentralized Architectures 3) 2) 1) Freenet 2) Buzzpad 3) WuWu 1) [Most relevant P2P-Applications in the year 2001] 7-6/62

7 From ARPANET to Peer-to-Peer Late 1960s: Establishment of the ARPANET Goal: share computing resources and documents between US research facilities The logical network matched the physical network to a large extent Applications: FTP and TelNet client/server model Central steering committee to organize the network 1979: Development of the UseNet protocol Newsgroup application to organize content Newsgroup server network exhibits P2P characteristics Self organizing approach to add and remove newsgroup servers Fully distributed content replication Still client/server application with respect to endpoints ~1990 rush of the general public to join the Internet Applications following the client/server approach: WWW, , streaming Straightforward model to administrate and control the content distribution 7-7/62

8 The Napster Story 1. How It All Began: From Arpanet to Peer-to-Peer 2. The Napster Story 3. Gnutella and its Relatives: Fully Decentralized Architectures 3) 2) 1) Freenet 2) Buzzpad 3) WuWu 1) [Most relevant P2P-Applications in the year 2001] 7-8/62

9 The Napster Story MAY 1999: Disruption of the Internet community First Generation of P2P Introduction of Napster User not only consume and download content but also offer and provide content to other participants Users establish a virtual network, entirely independent from physical network and administrative authorities or restrictions Basis: UDP and TCP connections between the peers December 1999: RIAA files a lawsuit against Napster Inc. Target of the RIAA: the central lookup server of Napster February 2001: 2.79 billion files exchanged via the Napster network per month July 2001: Napster Inc. is convicted Napster has to stop the operation of the Napster server Napster network breaks down BUT: Already a number of promising successors available 7-9/62

10 Centralized Directory Model Centralized Directory Model The index service is provided centrally by a coordinating entity. Search request is issued to the coordinating entity which delivers a list of peers having the desired files available for download. Requesting peer obtains the respective files directly from the peer offering them. Characteristics Lookup of existing documents can be guaranteed. Index service is a Single Point of Failure. Centralized P2P system Representative: Napster 7-10/62

11 Centralized Directory Model - Example Mr. Müller shares on his client several MP3- files. Mr. Arayama shares on his client several MP3- files, too.? Prince purple rain?! Prince purple Mr. Arayama Central database with index of all shared files? Prince purple rain?! Prince purple rain! 7-11/62

12 Gnutella and its Relatives 1. How It All Began: From Arpanet to Peer-to-Peer 2. The Napster Story 3. Gnutella and its Relatives: Fully Decentralized Architectures 3) 2) 1) Freenet 2) Buzzpad 3) WuWu 1) [Most relevant P2P-Applications in the year 2001] 7-12/62

13 Gnutella March 2000: Nullsoft releases Gnutella as an open source project Major developer: Gene Khan Additionally to servent functionality, the peers also take over routing tasks Becomes extremely popular after Napster has to shut down October 2000: introduction of hierarchical routing layers. Gnutella 0.6: Ultrapeer concept Increases the scalability significantly Variety of similar fully decentralized P2P-protocols followed soon: Audiogalaxy FastTrack/KaZaA imesh Freenet 7-13/62

14 Flooded Request Model Flooded Request Model: Atomic P2P system Without central coordination authority (all peers are equal). Search request is passed on to neighbors. If they cannot answer the request, they pass it on to various other nodes until a predetermined search depth (ttl=time-to-live). When requested file has been located, positive search results are sent to the requesting entity. Requesting peer can then download the desired file directly from the entity which is offering it. Characteristics: Fully decentralized, no central lookup server no single point of failure or control Unreliable lookup (no guarantees) System doesn't scale. Pure P2P system Representative: Gnutella /62

15 Flooded Request Model - Example No central Database Mr. Müller is searching for Prince??????? Mr. Arayama serves Prince 7-15/62

16 Super-peer based Flooding Super-peer based Flooding: Hierarchical P2P system Super-peers (Ultrapeers) form pure P2P subnet All other peers (Leaf nodes) directly attach to one super-peer Super-peer netwerk acts as distributed file index o Super-peers request file list from their leaf peers Queries are distributed in super-peer subnet only Combination of Pure and Central P2P Characteristics: Fully decentralized, no central lookup server no single point of failure or control Systems scales much better Unreliable lookup (but more success due to smaller network) Hybrid P2P system Representative: Gnutella /62

17 Super-peer based Flooding- Example Mr. Müller is searching for Prince?????????? Mr. Arayama serves Prince 7-17/62

18 August 2001 Gnutella and its Relatives: The Story Goes on Users adapt very fast to the breakdown of Napster Already 3.05 billion files exchanged per months via the Gnutella network Year 2001 Invention of structured P2P networks (regular instead of random network graph) August 2002 Amount of exchanged data in KaZaA decreases, caused by a high number of defected files (reason: weak hash keys to identify files) Edonkey and Gnutella regain popularity May 2003 Bittorrent is released Soon causes majority of the observed traffic, due to its efficiency Middle of 2003 Beyond the exchange of content, new concepts are developed to use P2P also for other applications Skype a Voice over P2P application is developed Today: Major efforts are made to increase the reliability of P2P-searches, also in mobile networks, In 2005 Ebay buys Skype to use the paradigm for the communication between bidders and sellers 7-18/62

19 1 st and 2 nd Generations of P2P Client-Server 1. Server is the central entity and only provider of service and content. Network managed by the Server 2. Server as the higher performance system. 3. Clients as the lower performance system Example: WWW 1. Resources are shared between the peers 2. Resources can be accessed directly from other peers 3. Peer is provider and requestor (Servent concept) Unstructured P2P Peer-to-Peer Structured P2P Centralized P2P Pure P2P Hybrid P2P Pure P2P Hybrid P2P 1. All features of Peer-to- Peer included 2. Central entity is necessary to provide the service 3. Central entity is some kind of index/group database Example: Napster 1. All features of Peer-to- Peer included 2. Any terminal entity can be removed without loss of functionality 3. No central entities Examples: Gnutella 0.4, Freenet 1. All features of Peer-to- Peer included 2. Any terminal entity can be removed without loss of functionality 3. dynamic central entities Example: Gnutella 0.6, JXTA 1 st Gen. 2 nd Gen. 7-19/62

20 Unstructured P2P Networks History Overlay Network Characteristics Network Types Central P2P: Napster Pure P2P: Gnutella 0.4 Hybrid P2P: Gnutella /62

21 Overlay Networks Virtual signaling network established via TCP connections between the peers Characteristics of the overlay topology: completely independent from physical network Separate addressing and routing scheme No relation between physical network edges and overlay network edges May include hierarchies (hub network) (e.g. rendezvous peers in JXTA) May include centralized elements (star network) (lookup server in Napster) May be a completely randomized network (Gnutella 0.4) (randomly meshed network) Overlay network can be seen as graph Peers as nodes Conceptual connections as edges 7-21/62

22 General Characteristics of 1 st And 2 nd Gen. P2P 1st and 2nd Generation P2P systems are overlay architectures, with the following characteristics: TCP/IP based Decentralized and self organizing (with possible centralized elements) Content: Distributed randomly on the network, with several replicas (due to popularity) Content stays at provider peer Content transfer: o Out of band, i.e. on separate connections and not via signaling connections o Mostly via HTTP Employ distributed shared resources (data storage, bandwidth) Generally two kinds of requests: Content requests: to find content in the overlay Keep-alive requests: stay connected in the overlay Initially developed for file-sharing Various realizations exist 7-22/62

23 Basic Routing Behavior Request messages: Include a hop-counter, a GUID (Globally Unique Identifier) and a TTL (Time-To-Live) in the header TTL determines along how many hops a message may be forwarded Are flooded in the overlay network Every node forwards every incoming message to all neighbors except the neighbor, it received the message from Exceptions: see below Request messages terminate, if Same message-type with same GUID is received more than once (loop!!) Hop-counter=TTL Response messages: Include a hop-counter, a GUID and a TTL (Time-to-Live) in the header GUID is the same as of the initializing request message Are routed back on the same way to the requestor, the request message was transmitted to the responding peer every peer has to store the GUID of each request for a certain amount of time No flooding to save resources 7-23/62

24 Basic Bootstrapping Mostly not part of the protocol specification Necessary to know at least one active participant of the network Otherwise no participation at the overlay possible for a new node Address (TCP) of an active node can be retrieved by different means: Bootstrap cache: Try to establish one after another a connection to a node seen in a previous session Bootstrap server: Connect to a well known host, which almost always participates Ask a bootstrap server to provide a valid address of at least one active node Realizations: o o FIFO of all node-addresses which recently used this bootstrap (a node which just connected is assumed to be still active) Random pick of addresses which recently connected via this server to the overlay (+ no loops, -may be outdated) Broadcast on the IP layer Use multicast channels Use IP broadcasting (-limited to local network) 7-24/62

25 History Unstructured P2P Networks Overlay Network Characteristics Network Types Central P2P: Napster 1. Basic Characteristics 2. Signaling Characteristics 3. Discussion Pure P2P: Gnutella 0.4 Hybrid P2P: Gnutella /62

26 Definition of centralized P2P All peers are connected to central entity Peers establish connections between each other on demand to exchange user data (e.g. mp3 compressed data) Central entity is necessary to provide network services Central entity is some kind of index/group database Central entity is lookup/routing table 7-26/62

27 Basic Characteristics of centralized P2P Bootstrapping: Bootstrap-server = central server Central entity can be established as a server farm, but one single entry point = single point of failure (SPOF) All signaling connections are directed to central entity Peer central entity: P2P protocol, e.g. Napster protocol To find content To log on to the overlay To register To update the routing tables To update shared content information Peer Peer: HTTP To exchange content/data 7-27/62

28 Topology of Centralized P2P Servent Connection between 2 servents (TCP) Connection between router & servent Connection between routers (Core) 7-28/62

29 Napster: How Does It Work Application-level, client-server protocol over point-to-point TCP Partcipants: Napster Hosts/peers Client Service Login Data-requests Download-requests P2P Service Data-transfer Napster Indexserver Pure Server Napster Host Data Transfer Napster Host Central Napster Index server Napster Host Napster Host Five steps: Connect to Napster Server Upload your list of files (push) to server Query Indexserver with a list of keywords to search the full list with Select best of correct answers Connect to providing host/peer 7-29/62

30 Napster Message Structure General Header Structure: HEADER 4byte PAYLOAD <Payload Length> 2byte <Function> 2Byte Describes the message type (e.g. login, search, ) Describes parameters of the message (e.g. IDs, keywords, ) 7-30/62

31 Napster: Initialization Client/Server Service 1: LOGIN (Function:0x02) <Nick> <Password> <Port> 2: LOGIN ACK (Function: 0x03) <Client-Info> <Link-type> 3: NOTIFICATION OF SHARED FILE (0x64) <Filename> <MD5> <Size> <Bitrate> <Freq> <Time> Napster Host IP: 001 Nick: LKN NOTIFICATION(0x64) band LOGIN(0x02) - song.mp3 ACK(0x03) 3f3a lkn nap v0.8 9 Central Napster Index server 7-31/62

32 Napster: File Request Procedure 1: SEARCH (Function: 0xC8) [FILENAME CONTAINS Search Criteria ] [MAX_RESULT <Max>] [LINESPEED <Compare> <Link-Type>] [BITRATE <Compare> <Bitrate> ] [FREQ <Compare> <Freq> ] 2: SEARCH RESPONSE (Function: 0xC9) <Filename> <MD5> <Size> <Bitrate> <Freq> <Time> <Nick> <IP> <Link-Type> Central Napster Index server SEARCH(0xC8) FILENAME CONTAINS song MAX_RESULTS 100 LINESPEED AT LEAST 6 BITRATE AT LEAST 128 FREQ EQUAL TO Napster Host IP: 002 Nick: MIT 7-32/62

33 Summary of Napster Signaling Napster Peer (Req) Napster Server Napster Peer (Prov) Login: [0x24 0x02 ] Login Ack: [0x00 0x03 ] Notif: [0x46 0x64 ] Notif: [0x46 0x64 ] Notif: [0x46 0x64 ] Search: [0x7E 0xC8 ] Response: [0xC4 0xC9 ] Response: [0xC4 0xC9 ] HTTP: GET[Filename] OK[data] Sample message sequence chart for one Napster server with one requesting and one providing peer 7-33/62

34 Napster: Wrap-Up I 1. Search Request User sends out a music file request and Napster searches its central data base /62

35 Napster: Wrap-Up II 2. Search Response The Napster Server sends back a list of peers that share the file. 7-35/62

36 Napster: Wrap-Up II 3. File Download The requesting user downloads the file directly from the computer of another Napster user via HTTP. 7-36/62

37 Centralized P2P: Discussion Disadvantages Single Point of Failure easily attackable Bottleneck Potential of congestion Central server in control of all peers Advantages Fast and complete lookup (one hop lookup) Central managing/trust authority No keep alive necessary, beyond content updates Application areas File Sharing VoIP (SIP, H.323) Conceptually: Social Web applications (ebay, YouTube, del.icio.us, etc.) Systems BitTorrent, Audiogalaxy, WinMX 7-37/62

38 History Unstructured P2P Networks Overlay Network Characteristics Network Types Central P2P: Napster Pure P2P: Gnutella Basic Characteristics 2. Signaling Characteristics 3. Discussion Hybrid P2P: Gnutella /62

39 Definition of Pure P2P Any terminal entity can be removed without loss of functionality No central entities employed in the overlay Peers establish connections between each other randomly To route request and response messages To insert request messages into the overlay 7-39/62

40 Model of Pure P2P Networks Degree distribution: ( ) p d ( ) - c d 1.4, 0 d 7 p d = =, with c 0, in any other case d c -1 average : d = 2.2 var ( d) = 1.63 According Sample Graph: Separate sub networks Major component 7-40/62

41 Basic Characteristics of Pure P2P Bootstrapping: Via bootstrap-server (host list from a web server) Via peer-cache (from previous sessions) Via well-known host No registration Routing: Completely decentralized Reactive protocol: routes to content providers are only established on demand, no content announcements Requests: flooding (limited by TTL and GUID) Responses: routed (Backward routing with help of GUID) Signaling connections (stable, as long as neighbors do not change): Based on TCP Keep-alive Content search Content transfer connections (temporary): Based on HTTP Out of band transmission 7-41/62

42 Topology of Pure P2P Servent Connection between 2 servents (TCP) Connection between router & servent Connection between routers (Core) 7-42/62

43 Gnutella 0.4: How Does It Work Application-level, peer-to-peer protocol over point-to-point TCP Partcipants: Gnutella peers/servents G Router Service Flood incoming requests (regard TTL!) o Keep alive G o content G Route responses for other peers (regard GUID of message) o Keep alive (PING/PONG) o Content (QUERY/QUERYHIT) G Data-requests G G G G G G G G TCP connection Peer/ Servent Download-requests Lookup Service Initialize Data requests Initialize keep alive requests Server -Service Serve Data-requests (HTTP) Five steps: Connect to at least one active peer (address received from bootstrap) Explore your neighborhood (PING/PONG) Submit Query with a list of keywords to your neighbors (they forward it) Select best of correct answers (which we receive after a while) Connect to providing host/peer 7-43/62

44 The Gnutella Network Measurements taken at the LKN in May /62

45 Gnutella Message Structure General Header Structure: MESSAGEHEADER: 23Byte GnodeID 16 Bytes Function 1 Byte TTL 1 Byte Hops 1 Byte Payload Length 4 Bytes Describes the message type (e.g. login, search, ) Describes parameters of the message (e.g. IDs, keywords, ) GnodeID: unique 128bit Id of any Hosts TTL(Time-To-Live): number of servents, a message may pass before it is killed Hops: number of servents a message already passed 7-45/62

46 Gnutella Messages PING (Function:0x00) No Payload PONG (Function:0x01) Port 2 Bytes IP Address 4 Bytes Nb. of shared Files 4 Bytes Nb. of Kbytes shared 4 Bytes QUERY (Function:0x80) Minimum Speed 2 Bytes Search Criteria n Bytes QUERY HIT (Function:0x81) Nb. of Hits 1 Byte Port 2 Bytes IP Address 4 Bytes Speed 1 Byte Result Set n Bytes GnodeID 16 Bytes File Index 4 Bytes File Name n Bytes 7-46/62

47 Gnutella Routing Basic Routing Principle: Enhanced Flooding Save Origin of received PINGs and QUERIEs Increase Hops by 1 If Hops equals TTL, kill the message Flooding: Received PINGS and QUERIES must be forwarded to all connected Gnodes PINGS or QUERYS with the same FUNCTION ID and GNODE ID as previous messages are destroyed (avoid loops) PONG and QUERY HIT are forwarded to the origin of the according PING or QUERY 7-47/62

48 Gnutella Connection Setup Gnode 2000 establishes a connection to Gnutella Connect GNODE ID: 1000 IP: 001 GNODE ID: 2000 IP: Gnutella OK 19PING 20PONG/IP: PING 22PING 23PONG/IP:001 27PONG/IP:001 24PONG/IP:003 GNODE ID: 3000 IP: GNODE ID: 4000 IP: PING 28PONG/IP:003 26PING 7-48/62

49 Summary of the Signaling in Gnutella 0.4 Sample Gnutella 0.4 network: Sample message sequence chart according to the sample network: Peer7 Peer3 Peer1 Peer5 Peer2 Peer4 Peer6 Gnu-Con Gnu-Con OK OK Gnu-Con OK PING PING PING PING PING PING PING PING PING PING Peer8 PING PING PONG PONG PONG PONG PONG PONG PONG PONG PONG PONG PONG PONG 7-49/62

50 Gnutella Wrap-Up I Requesting Servent Servent Query [ ] Query-Hit [ ] Requested Data Broadcast Query[XYZ, TTL = 3, ] 7-50/62

51 Gnutella Wrap-Up II Requesting Servent Servent Query [ ] Query-Hit [ ] Requested Data 1. Query-Hit Broadcast Query[XYZ, TTL = 2, ] 7-51/62

52 Gnutella Wrap-Up III Requesting Servent Servent Query [ ] Query-Hit [ ] Requested Data 2. Query-Hit Broadcast Query[XYZ, TTL = 1, ] 7-52/62

53 Gnutella Wrap-Up IV Requesting Servent Servent Query [ ] Query-Hit [ ] Requested Data Query-Hit [TTL = 0] no further Broadcast 7-53/62

54 Gnutella Wrap-Up V Requesting Servent Servent Query [ ] Query-Hit [ ] Requested Data Establish HTTP Connection 7-54/62

55 Gnutella Wrap-Up VI Requesting Servent Servent Query [ ] Query-Hit [ ] Requested Data HTTP Connection Get[XYZ,, ] Download Data 7-55/62

56 Discussion Disadvantages High signaling traffic, because of decentralization Modem nodes may become bottlenecks Overlay topology not optimal, as no complete view available, no coordinator If not adapted to physical structure delay and total network load increases Zigzag routes loops Advantages No single point of failure Can be adapted to physical network Can provide anonymity Can be adapted to special interest groups Application areas File-sharing Context based routing (see chapter about mobility) Systems Freenet, Gnutella, Gnunet 7-56/62

57 History Unstructured P2P Networks Overlay Network Characteristics Network Types Central P2P: Napster Pure P2P: Gnutella 0.4 Hybrid P2P: Gnutella Basic Characteristics 2. Signaling Characteristics 3. Discussion 7-57/62

58 Definition of Hybrid P2P Main characteristic, compared to pure P2P: Introduction of another dynamic hierarchical layer Hub based network Reduces the signaling load without reducing the reliability Election process to select and assign Superpeers Superpeers: high degree (degree>>20, depending on network size) Leafnodes: connected to one or more Superpeers (degree<7) leafnode Superpeer 7-58/62

59 Model of Hybrid P2P Networks Degree distribution: According sample graph: ( ) p d -1.4 c d, 1 d c , d = 1 p ( d ) = =, with c c 0.05, d= 20 d c 0, in any other case average : d = 2.8 var ( d) = Separate sub networks Major component leafnode Hub connections (2nd hierarchy) Superpeer 7-59/62

60 Basic Characteristics of Hybrid P2P Bootstrapping: Routing: Via bootstrap-server (host list from a web server) Via peer-cache (from previous sessions) Via well-known host Registration of each leafnode at the Superpeer it connects to, i.e. it announces its shared files to the Superpeer Partly decentralized Leafnodes send request to a Superpeer Superpeer distributes this request in the Superpeer layer If a Superpeer has information about a matching file shared by one of its leafnodes, it sends this information back to the requesting leafnode (backward routing) Hybrid protocol (reactive and proactive): routes to content providers are only established on demand; content announcements from leafnodes to their Superpeers Routing within Superpeer layer equal to Pure P2P Signaling connections (stable, as long as neighbors do not change): Based on TCP Keep-alive Content search Content transfer connections (temporary): Based on HTTP Out of band transmission (directly between leafnodes) 7-60/62

61 Gnutella 0.6 Network Organization New connection/network setup Upon connection to the network via a Superpeer, each node is a leafnode It announces its shared content to the Superpeer it connected to Superpeer thus updates its routing tables Election mechanism decides which node becomes a Superpeer or a leafnode (depending on capabilities (storage, processing power) network connection, the uptime of a node, ), if Too many nodes are connected to one Superpeer A Superpeer leaves the network To less nodes are connected to a Superpeer 7-61/62

62 Gnutella 0.6 Routing Content requests: Leafnode sends request to Superpeer Superpeer looks up in its routing tables whether content is offered by one of its leafnode. In this case the request is forwarded to this node. Additionally the Superpeer increases the hopcounter and forwards this request to the Superpeers it is connected to. To enable backward routing, the peer has to store the GUID of the message connected to the information from which peer it received the request in the previous hop If a Superpeer receives such a request from another Superpeer, this request is handled the same way, as if it would have received it from one of its leafnodes After the hopcounter of the request reaches the TTL-value it is not forwarded any further (prevent circles) Content responses: If a leafnode receives a request, it double-checks whether it shares the file (should be the case, as long as the routing tables of the Superpeer are correct) In case of success, the leafnode sends a content reply back to the requesting peer, by sending it back to that node (Superpeer) it received the message from (backward routing) Hop by hop the message can thus be routed back to the requesting node Content exchange: Directly between the leafnodes, via HTTP connections 7-62/62

63 Topology of Hybrid P2P , Abstract network structure of a part of the Gnutella network (222 nodes Geographical view given by Figure on the right, measured on Geographical view of a part of the Gnutella network (222 nodes); The numbers depict the node numbers from the abstract view (Figure on the left, measured on ) Virtual network not matched to physical network. See path from node 118 to node 18. Superpeer (hub) structure clearly visible in abstract view 7-63/62

64 Gnutella 0.6 Messages Content requests and responses QUERY (defined as in Gnutella 0.4) QUERY_HIT (defined as in Gnutella 0.4) Keep alive: PING (defined as in Gnutella 0.4) PONG (defined as in Gnutella 0.4) Announcement of shared content: ROUTE_TABLE_UPDATE (0x30), Reset variant (0x0): to clear the routing table and to set a new routing table for one leafnode Variant Table_Length Infinity ROUTE_TABLE_UPDATE (0x30), Patch variant(0x1): to update and set a new routing table with a certain number of entries (e.g. new shared files) n+4 Variant Seq_No Seq_Size Compressor Entry_Bits DATA 7-64/62

65 Summary of the Signaling in Gnutella 0.6 Sample Gnutella 0.6 network: S3 L7 L6 Sample message sequence chart according to the sample network: L1 L2 S1 L3 S2 L4 4 L2 L3 L1 S1 S3 S2 L7 Gnu-Con OK RTU PING PONG PONG PONG PING PONG PING PONG L5 PING L6 L5 L4 QUERY QUERY QUERY QUERY QUERY QUHIT QUERY QUERY QUHIT QUHIT QUHIT QUHIT QUHIT QUHIT QUHIT 7-65/62

66 Gnutella 0.6: How Does It Work I Ultrapeer Leafnode 7-66/62

67 Gnutella 0.6: How Does It Work II Ultrapeer Leafnode 7-67/62

68 Gnutella 0.6: How Does It Work III Ultrapeer Leafnode 7-68/62

69 Gnutella 0.6: How Does It Work III Ultrapeer Leafnode 7-69/62

70 Gnutella 0.6: How Does It Work IV Ultrapeer Leafnode 7-70/62

71 Gnutella 0.6: How Does It Work V Ultrapeer Leafnode 7-71/62

72 Disadvantages Discussion Still High signaling traffic, because of decentralization No definitive statement possible if content is not available or not found Overlay topology not optimal, as no complete view available, no coordinator If not adapted to physical structure delay and total network load increases Zigzag routes Loops Advantages Difficult to adapt to physical network completely because of hub structure No single point of failure Can provide anonymity Can be adapted to special interest groups Application areas Systems File-sharing Context based routing (see chapter about mobility) Gnutella, edonkey, Kazaa 7-72/62

73 Topology combinations Each approach comes with a different set of advantages/disadvantages Suitability depends on application context Combination of approaches Use different techniques for different application aspects Example: Skype Centralized P2P for Login/Account Mgmt. o Routed by super-nodes if necessary Attempts to establish direct Voice over IP connections Hybrid P2P to route through firewall, between NATs, etc. Figure from Salman A. Baset and Henning G. Schulzrinne: An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol, INFOCOM /62

74 1 st and 2 nd Generations of P2P Client-Server Peer-to-Peer 1. Server is the central entity and only provider of service and content. Network managed by the Server 2. Server as the higher performance system. 3. Clients as the lower performance system Example: WWW 1. Resources are shared between the peers 2. Resources can be accessed directly from other peers 3. Peer is provider and requestor (Servent concept) Unstructured P2P Structured P2P Centralized P2P Pure P2P Hybrid P2P Pure P2P Hybrid P2P 1. All features of Peer-to- Peer included 2. Central entity is necessary to provide the service 3. Central entity is some kind of index/group database Example: Napster 1. All features of Peer-to- Peer included 2. Any terminal entity can be removed without loss of functionality 3. No central entities Examples: Gnutella 0.4, Freenet 1. All features of Peer-to- Peer included 2. Any terminal entity can be removed without loss of functionality 3. dynamic central entities Example: Gnutella 0.6, JXTA 1 st Gen. 2 nd Gen. 7-74/62

75 Outlook Structured Networks Distributed Hash Table (DHT) Basics DHT Algorithms DHT Dynamics File Distribution Networks 7-75/62