Protocolp 2 P

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

INGENIERO EN INFORMTICA
PROYECTO FIN DE CARRERA
DISEO E IMPLEMENTACIN DE UN
PROTOCOLO DE REDES
PEER-TO-PEER
LUIS MARA GARCA SANJUN

MADRID, JUNIO DE 2009
Autorizada la entrega del proyecto del alumno:
Luis Mara Garca Sanjun
EL DIRECTOR DEL PROYECTO
Jos Manuel Muoz Berengena
Fdo:
Fecha:
Vo Bo del Coordinador de Proyectos
David Contreras Brcena
Fdo:
Fecha:
UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)
INGENIERO EN INFORMTICA
PROYECTO FIN DE CARRERA
DISEO E IMPLEMENTACIN DE UN
PROTOCOLO DE REDES
PEER-TO-PEER
AUTOR: LUIS MARA GARCA SANJUN

DIRECTOR: JOS MANUEL MUOZ BERENGENA
MADRID, JUNIO DE 2009
A mi madre y a mi hermana.
Dicen que quien convive con lo que admira termina imitndolo, y la dedicacin y
entrega que mostris cada da en vuestro trabajo ha sido para m todo un ejemplo a
seguir, guindome hacia el ocaso de esta etapa.
AGRADECIMIENTOS
Mi ms sincero agradecimiento a Jos Manuel Muoz Berengena, mi director de
proyecto. Una vez terminado el trabajo, slo me queda decir gracias y perdn. Gracias
por todo el tiempo que me has dedicado, por tu ayuda e inagotable paciencia. Perdn
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 Brcena, mi coordinador de
proyecto, y a todos los profesores de la Escuela Tcnica Superior De Ingeniera de la
Universidad Pontificia Comillas de Madrid por su trabajo realizado durante estos aos
de carrera.
A Pilar Balda, Marta Galn y Marta Lozoya por ese da en el que os sentasteis a
mi lado, regalndome as la oportunidad de conoceros. Gracias por todo vuestro cario
y por los momentos que habis compartido conmigo.
Por ltimo, no quisiera olvidarme de mis amigos Beatriz, Juan y Julio. Aunque ya
sabis lo mucho que os quiero, no est de ms agradeceros el cmo 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, telefona por Internet, sistemas de ficheros distribuidos, clculo
cientfico y dems. Probablemente, la finalidad con ms uso sea la de bsqueda y
transferencia de archivos.
Haciendo uso de determinadas aplicaciones que cubren esta finalidad, se puede
comprobar que la bsqueda e intercambio de archivos de las actuales aplicaciones de
redes peer-to-peer estn 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 diseo e implementacin de un protocolo
peer-to-peer, que mejore el proceso de bsqueda de los archivos entre los usuarios
que se encuentren conectados a la red. Se entiende por mejora la eliminacin de la
dependencia del proceso de bsqueda al servidor al que el usuario se encuentre
conectado.
Para poder desarrollar el proyecto, es necesario que los servidores compartan la
misma informacin acerca de los archivos y de los clientes que se encuentran
conectados a la red peer-to-peer. Dado el gran nmero de clientes de este tipo de
redes, es inviable que un servidor albergue toda sta informacin, ya que manejara
una gran volumen de datos que adems estara duplicado en el resto de servidores.
Por este motivo, la arquitectura propuesta se basa en la conexin de todos los
servidores a una red IP multicast, para as poder distribuir la informacin 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 bsqueda de un
determinado archivo, enva una solicitud de bsqueda al servidor al que se encuentra
conectado. El servidor procesa la solicitud, realizando una consulta en su base de
datos, en la que estn registrados todos los archivos de los clientes con los que
mantiene una conexin. Al finalizar la consulta, transmite la solicitud de bsqueda 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
peticin. Una vez consultada la base de datos, se envan los resultados al servidor que
los solicit para aadir esos resultados a los que ya tena. Una vez terminado este
proceso, todos los resultados se envan al cliente que inici el proceso de bsqueda.
Dado que el proyecto realizado tiene caractersticas de un sistema distribuido, el
protocolo se ha implementado bajo el lenguaje de programacin Java, para asegurar la
portabilidad en entornos heterogneos, con hardware y sistemas operativos diversos.
El protocolo implementado aporta una serie de mejoras tanto en los servidores
como en los clientes. El nmero de archivos encontrados en el proceso de bsqueda, el
nmero de comentarios de los usuarios que califican los archivos y el nmero de
fuentes encontradas que tienen disponible el archivo para compartir son mayores, ya
que se elimina la dependencia de la conexin con el servidor. Dado que el nmero de
fuentes encontradas es mayor, se reduce considerablemente el tiempo de
transferencia del archivo, ya que la posibilidad de conexin a un mayor nmero 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 conexin, por lo que se le libera de una tarea innecesaria. Al eliminar
una preferencia de conexin entre un servidor u otro, las conexiones de los clientes
entre los distintos servidores de la red estn ms equilibradas y por lo tanto el reparto
de carga de trabajo entre estos y las solicitudes de bsqueda de un archivo entre los
usuarios de la red estarn ms equilibradas.
En el presente proyecto, se ha realizado un exhaustivo anlisis sobre los sistemas
actuales peer-to-peer de transferencia de archivos, detallando sus caractersticas,
funcionamiento y mejoras con respecto a otros sistemas y, conjuntamente, se ha
introducido el problema de las bsquedas de archivos en este tipo de redes. Sobre esa
IV
base, se ha realizado el diseo e implementacin de un protocolo independiente del

servidor al que el usuario se encuentre conectado.
El sistema desarrollado se podra enmarcar dentro de los sistemas peer-to-peer
estructurados, ya que se conoce la localizacin 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 bsqueda determinista, de tal forma que se
asegura la localizacin de un recurso siempre y cuando se encuentre en la red,
encaminando los mensajes de forma eficiente.
Con la realizacin de este proyecto, se suplen algunas carencias de las actuales
aplicaciones de bsqueda y transferencia de archivos en redes peer-to-peer, como es el
caso de la bsqueda de fuentes o de comentarios de un determinado archivo. Adems,
otras caractersticas y funcionalidades de estas aplicaciones se optimizan, como por
ejemplo la previsualizacin de los archivos en estado de descarga y la gestin del
espacio de los archivos temporales.
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. INTRODUCCIN .................................................................................................. 13
1.1. INTRODUCCIN 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. CLASIFICACIN 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. TECNOLOGAS ................................................................................................................. 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 TECNOLOGAS ACTUALES ........................................................................ 33
2.2.1. P2P ANNIMO ........................................................................................................ 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. MOTIVACIN Y OBJETIVOS DEL PROYECTO ......................................................... 36

4. ANLISIS DEL SISTEMA........................................................................................ 41
4.1. IDENTIFICACIN DE NECESIDADES ................................................................................. 42
4.1.1. ALCANCE DEL SISTEMA ........................................................................................... 42
4.1.2. TOPOLOGA DE USUARIOS FINALES ........................................................................ 43
4.1.3. RESTRICCIONES ....................................................................................................... 44
4.2. ANLISIS 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 DISEO .......................................................................................... 49
4.3. METODOLOGA ............................................................................................................... 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. DISEO DE LA BASE DE DATOS ............................................................................... 65
5. PROTOCOLO DEL SISTEMA .................................................................................. 68

5.1. PROTOCOLO ENTRE CLIENTE Y SERVIDOR ...................................................................... 69
5.1.1. SOLICITUD DE CONEXIN A LA RED PEER-TO-PEER ................................................ 69
5.1.2. SOLICITUD DE BSQUEDA DE ARCHIVOS................................................................ 69
5.1.3. SOLICITUD DE BSQUEDA DE COMENTARIOS ........................................................ 70
5.1.4. SOLICITUD DE BSQUEDA DE CLIENTES ................................................................. 70
5.1.5. SOLICITUD DE SINCRONIZACIN............................................................................. 71
IX
5.1.6. SOLICITUD DE DESCONEXIN DE LA RED PEER-TO-PEER ....................................... 72

5.2. PROTOCOLO ENTRE SERVIDORES ................................................................................... 72
5.2.1. SOLICITUD DE CONEXIN A LA RED MULTICAST .................................................... 72
5.2.2. SOLICITUD DE BSQUEDA DE ARCHIVOS................................................................ 73
5.2.3. SOLICITUD DE BSQUEDA DE COMENTARIOS ........................................................ 73
5.2.4. SOLICITUD DE BSQUEDA DE CLIENTES ................................................................. 74
5.3. PROTOCOLO ENTRE CLIENTES......................................................................................... 75
6. PROGRAMACIN Y PRUEBAS DEL SISTEMA ......................................................... 77

6.1. PROGRAMACIN............................................................................................................. 78
6.1.1. INTRODUCCIN....................................................................................................... 78
6.1.2. LENGUAJES DE PROGRAMACIN ............................................................................ 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 INTEGRACIN .................................................................................... 80
6.2.3. PRUEBAS DE EXPLOTACIN DEL SISTEMA .............................................................. 80
6.2.4. PRUEBAS DE SOBRECARGA ..................................................................................... 80
6.2.5. PRUEBAS DE RECUPERACIN.................................................................................. 80
6.2.6. PRUEBAS DE SEGURIDAD ........................................................................................ 81
6.2.7. PRUEBAS DE USABILIDAD ....................................................................................... 81
6.2.8. PRUEBAS DE ACEPTACIN DEL USUARIO ............................................................... 81
7. PLANIFICACIN DEL PROYECTO........................................................................... 82

8. VALORACIN ECONMICA DEL PROYECTO ......................................................... 85
8.1. COSTES DE TECNOLOGA ................................................................................................. 86
8.1.1. COSTES DE HARDWARE........................................................................................... 86
8.1.2. COSTES DE SOFTWARE ............................................................................................ 86
8.2. COSTES DE IMPLANTACIN ............................................................................................ 87
8.3. VALORACIN FINAL......................................................................................................... 89
9. CONCLUSIONES Y FUTURAS LNEAS DE DESARROLLO........................................... 90

BIBLIOGRAFA Y REFERENCIAS ................................................................................ 94
ANEXO I. MANUAL DE USUARIO DE LA APLICACIN CLIENTE................................... 98
ANEXO II. MANUAL DE USUARIO DE LA APLICACIN SERVIDOR ............................ 115
TABLA DE FIGURAS
IDENTIFICADOR
DESCRIPCIN
PGINA
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 conexin con el servidor 212.63.206.35
Resultados en la conexin 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 aplicacin cliente
Capas de la aplicacin servidor
Diagrama de dominio del sistema
Diagrama de casos de uso del usuario de la aplicacin 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 conexin a la red P2P
Solicitud de bsqueda de archivos
Solicitud de bsqueda de comentarios
Solicitud de bsqueda de comentarios
Solicitud de sincronizacin de archivos
Solicitud de desconexin a la red P2P
Solicitud de conexin a la red IP multicast
Solicitud de bsqueda de archivos a la red IP multicast
Solicitud de bsqueda 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
DESCRIPCIN
PGINA
Figura 41
Figura 42
Figura 43
Figura 44
Figura 45
Figura 46
Figura 47
Figura 48
Figura 49
Figura 50
Figura 51
Solicitud de bsqueda de direcciones IP a la red IP multicast

Solicitud de transferencia de un parte del archivo
Sincronizacin de transferencia de un parte del archivo
Costes de hardware
Costes de software
Costes de tecnologa
Estimacin del esfuerzo de los integrantes del proyecto
Costes de implantacin
Costes de desarrollo del proyecto
Planificacin del proyecto
Planificacin de la etapa de desarrollo e implementacin
74
75
76
83
83
84
85
86
86
88
89
XII
Captulo 1
Introduccin
Diseo e implementacin de un protocolo peer-to-peer
1.1 INTRODUCCIN A LAS REDES PEER-TO-PEER

1.1.1 REDES PEER-TO-PEER
Debido a un notable crecimiento en el nmero de equipos conectados a Internet,
una mayor capacidad de almacenamiento de stos y un rpido incremento del ancho
de banda disponible, ha surgido una enorme difusin 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 ms comnmente P2P.
Una red peer-to-peer, en adelante P2P, es un conjunto de equipos conectados
por medio de un mtodo de transporte de datos en el que se comparten recursos y en
el que no estn definidos ni clientes ni servidores fijos. Se puede decir que los equipos
conectados a la red se comportan, simultneamente 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 ms servidores. En
este tipo de arquitectura, segn se aaden ms usuarios a la red, la tasa de
transferencia1 disminuye ya que los recursos de los que dispone el servidor se

consumen debido al intenso trfico. 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 continuacin.
Escalabilidad. El alcance de las redes P2P es mundial, con un gran nmero de
usuarios potenciales. A diferencia de las redes basadas en una arquitectura
cliente-servidor, cuantos ms usuarios estn conectados a la red, mayor
rendimiento se obtiene.
Descentralizacin. Por definicin, estas redes son descentralizadas y los
usuarios se comportan, simultneamente como clientes y servidores, lo que
hace que ningn 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 caracterstica menos implementada, aunque existen
mecanismos de cifrado de clave, comunicaciones seguras, gestin de
derechos de autor, firmas digitales y dems mtodos de seguridad.
El trmino tasa de transferencia se refiere al nmero de bits que se transmiten durante un tiempo
determinado entre dos dispositivos digitales. Mide la velocidad de transferencia de datos.

Anonimato. Aunque es deseable que queden en anonimato el autor de un
contenido, el editor, el lector, el servidor que lo alberga y la peticin para

encontrarlo, esta caracterstica es incompatible con los derechos de autor, por
lo que se proponen mecanismos de limitacin 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 lgico,
capaz de llevar a cabo una tarea encomendada y comunicar los resultados de la
ejecucin 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, proporcionndole servicios y demandndolos
a otros pares de la red. Los segundos gestionan el trfico recibiendo solicitudes de
bsqueda 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 inters comn, sealado 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 comunicacin de los mismos. Esta funcionalidad
cubre una larga lista de diferentes finalidades, entre las que se encuentran la bsqueda
y transferencia de archivos, la telefona por internet y los clculos de carcter
cientfico.
El trmino DRM (Digital Rights Management) se refiere al conjunto de tecnologas de control para la
limitacin del uso de medios o dispositivos digitales. Tambin se puede referir a las restricciones
asociadas a instancias especficas de obras digitales o dispositivos.
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 continan 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 bsqueda y control se realizan a travs
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 informacin de los
archivos que tiene cada cliente, actualizndola cada vez que un cliente se conecta o
desconecta. Cada solicitud de bsqueda es comparada en servidor central con la
informacin 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 administracin dinmica, una
disposicin ms permanente de los recursos y un elevado rendimiento en la
localizacin 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.
El trmino escalabilidad se refiere a una propiedad deseable en un sistema, que indica su habilidad
para poder hacerse ms grande sin perder calidad en sus servicios.
4
El trmino robustez se refiere a una propiedad deseable de un sistema, que indica su habilidad para
poder funcionar o continuar funcionando correctamente bajo situaciones inesperadas.
Figura 3. Modelo centralizado
El modelo totalmente descentralizado o puro se caracteriza porque no existe un

servidor central, cada nodo acta como cliente y como servidor, tratando de mantener
un cierto nmero 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 ms verstiles y robustas al no
depender de un servidor central, no obstante, el elevado tiempo y la sobrecarga de
ancho de banda que suponen las bsquedas de informacin 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
El modelo semicentralizado o mixto es el ms extendido entre las arquitecturas

de redes P2P. En este modelo, se seleccionan ciertos nodos para que cumplan la
funcin de superpares y as ayudar a encaminar el trfico hacia otros pares. Los
superpares cambian dinmicamente a medida que otros clientes se conectan a la red.
Cada par mantiene un nmero 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 nmero de nodos implicados en el proceso de encaminamiento, y disminuir
el volumen de trfico entre estos. Algunos ejemplos de redes que se basan en este
modelo son eDonkey y BitTorrent.
Figura 5. Modelo semicentralizado
1.1.4 CLASIFICACIN DE LAS REDES PEER-TO-PEER

La clasificacin ms 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 estn situados en
pares precisos. Cada nodo de la red cuenta con su propia tabla hash5, el lugar en el que
El trmino tabla hash se refiere a una estructura de datos que asocia claves con valores, cuya operacin
fundamental es la bsqueda, permitiendo el acceso a los valores almacenados a partir de una clave
generada.
est cada recurso es calculado mediante una funcin hash6 aplicada sobre la tabla, la
cual indica que par de la red conoce la localizacin del recurso. Algunos ejemplos de
este tipo de redes son Pastry, CAN y Chord.
Este tipo de redes proporcionan un mecanismo de bsqueda determinista, de tal
forma que asegura la localizacin de un recurso siempre y cuando se encuentre en la
red. Adems los mensajes de bsqueda son encaminados de forma eficiente, de tal
forma que el recurso es encontrado en saltos, donde es el tamao de la
red. Sin embargo, estas redes son ineficientes para realizar bsquedas por palabras
clave, ya que el usuario debe conocer el nombre exacto del recurso para poder aplicar
la funcin hash y as poder enrutar la bsqueda de forma eficaz. Adems 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 nmero
de mensajes de sincronizacin, lo que puede dar lugar a un colapso de la red.
En las redes P2P no estructuradas, la localizacin de los recursos no est
determinada en pares concretos, sino que a cada nodo se le asignan enlaces
arbitrariamente. No existe garanta alguna de encontrar el recurso, aunque ste est
en la red, ya que la bsqueda no es determinista. Un ejemplo de este tipo de redes es
Gnutella.
Existen distintos mecanismos de bsqueda dentro de las redes no estructuradas,
pero los ms utilizados son el de inundacin y el de paseos aleatorios. En el primero,
cuando un nodo recibe un mensaje de solicitud de bsqueda de un recurso, si no
conoce el recurso buscado, reenva el mensaje a todos los pares con los que tiene una
conexin. El inconveniente de este mtodo de bsqueda es que introduce mucho
trfico en la red. En el segundo mecanismo, los mensajes no se envan a todos los
pares con los que se tiene conexin, sino que slo es enviado a uno ellos elegido
aleatoriamente. El alcance del mensaje est limitado por medio de la utilizacin de un
El trmino funcin hash se refiere a un algoritmo para la generacin de claves que representen de
forma unvoca un determinado valor.
mecanismo basado en TTL7 (Time To Live). Este mtodo introduce mucho menos
trfico en la red que el primero, sin embargo, reduce la probabilidad de encontrar el
recurso debido a la limitacin de la distribucin del mensaje de bsqueda.
Aunque no se han detallado, existen muchas ms clasificaciones de las redes
P2P, atendiendo a su generacin y a sus caractersticas de anonimidad.
1.1.5 APLICACIONES DE REDES PEER-TO-PEER
Aunque, como se ha detallado anteriormente, una mayor capacidad de
almacenamiento y un rpido 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 aplicacin de estas redes son los siguientes.
Sistemas de intercambio de archivos. Posiblemente sea la aplicacin ms
extendida en este tipo de redes. Los propsitos de este tipo de aplicacin son
muy variados, desde el uso particular hasta el mbito educativo. Algunos
ejemplos son LionShare, eDonkey2000 y BitTorrent.
Sistemas de telefona por Internet. Sistemas basados en VoIP8 (Voice over
Internet Protocol) que permite la transmisin en tiempo real de seales de voz
por la Red. Algunos ejemplos de este tipo de aplicacin son Skype y Gizmo5.
Sistemas de archivos distribuidos. Sistema de datos distribuido en los que la
informacin se almacena en nodos de la red y se permite el acceso de otros
pares a la misma. Algunos ejemplos de este tipo de aplicacin son Freenet y
CFS.
Sistemas de P2PTV. Sistemas para la transmisin y difusin de contenidos
audiovisuales a travs de Internet. En este tipo de sistemas, los nodos se
El trmino TTL (Time To Live) se refiere al nmero de veces que puede ser enrutado un paquete antes de
ser descartado o devuelto al origen.
8
El trmino VoIP (Voice over Internet Protocol) se refiere al conjunto de recursos que hacen posible
enviar la voz en forma digital a travs de Internet, utilizando para ello el protocolo IP.
conectan a sus pares para recibir los streams9 de video y audio, en lugar de
conectarse con un servidor central en la televisin basada en IP (Internet
Protocol), IPTV10 (Internet Protocol Television). Algunos ejemplos de este tipo
de aplicacin son SopCast y CoolStreaming.
Sistemas de clculo cientfico. Sistemas que tienen que manejar grandes
cantidades de datos y tienen una gran carga computacional, como es el caso
de sistemas de administracin autnoma para la bioinformtica. Un ejemplo
de este tipo de aplicacin 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 bsqueda de los nodos. El problema de encontrar un par que
se encuentre conectado a la red P2P es, comnmente, solucionado realizando una
conexin con un servidor, en el que la direccin 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 conexin de pares sin direccin IP pblica. La solucin
que se suele aplicar es la conexin de otro nodo que cumple la funcin de proxy11. El
resto de los pares se conectan a este proxy el cual enva la informacin que llega de
uno al otro. Cualquier nodo que est conectado a la red P2P y tenga una direccin IP
pblica puede ser elegido para que cumpla con el cometido de proxy. En este caso, es
de implementacin obligatoria el desarrollo de mecanismos de seguridad para evitar
que los proxies puedan acceder a la informacin que se comunican dos pares de la red.
El trmino stream se refiere a un elemento software que permite un flujo de informacin entre un
origen y un destino.
10
El trmino IPTV (Internet Protocol Television) se refiere a una tecnologa basada en video streaming de
distribucin de seales de televisin y video, que usa conexiones de banda ancha sobre el protocolo IP.
11
El trmino proxy se refiere a un dispositivo de red que realiza una accin en representacin de un
equipo perteneciente a esa red. Su finalidad ms usual es permitir el acceso a Internet a todos los
equipos de una organizacin.
10
1.2 TECNOLOGAS
En este apartado se realizar una breve explicacin sobre las principales
tecnologas del proyecto y el motivo de su eleccin.
1.2.1 JAVA
Java fue desarrollado en 1990 por Sun Microsystems, como parte de un proyecto
de investigacin para el desarrollo de una amplia variedad de dispositivos de red, con
el fin de que fuera independiente de la arquitectura del dispositivo. El propsito era
crear una nueva plataforma operativa que, adems de ser independiente de la
arquitectura del dispositivo, fuera sencilla, portable, fiable, distribuida y en tiempo
real. Este lenguaje de programacin toma mucha de su sintaxis de otros lenguajes
como C, C++, Eiffel y SmallTalk, pero el modelo de objetos que utiliza es ms 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 caractersticas principales de Java [MUO04] son las que se muestran a
continuacin.
Sencillo, orientado a objetos y familiar: Sencillo, para que no requiera
grandes esfuerzos de entrenamiento para los desarrolladores. Orientado a
objetos, porque la tecnologa de objetos se considera madura y es el enfoque
ms adecuado para las necesidades de los sistemas distribuidos y clienteservidor. Familiar, porque aunque se rechaz C++, se mantuvo Java lo ms
parecido posible a C++, eliminando sus complejidades innecesarias, para
facilitar la migracin al nuevo lenguaje.
Robusto y seguro: Robusto, simplificando la gestin de memoria y eliminando
las complejidades de la gestin explicita de punteros y aritmtica de punteros
de C. Seguro para que pueda operar en un entorno de red.
Independiente de la arquitectura y portable: Java est diseado para
soportar aplicaciones que sern instaladas en un entorno de red heterogneo,
11
con hardware y sistemas operativos diversos. Para hacer esto posible el

compilador Java genera bytecodes, un formato de cdigo independiente de la
plataforma diseado para transportar cdigo eficientemente a travs de
mltiples plataformas de hardware y software. Es adems portable en el
sentido de que es rigurosamente el mismo lenguaje en todas las plataformas.
El bytecode es traducido a cdigo mquina y ejecutado por la Mquina Virtual
Java, que es la implementacin 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 optimizacin. Cuando se necesitan capacidades de
proceso intensivas, pueden usarse llamadas a cdigo nativo.
Interpretado, multi-thread y dinmico: El intrprete Java puede ejecutar
bytecodes en cualquier mquina que disponga de una Mquina Virtual Java.
Adems Java incorpora capacidades avanzadas de ejecucin multi-thread,
ejecucin simultnea de ms de un flujo de programa, y proporciona
mecanismos de carga dinmica de clases en tiempo de ejecucin.
Dado que el presente proyecto tiene caractersticas de un sistema distribuido,
ste ha de ser independiente tanto del hardware como del sistema operativo en el que
se ejecute. Adems la arquitectura planteada se ajusta muy bien a las caractersticas
anteriormente mencionadas, sencillez, robustez, multi-thread y dems, por lo que la
eleccin de Java como lenguaje de implementacin es la ms indicada para la
implementacin del proyecto.
1.2.2 MYSQL
MySQL es un sistema de gestin de bases de datos relacionales desarrollado por
David Axmark y Michael Widenius y actualmente distribuido por la compaa comercial
MySQL AB. Actualmente, segn las cifras de la pgina del proyecto, existen ms 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 ms utilizados. MySQL es
muy utilizado en aplicaciones web, ya que es un sistema gestor muy rpido en la
12
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 trfico, como Google, Amazon y YouTube entre
otros, utilicen este sistema gestor para el almacenamiento y recuperacin de datos as
como para el proceso de autenticacin de los usuarios.
MySQL est escrito en los lenguajes de programacin C y C++, utilizando yacc
como analizador gramatical de SQL (Structured Query Language). Adems 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. Tambin existe un interfaz ODBC12 (Open
Database Connectivity), llamado MyODBC que permite a cualquier lenguaje de
programacin que soporte ODBC comunicarse con las bases de datos MySQL.
Las principales caractersticas 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
programacin para aplicaciones. Tambin proporciona MySQL Server como
biblioteca incrustada multi-thread, la cual se puede lincar en cualquier tipo de
aplicacin para obtener un producto ms pequeo, rpido y fcil de
administrar.
Rpido, fiable y fcil de usar. MySQL Server se desarroll originalmente para
tratar grandes bases de datos mucho ms rpido que soluciones existentes y
ha sido usado con xito en entornos de produccin de alto rendimiento
durante varios aos. MySQL Server ofrece hoy en da una gran cantidad de
12
El trmino ODBC (Open Database Connectivity) se refiere a un estndar de acceso a bases de datos
desarrollado por Microsoft con el objetivo de hacer posible la comunicacin entre una aplicacin y el
sistema gestor de bases de datos.
13
El trmino backend se refiere a un tipo de abstraccin que engloba las diferentes partes finales de un
sistema o proceso.
13
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 cdigo 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 aadir cdigo MySQL en
una aplicacin comercial, se puede adquirir una licencia de tipo privativa.
Tras la descripcin detalla de las caractersticas, se puede apreciar que el sistema
gestor de bases de datos relacionales MySQL es una de las mejores propuestas
tecnolgicas, ya que las caractersticas se ajustan a los requisitos del proyecto, tales
como multi-thread, rapidez y fiabilidad. Adems MySQL est bajo licencia GPL, un valor
aadido al producto final que hoy en da es bastante valorado en algunos proyectos.
14
Captulo 2
Estado del Arte de
las Aplicaciones
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 bsqueda e intercambio
de archivos, el siguiente estudio del estado del arte slo afecta a aquellas aplicaciones
cuya finalidad es la anteriormente mencionada.
El sistema global de discusin en Internet Usenet, fue unos de los primeros
sistemas de comunicacin 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, sostenindose gracias a
un gran nmero de servidores distribuidos y actualizados mundialmente que
almacenan y transmiten los mensajes. El gran nmero de usuarios y grupos, la escasez
de recursos requeridos, la velocidad, el anonimato, su libre acceso y su
descentralizacin, entre otros, hacen de Usenet la mayor red de intercambio de
informacin y debate del mundo. Tambin 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 aplicacin P2P conocida, desarrollada en el ao 1996 por Adam
Hinkley para Mac OS, fue Hotline Connect, ms conocida simplemente como Hotline, y
se basaba en la librera AppWarrior que el propio Hinkley haba implementado
anteriormente. Distribuida por Hotline Communications, pretenda ser una plataforma
de distribucin 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 distribucin.
14
El trmino UUCP (Unix to Unix Copy) se refiere a un conjunto de programas y protocolos que permiten
la ejecucin remota de comandos y transferencia de archivos, emails y netnews entre los ordenadores de
una red.
16
Hotline se distribua 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 tena que cancelar y empezar de nuevo desde otro servidor del
cual seguir descargando el archivo, ya que no exista ningn otro lugar del cual
descargar el archivo.
Existen varias versiones open source de Hotline que no se basan en el cdigo
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
continuacin.
Hotline Client. La aplicacin que se utilizaba para poder acceder a los usuarios
que ejecutaban la aplicacin servidora conociendo la direccin IP de estos.
Hotline Server. La aplicacin que ejecutaban los clientes para gestionar el
acceso a los recursos.
Hotline Tracker. Un servidor de nombres que mantena las direcciones IP de
los clientes que ejecutaban la aplicacin servidora.
Figura 6. Arquitectura de Hotline Connect

15
El trmino shareware se refiere a un tipo de distribucin de aplicaciones en la que el usuario puede

evaluar el software de forma gratuita y durante un tiempo determinado.
17
El problema de la dependencia de las descargas al servidor al que el usuario se

encontrara conectado y la dependencia de la ejecucin de la aplicacin en sistemas
MAC, una plataforma minoritaria en aquel tiempo, motiv la aparicin de Napster.
Napster fue desarrollado por Shawn Fanning y ofreca un servicio de distribucin
de archivos de msica en formato MP3 (MPEG-1 Audio Layer 3), que facilitaba la
bsqueda de estos por medio de la centralizacin, en lugar de buscar en IRCs o en
buscadores de Internet.
Fue el primer sistema P2P de distribucin 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 ningn
tipo de intermediario. Aunque hubo varias redes que facilitaban la distribucin de
archivos a travs del Internet, Napster se especializaba directamente en msica, en
archivos de formato MP3, presentados a travs de una interfaz amigable al usuario. El
resultado fue un sistema cuya popularidad gener una enorme seleccin de msica
para descargar. El servicio y programa eran inicialmente slo para plataformas
Windows, pero en el 2000 Black Hole Media realiz un cliente llamado Macster para
sistemas Mac.
Figura 7. Arquitectura de Napster

18
El hecho de que Napster fuera un servicio centralizado result su perdicin ya

que varias discogrficas estadounidenses demandaron a Napster, reclamando su cierre
a la RIAA16 (Recording Industry Association of America). A pesar de la clausura del
servicio, existan ya bastantes alternativas, como servidores no oficiales, OpenNap, y
una gran variedad de aplicaciones como Winmx e iMesh. Despus se estableci
Audiogalaxy como el sistema P2P ms utilizado por los usuarios de Internet, otra
aplicacin centralizada de intercambio de msica, que acab clausurada tambin 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, tambin 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
informacin de los usuario y de los archivos, pero ninguno de estos era central, por lo
que en caso de fallo otro servidor poda seguir ofreciendo el servicio, incluso los
usuarios de las red podan crear sus propios servidores.
Los elementos de la red eDonkey son los que se detallan a continuacin.
Servidores. Utilizacin de servidores para conectar a los clientes.
Metadatos. Envo de metadatos de un archivo justo en el momento de enviar
la informacin de los archivos compartidos al servidor.
Enlaces. Utilizacin de enlaces llamados elinks o ed2k links para permitir la
identificacin, por medio de una funcin hash, de un archivo o un servidor en
el navegador del cliente y transferirlo a la aplicacin. La estructura tpica de
los
enlaces
para
identificar
un
archivo
es
la
siguiente.
ed2k://|file|NOMBRE.EXTENSIN|TAMAO|HASH|. Opcionalmente se poda
16
El trmino RIAA (Recording Industry Association of America) se refiere a una asociacin americana que
representa a la industria discogrfica.
19
aadir al final del enlace la referencia a la direccin IP y el puerto del cliente

que comparta el archivo /|sources, DIRECCIN_IP:PUERTO|/. La estructura tpica
de
los
enlaces
para
identificar
un
servidor
es
la
siguiente.
ed2k://|server|IP|PUERTO|/
Deteccin de errores. Divisin 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 raz o root, para comprobar los
datos transmitidos y evitar la corrupcin 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 bsquedas, el cliente enva la peticin
al servidor, el cual se encarga de buscar el archivo en la informacin que los clientes le
proporcionaron durante el handshake. Cuando la peticin es aceptada, el servidor
establece una conexin entre los dos clientes y comienza la descarga.
Figura 8. Arquitectura de eDonkey

17
El trmino algoritmo MD4 se refiere a un algoritmo de funcin hash diseado Ronald Rivest para el uso
en comprobaciones de integridad de mensajes que produce un identificador de 128 bits.
20
Ya que la red eDonkey estaba basada en servidores administrados por los

usuarios, estos podan ser objeto de trfico pesado y, por consiguiente, ms
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
infraccin de los derechos de propiedad intelectual. La compaa dej de distribuir su
software y acord pagar una compensacin 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
continuacin.
NOMBRE
REDES
ANNIMO
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
Cdigo
cerrado
Windows
Desconocido
Figura 9. Clientes eDonkey
21
NOTA: En la tabla anterior no se han incluido todos los mods, modificaciones de

los clientes con respecto a su original, ya que el tamao de la tabla habra aumentado
considerablemente.
Paralelamente al cliente eDonkey, exista 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 ms 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 librera
Microsoft Foundation Classes y se encuentra bajo licencia GPL.
Las caractersticas de eMule son las que se detallan a continuacin.
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 cdigo libremente. Por este motivo han
proliferado toda una serie de modificaciones, mods, del programa original,
como eMule Plus o eMule MorphXT.
Deteccin de errores y recuperacin de partes. Se utiliza algoritmos de
deteccin 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. Adems el sistema AICH (Advanced Intelligent Corruption
22
Handling) utiliza el mtodo 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 transmisin.
Transferencias comprimidas. Cada vez que eMule transmite datos, estos se
comprimen con la librera 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 coleccin. Se permite crear archivos en un formato especial
llamado coleccin. Este tipo de archivo contiene un conjunto de enlaces de
eMule, dando la posibilidad de bajarlo como un conjunto y guardar toda la
coleccin de archivos como un conjunto, aunque cada descarga se gestiona
independientemente.
Previsualizacin archivos multimedia. Se permite la visualizacin de diversos
tipos de archivos, como audio y vdeo, aunque el archivo no se haya
descargado completamente, siempre que el usuario tenga instalado un
reproductor multimedia.
Mensajera instantnea. 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 informacin sobre lo que interese a los usuarios.
Adems de las caractersticas anteriores, eMule se distingue por la utilizacin de
un sistema de crditos por el cual los usuarios que ms archivos aporta a la red, ms
rpido avanzan en las colas de descarga de un archivo. Es la forma de recompensar,
mediante un algoritmo meritocrtico, a los usuarios que aportan recursos a la red. El
sistema de gestin 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 crditos proporciona un
18
El trmino 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
ratio de modificacin al algoritmo de gestin de la cola de descarga, en funcin de la

cantidad de datos transferidos entre dos clientes. Los crditos se almacenan en cada
usuario para evitar que sean modificados, con la problemtica de que nicamente se
obtendrn crditos en los usuarios en los que se haya transferido un archivo.
La expresin de clculo que utiliza el sistema de crditos est compuesta por dos
ratios [MONK03].

1
2

2
2
Al terminar el clculo, ambos ratios son comparados y el sistema de crditos
elige el menor como ratio de modificacin al algoritmo de gestin de la cola de
descarga. Existen tres restricciones a este clculo, que son las siguientes.
El ratio de modificacin al algoritmo de gestin de colas es un nmero entre 1
y 10.
Si el total subido es menor que 1 MB, entonces el ratio de modificacin
permanece a 1.
Si el cliente no ha descargado nada, el ratio de modificacin es fijado a 10.
Una excepcin a esta regla se aplica slo cuando un par es asignado como amigo
despus de la agregacin a la lista de amigos del cliente. Esto automticamente asigna
una posicin en la cola de descarga para que se pueda comenzar a descargar,
independientemente de la calificacin de los anteriores ratios. Slo se puede reservar
una posicin para un amigo, para impedir cualquier forma de abuso.
Otra de las caractersticas de distincin es la ofuscacin del protocolo. Esta
funcin evita que las conexiones sean detectadas y, posteriormente, bloqueadas por
los ISPs (Internet Service Provider). La ofuscacin del protocolo es una caracterstica
que hace que eMule encubra su protocolo al comunicarse con un servidor u otros
clientes. Sin ofuscacin, cada comunicacin de eMule tiene una estructura
predeterminada que puede ser fcilmente identificada por un packet sniffer, programa
24
de captura de las tramas de red. Si se activa el modo ofuscado, toda la comunicacin

simula estar compuesta de datos aleatorios y ya no es posible realizar una
identificacin. Esto ayuda en situaciones en las que, mediante identificacin de
paquetes, el protocolo eMule es bloqueado. No hay que confundir el modo ofuscado
con un modo que proporciona anonimato.
Para la identificacin de archivos, estos tienen asignado un valor mediante una
funcin hash, que identifica de forma unvoca 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. Adems, 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 funcin hash MD4 a la concatenacin de los valores hash
de todas sus partes. En los elinks es imprescindible especificar el hash del archivo y
tambin su tamao correcto.
Como se ha detallado anteriormente, eMule dispone de dos redes, una red
basada en servidores eDonkey y una descentralizada, denominada Kad. A continuacin
se explica el funcionamiento de cada una de ellas.
Para conectarse a la red de servidores, es necesario conocer la direccin 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 bsquedas ms precisas y extensas y encontrar servidores
ms rpidos.
La red Kad es una red totalmente descentralizada, que usa una variante del
protocolo Kademlia y diseada para que eMule pueda mantenerse activo tras una
posible cada de la red de servidores. Para conectarse a esta red hay que conocer la
direccin IP de otro par, pero es posible conectarse a partir de los pares obtenidos de
la red de servidores. Cada par conoce una pequea parte de la red, de manera que el
tamao de la red puede crecer tanto como haga falta sin afectar al rendimiento.
25
Cuando un nodo se conecta, almacena los identificadores de los archivos que

quiere compartir con otros pares, escogidos en funcin 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 bsqueda por nombre funciona de una manera parecida, guardando el
nombre del archivo dentro de otros nodos escogidos en funcin de cada palabra del
nombre. Una bsqueda 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.
Bsquedas 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 estn comunicndose
continuamente entre ellos puede producir una mayor carga en mquinas.
Como alternativa a eMule, en Abril del 2001 apareci el protocolo BitTorrent,
desarrollado por Bram Cohen y liberada la primera implementacin en Julio del 2001
[COHE01], actualmente mantenido por la empresa BitTorrent.
BitTorrent es un protocolo P2P de transferencia de archivos ms comunes para
transferir archivos grandes, algunas estimaciones otorgan la cantidad total de
contenido compartido actualmente en ms de 1,4 PB [ISOH08].
26
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 comnmente 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
pequeo archivo con extensin .torrent. Este archivo es esttico, por lo que a menudo
se encuentra en pginas web o incluso se distribuye por correo electrnico. El archivo
.torrent contiene la direccin de un servidor de bsqueda, o tracker, el cual se encarga
de localizar posibles fuentes. Este servidor realmente se encuentra centralizado y
provee estadsticas acerca del nmero de transferencias, el nmero de nodos con una
copia completa del archivo y el nmero de nodos que poseen slo 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 bsqueda 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 distribucin de este ya
que a medida que ms pares se descarguen el archivo, la probabilidad de xito de la
descarga y la velocidad de la misma aumentan.
27
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 mtodo produce importantes
mejoras en la velocidad de transferencia cuando muchos usuarios se conectan para
bajar un mismo fichero. Cuando no existan ya ms nodos conectados al servidor de
bsqueda 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 polticas que los
clientes usan para determinar a qu par enviar los datos. Los clientes pueden preferir
enviar datos a los pares que les han envan anteriormente datos que a los nuevos
pares que se han aadido al enjambre, sta estrategia se conoce con el nombre tit for
tat19. Para contrarrestar este efecto, el cliente BitTorrent utiliza un mecanismo, segn
el cual el cliente se reserva un porcentaje de su ancho de banda disponible para el
envo de bloques a pares tomados al azar, con la finalidad de garantizar que pares
nuevos puedan unirse al enjambre [AMIL06].
19
El trmino tit for tat se refiere a un estrategia en teora 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
Los archivos que se distribuyen entre los pares son tratados en bloques,
normalmente, de entre 32 KB y 4 MB. El par aplica una funcin hash, usando el
algoritmo SHA120, y almacenndolo en el archivo torrent. Cuando otro par recibe un
bloque del archivo que se est descargando, se le aplica la funcin hash, y el valor
obtenido es comparado con el almacenado, para comprobar que se encuentra libre de
error. El valor de comprobacin que se encuentra contenido en el archivo torrent,
depende de la versin del protocolo BitTorrent utilizado. Por convencin, los archivos
torrent tiene un apartado llamado anuncio, en el cual se especifica la URL (Uniform
Resource Locator) del servidor de bsqueda, y una seccin de informacin, la cual
contiene los nombres de los archivos, sus tamaos, longitud, y el valor hash SHA1 por
cada uno de los bloques. Toda esta informacin es usada por los clientes para verificar
la integridad de los datos recibidos.
Una vez creado el archivo torrent, este es publicado en algn sitio web o en otra
parte, y registrado en el servidor de bsqueda. El servidor de bsqueda mantiene una
lista de clientes que se encuentran participando sobre el archivo torrent.
Alternativamente, en un sistema descentralizado, cada par acta como un servidor de
bsqueda, caracterstica implementada por clientes como Torrent, BitComet y
KTorrent a travs de mtodos 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 continuacin.
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
comnmente con el nombre de leecher o sanguijuela. Si un nmero considerable de
20
El trmino algoritmo SHA1 se refiere a un algoritmo de funcin hash diseado 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
usuarios siguen esta conducta, el nmero 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
obtendrn 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 basndose en el cdigo original, disponibles
en cualquier plataforma e implementados en una larga lista de lenguajes de
programacin. El cliente oficial de BitTorrent, BitComet, Vuze y Torrent son los ms
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
continuacin.
NOMBRE
PLATAFORMA
LENGUAJE
TRACKER
ADMITE
DHT
TORRENTS
ACTIVOS
ABC
Windows Linux
Python
No
No
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
No
C++
C++
No
No
S
S
8
8
C#
Desconocido
30

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
No
No
No
S
8
10
Integrado
Sin lmite
Integrado
Figura 12. Clientes BitTorrent
NOTA: En la tabla anterior no se han incluido todos los clientes, ya que el tamao
de la tabla habra aumentado considerablemente. Slo se han mostrado los ms
populares.
El sistema de ms reciente aparicin ha sido Omemo, un sistema de
almacenamiento virtual distribuido open source, basado en tablas de hash distribuidas,
distribuido por la firma espaola 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 estn accesibles para el resto de la red. Omemo
ofrece muchas ms novedades, tantas que sus creadores lo denominan P2P 2.0.
Las caractersticas 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
Rpido. 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
destruir
carpetas
para
organizar
categricamente los archivos. El estado actual del disco es el resultado

democrtico de los cambios que todos los usuarios van haciendo sobre l.
Annimo. No hay forma de conocer quin es el usuario que publica un
archivo, ni quin lo descarga. El diseo lgico 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 bsqueda 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, despus se cifran los
fragmentos y antes de lanzarlo a la red se les asigna un identificador que permite al
sistema su posterior rastreo y recomposicin en el archivo original. Estas medidas de
seguridad hacen de Omemo el programa de intercambio ms annimo y refractario a
la censura. No existe, actualmente, forma alguna de conocer quin ha subido un
determinado archivo y quin 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 combinacin de
votos negativos y positivos hace que unos archivos suban de puntuacin y otros vayan
quedando obsoletos.
32
2.2 CONCEPTOS Y TECNOLOGAS ACTUALES

Para concluir el presente estudio del estado del arte de las aplicaciones P2P, se
detalla a continuacin conceptos y tecnologas actuales.
2.2.1 P2P ANNIMO
Una red P2P annima es un tipo particular de red P2P en la que los pares son
annimos por defecto. La principal diferencia entre las redes P2P habituales y las
annimas est en el mtodo de encaminamiento de las respectivas arquitecturas de
redes. Estas redes permiten el flujo libre de informacin.
En una red P2P annima, cada par de la red tiene un pseudnimo asociado a su
direccin IP, para poder ser alcanzado por otro par y as intercambiar archivos. Sin
embargo, normalmente esta direccin, especialmente en redes annimas, no contiene
informacin alguna que pueda permitir la identificacin. Por tanto, un usuario es
prcticamente annimo.
El anonimato viene de la idea en la que nadie sabe quien requiere la informacin,
ya que es difcil 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 annima actan como un emisor y un receptor global
para mantener el anonimato.
El inters de la comunidad P2P en el anonimato ha incrementado muy
rpidamente desde hace unos aos 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 ms frecuentes de la tecnologa P2P annima son los que se muestran a
continuacin.
Navegacin annima por Internet.
Bloqueo de la posibilidad del registro de visitantes de sitios web.
Evasin de la censura de ISPs.
33
2.2.2 REDES FRIEND-TO-FRIEND

El trmino friend-to-friend, en adelante F2F, fue acuado por Dan Bricklin y hace
referencia a un tipo particular de red P2P annima en donde los pares se conectan
directamente a otros pares conocidos. Las aplicaciones F2F solamente permiten la
conexin con otros pares en los que el usuario confa, 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 annima.
Una de las mayores ventajas de este tipo de redes es que pueden crecer en
tamao 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 da 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.
Adems, las descargas en las aplicaciones P2P estn 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 tamao del
segmento est condicionado por el tamao mximo 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
subi al servidor. La unin de los segmentos descargados se realiza con programas

externos a la aplicacin P2M.
2.2.4 WEBCACH
Webcach es una caracterstica de algunos clientes P2P de la red eDonkey que
hacen uso de un proxy cach, una mquina que almacenan en su memoria lo que
acaba de pasar por ella en el trnsito de un par a otro, con la finalidad de disminuir el
trfico entre estos.
Los usuarios que usan la opcin 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 ms rpida.
Estas mquinas tienen un ancho de banda muy grande, ms que cualquier
conexin entre dos pares, con lo que se permite aprovechar la velocidad de conexin,
siempre que no se colapsen.
2.2.5 PROACTIVE NETWORK PROVIDER PARTICIPATION FOR P2P
Proactive network Provider Participation for P2P, ms conocido por su acrnimo
P4P, es un medio utilizado por los proveedores de Internet para optimizar el trfico de
las redes P2P de sus usuarios.
Es el siguiente paso en el desarrollo de servicios P2P, ya que permite minimizar el
nmero de saltos requeridos para las transferencias de archivos, eligiendo los pares
ms cercanos a otro, siempre y cuando pertenezcan al mismo proveedor.
35
Captulo 3
Motivacin y
Objetivos del
Proyecto
La bsqueda e intercambio de archivos de las actuales aplicaciones de redes P2P

estn 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, versin 8.04 Hardy Heron, para arquitecturas AMD. Los resultados obtenidos
son los que se muestran a continuacin.
Figura 13. Resultados en la conexin con el servidor 212.63.206.35
Figura 14. Resultados en la conexin con el servidor 195.22.108.26

37
Como se puede apreciar en las dos imgenes anteriores, los resultados de la

bsqueda difieren en el nmero de resultados, 18 para el primer caso y 10 para el
segundo. Adems, para resultados iguales, como sucede en el primer caso, la
disponibilidad y el nmero de fuentes completas, atributos que reflejan el nmero de
fuentes que tienen el archivo, tambin es diferente, por lo que la bsqueda y la
posterior descarga del archivo dependen del servidor en el que el cliente se conecte.
Adems, con el fin de reducir la cadena de bsqueda, si el usuario de la
aplicacin cliente introduce Ubu, Ubun, Ubunt o cualquier combinacin que no
contenga una palabra del nombre completo del archivo a buscar, Ubuntu, no se
produce ningn resultado en ambos servidores.
Tras el breve anlisis anterior, se demuestra que los resultados de las bsquedas
que realiza el cliente, dependen de la conexin 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 nmero de conexiones con clientes, mientras que en
otros el nmero de estas sea mnimo, provocando una ineficiente gestin 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 ms conexiones
haya, mayor ser la carga de trabajo, mientras que los menos favorecidos apenas
recibirn solicitudes de bsqueda de archivos.
Otra ineficiencia, comn entre los clientes de redes P2P, es que en el momento
de introducir una cadena de bsqueda 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 bsquedas en estos
sistemas, obligando al usuario conocer una serie de atributos del nombre del archivo, a
diferencia de las bsquedas en buscadores de Internet, que son menos rgidas en lo
referente a la cadena de bsqueda.
38
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 conexin a usuarios que tenga disponible este archivo para compartir y
que hayan escrito comentario sobre l. Adems, no todos los comentarios de la red
son accesibles ya que en este tipo de aplicaciones se suelen limitar el nmero de
conexiones y por lo tanto, indirectamente, afectan a la cantidad de comentarios a los
que se puede acceder.
Despus de haber analizado y detallado algunas de las carencias de los actuales
clientes de bsqueda 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 diseo e
implementacin de un protocolo P2P, que mejore el proceso de bsqueda de los
archivos entre los usuarios que se encuentren conectados a la red. Se entiende por
mejora la eliminacin de la dependencia del proceso de bsqueda 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 nmero de resultados. Al eliminar la dependencia de la
conexin con el servidor, el nmero de archivos encontrados en el proceso de
bsqueda, el nmero de fuentes encontradas que tienen disponible el archivo
para compartir y el nmero de comentarios de los usuarios que califican los
archivos, sern mayores.
Reduccin del tiempo de transferencia del archivo. Dado que el nmero de
fuentes encontradas es mayor, se reducir considerablemente el tiempo de
transferencia del archivo, ya que la probabilidad de conexin a un mayor
nmero de pares se incrementa.
39
Eliminacin del mantenimiento de una lista de servidores. Al no existir una

dependencia con el servidor, los clientes no tendrn que mantener una lista
de servidores en la que elegir sus favoritos y su prioridad en el proceso de
conexin, por lo que se le libera de una tarea innecesaria.
ptima gestin de los recursos. Al eliminar una preferencia de conexin
entre un servidor u otro, las conexiones de los clientes entre los distintos
servidores de la red estarn ms equilibradas.
Eficiente reparto de la carga de trabajo. Al realizar un gestin 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 bsqueda de un
archivo entre los usuarios
usu
de la red estarn ms equilibradas.
Para poder desarrollar el principal objetivo del proyecto, es necesario que los
servidores compartan la misma informacin acerca de los archivos y de los clientes que
se encuentren conectados a la red P2P. Dado el gran nmero de clientes de este tipo
de redes, es inviable que un servidor albergue toda sta informacin, ya que manejara
una gran volumen de datos que adems estara duplicado en el resto de servidores.
Por este motivo, la arquitectura propuesta se basa
basa en la conexin de todos los
servidores a una red IP multicast, para as poder distribuir la informacin por medio de
mensajes sin la necesidad de almacenarla en la base de datos de cada uno de ellos.
Figura 15. Arquitectura propuesta
40
Captulo 4
Anlisis del
Sistema
4.1 IDENTIFICACIN DE NECESIDADES

4.1.1 ALCANCE DEL SISTEMA
El objetivo del proyecto es el diseo e implementacin de un protocolo P2P, que
mejore el proceso de bsqueda de los archivos entre los usuarios que se encuentren
conectados a la red, ya que, como se detall en el captulo anterior, en los actuales
clientes de bsqueda y transferencia P2P, el proceso de bsqueda de archivos y su
posterior transferencia estn condicionados al servidor al que se encuentre conectado
el cliente.
Para poder mejorar el proceso de bsqueda, es necesario eliminar la
dependencia de los clientes al servidor que se encuentren conectados, haciendo
obligatorio que los servidores compartan la misma informacin acerca de los archivos
y de los clientes que se encuentren conectados a la red P2P. Dado el gran nmero de
clientes de este tipo de redes, es inviable que un servidor albergue toda sta
informacin, ya que manejara una gran volumen de datos que adems estara
duplicado en el resto de servidores. Por este motivo, la arquitectura propuesta se basa
en la conexin de todos los servidores a una red IP multicast, para as poder distribuir
la informacin 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
Cuando un cliente de la red P2P desea realizar una bsqueda de un determinado

archivo, enva una solicitud de bsqueda al servidor al que se encuentra conectado. El
servidor procesa la solicitud, realizando una consulta en su base de datos, en la que
estn registrados todos los archivos de los clientes con los que mantiene una conexin.
Al finalizar la consulta, transmite la solicitud de bsqueda 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 peticin. Una vez consultada la
base de datos, se envan los resultados al servidor que los solicit para aadir esos
resultados a los que ya tena. Una vez terminado este proceso, todos los resultados se
envan al cliente que inici el proceso de bsqueda.
El proceso anteriormente explicado, se realiza tanto para las bsquedas de
archivos, para las bsquedas de comentarios de los archivos que comparten los
clientes, como para las bsquedas de los clientes que tienen el archivo que el usuario
desea descargarse.
4.1.2 TOPOLOGA DE USUARIOS FINALES
Hay que distinguir entre dos tipos de usuarios claramente definidos por su uso
de la aplicacin diseada.
Por una parte se encuentran los administradores de los servidores de la red,
personas con conocimientos de la aplicacin, conocimientos de bases de datos y con
derechos a acceso a esta para realizar los procesos de control y mantenimiento que
crean adecuados. Adems este tipo de usuario ser el encargado de establecer una
poltica, 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 aplicacin cliente, la cual es
utilizada para buscar y transferir archivos con otros usuarios de la red.
43
4.1.3 RESTRICCIONES
No existe ningn tipo de restriccin de tipo econmica, ya que estas no son
considerables en el desarrollo del proyecto.
Sin embargo, s existen restricciones de carcter temporal, ya que el proyecto ha
de ser presentado en Junio del 2009, la planificacin de este est condicionada a esta
fecha.
Con respecto a restricciones tecnolgicas, dado que el lenguaje a utilizado para
la implementacin del protocolo ha sido Java, las mquinas en las que se ejecute tanto
el cliente como el servidor, han de tener instaladas una implementacin de la Mquina
Virtual Java. Con respecto al sistema operativo, al haber elegido un lenguaje
multiplataforma, no existe ninguna restriccin en lo referente al entorno de ejecucin
de la aplicacin.
4.2 ANLISIS DE REQUISITOS

4.2.1 CONTEXTO GENERAL DEL SISTEMA
Este contexto general del sistema est representado mediante un diagrama de
presentacin, con smbolos y figuras, donde se muestra la iteracin 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
realizar una bsqueda, enva una solicitud al servidor al que se encuentra conectado. El
servidor procesa la solicitud, consultando en su base de datos, en la que estn
registrados todos los archivos de los clientes con los que mantiene una conexin. 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 ms resultados que satisfacen la peticin. Una vez consultada la base de datos,
envan los resultados al servidor que los solicit para aadir esos resultados a los que
ya tena. Una vez terminado este proceso, todos los resultados se envan al cliente que
inici el proceso de bsqueda.
El proceso anterior, se realiza tanto para las bsquedas de archivos, como para
las bsquedas de comentarios de los archivos que comparten los clientes, como para
las bsquedas de los clientes que tienen el archivo que el usuario desea descargarse.
Despus de que el cliente obtenga los resultados de los clientes que tienen un
determinado archivo disponible para su transferencia, ste realiza una conexin con
cada uno de ellos para obtener las partes del archivo que necesite.
Figura 18. Conexiones entre clientes de la red

45
4.2.2 MBITO DEL SISTEMA

Partiendo de los objetivos sealados en el anterior captulo, se definen a
continuacin, las entidades principales del proyecto.
Hermes. Es la aplicacin cliente que ejecuta el usuario para la bsqueda 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 bsqueda de archivos,
comentarios o clientes que ofrecen un determinado archivo. Adems
mantiene un conexin 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 aplicacin servidora para satisfacer las peticiones de los
clientes.
4.2.3 MBITO DEL CLIENTE
Partiendo de los objetivos sealados en el captulo anterior, los requisitos
identificados en la aplicacin cliente, son lo que se muestran a continuacin.
Eliminacin de lista de servidores. Con la finalidad de eliminar el
mantenimiento de la lista de servidores por parte del cliente, y la eleccin de
sus favoritos, este recibir la informacin necesaria acerca de los servidores
que se encuentran conectados a la red, para su agregacin automtica en la
lista de servidores.
Limitacin de bsquedas. Con el fin de que los resultados de las bsquedas se
cian ms a los requisitos del usuario, este podr introducir el tipo de archivo
a buscar, obteniendo de esta forma un conjunto de resultados ms limitado a
las necesidades del cliente.
46
Transferencias simultneas. Para poder reducir el tiempo de las

transferencias, los clientes mantendrn 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 conexin. Con el objetivo de controlar los posibles
errores de las conexiones entre clientes, si ocurriese alguna desconexin
imprevista de alguno de estos, el resto de los clientes mantendrn la conexin
con los clientes a los que se encuentran conectados, sin afectar a las
comunicaciones ni a los datos transferidos.
Incremento paulatino del tamao del fichero temporal. Con el fin de realizar
una correcta gestin del espacio del disco duro del usuario, el tamao del
archivo temporal asociado a una descarga, se incrementar a medida que la
descarga avanza y no se establecer al tamao del archivo original, como
sucede en los actuales clientes.
Previsualizacin de los archivos. Con la finalidad de eliminar los archivos
corruptos, los clientes podrn reproducir los archivos multimedia que se
encuentran descargando sin la necesidad de que estos estn completamente
descargados. Ser requisito indispensable en este caso, que el cliente
disponga de la una aplicacin instalada en su equipo que permita la
reproduccin 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 descomposicin separa los diferentes mdulos de los que consta la
aplicacin, proporcionando transparencia para modificar el sistema. Cada subsistema
engloba una funcionalidad diferente de la aplicacin. La independencia entre los
subsistemas identificados permite realizar modificaciones sobre cualquier capa sin
afectar a la interfaz del resto de componentes.
47
Las capas identificadas en el mbito del cliente son las que se muestran a
continuacin.
Figura 19. Capas de la aplicacin cliente
GUI. Es la capa ms cercana al usuario. Recoge la interfaz grfica que este

utilizar para interactuar con el sistema y redirige sus peticiones a la capa de
lgica.
Lgica. Recoge toda la lgica del cliente, necesaria para la gestin de los
archivos locales, las transferencias de archivos en la red y las solicitudes de
servicios a la capa de comunicaciones.
Comunicaciones. Recoge la implementacin 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 sealados en el captulo anterior, los requisitos
identificados en la aplicacin servidor, son lo que se muestran a continuacin.
Comunicacin entre servidores. Con la finalidad de que las bsquedas sean
independientes del servidor al que se est conectado, los servidores
distribuirn una lista en la que estn registrados los usuarios conectados a la
red y los archivos que comparten, as como sus comentarios.
Gestin de comentarios. Para otorgar una mayor informacin a los clientes
con respecto a los archivos que se descargan, los servidores de la red
gestionarn los comentarios de los usuarios con el fin de que stos puedan
solicitar esta informacin como si se tratase de un recurso ms de la red.
48
Gestin de errores. Para conseguir un mantenimiento correctivo del sistema,

los posibles errores que sucedan en el servidor, tras una solicitud de un
cliente, se registrarn 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
continuacin.
Figura 20. Capas de la aplicacin servidor
Comunicaciones. Recoge la implementacin 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.
Lgica. Recoge toda la lgica del servidor, necesaria para la gestin 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 informacin contenida en la base de datos. Este
conjunto de objetos gestiona la conectividad con la base de datos,
exponiendo una interfaz ms simple, actuando como adaptadores entre el
componente de la lgica y la base de datos.
4.2.5 DECISIONES DE DISEO
El lenguaje de programacin Java proporciona dos clases para la implementacin
de sockets. Estas clases son Socket y DatagramSocket. La principal diferencia entre
49
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 conexin, a
diferencia de UDP.
Las principales caractersticas de este protocolo son las que se detallan a
continuacin [GARC05].
Control de flujo. Mediante el uso de ventanas de envo y la identificacin de
paquetes transmitidos, se proporciona un modo para que dos sistemas
cooperen activamente en la transmisin de paquetes para evitar exceso de
flujo y prdida de paquetes y adaptarse a la congestin de la red.
Deteccin y correccin de errores. Mediante una utilidad de cdigo de
paridad,
checksum21,
nmeros
de
secuencia,
confirmaciones
temporizadores de retransmisin se asegura la integridad de los paquetes,

dando lugar a que no existan rechazos. La retransmisin de los paquetes
corrompidos o perdidos se puede manejar de una manera oportuna y
eficiente.
Reconocimiento del paquete recibido. El envo 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 conexin y liberacin, conlleva muchos ms controles que el protocolo UDP,
llegando a aumentar el tiempo de procesamiento considerablemente.
21
El trmino 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
comparacin.
22
El trmino acknowledgement se refiere a un mensaje enviado por el receptor al emisor indicando bien
que ste est listo para recibir una transmisin o que una transmisin fue recibida sin error.
50
A pesar del inconveniente anterior, se ha implementado la comunicacin 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 caractersticas que aporta este
protocolo son ms 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 programacin Java para la implementacin 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 conexin 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 programacin utilizado.
Para la identificacin de los archivos que los clientes ponen a disposicin de la
red P2P, ha sido necesario el uso de un sistema de funciones hash criptogrficas para
asegurar que la identificacin se realiza de forma unvoca.
Actualmente existen varios algoritmos hash, entre los que se encuentra SHA1.
Este algoritmo procesa la informacin 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). Adems, hasta hoy da, no se han registrado
ataques contra este algoritmo, comprometiendo su resistencia, como s sucede con
otros como MD5. En el ao 2005, Xiaoyun Wang y Hongbo Yu de la Universidad
Shandong, China, publicaron un artculo en el cual se describa 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 eleccin del
algoritmo SHA1 como funcin hash para el clculo de identificadores de los archivos de
la red P2P.
23
El trmino RIPEMD se refiere a un algoritmo de funcin hash diseado 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
4.3 METODOLOGA
Para la realizacin del proyecto se ha aplicado la metodologa UML (Unified
Modeling Language) en su versin 2.0, ya que se utiliza un lenguaje que permite de
forma grfica visualizar, especificar, construir y documentar un sistema [OMG09].
Adems, ofrece un estndar 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 programacin, modelos de bases de
datos y componentes reutilizables.
4.3.1 DIAGRAMA DE DOMINIO
Un diagrama de dominio muestra los conceptos bsicos del dominio, sus
propiedades ms importantes y las relaciones entre dichos conceptos.
El diagrama de dominio del sistema es el que se muestra a continuacin.
52
Figura 21. Diagrama de dominio del sistema
53
4.3.2 DIAGRAMA DE CASOS DE USO

Un diagrama de casos de uso muestra la relacin entre los actores y los casos de
uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere
a su interaccin externa.
El diagrama de casos de uso para el usuario de la aplicacin cliente es el que se
muestra a continuacin.
Conectar a la red
P2P
Buscar archivos en
la red P2P
Buscar comentarios
de un archivo
Eliminar resultados
de una bsqueda
Descargar archivo
de la red P2P
Previsualizar
archivo
Usuario
Aadir 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 aplicacin cliente
54
Seguidamente, se detalla cada uno de los casos de uso descritos en el diagrama

anterior.
CASOS DE USO.
- Conectar a la red P2P. Conexin a la red P2P para poder comenzar con la
bsqueda de archivos o continuar con las transferencias pendientes.
- Buscar archivos en la red P2P. Bsqueda de archivos en la red P2P
introduciendo el nombre del archivo o parte de l, con la posibilidad de
limitacin de la bsqueda, seleccionando el tipo de archivo a buscar.
- Buscar comentarios de un archivo. Una vez obtenidos los resultados de
una bsqueda, bsqueda de los comentarios con los que otros usuarios
han calificado un determinado archivo.
- Eliminar resultado de una bsqueda. Eliminacin de los resultados de una
bsqueda 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 bsqueda o descarga de los archivos
pendientes.
- Previsualizar archivo. Previsualizacin de un archivo en estado de
descarga, una vez iniciada esta y con al menos el primer trozo del archivo
descargado (RN01).
- Aadir comentario. Insertar la evaluacin de un archivo y su comentario
de un archivo descargado o en estado de descarga.
- Ver comentarios de un archivo local. Visualizacin de los comentarios de
los archivos que el usuario pone a disposicin del resto de usuarios de la
red P2P.
- Eliminar comentario de un archivo local. Eliminacin, por cualquier motivo
que considere el usuario, de un comentario de un archivo local.
- Recargar archivos locales. Recarga de los archivos locales y sincronizacin
con el servidor al que el usuario se encuentra conectado, por si el usuario
ha eliminado un archivo o introducido uno nuevo.
55
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
continuacin del resto.
4.3.3 DIAGRAMA DE PAQUETES
Los diagramas de paquetes reflejan la organizacin de los subsistemas en que se
descompone el sistema y las dependencias entre ellos. Representa una visin
fundamental para el control de alto nivel de un sistema.
El diagrama de paquetes es el que se muestra a continuacin.
Figura 23. Diagrama de paquetes
A continuacin se detalla cada uno de los paquetes que aparecen en el diagrama

anterior.
Paquete gui. Contiene la interfaz grfica del usuario y gestiona las acciones de
este sobre cada una de sus componentes.
56
Paquete client. Contiene toda la lgica del cliente en clases denominadas

gestores, como son los gestores de transferencias, comentarios, archivos
locales y dems.
Paquete constants. Contiene la definicin de las constantes usadas por la
aplicacin, como definicin de directorios, ficheros necesarios para la
ejecucin y tipos de datagramas y paquetes.
Paquete til. Contiene las definiciones de los conceptos del dominio del
sistema.
Paquete packets. Contiene la definicin de los paquetes que se transmiten en
la comunicacin del cliente con el servidor y el cliente con el resto de los
clientes de la red P2P.
Paquete data. Contiene la informacin de los datagramas que se transmiten
en la comunicacin entre los servidores de las red IP multicast.
Paquete server. Contiene toda la lgica del servidor para el servicio de
solicitudes y la gestin del fichero de control de errores.
Paquete dao. Contiene la abstraccin del acceso a la base de datos por parte
del servidor.
57
4.3.4 DIAGRAMA DE CLASES

A continuacin 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 continuacin.
Figura 24. Clases del paquete gui
58
Las clases del paquete client son las que se muestran a continuacin.
Figura 25. Clases del paquete client
59
Las clases del paquete constants son las que se muestran a continuacin.
Figura 26. Clases del paquete constants
60
Las clases del paquete util son las que se muestran a continuacin.
Figura 27. Clases del paquete util
61
Las clases del paquete packets son las que se muestran a continuacin.
Figura 28. Clases del paquete packets
62
Las clases del paquete data son las que se muestran a continuacin.
Figura 29. Clases del paquete data
63
Las clases del paquete server son las que se muestran a continuacin.
Figura 30. Clases del paquete server
64
Las clases del paquete dao son las que se muestran a continuacin.
Figura 31. Clases del paquete dao
4.3.5 DISEO DE LA BASE DE DATOS

A continuacin se detallan las tablas y relaciones que componen la base de datos
de la aplicacin.
TABLA EXTENSIONS.
- Descripcin: contiene las extensiones de los archivos.
- Relacin con: ninguna tabla.
-
Sentencia de creacin: CREATE TABLE DELPHIC.EXTENSIONS(

EXTENSION VARCHAR(6) NOT NULL,
TYPE VARCHAR(8) NOT NULL,
PRIMARY KEY(EXTENSION)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
65

EXTENSIONS
PK
EXTENSION: varchar(6)
TYPE: varchar(8)
TABLA SHARES.
- Descripcin: contiene los archivos de los usuarios conectados a la red.
-
Sentencia de creacin: CREATE TABLE DELPHIC.SHARES(

NAME VARCHAR(256) NOT NULL,
SIZE BIGINT NOT NULL,
HASH CHAR(40) NOT NULL,
COUNTER INT NOT NULL DEFAULT 0,
PRIMARY KEY(NAME,HASH)
TABLA CLIENTS.
- Descripcin: contiene la informacin de los clientes conectados a la red.
- Relacin con: COMMENTS.
- Sentencia de creacin: CREATE TABLE DELPHIC.CLIENTS(
IP VARCHAR(15) NOT NULL,
PRIMARY KEY(IP,HASH)
66
TABLA COMMENTS.
- Descripcin: contiene los comentarios de los usuarios conectados a la red.
- Relacin con: CLIENTS.
-
Sentencia de creacin: CREATE TABLE DELPHIC.COMMENTS(

NCOMMENT INT NOT NULL AUTO_INCREMENT,
CLIENTIP VARCHAR(15) 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
Captulo 5
Protocolo del
Sistema
5.1 PROTOCOLO ENTRE CLIENTE Y SERVIDOR

5.1.1 SOLICITUD DE CONEXIN A LA RED PEER-TO-PEER
Cuando un cliente se conecta la red P2P, se enva un paquete a la direccin IP del
servidor para que se contemple la nueva agregacin de este cliente, registrando en la
base de datos la direccin del cliente, los archivos que comparte y sus comentarios. El
servidor acredita al nuevo cliente con el correspondiente paquete de contestacin.
Figura 32. Solicitud de conexin a la red P2P
PAQUETE REQUEST_CONNECT.
- Implementado por la clase: ConnectPacket.
- Datos. La direccin IP del cliente y los archivos que pone a disposicin
de la red P2P.
PAQUETE REPLY_ CONNECT.
- Implementado por la clase: StandardPacket.
- Datos. Sin datos. El tipo de paquete transmitido es la propia
confirmacin del protocolo.
5.1.2 SOLICITUD DE BSQUEDA DE ARCHIVOS
Cuando un cliente solicita una bsqueda de archivos, se enva un paquete a la
direccin 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 bsqueda
del archivo, tanto los suyos como los que provienen de la red IP multicast.
Figura 33. Solicitud de bsqueda de archivos
69
PAQUETE REQUEST_SEARCH.
- Implementado por la clase: RequestSearchPacket.
- Datos. La secuencia de la cadena de bsqueda y el tipo de archivo a
buscar.
PAQUETE REPLY_SEARCH.
- Implementado por la clase: ReplySearchPacket.
- Datos. Los archivos que satisfacen los requisitos de bsqueda.
5.1.3 SOLICITUD DE BSQUEDA DE COMENTARIOS
Cuando un cliente solicita una bsqueda de comentarios de un archivo
determinado, se enva un paquete a la direccin 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 bsqueda de la solicitud, tanto los suyos como los que
provienen de la red IP multicast.
Figura 34. Solicitud de bsqueda de comentarios
PAQUETE REQUEST_COMMENTS.
- Implementado por la clase: RequestCommentsPacket.
- Datos. El valor de la funcin 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 bsqueda.
5.1.4 SOLICITUD DE BSQUEDA DE CLIENTES
Cuando un cliente solicita una bsqueda de otros clientes que tienen disponible
un archivo determinado para su transferencia, se enva un paquete a la direccin IP del
servidor al que se encuentra conectado para que consulte su base de datos. El servidor
70
contesta con las direcciones IP de los clientes que satisfacen los requisitos de
bsqueda 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 bsqueda de comentarios
- Implementado por la clase: RequestIPsPacket.
- Datos. El valor de la funcin hash que identifica un archivo en la red
P2P.
- 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 SINCRONIZACIN
Cuando un cliente ha terminado de descargar completamente un archivo de la
red P2P, se enva un paquete a la direccin IP del servidor al que se encuentra
conectado para que aada a la disponibilidad del archivo a este cliente.
Figura 36. Solicitud de sincronizacin de archivos
PAQUETE REQUEST_SYNCHRONIZE.
- Implementado por la clase: SynchronizePacket.
- Datos. El archivo descargado del cliente.
71
5.1.6 SOLICITUD DE DESCONEXIN DE LA RED PEER-TO-PEER

Cuando un cliente se desconecta la red P2P, se enva un paquete a la direccin IP
del servidor para que se contemple la desconexin de este cliente, eliminando los
registros de la base de datos, los archivos que comparte y sus comentarios. El servidor
acredita la desconexin con el correspondiente paquete de contestacin.
Figura 37. Solicitud de desconexin a la red P2P
- Datos. La direccin IP del cliente que se desconecta de la red P2P.
confirmacin del protocolo.
5.2 PROTOCOLO ENTRE SERVIDORES

5.2.1 SOLICITUD DE CONEXIN A LA RED MULTICAST
Cuando un servidor se conecta la red IP multicast, se enva un datagrama a la
direccin de esta red para que el resto de los servidores contemplen la nueva
agregacin del servidor. El resto de los servidores conectados a la red IP multicast,
acreditan a este nuevo servidor con el correspondiente datagrama de contestacin.
Figura 38. Solicitud de conexin a la red IP multicast
72
DATAGRAMA REQUEST_JOIN.
- Implementado por la clase: RequestJoinData.
- Datos. La direccin IP y el puerto asignado a la red IP multicast del
servidor que solicita la conexin.
DATAGRAMA REPLY_JOIN.
- Implementado por la clase: ReplyJoinData.
- Datos. La direccin IP y el puerto asignado a la red IP multicast del
servidor que contesta a la solicitud de conexin.
5.2.2 SOLICITUD DE BSQUEDA DE ARCHIVOS
Cuando un servidor solicita una bsqueda de archivos, se enva un datagrama a
la direccin 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 bsqueda del archivo.
Figura 39. Solicitud de bsqueda de archivos a la red IP multicast
DATAGRAMA REQUEST_SEARCH.
- Implementado por la clase: RequestSearchData.
- Datos. La secuencia de la cadena de bsqueda y el tipo de archivo a
buscar.
DATAGRAMA REPLY_ SEARCH.
- Implementado por la clase: ReplySearchData.
- Datos. Los archivos que satisfacen los requisitos de bsqueda.
5.2.3 SOLICITUD DE BSQUEDA DE COMENTARIOS
Cuando un servidor solicita una bsqueda de comentarios de un archivo
determinado, se enva un datagrama a la direccin de la red IP multicast para que el
73
resto de los servidores consulten sus bases de datos. El resto de los servidores
contestan con los resultados que satisfacen los requisitos de bsqueda de la solicitud.
Figura 40. Solicitud de bsqueda de comentarios a la red IP multicast
DATAGRAMA REQUEST_SEARCH.
- Implementado por la clase: RequestCommentsData.
- Datos. El valor de la funcin hash que identifica un archivo en la red.
DATAGRAMA REPLY_ SEARCH.
- Implementado por la clase: ReplyCommentsData.
- Datos. Los comentarios que satisfacen los requisitos de bsqueda.
5.2.4 SOLICITUD DE BSQUEDA DE CLIENTES
Cuando un servidor solicita una bsqueda de clientes que tienen disponible un
archivo determinado para su transferencia, se enva un datagrama a la direccin 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 bsqueda de la solicitud.
Figura 41. Solicitud de bsqueda de direcciones IP a la red IP multicast
DATAGRAMA REQUEST_IPS.
- Implementado por la clase: RequestIPsData.
- Datos. El valor de la funcin hash que identifica un archivo en la red.
74
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 peticin 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 enva 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.
sincronizacin 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 despus 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
necesario para que el cliente que sirve el archivo elimine o vuelva a insertar la peticin
en la cola de descargas.
Figura 43. Sincronizacin de transferencia de un parte del archivo
PAQUETE CONTINUE.
PAQUETE END.
76
Captulo 6
Programacin y
Pruebas del
Sistema
6.1 PROGRAMACIN
6.1.1 INTRODUCCIN
El objetivo de esta etapa es alcanzar la transformacin 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 transformacin de
la mejor forma posible, ya que dependen de factores como el lenguaje de
programacin y las herramientas y utilidades software utilizadas.
Esta etapa recoge los detalles de la programacin empleada para realizar la
aplicacin con explicaciones de los lenguajes utilizados en todos los componentes.
6.1.2 LENGUAJES DE PROGRAMACIN
Para la implementacin del protocolo se ha utilizado Java como lenguaje de
programacin, puesto que el proyecto tiene caractersticas de un sistema distribuido,
y este ha de ser independiente tanto del hardware como del sistema operativo en el
que se ejecute. Adems la arquitectura planteada se ajusta muy bien a las
caractersticas del lenguaje de programacin anteriormente mencionadas.
Para la implementacin de la base de datos de los servidores se ha utilizado el
sistema gestor de bases de datos relacionales MySQL, unos de los ms utilizados, ya
que las caractersticas de este sistema gestor, detalladas anteriormente, se ajustan a
los requisitos del proyecto, tales como multi-thread, rapidez y fiabilidad. Adems
MySQL est bajo licencia GPL, un valor aadido al producto final que hoy en da es
bastante valorado en algunos proyectos.
6.1.3 MANUAL DE USUARIO
En esta etapa es donde, por ltimo, se ha procedido a la realizacin del manual
de usuario, incluido en el anexo I para el cliente y en el anexo II para el servidor. La
realizacin 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 determinacin del usuario de cmo utilizarlo.
78
6.2 PRUEBAS DEL SISTEMA

Despus de haber desarrollado cada una de las clases que componen el dominio
de la aplicacin, es necesario realizar una serie de pruebas para conseguir una correcta
integracin y funcionamiento de esta. El objetivo global de esta fase es someter a
todas las componentes de la aplicacin 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 diagnstico del rendimiento del sistema ante
situaciones lmites. A continuacin 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 aplicacin.
Pruebas de integracin. Verifican la funcionalidad de toda la aplicacin y el
rendimiento de los recursos utilizados.
Pruebas de explotacin del sistema. Confirman la correcta operacin de la
totalidad del sistema.
Pruebas de sobrecarga. Comprueban el correcto funcionamiento y
comportamiento de la aplicacin ante los estados de sobrecarga en los que se
puede ver envuelto.
Pruebas de recuperacin. Verifica la capacidad de la aplicacin para recuperar
la informacin ante posibles errores de ejecucin.
Pruebas de seguridad. Verifican los aspectos de seguridad exigidos en los
requisitos del sistema.
Pruebas de usabilidad. Aseguran la accesibilidad de la aplicacin por parte de
los usuarios finales.
Pruebas de aceptacin del usuario. Certifican por parte de los usuarios finales
la funcionalidad y rendimiento de la aplicacin de acuerdo con los requisitos
establecidos.
79
6.2.1 PRUEBAS DE ENCADENAMIENTO

Una vez comprobado el correcto funcionamiento de cada componente software,
estas pruebas garantizan la adecuada comunicacin y llamadas remotas entre unos
componentes y otros.
6.2.2 PRUEBAS DE INTEGRACIN
Una vez verificadas las comunicaciones y llamadas entre mdulos y programas
de la aplicacin se procede a integrar todos sus componentes.
6.2.3 PRUEBAS DE EXPLOTACIN DEL SISTEMA
Estas pruebas van encaminadas a determinar la facilidad que ofrece el sistema
para su explotacin u operacin. Para ello, se han ejecutado todos los procesos
recogidos en el manual de explotacin 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 aplicacin en situaciones de sobrecarga de trabajo y concurrencia de
usuarios o tareas. Estas pruebas ayudan a establecer el nivel de sobrecarga mximo
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 RECUPERACIN
En toda aplicacin es necesario establecer determinados procesos y mecanismos
para que en caso de un mal funcionamiento del sistema y su posterior prdida de
informacin, esta pueda ser recuperada o en su defecto llevar al sistema a un estado
consistente anterior.
80
6.2.6 PRUEBAS DE SEGURIDAD

Una vez verificadas las comunicaciones y llamadas entre mdulos y programas
de la aplicacin 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 diseo 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 informtica, puedan utilizar esta
aplicacin sin ningn tipo de problema.
6.2.8 PRUEBAS DE ACEPTACIN 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 navegacin del sistema.
81
Captulo 7
Planificacin del
Proyecto
El presente proyecto comenz el da 28 de Octubre del 2008 con la reunin de

lanzamiento mantenida entre el director de proyecto y el jefe de proyecto, en la que se
firm la informacin del proyecto contenida en el anexo A. Posteriormente, este anexo
fue entregado al coordinador de proyectos.
Aunque la realizacin del proyecto ha sido constante, se ha visto interrumpida
por los exmenes intersemestrales de Noviembre y Abril y los exmenes finales del
curso.
Cabe destacar, que se han mantenido reuniones peridicas 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 diseo tomadas y registrar las incidencias ocurridas.
Figura 50. Planificacin del proyecto
El proyecto concluy el da 4 de Junio del 2009 con la reunin de finalizacin

mantenida entre el director de proyecto y el jefe de proyecto. Posteriormente, el da 5
de Junio del 2009 se entreg el presente documento al coordinador de proyecto.
83
La etapa de desarrollo e implementacin tanto del servidor como del cliente se

ha dividido en las fases que se muestran a continuacin.
Figura 51. Planificacin de la etapa de desarrollo e implementacin
Interfaz. Corresponde a la fase de diseo del medio de interactuacin del

usuario con la aplicacin, ya sea bien por medio de componentes visuales o
por medio de ficheros de registro, como es el caso del servidor.
Lgica. Corresponde a la fase de diseo de los algoritmos y mtodos
necesarios para la ejecucin del sistema.
Programacin. Corresponde a la fase de implementacin de los requisitos y
conclusiones de las dos fases anteriores.
Diseo de la base de datos. Corresponde a la fase de diseo de la base de
datos utilizada por los servidores.
Implementacin de la base de datos. Corresponde a la fase de
implementacin del diseo de la fase anterior.
84
Captulo 8
Valoracin
Econmica del
Proyecto
El objetivo de esta valoracin es dotar al proyecto de un valor econmico y

realizar una estimacin del desarrollo del mismo.
8.1 COSTES DE TECNOLOGA

Los costes de tecnologa son costes procedentes de la adquisicin de todo tipo
de mquinas hardware para el correcto funcionamiento del sistema, as como las
licencias necesarias para la utilizacin 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 realizacin 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 conexin a Internet.
CONCEPTO
Equipo de trabajo
Amortizacin estacin de trabajo
Conexin 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 Versin 2002 Service
Pack 3 y el paquete ofimtico 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
cdigo abierto, por lo que no representan coste alguno en la valoracin econmica.
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
NOTA: La valoracin anterior corresponde al valor mximo, ya que se han

tomado los costes de licencias de nueva adquisicin. En caso de poseer licencias para
el uso de las anteriores herramientas, o adquirir ampliaciones de licencias, los costes
de tecnologa seran inferiores.
Con el clculo de los dos costes anteriores se puede calcular los costes de
tecnologa, como se detalla a continuacin.
CONCEPTO
Costes de hardware
Costes de software
Total
COSTE
1.315,00
1.500,00
2.815,00
Figura 46. Costes de tecnologa
8.2 COSTES DE IMPLANTACIN

Los costes de implantacin son costes procedentes del trabajo de todo el
personal implicado en el desarrollo del proyecto.
A continuacin 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 documentacin de calidad exigida en los plazos acordados,
aportando conocimiento de tipo tcnico y funcional. Es el responsable de
dirigir el proyecto, facilitar conocimientos y orientar indicaciones para la
resolucin ante posibles problemas surjan, y supervisar la realizacin del
proyecto as como la calidad de sus contenidos.
Jefe de proyecto. Es el mximo responsable del proyecto. Su labor consiste en
gestionar el proyecto realizando actividades de seguimiento, control y
planificacin, asignacin de recursos y dems actividades de gestin.
87
Analista. Es el responsable de analizar los requisitos de la aplicacin y

elaborar las especificaciones tcnicas de los programas. Adems, en algunos
casos puede ayudar al programador en la realizacin de alguna actividad.
Programador. Es el responsable de implementar el cdigo ejecutable de la
aplicacin con los requisitos y especificaciones facilitadas por el analista, as
como realizar parte de la documentacin del proyecto, como el manual de
usuario y el manual del administrador.
A continuacin se muestra la estimacin del esfuerzo de cada unos de los
integrantes del proyecto. Dicha estimacin se ha realizado junto con la planificacin
del proyecto.
ACTIVIDAD
Reunin de lanzamiento
Anexo A
Estudio de clientes actuales
Anexo B
Reunin de seguimiento
Interfaz del servidor
Lgica del servidor
Programacin del servidor
Diseo de la BBDD
Implementacin de la BBDD
Interfaz del cliente
Lgica del cliente
Programacin del cliente
Pruebas unitarias
Pruebas de integracin
Pruebas de aceptacin
Documentacin
Anexos
Reunin de finalizacin
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. Estimacin del esfuerzo de los integrantes del proyecto
88
Con la estimacin anterior, y el coste base de cada integrante del proyecto, se

puede realizar el clculo de los costes de implantacin, como se detalla a continuacin.
FUNCIN
Director de proyecto
Jefe de proyecto
Analista
Programador
NMERO 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 implantacin
8.3 VALORACIN 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 tecnologa
Costes de implantacin
Figura 49. Costes de desarrollo del proyecto
NOTA: El concepto de otros gastos hace referencia a gastos de material

consumible.
89
Captulo 9
Conclusiones y
Futuras Lneas de
Desarrollo
En el presente proyecto se ha realizado un exhaustivo anlisis sobre los sistemas

actuales P2P de transferencia de archivos, detallando sus caractersticas,
funcionamiento y mejoras con respecto a otros sistemas y, conjuntamente, se ha
introducido el problema de las bsquedas de archivos en este tipo de redes. Sobre esa
base, se ha realizado el diseo e implementacin de un protocolo independiente del
servidor al que el usuario se encuentre conectado.
Al eliminar la dependencia de la conexin con el servidor, el nmero de archivos
encontrados en el proceso de bsqueda, el nmero de fuentes encontradas que tienen
disponible el archivo para compartir, y el nmero de comentarios de los usuarios que
califican los archivos, son mayores. Adems, dado que el nmero de fuentes
encontradas es mayor, se reduce considerablemente el tiempo de transferencia del
archivo, ya que la posibilidad de conexin a un mayor nmero 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 conexin, por lo que se le libera de una tarea innecesaria, equilibrando de
esta forma las conexiones de los clientes entre los distintos servidores. Adems, al
realizar una gestin 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 bsqueda de un archivo entre los usuarios de la red estn ms
proporcionadas.
La arquitectura propuesta, basada en una red IP multicast, permite que cada
servidor conozca una pequea parte de la red P2P y no sea necesario conocer toda la
tipologa de esta, de manera que el tamao de la red puede crecer tanto como sea
necesarios sin la necesidad de afectar al rendimiento de los nodos. Asimismo, con una
nica conexin, a la red IP multicast, se permite mantener un intercambio continuado
de la informacin de la base de datos entre los distintos servidores, sin la necesidad de
mantener tantas conexiones como servidores estn conectados a la red P2P, lo que
disminuye la sobrecarga y el coste computacional de estos.
91
El sistema propuesto se podra enmarcar dentro de los sistemas P2P

estructurados, ya que se conoce la localizacin 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 bsqueda determinista, de tal
forma que se asegura la localizacin de un recurso siempre y cuando se encuentre en
la red, encaminando los mensajes de forma eficiente.
Con la realizacin de este proyecto, se suplen algunas carencias de las actuales
aplicaciones de bsqueda y transferencia de archivos en redes peer-to-peer, como es
el caso de la bsqueda de fuentes o de comentarios de un determinado archivo.
Adems, otras caractersticas y funcionalidades de estas aplicaciones se optimizan,
como por ejemplo la previsualizacin de los archivos en estado de descarga y la
gestin del espacio de los archivos temporales.
Las posibles futuras lneas de investigacin en el contexto de las redes P2P son
numerosas y amplias. Las capacidades que aporta la infraestructura de clave pblica,
PKI24 (Public Key Infrastructure), a las aplicaciones en las que es necesaria la ejecucin
con garantas de operaciones criptogrficas como el cifrado, la firma digital o el no
repudio de transacciones electrnicas, son extremadamente seguras. Las operaciones
criptogrficas de clave pblica, 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 tecnologa PKI, est fuertemente ligada a la privacidad
de la llamada clave privada y los procedimientos operacionales o polticas de seguridad
aplicados. El uso de esta infraestructura de clave pblica se podra extender al
presente proyecto para as poder limitar la conexin entre los pares de la red
exclusivamente a aquellos nodos en los que el usuario confa, transformando as la red
P2P en una red F2F.
Conjuntamente, esta infraestructura se podra extender al sistema del presente
proyecto para, adems de garantizar un alto grado de seguridad en las
24
El trmino PKI (Public Key Infrastructure) se refiere a la combinacin de hardware, software y polticas
de seguridad para permitir la ejecucin de cifrados y firmas digitales en operaciones electrnicas.
92
comunicaciones, que los contenidos que estn bajo derechos de autor sean
compatibles con las transferencias. De esta forma, existira 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 podra realizar un proceso de reconexin 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 garantizara un rpido retorno de la
disponibilidad de los recursos en caso de fallo de algn 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 conexin a Internet, se podra dar la posibilidad al
usuario de elegir los rangos de velocidades mximas de subida y descarga de archivos.
De esta forma, la aplicacin cliente no copara todo el ancho de banda disponible y el
usuario podra ejecutar otras aplicaciones que necesiten de conexin a Internet.
Ampliando la propuesta anterior, la aplicacin cliente podra aadir un sistema
de filtrado de paquetes, aplicando tcnicas de traffic shaping25, para otorgar mayor
prioridad a los paquetes, protocolos o servicios que decida el usuario. El resultado de
la aplicacin de este sistema de filtrado, sera una navegacin por Internet mucho ms
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 tamao
considerable y por lo tanto el tiempo de transferencia suele ser alto, se podra aadir
una aplicacin web para la gestin y monitorizacin 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 trmino traffic shaping se refiere a una tcnica de catalogacin del trfico para optimizar el
rendimiento de una red.
26
El trmino streaming se refiere a un servicio para la reproduccin de contenidos multimedia

directamente desde una pgina web.
93
Bibliografa y
Referencias
BIBLIOGRAFA DE CONSULTA
[MILL06]
Milln R. J. Domine las redes P2P: Peer to Peer orgenes, funcionamiento

y legislacin del P2P, seleccin y configuracin del acceso de banda
ancha a Internet. Creaciones Copyright. ISBN 849630020X.
[TAVE08]
Tavera M. L. Apuntes de la asignatura Tecnologas avanzadas de

sistemas operativos. Universidad Pontificia de Comillas de Madrid.
[STEV02]
Stevens P., Pooley R. Traduccin de Alarcn M., Sanjun O., Prez F.

Utilizacin de UML en ingeniera del software. Addison Wesley. ISBN
9788478290864
[BARR01]
Barranco J. Metodologa del anlisis estructurado de sistemas.

Universidad Pontificia de Comillas de Madrid. ISBN 8484680436.
[ESQU08]
Esquivel J. C. Apuntes de la asignatura Ingeniera del software II.

Universidad Pontificia de Comillas de Madrid.
[ECKE02]
Eckel B. Traduccin de Gonzlez J. Thinking in Java. Prentice Hall. ISBN

8420531928.
[RUST04]
Rusty E. Java Network Programming. OREILLY. 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. Revisin Barahona E, Snchez B. Diccionario de informtica e

Internet. McGraw Hill. ISBN 8448138600.
[GOME02]
Gmez M. J., de Pino L. Diccionario ingls-espaol de informtica y

telecomuniacaciones. McGraw Hill. ISBN 8448136403.
95
REFERENCIAS BIBLIOGRFICAS
[AFAN06]
Afanador J. A., Ribero D. F., Ulloa G. E. Redes P2P y enrutamiento en

capa de de aplicacin. Revista Sistemas N 98.
[SANT07]
Santn A. Peer 2 Peer. Sistemas Operativos Distribuidos. http://jungla.

dit.upm.es/~joaquin/so/p2p/p2p.pdf
[RODE05]
Rodero L., Fernndez A., Lpez L., Cholvi V. Topologas dinmicas en

redes P2P no estructuras. XV Jornadas Telecom I+D.
[MUO04]
Muoz 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]
Garca A. Apuntes de la asignatura Redes de ordenadores. Universidad

Pontificia de Comillas de Madrid.
96
[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 Aplicacin
Cliente
NDICE
1. INTRODUCCIN ............................................................................................... 101
1.1. OBJETIVO DEL MANUAL DE USUARIO ........................................................................... 101
1.2. OBJETIVO DE LA APLICACIN ........................................................................................ 101
2. ENTORNO DE LA APLICACIN ........................................................................... 101

2.1. REQUISITOS HARDWARE ............................................................................................... 101
2.2. REQUISITOS SOFTWARE ................................................................................................ 103
3. INSTALACIN DE LA APLICACIN...................................................................... 103

4. EJECUCIN DE LA APLICACIN ......................................................................... 103
4.1. CONEXIN A LA RED P2P .............................................................................................. 103
4.2. BSQUEDAS DE ARCHIVOS ........................................................................................... 104
4.3. TRANSFERENCIAS .......................................................................................................... 105
4.4. ARCHIVOS LOCALES....................................................................................................... 107
5. ESTRUCTURA DE DIRECTORIOS Y ARCHIVOS ..................................................... 108

5.1. DIRECTORIOS DE LA APLICACIN .................................................................................. 108
5.2. ARCHIVOS DE LA APLICACIN ....................................................................................... 109
6. INCIDENCIAS MS FRECUENTES ....................................................................... 110

7. MENSAJES DE AVISO ........................................................................................ 110
7.1. AVISO DE NO CONEXIN ............................................................................................... 110
7.2. AVISO DE NO SELECCIN DE ARCHIVO ......................................................................... 111
7.3. CONFIRMACIN DE CIERRE........................................................................................... 111
8. MENSAJES DE ERROR ....................................................................................... 112

8.1. ERROR EN LA CONEXIN ............................................................................................... 112
8.2. ERROR EN LA BSQUEDA DE ARCHIVOS ....................................................................... 112
8.3. ERROR EN LA OBTENCIN DE DIRECCIONES IP ............................................................. 112
8.4. ERROR DE OBTENCIN DE ARCHIVOS LOCALES............................................................ 113
8.5. ERROR EN LA DESCONEXIN......................................................................................... 113
9. GLOSARIO DE TRMINOS ................................................................................. 113
TABLA DE FIGURAS
IDENTIFICADOR
DESCRIPCIN
PGINA
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
Parmetros de bsqueda de archivos
Tabla de resultados de una bsqueda
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
Previsualizacin de un archivo de vdeo
Ventana de recursos locales
Acciones sobre los archivos locales
Aviso de desconexin del cliente
Aviso de archivo no seleccionado
Confirmacin de cierre de la aplicacin
Aviso de error en la conexin
Error en la bsqueda de archivos
Error en la obtencin de direcciones IP
Aviso de error en la obtencin de archivos locales
Aviso de error en la obtencin de archivos locales
101
102
102
104
104
105
105
106
106
106
107
108
108
111
111
111
112
112
113
113
113
1. INTRODUCCIN
1.1 OBJETIVO DEL MANUAL DE USUARIO
El objetivo del presente manual es facilitar al usuario el aprendizaje y uso de la
de la aplicacin cliente que se ha desarrollado. Contiene descripciones y detalles de
todos los componentes de la aplicacin, as como las especificaciones de las posibles
opciones que se ofrecen.
1.2 OBJETIVO DE LA APLICACIN
El objetivo de la aplicacin cliente es ofrecer una aplicacin que se conecte a una
red P2P en la que se ha mejorado el proceso de bsqueda de los archivos entre los
usuarios. Se entiende por mejora la eliminacin de la dependencia del proceso de
bsqueda al servidor al que el usuario se encuentre conectado. Adems la aplicacin
ofrece la posibilidad de gestin de archivos, en lo que respecta la bsqueda y
transferencia de estos as como de la gestin de los recursos locales que se ponen a
disposicin de la red P2P.
2. ENTORNO DE LA APLICACIN
2.1 REQUISITOS HARDWARE
Para una correcta ejecucin de la aplicacin, los requisitos hardware son los
especificados por Sun Microsystems para el entorno de ejecucin de Java 5.0 JRE (Java
Runtime Environment).
Los requisitos para sistemas Solaris son los que se describen a continuacin.
PLATAFORMA
VERSIN
Sistema operativo
Sistema operativo
Solaris AMD64/EM64T
Solaris 10
MEMORIA
ESPACIO EN DISCO
64 MB
Instalacin de 32 bits en 53 MB
Figura 1. Requisitos para sistemas Solaris
101
Los requisitos para sistemas Windows son los que se describen a continuacin.
PLATAFORMA
Intel de 32 bits
VERSIN
Windows XP Professional
SP1
Windows XP Home
Windows 2000 Professional
SP3 o posterior
Windows 98 2 edicin
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
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 continuacin.
PLATAFORMA
VERSIN
MEMORIA
Red Hat 9.0

Red Hat Enterprise Linux
AS 3.0
64 MB
ESPACIO EN DISCO
64 MB

WS 2.1
64 MB

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 versin 1
64 MB
58 MB
102

Sun Java Desktop
System versin 2
Arquitectura Intel de 32 bits
64 MB
58 MB
Red Hat Enterprise

Linux AS 3.0
58 MB
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 ejecucin de la aplicacin, el requisito software es la
instalacin del
el entorno de ejecucin de Java 5.0 JRE (Java
(Java Runtime Environment).
Environment
El archivo ejecutable contiene las referencias a libreras externas para la
ejecucin de la interfaz grfica de usuario Java Swing Look and Feel of Mosfet Liquid
KDE 3.x. Para ms informacin acerca de esta librera, visitar la pgina web
https://liquidlnf.dev.java.net/
3. INSTALACIN DE LA APLICACIN
El archivo dee instalacin se distribuye con la extensin jar.. Si el sistema operativo
instalado reconoce esta extensin, pinchar repetidamente sobre el icono del archivo
para su ejecucin. En caso de que el sistema operativo no reconozca este tipo de
extensin, ser necesario asociar la extensin jar con el programa java..
4. EJECUCIN DE LA APLICACIN
4.1 CONEXIN A LA RED P2P
Para conectar el cliente a la red P2P, pulsar el botn con
con el icono
localizado
en la barra de herramientas de la aplicacin. Una vez conectado el cliente aparecer el

icono
, pulsar sobre l para la desconexin de la aplicacin.
103
4.2 BSQUEDAS DE ARCHIVOS

Para comenzar las bsquedas de archivos, pulsar sobre el icono
localizado en la
barra de herramientas de la aplicacin. A continuacin aparecer una ventana en la

que en la parte superior izquierda se encuentran los parmetros a introducir para
comenzar la bsqueda.
Figura 4.
4 Parmetros de bsqueda de archivos
Para comenzar la bsqueda, introducir la cadena de bsqueda y presionar la

tecla Enter o pinchar sobre el botn Search.. Con el fin de limitar los resultados de las
bsquedas, se puede introducir el tipo de archivo a buscar, seleccionndolo del
componente desplegable.
Los resultados de la bsqueda se mostrarn en una tabla de la parte derecha de
la ventana. Una vez se muestren
muestren los resultados obtenidos, los botones Comments y
Download se activarn.
Figura 5.
5 Tabla de resultados de una bsqueda
104
Cuando algn resultado de la bsqueda contenga el valor
, se podr iniciar
una bsqueda de una bsqueda de comentarios de un archivo.

Para iniciar una bsqueda de comentarios de un archivo, seleccionar el archivo
de la tabla de resultados y pinchar sobre el botn Comments.. Cuando se obtengan los
comentarios del archivo seleccionado, se mostrar una ventana con los resultados.
La evaluacin que puede recibir un archivo es good,, indicada por el icono

bad, indicada por el icono
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 aplicacin. A
continuacin 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
Figura 8. Acciones sobre los archivos en estado de descarga
Seleccionando la accin Add comment,, aparecer una ventana en la que se podr

aadir un nuevo comentario al archivo. Para aadir un nuevo comentario, escribir la
descripcin del comentario y elegir la evaluacin del archivo entre los distintos valores,
Not evaluated, Good o Bad.
Bad Una vez introducidos
roducidos estos valores pinchar sobre el botn
Accept.
Figura 9.. Ventana de registro de un nuevo comentario
Seleccionando la accin See comments,, aparecer una ventana en la que se

mostrarn los comentarios del archivo. La evaluacin 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 accin Preview download,, el archivo seleccionado se

previsualizar utilizando en programa asociado a la extensin del archivo. La
previsualizacin 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 instalacin del
reproductor VideoLAN VLC media player, disponible en la pgina web
http://www.videolan.org/
106
La previsualizacin
ualizacin 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
seleccin de esta opcin hasta la reproduccin del archivo puede ser considerable.
Figura 11.
11 Previsualizacin de un archivo de vdeo
Seleccionando la accin Cancel download,, la descarga del archivo seleccionado

se anular y todos los archivos e informacin relativa a est sern eliminados.
4.4 ARCHIVOS LOCALES
Para gestionar los archivos locales que se ponen a disposicin de la red P2P,
pinchar sobre el icono
localizado en la barra de herramientas de la aplicacin. A
continuacin aparecer una ventana en la que en la parte derecha se encuentran una

tabla que contiene
ontiene los archivos que se ponen a disposicin de otros clientes de la red y
que se encuentran localizados en el directorio Incoming.
107
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 accin Add comment, aparecer una ventana en la que se podr

aadir un nuevo comentario al archivo. Para aadir un nuevo comentario, escribir la
descripcin del comentario y elegir la evaluacin del archivo entre los distintos valores.
Ver figura 8.
Seleccionando la accin See comments, aparecer una ventana en la que se
mostrarn los comentarios del archivo. Ver figura 9
Seleccionando la opcin Reload shares, se recarga en la aplicacin 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 APLICACIN
Cuando se instala la aplicacin, se crea una estructura de directorios para el
almacenamiento y gestin de archivos, tanto los transferidos a la red P2P, como los
necesarios para la ejecucin de la aplicacin. A continuacin se detalla cada uno de
estos directorios.
108
Config. Directorio que contiene archivos necesarios para la ejecucin de la

aplicacin.
Incoming. Directorio donde se alojan los archivos descargados por el cliente y
los que se ponen a disposicin de la red P2P. Dentro de este directorio se
puede realizar cualquier tipo de distribucin de otros directorios, ya que la
aplicacin tomar este como raz 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
previsualizacin de los archivos que se estn descargando. Por motivos de
gestin del espacio de almacenamiento del disco, al cerrar la aplicacin, 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 APLICACIN
Los archivos que maneja la aplicacin son lo que se detallan a continuacin.
Comments.dat. Archivo que contiene la evaluacin y los comentarios que el
usuario realiza sobre la calificacin de un determinado archivo.
Downloads.dat. Archivo que contiene informacin relativa de los archivos que
se estn descargando, como el fichero temporal asociado a la descarga, el
nombre, la extensin, el tamao y el valor de la funcin hash.
Hashes.dat. Ya que el clculo del valor de la funcin 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
6. INCIDENCIAS MS FRECUENTES
La resolucin adecuada para la ejecucin del cliente es 1152 por 864 pxeles. Si al
ejecutar la aplicacin no se ven todos los componentes o se ve partes de stos, es que
la resolucin actual no es la indicada anteriormente. Para solucionar el problema,
cambiar la resolucin de la pantalla a 1152 por 864 pxeles o en su defecto a la ms
aproximada.
El proceso de conexin del cliente al servidor de la red P2P, es un proceso largo,
por lo que tiempo que transcurre desde que se inicia la conexin hasta que el cliente
se conecta, puede ser considerable. Si despus de unos minutos el cliente no se ha
conectado a la red, comprobar la conexin a Internet, ya que el problema es de la
conexin y no del cliente. En caso de tener instalado en el sistema un firewall, aplicar
las polticas de seguridad adecuadas para permitir la ejecucin de la aplicacin cliente.
La previsualizacin 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 msica, no se ve la imagen o no se escucha sonido
alguno, es por la falta de instalacin de algn cdec en el sistema. Se recomienda la
instalacin del reproductor VideoLAN VLC media player, disponible en la pgina web
http://www.videolan.org/
7. MENSAJES DE AVISO
La aplicacin maneja diversos tipos de mensajes de aviso para advertir al usuario
de las distintas incidencias que ocurren en tiempo de ejecucin por la accin que se ha
realizado. A continuacin se describe cada unos de estos mensajes de aviso.
7.1 AVISO DE NO CONEXIN
Este aviso aparece cuando el cliente no se encuentra conectado a la red P2P.
Mientras el cliente no se encuentre conectado, no se podrn realizar bsquedas en la
red, ni tampoco transferencia alguna. Tampoco se iniciarn las descargas pendientes
en el sistema.
110
Para solucionar el problema, pulsar el botn con el icono
localizado en la
barra de herramientas de la aplicacin.
Figura 14.
14 Aviso de desconexin del cliente
7.2 AVISO DE NO SELECCIN DE ARCHIVO

Este aviso aparece cuando el usuario ha ejecutado una accin y no hay ningn
archivo seleccionado. Para solucionar el problema, pinchar
pinchar el archivo sobre el que se
desea ejecutar la accin.
Figura 15.
15 Aviso de archivo no seleccionado
7.3 CONFIRMACIN DE CIERRE

Este aviso aparece cuando el usuario pincha sobre el icono de cierre de la
aplicacin cliente. Pulsar Yes para cerrar la aplicacin o No para continuar con la
ejecucin.
Figura 16.
16 Confirmacin de cierre de la aplicacin
111
8. MENSAJES DE ERROR
La aplicacin maneja diversos tipos de mensajes de error para advertir al usuario
de las distintas
istintas incidencias que ocurren en tiempo de ejecucin por la accin que se ha
realizado. A continuacin se describe cada unos de estos mensajes de aviso.
8.1 ERROR EN LA CONEXIN
Este aviso aparece cuando por algn motivo ajeno al cliente, no se ha podido
realizar la conexin con el servidor de la red.
red Para solucionar el problema, vuelva a
intentar la conexin del cliente, pulsando el botn con el icono
Figura 17.
17 Aviso de error en la conexin
8.2 ERROR EN LA BSQUEDA DE ARCHIVOS

obtener las direcciones IP de los clientes disponen de un determinado fichero.
fichero
Figura 18.
18 Error en la bsqueda de archivos
8.3 ERROR EN LA OBTENCIN DE DIRECCIONES IP

obtener las direcciones IP de los clientes disponen de un determinado fichero.
fichero
112
Figura 19. Error en la obtencin de direcciones IP
8.4 ERROR DE OBTENCIN DE ARCHIVOS LOCALES

Este aviso aparece cuando ocurre un error en el clculo del identificador del
archivo, al aplicar el algoritmo SHA1.
Figura 20. Aviso de error en la obtencin de archivos locales
8.5 ERROR EN LA DESCONEXIN

Este aviso aparece cuando ocurre algn error por algn motivo ajeno al cliente
no se ha podido registrar la desconexin en el servidor.
Figura 21. Aviso de error en la obtencin de archivos locales
9. GLOSARIO DE TRMINOS
Red P2P. Conjunto de equipos conectados por medio de un mtodo de
transporte de datos en el que se comparten recursos y en el que no estn definidos ni
clientes ni servidores fijos.
113
JRE. (Java Runtime Environment). Conjunto de utilidades que permiten la

ejecucin de aplicaciones realizadas bajo el lenguaje de programacin 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 ms alto
se denomina raz y los que se encuentran dentro de ste, subdirectorios.
Funcin hash. Mtodo de generacin de claves que identifican de manera
unvoca un archivo. Un hash es el valor obtenido despus de haber aplicado la funcin.
Direccin IP. Nmero binario de 32 bits que identifica de manera inequvoca a
una mquina conectada a una red con el objetivo de comunicarse intercambiando
paquetes de informacin.
Puerto. Forma genrica de denominar una interfaz por la cual diferentes tipos de
datos pueden ser enviados o recibidos. Esta interfaz puede ser fsica o lgica.
Firewall. Sistema que est configurado para controlar el flujo de trfico entre dos
redes, permitiendo o denegando servicios dentro de una red.
SHA1. (Secure Hash Algorithm). Algoritmo de funcin hash diseado 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 Aplicacin
Servidor
NDICE
1. INTRODUCCIN ................................................................................................ 118
1.1. OBJETIVO DEL MANUAL DE USUARIO ........................................................................... 118
1.2. OBJETIVO DE LA APLICACIN ........................................................................................ 118
2. ENTORNO DE LA APLICACIN ............................................................................ 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. DEFINICIN DE TABLAS ................................................................................................. 121
4. INSTALACIN DE LA APLICACIN ...................................................................... 123

5. ARCHIVO DE REGISTRO DE ERRORES ................................................................. 123
6. ARCHIVOS DE LA APLICACIN ........................................................................... 124
7. GLOSARIO DE TRMINOS .................................................................................. 124
TABLA DE FIGURAS
IDENTIFICADOR
Figura 1
Figura 2
Figura 3
Figura 4
DESCRIPCIN
Requisitos para sistemas Solaris
Requisitos para sistemas Windows
Requisitos para sistemas Linux
Fichero de registro de errores
PGINA
118
118
119
123
1. INTRODUCCIN
1.1 OBJETIVO DEL MANUAL DE USUARIO
El objetivo del presente manual es facilitar al usuario el aprendizaje y uso de la
de la aplicacin servidor que se ha desarrollado. Contiene descripciones y detalles de
todos los componentes de la aplicacin, as como las especificaciones de las posibles
opciones que se ofrecen.
1.2 OBJETIVO DE LA APLICACIN
El objetivo de la aplicacin servidor es ofrecer una aplicacin que gestione las
bsquedas que demandan los clientes que se encuentran conectados a l.
2. ENTORNO DE LA APLICACIN
2.1 REQUISITOS HARDWARE
Para una correcta ejecucin de la aplicacin, los requisitos hardware son los
especificados por Sun Microsystems para el entorno de ejecucin de Java 5.0 JRE (Java
Runtime Environment).
Los requisitos para sistemas Solaris son los que se describen a continuacin.
PLATAFORMA
VERSIN
Sistema operativo
Sistema operativo
Solaris AMD64/EM64T
Solaris 10
MEMORIA
ESPACIO EN DISCO
64 MB
Figura 1. Requisitos para sistemas Solaris
Los requisitos para sistemas Windows son los que se describen a continuacin.
PLATAFORMA
VERSIN
Intel de 32 bits
Windows XP Professional
SP1
Windows XP Home
Windows 2000
Professional SP3 o
posterior
Windows 98 2 edicin
Windows ME
MEMORIA
ESPACIO EN DISCO
64 MB
64 MB
64 MB
98 MB
64 MB
64 MB
118

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
Windows Server 2003,

128 MB
98 MB
Windows Server 2003

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 continuacin.
PLATAFORMA
VERSIN
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 versin 1
64 MB
Sun Java Desktop

System versin 2
64 MB
58 MB
Red Hat Enterprise

Linux AS 3.0
58 MB
SLES 8
Red Hat Enterprise
Linux AS 3.0
56 MB
SLES 8
Figura 3. Requisitos para sistemas Linux
119
2.2 REQUISITOS SOFTWARE

Para una correcta ejecucin de la aplicacin, los requisitos software son la
instalacin del entorno de ejecucin 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 travs del driver Connector/J, MySQL proporciona conectividad para
aplicaciones cliente desarrolladas en el lenguaje de programacin 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 mquina 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 continuacin
Independencia de la plataforma. Al utilizar un driver 100% Java, se consigue
una independencia de la plataforma utilizada.
Rapidez. Ya que no es necesario ningn tipo de traduccin al lenguaje
soportado por el sistema gestor de bases de datos, la ejecucin de las
sentencias es ms rpida.
Facilidad de despliegue. Ya que no se utilizan libreras adicionales ni se
requiere la instalacin de software intermediario, el despliegue es mucho ms
sencillo.
El driver tipo 4, tambin denominado native-protocol all-Java, no requiere
instalacin en los clientes y es suministrado por la aplicacin en el archivo mysqlconnector-java-5.1.7-bin.jar.
Para ms informacin visitar la pgina web http://dev.mysql.com/downloads
/connector/j/5.1.html
120
3.2 DEFINICIN DE TABLAS

A continuacin se detallan las tablas y relaciones que componen la base de datos
de la aplicacin.
TABLA EXTENSIONS.
- Descripcin: contiene las extensiones de los archivos.
-
Sentencia de creacin: CREATE TABLE DELPHIC.EXTENSIONS(

TYPE VARCHAR(8) NOT NULL,
PRIMARY KEY(EXTENSION)
EXTENSIONS
PK
EXTENSION: varchar(6)
TYPE: varchar(8)
TABLA SHARES.
- Descripcin: contiene los archivos de los usuarios conectados a la red.
-
Sentencia de creacin: CREATE TABLE DELPHIC.SHARES(

SIZE BIGINT NOT NULL,
COUNTER INT NOT NULL DEFAULT 0,
PRIMARY KEY(NAME,HASH)
121
TABLA CLIENTS.
- Descripcin: contiene la informacin de los clientes conectados a la red.
- Relacin con: COMMENTS.
- Sentencia de creacin: CREATE TABLE DELPHIC.CLIENTS(
IP VARCHAR(15) NOT NULL,
PRIMARY KEY(IP,HASH)
TABLA COMMENTS.
- Descripcin: contiene los comentarios de los usuarios conectados a la red.
- Relacin con: CLIENTS.
-
Sentencia de creacin: CREATE TABLE DELPHIC.COMMENTS(

NCOMMENT INT NOT NULL AUTO_INCREMENT,
CLIENTIP VARCHAR(15) 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
4. INSTALACIN DE LA APLICACIN
El archivo de instalacin se distribuye con la extensin jar. Si el sistema operativo
instalado reconoce esta extensin, pinchar repetidamente sobre el icono del archivo
para su ejecucin. En caso de que el sistema operativo no reconozca este tipo de
extensin, ser necesario asociar la extensin jar con el programa java.
5. ARCHIVO DE REGISTRO DE ERRORES

Para la gestin y el control de errores por parte de los administradores del
servidor, la aplicacin 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 bsquedas, 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
continuacin.
<DA_DE_LA_SEMANA,MES,DA,HORA,AO>
Descripcin
del
error
<DIRECCIN_IP_CLIENTE>.
Figura 4. Fichero de registro de errores
123
6. ARCHIVOS DE LA APLICACIN
Los diferentes archivos que maneja la aplicacin son lo que se detallan a
continuacin.
Delphic.sql. Archivo que contiene las sentencias DDL (Data Definition
Language) para la creacin de las base de datos y las sentencias DML (Data
Manipulation Language) para la insercin 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 bsquedas.
7. GLOSARIO DE TRMINOS
JRE. (Java Runtime Environment). Conjunto de utilidades que permiten la
ejecucin de aplicaciones realizadas bajo el lenguaje de programacin 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 comunicacin entre la aplicacin

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 programacin 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 aplicacin sea independiente del sistema gestor de base de datos. JDBC est
basado en X/Open SQL CLI.
124
DDL. (Data Definition Language). Lenguaje suministrado por el sistema gestor de

bases de datos que permite realizar tareas de definicin 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 manipulacin de
datos.
125

Protocolp 2 P

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Protocolp 2 P

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

PROYECTO FIN DE CARRERA

LUIS MARA GARCA SANJUN

Autorizada la entrega del proyecto del alumno:

Luis Mara Garca Sanjun

EL DIRECTOR DEL PROYECTO

Jos Manuel Muoz Berengena

Vo Bo del Coordinador de Proyectos

David Contreras Brcena

UNIVERSIDAD PONTIFICIA COMILLAS

PROYECTO FIN DE CARRERA

AUTOR: LUIS MARA GARCA SANJUN

base, se ha realizado el diseo e implementacin de un protocolo independiente del

2. ESTADO DEL ARTE DE LAS APLICACIONES PEER-TO-PEER ..................................... 15

3. MOTIVACIN Y OBJETIVOS DEL PROYECTO ......................................................... 36

5. PROTOCOLO DEL SISTEMA .................................................................................. 68

5.1.6. SOLICITUD DE DESCONEXIN DE LA RED PEER-TO-PEER ....................................... 72

6. PROGRAMACIN Y PRUEBAS DEL SISTEMA ......................................................... 77

7. PLANIFICACIN DEL PROYECTO........................................................................... 82

9. CONCLUSIONES Y FUTURAS LNEAS DE DESARROLLO........................................... 90

Solicitud de bsqueda de direcciones IP a la red IP multicast

Diseo e implementacin de un protocolo peer-to-peer

1.1 INTRODUCCIN A LAS REDES PEER-TO-PEER

Figura 1. Arquitectura P2P

Diseo e implementacin de un protocolo peer-to-peer

transferencia1 disminuye ya que los recursos de los que dispone el servidor se

Figura 2. Arquitectura cliente-servidor

Diseo e implementacin de un protocolo peer-to-peer

contenido, el editor, el lector, el servidor que lo alberga y la peticin para

Diseo e implementacin de un protocolo peer-to-peer

Los servicios pueden clasificarse en servicios de pares y servicios de grupos de

Diseo e implementacin de un protocolo peer-to-peer

Figura 3. Modelo centralizado

El modelo totalmente descentralizado o puro se caracteriza porque no existe un

Figura 4. Modelo totalmente descentralizado

Diseo e implementacin de un protocolo peer-to-peer

El modelo semicentralizado o mixto es el ms extendido entre las arquitecturas

Figura 5. Modelo semicentralizado

1.1.4 CLASIFICACIN DE LAS REDES PEER-TO-PEER

Diseo e implementacin de un protocolo peer-to-peer

Diseo e implementacin de un protocolo peer-to-peer

Diseo e implementacin de un protocolo peer-to-peer

Diseo e implementacin de un protocolo peer-to-peer

Diseo e implementacin de un protocolo peer-to-peer

con hardware y sistemas operativos diversos. Para hacer esto posible el

Diseo e implementacin de un protocolo peer-to-peer

lectura, y en este tipo de aplicaciones el entorno es intensivo en lectura de datos, lo

Diseo e implementacin de un protocolo peer-to-peer

funciones. Su conectividad, velocidad, y seguridad hacen de MySQL Server

Diseo e implementacin de un protocolo peer-to-peer

2.1 ESTADO DEL ARTE

Diseo e implementacin de un protocolo peer-to-peer

los clientes que ejecutaban la aplicacin servidora.

Figura 6. Arquitectura de Hotline Connect

El trmino shareware se refiere a un tipo de distribucin de aplicaciones en la que el usuario puede

Diseo e implementacin de un protocolo peer-to-peer

El problema de la dependencia de las descargas al servidor al que el usuario se

Figura 7. Arquitectura de Napster

Diseo e implementacin de un protocolo peer-to-peer

El hecho de que Napster fuera un servicio centralizado result su perdicin ya

ed2k://|file|NOMBRE.EXTENSIN|TAMAO|HASH|. Opcionalmente se poda

Diseo e implementacin de un protocolo peer-to-peer