RETI DI CALCOLATORI II

RETI DI CALCOLATORI II

Facoltà di Ingegneria

Università degli Studi di Udine

Ing. DANIELE DE CANEVA

RETI DI CALCOLATORI II

Facoltà di Ingegneria

Università degli Studi di Udine

a.a. 2009/2010

ARG OM ENT I DELLA LEZIONE

ROUTING MULTICAST

o IGMP

o TECNICHE

o PROTOCOLLI REALI

RETI P2P

o DIRECTORY CENTRALIZZATA o DIRECTORY DISTRIBUITA

o RETI IBRIDE

ROU TING MU LTICAST

ROUTING MULTICAST

Broadcast: la destinazione corrisponde a tutti i nodi

Multicast: la destinazione è sottoinsieme di nodi della rete

applicazioni tipo: distribuzione degli aggiornamenti del software, streaming eventi e conferenze, giochi

distribuiti multiplayer

ROU TING MU LTICAST

ROUTING MULTICAST

“indirettezza dell’indirizzo”: un identificatore viene utilizzato per contraddistinguere un gruppo di destinazione

Internet utilizza indirizzi di classe D

! problematiche:

 modalità fondazione/scioglimento del gruppo

 modalità di adesione

 privacy/conoscenza reciproca tra i partecipanti

ROU TING MU LTICAST - IG MP

IGMP (Internet Group Management Protocol)

Opera localmente tra l’host e il router al quale è direttamente connesso

CARATTERISTICHE:

• attualmente nella ver 2 definita nella RFC 3376

• permette all’host di avvisare il router che vuole far parte di un certo gruppo

• messaggi incapsulati dentro IP (tipo di protocollo = 2)

ROU TING MU LTICAST - IG MP

IGMP (Internet Group Management Protocol)

3 tipi di pacchetti:

• membership_query: il router chiede a tutti gli host collegati al link se aderiscono a particolare gruppo

• membership_report: un host dichiara interesse a partecipare a un gruppo

 può essere mandato senza attendere richiesta del router

• leave_group: opzionale!!!

 principio del soft-state: lo stato viene alterato da un

timer

ROU TING MU LTICAST - IG MP

IGMP (Internet Group Management Protocol)

NOTE:

• opera solo localmente

• adesione è guidata dal destinatario!

 chi trasmette non può controllare partecipanti

 l’host non conosce gli altri appartenenti al gruppo

ROU TING MU LTICAST - TEO RIA

ROUTING MULTICAST

obiettivo: trovare l’albero che collega tutti i router connessi agli host appartenenti al gruppo multicast

APPROCCI:

• albero condiviso: analogo al broadcast con albero di copertura

 un unico albero formato per mezzo di messaggi di adesione unicast

 critico come selezionare il centro dell’albero

ROU TING MU LTICAST - TEO RIA

ROUTING MULTICAST

• albero basato sull’origine: un albero per ogni mittente

 analogo a RPF dove il trasmittente costituisce la radice dell’albero

 pruning: un router può scollegarsi dall’albero per mezzo di messaggi di potatura

 se un router riceve un pacchetto di potatura da tutti i router downstream allora può inviare

richiesta di potatura al router upstream

ROU TING MU LTICAST - PROTOCOLLI

DVMRP (Distance Vector Multicast Routing Protocol)

CARATTERISTICHE

• definito in RFC 1075

• tecnica dell’albero basato sull’origine con RPF e potatura

 algoritmo DV per calcolare il link che si trova sul percorso minimo da ciascuna possibile origine

 mantiene lista router downstream per eventuale richiesta di potatura in upstream

 il messaggio di potatura ha validità di 2 ore

 possibili messaggi di innesto per rimuovere

potatura

ROU TING MU LTICAST - PROTOCOLLI

PIM (Protocol Independent Multicast)

CARATTERISTICHE

• definito in RFC 2362

• prevede 2 scenari:

 modalità densa: i membri del gruppo sono concentrati in un’area

o RPF flood-and-prune, concettualmente simile a DVMRP

 modalità sparsa: il numero dei router con membri del gruppo è piccolo rispetto al totale dei router

o approccio basato sul centro

ROU TING MU LTICAST

DIFFUSIONE E PROBLEMATICHE

Diffusione e problemi

• non esiste protocollo unico per tutti gli AS

 regole di interoperabilità per i principali protocolli multicast (RFC 2715)

! devono accordare approcci completamente differenti dei diversi protocolli

• attualmente si preferiscono sovrastrutture con

distribuzione multicast a livello applicazione.

PEER TO PEER

P2P (PEER-TO-PEER)

Dal 2004 il traffico P2P è diventato maggiore rispetto a qualsiasi altra applicazione

VANTAGGI:

• banda

• capacità di memorizzazione

• CPU

PROBLEMATICHE:

• utenti non stabili e con IP non fisso

• localizzazione contenuti

PEER TO PEER - NAPSTER

DIRECTORY CENTRALIZZATA - NAPSTER

CARATTERISTICHE:

• ogni peer informa il server centrale del proprio indirizzo e dei contenuti posseduti

 notifica di scollegamento da parte dei peer

 sistema di query periodiche per controllare attività

• il server centrale mantiene un database che associa

contenuto ad elenco di indirizzi IP

PEER TO PEER - NAPSTER

DIRECTORY CENTRALIZZATA - NAPSTER

IP, info contenuti

IP, info contenuti

IP, info contenuti IP, info contenuti

IP, info contenuti IP, info contenuti

A B

D E

F C

query

reply A B

C

D E

F

PEER TO PEER - NAPSTER

DIRECTORY CENTRALIZZATA - NAPSTER

PEER TO PEER - NAPSTER

DIRECTORY CENTRALIZZATA - NAPSTER

file A B

C

D E

F

PEER TO PEER - NAPSTER

DIRECTORY CENTRALIZZATA - NAPSTER

SVANTAGGI:

• single point of failure

• collo di bottiglia per le prestazioni

! database centralizzato ampio e performante

• diritti d’autore

PEER TO PEER -GN UT ELLA

GNUTELLA

CARATTERISTICHE:

• approccio completamente distribuito

• specifiche del protocollo scarne

• i peer formano un’overlay network

• grafo con collegamenti tra i nodi non corrispondenti a link fisici

 un singolo peer è connesso a meno di altri 10 nodi

PEER TO PEER - GN UT ELLA

OVERLAY NETWORK

INTERNET

PEER TO PEER - GN UT ELLA

OVERLAY NETWORK

BOOTSTRAP:

1. il client A mantiene una lista di nodi che fanno spesso parte della rete o contatta un sito Gnutella con tale lista 2. A tenta di connettersi ai peer della lista fino a quando

non ha successo (connessione con nodo B)

3. A invia a B un Gnutella-Ping con campo contatore

4. B inoltra il messaggio ai vicini, i quali lo inoltrano a loro

volta e così via fino a quando il contatore non si azzera

PEER TO PEER - GN UT ELLA

OVERLAY NETWORK

BOOTSTRAP:

6. i client che ricevono il messaggio rispondono con un messaggio Gnutella-Pong contenente il loro IP

 attraverso la rete di copertura fino ad A

7. A si connette via TCP con un certo numero di client che hanno risposto

 numero non stabilito dallo standard

PEER TO PEER - GN UT ELLA

OVERLAY NETWORK

QUERY FLOODING:

• Gnutella-Query inviato a tutti i vicini

1. se client ha il contenuto allora risponde con messaggio Quer-Hit (nome file, dimensione) attraverso l’overlay network

2. connessione TCP diretta con nodo scelto dall’elenco

 HTTP GET esterna all’overlay network

PEER TO PEER - GN UT ELLA

OVERLAY NETWORK

SVANTAGGI:

• scalabilità: l’overlay network viene inondata dal query flooding

soluzione: query flooding limitato

• quando il campo di conteggio diventa pari a 0 la query non viene inoltrato oltre

! meno traffico ma meno contatti: altra probabilità di

non trovare contenuti anche se presenti nella rete

PEER TO PEER - K A Z A A

KaZaA

sviluppatori Niklas Zennström e Janus Friis (..Skype) CARATTERISTICHE:

• tecnologia proprietaria, traffico di controllo è criptato

• fonde le due tecniche precedenti

 non ci sono server dedicati

 peer con più banda designati come peer-leader e

sovrintendono ad alcune centinaia di nodi

PEER TO PEER - K A Z A A

KaZaA

PEER TO PEER - K A Z A A

KaZaA

CARATTERISTICHE:

• client stabilisce connessione TCP verso leader del gruppo e vengono comunicati i contenuti messi in condivisione

o creato un database con contenuti – elenco IP

analogo a un hub napster

PEER TO PEER - K A Z A A

KaZaA

CARATTERISTICHE:

• i leader si collegano tra loro in TCP -> rete simile a gnutella

o rete simile a gnutella

o condivisione contenuti tra i vari gruppi

 fusione dei database

 query specifiche (come gnutella ma il flooding avviene a livello di supernodi)

 contattati tutti i peer con poco traffico!

PEER TO PEER - K A Z A A

TECNICHE AGGIUNTIVE:

• accodamento delle richieste: limite al numero di upload per garantire banda accettabile

• incentivo di priorità: basato sul comportamento dell’utente

 tecniche anti-leech

• download parallelo: utilizzo di HTTP GET con byte

range