Introducci´on a las Arquitecturas Peer-to-Peer
(P2P)
LSUB
GSYC
28 de abril de 2015
(cc) 2015 Laboratorio de Sistemas,
Algunos derechos reservados. Este trabajo se entrega bajo la licencia Creative Commons Reconocimiento NoComercial - SinObraDerivada (by-nc-nd). Para obtener la licencia completa, v´
ease
http://creativecommons.org/licenses/. Tambi´
en puede solicitarse a Creative Commons, 559 Nathan Abbott Way,
Stanford, California 94305, USA.
Las im´
agenes de terceros conservan su licencia original.
P2P vs C/S
• En el modelo cliente/servidor tenemos muchos clientes que
piden servicio a un servidor.
• En el modelo Peer-to-Peer (entre iguales), los participantes se
comportan como clientes y tambi´en como servidores.
• Los peers son din´
amicos, aparecen y desaparecen a lo largo del
tiempo.
Modelos
P2P con b´
usqueda centralizada (modelo h´ıbrido):
• Un servidor central contiene el mapa entre peers y contenido,
recursos del peer (ancho de banda, etc.).
• Las altas/bajas en la red se realizan en el servidor central.
• Las b´
usquedas se realizan en el servidor.
• La comunicaci´
on se realiza entre los peers.
• Desventaja: u
´nico punto de fallo en el servidor central.
• Ejemplo: Napster.
Ejemplo: BitTorrent
BitTorrent es la red P2P m´as usada actualmente:
• Es una red P2P h´ıbrida.
• El fichero se parte en trozos de 512/256 Kb. Cada trozo se
identifica y verifica con su hash SHA-1.
• El fichero .torrent contiene inforaci´
on sobre el fichero: nombre,
tama˜
no, bytes por trozo, SHA-1 de los trozos, y URL del
tracker.
• El tracker es un servidor que tiene la lista de los peers que
est´an compartiendo un fichero en concreto. El peer manda su
info al tracker y se baja la info de los otros peers del swarm
(enjambre).
Nota: El tracker puede ser substituido por una DHT (ver m´as
adelante): trackless torrent.
Ejemplo: BitTorrent
• Swarm: conjunto de peers que est´
an compartiendo un fichero
en concreto.
• Seed: un peer que tiene el fichero entero. Para poner un
fichero en BitTorrent tenemos que proporcionar un seed
original
• Cuando un peer consigue el fichero entero se convierte en
seed. Mientras tanto, es un leecher. Todos suben partes del
fichero mientras bajan otras.
Modelos
P2P asim´etrico (Superpeers):
• Existen dos tipos de peers, los normales y los superpeers.
• Los peers contienen los contenidos.
• Los superpeers contienen informaci´
on sobre algunos peers y
los superpeers.
• Los superpeers conocen a todos los dem´
as superpeers y
comparten con ellos la lista de peers que conocen con el
contenido.
• Las altas/bajas se realizan en un superpeer.
• Las b´
usquedas se realizan en un superpeer, que las propaga a
otros superpeers para encontrar un contenidos.
• Normalmente tienen una naturaleza est´
atica y son conocidos.
Modelos
P2P puro (sim´etrico):
• Todos los peers son iguales.
• Redes P2P puras no estructuradas: la red superpuesta
(overlay) es un grafo aleatorio.
• Redes P2P puras estructuradas: la red superpuesta se
construye mediante un algoritmo.
• ¿C´
omo se da de alta/baja un peer en la red?
• ¿C´
omo se busca en la red?
Modelos
P2P puro no estructurado:
• Alta: el peer tiene que conocer al menos un peer para poder
engancharse a la red overlay.
• Baja: baja expl´ıcita en los nodos vecinos o por timeout.
• B´
usqueda b´asica: por caminos aleatorios, por inundaci´on
(campo activo de investigaci´
on con muchas variantes
propuestas).
• Ventajas: overlay robusto ante fallos o ataques.
• Inconvenientes: b´
usqueda complicada y poco eficiente.
• Ejemplo: Gnutella, Kazaa.
P2P pura no estructurada
B´
usqueda por inundaci´
on:
• El peer pregunta a todos sus vecinos.
• Se aplica de forma recursiva: cada peer que recibe la
b´
usqueda la propaga a todos sus vecinos.
• Si un peer tiene el recurso, responde al que pregunta y no
propaga la b´
usqueda.
• Se limita el alcance de la b´
usqueda con una profundidad
m´axima.
• Hay problemas de escalabilidad: la propagaci´
on es exponencial
y los peers se sobrecargan con peticiones de b´
usqueda.
• La b´
usqueda es lenta.
P2P pura no estructurada
B´
usqueda por caminos aleatorios:
• El peer pregunta a uno o varios vecinos elegidos al azar.
• Se aplica de forma recursiva: cada peer que recibe la
b´
usqueda la propaga a uno o varios vecinos elegidos al azar.
• Si un peer tiene el recurso, responde al que le pregunta y no
propaga la b´
usqueda. La respuesta se encamina
• Tambi´
en se limita el alcance de la b´
usqueda con una
profundidad m´axima.
• La b´
usqueda es lenta.
P2P pura estructurada
• Cada peer tiene una posici´
on en la red overlay siguiendo una
topolog´ıa.
• Las b´
usquedas son mucho m´as eficientes.
• La implementaci´
on habitual es una Tabla Hash Distribuida
(DHT).
• Hay distintas DHT con distintos algoritmos de rutas y
diferentes estructuras: Chord, Pastry, Kademliam...
Ejemplo: Chord
• Cada peer tiene un ID u
´nico de m bits, 0 .. 2m − 1.
• Los IDs se ordenan en un c´ırculo (identifier circle) m´
odulo 2m .
• Se define el sucesor de un ID como el siguiente en el c´ırculo
siguiendo las agujas del reloj.
• Un peer conoce a su sucesor y su antecesor.
• P. ej. un c´ırculo con m=3:
Ejemplo: Chord
• Un elemento con clave K se almacena en el peer sucesor (K )
que est´e en la red
Ejemplo: Chord
Routing b´asico:
• Cada peer conoce a sus vecinos (antecesor y sucesor).
• Para llegar al nodo que tiene el elemento, se recorre el c´ırculo,
O(n).
Alternativa: Finger Table
• Un nodo A conoce los nodos:
A, A + 21 , A + 22 , A + 23 , ..., A + 2n
• Para llegar al nodo que tiene el elemento, salta al m´
as cercano
y despu´es se recorre el c´ırculo restante, O(log (n)).
Ejemplo: Chord
Cuando se une un nuevo peer (A), que tiene que conocer a alg´
un
otro peer (B)
• Se elige el ID de A con SHA-1(Ip, Port).
• Se inicializa la finger table y su antecesor (se pide a B que lo
resuelva).
• Se manda actualizar las finger tables y el antecesor del resto
de peers.
• Se manda transferir las claves/valor correspondientes al nuevo
nodo de la red (el antecesor de A se las transfiere a A).
Se ejecuta periodicamente un protocolo de estabilizaci´
on para
mantener los sucesores de los peers actualizados.
Ejemplo: Chord
Fallo de un peer:
• Aunque los pares clave/valor del peer fallido ya no se
encuentren en la tabla, el resto de la tabla tiene que seguir
funcionando.
• Un peer en realidad almacena una lista de los R sucesores m´
as
cercanos en el c´ırculo.
• Si un peer da a su sucesor como fallido, lo reemplaza con el
m´as cercano de la lista que est´e vivo.
• El protocolo de estabilizaci´
on har´a que los sucesores y las
finger tables terminen actualizadas.
• Se pueden guardar r´
eplicas de las clave/valor en los peers de
la lista de R sucesores.
Referencias
Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and
Hari Balakrishnan. Chord: A scalable peer-to-peer lookup
service for internet applications. SIGCOMM Comput.
Commun. Rev. 31, 4 (August 2001), 149-160.
http://doi.acm.org/10.1145/964723.383071