Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

(1904) Redes de Comunicaciones

1 Introduccin a la prctica
El sistema nanoP2P est formado por un conjunto de pares (peers) y un servidor central (tracker),
como puede apreciarse en la Figura 1.

Figura 1. Arquitectura de nanoP2P.

El tracker dispone de una base de datos en la que guarda ciertos metadatos sobre los ficheros
compartidos por los pares actualmente conectados al servidor (como su nombre, tamao y hash), as
como la identidad de los pares que comparten dicho fichero. Cada par podr enviar al servidor su
lista de ficheros locales a compartir, as como obtener del servidor la lista de ficheros remotos
compartidos por todos los pares. Un par tambin podr consultar, para un cierto fichero compartido
por otros, cul es la lista de pares que poseen una copia completa del fichero; a estos pares se les
denomina semillas (seeds). A partir de dicha lista de semillas, un par podr descargar el fichero,
obteniendo de cada semilla uno o ms fragmentos en los que se divide el fichero. Una vez completa
la descarga, el par deber notificarlo al tracker para ser aadido a la lista de semillas que comparten
el fichero.
El ncleo central de esta prctica consistir en la implementacin de los peers de la arquitectura,
puesto que la implementacin del tracker se proporciona a los alumnos como material de partida.
Por tanto, debern programar toda la funcionalidad necesaria para comunicarse con un tracker a
travs de un protocolo ya definido y para intercambiar trozos de ficheros con otros peers mediante
un protocolo que cada grupo de prcticas ha definido como parte de la prctica de diseo.

2 Arquitectura de protocolos relacionados con la prctica

2.1. Especificacin del protocolo de comunicacin peer-peer
Esta sera la arquitectura de capas de inters para la comunicacin entre pares:
Nivel de Aplicacin

Protocolo peer-peer

Nivel de Transporte

TCP

1/8

(1904) Redes de Comunicaciones

Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

En el protocolo peer-peer, tanto el formato de sus mensajes como la secuencia de envo de los
mismos, ser el especificado por los alumnos en la anterior entrega.

2.2. Especificacin del protocolo de comunicacin peer-tracker

Esta sera la arquitectura de capas de inters para la comunicacin entre servidor y pares:
Nivel de Aplicacin

Protocolo peer-tracker

Nivel de Transporte

UDP

2.2.1. Formato de los mensajes

El protocolo de comunicacin entre peers y trackers ser el mismo para todos los grupos de
prcticas, puesto que es el que respeta la implementacin del tracker que se proporciona. En esta
seccin se proporcionan los detalles relativos a los distintos tipos de mensajes que pueden
intercambiarse ambas entidades. Los mensajes estarn codificados mediante un esquema
multiformato.
A continuacin se muestra un esquema de los tres formatos de paquetes intercambiados:

Tipo CONTROL
Tipo FILEINFO
Tipo SEEDINFO

FORMATO CONTROL
1b
+-------+
|opcode |
+-------+

El campo opcode, presente en todos los mensajes, especifica el tipo del mensaje en cuestin. Los
tipos de mensajes de los que consta el protocolo se enumeran a continuacin. Este formato ser
utilizado por los mensajes de confirmacin (acknowledgments) que el tracker enva como respuesta
al peer tras recibir mensajes de peticin de alta/baja de una lista de ficheros, as como para el
mensaje de consulta de la lista de todos los ficheros compartidos.
FORMATO FILEINFO
1b
2b
2b
20b
8b
4b
0 .. long.filename-1
+------------------------------------------------------------------------+
|opcode| port | #files | hash | filesize |filename.len| filename
|
+------+------+---------+-------+----------+------------+----------------+
<----------- file info -------------------------->

2/8

(1904) Redes de Comunicaciones

Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

El campo port indica el puerto TCP en el que el peer escucha conexiones para servir los ficheros
que comparte. El campo #files indica cuntas entradas file info contiene el mensaje. Cada
entrada file info contiene, a su vez, cuatro campos con los meta-datos de un fichero: hash
SHA-1 del contenido del fichero, su tamao (en bytes), la longitud del nombre y el propio nombre
del fichero. En algunas circunstancias, #files puede ser 0 indicando que la lista de informacin
sobre ficheros que sigue est vaca.
FORMATO SEEDINFO
1b
20b
2b
4b
2b
4b
2b
+------------------------------------------------------------------------+
|opcode|
hash
| #seeds | IP | Port | IP | Port | ...
|
+------+-----------+----------+------+------+------+------+--------------+
<--- seed 1---><---seed 2--->
<-------- seed list ----------------------->

En todo caso, el campo hash identifica el fichero sobre el que se realiza la consulta. El campo
#seeds indica el nmero de semillas que contiene el mensaje, y es posible que tome el valor 0
(lista de seeds vaca) en el caso de que no exista ninguna semilla para el fichero en cuestin en el
momento de la consulta (por ejemplo, porque todos los pares que lo compartan se han
desconectado). Cada seed viene identificado por una direccin de socket, formada por la
combinacin de direccin IP (IPv4) y nmero de puerto TCP en el que dicho seed escucha
peticiones de otros peers.
Los diferentes tipos de mensajes son los siguientes:

Tipo = 1 (ADD_SEED)
Formato del mensaje: FILEINFO
El par solicita al servidor ser aadido como semilla para una lista de ficheros.
Inicialmente, se tratar de la lista de ficheros a compartir que se encuentran en su
directorio local compartido. Posteriormente, este mensaje se utilizar para notificar al
servidor sobre un fichero recin descargado. El servidor actualizar su base de datos:
Para cada fichero de la lista, el servidor comprobar si su hash existe en la BD, en cuyo
caso aadir al par que se conecta a la lista de pares seed_list que comparten dicho
fichero. Si el hash no existe, insertar una nueva tupla <hash, filesize, filename,
seed_list> en la BD, estableciendo en seed_list que el fichero est compartido
nicamente por este par.
Tipo = 2 (ADD_SEED_ACK)
Formato del mensaje: CONTROL
El servidor responde a un mensaje ADD_SEED con el correspondiente ACK.
Tipo = 3 (QUERY_FILES)
Formato del mensaje: CONTROL
El par solicita al tracker la lista de todos los ficheros compartidos en el sistema.
El tracker responde con un mensaje FILE_LIST
Tipo = 4 (FILE_LIST)
Formato del mensaje: FILEINFO
3/8

(1904) Redes de Comunicaciones

Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

El tracker responde a una peticin QUERY_FILES de un par con una lista de todos los
ficheros compartidos actualmente en el sistema. El nmero de ficheros viene dado por
#files. Para cada fichero, el tracker informa de su hash, tamao y nombre mediante
los subcampos de file info.
Tipo = 5 (GET_SEEDS)
Formato del mensaje: SEEDINFO
El par consulta al servidor la lista de semillas para un fichero dado, identificado por su
hash. El campo #seeds se debe establecer a 0, indicando que el campo seed list
est vaco.
Tipo = 6 (SEED_LIST)
Formato del mensaje: SEEDINFO
El tracker responde a una peticin GET_SEEDS de un par con la lista de semillas para el
fichero consultado, identificado por su hash. El campo #seeds indica el nmero de
semillas que contiene el mensaje, y es posible que tome el valor 0 en el caso de que no
exista ninguna semilla para el fichero en cuestin en el momento de la consulta (por
ejemplo, porque todos los pares que lo compartan se han desconectado), en cuyo caso la
lista de semillas est vaca. En todo caso, el campo hash identifica el fichero sobre el
que se realiz la consulta. Cada seed contiene la direccin IPv4 de un par que posee el
fichero.
Tipo = 7 (REMOVE_SEED)
Formato del mensaje: FILEINFO
El par solicita al tracker dar de baja una lista de ficheros que ya no desea compartir en la
base de datos. El tracker actualizar su base de datos, eliminando a este peer de la lista
de semillas en todos los ficheros indicados.
Tipo = 8 (REMOVE_SEED_ACK)
Formato del mensaje: CONTROL
El servidor responde con el correspondiente ACK.

2.2.2. Autmatas del protocolo peer-tracker

La comunicacin entre peer (cliente) y tracker (servidor) viene dada por los autmatas de protocolo
que se muestran a continuacin. Puesto que el protocolo de nivel de transporte no ofrece
comunicacin confiable, ambos autmatas contemplan la prdida y retransmisin de los mensajes
intercambiados. As, en el caso del autmata del cliente, tras cada envo de un mensaje es necesario
pasar a un estado transitorio que considere el evento de prdida o corrupcin de dicha peticin (o su
respuesta), detectado mediante el timeout de un temporizador establecido en cada envo. De esta
forma, si un mensaje se pierde en su camino hacia o desde el tracker, siempre ser el cliente el
encargado de retransmitir. Por esta razn, el autmata del servidor no tiene los estados de timeout
correspondiente al envo de respuestas, sino que simplemente confa en la retransmisin de la
peticin por parte del cliente en caso de que la respuesta se pierda/corrompa.

4/8

(1904) Redes de Comunicaciones

Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

Autmata del cliente.

Como podemos ver, el cliente (peer) puede en cualquier momento realizar cualquiera de las
interacciones posibles con el tracker:
1. Publicar de la lista de ficheros compartidos, mediante el envo de un mensaje con la lista de
ficheros al tracker y la recepcin de su confirmacin.
2. Consultar los ficheros compartidos por todos los pares, mediante el envo de un mensaje de
consulta al tracker y la recepcin de la lista de ficheros disponibles.
3. Descargar ficheros desde otros pares, siguiendo la siguiente secuencia:
a) Obtener de la lista de semillas que comparten dicho fichero.
b) Una vez finalizada la descarga, publicar el fichero descargado como compartido por el
par que realiz la descarga.
4. Comunicar al tracker la baja (eliminacin) de una lista de ficheros locales que ya no son
compartidos (por ejemplo, ante la desconexin del peer) y la recepcin del ack asociado.
El autmata del servidor muestra que se trata de un protocolo sin estado, en el que el servidor se
limita a realizar la operacin solicitada en cada momento sin imponer ningn orden concreto entre
las distintas operaciones.

Autmata del servidor.

5/8

(1904) Redes de Comunicaciones

Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

3 Lgica de los programas

3.1. Lgica del programa tracker
El programa Tracker no interacta con el usuario, simplemente queda a la espera, una vez lanzado,
de los mensajes que va recibiendo y va listando la lista de ficheros compartidos, suministrando
informacin de comparticin sobre cada fichero solicitado y actualizando la base de datos de
ficheros compartidos por los peers apropiadamente tras cada descarga completada, conexin y
desconexin de un par. Este programa se proporciona al alumnado por parte de los profesores de la
asignatura, por lo que no es necesario desarrollarlo. El tracker utilizar el puerto 4450/udp para
atender peticiones de los peers.
Con la finalidad de que los alumnos puedan depurar el correcto funcionamiento de sus peers, el
tracker imprime por consola un breve resumen de los mensajes recibidos y enviados por parte de los
peers.

3.2. Lgica del programa peer

El programa Peer s interactuar con el usuario mediante una lnea de comandos. Al ejecutarlo se le
deben suministrar dos argumentos, en el orden indicado:
1. La direccin IP en la que se encuentra el tracker con el que se desea conectar.
2. Una ruta a un directorio local cuyo contenido ser compartido en el sistema de intercambio
de ficheros, y dentro del cual tambin se depositarn los ficheros descargados.
Una vez en ejecucin, el programa cliente aceptar, al menos, las siguientes tres rdenes:

query
download <hash>
quit

(consulta al tracker la lista de ficheros compartidos disponibles)

(descarga el fichero de otros peers)
(cierra la conexin con el tracker y termina el programa)

El programa se conectar al tracker utilizando cualquier puerto UDP disponible en la mquina local.
Tras el establecimiento de la conexin, el programa deber escanear el directorio local de
comparticin suministrado como argumento por la lnea de comandos, y enviar la lista de ficheros
compartidos al tracker. A partir de ese momento, el programa quedar a la espera de que el usuario
introduzca un comando.
La respuesta del tracker ante la orden query consistir en todos los ficheros compartidos por todos
los peers conectados en ese instante, incluidos los del peer que realiza la consulta. Ser
responsabilidad de cada peer filtrar dicha lista para evitar mostrar los ficheros que ya posee. La lista
de ficheros obtenida del tracker incluir el nombre de cada fichero, su tamao y hash, que lo
identificar de manera unvoca independientemente de su nombre.
Para descargar un fichero se utilizar el comando download, indicando como argumento el hash del
archivo a descargar, o una parte del mismo, siempre que subcadena del hash identifique de forma no
ambigua el archivo a descargar. El proceso de descarga consta de tres fases:
6/8

(1904) Redes de Comunicaciones

Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

1. Obtener del tracker la lista de pares que tienen el fichero (semillas).

2. Descargar el fichero de dichas semillas.
3. Notificar al tracker de que ya se dispone el fichero, una vez descargado, para ser aadido a
la lista de semillas.
Para aquellos ficheros compartidos por varios peers, se considerar suficiente que el downloader
obtenga los trozos del fichero de al menos dos semillas, aunque sera deseable la descarga desde un
nmero mayor de peers. Los trozos en los que se divide un fichero, que denominaremos chunks,
podrn ser de tamao fijo o variable, a decisin de los alumnos. Ser suficiente con permitir una
nica descarga en cada instante, de modo que la interfaz del programa cliente se bloquee hasta que
se complete cada descarga. A modo de mejora, se proponer permitir varias descargas simultneas en
un mismo peer. En todo caso, se deber mostrar el progreso de las descargas: bytes descargados
frente al tamao total del fichero. El programa tambin deber mostrar un breve resumen al
finalizar la descarga, con el nmero de trozos que se ha descargado de cada semilla.
El programa peer debe tener funcionando en todo momento, en segundo plano, un proceso
dispuesto a servir los trozos de los ficheros que otros peers puedan solicitarle. Dicho proceso
finalizar cuando se teclee el comando quit. El nmero de puerto TCP utilizado por cada peer para
escuchar peticiones de otros peers podr ser diferente, y deber ser en todo caso comunicado al
tracker junto con la lista de ficheros compartidos por el peer.

4 Detalles de la entrega
El trabajo que los alumnos debern desarrollar es el siguiente:
Programa del peer de nanoP2P.
Documentacin de la prctica.
Instrucciones detalladas:
Las prcticas deben ser realizadas obligatoriamente por grupos de dos personas.
Los grupos debern subir al Aula Virtual, a la tarea denominada Prctica de
implementacin de protocolos P2P un archivo comprimido que contenga un documento
PDF con los siguientes apartados:
Introduccin.
Diseo del protocolo P2P implementado
Detalles sobre los principales aspectos de implementacin (ver Rbrica)
Manual de uso de la aplicacin peer nanoP2P.
Ejemplos de ejecuciones donde se obtengan ficheros de varios peers, incluyendo la
informacin mostrada en la consola de los peers y del tracker en dichos casos.
Conclusiones.
Dicho archivo comprimido incluir el proyecto con la implementacin de todo el cdigo.
Debe ser un proyecto Eclipse listo para ser importado y ejecutado.
Tambin se incluirn dos archivos .jar que permitan ejecutar tanto el programa del tracker
como el programa del peer.
El da tope de entrega coincidir con el del examen de teora de junio, es decir, el da 27 de
Mayo a las 9.00 horas.
7/8

(1904) Redes de Comunicaciones

Prctica de Redes de Comunicaciones

(Implementacin de protocolos P2P 2015/16)

Rbrica de la prctica de implementacin

Una rbrica est formada habitualmente por ms de un criterio, y cada criterio dispone de un peso
dentro de la calificacin de la tarea. En el caso concreto de la prctica de implementacin que se
enuncia en este documento, la rbrica que tiene asociada se puede ver en la siguiente tabla:
Criterio

Peso

Sobresaliente (2)

Alcanzado (1)

Insuficiente (0)

Funcionamiento

40% El programa se ejecuta

correctamente y es capaz de
obtener al menos 2 ficheros
distintos de un nmero
ilimitado de peers antes de salir
de l, incluso en el caso de que
haya errores en el canal de
comunicacin con el tracker.

El programa se ejecuta
correctamente y es capaz
de obtener al menos 2
ficheros distintos a partir
de dos peers antes de salir
de l, incluso en el caso
de que haya errores en el
canal de comunicacin
con el tracker.

El programa no
cumple con la
funcionalidad
indicada para el
nivel
Alcanzado.

Implementacin

20% La estructura del cdigo es

clara, se divide correctamente
en paquetes, se controlan los
aspectos derivados de la
concurrencia de procesos y
respeta claramente los niveles
de abstraccin.

Algunas de las
caractersticas en el
apartado de sobresaliente
no se implementan
correctamente.

Muchas de las
caractersticas en
el apartado de
sobresaliente no
se implementan
correctamente.

Formato

15% El formato de los mensajes

P2P es correcto, ptimo y
contiene todos los campos
necesarios.

El formato de los
El formato de los
mensajes P2P es correcto, mensajes no se
pero no ptimo.
adapta bien al
protocolo.

Salida por consola

15% La informacin mostrada por

consola permite conocer el
progreso de las descargas as
como de qu peers se ha
obtenido cada fichero y en qu
proporcin.

La informacin mostrada
por consola se genera
correctamente, pero falta
parte de la informacin
solicitada.

La informacin
mostrada por
consola es
claramente
insuficiente.

Correccin de la
documentacin
presentada

10% El documento contiene una

portada, ndice de contenidos,
nmero de pginas, respeta la
estructura indicada, es claro y
carece de faltas ortogrficas y
gramaticales.

El documento est
estructurado aunque
carece de ciertos aspectos
formales. La estructura es
la correcta y carece de
faltas ortogrficas y
gramaticales.

El documento
carece de
estructura y no
est redactado
correctamente.

IMPORTANTE: Durante la entrevista los dos alumnos deben responder con soltura a las preguntas
formuladas, que pueden incluir cambios en el cdigo y establecen claramente la divisin del trabajo.

8/8