Protocolo GNUTELLA Daniel Sánchez Pedreño Sistemas Distribuidos Facultad de Informática

Download Report

Transcript Protocolo GNUTELLA Daniel Sánchez Pedreño Sistemas Distribuidos Facultad de Informática

Protocolo GNUTELLA
Daniel Sánchez Pedreño
Sistemas Distribuidos
Facultad de Informática
Universidad de Murcia
Índice de contenidos

Ideas Principales

Historia

¿Cómo funciona?

En detalle

GGEP

Ultrapeers

Transferencia de archivos

Bibliografía
27/05/2016
Sistemas Distribuidos
2
Ideas principales




Gnutella es un sistema peer-to-peer descentralizado.
Permite a cada par compartir, buscar y obtener
recursos de cualquier sistema conectado a la red
Las búsquedas por la red se hacen entre nodos al estilo
round-robin
El intercambio de datos entre nodos está recogido en el
estándar HTTP y es independiente a Gnutella
27/05/2016
Sistemas Distribuidos
3
Historia





Los desarrolladores fueron Justin Frankel y Tom Pepper en el
año 2000 mientras trabajaban en Nullsoft
El código fuente iba a salir bajo licencia GNU pero AOL se
interpuso. La ingeniería inversa se puso en funcionamiento. Se
tardó 6 días :D
Este protocolo se presentaba como la gran esperanza tras la
caída en picado de Napster en 2001.
Actualmente su desarrollo se lleva a cabo por el GDF
El nombre del protocolo es un enigma. Pero muchos aseguran
que viene de GNU y …
27/05/2016
Sistemas Distribuidos
4
¿Cómo funciona?





Un cliente A se conecta a otro B, mediante un mecanismo de
bootstrap, dirección bien conocida o algún mecanismo similar.
B envía a A una lista de nodos actualmente activos en la red
A se conectará a un número determinado de ellos
(normalmente 5) y guarda el resto
Cuando A realice una búsqueda manda las peticiones a los
nodos a los que está conectado. Estos a su vez harán un
forwarding de la petición
Al encontrar resultados se reenvían hacia A directamente o
bien indirectamente
27/05/2016
Sistemas Distribuidos
5
¿Cómo funciona? Esquema
A
B
H1
27/05/2016
H2
H3
H4
H5
Sistemas Distribuidos
6
El protocolo en detalle

Inicializar una conexión

Cabecera

Ping

Pong

Query

Query hit

Push

Bye
27/05/2016
Sistemas Distribuidos
7
Inicializar una conexión

1.
2.
3.
4.
5.
6.
El puerto de escucha por defecto es el 6346
El cliente (iniciador) establece una conexión TCP con el
servidor (receptor)
El cliente envía “GNUTELLA CONNECT/0.6” acompañado
de las cabeceras de opciones
El servidor responde “GNUTELLA/0.6 200” acompañado
de sus cabeceras de opciones
El cliente responde “GNUTELLA/0.6 200 OK” si desea
realizar la conexión
El cliente envía las cabeceras Vendor-specific
necesarias
El servidor envía las ceabeceras Vendor-specific
necesarias
27/05/2016
Sistemas Distribuidos
8
Inicializar una conexión: Ejemplo
Client
Server
---------------------------------------------------GNUTELLA CONNECT/0.6
User-Agent: BearShare/1.0
Pong-Caching: 0.1
GGEP: 0.5
GNUTELLA/0.6 200 OK
User-Agent: BearShare/1.0
Pong-Caching: 0.1
GGEP: 0.5
Private-Data:5ef89a
GNUTELLA/0.6 200 OK
BearShare-Data: a04fce
[binary messages]
27/05/2016
[binary messages]
Sistemas Distribuidos
9
Cabecera


Una vez conectados dos nodos, se pueden comunicar
utilizando mensajes del protocolo.
Cada mensaje es precedido de una cabecera de mensaje de
23 bytes.
0
16
Message
ID





17
Payload
Type
18
TTL
19
HOPS
22
Payload
Lenght
Message ID: identificador único de mensaje
Payload Type: Ping, Pong, Bye, Push, Query, Query Hit
TTL: número de veces que se puede hacer forwading
HOPS: el número de veces que ha sido forwarded
Payload Lenght: longitud del mensaje de protocolo
27/05/2016
Sistemas Distribuidos
10
Ping (0x00)




Los paquetes Ping se utilizan para descubrir hosts en la
red
Un nodo que reciba un Ping debería responder con 1 o
más mensajes Pong
Estos mensajes no llevan Payload
Opcionalmente pueden contener alguna extensión
GGEP
27/05/2016
Sistemas Distribuidos
11
Pong (0x01)



Emitidos en respuesta a un mensaje Ping. Un Ping puede
provocar el envío de 1 o más paquetes Pong de respuesta
La cabecera debe tener el mismo ID que la cabecera del Ping
que ocasiona el Pong
0
Port
Number





2
6
IP
Address
10
Shared
Files
Number
14
Shared
Files Size
-
OPTIONAL
GGEP
Port Number: puerto para las conexiones de entrada
IP Address: dirección IP del host
Shared Files Number: número de ficheros compartidos
Shared Files Size: tamaño en KB’s de ficheros compartidos
OPTIONAL GGEP: bloque GGEP opcional
27/05/2016
Sistemas Distribuidos
12
Uso de Ping y Pong




Cuando se recibe un Ping con TTL>1 y ha pasado más
de 1 segundo desde el anterior se debe responder con
1 o más Pong. 10 es un número razonable.
Los hosts deben minimizar el número de Pings y Pongs
para no consumir bandwidth
Un Ping con TTL=1 y Hops=0 se utiliza para probar al
host remoto de una conexión. Debe responderse con un
Pong
Un Ping con TTL=2 y Hops = 0 se denomina “Crawler
Ping”. Se debe responder con varios Pong que
contengan la información del host que recibió el Ping y
de sus vecinos. (La información de sus vecinos se puede generar en el
propio host o bien reenviando el Ping original a sus vecinos.)
27/05/2016
Sistemas Distribuidos
13
Query (0x80)


Mecanismo para realizar búsquedas por la red. Si hay éxito se
responde con un Query Hit
Al ser enviados a varios nodos su tamaño no debe exceder
256 bytes. Un host puede eliminar mensajes de más de 256
bytes y debe eliminarlos si son de más de 4 KB
0
Minimun
Speed



2
Search
Criteria
Rest
Minimun Speed: velocidad mínima en kb/s a la que debe
responder el receptor del mensaje
Search Criteria: criterio de búsqueda. Terminado en 0x00
Rest: Extensiones Opcionales del Query. GGEP, HUGE, XML
27/05/2016
Sistemas Distribuidos
14
Query Hit (0x81)

0
Este tipo de mensaje se genera en respuesta a un Query
1
3
Hits
Port
IP
Address
Number








7
11
-x
Speed Result X
Set
x
Private
Data
Last 16
Servent
ID
Hits Number: número de Query Hits en el Result Set
Port: el puerto por el que aceptar peticiones HTTP
IP Address: dirección del responding host
Speed: velocidad en KB/s del responding host
Result Set: conjunto de respuestas al Query
X: bloque extra recomendado.
Private Data: datos Vendor-specific no documentados
Servent ID: ID del servent, función de la network address
27/05/2016
Sistemas Distribuidos
15
Query Hit (0x81)

El formato del Result Set es:
0
4
File
Index




8
File Size
File
Name
Extensions
Block
File index: un número local asignado por el responding host
File Size: tamaño del archivo especificado en File_index en
bytes
File Name: nombre del archivo
Extensions Block: permitidos HUGE, GGEP y texto plano.
27/05/2016
Sistemas Distribuidos
16
Uso de Query y Query Hit

Query:






Se manda cuando el usuario realiza una búsqueda.
Pueden ser generados automáticamente (no más de 1 por
hora)
El TTL no debe ser mayor de 7 y no puede ser mayor de
10. HOPS = 0.
Un servant debe hacer el forwarding de los incoming
Query a los servents a los que esté conectado siempre
que el TTL > 0
Al recibir un Query se decrementa su TTL y se incrementa
su HOPS
Un servent que reciba un mensaje con el mismo payload y
Message ID que otro recibido previamente lo descartará
27/05/2016
Sistemas Distribuidos
17
Uso de Query y Query Hit (II)

Query Hit:





Los Query Hit deben enviarse como respuesta a un Query
siempre que haya un matching entre la información local y
el Search Criteria, por la misma ruta por la que llegó al
nodo
Un Query Hit tendrá el mismo Message ID que el Query
que lo genera. El TTL será igual al número de HOPS + 2
del Query.
El método de matching para el Search Criteria no se
especifica. Las extensiones GGEP pueden ayudar a esto
Un nodo que reciba un Query Hit con Message ID que no
corresponda con el Message ID de un Query previo
descartará el mensaje
Un Query con TTL = 1, HOPS = 0 y Search Criteria = “ “
indica a un host que debe enviar toda la información sobre
sus archivos compartidos a través de Query Hits
27/05/2016
Sistemas Distribuidos
18
Push (0x40)


Este mensaje se utiliza para realizar peticiones de descarga a
un host tras un cortafuegos
Un servent puede enviar un Push si el emisor de un Query Hit
no soporta conexiones de entrada
0
16
Servent
Identifier





20
File
Index
24
IP
Address
26
Port
-
Optional GGEP
Servent Identifier: identificador único de 16 bytes del
servent indicado en el Query Hit previo al Push
File Index: el índice local extraído del Query Hit previo al Push
IP Address: la IP del servent, extraída del Query Hit previo
Port: puerto del servent, extraído del Query Hit previo
Optional GGEP: bloque opcional
27/05/2016
Sistemas Distribuidos
19
Bye (0x02)






Mensaje opcional usado para indicar a los servent a los
que estás conectado, que vas a cerrar la conexión.
El soporte de este mensaje se indica en el hanshake
mediante la cabecera Bye-Packet: 0.1
Un servent que mande un Bye entra en un “periodo de
gracia”, mientras que el otro extremo no se entere.
En el momento de recibir un Bye, se ha de cerrar la
conexión con el remitente del mensaje.
En el “periodo de gracia” todos los paquetes son
descartados a excepción de Query Hits y Push que
deben seguir siendo propagados.
El periodo de gracia expira cuando se obtenga una
condición EOF en la lectura.
27/05/2016
Sistemas Distribuidos
20
GGEP






“Gnutella Generic Extension Protocol”
Un bloque GGEP es un framework para extensiones de
paquetes
Es recomendado que un servent implemente GGEP pero
no imprescindible. Un servent que no lo implemente y
reciba este tipo de cabeceras debe ignorarlas
Un servent indica que implementa GGEP en el
handshake mediante la cabecera GGEP: 0.5
Un servent debería eliminar las extensiones GGEP en
los mensajes destinados a un servent que no lo
implemente
Cualquiera puede implementar una nueva extensión
GGEP para lo cual deben proporcionar el ID, formato y
tamaño de datos esperado para la extensión, al GDF
27/05/2016
Sistemas Distribuidos
21
GGEP: Formato


Cada bloque GGEP comienza con un “byte mágico” para
ayudar a diferenciarlo del resto de datos. Este byte es
0xC3
Los diferentes campos son:




Flags: 1 byte. Son opciones para describir el resto de la
cabecera GGEP
ID: entre 1 y 15 bytes (determinado por las flags). El el
identificador único de la extensión. Debe evitarse el byte
0x00
Data Length: de 1 a 3 bytes. Indica la longitud del campo
Extensión Data
Extension Data: datos propios de cada extensión. De
formato y tamaño variable. Si un servent no conoce el ID
de la extensión se saltaría esta parte gracias al Data
Length para llegar a la siguiente extensión.
27/05/2016
Sistemas Distribuidos
22
Ultrapeers


Para paliar los problemas de ancho de banda nace el
sistema Ultrapeer
Existen dos tipos de nodos:





Hojas: mantienen abiertas unas solo unas pocas
conexiones a Ultrapeers
Ultrapeers: actúan como proxys entre las hojas y la red
Conseguimos hacer la red más escalable porque
reducimos el número de nodos que intervienen en ella
Un Ultrapeer solo manda mensajes que considere que
sus hojas pueden responder
Es recomendable que los host implementen el sistema
Ultrapeer
27/05/2016
Sistemas Distribuidos
23
Ultrapeer: Elección


Dado que el protocolo es descentralizado los ultrapeers
son elegidos sin la ayuda de un servidor central
Algunos requerimientos son:







Suficiente ancho de banda: 15KB/s bajada y 10KB/s
Memoria y velocidad procesamiento
Que no se encuentre “firewalled”
Tiempo conectado
Necesidad de más Ultrapeers en la red
Un Ultrapeer se realiza en el hanshake
Algunas cabeceras son:





X-Ultrapeer: True/False
X-Try: 24.37.144:6346
X-Try-Ultrapeers: 23.35.1.7:6346
X-Ultrapeer-Needed: False
X-Query-Routing: 0.1
27/05/2016
Sistemas Distribuidos
24
Transferencia de archivos



Recibido un Query Hit un servent puede comenzar la
descarga de un fichero
La descarga de ficheros se realiza fuera de la red Gnutella
El protocolo de descarga recomendado es HTTP. Ejemplo:
CLIENTE
SERVIDOR
File Index: 2468
File Size: 4356789
File Name: Foobar.mp3
GET /get/2468/Foobar.mp3
HTTP/1.1 User-Agent: Gnutella
Host: 123.123.123.123:6346
Connection: Keep-Alive
Range: Bytes=0HTTP/1.1 200 OK
Server: Gnutella
Content-type:application/binary
Content-length:4356789
27/05/2016
Sistemas Distribuidos
25
Implementaciones

MLDonkey: Linux, Mac y Windows. Licencia GNU GPL

Limewire: Java. Licencia GNU GPL

Morpheus: Windows. Código cerrado

Shareaza: Wndows. Licencia GNU GPL

Apollon, BearShare, CocoGnut, GTK-gnutella,
Kiwi-Alpha, Fex, XNap…
27/05/2016
Sistemas Distribuidos
26
Bibliografía

Artículos en la wikipedia:




RFC


http://en.wikipedia.org/wiki/Gnutella
http://en.wikipedia.org/wiki/Gnutella_crawler
http://en.wikipedia.org/wiki/Ultrapeer
http://rfc-gnutella.sourceforge.net/
Varios:

GDF: http://groups.yahoo.com/group/the_gdf/
27/05/2016
Sistemas Distribuidos
27