NAPSTER - Dipartimento di Informatica

Transcript

NAPSTER - Dipartimento di Informatica
Università degli Studi di Pisa
Dipartimento di Informatica
Lezione n.2
Sistemi P2P di Prima Generazione:
NAPSTER
Laura Ricci
27-02-2009
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
1
P2P:CLASSIFICAZIONE GENERALE
Client-Server
•
Il Server è l’unica
entità in grado di
memorizzare
l’informazione
condivisa
 La rete è gestita
dal Server in modo
centralizzato
2. Il Server è il Sistema
con la maggior
capacità di calcolo
3. I client posseggono
minor capacità di
calcolo
Esempio: WWW
Peer-to-Peer: Caratteristiche Generali
1. Le risorse sono condivise tra i peers.
2. Le risorse offerte da un peer possono essere accedute direttamente da altri peer
3. Il peer fornisce e richiede risorse (Servent)
P2P Non strutturati
P2P Centralizzato
P2P Puro
P2P Ibridp
P2P basato su DHT
1. Soddisfano 1,.2.,3.
• Esistono alcuni peer
(superpeer) chehanno
anche funzioni di
indicizzazione
1. Soddisfano 1.,2.,3.
3. I superpeer sono
determinati
dinamicamente
4. Overlay network
strutturata
•
Soddisfano 1.,2.,3.
1. Soddisfano 1.,2.,3.
•
Esiste una entità
centralizzata
2. Non esiste alcuna entità
centralizzata
•
Tale entità centralizzata
svolge solo compiti di
indicizzazione delle
risorse
3. La funzionalità del
sistema non viene
compromessa dall’
eliminazione di un peer
Esempio: Napster
Esempi: Gnutella 0.4,
1st Gen.
Dipartimento di Informatica
Università degli Studi di Pisa
P2P Strutturati
Esempi: Gnutella 0.6,
JXTA, Kazaa
Laura Ricci
Sistemi P2P:Napster
2nd Gen.
2. Non esistono entità
centralizzate
3. La overlay network
risulta strutturata
Esemnpi: Chord,
CAN,Pastry,Kademlia
2
P2P: CARATTERISTICHE GENERALI

L’informazione condivisa:


E’ distribuita sulla rete in modo non deterministico, possono esistere diverse repliche di
un’informazione.
Può essere memorizzata
 sui nodi che la mettono a disposizione della rete
 Su altri nodi della rete
I peer definiscono una overlay network, o signaling network, utilizzata per
scambiare messaggi di controllo, ma non per lo scambio dei dati





Il trasferimento dei dati:



Inserimento/cancellazione di peer
Verifica periodica di altri peers (keep-alive)
Ricerca di dati
Avviene su connessioni distinte da quelle definite dalla overlay network
In genere mediante il protocollo HTTP
Connessioni basate su TCP/IP
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
3
P2P:CARATTERISTICHE GENERALI

Overlay Topology: rete virtuale stabilita tra i peer mediante connessioni
TCP per lo scambio di informazione di controllo

Caratteristiche della overlay network




completamente indipendente dalla rete fisica, grazie al livello di astrazione TCP/IP
può essere strutturata in modo gerarchico (Gnutella Superpeers, JXTA rendezvouz peers)
può includere un server centralizzato (look up server di Napster)
I peer partecipano attivamente alla overlay network

Forniscono informazione

Ricercano informazione

Svolgono funzioni di routing
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
4
RIASSUNTO DELLA PRESENTAZIONE
1.
Reti P2P centralizzate



2.
Reti Peer to Peer Pure



3.
Caratteristiche Base
Protocollo
Dicussione
Caratteristiche Base
Protocollo
Discussione
Reti Peer to Peer Ibride
1.
2.
3.
Caratteristiche Base
Protocollo
Discussione
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
5
SISTEMI P2P CENTRALIZZATI: NAPSTER

Documentazione: http://opennap.sourceforge.net/napster.txt su questo sito
trovate la specifica completa del protocollo


Tutti i peer si connettono ad un server centralizzato (broker). La topologia
dell’overlay network risultante è a stella: star overlay network.
Le connessioni tra i peers sono stabilite dinamicamente ‘on demand’ per lo
scambio dei i dati
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
6
NAPSTER:TOPOLOGIA
Servent
Connection between
2 servents (TCP)
Dipartimento di Informatica
Università degli Studi di Pisa
Connection between
router & servent
Connection between
routers (Core)
Laura Ricci
Sistemi P2P:Napster
7
NAPSTER:PRINCIPI DI FUNZIONAMENTO
Comportamento del peer (ad alto livello)





Si connette al Server Napster
Invia al Server (push) le informazioni relative ai files musicali che intende condividere
(metadata). Il server memorizza queste informazioni in un database centralizzato
Ricerca un file, fornendo una lista di keywords inviate al server
Riceve un insieme di coppie (file-peer) e sceglie una coppia in base a qulche criterio
(bitrate, frequency, tipo di collegamento)
Si connette al peer prescelto e scarica il file(connessione HTTP)
Napster
Host
Data
Transfer
Ricerca : client server
Download: P2P
Napster
Host

Napster
Host
Napster
Host
Caratteristiche

Central
Napster
Index
server
Non esistono 'falsi negativi'Si garantisce l’individuazione di un file, se
esso esiste
Il servizio di indicizzazione costituisce “a Single Point of Failure”.
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
8
NAPSTER: PRINCIPI DI FUNZIONAMENTO


Altre funzionalità

Instant messaging

Chats tra peers

Hot lists
A causa della popolarità di NAPSTER, un unico server centralizzato si è
rilevato presto insufficiente. Architetture alternative



definizione di un server farm. Si introduce un insieme di brokers. L’interfaccia
verso l’esterno rimane comunque unico (single point of failure)
introduzione di un insieme di broker Napster. Ogni broker gestisce un proprio
database

Non c’e’ condivisione di dati tra i diversi database

Ogni broker gestisce una diversa rete Napster (più reti centralizzate)

Bilanciamento del carico effettuato da un insieme di look-up servers
Coordinamento dei diversi brokers (verso le reti P2P ibride)
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
9
EVOLUZIONE DI NAPSTER

Definizione di un insieme di servers geograficamente distribuiti

Il server possiede solo funzionalità di indicizzazione (non può essere un
peer)


Alto numero di servers più o meno interconnessi

Si stabilisce staticamente quali nodi eseguono i servers

Full time activity

Esempio: e-mule, protocollo e-donkey
Alcuni peer assumono anche funzionalità di indicizzazione.

Super Peers, Rendez-vouz Peer

I super Peer vengono eletti dinamicamente e cooperano


Part Time Activity:assumono funzione di servers, ma continuano a
funzionare come peers
Es: JXTA
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
10
NAPSTER: STRUTTURA DELL'HEADER
Messaggi scambiati tra il peer ed il Server NAPSTER: header
HEADER 8byte
<Payload Length>
4byte
PAYLOAD
<Function>
4byte
Contiene il tipo del
messaggio (e.g.
login, search,…)
Dipartimento di Informatica
Università degli Studi di Pisa
Contiene i parametri del
messaggio(dipendente dal
tipo di messaggio,e.g.
keywords nel caso di
search,…)
Laura Ricci
Sistemi P2P:Napster
11
NAPSTER:REGISTRAZIONE
Client/Server Service
1: NEW USER LOGIN
<Nick>
<Password>
<Port>
<Speed>
<e-mail>
• Utilizzato quando l'utente si collega per la prima volta
• L'utente puo' utilizzare un messaggio di nick check per verificare
l'unicità del nickname
• Il server risponde con un msg di nickname not registered/already registered/
invalid
Napster
Host
IP: 001
Nick: laura
NEW_USER_LOGIN
LOGIN(0x02)
laura pass 6699 "nap v0.8" 3 laura@....
lkn 54332 6699 „nap v0.8“ 9
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
Central
Napster
Index
server
12
NAPSTER:INIZIALIZZAZIONE
Client/Server Service
1: LOGIN (Function:0x02)
<Nick>
<Password>
<Port>
<Client-Info>
<Link-type>
2: LOGIN ACK (Function: 0x03)
3: NOTIFICATION OF SHARED FILE (0x64)
„<Filename>“
Napster
Host
IP: 001
Nick: laura
<MD5>
<Size>
<Bitrate> <Freq>
LOGIN(0x02)
LOGIN(0x02)
laura pass 6699 "nap v0.8" 3
lkn 54332 6699 „nap v0.8“ 9
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
<Time>
Central
Napster
Index
server
13
NAPSTER LOGIN
Client/Server Service
1: LOGIN (Function:0x02)
<Nick>
<Password>
<Port>
<Client-Info>
<Link-type>
2: LOGIN ACK (Function: 0x03)
3: NOTIFICATION OF SHARED FILE (0x64)
„<Filename>“
Napster
Host
IP: 001
Nick: LKN
<MD5>
<Size>
<Bitrate> <Freq>
LOGIN ACK(0x03)
LOGIN(0x02)
lkn 54332 6699 „nap v0.8“ 9
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
<Time>
Central
Napster
Index
server
14
NAPSTER LOGIN
Client/Server Service
1: LOGIN (Function:0x02)
<Nick>
<Password>
<Port>
<Client-Info>
<Link-type>
2: LOGIN ACK (Function: 0x03)
3: NOTIFICATION OF SHARED FILE (0x64)
„<Filename>“
Napster
Host
IP: 001
Nick:
Laura
<MD5>
<Size>
<Bitrate> <Freq>
NOTIFICATION(0x64)
LOGIN ACK(0x03)
LOGIN(0x02)
„hang-up.mp3“
3f3a3... 5674544
128
342 „nap v0.8“ 9
lkn44100
54332 6699
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
<Time>
Central
Napster
Index
server
15
NAPSTER LOGIN

MD5
(acronimo di Message Digest algorithm 5) è un algoritmo per la
crittografia dei dati

MD5 prende in input una stringa di lunghezza arbitraria e produce in output una
stringa a 128 bit (32 valori esadecimali, indipendentemente dalla stringa di
input).

l'output (noto anche come "MD5 Checksum" o "MD5 Hash") restituito è con
alta probabilità univoco

È praticamente impossibile
ottenere date due diverse stringhe in input la
medesima stringa in output

È estremamente complesso risalire alla stringa di input partendo dalla stringa
di output (la gamma di possibili valori in output è pari a 16 alla 32esima
potenza).
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
16
NAPSTER LOGIN

MD5 (fingerprint) – Introdotto originariamente per

identificare univocamente file MP3 identici offerti da utenti diversi ed
identificati da chiavi diverse


tenere traccia dei files duplicati nel sistema

facilitare il download del file da utenti diversi ed il resume dei download
Nel processo contro NAPSTER, gli amministratori di NAPSTER sostennero che
era difficile individuare chi aveva registrato nel materiale illegale (sotto
copyright)

Lo stesso materiale identificato da chiavi diverse

Difficile il filtro su campi testuali
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
17
NAPSTER LOGIN

Ma....nel processo contro NAPSTER fu messo in evidenza che le canzoni
scaricate illegalmente sul sistema (ad esempio i CD appena lanciati dalle case
discografiche) potevano essere individuati facilmente tramite il loro MD5
The "fingerprints" of copyrighted sound recordings
could, and should, be used by Napster to block access to plaintiffs
plaintiff(=parte lesa)

Risultato: questo campo venne tolto in seguito alla causa legale sostenuta dalle
case discografiche contro NAPSTER

Altri campi:
Size – Dimensione in byte dl file
BitRate, Frequency – indicano la qualità dell'MP3
Time - Durata della canzone
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
18
NAPSTER LOGIN
Bitrate

File mp3 è un flusso di bit suddiviso in frames (simili ai fotogrammi di un film).

Il bitrate è il valore che indica quanti bit vengono usati per codificare un
secondo di musica .

Si esprime in kilobit per secondo (kbps) e

Maggiore sarà la quantità di bit utilizzati migliore sarà la resa

Normalmente, la qualità in ascolto è proporzionale al bitrate, dunque bitrate
sempre più alti garantiscono sicuramente qualità superiore.
Frequenza

Frequenza di campionamento del suono
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
19
NAPSTER: RICERCA
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>
<Time>
<Size>
<Nick>
<Bitrate>
<IP>
<Freq>
<Link-Type>
SEARCH(0xC8)
Central
Napster
Index
server
FILENAME CONTAINS „greendays“ MAX_RESULTS Napster
Host
100
LINESPEED „AT LEAST“ 6 BITRATE „AT
LEAST“ „128“
IP: 002
Nick:
Laura
FREQ „EQUAL TO“ „44100“
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
20
NAPSTER: RICERCA

Quando il server riceve un messaggio di SEARCH, ricerca nel proprio database
un file che soddisfi i parametri della ricerca.

Il database è creato con i dati ricevuti dai peer

Se la query è soddisfatta, ilserver risponde con almeno un messaggio di serach
response

Il messaggio di query response contiene:

Il nome completo del file

Le sue caratteristiche. Viene spedito anche l'MD5 del file. Questo verrà utilizzato per
controllare l'integrità del file scaricato


L'indirizzo IP dell'host che lo possiede
Il file viene scaricato utilizzando il protocollo HTTP
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
21
NAPSTER: IL PROTOCOLLO SEMPLIFICATO
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]
Sequenza semplificata (rispetto al protocollo reale) di messaggi di una rete
Napster con due peer. Il peer req richiede un file al Peer Prov
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
22
NAPSTER: IL PROBLEMA DELLA SCALABILITA'
S
S
S
PP
SS
P
P
P
Definizione di un cluster di server (server farm) per aumentare la
scalabilità del sistema
• I server sono localizzati in un’unica locazione geografica
Esiste comunque un unico punto di accesso al sistema (esempio i router
che collega il cluster alla rete)
• i server condividono il database contenente le meta-informazioni
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
23
NAPSTER: IL PROBLEMA DELLA SCALABILITA'
Bilanciamento del carico: vengono definiti m lookup servers ed n brokers



Brookers: gestiscono i metadata (informazioni sui files)
Look-up servers: ricevono le richieste dagli utenti e smistano le richieste ai
broker in modo da bilanciare il carico. Ogni look-up server è collegato ad
ognuno dei broker per conoscere il suo carico
I brokers sono interconnessi in modo da condividere i metadati
Peer
lookup2
lookup1
Broker1
Peer
…………..
Broker2
Dipartimento di Informatica
Università degli Studi di Pisa
………… lookupm
Broker3
Laura Ricci
Sistemi P2P:Napster
Brokerm
24
NAPSTER: ARCHITETTURA
Bilanciamento del carico



L’intero sistema può essere acceduto mediante un unico punto di entrata,
rappresentato mediante un unico nome simbolico (es: server.napster.com,
porta 8875)
Il DNS locale può effettuare il bilanciamento del carico, distribuendo le
richieste ai diversi look-up servers
Tecnica utilizzata per server che devono gestire un alto tasso di richieste
(es: cnn.com, java.sun.com,…)

Si definisce un server farm

Il DNS associa al nome simbolico dell’host un insieme di indirizzi IP

Il DNS restituisce tutto l’insieme di indirizzi IP al richiedente, ma ruota l’ordine
degli indirirzzi. Poiché il client sceglie in genere il primo indirizzo IP, si ottiene un
bilanciamento del carico sui diversi
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
25
P2P IBRIDO vs. SERVER FARM
S
S
S
S
P
P
P
P
P
P
P
SP
SP
P
P
SP
P
P
•i servers sono collocati in un’unica
locazione geografica
P
P
•L’insieme di servers è geograficamente
distribuito
⇒
maggiore individuabilità
•un server ha solo funzionalità di
coordinamento (full time activity)
Dipartimento di Informatica
Università degli Studi di Pisa
•Il super peer è un peer che si assume
anche funzionalità di coordinamento
(part time activity)
Laura Ricci
Sistemi P2P:Napster
26
P2P ibrido vs. Server Farm
S
S
S
S
P
P
P
P
P
P
P
SP
SP
P
P
SP
P
P
P
•Super peer sono eletti dinamicamente
• L’ insieme dei servers è definito
staticamente
•Unico punto di accesso al sistema
⇒
scarsa tolleranza ai guasti
Dipartimento di Informatica
Università degli Studi di Pisa
P
• Nel caso di fault di un superpeer
il sistema si riconfigura eleggendo
altri superpeers
Laura Ricci
Sistemi P2P:Napster
27
NAPSTER: IL PROTOCOLLO COMPLETO



Un peer P riceva da un broker Napster una lista di peer che condividono una
canzone ricercata. P sceglie un peer S dalla lista.
La creazione della connessione tra P ed S viene coordinata dal broker B.
Questo consente ai peer di accettare connessioni solo se “certificate” da B.

P notifica a B che intende scaricare un file da S

B notifica ad S la richiesta di P

S notifica a B la propria disponibilità ad accettare la connessione

B notifica a P la risposta di S

A questo punto P può aprire una connessione con S per il trasferimento dei dati
Supponiamo che S si trovi a monte di un firewall.

S notifica a B la propria indisponibilità ad accettare connessioni

S effettua un push del file verso P = S apre una connessione verso P e gli invia il file
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
28
NAPSTER: STRUTTURA DI UN PEER
Coordinatore
Gestore Download
Gestore Upload
Gestore delle
connessioni
Gestore Push
Struttura del Peer Napster
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
29
NAPSTER: STRUTTURA DI UN PEER

Il coordinatore gestisce:



le connessioni e le comunicazioni con il look-up server e quindi con il
Broker
l’interazione con l’utente: ricerca di files, download, rimozione di files,
etc.
Il gestore delle connessioni si occupa di gestire tutte le richieste di
connessione provenienti dagli altri peers (richieste di connessione per upload
o per push)

I gestori di download, upload,push, gestiscono lo scambio diretto dei dati tra i
peers


Possono esistere più istanze di questi gestori. Ogni istanza si occupa di un
singolo trasferimento
Push: utilizzato per peer che si trovano a monte del firewall.
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
30
NAPSTER: STRUTTURA DI UN PEER

Tutte le comunicazioni avvengono tramite TCP/IP

Per unirsi alla rete Napster il peer

Apre una connessione con un look-up server (porta 8875)

Il look-up server restituisce l’indirizzo di uno dei brokers (porta 6699)

Si connette al broker ed invia l’informazione relativa ai dati che vuole condividere
(metadata)

Attende messaggi dal broker, oppure connessioni da altri peer (porta 6699) o
eventi generati dall’utente locale
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
31
NAPSTER:STRUTTURA DI UN PEER



In Napster il download peer-to-peer di un file viene coordinato dal broker in
modo centralizzato
Download di un file: P1 vuole scaricare un file dal peer P2

P1 invia al proprio broker la richiesta di download (download request)

Il broker invia a P2 una richiesta di upload (upload request)

P2 invia al broker l’ack (upload accept+porta su cui effettuare la connessione)

Il broker invia a P1 l’ack (download accept)

P1 apre una connessione verso P2

Il file viene spedito da P2 sulla connessione aperta (upload)
Il coordinamento centralizzato consente di introdurre un livello di sicurezza
⇒
un peer non accetta una connessione se prima non ha ricevuto una richiesta
di upload
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
32
NAPSTER: STRUTTURA DI UN PEER

Se il peer P1 che possiede il file F non si trova a monte di un firewall, il peer P2
che vuole scaricare F apre una connessione sulla porta specificata dal server

P2 accetta la connessione

P1 invia una GET, poi invia un messaggio
<mynick> "<filename>" <offset>
<offset> è l'offset in F che indica il primo byte che si intende scaricare (0 la
prima volta)

P2 restituisce la lunghezza del file, oppure un messaggio di errore

Se non ci sono errori P2 inizia ad inviare il file
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
33
NAPSTER: STRUTTURA DI UN PEER


Alcuni peer possono trovarsi a monte di un firewall

In questo caso, in generale, il peer non può accettare connessioni dall’esterno

Supponiamo che il peer possa aprire connessioni verso l’esterno

Almeno uno dei due peer deve accettare connessioni dall’esterno
P1 vuole scaricare un file da un peer P2 che si trova a monte di un firewall

P1 invia al proprio broker la richiesta di download (download request)

Il broker invia a P2 una richiesta di upload (upload request)

P2 invia al broker l’ack indicando la disponibilità di effettuare l’upload, ma
l’impossibilità di accettare connessioni dall’esterno(upload accept, porta = 0)

Il broker invia a P1 l’ack (download accept, porta =0)

P1 dichiara di accettare la connessione da P2 (alternate download request)

Il broker invia a P2 l’ack (alternate download ack)

P2 apre una connessione verso P1

Il file viene spedito da P2 sulla connessione aperta (push)
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
34
STRUTTURA DI UN PEER:IL COORDINATORE
Offline
Connessione
non accettata
Connessione al
LookupServer
Attesa Best
Broker
ricezione IP Best Broker/
Connessione rifiutata
chiusura connessione con il LookupServer
o ricezione login nack
apertura connessione con il best broker
invio login o new login al best broker
Attesa Login
Ricezione login ack
Logged in
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
35
STRUTTURA DI UN PEER: IL COORDINATORE
Chiusura
connessione
Offline
Chiusura
connessione
Logged in
Query dal client/
Invio query al broker, imposta timeout
Fine Risposte/ Timeout
Upload
Meta Dati
fine
notifica
fine risposta
o timeout
Ricerca
risposte query
Notifica file condiviso dal client/
Invio notifica al broker
Eventi Asincroni
(messaggi dal broker, eventi generati dall’utente,vedi pagina
successiva)
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
36
STRUTTURA DI UN PEER: IL COORDINATORE
Eventi Asincroni

Ricezione di statistiche da parte del server

Richiesta di cancellazione di un file (dall’utente) / invio meta dati al broker

Richiesta di download da parte dell’utente / invio download request al server




Richiesta di upload da parte del broker / invio (upload accept + porta, porta ≠
0 se posso accettare connessione, porta = 0 se non posso accettare
connessioni, perché a monte di un firewall) oppure accept failed
Ricezione di dowload ack con porta > 0/ apertura connessione con il peer
remoto, attivazione di un’istanza del Gestore di Download
Ricezione di download ack con porta = 0/ invio di alternate-download request
al server o rifiuto ad accettare connessione (se il peer si trova a monte di un
firewall)
Ricezione di alternate download ack/ attivazione di un’istanza del Gestore di
Push
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
37
NAPSTER: GESTIONE DELLE CONNESSIONI
Gestore delle connessioni: schema generale
In attesa di
connessione
Richiesta SEND/
attivazione di
una istanza del Gestore
di Download
Richiesta GET/
attivazione di una istanza del
Gestore di Upload
Una connessione può essere aperta da
un peer che richiede il download (GET): invio i dati, attivo una istanza del
gestore di upload
un peer che esegue la push (SEND): ricevo i dati
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
38
NAPSTER: STRUTTURA GENERALE DEL PEER

Gestore Download = riceve il file dal peer remoto e lo memorizza sul disco
(esegue una sequenza di receive)


Gestore Upload = spedisce il file al peer remoto che lo ha richiesto (esegue
una sequenza di send)
Gestore Push = apre una connessione verso il peer remoto e spedisce il file
richiesto (come sopra, ma apre anche la connessione)
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
39
NAPSTER: VALUTAZIONE DEL PROTOCOLLO


Consideriamo un utente che condivide 10 files e richiede un file che è condiviso
da altri 20 utenti
Traffico sulla rete generato dal protocollo (solo messaggi per
l'implementazione del protocollo, non download
(login + login-ack) + 10* notif + 1 * serch + 10 * response
login = 40 bytes, login_ack= 4 bytes, notif = 74 bytes,
search = 130 bytes, response = 200 bytes
40 + 4 + 10* 74 + 130 + 10* 200 = 2914 bytes

2914 bytes per la gestione del protocollo
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
40
NAPSTER: VANTAGGI E SVANTAGGI


Svantaggi: Server centralizzato

Collo di bottiglia

Limitata scalabilità

Poco affidabile (single point of failure)
Vantaggi





Ricerca veloce (one hop lookup)
Ricerca completa = assicura che, se una informazione esiste nel sistema,
essa viene individuata
L'entità centralizzata garantisce funzionalitàm di controllo/sicurezza
Minimizzazione dei messaggi spediti sulla rete. Non richiesti messaggi per
la riconfigurazione dinamica della rete (vedi keep-alive in Gnutella)
Idee di base ripresa da

BitTorrent

E-mule- E-donkey

......
Dipartimento di Informatica
Università degli Studi di Pisa
Laura Ricci
Sistemi P2P:Napster
41