Protocolo de Redes

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
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
DESCRIPCIN
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
PGINA
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
Figura 41 Figura 42 Figura 43 Figura 44 Figura 45 Figura 46 Figura 47 Figura 48 Figura 49 Figura 50 Figura 51
DESCRIPCIN
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
PGINA
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. 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.
4
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. 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.
8
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. 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. 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.
11 10
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
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 12
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.
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.
14
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

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.
15
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
El trmino RIAA (Recording Industry Association of America) se refiere a una asociacin americana que representa a la industria discogrfica.
16
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 aMule eMule REDES eDonkey Kad eDonkey Kad ANNIMO No No LICENCIA GPL GPL PLATAFORMA Windows, Linux MAC OS Windows LENGUAJE C++ C++
BitTorrent eDonkey FastTrack MLDonkey Gnutella Gnutella2 Kad Lphant BitTorrent eDonkey BitTorrent eDonkey Gnutella Gnutella2 BitTorrent eDonkey FastTrack Gnutella Gnutella2 Overnet
No
GPL
Windows, Linux MAC OS
Ocaml
No
Freeware con Adware
Windows, Linux MAC OS
C#
Shareaza
No
GPL
Windows
C++
TrustyFile
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
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.
18
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
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].
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.
19
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
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.
20
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.
ADMITE DHT No TORRENTS ACTIVOS 8
NOMBRE ABC Ares Galaxy BitComet BitTornado BitSpirit Ktorrent Lphant
PLATAFORMA Windows Linux Windows Windows Windows, Linux MAC OS Windows Linux, MAC OS Windows, Linux MAC OS
LENGUAJE Python Delphi C++ Python C++ C++ C#
TRACKER No
Desconocido Desconocido Desconocido Descargas S 8 separadas S No No S No S S Desconocido 8 8 8 8
30
Diseo e implementacin de un protocolo peer-to-peer MLNet Rtorrent Shareaza Vuze Torrent Windows, Linux Ocalm MAC OS Linux, MAC OS C++ Windows C++ Windows, Linux Java y SWT MAC OS Windows, Linux C++ MAC OS No No No Integrado Integrado No No S S S 8 8 10 Sin lmite 8
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 y 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 usu usuarios 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 en la conexin de todos los basa 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 y
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.
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. 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.
22
21
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.
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.
23
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
Diseo e implementacin de un protocolo peer-to-peer EXTENSIONS PK EXTENSION: varchar(6) TYPE: varchar(8)
TABLA SHARES. - Descripcin: contiene los archivos de los usuarios conectados a la red. - Relacin con: ninguna tabla.
-
Sentencia de creacin: CREATE TABLE DELPHIC.SHARES(

NAME VARCHAR(256) NOT NULL, SIZE BIGINT NOT NULL, HASH CHAR(40) NOT NULL, EXTENSION VARCHAR(6) NOT NULL, COUNTER INT NOT NULL DEFAULT 0, PRIMARY KEY(NAME,HASH) )ENGINE=INNODB DEFAULT CHARSET=latin1;
TABLA CLIENTS. - 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, HASH CHAR(40) NOT NULL, NAME VARCHAR(256) NOT NULL, PRIMARY KEY(IP,HASH) )ENGINE=INNODB DEFAULT CHARSET=latin1;
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, HASH CHAR(40) NOT NULL, COMMENT VARCHAR(120), EVALUATION TINYINT, PRIMARY KEY(NCOMMENT), INDEX (CLIENTIP,HASH), FOREIGN KEY(CLIENTIP,HASH) REFERENCES DELPHIC.CLIENTS(IP,HASH) ON DELETE CASCADE)ENGINE=INNODB DEFAULT CHARSET=latin1;
COMMENTS PK FK1,I1 FK1,I1 NCOMMENT: int 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
PAQUETE REQUEST_COMMENTS. - Implementado por la clase: RequestIPsPacket. - Datos. El valor de la funcin hash que identifica un archivo en la red P2P. PAQUETE REPLY_ COMMENTS. - Implementado por la clase: ReplyIPsPacket. - Datos. Las direcciones IP de los clientes que tienen disponible un archivo determinado para su transferencia. 5.1.5 SOLICITUD DE 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
PAQUETE REQUEST_COMMENTS. - Implementado por la clase: StandardPacket. - Datos. La direccin IP del cliente que se desconecta de la red P2P. PAQUETE REPLY_ COMMENTS. - Implementado por la clase: StandardPacket. - Datos. Sin datos. El tipo de paquete transmitido es la propia 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. - Implementado por la clase: StandardPacket. - Datos. Sin datos. El tipo de paquete transmitido es la propia 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. - Implementado por la clase: StandardPacket. - Datos. Sin datos. El tipo de paquete transmitido es la propia sincronizacin del protocolo. PAQUETE END. - Implementado por la clase: StandardPacket. - Datos. Sin datos. El tipo de paquete transmitido es la propia sincronizacin del protocolo.
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
Figura 45. Costes de software
COSTE 700,00 800,00 1.500,00
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
Figura 46. Costes de tecnologa
COSTE 1.315,00 1.500,00 2.815,00
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.
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 -----
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 Reunin de seguimiento Interfaz del cliente Lgica del cliente Programacin del cliente Pruebas unitarias Pruebas de integracin Pruebas de aceptacin Reunin de seguimiento Documentacin Anexos Reunin de finalizacin
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 Total
Figura 48. Costes de implantacin
NMERO DE HORAS 15 25 150 285
COSTE/HORA 100,00 80,00 60,00 40,00
COSTE 1.500,00 2.000,00 9.000,00 11.400,00 23.900,00
8.3 VALORACIN FINAL

En total, los costes del desarrollo del proyecto ascienden a una cantidad de 26.865,00 . CONCEPTO Costes de tecnologa DETALLE Costes de hardware Costes de software Director de proyecto Jefe de proyecto Analista Programador COSTE 1.315,00 1.500,00 1.500,00 2.000,00 9.000,00 11.400,00 150,00 26.865,00
Figura 49. Costes de desarrollo del proyecto
Costes de implantacin
Otros gastos Total
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
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.
24
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.
El trmino traffic shaping se refiere a una tcnica de catalogacin del trfico para optimizar el rendimiento de una red. El trmino streaming se refiere a un servicio para la reproduccin de contenidos multimedia directamente desde una pgina web.
26
25
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] [MYSQ09] Rusty E. Java Network Programming. OREILLY. ISBN 0596007213. 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] [MONK03] http://www.haxial.com/products/kdx/index2.html 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] [AMIL06] http://isohunt.com/forum/viewtopic.php?t=145853 Amilmani, K. Studying and enhancing the BitTorrent protocol. Stony Brook University. [SOTO06] [GARC05] Soto P. http://www.pablosoto.com/2006/11/omemo.html 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 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 DESCRIPCIN 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 PGINA 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 MEMORIA 64 MB ESPACIO EN DISCO Instalacin de 32 bits en 53 MB Instalacin de 64 bits en 23 MB
Sistema operativo Sistema operativo Solaris AMD64/EM64T Solaris 10
Figura 1. Requisitos para sistemas Solaris
101
Los requisitos para sistemas Windows son los que se describen a continuacin.
PLATAFORMA 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 Windows Server 2003 Standard Edition Windows Server 2003 Enterprise Edition Windows Server 2003 DataCenter Edition AMD Opteron de 32 bits AMD Opteron de 64 bits Windows Server 2003 AMD Opteron de 32 bits Windows Server 2003 AMD Opteron de 32 bits MEMORIA 64 MB 64 MB 64 MB 64 MB 64 MB 128 MB 128 MB 128 MB 128 MB 128 MB 128 MB 98 MB 110 MB 98 MB ESPACIO EN DISCO
Intel de 32 bits
Figura 2. Requisitos para sistemas Windows
Los requisitos para sistemas Linux son los que se describen a continuacin. PLATAFORMA VERSIN
Red Hat 9.0 Red Hat Enterprise Linux AS 3.0 Red Hat Enterprise Linux WS 2.1 Red Hat Enterprise Linux ES 2.1 Arquitectura Intel de 32 bits Red Hat Enterprise Linux AS 2.1 SuSE 8.2 SLEC 8 SLES 8 TurboLinux 8.0 Sun Java Desktop System versin 1
MEMORIA
64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB
ESPACIO EN DISCO
58 MB
102
Diseo e implementacin de un protocolo peer-to-peer Arquitectura Intel de 32 bits Sun Java Desktop System versin 2 Red Hat Enterprise Linux AS 3.0 SLES 8 Red Hat Enterprise Linux AS 3.0 SLES 8 Figura 3 Requisitos para sistemas Linux 3. 64 MB 58 MB
AMD Opteron de 32 bits
58 MB
56 MB
2.2 REQUISITOS SOFTWARE Para una correcta ejecucin de la aplicacin, el requisito software es la instalacin del entorno de ejecucin de Java 5.0 JRE (Java Runtime Environment el (Java 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 de instalacin se distribuye con la extensin jar. Si el sistema operativo e . 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 el icono con 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 Parmetros de bsqueda de archivos 4.
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 los resultados obtenidos, los botones Comments y muestren Download se activarn.
Figura 5 Tabla de resultados de una bsqueda 5.
104
Cuando algn resultado de la bsqueda contenga el valor una bsqueda de una bsqueda de comentarios de un archivo.
, se podr iniciar
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 Ventana de comentarios de un archivo 6.
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 Tabla de descargas actuales del cliente 7.
En la parte superior izquierda se encuentran las acciones que se pueden realizar rior 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 Una vez introducidos estos valores pinchar sobre el botn Bad. roducidos 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 Ventana de comentarios de un archivo 10.
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 es de la calidad esperada. o 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 del un archivo es un proceso complejo, ya que hay que unir ualizacin 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 Previsualizacin de un archivo de vdeo 11.
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 los archivos que se ponen a disposicin de otros clientes de la red y ontiene 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 barra de herramientas de la aplicacin.
localizado en la
Figura 14 Aviso de desconexin del cliente 14.
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 el archivo sobre el que se pinchar desea ejecutar la accin.
Figura 15 Aviso de archivo no seleccionado 15.
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 Confirmacin de cierre de la aplicacin 16.
111
8. MENSAJES DE ERROR
La aplicacin maneja diversos tipos de mensajes de error para advertir al usuario de las distintas incidencias que ocurren en tiempo de ejecucin por la accin que se ha istintas 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 Para solucionar el problema, vuelva a red. intentar la conexin del cliente, pulsando el botn con el icono .
Figura 17 Aviso de error en la conexin 17.
8.2 ERROR EN LA BSQUEDA DE ARCHIVOS Este aviso aparece cuando por algn motivo ajeno al cliente, no se ha podido obtener las direcciones IP de los clientes disponen de un determinado fichero fichero.
Figura 18 Error en la bsqueda de archivos 18.
8.3 ERROR EN LA OBTENCIN DE DIRECCIONES IP Este aviso aparece cuando por algn motivo ajeno al cliente, no se ha podido 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 MEMORIA 64 MB ESPACIO EN DISCO Instalacin de 32 bits en 53 MB Instalacin de 64 bits en 23 MB
Sistema operativo Sistema operativo Solaris AMD64/EM64T Solaris 10
Figura 1. Requisitos para sistemas Solaris
Los requisitos para sistemas Windows son los que se describen a continuacin. PLATAFORMA VERSIN
Windows XP Professional SP1 Windows XP Home Windows 2000 Professional SP3 o posterior Windows 98 2 edicin Windows ME
MEMORIA
64 MB 64 MB 64 MB 64 MB 64 MB
ESPACIO EN DISCO
Intel de 32 bits
98 MB
118
Diseo e implementacin de un protocolo peer-to-peer Windows Server 2003 Web 128 MB Edition Windows Server 2003 Standard Edition Windows Server 2003 Enterprise Edition Windows Server 2003 DataCenter Edition AMD Opteron de 32 bits AMD Opteron de 64 bits Windows Server 2003, AMD Opteron de 32 bits Windows Server 2003 AMD Opteron de 32 bits 128 MB 98 MB 128 MB 128 MB 128 MB 128 MB 98 MB 110 MB
Intel de 32 bits
Figura 2. Requisitos para sistemas Windows
Los requisitos para sistemas Linux son los que se describen a continuacin. PLATAFORMA VERSIN
Red Hat 9.0 Red Hat Enterprise Linux AS 3.0 Red Hat Enterprise Linux WS 2.1 Red Hat Enterprise Linux ES 2.1 Arquitectura Intel de 32 bits Red Hat Enterprise Linux AS 2.1 SuSE 8.2 SLEC 8 SLES 8 TurboLinux 8.0 Sun Java Desktop System versin 1 Arquitectura Intel de 32 bits Sun Java Desktop System versin 2 Red Hat Enterprise Linux AS 3.0 SLES 8 Red Hat Enterprise Linux AS 3.0 SLES 8 Figura 3. Requisitos para sistemas Linux
MEMORIA
64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB 64 MB
ESPACIO EN DISCO
58 MB
58 MB
58 MB
56 MB
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. - 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;
EXTENSIONS PK EXTENSION: varchar(6) TYPE: varchar(8)
TABLA SHARES. - Descripcin: contiene los archivos de los usuarios conectados a la red. - Relacin con: ninguna tabla.
-
Sentencia de creacin: CREATE TABLE DELPHIC.SHARES(

NAME VARCHAR(256) NOT NULL, SIZE BIGINT NOT NULL, HASH CHAR(40) NOT NULL, EXTENSION VARCHAR(6) NOT NULL, COUNTER INT NOT NULL DEFAULT 0, PRIMARY KEY(NAME,HASH) )ENGINE=INNODB DEFAULT CHARSET=latin1;
121
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, HASH CHAR(40) NOT NULL, NAME VARCHAR(256) NOT NULL, PRIMARY KEY(IP,HASH) )ENGINE=INNODB DEFAULT CHARSET=latin1;
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, HASH CHAR(40) NOT NULL, COMMENT VARCHAR(120), EVALUATION TINYINT, PRIMARY KEY(NCOMMENT), INDEX (CLIENTIP,HASH), FOREIGN KEY(CLIENTIP,HASH) REFERENCES DELPHIC.CLIENTS(IP,HASH) ON DELETE CASCADE)ENGINE=INNODB DEFAULT CHARSET=latin1;
COMMENTS PK FK1,I1 FK1,I1 NCOMMENT: int 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> <DIRECCIN_IP_CLIENTE>. Descripcin del error
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

Protocolo de Redes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protocolo de Redes

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

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

Vo Bo del Coordinador de Proyectos

David Contreras Brcena

UNIVERSIDAD PONTIFICIA COMILLAS

PROYECTO FIN DE CARRERA

DISEO E IMPLEMENTACIN DE UN PROTOCOLO DE REDES PEER-TO-PEER

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

3. MOTIVACIN Y OBJETIVOS DEL PROYECTO ......................................................... 36 4. ANLISIS DEL SISTEMA........................................................................................ 41

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

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

7. PLANIFICACIN DEL PROYECTO........................................................................... 82 8. VALORACIN ECONMICA DEL PROYECTO ......................................................... 85

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

Figura 2. Arquitectura cliente-servidor

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

Figura 3. Modelo centralizado

Figura 4. Modelo totalmente descentralizado 6

Diseo e implementacin de un protocolo peer-to-peer

Figura 5. Modelo semicentralizado

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

Diseo e implementacin de un protocolo peer-to-peer

Diseo e implementacin de un protocolo peer-to-peer

Captulo 2 Estado del Arte de las Aplicaciones Peer-to-Peer

Diseo e implementacin de un protocolo peer-to-peer

2.1 ESTADO DEL ARTE

Diseo e implementacin de un protocolo peer-to-peer

Figura 6. Arquitectura de Hotline Connect

Diseo e implementacin de un protocolo peer-to-peer

Figura 7. Arquitectura de Napster 18

Diseo e implementacin de un protocolo peer-to-peer

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

Diseo e implementacin de un protocolo peer-to-peer

Figura 8. Arquitectura de eDonkey

Diseo e implementacin de un protocolo peer-to-peer

Windows, Linux MAC OS

Freeware con Adware

Windows, Linux MAC OS

Figura 9. Clientes eDonkey

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

Diseo e implementacin de un protocolo peer-to-peer

Figura 10. Cantidad de contenido compartido de BitTorrent

Diseo e implementacin de un protocolo peer-to-peer

Figura 11. Enjambre de BitTorrent

Diseo e implementacin de un protocolo peer-to-peer