UnstructuredUnstructured Peer Peer--toto--PeerPeer Networksbalke/lecture-p2p/Vorlesung_2.pdf · UnstructuredUnstructured Peer Peer--toto--PeerPeer Networks WolfWolf--TiloTilo BalkeBalke

L3S Research Center, University of Hannover

UnstructuredUnstructured PeerPeer--toto--Peer Peer NetworksNetworks

WolfWolf--TiloTilo BalkeBalke and Wolf Siberskiand Wolf Siberski

24.10.0724.10.07

1Peer-to-Peer Systems and Applications, Springer LNCS 3485Peer-to-Peer Systems and Applications, Springer LNCS 3485

* Original slides partially provided by Rüdiger Schollmeier and Jörg Eberspächer (TU München)

Unstructured P2P Networks

History

Overlay Network Characteristics

Network TypesCentralized P2P

Pure P2P

Hybrid P2P

2Unstructured Peer-to-Peer NetworksL3S Research Center

Review: Driving Forces of P2P – File Sharing

Sharing of otherwise unused resourcesStorage

Bandwidth

(Processing)

No central controlNo single point of failure

No administrative efforts

Diffi lt t tt k ith j di i l


Difficult to attack with judicial means


History


Network TypesCentralized P2P

Pure P2P

Hybrid P2P


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

1) Freenet

3)


2) Buzzpad3) WuWu

1)

2)

[Most relevant P2P-Applications in the year 2001]

From ARPANET to Peer-to-Peer

Late 1960s: Establishment of the ARPANETGoal: share computing resources and documents between US research facilitiesThe logical network matched the physical network to a large extentApplications: FTP and TelNet client/server modelCentral steering committee to organize the network

1979: Development of the UseNet protocolNewsgroup application to organize contentNewsgroup server network exhibits P2P characteristics

Self organizing approach to add and remove newsgroup serversFully distributed content replication


y pStill client/server application with respect to endpoints

~1990 rush of the general public to join the InternetApplications following the client/server approach: WWW, email, streamingStraightforward model to administrate and control the content distribution

The Napster Story




1) Freenet

3)


)2) Buzzpad3) WuWu

1)

2)


The Napster Story

MAY 1999: Disruption of the Internet communityFirst Generation of P2P

Introduction of NapsterUser not only consume and download content but also offer and provide content to other participantscontent to other participantsUsers establish a virtual network, entirely independent from physical network and administrative authorities or restrictionsBasis: 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


pJuly 2001: Napster Inc. is convicted

Napster has to stop the operation of the Napster serverNapster network breaks downBUT: Already a number of promising successors available

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 downloadof peers having the desired files available for download.

Requesting peer obtains the respective files directly from the peer offering them.

CharacteristicsLookup of existing documents can be guaranteed.Index service is a “Single Point of Failure”.Centralized P2P system


Centralized P2P system

Representative: Napster

Centralized Directory Model - Example

? Prince

purple rain ? ! Prince

purple rain !

Central database with

index of all shared files

Mr. Müller shares on his client several MP3-

files.

Mr. Arayama shares on his client several MP3-

files, too.

! Prince


purple rain !@ Mr. Arayama

? Prince purple rain ?

Gnutella and its Relatives




1) Freenet

3)


1) Freenet2) Buzzpad3) WuWu

1)

2)


Gnutella

March 2000: Nullsoft releases Gnutella as an open source project

Major developer: Gene KhanAdditionally to servent functionality, the peers also take over routing tasksBecomes extremely popular after Napster has to shut down

October 2000: introduction of hierarchical routing layers. Gnutella 0.6: Ultrapeer conceptIncreases the scalability significantly

Variety of similar fully decentralized P2P-protocols followed soon:


y y pAudiogalaxyFastTrack/KaZaAiMeshFreenet

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 aIf 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

i l i t f f il t l


no single point of failure or controlUnreliable lookup (no guarantees)System doesn't scale.Pure P2P system

Representative: Gnutella 0.4

http://www gnutelliums com/

Flooded Request Model - Example

Mr. Müller is searching for

Prince

?

?

?

?

? ? ?

http://www.gnutelliums.com/

Mr. Arayama serves Prince


No central Database

?

??

serves Prince

Super-peer based Flooding

Super-peer based Flooding:Hierarchical P2P system

Super-peers (Ultrapeers) form pure P2P subnetAll other peers (Leaf nodes) directly attach to one super-peerSuper peer netwerk acts as distributed file indexSuper-peer netwerk acts as distributed file index

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


g pSystems scales much betterUnreliable lookup (but more success due to smaller network)Hybrid P2P system

Representative: Gnutella 0.6

http://www gnutelliums com/

Super-peer based Flooding- Example

Mr. Müller is searching for

Prince

?

?

?

http://www.gnutelliums.com/

Mr. Arayama

?

? ?

?

?


?

?

Mr. Arayama serves Prince?

August 2001Users adapt very fast to the breakdown of NapsterAlready 3.05 billion files exchanged per months via the Gnutella network

Year 2001Invention of structured P2P networks (regular instead of random network graph)

A t 2002

Gnutella and its Relatives: The Story Goes on

August 2002Amount 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 2003Bittorrent is releasedSoon causes majority of the observed traffic, due to its efficiency

Middle of 2003Beyond the exchange of content, new concepts are developed to use P2P also for other applications


applicationsSkype 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

1st and 2nd 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

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

2. Server as the higher performance system.

3. Clients as the lower performance system

Example: WWW

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


2. Any terminal entity can be removed without loss of functionality

3. No central entities

Examples: Gnutella 0.4, Freenet



3. dynamic central entities

Example: Gnutella 0.6, JXTA


1st Gen. 2nd Gen.

Folie 17

ws1 Split into two slidesWolf Siberski; 22.10.2007


History


Network TypesCentral P2P: Napster

Pure P2P: Gnutella 0.4

Hybrid P2P: Gnutella 0.6


Overlay Networks

“Virtual” signaling network established via TCP connections between the peers

Characteristics of the overlay topology:

completely independent from physical networkS t dd i d ti hSeparate addressing and routing schemeNo 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)


(Gnutella 0.4) (randomly meshed network)

Overlay network can be seen as graphPeers as nodesConceptual connections as edges

General Characteristics of 1st And 2nd Gen. P2P

1st and 2nd Generation P2P systems are overlay architectures, with the following characteristics:

TCP/IP basedDecentralized and self organizing (with possible centralized elements)ContentContent:

Distributed “randomly” on the network, with several replicas (due to popularity)Content stays at provider peerContent transfer:

Out of band, i.e. on separate connections and not via signaling connectionsMostly via HTTP

Employ distributed shared resources (data storage, bandwidth)Generally two kinds of requests:


yContent requests: to find content in the overlayKeep-alive requests: stay connected in the overlay

Initially developed for file-sharingVarious realizations exist

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 networkEvery node forwards every incoming message to all neighbors except the neighbor it received the messageEvery node forwards every incoming message to all neighbors except the neighbor, it received the message from

Exceptions: see below

Request messages terminate, ifSame 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


g g

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

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:

B t t h T t t bli h ft th ti t d i iBootstrap 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:

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)


outdated)

Broadcast on the IP layerUse multicast channels

Use IP broadcasting (-limited to local network)


History



1. Basic Characteristics2. Signaling Characteristics3. Discussion




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 necessary to provide network services

Central entity is some kind of index/group database

Central entity is lookup/routing table


Basic Characteristics of centralized P2P

Bootstrapping: Bootstrap-server = central serverCentral entity can be established as a server farm, but one single entry point = single point of failure (SPOF)All i li ti di t d t t l titAll signaling connections are directed to central entityPeer ↔ central entity: P2P protocol, e.g. Napster protocol

To find contentTo log on to the overlayTo register


To update the routing tablesTo update shared content information

Peer ↔ Peer: HTTPTo exchange content/data

Topology of Centralized P2P


ServentConnection between

2 servents (TCP)

Connection betweenrouter & servent

Connection betweenrouters (Core)

Napster: How Does It Work

Data

NapsterHost

Application-level, client-server protocol over point-to-point TCPPartcipants:

Napster Hosts/peersClient Service

Login

CentralNapsterIndexserver

Transfer

NapsterHost

NapsterHost

NapsterHost

gData-requestsDownload-requests

P2P ServiceData-transfer

Napster IndexserverPure Server

Five steps:C t t N t S


Connect to Napster ServerUpload your list of files (push) to serverQuery Indexserver with a list of keywords to search the full list withSelect “best” of correct answersConnect to providing host/peer

Napster Message Structure

General Header Structure:

<Payload Length>2byte

<Function>2Byte

HEADER 4byte PAYLOAD

Describes the Describes parameters


message type (e.g. login, search,…)

pof the message (e.g. IDs, keywords,…)

Napster: Initialization

1: LOGIN (Function:0x02)

Client/Server Service

<Nick> <Password> <Port> <Client-Info> <Link-type>

2: LOGIN ACK (Function: 0x03)

„<Filename>“ <MD5>

3: NOTIFICATION OF SHARED FILE (0x64)

<Size> <Bitrate> <Freq> <Time>


NapsterHost

IP: 001Nick: LKN

LOGIN(0x02)

lkn 54332 6699 „nap v0.8“ 9

LOGIN ACK(0x03)NOTIFICATION(0x64)

„band - song.mp3“ 3f3a3... 5674544

128 44100 342


Napster: File Request Procedure

[FILENAME CONTAINS „Search Criteria“]

[LINESPEED <Compare> <Link-Type>]

1: SEARCH (Function: 0xC8)

[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>


SEARCH(0xC8)

FILENAME CONTAINS „song“ MAX_RESULTS 100

LINESPEED „AT LEAST“ 6 BITRATE „AT LEAST“ „128“

FREQ „EQUAL TO“ „44100“

NapsterHost

IP: 002Nick: MIT


Summary of Napster Signaling

NapsterPeer (Req)

NapsterServer

NapsterPeer (Prov)

Login: [0x24|0x02|…]

Login Ack: [0x00|0x03|…]

HTTP: GET[Filename]

Notif: [0x46|0x64|…]

Notif: [0x46|0x64|…]

Notif: [0x46|0x64|…]

Search: [0x7E|0xC8|…]

Response: [0xC4|0xC9|…]

Response: [0xC4|0xC9|…]


OK[data]

Sample message sequence chart for one Napster server with one requesting and one providing peer

Napster: Wrap-Up


Centralized P2P: Discussion

DisadvantagesSingle Point of Failure easily attackableBottleneckPotential of congestionCentral server in control of all peers

AdvantagesFast and complete lookup (one hop lookup)Central managing/trust authorityNo keep alive necessary, beyond content updates

Application areasFile Sharing


gVoIP (SIP, H.323)Conceptually: ‘Social Web’ applications (eBay, YouTube, del.icio.us, etc.)

SystemsBitTorrent, Audiogalaxy, WinMX


History



Pure P2P: Gnutella 0.41. Basic Characteristics2. Signaling Characteristics3. Discussion



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 messagesTo route request and response messages

To insert request messages into the overlay


=

⎛ ⎞c d d

Model of Pure P2P Networks

Degree distribution: ( ) ( )

( )

11.4, 0 7 ,0 ,

: 2.2var 1.63

d

p dp d with c

cin any other case

average dd

−−⎧ < ≤= = ⎜ ⎟⎨

⎩ ⎝ ⎠

=

∑⋅

Separate sub networks

According Sample Graph:


Major component

Basic Characteristics of Pure P2P

Bootstrapping: Via bootstrap-server (host list from a web server)Via peer-cache (from previous sessions)Via well-known hostNo registration

Routing:Completely decentralizedReactive protocol: routes to content providers are only established on demand, no content announcementsRequests: 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 TCPKeep alive


Keep-aliveContent search

Content transfer connections (temporary):Based on HTTPOut of band transmission

Topology of Pure P2P


ServentConnection between

2 servents (TCP)

Connection betweenrouter & servent

Connection betweenrouters (Core)

Gnutella 0.4: How Does It Work

Application-level, peer-to-peer protocol over point-to-point TCPPartcipants:

Gnutella peers/serventsRouter Service

Flood incoming requests (regard TTL!)Keep alive

G

G

GG

Peer/G

G

contentRoute responses for other peers (regard GUID of message)

Keep alive (PING/PONG)Content (QUERY/QUERYHIT)

Data-requestsDownload-requests

Lookup ServiceInitialize Data requestsInitialize keep alive requests

“Server”-Service

G

G

G

GG

TCP connection

Servent

G G


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

The Gnutella Network


Measurements taken at the LKN in May 2002

Gnutella Message Structure

General Header Structure:General Header Structure:

MESSAGEHEADER: 23Byte

Describes the message type (e.g. login, search,…)

Describes parameters of the message (e.g. IDs, keywords,…)

GnodeID16 Bytes

Function1 Byte

TTL1 Byte

Hops1 Byte

Payload Length4 Bytes


• 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

Gnutella Messages

Port IP Address

PING (Function:0x00)

Nb. of shared Files Nb. of Kbytes shared

No Payload

PONG (Function:0x01)

2 Bytes 4 Bytes 4 Bytesy

4 Bytes

Minimum Speed2 Bytes

Search Criterian Bytes

QUERY (Function:0x80)

b f i P G d IDR l S

QUERY HIT (Function:0x81)

S dIP Add


Nb. of Hits1 Byte

Port2 Bytes

GnodeID16 Bytes

Result Setn Bytes

Speed1 Byte

File Index4 Bytes

File Namen Bytes

IP Address4 Bytes

Gnutella Routing

• Save Origin of received PINGs and QUERIEs

• Basic Routing Principle: „Enhanced“ Flooding

• 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

• Decrease TTL by 1

• If TTL equals 0, kill the message


and GNODE ID as previous messages are destroyed (avoid loops)

• PONG and QUERY HIT are forwarded to theorigin of the according PING or QUERY

Gnutella Connection Setup

GNODE GNODE

17Gnutella Connect

18Gnutella OK

Gnode 2000 establishes a connection to 4000

GNODE ID: 2000IP: 002


2625

17

18Gnutella OK

19PING 20PONG/IP:004


27PONG/IP:001


18

19202728




2224

28PONG/IP:003

25PING

26PING

Summary of the Signaling in Gnutella 0.4

1

7

3

2

4

5

6

Sample Gnutella 0.4 network:

78

Gnu-ConGnu-Con

Peer7 Peer3 Peer1 Peer5 Peer2 Peer4 Peer6

Gnu-ConOKOK

OK

PINGPING

PINGPINGPING PING

PING

PINGPING

PING

Peer8

PING

PING

Sample message sequence chart according to the sample network:


PONGPONG

PONG

PONG

PONGPONG

PONG

PONG

PONGPONG

PONG

PONG

Gnutella Wrap-Up


Discussion

DisadvantagesHigh signaling traffic, because of decentralizationModem nodes may become bottlenecksOverlay topology not optimal, as

no complete view available,dino coordinator

If not adapted to physical structure delay and total network load increasesZigzag routesloops

AdvantagesNo single point of failureCan be adapted to physical networkCan provide anonymityCan be adapted to special interest groups


Can be adapted to special interest groupsApplication areas

File-sharingContext based routing (see chapter about mobility)

SystemsFreenet, Gnutella, Gnunet


History




Hybrid P2P: Gnutella 0.61. Basic Characteristics2. Signaling Characteristics3. Discussion


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 reliabilityReduces 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)


Superpeer

leafnode

⋅

− =⋅

< ≤, 1 7c d d

average d

⎛ ⎞

Model of Hybrid P2P Networks

Degree distribution:

Separate sub networks

( ) ( )

( )

1.4

11.41 0.05, 1 ,0.05, 20

0,

: 2.8

d

p dp d with cc d

cc din any other case

−

−−

= = ⎜ ⎟= ⎝ ⎠

=

∑⋅

According sample graph:

Major component

( )var 3.55d =


Hub connections (2nd hierarchy)

Superpeer

leafnode

Basic Characteristics of Hybrid P2P

Bootstrapping: Via bootstrap-server (host list from a web server)Via peer-cache (from previous sessions)Via well-known hostRegistration of each leafnode at the Superpeer it connects to, i.e. it announces its shared files to the Superpeer

Routing:Partly decentralized

Leafnodes send request to a SuperpeerSuperpeer distributes this request in the Superpeer layerIf 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 SuperpeersRouting within Superpeer layer equal to Pure P2P

Signaling connections (stable, as long as neighbors do not change):B d TCP


Based on TCPKeep-aliveContent search

Content transfer connections (temporary):Based on HTTPOut of band transmission (directly between leafnodes)

Gnutella 0.6 Network Organization

New connection/network setupUpon connection to the network via a Superpeer, each node is a leafnode

It it h d t t t th S it t d tIt 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

Gnutella 0.6 Routing

Content requests:Leafnode sends request to SuperpeerSuperpeer 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.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 hopIf 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 leafnodesAfter 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)I f th l f d d t t l b k t th ti b di it


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

Topology of Hybrid P2P

43

39

7

100

118116

18

118

7

116

3, 43

18100

100

3

39

7

Abstract network structure of a part of Geographical view of a part of the Gnutella


the Gnutella network (222 nodes Geographical view given by Figure on the right, measured on 01.08.2002

network (222 nodes); The numbers depict thenode numbers from the abstract view (Figure onthe left, measured on 01.08.2002)

• Virtual network not matched to physical network. See path from node 118 to node 18.• Superpeer (hub) structure clearly visible in abstract view• Virtual network not matched to physical network. See path from node 118 to node 18.• Superpeer (hub) structure clearly visible in abstract view

Gnutella 0.6 Messages

Content requests and responsesQUERY (defined as in Gnutella 0.4)QUERY_HIT (defined as in Gnutella 0.4)

Keep alive:PING (defined as in Gnutella 0.4)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

ROUTE TABLE UPDATE (0x30) Patch variant(0x1): to update and set a new routing

0 1 4 5 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)

0 1 2 3 4 5 n+4 Variant Seq_No Seq_Size Compressor Entry_Bits DATA

Summary of the Signaling in Gnutella 0.6

Sample Gnutella 0.6 network:

4L1 L3

S2

S3

S1 L5

L4

L6

L7

Sample message sequence chart according to the sample network:

4L1 L3L2

L4

Gnu-Con

L2 L3 L1 S1 S3 S2 L7

OK

PONG

L6 L5 L4

RTU

PING

PONGPONG

PING

PINGPONG

PONG

PINGPING

QUERYQUERY

QUERYQUERY QUERY


QUERYQUERYQUERY

QUHIT

QUHIT QUHITQUHIT

QUHITQUHITQUHITQUHIT

Gnutella 0.6: How Does It Work


Discussion

DisadvantagesStill High signaling traffic, because of decentralizationNo definitive statement possible if content is not available or not foundOverlay topology not optimal, as

no complete view available,no coordinatorno coordinator

If not adapted to physical structure delay and total network load increasesZigzag routesLoops

Difficult to adapt to physical network completely because of hub structureAdvantages

No single point of failureCan provide anonymityCan be adapted to special interest groups


Can be adapted to special interest groupsApplication areas

File-sharingContext based routing (see chapter about mobility)

SystemsGnutella, eDonkey, Kazaa

Topology combinations

Each approach comes with a different set of advantages/disadvantages

Suitability depends on application context

Combination of approachespp

Use different techniques for different application aspects

Example: SkypeCentralized P2P for Login/Account Mgmt.

Routed by super-nodes if necessary

Attempts to establish direct Voice over IP connections


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, INFOCOM2006

1st and 2nd 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

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

2. Server as the higher performance system.

3. Clients as the lower performance system

Example: WWW

Centralized P2P Pure P2P Hybrid P2P Pure P2P Hybrid P2P


2. Central entity is necessary to provide the service

3. Central entity is some kind of index/group database

Example: Napster



3. No central entities

Examples: Gnutella 0.4, Freenet



3. dynamic central entities

Example: Gnutella 0.6, JXTA


1st Gen. 2nd Gen.

Outlook

Structured NetworksDistributed Hash Table (DHT) Basics (31.10.)

DHT Algorithms (14.11.)

DHT Dynamics (21.11.)

File Distribution Networks (28.11)


Documents

UnstructuredUnstructured Peer Peer--toto--PeerPeer Networksbalke/lecture-p2p/Vorlesung_2.pdf · UnstructuredUnstructured Peer Peer--toto--PeerPeer Networks WolfWolf--TiloTilo BalkeBalke