diseño e implementación de un protocolo de redes peer-to-peer

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
PROYECTO FIN DE CARRERA
DISEÑO E IMPLEMENTACIÓN DE UN
PROTOCOLO DE REDES
PEER-TO-PEER
LUIS MARÍA GARCÍA SANJUÁN
MADRID, JUNIO DE 2009
Autorizada la entrega del proyecto del alumno:
Luis María García Sanjuán
EL DIRECTOR DEL PROYECTO
José Manuel Muñoz Berengena
Fdo:
Fecha:
Vo Bo del Coordinador de Proyectos
David Contreras Bárcena
Fdo:
Fecha:
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
PROYECTO FIN DE CARRERA
DISEÑO E IMPLEMENTACIÓN DE UN
PROTOCOLO DE REDES
PEER-TO-PEER
AUTOR: LUIS MARÍA GARCÍA SANJUÁN
DIRECTOR: JOSÉ MANUEL MUÑOZ BERENGENA
MADRID, JUNIO DE 2009
A mi madre y a mi hermana.
Dicen que “quien convive con lo que admira termina imitándolo”, y la dedicación y
entrega que mostráis cada día en vuestro trabajo ha sido para mí todo un ejemplo a
seguir, guiándome hacia el ocaso de esta etapa.
I
AGRADECIMIENTOS
Mi más sincero agradecimiento a José Manuel Muñoz Berengena, mi director de
proyecto. Una vez terminado el trabajo, sólo me queda decir gracias y perdón. Gracias
por todo el tiempo que me has dedicado, por tu ayuda e inagotable paciencia. Perdón
por los momentos en los que el peso del proyecto me ha superado, y has tenido que
transmitirme tu sosiego y tranquilidad.
Deseo expresar mi agradecimiento a David Contreras Bárcena, mi coordinador de
proyecto, y a todos los profesores de la Escuela Técnica Superior De Ingeniería de la
Universidad Pontificia Comillas de Madrid por su trabajo realizado durante estos años
de carrera.
A Pilar Balda, Marta Galán y Marta Lozoya por ese día en el que os sentasteis a
mi lado, regalándome así la oportunidad de conoceros. Gracias por todo vuestro cariño
y por los momentos que habéis compartido conmigo.
Por último, no quisiera olvidarme de mis amigos Beatriz, Juan y Julio. Aunque ya
sabéis lo mucho que os quiero, no está de más agradeceros el cómo sois y el estar, a
pesar de la distancia, tan cerca de mí.
II
RESUMEN
Actualmente existe una gran variedad de clientes de redes peer-to-peer con
diferentes finalidades, telefonía por Internet, sistemas de ficheros distribuidos, cálculo
científico y demás. Probablemente, la finalidad con más uso sea la de búsqueda y
transferencia de archivos.
Haciendo uso de determinadas aplicaciones que cubren esta finalidad, se puede
comprobar que la búsqueda e intercambio de archivos de las actuales aplicaciones de
redes peer-to-peer están muy condicionadas al servidor al que el cliente se encuentre
conectado, ya que diferentes conexiones entre distintos servidores producen
diferentes resultados. Por lo tanto, se puede concluir que existe un desequilibrio entre
lo que ofrecen este tipo de aplicaciones y lo que demandan los usuarios. Por este
motivo, el objetivo de este proyecto es el diseño e implementación de un protocolo
peer-to-peer, que mejore el proceso de búsqueda de los archivos entre los usuarios
que se encuentren conectados a la red. Se entiende por mejora la eliminación de la
dependencia del proceso de búsqueda al servidor al que el usuario se encuentre
conectado.
Para poder desarrollar el proyecto, es necesario que los servidores compartan la
misma información acerca de los archivos y de los clientes que se encuentran
conectados a la red peer-to-peer. Dado el gran número de clientes de este tipo de
redes, es inviable que un servidor albergue toda ésta información, ya que manejaría
una gran volumen de datos que además estaría duplicado en el resto de servidores.
Por este motivo, la arquitectura propuesta se basa en la conexión de todos los
servidores a una red IP multicast, para así poder distribuir la información por medio de
mensajes, sin la necesidad de almacenarla en la base de datos de cada uno de ellos.
Cuando un cliente de la red peer-to-peer desea realizar una búsqueda de un
determinado archivo, envía una solicitud de búsqueda al servidor al que se encuentra
conectado. El servidor procesa la solicitud, realizando una consulta en su base de
datos, en la que están registrados todos los archivos de los clientes con los que
mantiene una conexión. Al finalizar la consulta, transmite la solicitud de búsqueda del
III
cliente a la red IP multicast para que todos los servidores, que se encuentran
conectados a esta red, reciban dicha solicitud y consulten en sus bases de datos, al
igual que hizo el primer servidor, para obtener los resultados que satisfacen la
petición. Una vez consultada la base de datos, se envían los resultados al servidor que
los solicitó para añadir esos resultados a los que ya tenía. Una vez terminado este
proceso, todos los resultados se envían al cliente que inició el proceso de búsqueda.
Dado que el proyecto realizado tiene características de un sistema distribuido, el
protocolo se ha implementado bajo el lenguaje de programación Java, para asegurar la
portabilidad en entornos heterogéneos, con hardware y sistemas operativos diversos.
El protocolo implementado aporta una serie de mejoras tanto en los servidores
como en los clientes. El número de archivos encontrados en el proceso de búsqueda, el
número de comentarios de los usuarios que califican los archivos y el número de
fuentes encontradas que tienen disponible el archivo para compartir son mayores, ya
que se elimina la dependencia de la conexión con el servidor. Dado que el número de
fuentes encontradas es mayor, se reduce considerablemente el tiempo de
transferencia del archivo, ya que la posibilidad de conexión a un mayor número de
pares se incrementa.
Al no existir una dependencia con el servidor, en los clientes no se requiere un
mantenimiento de una lista de servidores en la que elegir sus favoritos y su prioridad
en el proceso de conexión, por lo que se le libera de una tarea innecesaria. Al eliminar
una preferencia de conexión entre un servidor u otro, las conexiones de los clientes
entre los distintos servidores de la red están más equilibradas y por lo tanto el reparto
de carga de trabajo entre estos y las solicitudes de búsqueda de un archivo entre los
usuarios de la red estarán más equilibradas.
En el presente proyecto, se ha realizado un exhaustivo análisis sobre los sistemas
actuales peer-to-peer de transferencia de archivos, detallando sus características,
funcionamiento y mejoras con respecto a otros sistemas y, conjuntamente, se ha
introducido el problema de las búsquedas de archivos en este tipo de redes. Sobre esa
IV
base, se ha realizado el diseño e implementación de un protocolo independiente del
servidor al que el usuario se encuentre conectado.
El sistema desarrollado se podría enmarcar dentro de los sistemas peer-to-peer
estructurados, ya que se conoce la localización exacta de los recursos, pero sin la
necesidad de que los clientes tengan que mantener una tabla hash para calcular el
lugar en el que está cada recurso como sucede en el caso de las redes Pastry, CAN o
Chord, proporcionando un mecanismo de búsqueda determinista, de tal forma que se
asegura la localización de un recurso siempre y cuando se encuentre en la red,
encaminando los mensajes de forma eficiente.
Con la realización de este proyecto, se suplen algunas carencias de las actuales
aplicaciones de búsqueda y transferencia de archivos en redes peer-to-peer, como es el
caso de la búsqueda de fuentes o de comentarios de un determinado archivo. Además,
otras características y funcionalidades de estas aplicaciones se optimizan, como por
ejemplo la previsualización de los archivos en estado de descarga y la gestión del
espacio de los archivos temporales.
V
ABSTRACT
Currently there is a wide variety of clients on peer-to-peer networks, with
different determinations, such as telephony through internet, distributed file systems,
scientific calculation and so on. Most likely, the determinations most widely used are
search and file transfers.
Using specific applications that cover this determination, it is clear that the
search and exchange of files using the current applications of the peer-to-peer
networks are highly conditioned by the server being used by the client, as different
connections between different servers produce different results. Therefore, one
comes to the conclusion that there is an imbalance between what this type of
applications offers and what the users need. For this reason, the objective of this
project is to design and install a peer-to-peer protocol to improve the search process
of files between the users that are connected to the network. Improvement is
understood to be the elimination of the dependence of the search process to the
server that the user is connected to.
To develop the project, the servers must share the same information on the files,
as well as on the clients that are connected to the peer-to-peer network. Given the
large number of clients on these networks, it is unviable that one server would store all
of this information, as it would handle a large volume of data that would be duplicated
in the rest of the servers. For this reason, the architecture proposed is based on the
connection of all the servers to an IP multicast network, to be able to distribute the
information through messages without the necessity of storing it in the database of
each one.
When a client on the peer-to-peer network wants to initiate a search for a
certain file, he sends a search request to the server he is connected to. The server
processes the request, consulting its database, in which all of the files of the clients
that maintain a connection are registered. When the consulting process is finished, the
search request is transmitted from the client to the IP multicast network so that all of
the servers that are connected to this network receive the request and consult their
VI
database, just like the first server did, to obtain the results that satisfy the request.
Once the database has been consulted, the results are sent to the server that
requested them, to add them to already existing information. Once concluded this
process, all of the results are sent to the client that initiated the search process.
Given that the project carried out has the characteristics of a distributed system,
the protocol has been set up under Java language programming, to assure the
portability in heterogeneous settings, with hardware and several operative systems.
The protocol installed provides a series of improvements in both the servers and
the clients. Since the dependence of the connection with the server is eliminated, the
number of files found in the search process, the number of comments of the users that
describe the files y and the number of sources found that have the file available to
share are greater. Considering that the number of sources found is greater, the time to
transfer the file is reduced, as the possibility of connecting to a larger number of peers
is increased.
Eliminating the dependence with the server, the clients are not required to
maintain a list of servers to choose their favourites and their priority in the connecting
process, saving them from an unnecessary task. Eliminating a connection preference
between one server or another, the connections of the clients between the different
servers of the network are more balanced and, as a result, the distribution of work
load among them, as well as the file search requests among the users of the network,
are more balanced.
In this project, an exhaustive analysis on the current peer-to-peer systems of file
transfers has been carried out, detailing its characteristics, its performance and
improvements over other systems, together with the introduction of the problem of
file searches in this type of network. Using this as a base, the design and installation of
an independent protocol of the server to which the user is connected to have been
carried out.
VII
The system developed could be kept within the structured peer-to-peer systems,
since the exact location of the resources is known, but without the necessity of the
clients maintaining a hash table to calculate where each resource is located, as in the
networks Pastry, CAN o Chord, providing a deterministic search mechanism that
always lets you know where the resource is and when it is on the network, efficiently
channelling the messages.
This project has supplemented some of the deficiencies of the current search
applications and file transfers in peer-to-peer networks, such as the search of sources
or comments of a determined file. Furthermore, other characteristics and functions of
these applications are optimized, such as the previsualization of files in an unloading
state and the procedure of space for temporary files.
VIII
ÍNDICE
1. INTRODUCCIÓN .................................................................................................. 13
1.1. INTRODUCCIÓN A LAS REDES PEER-TO-PEER.................................................................... 2
1.1.1. REDES PEER-TO-PEER ................................................................................................ 2
1.1.2. ELEMENTOS DE UNA RED PEER-TO-PEER ................................................................. 4
1.1.3. ARQUITECTURA DE LAS REDES PEER-TO-PEER ......................................................... 5
1.1.4. CLASIFICACIÓN DE LAS REDES PEER-TO-PEER........................................................... 7
1.1.5. APLICACIONES DE REDES PEER-TO-PEER .................................................................. 9
1.1.6. PROBLEMAS DE LAS REDES PEER-TO-PEER ............................................................. 10
1.2. TECNOLOGÍAS ................................................................................................................. 11
1.2.1. JAVA ........................................................................................................................ 11
1.2.2. MYSQL ..................................................................................................................... 12
2. ESTADO DEL ARTE DE LAS APLICACIONES PEER-TO-PEER ..................................... 15
2.1. ESTADO DEL ARTE ........................................................................................................... 16
2.2. CONCEPTOS Y TECNOLOGÍAS ACTUALES ........................................................................ 33
2.2.1. P2P ANÓNIMO ........................................................................................................ 33
2.2.2. REDES FRIEND-TO-FRIEND ...................................................................................... 34
2.2.3. PEER-TO-MAIL ......................................................................................................... 34
2.2.4. WEBCACHÉ .............................................................................................................. 35
2.2.5. PROACTIVE NETWORK PROVIDER PARTICIPATION FOR P2P .................................. 35
3. MOTIVACIÓN Y OBJETIVOS DEL PROYECTO ......................................................... 36
4. ANÁLISIS DEL SISTEMA........................................................................................ 41
4.1. IDENTIFICACIÓN DE NECESIDADES ................................................................................. 42
4.1.1. ALCANCE DEL SISTEMA ........................................................................................... 42
4.1.2. TOPOLOGÍA DE USUARIOS FINALES ........................................................................ 43
4.1.3. RESTRICCIONES ....................................................................................................... 44
4.2. ANÁLISIS DE REQUISITOS ................................................................................................ 44
4.2.1. CONTEXTO GENERAL DEL SISTEMA ........................................................................ 44
4.2.2. ÁMBITO DEL SISTEMA ............................................................................................. 46
4.2.3. ÁMBITO DEL CLIENTE .............................................................................................. 46
4.2.4. ÁMBITO DEL SERVIDOR........................................................................................... 48
4.2.5. DECISIONES DE DISEÑO .......................................................................................... 49
4.3. METODOLOGÍA ............................................................................................................... 52
4.3.1. DIAGRAMA DE DOMINIO ........................................................................................ 52
4.3.2. DIAGRAMA DE CASOS DE USO ................................................................................ 54
4.3.3. DIAGRAMA DE PAQUETES....................................................................................... 56
4.3.4. DIAGRAMA DE CLASES ............................................................................................ 58
4.3.5. DISEÑO DE LA BASE DE DATOS ............................................................................... 65
5. PROTOCOLO DEL SISTEMA .................................................................................. 68
5.1. PROTOCOLO ENTRE CLIENTE Y SERVIDOR ...................................................................... 69
5.1.1. SOLICITUD DE CONEXIÓN A LA RED PEER-TO-PEER ................................................ 69
5.1.2. SOLICITUD DE BÚSQUEDA DE ARCHIVOS................................................................ 69
5.1.3. SOLICITUD DE BÚSQUEDA DE COMENTARIOS ........................................................ 70
5.1.4. SOLICITUD DE BÚSQUEDA DE CLIENTES ................................................................. 70
5.1.5. SOLICITUD DE SINCRONIZACIÓN............................................................................. 71
IX
5.1.6. SOLICITUD DE DESCONEXIÓN DE LA RED PEER-TO-PEER ....................................... 72
5.2. PROTOCOLO ENTRE SERVIDORES ................................................................................... 72
5.2.1. SOLICITUD DE CONEXIÓN A LA RED MULTICAST .................................................... 72
5.2.2. SOLICITUD DE BÚSQUEDA DE ARCHIVOS................................................................ 73
5.2.3. SOLICITUD DE BÚSQUEDA DE COMENTARIOS ........................................................ 73
5.2.4. SOLICITUD DE BÚSQUEDA DE CLIENTES ................................................................. 74
5.3. PROTOCOLO ENTRE CLIENTES......................................................................................... 75
6. PROGRAMACIÓN Y PRUEBAS DEL SISTEMA ......................................................... 77
6.1. PROGRAMACIÓN............................................................................................................. 78
6.1.1. INTRODUCCIÓN....................................................................................................... 78
6.1.2. LENGUAJES DE PROGRAMACIÓN ............................................................................ 78
6.1.3. MANUAL DE USUARIO ............................................................................................ 78
6.2. PRUEBAS DEL SISTEMA ................................................................................................... 79
6.2.1. PRUEBAS DE ENCADENAMIENTO ........................................................................... 80
6.2.2. PRUEBAS DE INTEGRACIÓN .................................................................................... 80
6.2.3. PRUEBAS DE EXPLOTACIÓN DEL SISTEMA .............................................................. 80
6.2.4. PRUEBAS DE SOBRECARGA ..................................................................................... 80
6.2.5. PRUEBAS DE RECUPERACIÓN.................................................................................. 80
6.2.6. PRUEBAS DE SEGURIDAD ........................................................................................ 81
6.2.7. PRUEBAS DE USABILIDAD ....................................................................................... 81
6.2.8. PRUEBAS DE ACEPTACIÓN DEL USUARIO ............................................................... 81
7. PLANIFICACIÓN DEL PROYECTO........................................................................... 82
8. VALORACIÓN ECONÓMICA DEL PROYECTO ......................................................... 85
8.1. COSTES DE TECNOLOGÍA ................................................................................................. 86
8.1.1. COSTES DE HARDWARE........................................................................................... 86
8.1.2. COSTES DE SOFTWARE ............................................................................................ 86
8.2. COSTES DE IMPLANTACIÓN ............................................................................................ 87
8.3. VALORACIÓN FINAL......................................................................................................... 89
9. CONCLUSIONES Y FUTURAS LÍNEAS DE DESARROLLO........................................... 90
BIBLIOGRAFÍA Y REFERENCIAS ................................................................................ 94
ANEXO I. MANUAL DE USUARIO DE LA APLICACIÓN CLIENTE................................... 98
ANEXO II. MANUAL DE USUARIO DE LA APLICACIÓN SERVIDOR ............................ 115
X
TABLA DE FIGURAS
IDENTIFICADOR
DESCRIPCIÓN
PÁGINA
Figura 1
Figura 2
Figura 3
Figura 4
Figura 5
Figura 6
Figura 7
Figura 8
Figura 9
Figura 10
Figura 11
Figura 12
Figura 13
Figura 14
Figura 15
Figura 16
Figura 17
Figura 18
Figura 19
Figura 20
Figura 21
Figura 22
Figura 23
Figura 24
Figura 25
Figura 26
Figura 27
Figura 28
Figura 29
Figura 30
Figura 31
Figura 32
Figura 33
Figura 34
Figura 35
Figura 36
Figura 37
Figura 38
Figura 39
Figura 40
Arquitectura P2P
Arquitectura cliente-servidor
Modelo centralizado
Modelo totalmente descentralizado
Modelo semicentralizado
Arquitectura de Hotline Connect
Arquitectura de Napster
Arquitectura de eDonkey
Clientes de eDonkey
Cantidad de contenido compartido de BitTorrent
Enjambre de BitTorrent
Clientes BitTorrent
Resultados en la conexión con el servidor 212.63.206.35
Resultados en la conexión con el servidor 195.22.108.26
Arquitectura propuesta
Red IP multicast
Contexto general del sistema
Conexiones entre clientes de la red
Capas de la aplicación cliente
Capas de la aplicación servidor
Diagrama de dominio del sistema
Diagrama de casos de uso del usuario de la aplicación cliente
Diagrama de paquetes
Clases del paquete gui
Clases del paquete client
Clases del paquete constants
Clases del paquete util
Clases del paquete packets
Clases del paquete data
Clases del paquete server
Clases del paquete dao
Solicitud de conexión a la red P2P
Solicitud de búsqueda de archivos
Solicitud de búsqueda de comentarios
Solicitud de búsqueda de comentarios
Solicitud de sincronización de archivos
Solicitud de desconexión a la red P2P
Solicitud de conexión a la red IP multicast
Solicitud de búsqueda de archivos a la red IP multicast
Solicitud de búsqueda de comentarios a la red IP multicast
2
3
6
6
7
17
18
20
21
27
28
31
37
37
40
42
44
45
48
49
53
54
56
58
59
60
61
62
63
64
65
69
69
70
71
71
72
72
73
74
XI
IDENTIFICADOR
DESCRIPCIÓN
PÁGINA
Figura 41
Figura 42
Figura 43
Figura 44
Figura 45
Figura 46
Figura 47
Figura 48
Figura 49
Figura 50
Figura 51
Solicitud de búsqueda de direcciones IP a la red IP multicast
Solicitud de transferencia de un parte del archivo
Sincronización de transferencia de un parte del archivo
Costes de hardware
Costes de software
Costes de tecnología
Estimación del esfuerzo de los integrantes del proyecto
Costes de implantación
Costes de desarrollo del proyecto
Planificación del proyecto
Planificación de la etapa de desarrollo e implementación
74
75
76
83
83
84
85
86
86
88
89
XII
Capítulo 1
Introducción
Diseño e implementación de un protocolo peer-to-peer
1.1 INTRODUCCIÓN A LAS REDES PEER-TO-PEER
1.1.1 REDES PEER-TO-PEER
Debido a un notable crecimiento en el número de equipos conectados a Internet,
una mayor capacidad de almacenamiento de éstos y un rápido incremento del ancho
de banda disponible, ha surgido una enorme difusión de recursos de todo tipo en
Internet. Esta circunstancia ha hecho que sea necesario el desarrollo de una nueva
arquitectura de red para poder compartir y acceder a los recursos disponibles en
Internet. Esta arquitectura de red se conoce con el nombre de arquitectura peer-topeer, red peer-to-peer o más comúnmente P2P.
Una red peer-to-peer, en adelante P2P, es un conjunto de equipos conectados
por medio de un método de transporte de datos en el que se comparten recursos y en
el que no están definidos ni clientes ni servidores fijos. Se puede decir que los equipos
conectados a la red se comportan, simultáneamente como clientes y como servidores
con respecto al resto y todos tienen capacidades y responsabilidades equivalentes
[AFAN06].
Figura 1. Arquitectura P2P
Frente a este tipo de redes, se encuentran las que se basan en una arquitectura
cliente-servidor, en la que los clientes solicitan recursos a uno o más servidores. En
este tipo de arquitectura, según se añaden más usuarios a la red, la tasa de
2
Diseño e implementación de un protocolo peer-to-peer
transferencia1 disminuye ya que los recursos de los que dispone el servidor se
consumen debido al intenso tráfico. En las redes P2P, cada nodo provee al resto de los
recursos que dispone, obteniendo de esta forma un mayor rendimiento en las
conexiones y en las transferencias.
Figura 2. Arquitectura cliente-servidor
Los aspectos fundamentales que caracterizan una red P2P son los que se
muestran a continuación.
Escalabilidad. El alcance de las redes P2P es mundial, con un gran número de
usuarios potenciales. A diferencia de las redes basadas en una arquitectura
cliente-servidor, cuantos más usuarios estén conectados a la red, mayor
rendimiento se obtiene.
Descentralización. Por definición, estas redes son descentralizadas y los
usuarios se comportan, simultáneamente como clientes y servidores, lo que
hace que ningún nodo sea imprescindible.
Robustez. La naturaleza distribuida y descentralizada de las redes P2P
incrementan la robustez, ya que en el caso de fallo de un nodo, este no es
imprescindible.
Seguridad. Es la característica menos implementada, aunque existen
mecanismos de cifrado de clave, comunicaciones seguras, gestión de
derechos de autor, firmas digitales y demás métodos de seguridad.
1
El término tasa de transferencia se refiere al número de bits que se transmiten durante un tiempo
determinado entre dos dispositivos digitales. Mide la velocidad de transferencia de datos.
3
Diseño e implementación de un protocolo peer-to-peer
Anonimato. Aunque es deseable que queden en anonimato el autor de un
contenido, el editor, el lector, el servidor que lo alberga y la petición para
encontrarlo, esta característica es incompatible con los derechos de autor, por
lo que se proponen mecanismos de limitación de derechos como DRM2
(Digital Rights Management).
1.1.2 ELEMENTOS DE UNA RED PEER-TO-PEER
El elemento fundamental de una red P2P es una unidad de procesamiento lógico,
capaz de llevar a cabo una tarea encomendada y comunicar los resultados de la
ejecución de dicha tarea a otra entidad de la red, ya sea directa o indirectamente. Esta
unidad de procesamiento se conoce con el nombre de par o igual.
Existen dos tipos de pares [SANT07], los pares simples y los superpares. Los
primeros sirven a un único usuario final, proporcionándole servicios y demandándolos
a otros pares de la red. Los segundos gestionan el tráfico recibiendo solicitudes de
búsqueda de otros pares e indicando el acceso a los mismos.
Estos dos tipos de pares pueden agruparse con otros de su misma especie,
formando lo que se conoce como grupo de pares. Un grupo de pares es un conjunto de
pares del mismo tipo, configurado para servir un interés común, señalado por el resto
de pares del grupo. Los grupos de pares proporcionan servicios a sus pares miembro
que no son accesibles por otros pares de la red P2P. Este concepto es necesario para
poder dividir el espacio de la red.
Los servicios que proporcionan los pares de una red, proveen una funcionalidad
útil que se consigue por medio de la comunicación de los mismos. Esta funcionalidad
cubre una larga lista de diferentes finalidades, entre las que se encuentran la búsqueda
y transferencia de archivos, la telefonía por internet y los cálculos de carácter
científico.
2
El término DRM (Digital Rights Management) se refiere al conjunto de tecnologías de control para la
limitación del uso de medios o dispositivos digitales. También se puede referir a las restricciones
asociadas a instancias específicas de obras digitales o dispositivos.
4
Diseño e implementación de un protocolo peer-to-peer
Los servicios pueden clasificarse en servicios de pares y servicios de grupos de
pares. Los primeros son funcionalidades que ofrece un par concreto a otros pares de la
red. Si el par se desconecta, el servicio deja de estar disponible. Los segundos son
funcionalidades que ofrece un grupo de pares, consiguiendo así un acceso concurrente
al servicio. Si un par del grupo se desconecta, el servicio sigue estando disponible, ya
que el resto de los pares que forman parte del grupo continúan conectados.
1.1.3 ARQUITECTURA DE LAS REDES PEER-TO-PEER
El modelo en el que se basa la arquitectura de una red P2P puede ser
centralizado, totalmente descentralizado, semicentralizado.
En modelo centralizado, las solicitudes de búsqueda y control se realizan a través
de un único servidor central, que sirve de punto de enlace entre los nodos de la red.
Este servidor mantiene una base de datos en la que almacena la información de los
archivos que tiene cada cliente, actualizándola cada vez que un cliente se conecta o
desconecta. Cada solicitud de búsqueda es comparada en servidor central con la
información de la base de datos, y contestada con las correspondencias encontradas.
Una vez que el cliente tiene las correspondencias, se conecta directamente con cada
par y accede al recurso solicitado.
Este modelo se caracteriza por poseer una administración dinámica, una
disposición más permanente de los recursos y un elevado rendimiento en la
localización de recursos, sin embargo, está muy limitado en lo referente a la
escalabilidad3 y a la robustez4, ya que únicamente tiene un punto de fallo. Algunos
ejemplos de redes que se basan en este modelo son Napster y Audiogalaxy.
3
El término escalabilidad se refiere a una propiedad deseable en un sistema, que indica su habilidad
para poder hacerse más grande sin perder calidad en sus servicios.
4
El término robustez se refiere a una propiedad deseable de un sistema, que indica su habilidad para
poder funcionar o continuar funcionando correctamente bajo situaciones inesperadas.
5
Diseño e implementación de un protocolo peer-to-peer
Figura 3. Modelo centralizado
El modelo totalmente descentralizado o puro se caracteriza porque no existe un
servidor central, cada nodo actúa como cliente y como servidor, tratando de mantener
un cierto número de conexiones con otros pares, mandando y recibiendo peticiones y
mensajes de control que facilitan el descubrimiento y encaminamiento de otros nodos.
Las redes que se ajustan a este modelo son las más versátiles y robustas al no
depender de un servidor central, no obstante, el elevado tiempo y la sobrecarga de
ancho de banda que suponen las búsquedas de información son las principales
desventajas de esta arquitectura. Algunos ejemplos de redes que se basan en este
modelo son Kademlia, Gnutella y Freenet.
Figura 4. Modelo totalmente descentralizado
6
Diseño e implementación de un protocolo peer-to-peer
El modelo semicentralizado o mixto es el más extendido entre las arquitecturas
de redes P2P. En este modelo, se seleccionan ciertos nodos para que cumplan la
función de superpares y así ayudar a encaminar el tráfico hacia otros pares. Los
superpares cambian dinámicamente a medida que otros clientes se conectan a la red.
Cada par mantiene un número limitado de conexiones abiertas a un superpar y cada
superpar está conectado con el resto de superpares de la red.
Este modelo se caracteriza por presentar un alto grado de escalabilidad, al
reducir el número de nodos implicados en el proceso de encaminamiento, y disminuir
el volumen de tráfico entre estos. Algunos ejemplos de redes que se basan en este
modelo son eDonkey y BitTorrent.
Figura 5. Modelo semicentralizado
1.1.4 CLASIFICACIÓN DE LAS REDES PEER-TO-PEER
La clasificación más utiliza para identificar las redes P2P es de acuerdo al tipo de
estructura que presente, así se pueden presentar redes estructuradas o no
estructuradas [RODE05].
Las redes P2P estructuradas son aquellas en la que los recursos están situados en
pares precisos. Cada nodo de la red cuenta con su propia tabla hash5, el lugar en el que
5
El término tabla hash se refiere a una estructura de datos que asocia claves con valores, cuya operación
fundamental es la búsqueda, permitiendo el acceso a los valores almacenados a partir de una clave
generada.
7
Diseño e implementación de un protocolo peer-to-peer
está cada recurso es calculado mediante una función hash6 aplicada sobre la tabla, la
cual indica que par de la red conoce la localización del recurso. Algunos ejemplos de
este tipo de redes son Pastry, CAN y Chord.
Este tipo de redes proporcionan un mecanismo de búsqueda determinista, de tal
forma que asegura la localización de un recurso siempre y cuando se encuentre en la
red. Además los mensajes de búsqueda son encaminados de forma eficiente, de tal
forma que el recurso es encontrado en saltos, donde es el tamaño de la
red. Sin embargo, estas redes son ineficientes para realizar búsquedas por palabras
clave, ya que el usuario debe conocer el nombre exacto del recurso para poder aplicar
la función hash y así poder enrutar la búsqueda de forma eficaz. Además en este tipo
de redes, los usuarios deben organizar sus tablas hash cada vez que otro usuario se
conecta o desconecta, lo que provoca un proceso bastante complejo y un gran número
de mensajes de sincronización, lo que puede dar lugar a un colapso de la red.
En las redes P2P no estructuradas, la localización de los recursos no está
determinada en pares concretos, sino que a cada nodo se le asignan enlaces
arbitrariamente. No existe garantía alguna de encontrar el recurso, aunque éste esté
en la red, ya que la búsqueda no es determinista. Un ejemplo de este tipo de redes es
Gnutella.
Existen distintos mecanismos de búsqueda dentro de las redes no estructuradas,
pero los más utilizados son el de inundación y el de paseos aleatorios. En el primero,
cuando un nodo recibe un mensaje de solicitud de búsqueda de un recurso, si no
conoce el recurso buscado, reenvía el mensaje a todos los pares con los que tiene una
conexión. El inconveniente de este método de búsqueda es que introduce mucho
tráfico en la red. En el segundo mecanismo, los mensajes no se envían a todos los
pares con los que se tiene conexión, sino que sólo es enviado a uno ellos elegido
aleatoriamente. El alcance del mensaje está limitado por medio de la utilización de un
6
El término función hash se refiere a un algoritmo para la generación de claves que representen de
forma unívoca un determinado valor.
8
Diseño e implementación de un protocolo peer-to-peer
mecanismo basado en TTL7 (Time To Live). Este método introduce mucho menos
tráfico en la red que el primero, sin embargo, reduce la probabilidad de encontrar el
recurso debido a la limitación de la distribución del mensaje de búsqueda.
Aunque no se han detallado, existen muchas más clasificaciones de las redes
P2P, atendiendo a su generación y a sus características de anonimidad.
1.1.5 APLICACIONES DE REDES PEER-TO-PEER
Aunque, como se ha detallado anteriormente, una mayor capacidad de
almacenamiento y un rápido incremento del ancho de banda disponible han ayudado
al desarrollo de las redes P2P, estos recursos son costosos. Aquellos servicios y
aplicaciones que requieran un uso considerable de estos recursos pueden utilizarse las
redes P2P.
Algunos ejemplos de aplicación de estas redes son los siguientes.
Sistemas de intercambio de archivos. Posiblemente sea la aplicación más
extendida en este tipo de redes. Los propósitos de este tipo de aplicación son
muy variados, desde el uso particular hasta el ámbito educativo. Algunos
ejemplos son LionShare, eDonkey2000 y BitTorrent.
Sistemas de telefonía por Internet. Sistemas basados en VoIP8 (Voice over
Internet Protocol) que permite la transmisión en tiempo real de señales de voz
por la Red. Algunos ejemplos de este tipo de aplicación son Skype y Gizmo5.
Sistemas de archivos distribuidos. Sistema de datos distribuido en los que la
información se almacena en nodos de la red y se permite el acceso de otros
pares a la misma. Algunos ejemplos de este tipo de aplicación son Freenet y
CFS.
Sistemas de P2PTV. Sistemas para la transmisión y difusión de contenidos
audiovisuales a través de Internet. En este tipo de sistemas, los nodos se
7
El término TTL (Time To Live) se refiere al número de veces que puede ser enrutado un paquete antes de
ser descartado o devuelto al origen.
8
El término VoIP (Voice over Internet Protocol) se refiere al conjunto de recursos que hacen posible
enviar la voz en forma digital a través de Internet, utilizando para ello el protocolo IP.
9
Diseño e implementación de un protocolo peer-to-peer
conectan a sus pares para recibir los streams9 de video y audio, en lugar de
conectarse con un servidor central en la televisión basada en IP (Internet
Protocol), IPTV10 (Internet Protocol Television). Algunos ejemplos de este tipo
de aplicación son SopCast y CoolStreaming.
Sistemas de cálculo científico. Sistemas que tienen que manejar grandes
cantidades de datos y tienen una gran carga computacional, como es el caso
de sistemas de administración autónoma para la bioinformática. Un ejemplo
de este tipo de aplicación es Chinook.
1.1.6 PROBLEMAS DE LAS REDES PEER-TO-PEER
Como ya se ha detallado anteriormente, uno de los problemas de las redes P2P
radica en el proceso de búsqueda de los nodos. El problema de encontrar un par que
se encuentre conectado a la red P2P es, comúnmente, solucionado realizando una
conexión con un servidor, en el que la dirección IP es conocida. Este servidor es el
encargado de mantener una lista con las direcciones de los nodos que se encuentran
conectados a la red.
Otro problema es el de la conexión de pares sin dirección IP pública. La solución
que se suele aplicar es la conexión de otro nodo que cumple la función de proxy11. El
resto de los pares se conectan a este proxy el cual envía la información que llega de
uno al otro. Cualquier nodo que esté conectado a la red P2P y tenga una dirección IP
pública puede ser elegido para que cumpla con el cometido de proxy. En este caso, es
de implementación obligatoria el desarrollo de mecanismos de seguridad para evitar
que los proxies puedan acceder a la información que se comunican dos pares de la red.
9
El término stream se refiere a un elemento software que permite un flujo de información entre un
origen y un destino.
10
El término IPTV (Internet Protocol Television) se refiere a una tecnología basada en video streaming de
distribución de señales de televisión y video, que usa conexiones de banda ancha sobre el protocolo IP.
11
El término proxy se refiere a un dispositivo de red que realiza una acción en representación de un
equipo perteneciente a esa red. Su finalidad más usual es permitir el acceso a Internet a todos los
equipos de una organización.
10
Diseño e implementación de un protocolo peer-to-peer
1.2 TECNOLOGÍAS
En este apartado se realizará una breve explicación sobre las principales
tecnologías del proyecto y el motivo de su elección.
1.2.1 JAVA
Java fue desarrollado en 1990 por Sun Microsystems, como parte de un proyecto
de investigación para el desarrollo de una amplia variedad de dispositivos de red, con
el fin de que fuera independiente de la arquitectura del dispositivo. El propósito era
crear una nueva plataforma operativa que, además de ser independiente de la
arquitectura del dispositivo, fuera sencilla, portable, fiable, distribuida y en tiempo
real. Este lenguaje de programación toma mucha de su sintaxis de otros lenguajes
como C, C++, Eiffel y SmallTalk, pero el modelo de objetos que utiliza es más simple y
elimina accesos de bajo nivel. El resultado es un lenguaje que se ha mostrado ideal
para desarrollar aplicaciones de usuario final seguras, distribuidas y basadas en red en
un amplio rango de entornos desde los dispositivos de red embebidos hasta los
sistemas de sobremesa e Internet.
Las características principales de Java [MUÑO04] son las que se muestran a
continuación.
Sencillo, orientado a objetos y familiar: Sencillo, para que no requiera
grandes esfuerzos de entrenamiento para los desarrolladores. Orientado a
objetos, porque la tecnología de objetos se considera madura y es el enfoque
más adecuado para las necesidades de los sistemas distribuidos y clienteservidor. Familiar, porque aunque se rechazó C++, se mantuvo Java lo más
parecido posible a C++, eliminando sus complejidades innecesarias, para
facilitar la migración al nuevo lenguaje.
Robusto y seguro: Robusto, simplificando la gestión de memoria y eliminando
las complejidades de la gestión explicita de punteros y aritmética de punteros
de C. Seguro para que pueda operar en un entorno de red.
Independiente de la arquitectura y portable: Java está diseñado para
soportar aplicaciones que serán instaladas en un entorno de red heterogéneo,
11
Diseño e implementación de un protocolo peer-to-peer
con hardware y sistemas operativos diversos. Para hacer esto posible el
compilador Java genera bytecodes, un formato de código independiente de la
plataforma diseñado para transportar código eficientemente a través de
múltiples plataformas de hardware y software. Es además portable en el
sentido de que es rigurosamente el mismo lenguaje en todas las plataformas.
El bytecode es traducido a código máquina y ejecutado por la Máquina Virtual
Java, que es la implementación Java para cada plataforma hardware software
concreta.
Alto rendimiento: A pesar de ser interpretado, Java tiene en cuenta el
rendimiento, y particularmente en las últimas versiones dispone de diversas
herramientas para su optimización. Cuando se necesitan capacidades de
proceso intensivas, pueden usarse llamadas a código nativo.
Interpretado, multi-thread y dinámico: El intérprete Java puede ejecutar
bytecodes en cualquier máquina que disponga de una Máquina Virtual Java.
Además Java incorpora capacidades avanzadas de ejecución multi-thread,
ejecución simultánea de más de un flujo de programa, y proporciona
mecanismos de carga dinámica de clases en tiempo de ejecución.
Dado que el presente proyecto tiene características de un sistema distribuido,
éste ha de ser independiente tanto del hardware como del sistema operativo en el que
se ejecute. Además la arquitectura planteada se ajusta muy bien a las características
anteriormente mencionadas, sencillez, robustez, multi-thread y demás, por lo que la
elección de Java como lenguaje de implementación es la más indicada para la
implementación del proyecto.
1.2.2 MYSQL
MySQL es un sistema de gestión de bases de datos relacionales desarrollado por
David Axmark y Michael Widenius y actualmente distribuido por la compañía comercial
MySQL AB. Actualmente, según las cifras de la página del proyecto, existen más de seis
millones de copias funcionando en equipos de todo el mundo, lo que le convierte en
uno de los sistemas gestores de bases de datos relacionales más utilizados. MySQL es
muy utilizado en aplicaciones web, ya que es un sistema gestor muy rápido en la
12
Diseño e implementación de un protocolo peer-to-peer
lectura, y en este tipo de aplicaciones el entorno es intensivo en lectura de datos, lo
que hace que MySQL sea excelente para este tipo de aplicaciones. Este hecho hace
que portales web con alta tasa de tráfico, como Google, Amazon y YouTube entre
otros, utilicen este sistema gestor para el almacenamiento y recuperación de datos así
como para el proceso de autenticación de los usuarios.
MySQL está escrito en los lenguajes de programación C y C++, utilizando yacc
como analizador gramatical de SQL (Structured Query Language). Además existen
varias APIs (Application Programming Interface) que permiten a aplicaciones realizadas
en una gran variedad de lenguajes, acceder a las bases de datos, incluyendo C, C++,
Eiffel, Java, Perl, PHP, Python, Ruby, y Tcl. También existe un interfaz ODBC12 (Open
Database Connectivity), llamado MyODBC que permite a cualquier lenguaje de
programación que soporte ODBC comunicarse con las bases de datos MySQL.
Las principales características de este sistema gestor de bases de datos
relacionales [MYSQ09] son las siguientes.
Entorno cliente-servidor o incrustados. El software de bases de datos MySQL
es un sistema cliente-servidor que consiste en un servidor SQL multi-thread
que trabaja con diferentes backends13, programas y bibliotecas cliente,
herramientas administrativas y un amplio abanico de interfaces de
programación para aplicaciones. También proporciona MySQL Server como
biblioteca incrustada multi-thread, la cual se puede lincar en cualquier tipo de
aplicación para obtener un producto más pequeño, rápido y fácil de
administrar.
Rápido, fiable y fácil de usar. MySQL Server se desarrolló originalmente para
tratar grandes bases de datos mucho más rápido que soluciones existentes y
ha sido usado con éxito en entornos de producción de alto rendimiento
durante varios años. MySQL Server ofrece hoy en día una gran cantidad de
12
El término ODBC (Open Database Connectivity) se refiere a un estándar de acceso a bases de datos
desarrollado por Microsoft con el objetivo de hacer posible la comunicación entre una aplicación y el
sistema gestor de bases de datos.
13
El término backend se refiere a un tipo de abstracción que engloba las diferentes partes finales de un
sistema o proceso.
13
Diseño e implementación de un protocolo peer-to-peer
funciones. Su conectividad, velocidad, y seguridad hacen de MySQL Server
altamente apropiado para acceder bases de datos en Internet.
Open source. Open source significa que es posible usar y modificar el
software. Se puede bajar el software MySQL desde internet y usarlo sin pagar
nada. Si se desea se puede estudiar el código fuente y cambiarlo para
adaptarlo a las necesidades del usuario. El software MySQL usa la licencia GPL
(GNU General Public License) y en caso de necesitar añadir código MySQL en
una aplicación comercial, se puede adquirir una licencia de tipo privativa.
Tras la descripción detalla de las características, se puede apreciar que el sistema
gestor de bases de datos relacionales MySQL es una de las mejores propuestas
tecnológicas, ya que las características se ajustan a los requisitos del proyecto, tales
como multi-thread, rapidez y fiabilidad. Además MySQL está bajo licencia GPL, un valor
añadido al producto final que hoy en día es bastante valorado en algunos proyectos.
14
Capítulo 2
Estado del Arte de
las Aplicaciones
Peer-to-Peer
Diseño e implementación de un protocolo peer-to-peer
2.1 ESTADO DEL ARTE
Como ya se ha detallado anteriormente en el apartado de aplicaciones de redes
P2P, existe una gran variedad de aplicaciones P2P con diferentes finalidades. Ya que el
marco de desarrollo del presente proyecto se encuentra en la búsqueda e intercambio
de archivos, el siguiente estudio del estado del arte sólo afecta a aquellas aplicaciones
cuya finalidad es la anteriormente mencionada.
El sistema global de discusión en Internet Usenet, fue unos de los primeros
sistemas de comunicación entre redes. Desarrollado por Tom Truscott y Jim Ellis en
1979 y actualmente vigente, permite el intercambio de opiniones y experiencias entre
los usuarios interesados en el mismo tema.
Comenzó a utilizarse en 1980 empleando UUCP14 (Unix to Unix Copy), lo que
permite el uso de servicio de email y transferencia de archivos, sosteniéndose gracias a
un gran número de servidores distribuidos y actualizados mundialmente que
almacenan y transmiten los mensajes. El gran número de usuarios y grupos, la escasez
de recursos requeridos, la velocidad, el anonimato, su libre acceso y su
descentralización, entre otros, hacen de Usenet la mayor red de intercambio de
información y debate del mundo. También goza de una importancia cultural
significativa, habiendo dado lugar al nacimiento, y popularizado, conceptos
considerablemente reconocidos, como FAQ (Frequently Asked Questions) y spam.
La primera aplicación P2P conocida, desarrollada en el año 1996 por Adam
Hinkley para Mac OS, fue Hotline Connect, más conocida simplemente como Hotline, y
se basaba en la librería AppWarrior que el propio Hinkley había implementado
anteriormente. Distribuida por Hotline Communications, pretendía ser una plataforma
de distribución de archivos destinada al ámbito empresarial y universitario, pero en
muy poco tiempo empezó a servir de intercambio de archivos de dudosa legalidad y
como servicio de IRC (Internet Relay Chat), pasando a segundo plano el intercambio de
archivos de libre distribución.
14
El término UUCP (Unix to Unix Copy) se refiere a un conjunto de programas y protocolos que permiten
la ejecución remota de comandos y transferencia de archivos, emails y netnews entre los ordenadores de
una red.
16
Diseño e implementación de un protocolo peer-to-peer
Hotline se distribuía como shareware15 junto con los servicios de IRC bajo una
arquitectura cliente-servidor. Este hecho obligaba a que en caso de que un servidor
cerrase, la descarga se tenía que cancelar y empezar de nuevo desde otro servidor del
cual seguir descargando el archivo, ya que no existía ningún otro lugar del cual
descargar el archivo.
Existen varias versiones open source de Hotline que no se basan en el código
original de Hinkley, y que incluyen mejoras al protocolo y al servicio IRC, como IRC
bridge o KDX bridge [HAXI01].
Las aplicaciones de las que constaba Hotline eran las que se detallan a
continuación.
Hotline Client. La aplicación que se utilizaba para poder acceder a los usuarios
que ejecutaban la aplicación servidora conociendo la dirección IP de estos.
Hotline Server. La aplicación que ejecutaban los clientes para gestionar el
acceso a los recursos.
Hotline Tracker. Un servidor de nombres que mantenía las direcciones IP de
los clientes que ejecutaban la aplicación servidora.
Figura 6. Arquitectura de Hotline Connect
15
El término shareware se refiere a un tipo de distribución de aplicaciones en la que el usuario puede
evaluar el software de forma gratuita y durante un tiempo determinado.
17
Diseño e implementación de un protocolo peer-to-peer
El problema de la dependencia de las descargas al servidor al que el usuario se
encontrara conectado y la dependencia de la ejecución de la aplicación en sistemas
MAC, una plataforma minoritaria en aquel tiempo, motivó la aparición de Napster.
Napster fue desarrollado por Shawn Fanning y ofrecía un servicio de distribución
de archivos de música en formato MP3 (MPEG-1 Audio Layer 3), que facilitaba la
búsqueda de estos por medio de la centralización, en lugar de buscar en IRCs o en
buscadores de Internet.
Fue el primer sistema P2P de distribución de archivos entre pares basado en una
red centraliza, ya que utilizaba un servidor central para mantener la lista de usuarios
conectados y archivos compartidos por cada uno de ellos, mientras que las
transferencias de archivos, sin embargo, eran realizadas entre los usuarios sin ningún
tipo de intermediario. Aunque hubo varias redes que facilitaban la distribución de
archivos a través del Internet, Napster se especializaba directamente en música, en
archivos de formato MP3, presentados a través de una interfaz amigable al usuario. El
resultado fue un sistema cuya popularidad generó una enorme selección de música
para descargar. El servicio y programa eran inicialmente sólo para plataformas
Windows, pero en el 2000 Black Hole Media realizó un cliente llamado Macster para
sistemas Mac.
Figura 7. Arquitectura de Napster
18
Diseño e implementación de un protocolo peer-to-peer
El hecho de que Napster fuera un servicio centralizado resultó su perdición ya
que varias discográficas estadounidenses demandaron a Napster, reclamando su cierre
a la RIAA16 (Recording Industry Association of America). A pesar de la clausura del
servicio, existían ya bastantes alternativas, como servidores no oficiales, OpenNap, y
una gran variedad de aplicaciones como Winmx e iMesh. Después se estableció
Audiogalaxy como el sistema P2P más utilizado por los usuarios de Internet, otra
aplicación centralizada de intercambio de música, que acabó clausurada también por
orden judicial de la RIAA.
El cierre de los servidores de aplicaciones centralizadas como Napster y
Audiogalaxy, motivó nacimiento de las redes descentralizadas y semicentralizadas,
pues para terminar con estas bastaba con eliminar el servidor central que almacenaba
las listas de los archivos compartidos y de los usuarios conectados a la red.
Una de ellas, eDonkey, también conocida como eDonkey2000 o eD2K, apareció
por primera vez en Septiembre del 2000 desarrollada por MetaMachine. Esta red se
puede clasificar del tipo semicentralizada, pues utilizaba servidores para almacenar la
información de los usuario y de los archivos, pero ninguno de estos era central, por lo
que en caso de fallo otro servidor podía seguir ofreciendo el servicio, incluso los
usuarios de las red podían crear sus propios servidores.
Los elementos de la red eDonkey son los que se detallan a continuación.
Servidores. Utilización de servidores para conectar a los clientes.
Metadatos. Envío de metadatos de un archivo justo en el momento de enviar
la información de los archivos compartidos al servidor.
Enlaces. Utilización de enlaces llamados elinks o ed2k links para permitir la
identificación, por medio de una función hash, de un archivo o un servidor en
el navegador del cliente y transferirlo a la aplicación. La estructura típica de
los
enlaces
para
identificar
un
archivo
es
la
siguiente.
ed2k://|file|NOMBRE.EXTENSIÓN|TAMAÑO|HASH|. Opcionalmente se podía
16
El término RIAA (Recording Industry Association of America) se refiere a una asociación americana que
representa a la industria discográfica.
19
Diseño e implementación de un protocolo peer-to-peer
añadir al final del enlace la referencia a la dirección IP y el puerto del cliente
que compartía el archivo /|sources, DIRECCIÓN_IP:PUERTO|/. La estructura típica
de
los
enlaces
para
identificar
un
servidor
es
la
siguiente.
ed2k://|server|IP|PUERTO|/
Detección de errores. División de los archivos transmitidos en bloques de
9500 KB generando un hash, por medio del algoritmo MD417, por cada bloque
y luego de la suma del resto, conocido como raíz o root, para comprobar los
datos transmitidos y evitar la corrupción de los bloques.
El funcionamiento de la red era el siguiente. Cuando un cliente se conecta a la
red, se realiza un proceso de handshake entre éste y el servidor, para anunciar los
archivos que se comparten. En el proceso de las búsquedas, el cliente envía la petición
al servidor, el cual se encarga de buscar el archivo en la información que los clientes le
proporcionaron durante el handshake. Cuando la petición es aceptada, el servidor
establece una conexión entre los dos clientes y comienza la descarga.
Figura 8. Arquitectura de eDonkey
17
El término algoritmo MD4 se refiere a un algoritmo de función hash diseñado Ronald Rivest para el uso
en comprobaciones de integridad de mensajes que produce un identificador de 128 bits.
20
Diseño e implementación de un protocolo peer-to-peer
Ya que la red eDonkey estaba basada en servidores administrados por los
usuarios, estos podían ser objeto de tráfico pesado y, por consiguiente, más
vulnerables a los ataques. Para solventar este problema, MetaMachine, desarrolló la
red Overnet como su sucesor en el protocolo eDonkey. Overnet fue una red de
ordenadores P2P descentralizada, normalmente usada para compartir grandes
archivos que implementaba una variante del protocolo Kademlia.
En 2006, MetaMachine, alcanzó un acuerdo con la RIAA para evitar un juicio por
infracción de los derechos de propiedad intelectual. La compañía dejó de distribuir su
software y acordó pagar una compensación monetaria. En Septiembre del 2006, la red
eDonkey2000 dejó de funcionar, sin embargo, se puede comprobar que, por el
momento, sigue en funcionamiento usando otros clientes, como los que se muestran a
continuación.
NOMBRE
REDES
ANÓNIMO
LICENCIA
PLATAFORMA
LENGUAJE
aMule
eDonkey
Kad
No
GPL
Windows, Linux
MAC OS
C++
eMule
eDonkey
Kad
No
GPL
Windows
C++
BitTorrent
eDonkey
FastTrack
MLDonkey
Gnutella
Gnutella2
Kad
No
GPL
Windows, Linux
MAC OS
Ocaml
Lphant
BitTorrent
eDonkey
No
Freeware con
Adware
Windows, Linux
MAC OS
C#
Shareaza
BitTorrent
eDonkey
Gnutella
Gnutella2
No
GPL
Windows
C++
TrustyFile
BitTorrent
eDonkey
FastTrack
Gnutella
Gnutella2
Overnet
No
Código
cerrado
Windows
Desconocido
Figura 9. Clientes eDonkey
21
Diseño e implementación de un protocolo peer-to-peer
NOTA: En la tabla anterior no se han incluido todos los mods, modificaciones de
los clientes con respecto a su original, ya que el tamaño de la tabla habría aumentado
considerablemente.
Paralelamente al cliente eDonkey, existía el cliente eMule, desarrollado por
Hendrik Breitkreuz en Mayo del 2002 por discordancias con este, en poco tiempo lo
superó en funciones, y sumando el hecho de que era libre y gratuito, entre otros
motivos, lograron que en poco tiempo lo superase en popularidad para convertirse en
uno de los programas más usados por los usuarios de redes P2P.
eMule es un programa para intercambio de archivos con sistema P2P que utiliza
el protocolo eDonkey y la red Kad, publicado como software libre para sistemas
Windows. Está implementado en Microsoft Visual C++ haciendo uso de la librería
Microsoft Foundation Classes y se encuentra bajo licencia GPL.
Las características de eMule son las que se detallan a continuación.
Intercambio directo. Al igual que eDonkey, el intercambio de los archivos se
realiza directamente entre clientes, con el previo proceso de handshake con el
servidor.
Uso de una red descentralizada. Los clientes de eMule pueden conectarse
opcionalmente a una red descentralizada denominada Kad, utilizando el
protocolo Kademlia, la cual no depende de servidores centrales pero sí utiliza
tablas hash distribuidas.
Licencia GPL. El hecho de estar bajo esta licencia, implica que cualquier
usuario puede modificar el código libremente. Por este motivo han
proliferado toda una serie de modificaciones, mods, del programa original,
como eMule Plus o eMule MorphXT.
Detección de errores y recuperación de partes. Se utiliza algoritmos de
detección de errores, que dividen los archivos en bloques de 9500 KB y
generando un hash, por medio del algoritmo MD4, para comprobar los datos
transmitidos. Además el sistema AICH (Advanced Intelligent Corruption
22
Diseño e implementación de un protocolo peer-to-peer
Handling) utiliza el método de hashtree18 para fragmentar el archivo en
bloques de 180 KB, disminuyendo así la cantidad de datos que hay que volver
a descargar para corregir un error de transmisión.
Transferencias comprimidas. Cada vez que eMule transmite datos, estos se
comprimen con la librería zlib, de forma totalmente transparente al usuario y
ahorrando ancho de banda.
Comentarios para los archivos. Se permite calificar la calidad de un archivo y
escribir comentarios sobre él para que otros usuarios los puedan leer,
pudiendo así saber de antemano si el archivo tiene la calidad esperada o si
está corrupto. El problema es que para leer los comentarios de un usuario,
previamente se ha tenido que conectar a este.
Archivos de colección. Se permite crear archivos en un formato especial
llamado colección. Este tipo de archivo contiene un conjunto de enlaces de
eMule, dando la posibilidad de bajarlo como un conjunto y guardar toda la
colección de archivos como un conjunto, aunque cada descarga se gestiona
independientemente.
Previsualización archivos multimedia. Se permite la visualización de diversos
tipos de archivos, como audio y vídeo, aunque el archivo no se haya
descargado completamente, siempre que el usuario tenga instalado un
reproductor multimedia.
Mensajería instantánea. Cuenta con la posibilidad de enviar mensajes a
usuarios de la red eDonkey 2000 conectados a las descargas en curso y de un
chat IRC para buscar información sobre lo que interese a los usuarios.
Además de las características anteriores, eMule se distingue por la utilización de
un sistema de créditos por el cual los usuarios que más archivos aporta a la red, más
rápido avanzan en las colas de descarga de un archivo. Es la forma de recompensar,
mediante un algoritmo meritocrático, a los usuarios que aportan recursos a la red. El
sistema de gestión de la cola de descarga está basado en el tiempo de espera de un
usuario en la cola de descarga de un archivo. El sistema de créditos proporciona un
18
El término hashtree se refiere a una estructura de datos que contiene los valores hash de un árbol y
que se utiliza para verificar su contenido.
23
Diseño e implementación de un protocolo peer-to-peer
ratio de modificación al algoritmo de gestión de la cola de descarga, en función de la
cantidad de datos transferidos entre dos clientes. Los créditos se almacenan en cada
usuario para evitar que sean modificados, con la problemática de que únicamente se
obtendrán créditos en los usuarios en los que se haya transferido un archivo.
La expresión de cálculo que utiliza el sistema de créditos está compuesta por dos
ratios [MONK03].
1 2 2 √
2
Al terminar el cálculo, ambos ratios son comparados y el sistema de créditos
elige el menor como ratio de modificación al algoritmo de gestión de la cola de
descarga. Existen tres restricciones a este cálculo, que son las siguientes.
El ratio de modificación al algoritmo de gestión de colas es un número entre 1
y 10.
Si el total subido es menor que 1 MB, entonces el ratio de modificación
permanece a 1.
Si el cliente no ha descargado nada, el ratio de modificación es fijado a 10.
Una excepción a esta regla se aplica sólo cuando un par es asignado como amigo
después de la agregación a la lista de amigos del cliente. Esto automáticamente asigna
una posición en la cola de descarga para que se pueda comenzar a descargar,
independientemente de la calificación de los anteriores ratios. Sólo se puede reservar
una posición para un amigo, para impedir cualquier forma de abuso.
Otra de las características de distinción es la ofuscación del protocolo. Esta
función evita que las conexiones sean detectadas y, posteriormente, bloqueadas por
los ISPs (Internet Service Provider). La ofuscación del protocolo es una característica
que hace que eMule encubra su protocolo al comunicarse con un servidor u otros
clientes. Sin ofuscación, cada comunicación de eMule tiene una estructura
predeterminada que puede ser fácilmente identificada por un packet sniffer, programa
24
Diseño e implementación de un protocolo peer-to-peer
de captura de las tramas de red. Si se activa el modo ofuscado, toda la comunicación
simula estar compuesta de datos aleatorios y ya no es posible realizar una
identificación. Esto ayuda en situaciones en las que, mediante identificación de
paquetes, el protocolo eMule es bloqueado. No hay que confundir el modo ofuscado
con un modo que proporciona anonimato.
Para la identificación de archivos, estos tienen asignado un valor mediante una
función hash, que identifica de forma unívoca un archivo aunque este tenga diversos
nombres, de manera que un mismo archivo que tengan diferentes usuarios, aunque
alguno de ellos modifique el nombre, este sigue siendo el mismo. Además, todos los
archivos se separan en bloques de 9500 KB y de cada una de estas partes se calcula su
valor hash, mediante el algoritmo MD4, de manera que el valor hash final del archivo
es el resultado de aplicar la función hash MD4 a la concatenación de los valores hash
de todas sus partes. En los elinks es imprescindible especificar el hash del archivo y
también su tamaño correcto.
Como se ha detallado anteriormente, eMule dispone de dos redes, una red
basada en servidores eDonkey y una descentralizada, denominada Kad. A continuación
se explica el funcionamiento de cada una de ellas.
Para conectarse a la red de servidores, es necesario conocer la dirección IP del
servidor. Una vez el cliente se ha conectado a un servidor, éste le comunica los
archivos que quiere compartir. La lista de servidores que presenta eMule puede ser
actualizada, permitiendo búsquedas más precisas y extensas y encontrar servidores
más rápidos.
La red Kad es una red totalmente descentralizada, que usa una variante del
protocolo Kademlia y diseñada para que eMule pueda mantenerse activo tras una
posible caída de la red de servidores. Para conectarse a esta red hay que conocer la
dirección IP de otro par, pero es posible conectarse a partir de los pares obtenidos de
la red de servidores. Cada par conoce una pequeña parte de la red, de manera que el
tamaño de la red puede crecer tanto como haga falta sin afectar al rendimiento.
25
Diseño e implementación de un protocolo peer-to-peer
Cuando un nodo se conecta, almacena los identificadores de los archivos que
quiere compartir con otros pares, escogidos en función del identificador del archivo
mediante tablas hash distribuidas. Cuando se quiere descargar un archivo, se localizan
los pares que lo indexan y estos devuelven la lista de fuentes para este archivo
concreto.
La búsqueda por nombre funciona de una manera parecida, guardando el
nombre del archivo dentro de otros nodos escogidos en función de cada palabra del
nombre. Una búsqueda en Kad se ejecuta siempre en toda la red.
Esta red utiliza el protocolo de nivel de transporte UDP (User Datagram Protocol)
para las siguientes funciones.
Encontrar fuentes para valores hash eDonkey.
Búsquedas de valores hash eDonkey basadas en palabras clave del nombre
archivo.
Encontrar comentarios y valoraciones de los archivos.
Almacenar direcciones, comentarios y nombres de archivos.
Uno de los problemas de esta red es que ya que los nodos están comunicándose
continuamente entre ellos puede producir una mayor carga en máquinas.
Como alternativa a eMule, en Abril del 2001 apareció el protocolo BitTorrent,
desarrollado por Bram Cohen y liberada la primera implementación en Julio del 2001
[COHE01], actualmente mantenido por la empresa BitTorrent.
BitTorrent es un protocolo P2P de transferencia de archivos más comunes para
transferir archivos grandes, algunas estimaciones otorgan la cantidad total de
contenido compartido actualmente en más de 1,4 PB [ISOH08].
26
Diseño e implementación de un protocolo peer-to-peer
Figura 10. Cantidad de contenido compartido de BitTorrent
El protocolo trabaja inicialmente cuando un usuario crea un archivo y lo hace
disponible a otros usuarios de la red, esto es lo que comúnmente se conoce con el
nombre de semilla y permite que otros pares se puedan descargar este archivo.
Para compartir un archivo o grupo de archivos, un usuario debe crear primero un
pequeño archivo con extensión .torrent. Este archivo es estático, por lo que a menudo
se encuentra en páginas web o incluso se distribuye por correo electrónico. El archivo
.torrent contiene la dirección de un servidor de búsqueda, o tracker, el cual se encarga
de localizar posibles fuentes. Este servidor realmente se encuentra centralizado y
provee estadísticas acerca del número de transferencias, el número de nodos con una
copia completa del archivo y el número de nodos que poseen sólo una parte del
mismo.
Los clientes que deseen descargar el archivo primero debe obtener el archivo
.torrent, para poder conectarse a otros nodos de la red que tiene el archivo y así poder
empezar la descarga. La estructura que forman sus conexiones es conocida con el
nombre de enjambre. El archivo deseado es descargado de las fuentes encontradas
por el servidor de búsqueda y, al mismo tiempo que se realiza la descarga, se comienza
a subir las partes disponibles del archivo a otros pares. El hecho de compartir el
archivo, incluso antes de completar la descarga, contribuye a la distribución de este ya
que a medida que más pares se descarguen el archivo, la probabilidad de éxito de la
descarga y la velocidad de la misma aumentan.
27
Diseño e implementación de un protocolo peer-to-peer
Figura 11. Enjambre de BitTorrent
Cuando un usuario comienza la descarga de un archivo, no necesariamente se
comienza por el principio, sino que se descarga por partes al azar. Luego los usuarios
se conectan entre sí para la descarga. Por supuesto, inicialmente alguien debe poseer
el archivo completo para comenzar el proceso. Este método produce importantes
mejoras en la velocidad de transferencia cuando muchos usuarios se conectan para
bajar un mismo fichero. Cuando no existan ya más nodos conectados al servidor de
búsqueda con el fichero completo, existe la posibilidad de que el fichero no pueda ser
completado.
La eficacia de la transferencia depende en gran medida de las políticas que los
clientes usan para determinar a qué par enviar los datos. Los clientes pueden preferir
enviar datos a los pares que les han envían anteriormente datos que a los nuevos
pares que se han añadido al enjambre, ésta estrategia se conoce con el nombre tit for
tat19. Para contrarrestar este efecto, el cliente BitTorrent utiliza un mecanismo, según
el cual el cliente se reserva un porcentaje de su ancho de banda disponible para el
envío de bloques a pares tomados al azar, con la finalidad de garantizar que pares
nuevos puedan unirse al enjambre [AMIL06].
19
El término tit for tat se refiere a un estrategia en teoría de juegos, propuesta por Anatol Rapoport para
el dilema del prisionero, que consiste en repetir lo que el oponente hizo en la ronda anterior.
28
Diseño e implementación de un protocolo peer-to-peer
Los archivos que se distribuyen entre los pares son tratados en bloques,
normalmente, de entre 32 KB y 4 MB. El par aplica una función hash, usando el
algoritmo SHA120, y almacenándolo en el archivo torrent. Cuando otro par recibe un
bloque del archivo que se está descargando, se le aplica la función hash, y el valor
obtenido es comparado con el almacenado, para comprobar que se encuentra libre de
error. El valor de comprobación que se encuentra contenido en el archivo torrent,
depende de la versión del protocolo BitTorrent utilizado. Por convención, los archivos
torrent tiene un apartado llamado anuncio, en el cual se especifica la URL (Uniform
Resource Locator) del servidor de búsqueda, y una sección de información, la cual
contiene los nombres de los archivos, sus tamaños, longitud, y el valor hash SHA1 por
cada uno de los bloques. Toda esta información es usada por los clientes para verificar
la integridad de los datos recibidos.
Una vez creado el archivo torrent, este es publicado en algún sitio web o en otra
parte, y registrado en el servidor de búsqueda. El servidor de búsqueda mantiene una
lista de clientes que se encuentran participando sobre el archivo torrent.
Alternativamente, en un sistema descentralizado, cada par actúa como un servidor de
búsqueda, característica implementada por clientes como µTorrent, BitComet y
KTorrent a través de métodos de tablas de hash distribuidas.
A pesar de la eficacia y el alto rendimiento de las transferencias, el protocolo
BitTorrent tiene unas cuantas limitaciones, que se pasaran a detallar a continuación.
El protocolo no ofrece anonimato a los clientes, haciendo posible que se puedan
obtener las direcciones IP de los clientes que se encuentran en un enjambre. Esto
puede exponer a los usuarios a posibles ataques de agentes externos o propios de la
red.
Un usuario BitTorrent, a menudo, puede decidir dejar el enjambre en cuanto
tenga una copia completa del archivo descargado, a este usuario se le conoce
comúnmente con el nombre de leecher o sanguijuela. Si un número considerable de
20
El término algoritmo SHA1 se refiere a un algoritmo de función hash diseñado por NIST (National
Institute of Standards and Technology) y NSA (National Security Agency) para el uso en comprobaciones
de integridad de mensajes que produce un identificador de 160 bits.
29
Diseño e implementación de un protocolo peer-to-peer
usuarios siguen esta conducta, el número de semillas se reduce hasta que llegar a cero
y por lo tanto el archivo desaparece. Algunos sitios web BitTorrent han intentado
solventar este problema mediante el seguimiento de los ratios de subida y descarga de
archivos. En caso de existir una diferencia considerable entre ambos ratios, los clientes
obtendrán velocidades de descarga inferiores hasta que los ratios se compensen.
Ya que el protocolo BitTorrent es open source, al igual que sus clientes, han
proliferado una gran cantidad de clientes basándose en el código original, disponibles
en cualquier plataforma e implementados en una larga lista de lenguajes de
programación. El cliente oficial de BitTorrent, BitComet, Vuze y μTorrent son los más
populares entre los usuarios de este protocolo.
Algunos clientes, como Torrentflux y TorrentVolve, se pueden ejecutar
directamente desde un servidor, lo que permite a empresas de hosting ofrecer
velocidades superiores a los usuarios. BitLet permite a los usuarios descargar torrents
directamente desde su navegador, usando un applet de Java.
Existen versiones propietarias del protocolo que implementan DRM, como es el
caso de Pando.
Algunos clientes del protocolo BitTorrent son los que se muestran a
continuación.
NOMBRE
PLATAFORMA
LENGUAJE
TRACKER
ADMITE
DHT
TORRENTS
ACTIVOS
ABC
Windows Linux
Python
No
No
8
Ares Galaxy
Windows
Delphi
BitComet
Windows
C++
BitTornado
BitSpirit
Ktorrent
Lphant
Windows, Linux
MAC OS
Windows
Linux, MAC OS
Windows, Linux
MAC OS
Desconocido Desconocido Desconocido
Descargas
Sí
8
separadas
Python
Sí
No
8
C++
C++
No
No
Sí
Sí
8
8
C#
Sí
Desconocido
8
30
Diseño e implementación de un protocolo peer-to-peer
MLNet
Rtorrent
Shareaza
Vuze
μTorrent
Windows, Linux
Ocalm
MAC OS
Linux, MAC OS
C++
Windows
C++
Windows, Linux
Java y SWT
MAC OS
Windows, Linux
C++
MAC OS
No
No
8
No
No
No
Sí
8
10
Integrado
Sí
Sin límite
Integrado
Sí
8
Figura 12. Clientes BitTorrent
NOTA: En la tabla anterior no se han incluido todos los clientes, ya que el tamaño
de la tabla habría aumentado considerablemente. Sólo se han mostrado los más
populares.
El sistema de más reciente aparición ha sido Omemo, un sistema de
almacenamiento virtual distribuido open source, basado en tablas de hash distribuidas,
distribuido por la firma española MP2P Technologies y desarrollado por Pablo Soto.
La diferencia fundamental de Omemo con el resto de los sistemas P2P radica en
que no se comparten archivos, sino espacio libre de almacenamiento. Con el hecho de
aportar parte de espacio al disco, se obtienen dos beneficios a cambio, el primero, el
derecho de escritura persistente en el disco y el segundo, el derecho de lectura de
todos los contenidos del disco. El derecho de escritura es calculado en base a la
cantidad de espacio que se aporta y al tiempo durante el que se contribuye. La
principal novedad es la persistencia, no es necesario que el usuario esté conectado
para que los que dispone archivos estén accesibles para el resto de la red. Omemo
ofrece muchas más novedades, tantas que sus creadores lo denominan P2P 2.0.
Las características de Omemo son las siguientes [SOTO06].
Persistente. Se puede copiar algo en él, y luego desconectarse. A diferencia de
los P2P actuales, el contenido que se comparte sigue disponible en Omemo
cuando el usuario se desconecta.
31
Diseño e implementación de un protocolo peer-to-peer
Rápido. Se puede transferir archivos del disco con velocidades iguales o
superiores a las de un servidor FTP (File Transfer Protocol) o HTTP (HyperText
Transfer Protocol).
Organizado.
Se
puede
crear
y
destruir
carpetas
para
organizar
categóricamente los archivos. El estado actual del disco es el resultado
democrático de los cambios que todos los usuarios van haciendo sobre él.
Anónimo. No hay forma de conocer quién es el usuario que publica un
archivo, ni quién lo descarga. El diseño lógico del disco impide a un
observador externo conocer las actuaciones de otros usuarios.
Buscable. Se puede buscar cualquier archivo entre todos los que hay en el
disco. El horizonte buscable, a diferencia de los P2P actuales, es ilimitado. Por
muy grande que sea el disco, se puede buscar en toda su estructura.
Para la búsqueda de archivos, Omemo incluye un buscador que muestra todos
los resultados, salvo lo que cada usuario quiere reservar para sí mismo y los que él
desee, ya que el programa permite crear carpetas de acceso restringido.
En el proceso de transferencia del archivo, este es fragmentado en paquetes de
64 KB y a cada trozo se le imprime una clave digital única, después se cifran los
fragmentos y antes de lanzarlo a la red se les asigna un identificador que permite al
sistema su posterior rastreo y recomposición en el archivo original. Estas medidas de
seguridad hacen de Omemo el programa de intercambio más anónimo y refractario a
la censura. No existe, actualmente, forma alguna de conocer quién ha subido un
determinado archivo y quién se lo descarga.
Siguiendo la corriente Web 2.0, los diferentes archivos pueden ser valorados por
los usuarios etiquetando cada archivo. Cuando alguien no quiere determinado material
se elimina, desapareciendo de la lista del usuario pero no de la red. La combinación de
votos negativos y positivos hace que unos archivos suban de puntuación y otros vayan
quedando obsoletos.
32
Diseño e implementación de un protocolo peer-to-peer
2.2 CONCEPTOS Y TECNOLOGÍAS ACTUALES
Para concluir el presente estudio del estado del arte de las aplicaciones P2P, se
detalla a continuación conceptos y tecnologías actuales.
2.2.1 P2P ANÓNIMO
Una red P2P anónima es un tipo particular de red P2P en la que los pares son
anónimos por defecto. La principal diferencia entre las redes P2P habituales y las
anónimas está en el método de encaminamiento de las respectivas arquitecturas de
redes. Estas redes permiten el flujo libre de información.
En una red P2P anónima, cada par de la red tiene un pseudónimo asociado a su
dirección IP, para poder ser alcanzado por otro par y así intercambiar archivos. Sin
embargo, normalmente esta dirección, especialmente en redes anónimas, no contiene
información alguna que pueda permitir la identificación. Por tanto, un usuario es
prácticamente anónimo.
El anonimato viene de la idea en la que nadie sabe quien requiere la información,
ya que es difícil determinar si un usuario ha pedido los datos para él mismo o
simplemente está pidiendo datos que le ha requerido otro usuario. El resultado final es
que todos los pares en una red anónima actúan como un emisor y un receptor global
para mantener el anonimato.
El interés de la comunidad P2P en el anonimato ha incrementado muy
rápidamente desde hace unos años por varias razones, entre ellas la desconfianza en
todos los gobiernos y los permisos digitales. Tales redes suelen ser utilizadas por
aquellos que comparten archivos musicales con copyright.
Los usos más frecuentes de la tecnología P2P anónima son los que se muestran a
continuación.
Navegación anónima por Internet.
Bloqueo de la posibilidad del registro de visitantes de sitios web.
Evasión de la censura de ISPs.
33
Diseño e implementación de un protocolo peer-to-peer
2.2.2 REDES FRIEND-TO-FRIEND
El término friend-to-friend, en adelante F2F, fue acuñado por Dan Bricklin y hace
referencia a un tipo particular de red P2P anónima en donde los pares se conectan
directamente a otros pares conocidos. Las aplicaciones F2F solamente permiten la
conexión con otros pares en los que el usuario confía, usando direcciones de IP o
firmas digitales para las transferencias de archivos. De esta manera, los usuarios
pueden descargar indirectamente archivos de otro nodo de manera anónima.
Una de las mayores ventajas de este tipo de redes es que pueden crecer en
tamaño sin comprometer el anonimato del usuario. Ejemplos de este tipo de redes son
ANts P2P, GNUnet, Mute y Turtle F2F.
2.2.3 PEER-TO-MAIL
Peer-to-mail, en adelante P2M, es un programa que permite almacenar y
compartir archivos en cuentas de correo.
La posibilidad hoy en día de emplear cuentas privadas para el intercambio de
ficheros por el aumento de la capacidad de almacenamiento, ha facilitado el uso del
P2M, el cual ha surgido ante los problemas que encuentran algunos usuarios al usar
programas P2P. El principal inconveniente es que en programas P2P no se consigue
siempre una gran velocidad y un rango de tiempo corto para descargar un archivo.
Además, las descargas en las aplicaciones P2P están reguladas por un sistema de colas,
el cual ocasiona que estas sean muchas veces bastantes grandes, causando con ello
una demora en la descarga.
P2M funciona de la siguiente manera, primero los archivos compartidos se
dividen en segmentos que son hospedados en servidores de correo, el tamaño del
segmento está condicionado por el tamaño máximo de archivo adjunto que admite el
servidor de email donde son alojados. Mediante programas se accede a las cuentas
creadas por los usuarios con el fin de subir los archivos a compartir y dichos programas
recopilan y descargan todos los segmentos de la cuenta. Una vez descargados, el
programa une todos los segmentos para restablecer el archivo íntegro tal y como se
34
Diseño e implementación de un protocolo peer-to-peer
subió al servidor. La unión de los segmentos descargados se realiza con programas
externos a la aplicación P2M.
2.2.4 WEBCACHÉ
Webcaché es una característica de algunos clientes P2P de la red eDonkey que
hacen uso de un proxy caché, una máquina que almacenan en su memoria lo que
acaba de pasar por ella en el tránsito de un par a otro, con la finalidad de disminuir el
tráfico entre estos.
Los usuarios que usan la opción webcaché de estos programas, suben una parte
del archivo que comparten. De esta forma, se permite que otro usuario que pida al
usuario ese trozo de archivo, en realidad le pida el mismo trozo de archivo al proxy
caché, que lo tiene en su memoria, la cual es mucho más rápida.
Estas máquinas tienen un ancho de banda muy grande, más que cualquier
conexión entre dos pares, con lo que se permite aprovechar la velocidad de conexión,
siempre que no se colapsen.
2.2.5 PROACTIVE NETWORK PROVIDER PARTICIPATION FOR P2P
Proactive network Provider Participation for P2P, más conocido por su acrónimo
P4P, es un medio utilizado por los proveedores de Internet para optimizar el tráfico de
las redes P2P de sus usuarios.
Es el siguiente paso en el desarrollo de servicios P2P, ya que permite minimizar el
número de saltos requeridos para las transferencias de archivos, eligiendo los pares
más cercanos a otro, siempre y cuando pertenezcan al mismo proveedor.
35
Capítulo 3
Motivación y
Objetivos del
Proyecto
Diseño e implementación de un protocolo peer-to-peer
La búsqueda e intercambio de archivos de las actuales aplicaciones de redes P2P
están muy condicionados al servidor al que se encuentre conectado el cliente, ya que
diferentes conexiones entre distintos servidores producen diferentes resultados.
Para demostrar este hecho, se ha hecho uso del cliente de la red eDonkey, eMule
v0.49b, y se ha buscado en dos servidores distintos un archivo del sistema operativo
Ubuntu, versión 8.04 Hardy Heron, para arquitecturas AMD. Los resultados obtenidos
son los que se muestran a continuación.
Figura 13. Resultados en la conexión con el servidor 212.63.206.35
Figura 14. Resultados en la conexión con el servidor 195.22.108.26
37
Diseño e implementación de un protocolo peer-to-peer
Como se puede apreciar en las dos imágenes anteriores, los resultados de la
búsqueda difieren en el número de resultados, 18 para el primer caso y 10 para el
segundo. Además, para resultados iguales, como sucede en el primer caso, la
disponibilidad y el número de fuentes completas, atributos que reflejan el número de
fuentes que tienen el archivo, también es diferente, por lo que la búsqueda y la
posterior descarga del archivo dependen del servidor en el que el cliente se conecte.
Además, con el fin de reducir la cadena de búsqueda, si el usuario de la
aplicación cliente introduce “Ubu”, “Ubun”, “Ubunt” o cualquier combinación que no
contenga una palabra del nombre completo del archivo a buscar, “Ubuntu”, no se
produce ningún resultado en ambos servidores.
Tras el breve análisis anterior, se demuestra que los resultados de las búsquedas
que realiza el cliente, dependen de la conexión con el servidor, dando lugar a
diferentes resultados en diferentes conexiones. Este hecho origina una preferencia por
parte de los clientes en el momento de elegir el servidor al que conectarse, y por lo
tanto que exista una serie de servidores preferidos. De este modo se consigue que
unos servidores alcancen un gran número de conexiones con clientes, mientras que en
otros el número de estas sea mínimo, provocando una ineficiente gestión y reparto de
los recursos disponibles. Otra consecuencia de este hecho es el deficiente reparto de la
carga de trabajo entre los servidores, ya que en aquellos en los que más conexiones
haya, mayor será la carga de trabajo, mientras que los menos favorecidos apenas
recibirán solicitudes de búsqueda de archivos.
Otra ineficiencia, común entre los clientes de redes P2P, es que en el momento
de introducir una cadena de búsqueda para la posterior descarga de un archivo, ésta a
de contener el nombre exacto del archivo, en algunos casos, o al menos una palabra
completa de la totalidad del nombre del archivo a buscar, como ya se detalló con
anterioridad. De esta forma se caracteriza de cierta severidad a las búsquedas en estos
sistemas, obligando al usuario conocer una serie de atributos del nombre del archivo, a
diferencia de las búsquedas en buscadores de Internet, que son menos rígidas en lo
referente a la cadena de búsqueda.
38
Diseño e implementación de un protocolo peer-to-peer
Como ya se detalló en el estado del arte, algunas aplicaciones P2P permiten que
los usuarios califiquen la calidad de un archivo mediante la escritura de comentarios
sobre ese determinado archivo para que otros usuarios puedan leerlos, y así saber de
antemano si el archivo tiene la calidad esperada o si está corrupto. El problema es que
para leer los comentarios de un usuario, es necesario el inicio de la descarga de un
archivo y la conexión a usuarios que tenga disponible este archivo para compartir y
que hayan escrito comentario sobre él. Además, no todos los comentarios de la red
son accesibles ya que en este tipo de aplicaciones se suelen limitar el número de
conexiones y por lo tanto, indirectamente, afectan a la cantidad de comentarios a los
que se puede acceder.
Después de haber analizado y detallado algunas de las carencias de los actuales
clientes de búsqueda y transferencia de archivos de redes P2P, se puede concluir que
existe un desequilibrio entre lo que ofrecen este tipo de aplicaciones y lo que
demandan los usuarios. Por este motivo, el objetivo de este proyecto es el diseño e
implementación de un protocolo P2P, que mejore el proceso de búsqueda de los
archivos entre los usuarios que se encuentren conectados a la red. Se entiende por
mejora la eliminación de la dependencia del proceso de búsqueda al servidor al que el
usuario se encuentre conectado, obteniendo de esta forma las siguientes mejoras
tanto en los servidores como en los clientes.
Aumento del número de resultados. Al eliminar la dependencia de la
conexión con el servidor, el número de archivos encontrados en el proceso de
búsqueda, el número de fuentes encontradas que tienen disponible el archivo
para compartir y el número de comentarios de los usuarios que califican los
archivos, serán mayores.
Reducción del tiempo de transferencia del archivo. Dado que el número de
fuentes encontradas es mayor, se reducirá considerablemente el tiempo de
transferencia del archivo, ya que la probabilidad de conexión a un mayor
número de pares se incrementa.
39
Diseño e implementación de un protocolo peer-to-peer
Eliminación del mantenimiento de una lista de servidores. Al no existir una
dependencia con el servidor, los clientes no tendrán que mantener una lista
de servidores en la que elegir sus favoritos y su prioridad en el proceso de
conexión, por lo que se le libera de una tarea innecesaria.
Óptima gestión de los recursos. Al eliminar una preferencia de conexión
entre un servidor u otro, las conexiones de los clientes entre los distintos
servidores de la red estarán más equilibradas.
Eficiente reparto de la carga de trabajo. Al realizar un gestión óptima de los
recursos, en este caso los servidores que se encuentran conectados a la red, el
reparto de carga de trabajo entre estos y las solicitudes de búsqueda de un
archivo entre los usuarios
usu
de la red estarán más equilibradas.
Para poder desarrollar el principal objetivo del proyecto, es necesario que los
servidores compartan la misma información acerca de los archivos y de los clientes que
se encuentren conectados a la red P2P. Dado el gran número de clientes de este tipo
de redes, es inviable que un servidor albergue toda ésta información, ya que manejaría
una gran volumen de datos que además estaría duplicado en el resto de servidores.
Por este motivo, la arquitectura propuesta se basa
basa en la conexión de todos los
servidores a una red IP multicast, para así poder distribuir la información por medio de
mensajes sin la necesidad de almacenarla en la base de datos de cada uno de ellos.
Figura 15. Arquitectura propuesta
40
Capítulo 4
Análisis del
Sistema
Diseño e implementación de un protocolo peer-to-peer
4.1 IDENTIFICACIÓN DE NECESIDADES
4.1.1 ALCANCE DEL SISTEMA
El objetivo del proyecto es el diseño e implementación de un protocolo P2P, que
mejore el proceso de búsqueda de los archivos entre los usuarios que se encuentren
conectados a la red, ya que, como se detalló en el capítulo anterior, en los actuales
clientes de búsqueda y transferencia P2P, el proceso de búsqueda de archivos y su
posterior transferencia están condicionados al servidor al que se encuentre conectado
el cliente.
Para poder mejorar el proceso de búsqueda, es necesario eliminar la
dependencia de los clientes al servidor que se encuentren conectados, haciendo
obligatorio que los servidores compartan la misma información acerca de los archivos
y de los clientes que se encuentren conectados a la red P2P. Dado el gran número de
clientes de este tipo de redes, es inviable que un servidor albergue toda ésta
información, ya que manejaría una gran volumen de datos que además estaría
duplicado en el resto de servidores. Por este motivo, la arquitectura propuesta se basa
en la conexión de todos los servidores a una red IP multicast, para así poder distribuir
la información por medio de mensajes sin la necesidad de almacenarla en la base de
datos de cada uno de ellos.
Figura 16. Red IP multicast
42
Diseño e implementación de un protocolo peer-to-peer
Cuando un cliente de la red P2P desea realizar una búsqueda de un determinado
archivo, envía una solicitud de búsqueda al servidor al que se encuentra conectado. El
servidor procesa la solicitud, realizando una consulta en su base de datos, en la que
están registrados todos los archivos de los clientes con los que mantiene una conexión.
Al finalizar la consulta, transmite la solicitud de búsqueda del cliente a la red IP
multicast para que todos los servidores, que se encuentran conectados a esta red,
reciban dicha solicitud y consulten en sus bases de datos, al igual que hizo el primer
servidor, para obtener los resultados que satisfacen la petición. Una vez consultada la
base de datos, se envían los resultados al servidor que los solicitó para añadir esos
resultados a los que ya tenía. Una vez terminado este proceso, todos los resultados se
envían al cliente que inició el proceso de búsqueda.
El proceso anteriormente explicado, se realiza tanto para las búsquedas de
archivos, para las búsquedas de comentarios de los archivos que comparten los
clientes, como para las búsquedas de los clientes que tienen el archivo que el usuario
desea descargarse.
4.1.2 TOPOLOGÍA DE USUARIOS FINALES
Hay que distinguir entre dos tipos de usuarios claramente definidos por su uso
de la aplicación diseñada.
Por una parte se encuentran los administradores de los servidores de la red,
personas con conocimientos de la aplicación, conocimientos de bases de datos y con
derechos a acceso a esta para realizar los procesos de control y mantenimiento que
crean adecuados. Además este tipo de usuario será el encargado de establecer una
política, y mantener su cumplimiento, con respecto al tipo de archivos que maneje el
servidor que se encuentra a su cargo.
Por otro lado, se encuentran los usuarios de la aplicación cliente, la cual es
utilizada para buscar y transferir archivos con otros usuarios de la red.
43
Diseño e implementación de un protocolo peer-to-peer
4.1.3 RESTRICCIONES
No existe ningún tipo de restricción de tipo económica, ya que estas no son
considerables en el desarrollo del proyecto.
Sin embargo, sí existen restricciones de carácter temporal, ya que el proyecto ha
de ser presentado en Junio del 2009, la planificación de este está condicionada a esta
fecha.
Con respecto a restricciones tecnológicas, dado que el lenguaje a utilizado para
la implementación del protocolo ha sido Java, las máquinas en las que se ejecute tanto
el cliente como el servidor, han de tener instaladas una implementación de la Máquina
Virtual Java. Con respecto al sistema operativo, al haber elegido un lenguaje
multiplataforma, no existe ninguna restricción en lo referente al entorno de ejecución
de la aplicación.
4.2 ANÁLISIS DE REQUISITOS
4.2.1 CONTEXTO GENERAL DEL SISTEMA
Este contexto general del sistema está representado mediante un diagrama de
presentación, con símbolos y figuras, donde se muestra la iteración del sistema con el
cliente, y las relaciones entre ambos.
Figura 17. Contexto general del sistema
En el diagrama anterior se ha presentado el proceso de una solicitud de un
cliente. Como ya se detalló anteriormente, cuando un cliente de la red P2P desea
44
Diseño e implementación de un protocolo peer-to-peer
realizar una búsqueda, envía una solicitud al servidor al que se encuentra conectado. El
servidor procesa la solicitud, consultando en su base de datos, en la que están
registrados todos los archivos de los clientes con los que mantiene una conexión. Al
finalizar la consulta, transmite la solicitud del cliente a la red IP multicast para que
todos los servidores, que se encuentran conectados a esta red, la reciban y consulten
en sus bases de datos, al igual que lo hizo el primer servidor, para obtener de esta
forma más resultados que satisfacen la petición. Una vez consultada la base de datos,
envían los resultados al servidor que los solicitó para añadir esos resultados a los que
ya tenía. Una vez terminado este proceso, todos los resultados se envían al cliente que
inició el proceso de búsqueda.
El proceso anterior, se realiza tanto para las búsquedas de archivos, como para
las búsquedas de comentarios de los archivos que comparten los clientes, como para
las búsquedas de los clientes que tienen el archivo que el usuario desea descargarse.
Después de que el cliente obtenga los resultados de los clientes que tienen un
determinado archivo disponible para su transferencia, éste realiza una conexión con
cada uno de ellos para obtener las partes del archivo que necesite.
Figura 18. Conexiones entre clientes de la red
45
Diseño e implementación de un protocolo peer-to-peer
4.2.2 ÁMBITO DEL SISTEMA
Partiendo de los objetivos señalados en el anterior capítulo, se definen a
continuación, las entidades principales del proyecto.
Hermes. Es la aplicación cliente que ejecuta el usuario para la búsqueda y
posterior transferencia de archivos. Mantiene conexiones con otros pares de
la red para la transferencia de archivos, ya sea porque los haya solicitado este
u otro par.
Servidor. Es la entidad a la los clientes que se encuentran conectados para
solicitar determinados servicios, ya sean de búsqueda de archivos,
comentarios o clientes que ofrecen un determinado archivo. Además
mantiene un conexión con la red IP multicast para enviar la solicitud del
cliente al resto de los servidores que se encuentran conectados a la red.
Delphic. Es la base de datos en la cual se encuentran registrados los usuarios
conectados a la red y los archivos que comparten, así sus comentarios. Es
consultada por la aplicación servidora para satisfacer las peticiones de los
clientes.
4.2.3 ÁMBITO DEL CLIENTE
Partiendo de los objetivos señalados en el capítulo anterior, los requisitos
identificados en la aplicación cliente, son lo que se muestran a continuación.
Eliminación de lista de servidores. Con la finalidad de eliminar el
mantenimiento de la lista de servidores por parte del cliente, y la elección de
sus favoritos, este recibirá la información necesaria acerca de los servidores
que se encuentran conectados a la red, para su agregación automática en la
lista de servidores.
Limitación de búsquedas. Con el fin de que los resultados de las búsquedas se
ciñan más a los requisitos del usuario, este podrá introducir el tipo de archivo
a buscar, obteniendo de esta forma un conjunto de resultados más limitado a
las necesidades del cliente.
46
Diseño e implementación de un protocolo peer-to-peer
Transferencias simultáneas. Para poder reducir el tiempo de las
transferencias, los clientes mantendrán distintas conexiones entre los pares
de la red para así poder mantener transferencias paralelas, tanto de subida de
un archivo como de descarga.
Control de errores de conexión. Con el objetivo de controlar los posibles
errores de las conexiones entre clientes, si ocurriese alguna desconexión
imprevista de alguno de estos, el resto de los clientes mantendrán la conexión
con los clientes a los que se encuentran conectados, sin afectar a las
comunicaciones ni a los datos transferidos.
Incremento paulatino del tamaño del fichero temporal. Con el fin de realizar
una correcta gestión del espacio del disco duro del usuario, el tamaño del
archivo temporal asociado a una descarga, se incrementará a medida que la
descarga avanza y no se establecerá al tamaño del archivo original, como
sucede en los actuales clientes.
Previsualización de los archivos. Con la finalidad de eliminar los archivos
corruptos, los clientes podrán reproducir los archivos multimedia que se
encuentran descargando sin la necesidad de que estos estén completamente
descargados. Será requisito indispensable en este caso, que el cliente
disponga de la una aplicación instalada en su equipo que permita la
reproducción de archivos multimedia.
Para el desarrollo del cliente se ha elegido una arquitectura de tres capas, con el
objetivo de reducir las dependencias y mantener acotado el impacto de los cambios.
Los elementos agrupados en una misma capa pueden comunicarse entre sí. Cada capa
presta sus servicios a la capa superior y depende de los servicios prestados por la
inferior.
Esta descomposición separa los diferentes módulos de los que consta la
aplicación, proporcionando transparencia para modificar el sistema. Cada subsistema
engloba una funcionalidad diferente de la aplicación. La independencia entre los
subsistemas identificados permite realizar modificaciones sobre cualquier capa sin
afectar a la interfaz del resto de componentes.
47
Diseño e implementación de un protocolo peer-to-peer
Las capas identificadas en el ámbito del cliente son las que se muestran a
continuación.
Figura 19. Capas de la aplicación cliente
GUI. Es la capa más cercana al usuario. Recoge la interfaz gráfica que este
utilizará para interactuar con el sistema y redirige sus peticiones a la capa de
lógica.
Lógica. Recoge toda la lógica del cliente, necesaria para la gestión de los
archivos locales, las transferencias de archivos en la red y las solicitudes de
servicios a la capa de comunicaciones.
Comunicaciones. Recoge la implementación del protocolo desarrollado, y las
comunicaciones tanto con el servidor al que el usuario se encuentra
conectado, como las comunicaciones con el resto de los clientes para la
transferencia de archivos.
4.2.4 ÁMBITO DEL SERVIDOR
Partiendo de los objetivos señalados en el capítulo anterior, los requisitos
identificados en la aplicación servidor, son lo que se muestran a continuación.
Comunicación entre servidores. Con la finalidad de que las búsquedas sean
independientes del servidor al que se esté conectado, los servidores
distribuirán una lista en la que estén registrados los usuarios conectados a la
red y los archivos que comparten, así como sus comentarios.
Gestión de comentarios. Para otorgar una mayor información a los clientes
con respecto a los archivos que se descargan, los servidores de la red
gestionarán los comentarios de los usuarios con el fin de que éstos puedan
solicitar esta información como si se tratase de un recurso más de la red.
48
Diseño e implementación de un protocolo peer-to-peer
Gestión de errores. Para conseguir un mantenimiento correctivo del sistema,
los posibles errores que sucedan en el servidor, tras una solicitud de un
cliente, se registrarán en un archivo log.
Para el desarrollo del servidor se ha elegido, al igual que el cliente, una
arquitectura de tres capas, con el objetivo de reducir las dependencias y mantener
acotado el impacto de los cambios.
Las capas identificadas en el ámbito del servidor son las que se muestran a
continuación.
Figura 20. Capas de la aplicación servidor
Comunicaciones. Recoge la implementación del protocolo desarrollado, y las
comunicaciones tanto con el resto de los servidores de la red IP multicast,
como las comunicaciones con los clientes que se encuentran conectados a él.
Lógica. Recoge toda la lógica del servidor, necesaria para la gestión las
solicitudes de los clientes y las solicitudes de servicios a la capa de acceso a la
base de datos, DAO.
DAO. Esta capa utiliza objetos DAO (Data Access Object) para abstraer y
encapsular todo el acceso a la información contenida en la base de datos. Este
conjunto de objetos gestiona la conectividad con la base de datos,
exponiendo una interfaz más simple, actuando como adaptadores entre el
componente de la lógica y la base de datos.
4.2.5 DECISIONES DE DISEÑO
El lenguaje de programación Java proporciona dos clases para la implementación
de sockets. Estas clases son Socket y DatagramSocket. La principal diferencia entre
49
Diseño e implementación de un protocolo peer-to-peer
estas dos clases está en el uso del protocolo de transporte, mientras Socket hace uso
del protocolo TCP (Transmission Control Protocol), DatagramSocket hace uso de UDP.
TCP proporciona una cantidad considerablemente mayor de servicios a las
aplicaciones que UDP, ya que se trata de un protocolo orientado a conexión, a
diferencia de UDP.
Las principales características de este protocolo son las que se detallan a
continuación [GARC05].
Control de flujo. Mediante el uso de ventanas de envío y la identificación de
paquetes transmitidos, se proporciona un modo para que dos sistemas
cooperen activamente en la transmisión de paquetes para evitar exceso de
flujo y pérdida de paquetes y adaptarse a la congestión de la red.
Detección y corrección de errores. Mediante una utilidad de código de
paridad,
checksum21,
números
de
secuencia,
confirmaciones
y
temporizadores de retransmisión se asegura la integridad de los paquetes,
dando lugar a que no existan rechazos. La retransmisión de los paquetes
corrompidos o perdidos se puede manejar de una manera oportuna y
eficiente.
Reconocimiento del paquete recibido. El envío de un acknowledgement22 por
parte del emisor, permite al emisor saber que el receptor ha recibido los
paquetes. Si los paquetes no son notificados, el transmisor puede reenviar los
paquetes.
Como contrapartida, el protocolo TCP, al precisar de fases de establecimiento de
la conexión y liberación, conlleva muchos más controles que el protocolo UDP,
llegando a aumentar el tiempo de procesamiento considerablemente.
21
El término checksum se refiere a una forma de control de redundancia empleada en comunicaciones y
en almacenamiento de datos que consiste en el almacenamiento de la suma de bytes para su posterior
comparación.
22
El término acknowledgement se refiere a un mensaje enviado por el receptor al emisor indicando bien
que éste está listo para recibir una transmisión o que una transmisión fue recibida sin error.
50
Diseño e implementación de un protocolo peer-to-peer
A pesar del inconveniente anterior, se ha implementado la comunicación entre
cliente y servidor y entre clientes haciendo uso de la clase Socket, y por consiguiente
del protocolo TCP, ya que se ha considerado que las características que aporta este
protocolo son más significativas que el inconveniente de su uso.
Ya que la arquitectura propuesta entre los servidores de la red P2P es una
arquitectura basada en una red IP multicast, se ha hecho uso de la única clase que
proporciona el lenguaje de programación Java para la implementación de conexiones a
este tipo de redes. Esta clase es MulticastSocket, y es un caso particular de la clase
DatagramSocket con capacidades adicionales para la conexión a grupos de redes IP
multicast [MICRO04]. Por este motivo el uso de UDP como protocolo de transporte en
las comunicaciones de los servidores conectados a la red IP multicast ha sido
establecida por el lenguaje de programación utilizado.
Para la identificación de los archivos que los clientes ponen a disposición de la
red P2P, ha sido necesario el uso de un sistema de funciones hash criptográficas para
asegurar que la identificación se realiza de forma unívoca.
Actualmente existen varios algoritmos hash, entre los que se encuentra SHA1.
Este algoritmo procesa la información de un archivo en bloques de 512 bits y produce
un valor de 160 bits, lo que le otorga una mayor seguridad que algoritmos que
produces valores hash de 128 bits, como es el caso de RIPEMD23 (RACE Integrity
Primitives Evaluation Message Digest). Además, hasta hoy día, no se han registrado
ataques contra este algoritmo, comprometiendo su resistencia, como sí sucede con
otros como MD5. En el año 2005, Xiaoyun Wang y Hongbo Yu de la Universidad
Shandong, China, publicaron un artículo en el cual se describía la forma de encontrar
dos secuencias diferentes de 128 bits con el mismo valor hash MD5 [WANG04].
Los hechos anteriormente detallados han sido los motivos de elección del
algoritmo SHA1 como función hash para el cálculo de identificadores de los archivos de
la red P2P.
23
El término RIPEMD se refiere a un algoritmo de función hash diseñado por Hans Dobbertin, Antoon
Bosselaers y Bart Preneel para el uso en comprobaciones de integridad de mensajes que produce un
identificador de un archivo de 128 bits.
51
Diseño e implementación de un protocolo peer-to-peer
4.3 METODOLOGÍA
Para la realización del proyecto se ha aplicado la metodología UML (Unified
Modeling Language) en su versión 2.0, ya que se utiliza un lenguaje que permite de
forma gráfica visualizar, especificar, construir y documentar un sistema [OMG09].
Además, ofrece un estándar para describir el modelo de un sistema, incluyendo
aspectos conceptuales como reglas de negocio y funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programación, modelos de bases de
datos y componentes reutilizables.
4.3.1 DIAGRAMA DE DOMINIO
Un diagrama de dominio muestra los conceptos básicos del dominio, sus
propiedades más importantes y las relaciones entre dichos conceptos.
El diagrama de dominio del sistema es el que se muestra a continuación.
52
Diseño e implementación de un protocolo peer-to-peer
Figura 21. Diagrama de dominio del sistema
53
Diseño e implementación de un protocolo peer-to-peer
4.3.2 DIAGRAMA DE CASOS DE USO
Un diagrama de casos de uso muestra la relación entre los actores y los casos de
uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere
a su interacción externa.
El diagrama de casos de uso para el usuario de la aplicación cliente es el que se
muestra a continuación.
Conectar a la red
P2P
Buscar archivos en
la red P2P
Buscar comentarios
de un archivo
Eliminar resultados
de una búsqueda
Descargar archivo
de la red P2P
Previsualizar
archivo
Usuario
Añadir comentario
a un archivo
Ver comentarios de
un archivo local
Eliminar comentario
de un archivo local
Recargar archivos
locales
Figura 22. Diagrama de casos de uso del usuario de la aplicación cliente
54
Diseño e implementación de un protocolo peer-to-peer
Seguidamente, se detalla cada uno de los casos de uso descritos en el diagrama
anterior.
CASOS DE USO.
- Conectar a la red P2P. Conexión a la red P2P para poder comenzar con la
búsqueda de archivos o continuar con las transferencias pendientes.
- Buscar archivos en la red P2P. Búsqueda de archivos en la red P2P
introduciendo el nombre del archivo o parte de él, con la posibilidad de
limitación de la búsqueda, seleccionando el tipo de archivo a buscar.
- Buscar comentarios de un archivo. Una vez obtenidos los resultados de
una búsqueda, búsqueda de los comentarios con los que otros usuarios
han calificado un determinado archivo.
- Eliminar resultado de una búsqueda. Eliminación de los resultados de una
búsqueda en caso de que estos no sean satisfactorios para el usuario o por
cualquier motivo no sean necesarios.
- Descargar un archivo de la red P2P. Descarga de un archivo seleccionado
de entre los resultados de una búsqueda o descarga de los archivos
pendientes.
- Previsualizar archivo. Previsualización de un archivo en estado de
descarga, una vez iniciada esta y con al menos el primer trozo del archivo
descargado (RN01).
- Añadir comentario. Insertar la evaluación de un archivo y su comentario
de un archivo descargado o en estado de descarga.
- Ver comentarios de un archivo local. Visualización de los comentarios de
los archivos que el usuario pone a disposición del resto de usuarios de la
red P2P.
- Eliminar comentario de un archivo local. Eliminación, por cualquier motivo
que considere el usuario, de un comentario de un archivo local.
- Recargar archivos locales. Recarga de los archivos locales y sincronización
con el servidor al que el usuario se encuentra conectado, por si el usuario
ha eliminado un archivo o introducido uno nuevo.
55
Diseño e implementación de un protocolo peer-to-peer
REGLAS DE NEGOCIO.
- RN01. Prioridad de partes de un archivo. Con la finalidad de que el archivo
pueda ser previsualizado, es necesario que la primera parte, y en algunos
casos la última, esté completamente descargada. Por este motivo, esta
primera parte tendrá mayor prioridad, seguida de la última y a
continuación del resto.
4.3.3 DIAGRAMA DE PAQUETES
Los diagramas de paquetes reflejan la organización de los subsistemas en que se
descompone el sistema y las dependencias entre ellos. Representa una visión
fundamental para el control de alto nivel de un sistema.
El diagrama de paquetes es el que se muestra a continuación.
Figura 23. Diagrama de paquetes
A continuación se detalla cada uno de los paquetes que aparecen en el diagrama
anterior.
Paquete gui. Contiene la interfaz gráfica del usuario y gestiona las acciones de
este sobre cada una de sus componentes.
56
Diseño e implementación de un protocolo peer-to-peer
Paquete client. Contiene toda la lógica del cliente en clases denominadas
gestores, como son los gestores de transferencias, comentarios, archivos
locales y demás.
Paquete constants. Contiene la definición de las constantes usadas por la
aplicación, como definición de directorios, ficheros necesarios para la
ejecución y tipos de datagramas y paquetes.
Paquete útil. Contiene las definiciones de los conceptos del dominio del
sistema.
Paquete packets. Contiene la definición de los paquetes que se transmiten en
la comunicación del cliente con el servidor y el cliente con el resto de los
clientes de la red P2P.
Paquete data. Contiene la información de los datagramas que se transmiten
en la comunicación entre los servidores de las red IP multicast.
Paquete server. Contiene toda la lógica del servidor para el servicio de
solicitudes y la gestión del fichero de control de errores.
Paquete dao. Contiene la abstracción del acceso a la base de datos por parte
del servidor.
57
Diseño e implementación de un protocolo peer-to-peer
4.3.4 DIAGRAMA DE CLASES
A continuación se detallan cada una de las clases de cada unos de los paquetes
anteriores.
Las clases del paquete gui son las que se muestran a continuación.
Figura 24. Clases del paquete gui
58
Diseño e implementación de un protocolo peer-to-peer
Las clases del paquete client son las que se muestran a continuación.
Figura 25. Clases del paquete client
59
Diseño e implementación de un protocolo peer-to-peer
Las clases del paquete constants son las que se muestran a continuación.
Figura 26. Clases del paquete constants
60
Diseño e implementación de un protocolo peer-to-peer
Las clases del paquete util son las que se muestran a continuación.
Figura 27. Clases del paquete util
61
Diseño e implementación de un protocolo peer-to-peer
Las clases del paquete packets son las que se muestran a continuación.
Figura 28. Clases del paquete packets
62
Diseño e implementación de un protocolo peer-to-peer
Las clases del paquete data son las que se muestran a continuación.
Figura 29. Clases del paquete data
63
Diseño e implementación de un protocolo peer-to-peer
Las clases del paquete server son las que se muestran a continuación.
Figura 30. Clases del paquete server
64
Diseño e implementación de un protocolo peer-to-peer
Las clases del paquete dao son las que se muestran a continuación.
Figura 31. Clases del paquete dao
4.3.5 DISEÑO DE LA BASE DE DATOS
A continuación se detallan las tablas y relaciones que componen la base de datos
de la aplicación.
TABLA EXTENSIONS.
- Descripción: contiene las extensiones de los archivos.
- Relación con: ninguna tabla.
-
Sentencia de creación: CREATE TABLE DELPHIC.EXTENSIONS(
EXTENSION VARCHAR(6) NOT NULL,
TYPE VARCHAR(8) NOT NULL,
PRIMARY KEY(EXTENSION)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
65
Diseño e implementación de un protocolo peer-to-peer
EXTENSIONS
PK
EXTENSION: varchar(6)
TYPE: varchar(8)
TABLA SHARES.
- Descripción: contiene los archivos de los usuarios conectados a la red.
- Relación con: ninguna tabla.
-
Sentencia de creación: CREATE TABLE DELPHIC.SHARES(
NAME VARCHAR(256) NOT NULL,
SIZE BIGINT NOT NULL,
HASH CHAR(40) NOT NULL,
EXTENSION VARCHAR(6) NOT NULL,
COUNTER INT NOT NULL DEFAULT 0,
PRIMARY KEY(NAME,HASH)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
TABLA CLIENTS.
- Descripción: contiene la información de los clientes conectados a la red.
- Relación con: COMMENTS.
- Sentencia de creación: CREATE TABLE DELPHIC.CLIENTS(
IP VARCHAR(15) NOT NULL,
HASH CHAR(40) NOT NULL,
NAME VARCHAR(256) NOT NULL,
PRIMARY KEY(IP,HASH)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
66
Diseño e implementación de un protocolo peer-to-peer
TABLA COMMENTS.
- Descripción: contiene los comentarios de los usuarios conectados a la red.
- Relación con: CLIENTS.
-
Sentencia de creación: CREATE TABLE DELPHIC.COMMENTS(
NCOMMENT INT NOT NULL AUTO_INCREMENT,
CLIENTIP VARCHAR(15) NOT NULL,
HASH CHAR(40) NOT NULL,
COMMENT VARCHAR(120),
EVALUATION TINYINT,
PRIMARY KEY(NCOMMENT),
INDEX (CLIENTIP,HASH),
FOREIGN KEY(CLIENTIP,HASH) REFERENCES
DELPHIC.CLIENTS(IP,HASH) ON DELETE
CASCADE)ENGINE=INNODB DEFAULT
CHARSET=latin1;
COMMENTS
PK
NCOMMENT: int
FK1,I1
FK1,I1
CLIENTIP: varchar(15)
HASH: char(40)
COMMENT: varchar(120)
EVALUATION: tinyint
67
Capítulo 5
Protocolo del
Sistema
Diseño e implementación de un protocolo peer-to-peer
5.1 PROTOCOLO ENTRE CLIENTE Y SERVIDOR
5.1.1 SOLICITUD DE CONEXIÓN A LA RED PEER-TO-PEER
Cuando un cliente se conecta la red P2P, se envía un paquete a la dirección IP del
servidor para que se contemple la nueva agregación de este cliente, registrando en la
base de datos la dirección del cliente, los archivos que comparte y sus comentarios. El
servidor acredita al nuevo cliente con el correspondiente paquete de contestación.
Figura 32. Solicitud de conexión a la red P2P
PAQUETE REQUEST_CONNECT.
- Implementado por la clase: ConnectPacket.
- Datos. La dirección IP del cliente y los archivos que pone a disposición
de la red P2P.
PAQUETE REPLY_ CONNECT.
- Implementado por la clase: StandardPacket.
- Datos. Sin datos. El tipo de paquete transmitido es la propia
confirmación del protocolo.
5.1.2 SOLICITUD DE BÚSQUEDA DE ARCHIVOS
Cuando un cliente solicita una búsqueda de archivos, se envía un paquete a la
dirección IP del servidor al que se encuentra conectado para que consulte su base de
datos. El servidor contesta con los resultados que satisfacen los requisitos de búsqueda
del archivo, tanto los suyos como los que provienen de la red IP multicast.
Figura 33. Solicitud de búsqueda de archivos
69
Diseño e implementación de un protocolo peer-to-peer
PAQUETE REQUEST_SEARCH.
- Implementado por la clase: RequestSearchPacket.
- Datos. La secuencia de la cadena de búsqueda y el tipo de archivo a
buscar.
PAQUETE REPLY_SEARCH.
- Implementado por la clase: ReplySearchPacket.
- Datos. Los archivos que satisfacen los requisitos de búsqueda.
5.1.3 SOLICITUD DE BÚSQUEDA DE COMENTARIOS
Cuando un cliente solicita una búsqueda de comentarios de un archivo
determinado, se envía un paquete a la dirección IP del servidor al que se encuentra
conectado para que consulte su base de datos. El servidor contesta con los resultados
que satisfacen los requisitos de búsqueda de la solicitud, tanto los suyos como los que
provienen de la red IP multicast.
Figura 34. Solicitud de búsqueda de comentarios
PAQUETE REQUEST_COMMENTS.
- Implementado por la clase: RequestCommentsPacket.
- Datos. El valor de la función hash que identifica un archivo en la red
P2P.
PAQUETE REPLY_ COMMENTS.
- Implementado por la clase: ReplyCommentsPacket.
- Datos. Los comentarios que satisfacen los requisitos de búsqueda.
5.1.4 SOLICITUD DE BÚSQUEDA DE CLIENTES
Cuando un cliente solicita una búsqueda de otros clientes que tienen disponible
un archivo determinado para su transferencia, se envía un paquete a la dirección IP del
servidor al que se encuentra conectado para que consulte su base de datos. El servidor
70
Diseño e implementación de un protocolo peer-to-peer
contesta con las direcciones IP de los clientes que satisfacen los requisitos de
búsqueda de la solicitud, tanto las que tiene registradas en sus base de datos como las
que provienen de la red IP multicast.
Figura 35. Solicitud de búsqueda de comentarios
PAQUETE REQUEST_COMMENTS.
- Implementado por la clase: RequestIPsPacket.
- Datos. El valor de la función hash que identifica un archivo en la red
P2P.
PAQUETE REPLY_ COMMENTS.
- Implementado por la clase: ReplyIPsPacket.
- Datos. Las direcciones IP de los clientes que tienen disponible un
archivo determinado para su transferencia.
5.1.5 SOLICITUD DE SINCRONIZACIÓN
Cuando un cliente ha terminado de descargar completamente un archivo de la
red P2P, se envía un paquete a la dirección IP del servidor al que se encuentra
conectado para que añada a la disponibilidad del archivo a este cliente.
Figura 36. Solicitud de sincronización de archivos
PAQUETE REQUEST_SYNCHRONIZE.
- Implementado por la clase: SynchronizePacket.
- Datos. El archivo descargado del cliente.
71
Diseño e implementación de un protocolo peer-to-peer
5.1.6 SOLICITUD DE DESCONEXIÓN DE LA RED PEER-TO-PEER
Cuando un cliente se desconecta la red P2P, se envía un paquete a la dirección IP
del servidor para que se contemple la desconexión de este cliente, eliminando los
registros de la base de datos, los archivos que comparte y sus comentarios. El servidor
acredita la desconexión con el correspondiente paquete de contestación.
Figura 37. Solicitud de desconexión a la red P2P
PAQUETE REQUEST_COMMENTS.
- Implementado por la clase: StandardPacket.
- Datos. La dirección IP del cliente que se desconecta de la red P2P.
PAQUETE REPLY_ COMMENTS.
- Implementado por la clase: StandardPacket.
- Datos. Sin datos. El tipo de paquete transmitido es la propia
confirmación del protocolo.
5.2 PROTOCOLO ENTRE SERVIDORES
5.2.1 SOLICITUD DE CONEXIÓN A LA RED MULTICAST
Cuando un servidor se conecta la red IP multicast, se envía un datagrama a la
dirección de esta red para que el resto de los servidores contemplen la nueva
agregación del servidor. El resto de los servidores conectados a la red IP multicast,
acreditan a este nuevo servidor con el correspondiente datagrama de contestación.
Figura 38. Solicitud de conexión a la red IP multicast
72
Diseño e implementación de un protocolo peer-to-peer
DATAGRAMA REQUEST_JOIN.
- Implementado por la clase: RequestJoinData.
- Datos. La dirección IP y el puerto asignado a la red IP multicast del
servidor que solicita la conexión.
DATAGRAMA REPLY_JOIN.
- Implementado por la clase: ReplyJoinData.
- Datos. La dirección IP y el puerto asignado a la red IP multicast del
servidor que contesta a la solicitud de conexión.
5.2.2 SOLICITUD DE BÚSQUEDA DE ARCHIVOS
Cuando un servidor solicita una búsqueda de archivos, se envía un datagrama a
la dirección de la red IP multicast para que el resto de los servidores consulten sus
bases de datos. El resto de los servidores contestan con los resultados que satisfacen
los requisitos de búsqueda del archivo.
Figura 39. Solicitud de búsqueda de archivos a la red IP multicast
DATAGRAMA REQUEST_SEARCH.
- Implementado por la clase: RequestSearchData.
- Datos. La secuencia de la cadena de búsqueda y el tipo de archivo a
buscar.
DATAGRAMA REPLY_ SEARCH.
- Implementado por la clase: ReplySearchData.
- Datos. Los archivos que satisfacen los requisitos de búsqueda.
5.2.3 SOLICITUD DE BÚSQUEDA DE COMENTARIOS
Cuando un servidor solicita una búsqueda de comentarios de un archivo
determinado, se envía un datagrama a la dirección de la red IP multicast para que el
73
Diseño e implementación de un protocolo peer-to-peer
resto de los servidores consulten sus bases de datos. El resto de los servidores
contestan con los resultados que satisfacen los requisitos de búsqueda de la solicitud.
Figura 40. Solicitud de búsqueda de comentarios a la red IP multicast
DATAGRAMA REQUEST_SEARCH.
- Implementado por la clase: RequestCommentsData.
- Datos. El valor de la función hash que identifica un archivo en la red.
DATAGRAMA REPLY_ SEARCH.
- Implementado por la clase: ReplyCommentsData.
- Datos. Los comentarios que satisfacen los requisitos de búsqueda.
5.2.4 SOLICITUD DE BÚSQUEDA DE CLIENTES
Cuando un servidor solicita una búsqueda de clientes que tienen disponible un
archivo determinado para su transferencia, se envía un datagrama a la dirección de la
red IP multicast para que el resto de los servidores consulten sus bases de datos. El
resto de los servidores contestan con las direcciones IP de los clientes que satisfacen
los requisitos de búsqueda de la solicitud.
Figura 41. Solicitud de búsqueda de direcciones IP a la red IP multicast
DATAGRAMA REQUEST_IPS.
- Implementado por la clase: RequestIPsData.
- Datos. El valor de la función hash que identifica un archivo en la red.
74
Diseño e implementación de un protocolo peer-to-peer
DATAGRAMA REPLY_ IPS.
- Implementado por la clase: ReplyIPsData.
- Datos. Las direcciones IP de los clientes que tienen disponible un
archivo determinado para su transferencia.
5.3 PROTOCOLO ENTRE CLIENTES
Cuando un cliente se conecta a otro par de la red P2P al que ha solicitado la
descarga de un determinado archivo, su petición es insertada en la cola de descargas
del cliente que sirve, para su posterior procesamiento. Cuando esta solicitud es
atendida, el cliente que sirve el archivo envía un mensaje al cliente que solicita para
que le indique el identificador de la parte del archivo que necesita.
Figura 42. Solicitud de transferencia de un parte del archivo
PAQUETE START.
- Implementado por la clase: StandardPacket.
- Datos. Sin datos. El tipo de paquete transmitido es la propia
sincronización del protocolo.
PAQUETE CHUNK_1.
- Implementado por la clase: ChunkPacket.
- Datos. El identificador de la parte del archivo.
PAQUETE CHUNK_2.
- Implementado por la clase: ChunkPacket.
Datos. El identificador de la parte del archivo y los datos de esa parte.
Posteriormente, el cliente que recibe la parte del archivo solicitado, indica
inmediatamente después al cliente que se la ha servido que la transferencia a de
finalizarse, porque ya tiene el archivo completo, o bien a de continuar. Este mensaje es
75
Diseño e implementación de un protocolo peer-to-peer
necesario para que el cliente que sirve el archivo elimine o vuelva a insertar la petición
en la cola de descargas.
Figura 43. Sincronización de transferencia de un parte del archivo
PAQUETE CONTINUE.
- Implementado por la clase: StandardPacket.
- Datos. Sin datos. El tipo de paquete transmitido es la propia
sincronización del protocolo.
PAQUETE END.
- Implementado por la clase: StandardPacket.
- Datos. Sin datos. El tipo de paquete transmitido es la propia
sincronización del protocolo.
76
Capítulo 6
Programación y
Pruebas del
Sistema
Diseño e implementación de un protocolo peer-to-peer
6.1 PROGRAMACIÓN
6.1.1 INTRODUCCIÓN
El objetivo de esta etapa es alcanzar la transformación del sistema en un
conjunto de programas que puedan ser ejecutados correctamente bajo los criterios de
calidad definidos. La dificultad radica en la manera de realizar esta transformación de
la mejor forma posible, ya que dependen de factores como el lenguaje de
programación y las herramientas y utilidades software utilizadas.
Esta etapa recoge los detalles de la programación empleada para realizar la
aplicación con explicaciones de los lenguajes utilizados en todos los componentes.
6.1.2 LENGUAJES DE PROGRAMACIÓN
Para la implementación del protocolo se ha utilizado Java como lenguaje de
programación, puesto que el proyecto tiene características de un sistema distribuido,
y este ha de ser independiente tanto del hardware como del sistema operativo en el
que se ejecute. Además la arquitectura planteada se ajusta muy bien a las
características del lenguaje de programación anteriormente mencionadas.
Para la implementación de la base de datos de los servidores se ha utilizado el
sistema gestor de bases de datos relacionales MySQL, unos de los más utilizados, ya
que las características de este sistema gestor, detalladas anteriormente, se ajustan a
los requisitos del proyecto, tales como multi-thread, rapidez y fiabilidad. Además
MySQL está bajo licencia GPL, un valor añadido al producto final que hoy en día es
bastante valorado en algunos proyectos.
6.1.3 MANUAL DE USUARIO
En esta etapa es donde, por último, se ha procedido a la realización del manual
de usuario, incluido en el anexo I para el cliente y en el anexo II para el servidor. La
realización de estos manuales está orientada a las funciones que puede realizar el
usuario sobre cada uno de los controles del sistema, ya que dependerá del uso que se
haga del mismo y de la determinación del usuario de cómo utilizarlo.
78
Diseño e implementación de un protocolo peer-to-peer
6.2 PRUEBAS DEL SISTEMA
Después de haber desarrollado cada una de las clases que componen el dominio
de la aplicación, es necesario realizar una serie de pruebas para conseguir una correcta
integración y funcionamiento de esta. El objetivo global de esta fase es someter a
todas las componentes de la aplicación a una serie de planes de prueba y
verificaciones encaminadas a garantizar el nivel de fiabilidad exigido.
En esta fase se recogen las distintas pruebas a las que puede someterse el
software, desde las pruebas de encadenamiento entre los distintos componentes,
hasta las pruebas de sobrecarga para diagnóstico del rendimiento del sistema ante
situaciones límites. A continuación se detalla las distintas pruebas a las que se ha
sometido todas las componentes sistema:
Pruebas de encadenamiento. Aseguran y verifican las llamadas entre los
distintos componentes de la aplicación.
Pruebas de integración. Verifican la funcionalidad de toda la aplicación y el
rendimiento de los recursos utilizados.
Pruebas de explotación del sistema. Confirman la correcta operación de la
totalidad del sistema.
Pruebas de sobrecarga. Comprueban el correcto funcionamiento y
comportamiento de la aplicación ante los estados de sobrecarga en los que se
puede ver envuelto.
Pruebas de recuperación. Verifica la capacidad de la aplicación para recuperar
la información ante posibles errores de ejecución.
Pruebas de seguridad. Verifican los aspectos de seguridad exigidos en los
requisitos del sistema.
Pruebas de usabilidad. Aseguran la accesibilidad de la aplicación por parte de
los usuarios finales.
Pruebas de aceptación del usuario. Certifican por parte de los usuarios finales
la funcionalidad y rendimiento de la aplicación de acuerdo con los requisitos
establecidos.
79
Diseño e implementación de un protocolo peer-to-peer
6.2.1 PRUEBAS DE ENCADENAMIENTO
Una vez comprobado el correcto funcionamiento de cada componente software,
estas pruebas garantizan la adecuada comunicación y llamadas remotas entre unos
componentes y otros.
6.2.2 PRUEBAS DE INTEGRACIÓN
Una vez verificadas las comunicaciones y llamadas entre módulos y programas
de la aplicación se procede a integrar todos sus componentes.
6.2.3 PRUEBAS DE EXPLOTACIÓN DEL SISTEMA
Estas pruebas van encaminadas a determinar la facilidad que ofrece el sistema
para su explotación u operación. Para ello, se han ejecutado todos los procesos
recogidos en el manual de explotación siguiendo en todo momento las instrucciones
sobre entradas, sus salidas, mensajes de error y controles que se describe en dicho
manual.
6.2.4 PRUEBAS DE SOBRECARGA
Estas pruebas consisten en realizar distintos informes relacionados con el
rendimiento de la aplicación en situaciones de sobrecarga de trabajo y concurrencia de
usuarios o tareas. Estas pruebas ayudan a establecer el nivel de sobrecarga máximo
que puede soportar el sistema, a partir del cual se puede hacer necesaria la
escalabilidad de la arquitectura del sistema en cuanto al hardware, software o
comunicaciones.
6.2.5 PRUEBAS DE RECUPERACIÓN
En toda aplicación es necesario establecer determinados procesos y mecanismos
para que en caso de un mal funcionamiento del sistema y su posterior pérdida de
información, esta pueda ser recuperada o en su defecto llevar al sistema a un estado
consistente anterior.
80
Diseño e implementación de un protocolo peer-to-peer
6.2.6 PRUEBAS DE SEGURIDAD
Una vez verificadas las comunicaciones y llamadas entre módulos y programas
de la aplicación se procede a integrar todos sus componentes.
6.2.7 PRUEBAS DE USABILIDAD
El objetivo de estas pruebas es verificar la facilidad de uso del sistema, en lo
referente al diseño de la interfaz y al manual de usuario. Esta prueba es muy
importante para el sistema ya que una de las prioridades del proyecto es permitir que
los usuarios, tengan o no conocimientos previos en informática, puedan utilizar esta
aplicación sin ningún tipo de problema.
6.2.8 PRUEBAS DE ACEPTACIÓN DEL USUARIO
Estas pruebas, junto con las de usabilidad, son realizadas por el usuario. Su
objetivo es validar el sistema desde el punto de vista funcional y operativo, haciendo
uso del manual de usuario para guiarse por la navegación del sistema.
81
Capítulo 7
Planificación del
Proyecto
Diseño e implementación de un protocolo peer-to-peer
El presente proyecto comenzó el día 28 de Octubre del 2008 con la reunión de
lanzamiento mantenida entre el director de proyecto y el jefe de proyecto, en la que se
firmó la información del proyecto contenida en el anexo A. Posteriormente, este anexo
fue entregado al coordinador de proyectos.
Aunque la realización del proyecto ha sido constante, se ha visto interrumpida
por los exámenes intersemestrales de Noviembre y Abril y los exámenes finales del
curso.
Cabe destacar, que se han mantenido reuniones periódicas con el director de
proyecto, identificadas como reuniones de seguimiento, con el fin de exponer y
controlar el progreso de los objetivos del proyecto, así como presentar las decisiones
de diseño tomadas y registrar las incidencias ocurridas.
Figura 50. Planificación del proyecto
El proyecto concluyó el día 4 de Junio del 2009 con la reunión de finalización
mantenida entre el director de proyecto y el jefe de proyecto. Posteriormente, el día 5
de Junio del 2009 se entregó el presente documento al coordinador de proyecto.
83
Diseño e implementación de un protocolo peer-to-peer
La etapa de desarrollo e implementación tanto del servidor como del cliente se
ha dividido en las fases que se muestran a continuación.
Figura 51. Planificación de la etapa de desarrollo e implementación
Interfaz. Corresponde a la fase de diseño del medio de interactuación del
usuario con la aplicación, ya sea bien por medio de componentes visuales o
por medio de ficheros de registro, como es el caso del servidor.
Lógica. Corresponde a la fase de diseño de los algoritmos y métodos
necesarios para la ejecución del sistema.
Programación. Corresponde a la fase de implementación de los requisitos y
conclusiones de las dos fases anteriores.
Diseño de la base de datos. Corresponde a la fase de diseño de la base de
datos utilizada por los servidores.
Implementación de la base de datos. Corresponde a la fase de
implementación del diseño de la fase anterior.
84
Capítulo 8
Valoración
Económica del
Proyecto
Diseño e implementación de un protocolo peer-to-peer
El objetivo de esta valoración es dotar al proyecto de un valor económico y
realizar una estimación del desarrollo del mismo.
8.1 COSTES DE TECNOLOGÍA
Los costes de tecnología son costes procedentes de la adquisición de todo tipo
de máquinas hardware para el correcto funcionamiento del sistema, así como las
licencias necesarias para la utilización de las herramientas, IDEs (Integrated
Development Environment) y los distintos lenguajes empleados en el proyecto.
8.1.1 COSTES DE HARDWARE
Los recursos hardware que se han utilizado para la realización del proyecto han
sido un equipo de trabajo AMD Athlon 64 X2 Dual Core Processor 3800+ 2.00 GHz, 1 GB
de RAM, disco duro de 60 GB y una conexión a Internet.
CONCEPTO
Equipo de trabajo
Amortización estación de trabajo
Conexión a Internet
Total
COSTE
800,00 €
200,00 €
315,00 €
1.315,00 €
Figura 44. Costes de hardware
8.1.2 COSTES DE SOFTWARE
Los recursos software han sido, Windows XP Professional Versión 2002 Service
Pack 3 y el paquete ofimático Microsoft Office 2007. El resto de componentes software
necesarios, Java SE Development Kit, Eclipse Ganymede 3.4 y Omondo EclipseUML
2008 Studio Edition for Eclipse 3.4 Java Modelers, se encuentran bajo licencias de
código abierto, por lo que no representan coste alguno en la valoración económica.
CONCEPTO
Windows XP Professional 2002 Service Pack 3
Microsoft Office 2007
Total
COSTE
700,00 €
800,00 €
1.500,00 €
Figura 45. Costes de software
86
Diseño e implementación de un protocolo peer-to-peer
NOTA: La valoración anterior corresponde al valor máximo, ya que se han
tomado los costes de licencias de nueva adquisición. En caso de poseer licencias para
el uso de las anteriores herramientas, o adquirir ampliaciones de licencias, los costes
de tecnología serían inferiores.
Con el cálculo de los dos costes anteriores se puede calcular los costes de
tecnología, como se detalla a continuación.
CONCEPTO
Costes de hardware
Costes de software
Total
COSTE
1.315,00 €
1.500,00 €
2.815,00 €
Figura 46. Costes de tecnología
8.2 COSTES DE IMPLANTACIÓN
Los costes de implantación son costes procedentes del trabajo de todo el
personal implicado en el desarrollo del proyecto.
A continuación se detalla las funciones de cada una de las personas integrantes
del proyecto.
Director de proyecto. Su labor consiste en que el jefe de proyecto presente
un proyecto y una documentación de calidad exigida en los plazos acordados,
aportando conocimiento de tipo técnico y funcional. Es el responsable de
dirigir el proyecto, facilitar conocimientos y orientar indicaciones para la
resolución ante posibles problemas surjan, y supervisar la realización del
proyecto así como la calidad de sus contenidos.
Jefe de proyecto. Es el máximo responsable del proyecto. Su labor consiste en
gestionar el proyecto realizando actividades de seguimiento, control y
planificación, asignación de recursos y demás actividades de gestión.
87
Diseño e implementación de un protocolo peer-to-peer
Analista. Es el responsable de analizar los requisitos de la aplicación y
elaborar las especificaciones técnicas de los programas. Además, en algunos
casos puede ayudar al programador en la realización de alguna actividad.
Programador. Es el responsable de implementar el código ejecutable de la
aplicación con los requisitos y especificaciones facilitadas por el analista, así
como realizar parte de la documentación del proyecto, como el manual de
usuario y el manual del administrador.
A continuación se muestra la estimación del esfuerzo de cada unos de los
integrantes del proyecto. Dicha estimación se ha realizado junto con la planificación
del proyecto.
ACTIVIDAD
Reunión de lanzamiento
Anexo A
Estudio de clientes actuales
Anexo B
Reunión de seguimiento
Interfaz del servidor
Lógica del servidor
Programación del servidor
Diseño de la BBDD
Implementación de la BBDD
Reunión de seguimiento
Interfaz del cliente
Lógica del cliente
Programación del cliente
Pruebas unitarias
Pruebas de integración
Pruebas de aceptación
Reunión de seguimiento
Documentación
Anexos
Reunión de finalización
DIRECTOR DE
PROYECTO
1
1
--1
2
----------2
------------2
4
--2
JEFE DE
ANALISTA PROGRAMADOR
PROYECTO
1
----1
----2
20
--1
----2
------1
2
--5
15
--25
55
--2
3
----5
2
------10
25
--10
20
--30
75
--5
15
--5
15
--5
15
2
----10
30
30
--2
10
4
-----
Figura 47. Estimación del esfuerzo de los integrantes del proyecto
88
Diseño e implementación de un protocolo peer-to-peer
Con la estimación anterior, y el coste base de cada integrante del proyecto, se
puede realizar el cálculo de los costes de implantación, como se detalla a continuación.
FUNCIÓN
Director de proyecto
Jefe de proyecto
Analista
Programador
NÚMERO DE HORAS
15
25
150
285
COSTE/HORA
100,00 €
80,00 €
60,00 €
40,00 €
Total
COSTE
1.500,00 €
2.000,00 €
9.000,00 €
11.400,00 €
23.900,00 €
Figura 48. Costes de implantación
8.3 VALORACIÓN FINAL
En total, los costes del desarrollo del proyecto ascienden a una cantidad de
26.865,00 €.
CONCEPTO
DETALLE
Costes de hardware
Costes de software
Director de proyecto
Jefe de proyecto
Analista
Programador
COSTE
Otros gastos
1.315,00 €
1.500,00 €
1.500,00 €
2.000,00 €
9.000,00 €
11.400,00 €
150,00 €
Total
26.865,00 €
Costes de tecnología
Costes de implantación
Figura 49. Costes de desarrollo del proyecto
NOTA: El concepto de otros gastos hace referencia a gastos de material
consumible.
89
Capítulo 9
Conclusiones y
Futuras Líneas de
Desarrollo
Diseño e implementación de un protocolo peer-to-peer
En el presente proyecto se ha realizado un exhaustivo análisis sobre los sistemas
actuales P2P de transferencia de archivos, detallando sus características,
funcionamiento y mejoras con respecto a otros sistemas y, conjuntamente, se ha
introducido el problema de las búsquedas de archivos en este tipo de redes. Sobre esa
base, se ha realizado el diseño e implementación de un protocolo independiente del
servidor al que el usuario se encuentre conectado.
Al eliminar la dependencia de la conexión con el servidor, el número de archivos
encontrados en el proceso de búsqueda, el número de fuentes encontradas que tienen
disponible el archivo para compartir, y el número de comentarios de los usuarios que
califican los archivos, son mayores. Además, dado que el número de fuentes
encontradas es mayor, se reduce considerablemente el tiempo de transferencia del
archivo, ya que la posibilidad de conexión a un mayor número de pares se incrementa.
Al no existir una dependencia con el servidor, los clientes no tienen que
mantener una lista de servidores en la que elegir sus favoritos y su prioridad en el
proceso de conexión, por lo que se le libera de una tarea innecesaria, equilibrando de
esta forma las conexiones de los clientes entre los distintos servidores. Además, al
realizar una gestión óptima de los recursos, en este caso los servidores que se
encuentran conectados a la red, el reparto de carga de trabajo entre estos y las
solicitudes de búsqueda de un archivo entre los usuarios de la red están más
proporcionadas.
La arquitectura propuesta, basada en una red IP multicast, permite que cada
servidor conozca una pequeña parte de la red P2P y no sea necesario conocer toda la
tipología de esta, de manera que el tamaño de la red puede crecer tanto como sea
necesarios sin la necesidad de afectar al rendimiento de los nodos. Asimismo, con una
única conexión, a la red IP multicast, se permite mantener un intercambio continuado
de la información de la base de datos entre los distintos servidores, sin la necesidad de
mantener tantas conexiones como servidores estén conectados a la red P2P, lo que
disminuye la sobrecarga y el coste computacional de estos.
91
Diseño e implementación de un protocolo peer-to-peer
El sistema propuesto se podría enmarcar dentro de los sistemas P2P
estructurados, ya que se conoce la localización exacta de los recursos, pero sin la
necesidad de que los clientes tengan que mantener una tabla hash para calcular el
lugar en el que está cada recurso como sucede en el caso de las redes Pastry, CAN o
Chord. Este sistema, proporciona un mecanismo de búsqueda determinista, de tal
forma que se asegura la localización de un recurso siempre y cuando se encuentre en
la red, encaminando los mensajes de forma eficiente.
Con la realización de este proyecto, se suplen algunas carencias de las actuales
aplicaciones de búsqueda y transferencia de archivos en redes peer-to-peer, como es
el caso de la búsqueda de fuentes o de comentarios de un determinado archivo.
Además, otras características y funcionalidades de estas aplicaciones se optimizan,
como por ejemplo la previsualización de los archivos en estado de descarga y la
gestión del espacio de los archivos temporales.
Las posibles futuras líneas de investigación en el contexto de las redes P2P son
numerosas y amplias. Las capacidades que aporta la infraestructura de clave pública,
PKI24 (Public Key Infrastructure), a las aplicaciones en las que es necesaria la ejecución
con garantías de operaciones criptográficas como el cifrado, la firma digital o el no
repudio de transacciones electrónicas, son extremadamente seguras. Las operaciones
criptográficas de clave pública, son procesos en los que se utilizan determinados
algoritmos de cifrado que son conocidos y se encuentran accesibles. Por este motivo la
seguridad que puede aportar la tecnología PKI, está fuertemente ligada a la privacidad
de la llamada clave privada y los procedimientos operacionales o políticas de seguridad
aplicados. El uso de esta infraestructura de clave pública se podría extender al
presente proyecto para así poder limitar la conexión entre los pares de la red
exclusivamente a aquellos nodos en los que el usuario confía, transformando así la red
P2P en una red F2F.
Conjuntamente, esta infraestructura se podría extender al sistema del presente
proyecto para, además de garantizar un alto grado de seguridad en las
24
El término PKI (Public Key Infrastructure) se refiere a la combinación de hardware, software y políticas
de seguridad para permitir la ejecución de cifrados y firmas digitales en operaciones electrónicas.
92
Diseño e implementación de un protocolo peer-to-peer
comunicaciones, que los contenidos que estén bajo derechos de autor sean
compatibles con las transferencias. De esta forma, existiría una compatibilidad con los
derechos de autor y las licencias de los archivos.
Con el objetivo de dotar de una mayor estabilidad a las conexiones de los
clientes, se podría realizar un proceso de reconexión de estos a otros servidores de la
red P2P, en caso de que el servidor al que se encuentren conectados dejara de estar
accesible por cualquier motivo. De esta forma se garantizaría un rápido retorno de la
disponibilidad de los recursos en caso de fallo de algún servidor de la red.
Con el fin de encontrar el equilibrio con otras aplicaciones que se ejecuten en el
cliente y que hagan uso de una conexión a Internet, se podría dar la posibilidad al
usuario de elegir los rangos de velocidades máximas de subida y descarga de archivos.
De esta forma, la aplicación cliente no coparía todo el ancho de banda disponible y el
usuario podría ejecutar otras aplicaciones que necesiten de conexión a Internet.
Ampliando la propuesta anterior, la aplicación cliente podría añadir un sistema
de filtrado de paquetes, aplicando técnicas de traffic shaping25, para otorgar mayor
prioridad a los paquetes, protocolos o servicios que decida el usuario. El resultado de
la aplicación de este sistema de filtrado, sería una navegación por Internet mucho más
fluida, un menor valor del ping y mejores rendimientos en lo referente a servicios de
streaming26 o VoIP.
Ya que los archivos que se suelen transferir en las redes P2P son de un tamaño
considerable y por lo tanto el tiempo de transferencia suele ser alto, se podría añadir
una aplicación web para la gestión y monitorización remota por parte del cliente, para
así ofrecer la posibilidad de gestionar sus transferencias, sin la necesidad de estar
delante del equipo de trabajo desde el cual ha iniciado las transferencias de los
archivos.
25
El término traffic shaping se refiere a una técnica de catalogación del tráfico para optimizar el
rendimiento de una red.
26
El término streaming se refiere a un servicio para la reproducción de contenidos multimedia
directamente desde una página web.
93
Bibliografía y
Referencias
Diseño e implementación de un protocolo peer-to-peer
BIBLIOGRAFÍA DE CONSULTA
[MILL06]
Millán R. J. Domine las redes P2P: Peer to Peer orígenes, funcionamiento
y legislación del P2P, selección y configuración del acceso de banda
ancha a Internet. Creaciones Copyright. ISBN 849630020X.
[TAVE08]
Tavera M. L. Apuntes de la asignatura Tecnologías avanzadas de
sistemas operativos. Universidad Pontificia de Comillas de Madrid.
[STEV02]
Stevens P., Pooley R. Traducción de Alarcón M., Sanjuán O., Pérez F.
Utilización de UML en ingeniería del software. Addison Wesley. ISBN
9788478290864
[BARR01]
Barranco J. Metodología del análisis estructurado de sistemas.
Universidad Pontificia de Comillas de Madrid. ISBN 8484680436.
[ESQU08]
Esquivel J. C. Apuntes de la asignatura Ingeniería del software II.
Universidad Pontificia de Comillas de Madrid.
[ECKE02]
Eckel B. Traducción de González J. Thinking in Java. Prentice Hall. ISBN
8420531928.
[RUST04]
Rusty E. Java Network Programming. O’REILLY. ISBN 0596007213.
[MYSQ09]
MySQL AB. MySQL 5.0 Reference Manual. http://dev.mysql.com/doc/
refman/5.0/en/what-is-mysql.html
[MICR03]
Microsoft. Revisión Barahona E, Sánchez B. Diccionario de informática e
Internet. McGraw Hill. ISBN 8448138600.
[GOME02]
Gómez M. J., de Pino L. Diccionario inglés-español de informática y
telecomuniacaciones. McGraw Hill. ISBN 8448136403.
95
Diseño e implementación de un protocolo peer-to-peer
REFERENCIAS BIBLIOGRÁFICAS
[AFAN06]
Afanador J. A., Ribero D. F., Ulloa G. E. Redes P2P y enrutamiento en
capa de de aplicación. Revista Sistemas Nº 98.
[SANT07]
Santín A. Peer 2 Peer. Sistemas Operativos Distribuidos. http://jungla.
dit.upm.es/~joaquin/so/p2p/p2p.pdf
[RODE05]
Rodero L., Fernández A., López L., Cholvi V. Topologías dinámicas en
redes P2P no estructuras. XV Jornadas Telecom I+D.
[MUÑO04]
Muñoz J. M. SIRTED. Sistema Inteligente de Reparto de Trabajo en
Entornos Distribuidos. Proyecto Final de Carrera. Universidad Pontificia
de Comillas de Madrid.
[MYSQ09]
MySQL AB. MySQL 5.0 Reference Manual. http://dev.mysql.com/doc/
refman/5.0/en/what-is-mysql.html
[HAXI01]
http://www.haxial.com/products/kdx/index2.html
[MONK03]
Monk. Credit System. http://emule-project.net/home/perl/help.cgi?l=1&
rm=show_topic&topic_id=134
[COHE01]
Cohen
B.
http://finance.groups.yahoo.com/group/decentralization/
message/3160
[ISOH08]
http://isohunt.com/forum/viewtopic.php?t=145853
[AMIL06]
Amilmani, K. Studying and enhancing the BitTorrent protocol. Stony
Brook University.
[SOTO06]
Soto P. http://www.pablosoto.com/2006/11/omemo.html
[GARC05]
García A. Apuntes de la asignatura Redes de ordenadores. Universidad
Pontificia de Comillas de Madrid.
96
Diseño e implementación de un protocolo peer-to-peer
[MICRO04]
Sun Microsystems. API specification for the Java 2 Platform Standard
Edition 5.0. http://java.sun.com/j2se/1.5.0/docs/api/
[WANG04]
Wang X., Feng D., Lai X., Yu H. Collisions for Hash Functions MD4, MD5,
HAVAL-128 and RIPEMD. http://eprint.iacr.org/2004/199.pdf
[OMG09]
Object
Management
Group.
http://www.omg.org/gettingstarted/
what_is_uml.htm
97
Anexo I
Manual de Usuario
de la Aplicación
Cliente
ÍNDICE
1. INTRODUCCIÓN ............................................................................................... 101
1.1. OBJETIVO DEL MANUAL DE USUARIO ........................................................................... 101
1.2. OBJETIVO DE LA APLICACIÓN ........................................................................................ 101
2. ENTORNO DE LA APLICACIÓN ........................................................................... 101
2.1. REQUISITOS HARDWARE ............................................................................................... 101
2.2. REQUISITOS SOFTWARE ................................................................................................ 103
3. INSTALACIÓN DE LA APLICACIÓN...................................................................... 103
4. EJECUCIÓN DE LA APLICACIÓN ......................................................................... 103
4.1. CONEXIÓN A LA RED P2P .............................................................................................. 103
4.2. BÚSQUEDAS DE ARCHIVOS ........................................................................................... 104
4.3. TRANSFERENCIAS .......................................................................................................... 105
4.4. ARCHIVOS LOCALES....................................................................................................... 107
5. ESTRUCTURA DE DIRECTORIOS Y ARCHIVOS ..................................................... 108
5.1. DIRECTORIOS DE LA APLICACIÓN .................................................................................. 108
5.2. ARCHIVOS DE LA APLICACIÓN ....................................................................................... 109
6. INCIDENCIAS MÁS FRECUENTES ....................................................................... 110
7. MENSAJES DE AVISO ........................................................................................ 110
7.1. AVISO DE NO CONEXIÓN ............................................................................................... 110
7.2. AVISO DE NO SELECCIÓN DE ARCHIVO ......................................................................... 111
7.3. CONFIRMACIÓN DE CIERRE........................................................................................... 111
8. MENSAJES DE ERROR ....................................................................................... 112
8.1. ERROR EN LA CONEXIÓN ............................................................................................... 112
8.2. ERROR EN LA BÚSQUEDA DE ARCHIVOS ....................................................................... 112
8.3. ERROR EN LA OBTENCIÓN DE DIRECCIONES IP ............................................................. 112
8.4. ERROR DE OBTENCIÓN DE ARCHIVOS LOCALES............................................................ 113
8.5. ERROR EN LA DESCONEXIÓN......................................................................................... 113
9. GLOSARIO DE TÉRMINOS ................................................................................. 113
TABLA DE FIGURAS
IDENTIFICADOR
DESCRIPCIÓN
PÁGINA
Figura 1
Figura 2
Figura 3
Figura 4
Figura 5
Figura 6
Figura 7
Figura 8
Figura 9
Figura 10
Figura 11
Figura 12
Figura 13
Figura 14
Figura 15
Figura 16
Figura 17
Figura 18
Figura 19
Figura 20
Figura 21
Requisitos para sistemas Solaris
Requisitos para sistemas Windows
Requisitos para sistemas Linux
Parámetros de búsqueda de archivos
Tabla de resultados de una búsqueda
Ventana de comentarios de un archivo
Tabla de descargas actuales del cliente
Acciones sobre los archivos en estado de descarga
Ventana de registro de un nuevo comentario
Ventana de comentarios de un archivo
Previsualización de un archivo de vídeo
Ventana de recursos locales
Acciones sobre los archivos locales
Aviso de desconexión del cliente
Aviso de archivo no seleccionado
Confirmación de cierre de la aplicación
Aviso de error en la conexión
Error en la búsqueda de archivos
Error en la obtención de direcciones IP
Aviso de error en la obtención de archivos locales
Aviso de error en la obtención de archivos locales
101
102
102
104
104
105
105
106
106
106
107
108
108
111
111
111
112
112
113
113
113
Diseño e implementación de un protocolo peer-to-peer
1. INTRODUCCIÓN
1.1 OBJETIVO DEL MANUAL DE USUARIO
El objetivo del presente manual es facilitar al usuario el aprendizaje y uso de la
de la aplicación cliente que se ha desarrollado. Contiene descripciones y detalles de
todos los componentes de la aplicación, así como las especificaciones de las posibles
opciones que se ofrecen.
1.2 OBJETIVO DE LA APLICACIÓN
El objetivo de la aplicación cliente es ofrecer una aplicación que se conecte a una
red P2P en la que se ha mejorado el proceso de búsqueda de los archivos entre los
usuarios. Se entiende por mejora la eliminación de la dependencia del proceso de
búsqueda al servidor al que el usuario se encuentre conectado. Además la aplicación
ofrece la posibilidad de gestión de archivos, en lo que respecta la búsqueda y
transferencia de estos así como de la gestión de los recursos locales que se ponen a
disposición de la red P2P.
2. ENTORNO DE LA APLICACIÓN
2.1 REQUISITOS HARDWARE
Para una correcta ejecución de la aplicación, los requisitos hardware son los
especificados por Sun Microsystems para el entorno de ejecución de Java 5.0 JRE (Java
Runtime Environment).
Los requisitos para sistemas Solaris son los que se describen a continuación.
PLATAFORMA
VERSIÓN
Sistema operativo
Sistema operativo
Solaris AMD64/EM64T
Solaris 10
MEMORIA
ESPACIO EN DISCO
64 MB
Instalación de 32 bits en 53 MB
Instalación de 64 bits en 23 MB
Figura 1. Requisitos para sistemas Solaris
101
Diseño e implementación de un protocolo peer-to-peer
Los requisitos para sistemas Windows son los que se describen a continuación.
PLATAFORMA
Intel de 32 bits
VERSIÓN
Windows XP Professional
SP1
Windows XP Home
Windows 2000 Professional
SP3 o posterior
Windows 98 2ª edición
Windows ME
Windows Server 2003 Web
Edition
MEMORIA
ESPACIO EN DISCO
64 MB
64 MB
64 MB
64 MB
64 MB
128 MB
98 MB
Windows Server 2003
Standard Edition
128 MB
Windows Server 2003
Enterprise Edition
128 MB
Windows Server 2003
DataCenter Edition
128 MB
AMD Opteron de 32 bits
Windows Server 2003 AMD
Opteron de 32 bits
128 MB
98 MB
AMD Opteron de 64 bits
Windows Server 2003 AMD
Opteron de 32 bits
128 MB
110 MB
Figura 2. Requisitos para sistemas Windows
Los requisitos para sistemas Linux son los que se describen a continuación.
PLATAFORMA
VERSIÓN
MEMORIA
Red Hat 9.0
Red Hat Enterprise Linux
AS 3.0
64 MB
ESPACIO EN DISCO
64 MB
Red Hat Enterprise Linux
WS 2.1
64 MB
Red Hat Enterprise Linux
ES 2.1
64 MB
Arquitectura Intel de 32 bits Red Hat Enterprise Linux
AS 2.1
64 MB
SuSE 8.2
SLEC 8
SLES 8
TurboLinux 8.0
64 MB
64 MB
64 MB
64 MB
Sun Java Desktop
System versión 1
64 MB
58 MB
102
Diseño e implementación de un protocolo peer-to-peer
Sun Java Desktop
System versión 2
Arquitectura Intel de 32 bits
64 MB
58 MB
AMD Opteron de 32 bits
Red Hat Enterprise
Linux AS 3.0
58 MB
AMD Opteron de 64 bits
SLES 8
Red Hat Enterprise
Linux AS 3.0
56 MB
SLES 8
Figura 3.
3 Requisitos para sistemas Linux
2.2 REQUISITOS SOFTWARE
Para una correcta ejecución de la aplicación, el requisito software es la
instalación del
el entorno de ejecución de Java 5.0 JRE (Java
(Java Runtime Environment).
Environment
El archivo ejecutable contiene las referencias a librerías externas para la
ejecución de la interfaz gráfica de usuario Java Swing Look and Feel of Mosfet Liquid
KDE 3.x. Para más información acerca de esta librería, visitar la página web
https://liquidlnf.dev.java.net/
3. INSTALACIÓN DE LA APLICACIÓN
El archivo dee instalación se distribuye con la extensión jar.. Si el sistema operativo
instalado reconoce esta extensión, pinchar repetidamente sobre el icono del archivo
para su ejecución. En caso de que el sistema operativo no reconozca este tipo de
extensión, será necesario asociar la extensión jar con el programa java..
4. EJECUCIÓN DE LA APLICACIÓN
4.1 CONEXIÓN A LA RED P2P
Para conectar el cliente a la red P2P, pulsar el botón con
con el icono
localizado
en la barra de herramientas de la aplicación. Una vez conectado el cliente aparecerá el
icono
, pulsar sobre él para la desconexión de la aplicación.
103
Diseño e implementación de un protocolo peer-to-peer
4.2 BÚSQUEDAS DE ARCHIVOS
Para comenzar las búsquedas de archivos, pulsar sobre el icono
localizado en la
barra de herramientas de la aplicación. A continuación aparecerá una ventana en la
que en la parte superior izquierda se encuentran los parámetros a introducir para
comenzar la búsqueda.
Figura 4.
4 Parámetros de búsqueda de archivos
Para comenzar la búsqueda, introducir la cadena de búsqueda y presionar la
tecla Enter o pinchar sobre el botón Search.. Con el fin de limitar los resultados de las
búsquedas, se puede introducir el tipo de archivo a buscar, seleccionándolo del
componente desplegable.
Los resultados de la búsqueda se mostrarán en una tabla de la parte derecha de
la ventana. Una vez se muestren
muestren los resultados obtenidos, los botones Comments y
Download se activarán.
Figura 5.
5 Tabla de resultados de una búsqueda
104
Diseño e implementación de un protocolo peer-to-peer
Cuando algún resultado de la búsqueda contenga el valor
, se podrá iniciar
una búsqueda de una búsqueda de comentarios de un archivo.
Para iniciar una búsqueda de comentarios de un archivo, seleccionar el archivo
de la tabla de resultados y pinchar sobre el botón Comments.. Cuando se obtengan los
comentarios del archivo seleccionado, se mostrará una ventana con los resultados.
La evaluación que puede recibir un archivo es good,, indicada por el icono
bad, indicada por el icono
o
.
Figura 6.
6 Ventana de comentarios de un archivo
4.3 TRANSFERENCIAS
Para acceder a la ventana que muestra las actuales descargas del cliente, pulsar
sobre el icono
localizado en la barra de herramientas de la aplicación. A
continuación aparecerá una ventana en la que en la parte derecha se encuentran las
actuales descargas.
Figura 7.
7 Tabla de descargas actuales del cliente
En la parte superior
rior izquierda se encuentran las acciones que se pueden realizar
sobre los archivos que se encuentran descargando.
105
Diseño e implementación de un protocolo peer-to-peer
Figura 8. Acciones sobre los archivos en estado de descarga
Seleccionando la acción Add comment,, aparecerá una ventana en la que se podrá
añadir un nuevo comentario al archivo. Para añadir un nuevo comentario, escribir la
descripción del comentario y elegir la evaluación del archivo entre los distintos valores,
Not evaluated, Good o Bad.
Bad Una vez introducidos
roducidos estos valores pinchar sobre el botón
Accept.
Figura 9.. Ventana de registro de un nuevo comentario
Seleccionando la acción See comments,, aparecerá una ventana en la que se
mostrarán los comentarios del archivo. La evaluación que puede recibir un archivo es
good,, indicada por el icono
o bad, indicada por el icono
.
Figura 10.
10 Ventana de comentarios de un archivo
Seleccionando la acción Preview download,, el archivo seleccionado se
previsualizará utilizando en programa asociado a la extensión del archivo. La
previsualización del un archivo ofrece al usuario una forma de comprobar si el archivo
que se está descargando
o es de la calidad esperada.
Para los archivos multimedia de video o sonido, se recomienda la instalación del
reproductor VideoLAN – VLC media player, disponible en la página web
http://www.videolan.org/
106
Diseño e implementación de un protocolo peer-to-peer
La previsualización
ualización del un archivo es un proceso complejo, ya que hay que unir
las partes descargadas del archivo, por lo que el tiempo que transcurre desde la
selección de esta opción hasta la reproducción del archivo puede ser considerable.
Figura 11.
11 Previsualización de un archivo de vídeo
Seleccionando la acción Cancel download,, la descarga del archivo seleccionado
se anulará y todos los archivos e información relativa a está serán eliminados.
4.4 ARCHIVOS LOCALES
Para gestionar los archivos locales que se ponen a disposición de la red P2P,
pinchar sobre el icono
localizado en la barra de herramientas de la aplicación. A
continuación aparecerá una ventana en la que en la parte derecha se encuentran una
tabla que contiene
ontiene los archivos que se ponen a disposición de otros clientes de la red y
que se encuentran localizados en el directorio Incoming.
107
Diseño e implementación de un protocolo peer-to-peer
Figura 12. Ventana de recursos locales
En la parte superior izquierda se encuentran las acciones que se pueden realizar
sobre los archivos locales.
Figura 13. Acciones sobre los archivos locales
Seleccionando la acción Add comment, aparecerá una ventana en la que se podrá
añadir un nuevo comentario al archivo. Para añadir un nuevo comentario, escribir la
descripción del comentario y elegir la evaluación del archivo entre los distintos valores.
Ver figura 8.
Seleccionando la acción See comments, aparecerá una ventana en la que se
mostrarán los comentarios del archivo. Ver figura 9
Seleccionando la opción Reload shares, se recarga en la aplicación los archivos
del directorio incoming, por si han ocurrido eliminaciones o altas de nuevos archivos.
5. ESTRUCTURA DE DIRECTORIOS Y ARCHIVOS
5.1 DIRECTORIOS DE LA APLICACIÓN
Cuando se instala la aplicación, se crea una estructura de directorios para el
almacenamiento y gestión de archivos, tanto los transferidos a la red P2P, como los
necesarios para la ejecución de la aplicación. A continuación se detalla cada uno de
estos directorios.
108
Diseño e implementación de un protocolo peer-to-peer
Config. Directorio que contiene archivos necesarios para la ejecución de la
aplicación.
Incoming. Directorio donde se alojan los archivos descargados por el cliente y
los que se ponen a disposición de la red P2P. Dentro de este directorio se
puede realizar cualquier tipo de distribución de otros directorios, ya que la
aplicación tomará este como raíz y mostrará todos los archivos que contenga,
aun en el caso de existir subdirectorios dentro de él.
Previews. Directorio donde se almacenan los archivos que contienen la
previsualización de los archivos que se están descargando. Por motivos de
gestión del espacio de almacenamiento del disco, al cerrar la aplicación, todo
el contenido de este directorio es eliminado.
Temp. Directorio donde se albergan los archivos que contienen los datos de
las descargas actuales. Una vez el archivo se ha descargado completamente,
su correspondiente archivo temporal es eliminado.
5.2 ARCHIVOS DE LA APLICACIÓN
Los archivos que maneja la aplicación son lo que se detallan a continuación.
Comments.dat. Archivo que contiene la evaluación y los comentarios que el
usuario realiza sobre la calificación de un determinado archivo.
Downloads.dat. Archivo que contiene información relativa de los archivos que
se están descargando, como el fichero temporal asociado a la descarga, el
nombre, la extensión, el tamaño y el valor de la función hash.
Hashes.dat. Ya que el cálculo del valor de la función hash de un archivo, tiene
un coste computacional bastante alto, en este archivo se almacenan estos
valores.
Servers.dat. Archivo que contiene direcciones IP y puertos de los servidores
que se conectan a la red P2P.
N.temp. Archivo que contienen los datos de una de las descargas actuales. El
nombre del archivo, N, es un valor entero asignado por el gestor de
transferencias.
109
Diseño e implementación de un protocolo peer-to-peer
6. INCIDENCIAS MÁS FRECUENTES
La resolución adecuada para la ejecución del cliente es 1152 por 864 píxeles. Si al
ejecutar la aplicación no se ven todos los componentes o se ve partes de éstos, es que
la resolución actual no es la indicada anteriormente. Para solucionar el problema,
cambiar la resolución de la pantalla a 1152 por 864 píxeles o en su defecto a la más
aproximada.
El proceso de conexión del cliente al servidor de la red P2P, es un proceso largo,
por lo que tiempo que transcurre desde que se inicia la conexión hasta que el cliente
se conecta, puede ser considerable. Si después de unos minutos el cliente no se ha
conectado a la red, comprobar la conexión a Internet, ya que el problema es de la
conexión y no del cliente. En caso de tener instalado en el sistema un firewall, aplicar
las políticas de seguridad adecuadas para permitir la ejecución de la aplicación cliente.
La previsualización de los archivos que se encuentran en estado de descarga,
dependen del reproductor multimedia que se tenga instalado en el sistema. Si al
previsualizar un archivo de video o música, no se ve la imagen o no se escucha sonido
alguno, es por la falta de instalación de algún códec en el sistema. Se recomienda la
instalación del reproductor VideoLAN – VLC media player, disponible en la página web
http://www.videolan.org/
7. MENSAJES DE AVISO
La aplicación maneja diversos tipos de mensajes de aviso para advertir al usuario
de las distintas incidencias que ocurren en tiempo de ejecución por la acción que se ha
realizado. A continuación se describe cada unos de estos mensajes de aviso.
7.1 AVISO DE NO CONEXIÓN
Este aviso aparece cuando el cliente no se encuentra conectado a la red P2P.
Mientras el cliente no se encuentre conectado, no se podrán realizar búsquedas en la
red, ni tampoco transferencia alguna. Tampoco se iniciarán las descargas pendientes
en el sistema.
110
Diseño e implementación de un protocolo peer-to-peer
Para solucionar el problema, pulsar el botón con el icono
localizado en la
barra de herramientas de la aplicación.
Figura 14.
14 Aviso de desconexión del cliente
7.2 AVISO DE NO SELECCIÓN DE ARCHIVO
Este aviso aparece cuando el usuario ha ejecutado una acción y no hay ningún
archivo seleccionado. Para solucionar el problema, pinchar
pinchar el archivo sobre el que se
desea ejecutar la acción.
Figura 15.
15 Aviso de archivo no seleccionado
7.3 CONFIRMACIÓN DE CIERRE
Este aviso aparece cuando el usuario pincha sobre el icono de cierre de la
aplicación cliente. Pulsar Yes para cerrar la aplicación o No para continuar con la
ejecución.
Figura 16.
16 Confirmación de cierre de la aplicación
111
Diseño e implementación de un protocolo peer-to-peer
8. MENSAJES DE ERROR
La aplicación maneja diversos tipos de mensajes de error para advertir al usuario
de las distintas
istintas incidencias que ocurren en tiempo de ejecución por la acción que se ha
realizado. A continuación se describe cada unos de estos mensajes de aviso.
8.1 ERROR EN LA CONEXIÓN
Este aviso aparece cuando por algún motivo ajeno al cliente, no se ha podido
realizar la conexión con el servidor de la red.
red Para solucionar el problema, vuelva a
intentar la conexión del cliente, pulsando el botón con el icono
.
Figura 17.
17 Aviso de error en la conexión
8.2 ERROR EN LA BÚSQUEDA DE ARCHIVOS
Este aviso aparece cuando por algún motivo ajeno al cliente, no se ha podido
obtener las direcciones IP de los clientes disponen de un determinado fichero.
fichero
Figura 18.
18 Error en la búsqueda de archivos
8.3 ERROR EN LA OBTENCIÓN DE DIRECCIONES IP
Este aviso aparece cuando por algún motivo ajeno al cliente, no se ha podido
obtener las direcciones IP de los clientes disponen de un determinado fichero.
fichero
112
Diseño e implementación de un protocolo peer-to-peer
Figura 19. Error en la obtención de direcciones IP
8.4 ERROR DE OBTENCIÓN DE ARCHIVOS LOCALES
Este aviso aparece cuando ocurre un error en el cálculo del identificador del
archivo, al aplicar el algoritmo SHA1.
Figura 20. Aviso de error en la obtención de archivos locales
8.5 ERROR EN LA DESCONEXIÓN
Este aviso aparece cuando ocurre algún error por algún motivo ajeno al cliente
no se ha podido registrar la desconexión en el servidor.
Figura 21. Aviso de error en la obtención de archivos locales
9. GLOSARIO DE TÉRMINOS
Red P2P. Conjunto de equipos conectados por medio de un método de
transporte de datos en el que se comparten recursos y en el que no están definidos ni
clientes ni servidores fijos.
113
Diseño e implementación de un protocolo peer-to-peer
JRE. (Java Runtime Environment). Conjunto de utilidades que permiten la
ejecución de aplicaciones realizadas bajo el lenguaje de programación Java sobre todas
las plataformas soportadas.
VideoLAN – VLC media player. Reproductor desarrollado por estudiantes de la
escuela École Centrale Paris, distribuido bajo licencia GPL que soporta gran multitud de
formatos de audio y video, así como diferentes tipos de archivos.
Directorio. Modo de organizar los archivos del disco duro. El directorio más alto
se denomina raíz y los que se encuentran dentro de éste, subdirectorios.
Función hash. Método de generación de claves que identifican de manera
unívoca un archivo. Un hash es el valor obtenido después de haber aplicado la función.
Dirección IP. Número binario de 32 bits que identifica de manera inequívoca a
una máquina conectada a una red con el objetivo de comunicarse intercambiando
paquetes de información.
Puerto. Forma genérica de denominar una interfaz por la cual diferentes tipos de
datos pueden ser enviados o recibidos. Esta interfaz puede ser física o lógica.
Firewall. Sistema que está configurado para controlar el flujo de tráfico entre dos
redes, permitiendo o denegando servicios dentro de una red.
SHA1. (Secure Hash Algorithm). Algoritmo de función hash diseñado por NIST
(National Institute of Standards and Technology) y NSA (National Security Agency) para
el uso en comprobaciones de integridad de mensajes que produce un identificador de
un archivo de 160 bits.
114
Anexo II
Manual de Usuario
de la Aplicación
Servidor
ÍNDICE
1. INTRODUCCIÓN ................................................................................................ 118
1.1. OBJETIVO DEL MANUAL DE USUARIO ........................................................................... 118
1.2. OBJETIVO DE LA APLICACIÓN ........................................................................................ 118
2. ENTORNO DE LA APLICACIÓN ............................................................................ 118
2.1. REQUISITOS HARDWARE ............................................................................................... 118
2.2. REQUISITOS SOFTWARE ................................................................................................ 120
3. BASE DE DATOS ................................................................................................ 120
3.1. DRIVER MYSQL CONNECTOR/J ...................................................................................... 120
3.2. DEFINICIÓN DE TABLAS ................................................................................................. 121
4. INSTALACIÓN DE LA APLICACIÓN ...................................................................... 123
5. ARCHIVO DE REGISTRO DE ERRORES ................................................................. 123
6. ARCHIVOS DE LA APLICACIÓN ........................................................................... 124
7. GLOSARIO DE TÉRMINOS .................................................................................. 124
TABLA DE FIGURAS
IDENTIFICADOR
Figura 1
Figura 2
Figura 3
Figura 4
DESCRIPCIÓN
Requisitos para sistemas Solaris
Requisitos para sistemas Windows
Requisitos para sistemas Linux
Fichero de registro de errores
PÁGINA
118
118
119
123
Diseño e implementación de un protocolo peer-to-peer
1. INTRODUCCIÓN
1.1 OBJETIVO DEL MANUAL DE USUARIO
El objetivo del presente manual es facilitar al usuario el aprendizaje y uso de la
de la aplicación servidor que se ha desarrollado. Contiene descripciones y detalles de
todos los componentes de la aplicación, así como las especificaciones de las posibles
opciones que se ofrecen.
1.2 OBJETIVO DE LA APLICACIÓN
El objetivo de la aplicación servidor es ofrecer una aplicación que gestione las
búsquedas que demandan los clientes que se encuentran conectados a él.
2. ENTORNO DE LA APLICACIÓN
2.1 REQUISITOS HARDWARE
Para una correcta ejecución de la aplicación, los requisitos hardware son los
especificados por Sun Microsystems para el entorno de ejecución de Java 5.0 JRE (Java
Runtime Environment).
Los requisitos para sistemas Solaris son los que se describen a continuación.
PLATAFORMA
VERSIÓN
Sistema operativo
Sistema operativo
Solaris AMD64/EM64T
Solaris 10
MEMORIA
ESPACIO EN DISCO
64 MB
Instalación de 32 bits en 53 MB
Instalación de 64 bits en 23 MB
Figura 1. Requisitos para sistemas Solaris
Los requisitos para sistemas Windows son los que se describen a continuación.
PLATAFORMA
VERSIÓN
Intel de 32 bits
Windows XP Professional
SP1
Windows XP Home
Windows 2000
Professional SP3 o
posterior
Windows 98 2ª edición
Windows ME
MEMORIA
ESPACIO EN DISCO
64 MB
64 MB
64 MB
98 MB
64 MB
64 MB
118
Diseño e implementación de un protocolo peer-to-peer
Windows Server 2003 Web
128 MB
Edition
Windows Server 2003
Standard Edition
128 MB
Windows Server 2003
Enterprise Edition
128 MB
Windows Server 2003
DataCenter Edition
128 MB
AMD Opteron de 32 bits
Windows Server 2003,
AMD Opteron de 32 bits
128 MB
98 MB
AMD Opteron de 64 bits
Windows Server 2003
AMD Opteron de 32 bits
128 MB
110 MB
Intel de 32 bits
98 MB
Figura 2. Requisitos para sistemas Windows
Los requisitos para sistemas Linux son los que se describen a continuación.
PLATAFORMA
VERSIÓN
MEMORIA
Red Hat 9.0
Red Hat Enterprise
Linux AS 3.0
64 MB
Arquitectura Intel de 32 bits
64 MB
Red Hat Enterprise
Linux WS 2.1
64 MB
Red Hat Enterprise
Linux ES 2.1
64 MB
Arquitectura Intel de 32 bits Red Hat Enterprise
Linux AS 2.1
SuSE 8.2
SLEC 8
SLES 8
TurboLinux 8.0
ESPACIO EN DISCO
64 MB
58 MB
64 MB
64 MB
64 MB
64 MB
Sun Java Desktop
System versión 1
64 MB
Sun Java Desktop
System versión 2
64 MB
58 MB
AMD Opteron de 32 bits
Red Hat Enterprise
Linux AS 3.0
58 MB
AMD Opteron de 64 bits
SLES 8
Red Hat Enterprise
Linux AS 3.0
56 MB
SLES 8
Figura 3. Requisitos para sistemas Linux
119
Diseño e implementación de un protocolo peer-to-peer
2.2 REQUISITOS SOFTWARE
Para una correcta ejecución de la aplicación, los requisitos software son la
instalación del entorno de ejecución de Java 5.0 JRE (Java Runtime Environment) y del
gestor de bases de datos relacionales MySQL.
3. BASE DE DATOS
3.1 DRIVER MYSQL CONNECTOR/J
A través del driver Connector/J, MySQL proporciona conectividad para
aplicaciones cliente desarrolladas en el lenguaje de programación Java.
Este driver es del tipo JDBC (Java Database Connectivity) 4, lo que convierte las
llamadas JDBC directamente en el protocolo usado por el sistema gestor de bases de
datos. Este hecho permite llamadas directas desde la máquina del cliente al servidor
del gestor de bases de datos.
El uso de este tipo de driver aporta una serie de ventajas como las que se
describen a continuación
Independencia de la plataforma. Al utilizar un driver 100% Java, se consigue
una independencia de la plataforma utilizada.
Rapidez. Ya que no es necesario ningún tipo de traducción al lenguaje
soportado por el sistema gestor de bases de datos, la ejecución de las
sentencias es más rápida.
Facilidad de despliegue. Ya que no se utilizan librerías adicionales ni se
requiere la instalación de software intermediario, el despliegue es mucho más
sencillo.
El driver tipo 4, también denominado native-protocol all-Java, no requiere
instalación en los clientes y es suministrado por la aplicación en el archivo mysqlconnector-java-5.1.7-bin.jar.
Para más información visitar la página web http://dev.mysql.com/downloads
/connector/j/5.1.html
120
Diseño e implementación de un protocolo peer-to-peer
3.2 DEFINICIÓN DE TABLAS
A continuación se detallan las tablas y relaciones que componen la base de datos
de la aplicación.
TABLA EXTENSIONS.
- Descripción: contiene las extensiones de los archivos.
- Relación con: ninguna tabla.
-
Sentencia de creación: CREATE TABLE DELPHIC.EXTENSIONS(
EXTENSION VARCHAR(6) NOT NULL,
TYPE VARCHAR(8) NOT NULL,
PRIMARY KEY(EXTENSION)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
EXTENSIONS
PK
EXTENSION: varchar(6)
TYPE: varchar(8)
TABLA SHARES.
- Descripción: contiene los archivos de los usuarios conectados a la red.
- Relación con: ninguna tabla.
-
Sentencia de creación: CREATE TABLE DELPHIC.SHARES(
NAME VARCHAR(256) NOT NULL,
SIZE BIGINT NOT NULL,
HASH CHAR(40) NOT NULL,
EXTENSION VARCHAR(6) NOT NULL,
COUNTER INT NOT NULL DEFAULT 0,
PRIMARY KEY(NAME,HASH)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
121
Diseño e implementación de un protocolo peer-to-peer
TABLA CLIENTS.
- Descripción: contiene la información de los clientes conectados a la red.
- Relación con: COMMENTS.
- Sentencia de creación: CREATE TABLE DELPHIC.CLIENTS(
IP VARCHAR(15) NOT NULL,
HASH CHAR(40) NOT NULL,
NAME VARCHAR(256) NOT NULL,
PRIMARY KEY(IP,HASH)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
TABLA COMMENTS.
- Descripción: contiene los comentarios de los usuarios conectados a la red.
- Relación con: CLIENTS.
-
Sentencia de creación: CREATE TABLE DELPHIC.COMMENTS(
NCOMMENT INT NOT NULL AUTO_INCREMENT,
CLIENTIP VARCHAR(15) NOT NULL,
HASH CHAR(40) NOT NULL,
COMMENT VARCHAR(120),
EVALUATION TINYINT,
PRIMARY KEY(NCOMMENT),
INDEX (CLIENTIP,HASH),
FOREIGN KEY(CLIENTIP,HASH) REFERENCES
DELPHIC.CLIENTS(IP,HASH) ON DELETE
CASCADE)ENGINE=INNODB DEFAULT
CHARSET=latin1;
COMMENTS
PK
NCOMMENT: int
FK1,I1
FK1,I1
CLIENTIP: varchar(15)
HASH: char(40)
COMMENT: varchar(120)
EVALUATION: tinyint
122
Diseño e implementación de un protocolo peer-to-peer
4. INSTALACIÓN DE LA APLICACIÓN
El archivo de instalación se distribuye con la extensión jar. Si el sistema operativo
instalado reconoce esta extensión, pinchar repetidamente sobre el icono del archivo
para su ejecución. En caso de que el sistema operativo no reconozca este tipo de
extensión, será necesario asociar la extensión jar con el programa java.
5. ARCHIVO DE REGISTRO DE ERRORES
Para la gestión y el control de errores por parte de los administradores del
servidor, la aplicación dispone de un archivo de registro en el que se almacenan los
errores que se producen durante el proceso de registro de los clientes que se conectan
a él y durante el proceso de las búsquedas, tanto en la base de datos local como en la
red IP multicast.
La estructura de cada uno de los registros de error es la que se muestra a
continuación.
<DÍA_DE_LA_SEMANA,MES,DÍA,HORA,AÑO>
Descripción
del
error
<DIRECCIÓN_IP_CLIENTE>.
Figura 4. Fichero de registro de errores
123
Diseño e implementación de un protocolo peer-to-peer
6. ARCHIVOS DE LA APLICACIÓN
Los diferentes archivos que maneja la aplicación son lo que se detallan a
continuación.
Delphic.sql. Archivo que contiene las sentencias DDL (Data Definition
Language) para la creación de las base de datos y las sentencias DML (Data
Manipulation Language) para la inserción de los datos.
Mysql-connector-java-5.1.7-bin.jar. Archivo que contiene el driver del
sistema gestor de bases de datos, suministrado por MysqL AB.
Log.log. Archivo que contiene los errores que se producen durante el proceso
de registro de los clientes y durante el proceso de las búsquedas.
7. GLOSARIO DE TÉRMINOS
JRE. (Java Runtime Environment). Conjunto de utilidades que permiten la
ejecución de aplicaciones realizadas bajo el lenguaje de programación Java sobre todas
las plataformas soportadas.
Sistema gestor de bases de datos. Conjunto de utilidades que sirven de interfaz
entre la base de datos y las aplicaciones y el usuario y que sirven para definir, construir y
manipular los datos almacenados.
Driver. Conjunto de utilidades que permiten la comunicación entre la aplicación
y el sistema gestor de base de datos.
Connector/J. Driver implementado por MySQL AB que proporciona conectividad
a aplicaciones desarrolladas en el lenguaje de programación Java y el sistema gestor de
bases de datos MySQL.
JDBC. (Java Database Connectivity). Conjunto de clases e interfaces que
utilizadas para desarrollar aplicaciones Java de acceso a bases de datos que permiten
que la aplicación sea independiente del sistema gestor de base de datos. JDBC está
basado en X/Open SQL CLI.
124
Diseño e implementación de un protocolo peer-to-peer
DDL. (Data Definition Language). Lenguaje suministrado por el sistema gestor de
bases de datos que permite realizar tareas de definición de estructuras y objetos en la
base de datos.
DML. (Data Manipulation Language). Lenguaje suministrado por el sistema
gestor de bases de datos que permite realizar tareas de consulta y manipulación de
datos.
125