Está en la página 1de 140
UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO EN INFORMÁTICA

PROYECTO FIN DE CARRERA

DISEÑO E IMPLEMENTACIÓN DE UN PROTOCOLO DE REDES PEER-TO-PEER

LUIS MARÍA GARCÍA SANJUÁN

MADRID,

JUNIO DE 2009

Autorizada la entrega del proyecto del alumno:

Luis María García Sanjuán

EL DIRECTOR DEL PROYECTO

José Manuel Muñoz Berengena

Fdo:

Fecha:

V o B o del Coordinador de Proyectos

David Contreras Bárcena

Fdo:

Fecha:

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO EN INFORMÁTICA

PROYECTO FIN DE CARRERA

DISEÑO E IMPLEMENTACIÓN DE UN PROTOCOLO DE REDES PEER-TO-PEER

AUTOR: LUIS MARÍA GARCÍA SANJUÁN

DIRECTOR: JOSÉ MANUEL MUÑOZ BERENGENA

MADRID,

JUNIO DE 2009

A mi madre y a mi hermana.

Dicen que “quien convive con lo que admira termina imitándolo”, y la dedicación y entrega que mostráis cada día en vuestro trabajo ha sido para mí todo un ejemplo a seguir, guiándome hacia el ocaso de esta etapa.

AGRADECIMIENTOS

Mi más sincero agradecimiento a José Manuel Muñoz Berengena, mi director de proyecto. Una vez terminado el trabajo, sólo me queda decir gracias y perdón. Gracias por todo el tiempo que me has dedicado, por tu ayuda e inagotable paciencia. Perdón por los momentos en los que el peso del proyecto me ha superado, y has tenido que transmitirme tu sosiego y tranquilidad.

Deseo expresar mi agradecimiento a David Contreras Bárcena, mi coordinador de proyecto, y a todos los profesores de la Escuela Técnica Superior De Ingeniería de la Universidad Pontificia Comillas de Madrid por su trabajo realizado durante estos años de carrera.

A Pilar Balda, Marta Galán y Marta Lozoya por ese día en el que os sentasteis a mi lado, regalándome así la oportunidad de conoceros. Gracias por todo vuestro cariño y por los momentos que habéis compartido conmigo.

Por último, no quisiera olvidarme de mis amigos Beatriz, Juan y Julio. Aunque ya sabéis lo mucho que os quiero, no está de más agradeceros el cómo sois y el estar, a pesar de la distancia, tan cerca de mí.

RESUMEN

Actualmente existe una gran variedad de clientes de redes peer-to-peer con diferentes finalidades, telefonía por Internet, sistemas de ficheros distribuidos, cálculo científico y demás. Probablemente, la finalidad con más uso sea la de búsqueda y transferencia de archivos.

Haciendo uso de determinadas aplicaciones que cubren esta finalidad, se puede comprobar que la búsqueda e intercambio de archivos de las actuales aplicaciones de redes peer-to-peer están muy condicionadas al servidor al que el cliente se encuentre conectado, ya que diferentes conexiones entre distintos servidores producen diferentes resultados. Por lo tanto, se puede concluir que existe un desequilibrio entre lo que ofrecen este tipo de aplicaciones y lo que demandan los usuarios. Por este motivo, el objetivo de este proyecto es el diseño e implementación de un protocolo peer-to-peer, que mejore el proceso de búsqueda de los archivos entre los usuarios que se encuentren conectados a la red. Se entiende por mejora la eliminación de la dependencia del proceso de búsqueda al servidor al que el usuario se encuentre conectado.

Para poder desarrollar el proyecto, es necesario que los servidores compartan la misma información acerca de los archivos y de los clientes que se encuentran conectados a la red peer-to-peer. Dado el gran número de clientes de este tipo de redes, es inviable que un servidor albergue toda ésta información, ya que manejaría una gran volumen de datos que además estaría duplicado en el resto de servidores. Por este motivo, la arquitectura propuesta se basa en la conexión de todos los servidores a una red IP multicast, para así poder distribuir la información por medio de mensajes, sin la necesidad de almacenarla en la base de datos de cada uno de ellos.

Cuando un cliente de la red peer-to-peer desea realizar una búsqueda de un determinado archivo, envía una solicitud de búsqueda al servidor al que se encuentra conectado. El servidor procesa la solicitud, realizando una consulta en su base de datos, en la que están registrados todos los archivos de los clientes con los que mantiene una conexión. Al finalizar la consulta, transmite la solicitud de búsqueda del

cliente a la red IP multicast para que todos los servidores, que se encuentran conectados a esta red, reciban dicha solicitud y consulten en sus bases de datos, al igual que hizo el primer servidor, para obtener los resultados que satisfacen la petición. Una vez consultada la base de datos, se envían los resultados al servidor que los solicitó para añadir esos resultados a los que ya tenía. Una vez terminado este proceso, todos los resultados se envían al cliente que inició el proceso de búsqueda.

Dado que el proyecto realizado tiene características de un sistema distribuido, el protocolo se ha implementado bajo el lenguaje de programación Java, para asegurar la portabilidad en entornos heterogéneos, con hardware y sistemas operativos diversos.

El protocolo implementado aporta una serie de mejoras tanto en los servidores como en los clientes. El número de archivos encontrados en el proceso de búsqueda, el número de comentarios de los usuarios que califican los archivos y el número de fuentes encontradas que tienen disponible el archivo para compartir son mayores, ya que se elimina la dependencia de la conexión con el servidor. Dado que el número de fuentes encontradas es mayor, se reduce considerablemente el tiempo de transferencia del archivo, ya que la posibilidad de conexión a un mayor número de pares se incrementa.

Al no existir una dependencia con el servidor, en los clientes no se requiere un mantenimiento de una lista de servidores en la que elegir sus favoritos y su prioridad en el proceso de conexión, por lo que se le libera de una tarea innecesaria. Al eliminar una preferencia de conexión entre un servidor u otro, las conexiones de los clientes entre los distintos servidores de la red están más equilibradas y por lo tanto el reparto de carga de trabajo entre estos y las solicitudes de búsqueda de un archivo entre los usuarios de la red estarán más equilibradas.

En el presente proyecto, se ha realizado un exhaustivo análisis sobre los sistemas actuales peer-to-peer de transferencia de archivos, detallando sus características, funcionamiento y mejoras con respecto a otros sistemas y, conjuntamente, se ha introducido el problema de las búsquedas de archivos en este tipo de redes. Sobre esa

base, se ha realizado el diseño e implementación de un protocolo independiente del servidor al que el usuario se encuentre conectado.

El sistema desarrollado se podría enmarcar dentro de los sistemas peer-to-peer estructurados, ya que se conoce la localización exacta de los recursos, pero sin la necesidad de que los clientes tengan que mantener una tabla hash para calcular el lugar en el que está cada recurso como sucede en el caso de las redes Pastry, CAN o Chord, proporcionando un mecanismo de búsqueda determinista, de tal forma que se asegura la localización de un recurso siempre y cuando se encuentre en la red, encaminando los mensajes de forma eficiente.

Con la realización de este proyecto, se suplen algunas carencias de las actuales aplicaciones de búsqueda y transferencia de archivos en redes peer-to-peer, como es el caso de la búsqueda de fuentes o de comentarios de un determinado archivo. Además, otras características y funcionalidades de estas aplicaciones se optimizan, como por ejemplo la previsualización de los archivos en estado de descarga y la gestión del espacio de los archivos temporales.

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

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.

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.

ÍNDICE

1. INTRODUCCIÓN

13

1.1.

INTRODUCCIÓN A LAS REDES PEER-TO-PEER

2

1.1.1. REDES PEER-TO-PEER

2

1.1.2. ELEMENTOS DE UNA RED PEER-TO-PEER

4

1.1.3. ARQUITECTURA DE LAS REDES PEER-TO-PEER

5

1.1.4. CLASIFICACIÓN DE LAS REDES PEER-TO-PEER

7

1.1.5. APLICACIONES DE REDES PEER-TO-PEER

9

1.1.6. PROBLEMAS DE LAS REDES PEER-TO-PEER

10

1.2.

TECNOLOGÍAS

11

1.2.1. JAVA

11

1.2.2. MYSQL

12

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

15

2.1. ESTADO DEL ARTE

16

2.2. CONCEPTOS Y TECNOLOGÍAS ACTUALES

33

2.2.1. P2P ANÓNIMO

33

2.2.2. REDES FRIEND-TO-FRIEND

34

2.2.3. PEER-TO-MAIL

34

2.2.4. WEBCACHÉ

35

2.2.5. PROACTIVE NETWORK PROVIDER PARTICIPATION FOR P2P

35

3. MOTIVACIÓN Y OBJETIVOS DEL PROYECTO

36

4. ANÁLISIS DEL SISTEMA

41

4.1.

IDENTIFICACIÓN DE NECESIDADES

42

4.1.1. ALCANCE DEL SISTEMA

42

4.1.2. TOPOLOGÍA DE USUARIOS FINALES

43

4.1.3. RESTRICCIONES

44

4.2.

ANÁLISIS DE REQUISITOS

44

4.2.1. CONTEXTO GENERAL DEL SISTEMA

44

4.2.2. ÁMBITO DEL SISTEMA

46

4.2.3. ÁMBITO DEL CLIENTE

46

4.2.4. ÁMBITO DEL SERVIDOR

48

4.2.5. DECISIONES DE DISEÑO

49

4.3.

METODOLOGÍA

52

4.3.1. DIAGRAMA DE DOMINIO

52

4.3.2. DIAGRAMA DE CASOS DE USO

54

4.3.3. DIAGRAMA DE PAQUETES

56

4.3.4. DIAGRAMA DE CLASES

58

4.3.5. DISEÑO DE LA BASE DE DATOS

65

5. PROTOCOLO DEL SISTEMA

68

5.1.

PROTOCOLO ENTRE CLIENTE Y SERVIDOR

69

5.1.1. SOLICITUD DE CONEXIÓN A LA RED PEER-TO-PEER

69

5.1.2. SOLICITUD DE BÚSQUEDA DE ARCHIVOS

69

5.1.3. SOLICITUD DE BÚSQUEDA DE COMENTARIOS

70

5.1.4. SOLICITUD DE BÚSQUEDA DE CLIENTES

70

5.1.5. SOLICITUD DE SINCRONIZACIÓN

71

5.1.6.

SOLICITUD DE DESCONEXIÓN DE LA RED PEER-TO-PEER

72

5.2.

PROTOCOLO ENTRE SERVIDORES

72

5.2.1. SOLICITUD DE CONEXIÓN A LA RED MULTICAST

72

5.2.2. SOLICITUD DE BÚSQUEDA DE ARCHIVOS

73

5.2.3. SOLICITUD DE BÚSQUEDA DE COMENTARIOS

73

5.2.4. SOLICITUD DE BÚSQUEDA DE CLIENTES

74

5.3.

PROTOCOLO ENTRE CLIENTES

75

6. PROGRAMACIÓN Y PRUEBAS DEL SISTEMA

77

6.1.

PROGRAMACIÓN

78

6.1.1. INTRODUCCIÓN

78

6.1.2. LENGUAJES DE PROGRAMACIÓN

78

6.1.3. MANUAL DE USUARIO

78

6.2.

PRUEBAS DEL SISTEMA

79

6.2.1. PRUEBAS DE ENCADENAMIENTO

80

6.2.2. PRUEBAS DE INTEGRACIÓN

80

6.2.3. PRUEBAS DE EXPLOTACIÓN DEL SISTEMA

80

6.2.4. PRUEBAS DE SOBRECARGA

80

6.2.5. PRUEBAS DE RECUPERACIÓN

80

6.2.6. PRUEBAS DE SEGURIDAD

81

6.2.7. PRUEBAS DE USABILIDAD

81

6.2.8. PRUEBAS DE ACEPTACIÓN DEL USUARIO

81

7. PLANIFICACIÓN DEL PROYECTO

82

8. VALORACIÓN ECONÓMICA DEL PROYECTO

85

8.1.

COSTES DE TECNOLOGÍA

86

8.1.1. COSTES DE HARDWARE

86

8.1.2. COSTES DE SOFTWARE

86

8.2. COSTES DE IMPLANTACIÓN

87

8.3. VALORACIÓN FINAL

89

9. CONCLUSIONES Y FUTURAS LÍNEAS DE DESARROLLO

90

BIBLIOGRAFÍA Y REFERENCIAS

94

ANEXO I. MANUAL DE USUARIO DE LA APLICACIÓN CLIENTE

98

ANEXO II. MANUAL DE USUARIO DE LA APLICACIÓN SERVIDOR

115

TABLA DE FIGURAS

IDENTIFICADOR

DESCRIPCIÓN

PÁGINA

Figura 1

Arquitectura P2P

2

Figura 2

Arquitectura cliente-servidor

3

Figura 3

Modelo centralizado

6

Figura 4

Modelo totalmente descentralizado

6

Figura 5

Modelo semicentralizado

7

Figura 6

Arquitectura de Hotline Connect

17

Figura 7

Arquitectura de Napster

18

Figura 8

Arquitectura de eDonkey

20

Figura 9

Clientes de eDonkey

21

Figura 10

Cantidad de contenido compartido de BitTorrent

27

Figura 11

Enjambre de BitTorrent

28

Figura 12

Clientes BitTorrent

31

Figura 13

Resultados en la conexión con el servidor 212.63.206.35

37

Figura 14

Resultados en la conexión con el servidor 195.22.108.26

37

Figura 15

Arquitectura propuesta

40

Figura 16

Red IP multicast

42

Figura 17

Contexto general del sistema

44

Figura 18

Conexiones entre clientes de la red

45

Figura 19

Capas de la aplicación cliente

48

Figura 20

Capas de la aplicación servidor

49

Figura 21

Diagrama de dominio del sistema

53

Figura 22

Diagrama de casos de uso del usuario de la aplicación cliente

54

Figura 23

Diagrama de paquetes

56

Figura 24

Clases del paquete gui

58

Figura 25

Clases del paquete client

59

Figura 26

Clases del paquete constants

60

Figura 27

Clases del paquete util

61

Figura 28

Clases del paquete packets

62

Figura 29

Clases del paquete data

63

Figura 30

Clases del paquete server

64

Figura 31

Clases del paquete dao

65

Figura 32

Solicitud de conexión a la red P2P

69

Figura 33

Solicitud de búsqueda de archivos

69

Figura 34

Solicitud de búsqueda de comentarios

70

Figura 35

Solicitud de búsqueda de comentarios

71

Figura 36

Solicitud de sincronización de archivos

71

Figura 37

Solicitud de desconexión a la red P2P

72

Figura 38

Solicitud de conexión a la red IP multicast

72

Figura 39

Solicitud de búsqueda de archivos a la red IP multicast

73

Figura 40

Solicitud de búsqueda de comentarios a la red IP multicast

74

IDENTIFICADOR

DESCRIPCIÓN

PÁGINA

Figura 41

Solicitud de búsqueda de direcciones IP a la red IP multicast

74

Figura 42

Solicitud de transferencia de un parte del archivo

75

Figura 43

Sincronización de transferencia de un parte del archivo

76

Figura 44

Costes de hardware

83

Figura 45

Costes de software

83

Figura 46

Costes de tecnología

84

Figura 47

Estimación del esfuerzo de los integrantes del proyecto

85

Figura 48

Costes de implantación

86

Figura 49

Costes de desarrollo del proyecto

86

Figura 50

Planificación del proyecto

88

Figura 51

Planificación de la etapa de desarrollo e implementación

89

Capítulo 1

Introducción

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

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

1.1 INTRODUCCIÓN A LAS REDES PEER-TO-PEER

1.1.1 REDES PEER-TO-PEER

Debido a un notable crecimiento en el número de equipos conectados a Internet, una mayor capacidad de almacenamiento de éstos y un rápido incremento del ancho de banda disponible, ha surgido una enorme difusión de recursos de todo tipo en Internet. Esta circunstancia ha hecho que sea necesario el desarrollo de una nueva arquitectura de red para poder compartir y acceder a los recursos disponibles en Internet. Esta arquitectura de red se conoce con el nombre de arquitectura peer-to- peer, red peer-to-peer o más comúnmente P2P.

Una red peer-to-peer, en adelante P2P, es un conjunto de equipos conectados por medio de un método de transporte de datos en el que se comparten recursos y en el que no están definidos ni clientes ni servidores fijos. Se puede decir que los equipos conectados a la red se comportan, simultáneamente como clientes y como servidores con respecto al resto y todos tienen capacidades y responsabilidades equivalentes

[AFAN06].

capacidades y responsabilidades equivalentes [AFAN06] . Figura 1. Arquitectura P2P Frente a este tipo de redes,

Figura 1. Arquitectura P2P

Frente a este tipo de redes, se encuentran las que se basan en una arquitectura cliente-servidor, en la que los clientes solicitan recursos a uno o más servidores. En este tipo de arquitectura, según se añaden más usuarios a la red, la tasa de

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

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

transferencia 1 disminuye ya que los recursos de los que dispone el servidor se consumen debido al intenso tráfico. En las redes P2P, cada nodo provee al resto de los recursos que dispone, obteniendo de esta forma un mayor rendimiento en las conexiones y en las transferencias.

mayor rendimiento en las conexiones y en las transferencias. Figura 2. Arquitectura cliente-servidor Los aspectos
mayor rendimiento en las conexiones y en las transferencias. Figura 2. Arquitectura cliente-servidor Los aspectos
mayor rendimiento en las conexiones y en las transferencias. Figura 2. Arquitectura cliente-servidor Los aspectos
mayor rendimiento en las conexiones y en las transferencias. Figura 2. Arquitectura cliente-servidor Los aspectos

Figura 2. Arquitectura cliente-servidor

Los aspectos fundamentales que caracterizan una red P2P son los que se muestran a continuación.

Escalabilidad. El alcance de las redes P2P es mundial, con un gran número de usuarios potenciales. A diferencia de las redes basadas en una arquitectura cliente-servidor, cuantos más usuarios estén conectados a la red, mayor rendimiento se obtiene. Descentralización. Por definición, estas redes son descentralizadas y los usuarios se comportan, simultáneamente como clientes y servidores, lo que hace que ningún nodo sea imprescindible. Robustez. La naturaleza distribuida y descentralizada de las redes P2P incrementan la robustez, ya que en el caso de fallo de un nodo, este no es imprescindible. Seguridad. Es la característica menos implementada, aunque existen mecanismos de cifrado de clave, comunicaciones seguras, gestión de derechos de autor, firmas digitales y demás métodos de seguridad.

1 El término tasa de transferencia se refiere al número de bits que se transmiten durante un tiempo determinado entre dos dispositivos digitales. Mide la velocidad de transferencia de datos.

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

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

Anonimato. Aunque es deseable que queden en anonimato el autor de un contenido, el editor, el lector, el servidor que lo alberga y la petición para encontrarlo, esta característica es incompatible con los derechos de autor, por lo que se proponen mecanismos de limitación de derechos como DRM 2 (Digital Rights Management).

1.1.2 ELEMENTOS DE UNA RED PEER-TO-PEER

El elemento fundamental de una red P2P es una unidad de procesamiento lógico, capaz de llevar a cabo una tarea encomendada y comunicar los resultados de la ejecución de dicha tarea a otra entidad de la red, ya sea directa o indirectamente. Esta unidad de procesamiento se conoce con el nombre de par o igual.

Existen dos tipos de pares [SANT07], los pares simples y los superpares. Los primeros sirven a un único usuario final, proporcionándole servicios y demandándolos a otros pares de la red. Los segundos gestionan el tráfico recibiendo solicitudes de búsqueda de otros pares e indicando el acceso a los mismos.

Estos dos tipos de pares pueden agruparse con otros de su misma especie, formando lo que se conoce como grupo de pares. Un grupo de pares es un conjunto de pares del mismo tipo, configurado para servir un interés común, señalado por el resto de pares del grupo. Los grupos de pares proporcionan servicios a sus pares miembro que no son accesibles por otros pares de la red P2P. Este concepto es necesario para poder dividir el espacio de la red.

Los servicios que proporcionan los pares de una red, proveen una funcionalidad útil que se consigue por medio de la comunicación de los mismos. Esta funcionalidad cubre una larga lista de diferentes finalidades, entre las que se encuentran la búsqueda y transferencia de archivos, la telefonía por internet y los cálculos de carácter científico.

2 El término DRM (Digital Rights Management) se refiere al conjunto de tecnologías de control para la limitación del uso de medios o dispositivos digitales. También se puede referir a las restricciones asociadas a instancias específicas de obras digitales o dispositivos.

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

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

Los servicios pueden clasificarse en servicios de pares y servicios de grupos de pares. Los primeros son funcionalidades que ofrece un par concreto a otros pares de la red. Si el par se desconecta, el servicio deja de estar disponible. Los segundos son funcionalidades que ofrece un grupo de pares, consiguiendo así un acceso concurrente al servicio. Si un par del grupo se desconecta, el servicio sigue estando disponible, ya que el resto de los pares que forman parte del grupo continúan conectados.

1.1.3 ARQUITECTURA DE LAS REDES PEER-TO-PEER

de

centralizado, totalmente descentralizado, semicentralizado.

El

modelo

en

el

que se

basa

la

arquitectura

una

red

P2P

puede

ser

En modelo centralizado, las solicitudes de búsqueda y control se realizan a través de un único servidor central, que sirve de punto de enlace entre los nodos de la red. Este servidor mantiene una base de datos en la que almacena la información de los archivos que tiene cada cliente, actualizándola cada vez que un cliente se conecta o desconecta. Cada solicitud de búsqueda es comparada en servidor central con la información de la base de datos, y contestada con las correspondencias encontradas. Una vez que el cliente tiene las correspondencias, se conecta directamente con cada par y accede al recurso solicitado.

Este modelo se caracteriza por poseer una administración dinámica, una disposición más permanente de los recursos y un elevado rendimiento en la localización de recursos, sin embargo, está muy limitado en lo referente a la escalabilidad 3 y a la robustez 4 , ya que únicamente tiene un punto de fallo. Algunos ejemplos de redes que se basan en este modelo son Napster y Audiogalaxy.

3 El término escalabilidad se refiere a una propiedad deseable en un sistema, que indica su habilidad para poder hacerse más grande sin perder calidad en sus servicios.

4 El término robustez se refiere a una propiedad deseable de un sistema, que indica su habilidad para poder funcionar o continuar funcionando correctamente bajo situaciones inesperadas.

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

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

Diseño e implementación de un protocolo peer-to-peer Figura 3. Modelo centralizado El modelo totalmente

Figura 3. Modelo centralizado

El modelo totalmente descentralizado o puro se caracteriza porque no existe un servidor central, cada nodo actúa como cliente y como servidor, tratando de mantener un cierto número de conexiones con otros pares, mandando y recibiendo peticiones y mensajes de control que facilitan el descubrimiento y encaminamiento de otros nodos.

Las redes que se ajustan a este modelo son las más versátiles y robustas al no depender de un servidor central, no obstante, el elevado tiempo y la sobrecarga de ancho de banda que suponen las búsquedas de información son las principales desventajas de esta arquitectura. Algunos ejemplos de redes que se basan en este modelo son Kademlia, Gnutella y Freenet.

de redes que se basan en este modelo son Kademlia, Gnutella y Freenet. Figura 4. Modelo

Figura 4. Modelo totalmente descentralizado

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

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

El modelo semicentralizado o mixto es el más extendido entre las arquitecturas de redes P2P. En este modelo, se seleccionan ciertos nodos para que cumplan la función de superpares y así ayudar a encaminar el tráfico hacia otros pares. Los superpares cambian dinámicamente a medida que otros clientes se conectan a la red. Cada par mantiene un número limitado de conexiones abiertas a un superpar y cada superpar está conectado con el resto de superpares de la red.

Este modelo se caracteriza por presentar un alto grado de escalabilidad, al reducir el número de nodos implicados en el proceso de encaminamiento, y disminuir el volumen de tráfico entre estos. Algunos ejemplos de redes que se basan en este modelo son eDonkey y BitTorrent.

redes que se basan en este modelo son eDonkey y BitTorrent. Figura 5. Modelo semicentralizado 1.1.4

Figura 5. Modelo semicentralizado

1.1.4 CLASIFICACIÓN DE LAS REDES PEER-TO-PEER

La clasificación más utiliza para identificar las redes P2P es de acuerdo al tipo de estructura que presente, así se pueden presentar redes estructuradas o no estructuradas [RODE05].

Las redes P2P estructuradas son aquellas en la que los recursos están situados en pares precisos. Cada nodo de la red cuenta con su propia tabla hash 5 , el lugar en el que

5 El término tabla hash se refiere a una estructura de datos que asocia claves con valores, cuya operación fundamental es la búsqueda, permitiendo el acceso a los valores almacenados a partir de una clave generada.

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

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

está cada recurso es calculado mediante una función hash 6 aplicada sobre la tabla, la cual indica que par de la red conoce la localización del recurso. Algunos ejemplos de este tipo de redes son Pastry, CAN y Chord.

Este tipo de redes proporcionan un mecanismo de búsqueda determinista, de tal forma que asegura la localización de un recurso siempre y cuando se encuentre en la red. Además los mensajes de búsqueda son encaminados de forma eficiente, de tal forma que el recurso es encontrado en saltos, donde es el tamaño de la red. Sin embargo, estas redes son ineficientes para realizar búsquedas por palabras clave, ya que el usuario debe conocer el nombre exacto del recurso para poder aplicar la función hash y así poder enrutar la búsqueda de forma eficaz. Además en este tipo de redes, los usuarios deben organizar sus tablas hash cada vez que otro usuario se conecta o desconecta, lo que provoca un proceso bastante complejo y un gran número de mensajes de sincronización, lo que puede dar lugar a un colapso de la red.

En las redes P2P no estructuradas, la localización de los recursos no está determinada en pares concretos, sino que a cada nodo se le asignan enlaces arbitrariamente. No existe garantía alguna de encontrar el recurso, aunque éste esté en la red, ya que la búsqueda no es determinista. Un ejemplo de este tipo de redes es Gnutella.

Existen distintos mecanismos de búsqueda dentro de las redes no estructuradas, pero los más utilizados son el de inundación y el de paseos aleatorios. En el primero, cuando un nodo recibe un mensaje de solicitud de búsqueda de un recurso, si no conoce el recurso buscado, reenvía el mensaje a todos los pares con los que tiene una conexión. El inconveniente de este método de búsqueda es que introduce mucho tráfico en la red. En el segundo mecanismo, los mensajes no se envían a todos los pares con los que se tiene conexión, sino que sólo es enviado a uno ellos elegido aleatoriamente. El alcance del mensaje está limitado por medio de la utilización de un

6 El término función hash se refiere a un algoritmo para la generación de claves que representen de forma unívoca un determinado valor.

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

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

mecanismo basado en TTL 7 (Time To Live). Este método introduce mucho menos tráfico en la red que el primero, sin embargo, reduce la probabilidad de encontrar el recurso debido a la limitación de la distribución del mensaje de búsqueda.

Aunque no se han detallado, existen muchas más clasificaciones de las redes P2P, atendiendo a su generación y a sus características de anonimidad.

1.1.5 APLICACIONES DE REDES PEER-TO-PEER

Aunque, como se ha detallado anteriormente, una mayor capacidad de almacenamiento y un rápido incremento del ancho de banda disponible han ayudado al desarrollo de las redes P2P, estos recursos son costosos. Aquellos servicios y aplicaciones que requieran un uso considerable de estos recursos pueden utilizarse las redes P2P.

Algunos ejemplos de aplicación de estas redes son los siguientes.

Sistemas de intercambio de archivos. Posiblemente sea la aplicación más extendida en este tipo de redes. Los propósitos de este tipo de aplicación son muy variados, desde el uso particular hasta el ámbito educativo. Algunos ejemplos son LionShare, eDonkey2000 y BitTorrent. Sistemas de telefonía por Internet. Sistemas basados en VoIP 8 (Voice over Internet Protocol) que permite la transmisión en tiempo real de señales de voz por la Red. Algunos ejemplos de este tipo de aplicación son Skype y Gizmo5. Sistemas de archivos distribuidos. Sistema de datos distribuido en los que la información se almacena en nodos de la red y se permite el acceso de otros pares a la misma. Algunos ejemplos de este tipo de aplicación son Freenet y CFS. Sistemas de P2PTV. Sistemas para la transmisión y difusión de contenidos audiovisuales a través de Internet. En este tipo de sistemas, los nodos se

7 El término TTL (Time To Live) se refiere al número de veces que puede ser enrutado un paquete antes de ser descartado o devuelto al origen.

8 El término VoIP (Voice over Internet Protocol) se refiere al conjunto de recursos que hacen posible enviar la voz en forma digital a través de Internet, utilizando para ello el protocolo IP.

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

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

conectan a sus pares para recibir los streams 9 de video y audio, en lugar de conectarse con un servidor central en la televisión basada en IP (Internet Protocol), IPTV 10 (Internet Protocol Television). Algunos ejemplos de este tipo de aplicación son SopCast y CoolStreaming. Sistemas de cálculo científico. Sistemas que tienen que manejar grandes cantidades de datos y tienen una gran carga computacional, como es el caso de sistemas de administración autónoma para la bioinformática. Un ejemplo de este tipo de aplicación es Chinook.

1.1.6 PROBLEMAS DE LAS REDES PEER-TO-PEER

Como ya se ha detallado anteriormente, uno de los problemas de las redes P2P radica en el proceso de búsqueda de los nodos. El problema de encontrar un par que se encuentre conectado a la red P2P es, comúnmente, solucionado realizando una conexión con un servidor, en el que la dirección IP es conocida. Este servidor es el encargado de mantener una lista con las direcciones de los nodos que se encuentran conectados a la red.

Otro problema es el de la conexión de pares sin dirección IP pública. La solución que se suele aplicar es la conexión de otro nodo que cumple la función de proxy 11 . El resto de los pares se conectan a este proxy el cual envía la información que llega de uno al otro. Cualquier nodo que esté conectado a la red P2P y tenga una dirección IP pública puede ser elegido para que cumpla con el cometido de proxy. En este caso, es de implementación obligatoria el desarrollo de mecanismos de seguridad para evitar que los proxies puedan acceder a la información que se comunican dos pares de la red.

9 El término stream se refiere a un elemento software que permite un flujo de información entre un origen y un destino.

10 El término IPTV (Internet Protocol Television) se refiere a una tecnología basada en video streaming de distribución de señales de televisión y video, que usa conexiones de banda ancha sobre el protocolo IP.

11 El término proxy se refiere a un dispositivo de red que realiza una acción en representación de un equipo perteneciente a esa red. Su finalidad más usual es permitir el acceso a Internet a todos los equipos de una organización.

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

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

1.2 TECNOLOGÍAS

En

este

apartado

se

realizará

una

breve

explicación

sobre

las

principales

tecnologías del proyecto y el motivo de su elección.

1.2.1 JAVA

Java fue desarrollado en 1990 por Sun Microsystems, como parte de un proyecto de investigación para el desarrollo de una amplia variedad de dispositivos de red, con el fin de que fuera independiente de la arquitectura del dispositivo. El propósito era crear una nueva plataforma operativa que, además de ser independiente de la arquitectura del dispositivo, fuera sencilla, portable, fiable, distribuida y en tiempo real. Este lenguaje de programación toma mucha de su sintaxis de otros lenguajes como C, C++, Eiffel y SmallTalk, pero el modelo de objetos que utiliza es más simple y elimina accesos de bajo nivel. El resultado es un lenguaje que se ha mostrado ideal para desarrollar aplicaciones de usuario final seguras, distribuidas y basadas en red en un amplio rango de entornos desde los dispositivos de red embebidos hasta los sistemas de sobremesa e Internet.

Las características principales de Java [MUÑO04] son las que se muestran a continuación.

Sencillo, orientado a objetos y familiar: Sencillo, para que no requiera grandes esfuerzos de entrenamiento para los desarrolladores. Orientado a objetos, porque la tecnología de objetos se considera madura y es el enfoque más adecuado para las necesidades de los sistemas distribuidos y cliente- servidor. Familiar, porque aunque se rechazó C++, se mantuvo Java lo más parecido posible a C++, eliminando sus complejidades innecesarias, para facilitar la migración al nuevo lenguaje. Robusto y seguro: Robusto, simplificando la gestión de memoria y eliminando las complejidades de la gestión explicita de punteros y aritmética de punteros de C. Seguro para que pueda operar en un entorno de red. Independiente de la arquitectura y portable: Java está diseñado para soportar aplicaciones que serán instaladas en un entorno de red heterogéneo,

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

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

con hardware y sistemas operativos diversos. Para hacer esto posible el compilador Java genera bytecodes, un formato de código independiente de la plataforma diseñado para transportar código eficientemente a través de múltiples plataformas de hardware y software. Es además portable en el sentido de que es rigurosamente el mismo lenguaje en todas las plataformas. El bytecode es traducido a código máquina y ejecutado por la Máquina Virtual Java, que es la implementación Java para cada plataforma hardware software concreta. Alto rendimiento: A pesar de ser interpretado, Java tiene en cuenta el rendimiento, y particularmente en las últimas versiones dispone de diversas herramientas para su optimización. Cuando se necesitan capacidades de proceso intensivas, pueden usarse llamadas a código nativo. Interpretado, multi-thread y dinámico: El intérprete Java puede ejecutar bytecodes en cualquier máquina que disponga de una Máquina Virtual Java. Además Java incorpora capacidades avanzadas de ejecución multi-thread, ejecución simultánea de más de un flujo de programa, y proporciona mecanismos de carga dinámica de clases en tiempo de ejecución.

Dado que el presente proyecto tiene características de un sistema distribuido, éste ha de ser independiente tanto del hardware como del sistema operativo en el que se ejecute. Además la arquitectura planteada se ajusta muy bien a las características anteriormente mencionadas, sencillez, robustez, multi-thread y demás, por lo que la elección de Java como lenguaje de implementación es la más indicada para la implementación del proyecto.

1.2.2 MYSQL

MySQL es un sistema de gestión de bases de datos relacionales desarrollado por David Axmark y Michael Widenius y actualmente distribuido por la compañía comercial MySQL AB. Actualmente, según las cifras de la página del proyecto, existen más de seis millones de copias funcionando en equipos de todo el mundo, lo que le convierte en uno de los sistemas gestores de bases de datos relacionales más utilizados. MySQL es muy utilizado en aplicaciones web, ya que es un sistema gestor muy rápido en la

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

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

lectura, y en este tipo de aplicaciones el entorno es intensivo en lectura de datos, lo que hace que MySQL sea excelente para este tipo de aplicaciones. Este hecho hace que portales web con alta tasa de tráfico, como Google, Amazon y YouTube entre otros, utilicen este sistema gestor para el almacenamiento y recuperación de datos así como para el proceso de autenticación de los usuarios.

MySQL está escrito en los lenguajes de programación C y C++, utilizando yacc como analizador gramatical de SQL (Structured Query Language). Además existen varias APIs (Application Programming Interface) que permiten a aplicaciones realizadas en una gran variedad de lenguajes, acceder a las bases de datos, incluyendo C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, y Tcl. También existe un interfaz ODBC 12 (Open Database Connectivity), llamado MyODBC que permite a cualquier lenguaje de programación que soporte ODBC comunicarse con las bases de datos MySQL.

Las principales características de relacionales [MYSQ09] son las siguientes.

este

sistema

gestor

de

bases

de

datos

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 backends 13 , programas y bibliotecas cliente, herramientas administrativas y un amplio abanico de interfaces de programación para aplicaciones. También proporciona MySQL Server como biblioteca incrustada multi-thread, la cual se puede lincar en cualquier tipo de aplicación para obtener un producto más pequeño, rápido y fácil de administrar. Rápido, fiable y fácil de usar. MySQL Server se desarrolló originalmente para tratar grandes bases de datos mucho más rápido que soluciones existentes y ha sido usado con éxito en entornos de producción de alto rendimiento durante varios años. MySQL Server ofrece hoy en día una gran cantidad de

12 El término ODBC (Open Database Connectivity) se refiere a un estándar de acceso a bases de datos desarrollado por Microsoft con el objetivo de hacer posible la comunicación entre una aplicación y el sistema gestor de bases de datos.

13 El término backend se refiere a un tipo de abstracción que engloba las diferentes partes finales de un sistema o proceso.

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

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

funciones. Su conectividad, velocidad, y seguridad hacen de MySQL Server altamente apropiado para acceder bases de datos en Internet. Open source. Open source significa que es posible usar y modificar el software. Se puede bajar el software MySQL desde internet y usarlo sin pagar nada. Si se desea se puede estudiar el código fuente y cambiarlo para adaptarlo a las necesidades del usuario. El software MySQL usa la licencia GPL (GNU General Public License) y en caso de necesitar añadir código MySQL en una aplicación comercial, se puede adquirir una licencia de tipo privativa.

Tras la descripción detalla de las características, se puede apreciar que el sistema gestor de bases de datos relacionales MySQL es una de las mejores propuestas tecnológicas, ya que las características se ajustan a los requisitos del proyecto, tales como multi-thread, rapidez y fiabilidad. Además MySQL está bajo licencia GPL, un valor añadido al producto final que hoy en día es bastante valorado en algunos proyectos.

Capítulo 2

Estado del Arte de las Aplicaciones Peer-to-Peer

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

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

2.1 ESTADO DEL ARTE

Como ya se ha detallado anteriormente en el apartado de aplicaciones de redes P2P, existe una gran variedad de aplicaciones P2P con diferentes finalidades. Ya que el marco de desarrollo del presente proyecto se encuentra en la búsqueda e intercambio de archivos, el siguiente estudio del estado del arte sólo afecta a aquellas aplicaciones cuya finalidad es la anteriormente mencionada.

El sistema global de discusión en Internet Usenet, fue unos de los primeros sistemas de comunicación entre redes. Desarrollado por Tom Truscott y Jim Ellis en 1979 y actualmente vigente, permite el intercambio de opiniones y experiencias entre los usuarios interesados en el mismo tema.

Comenzó a utilizarse en 1980 empleando UUCP 14 (Unix to Unix Copy), lo que permite el uso de servicio de email y transferencia de archivos, sosteniéndose gracias a un gran número de servidores distribuidos y actualizados mundialmente que almacenan y transmiten los mensajes. El gran número de usuarios y grupos, la escasez de recursos requeridos, la velocidad, el anonimato, su libre acceso y su descentralización, entre otros, hacen de Usenet la mayor red de intercambio de información y debate del mundo. También goza de una importancia cultural significativa, habiendo dado lugar al nacimiento, y popularizado, conceptos considerablemente reconocidos, como FAQ (Frequently Asked Questions) y spam.

La primera aplicación P2P conocida, desarrollada en el año 1996 por Adam Hinkley para Mac OS, fue Hotline Connect, más conocida simplemente como Hotline, y se basaba en la librería AppWarrior que el propio Hinkley había implementado anteriormente. Distribuida por Hotline Communications, pretendía ser una plataforma de distribución de archivos destinada al ámbito empresarial y universitario, pero en muy poco tiempo empezó a servir de intercambio de archivos de dudosa legalidad y como servicio de IRC (Internet Relay Chat), pasando a segundo plano el intercambio de archivos de libre distribución.

14 El término UUCP (Unix to Unix Copy) se refiere a un conjunto de programas y protocolos que permiten la ejecución remota de comandos y transferencia de archivos, emails y netnews entre los ordenadores de una red.

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

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

Hotline se distribuía como shareware 15 junto con los servicios de IRC bajo una arquitectura cliente-servidor. Este hecho obligaba a que en caso de que un servidor cerrase, la descarga se tenía que cancelar y empezar de nuevo desde otro servidor del cual seguir descargando el archivo, ya que no existía ningún otro lugar del cual descargar el archivo.

Existen varias versiones open source de Hotline que no se basan en el código original de Hinkley, y que incluyen mejoras al protocolo y al servicio IRC, como IRC bridge o KDX bridge [HAXI01].

Las

aplicaciones

continuación.

de

las

que

constaba

Hotline

eran

las

que

se

detallan

a

Hotline Client. La aplicación que se utilizaba para poder acceder a los usuarios que ejecutaban la aplicación servidora conociendo la dirección IP de estos. Hotline Server. La aplicación que ejecutaban los clientes para gestionar el acceso a los recursos. Hotline Tracker. Un servidor de nombres que mantenía las direcciones IP de los clientes que ejecutaban la aplicación servidora.

IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1
IP de los clientes que ejecutaban la aplicación servidora. Figura 6. Arquitectura de Hotline Connect 1

Figura 6. Arquitectura de Hotline Connect

15 El término shareware se refiere a un tipo de distribución de aplicaciones en la que el usuario puede evaluar el software de forma gratuita y durante un tiempo determinado.

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

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

El problema de la dependencia de las descargas al servidor al que el usuario se encontrara conectado y la dependencia de la ejecución de la aplicación en sistemas MAC, una plataforma minoritaria en aquel tiempo, motivó la aparición de Napster.

Napster fue desarrollado por Shawn Fanning y ofrecía un servicio de distribución de archivos de música en formato MP3 (MPEG-1 Audio Layer 3), que facilitaba la búsqueda de estos por medio de la centralización, en lugar de buscar en IRCs o en buscadores de Internet.

Fue el primer sistema P2P de distribución de archivos entre pares basado en una red centraliza, ya que utilizaba un servidor central para mantener la lista de usuarios conectados y archivos compartidos por cada uno de ellos, mientras que las transferencias de archivos, sin embargo, eran realizadas entre los usuarios sin ningún tipo de intermediario. Aunque hubo varias redes que facilitaban la distribución de archivos a través del Internet, Napster se especializaba directamente en música, en archivos de formato MP3, presentados a través de una interfaz amigable al usuario. El resultado fue un sistema cuya popularidad generó una enorme selección de música para descargar. El servicio y programa eran inicialmente sólo para plataformas Windows, pero en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac.

en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.
en el 2000 Black Hole Media realizó un cliente llamado Macster para sistemas Mac. Figura 7.

Figura 7. Arquitectura de Napster

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

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

El hecho de que Napster fuera un servicio centralizado resultó su perdición ya que varias discográficas estadounidenses demandaron a Napster, reclamando su cierre a la RIAA 16 (Recording Industry Association of America). A pesar de la clausura del servicio, existían ya bastantes alternativas, como servidores no oficiales, OpenNap, y una gran variedad de aplicaciones como Winmx e iMesh. Después se estableció Audiogalaxy como el sistema P2P más utilizado por los usuarios de Internet, otra aplicación centralizada de intercambio de música, que acabó clausurada también por orden judicial de la RIAA.

El cierre de los servidores de aplicaciones centralizadas como Napster y Audiogalaxy, motivó nacimiento de las redes descentralizadas y semicentralizadas, pues para terminar con estas bastaba con eliminar el servidor central que almacenaba las listas de los archivos compartidos y de los usuarios conectados a la red.

Una de ellas, eDonkey, también conocida como eDonkey2000 o eD2K, apareció por primera vez en Septiembre del 2000 desarrollada por MetaMachine. Esta red se puede clasificar del tipo semicentralizada, pues utilizaba servidores para almacenar la información de los usuario y de los archivos, pero ninguno de estos era central, por lo que en caso de fallo otro servidor podía seguir ofreciendo el servicio, incluso los usuarios de las red podían crear sus propios servidores.

Los elementos de la red eDonkey son los que se detallan a continuación.

Servidores. Utilización de servidores para conectar a los clientes. Metadatos. Envío de metadatos de un archivo justo en el momento de enviar la información de los archivos compartidos al servidor. Enlaces. Utilización de enlaces llamados elinks o ed2k links para permitir la identificación, por medio de una función hash, de un archivo o un servidor en el navegador del cliente y transferirlo a la aplicación. La estructura típica de los enlaces para identificar un archivo es la siguiente. ed2k://|file|NOMBRE.EXTENSIÓN|TAMAÑO|HASH|. Opcionalmente se podía

16 El término RIAA (Recording Industry Association of America) se refiere a una asociación americana que representa a la industria discográfica.

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

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

añadir al final del enlace la referencia a la dirección IP y el puerto del cliente

que compartía el archivo /|sources, DIRECCIÓN_IP:PUERTO|/. La estructura típica

de

ed2k://|server|IP|PUERTO|/

Detección de errores. División de los archivos transmitidos en bloques de 9500 KB generando un hash, por medio del algoritmo MD4 17 , por cada bloque y luego de la suma del resto, conocido como raíz o root, para comprobar los datos transmitidos y evitar la corrupción de los bloques.

los

enlaces

para identificar un servidor es la siguiente.

El funcionamiento de la red era el siguiente. Cuando un cliente se conecta a la red, se realiza un proceso de handshake entre éste y el servidor, para anunciar los archivos que se comparten. En el proceso de las búsquedas, el cliente envía la petición al servidor, el cual se encarga de buscar el archivo en la información que los clientes le proporcionaron durante el handshake. Cuando la petición es aceptada, el servidor establece una conexión entre los dos clientes y comienza la descarga.

una conexión entre los dos clientes y comienza la descarga. Figura 8. Arquitectura de eDonkey 1
una conexión entre los dos clientes y comienza la descarga. Figura 8. Arquitectura de eDonkey 1
una conexión entre los dos clientes y comienza la descarga. Figura 8. Arquitectura de eDonkey 1

Figura 8. Arquitectura de eDonkey

17 El término algoritmo MD4 se refiere a un algoritmo de función hash diseñado Ronald Rivest para el uso en comprobaciones de integridad de mensajes que produce un identificador de 128 bits.

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

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

Ya que la red eDonkey estaba basada en servidores administrados por los usuarios, estos podían ser objeto de tráfico pesado y, por consiguiente, más vulnerables a los ataques. Para solventar este problema, MetaMachine, desarrolló la red Overnet como su sucesor en el protocolo eDonkey. Overnet fue una red de ordenadores P2P descentralizada, normalmente usada para compartir grandes archivos que implementaba una variante del protocolo Kademlia.

En 2006, MetaMachine, alcanzó un acuerdo con la RIAA para evitar un juicio por infracción de los derechos de propiedad intelectual. La compañía dejó de distribuir su software y acordó pagar una compensación monetaria. En Septiembre del 2006, la red eDonkey2000 dejó de funcionar, sin embargo, se puede comprobar que, por el momento, sigue en funcionamiento usando otros clientes, como los que se muestran a continuación.

NOMBRE

REDES

ANÓNIMO

LICENCIA

PLATAFORMA

LENGUAJE

aMule

eDonkey

No

GPL

Windows, Linux

C++

Kad

MAC OS

 

eDonkey

eMule

Kad

No

GPL

Windows

C++

 

BitTorrent

eDonkey

MLDonkey

FastTrack

No

GPL

Windows, Linux

Ocaml

Gnutella

MAC OS

 

Gnutella2

Kad

Lphant

BitTorrent

No

Freeware con

Windows, Linux

C#

eDonkey

Adware

MAC OS

 

BitTorrent

eDonkey

Shareaza

Gnutella

No

GPL

Windows

C++

Gnutella2

 

BitTorrent

eDonkey

TrustyFile

FastTrack

No

Código

Windows

Desconocido

Gnutella

cerrado

 

Gnutella2

Overnet

Figura 9. Clientes eDonkey

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

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

NOTA: En la tabla anterior no se han incluido todos los mods, modificaciones de los clientes con respecto a su original, ya que el tamaño de la tabla habría aumentado considerablemente.

Paralelamente al cliente eDonkey, existía el cliente eMule, desarrollado por Hendrik Breitkreuz en Mayo del 2002 por discordancias con este, en poco tiempo lo superó en funciones, y sumando el hecho de que era libre y gratuito, entre otros motivos, lograron que en poco tiempo lo superase en popularidad para convertirse en uno de los programas más usados por los usuarios de redes P2P.

eMule es un programa para intercambio de archivos con sistema P2P que utiliza el protocolo eDonkey y la red Kad, publicado como software libre para sistemas Windows. Está implementado en Microsoft Visual C++ haciendo uso de la librería Microsoft Foundation Classes y se encuentra bajo licencia GPL.

Las características de eMule son las que se detallan a continuación.

Intercambio directo. Al igual que eDonkey, el intercambio de los archivos se realiza directamente entre clientes, con el previo proceso de handshake con el servidor. Uso de una red descentralizada. Los clientes de eMule pueden conectarse opcionalmente a una red descentralizada denominada Kad, utilizando el protocolo Kademlia, la cual no depende de servidores centrales pero sí utiliza tablas hash distribuidas. Licencia GPL. El hecho de estar bajo esta licencia, implica que cualquier usuario puede modificar el código libremente. Por este motivo han proliferado toda una serie de modificaciones, mods, del programa original, como eMule Plus o eMule MorphXT. Detección de errores y recuperación de partes. Se utiliza algoritmos de detección de errores, que dividen los archivos en bloques de 9500 KB y generando un hash, por medio del algoritmo MD4, para comprobar los datos transmitidos. Además el sistema AICH (Advanced Intelligent Corruption

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

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

Handling) utiliza el método de hashtree 18 para fragmentar el archivo en bloques de 180 KB, disminuyendo así la cantidad de datos que hay que volver a descargar para corregir un error de transmisión. Transferencias comprimidas. Cada vez que eMule transmite datos, estos se comprimen con la librería zlib, de forma totalmente transparente al usuario y ahorrando ancho de banda. Comentarios para los archivos. Se permite calificar la calidad de un archivo y escribir comentarios sobre él para que otros usuarios los puedan leer, pudiendo así saber de antemano si el archivo tiene la calidad esperada o si está corrupto. El problema es que para leer los comentarios de un usuario, previamente se ha tenido que conectar a este. Archivos de colección. Se permite crear archivos en un formato especial llamado colección. Este tipo de archivo contiene un conjunto de enlaces de eMule, dando la posibilidad de bajarlo como un conjunto y guardar toda la colección de archivos como un conjunto, aunque cada descarga se gestiona independientemente. Previsualización archivos multimedia. Se permite la visualización de diversos tipos de archivos, como audio y vídeo, aunque el archivo no se haya descargado completamente, siempre que el usuario tenga instalado un reproductor multimedia. Mensajería instantánea. Cuenta con la posibilidad de enviar mensajes a usuarios de la red eDonkey 2000 conectados a las descargas en curso y de un chat IRC para buscar información sobre lo que interese a los usuarios.

Además de las características anteriores, eMule se distingue por la utilización de un sistema de créditos por el cual los usuarios que más archivos aporta a la red, más rápido avanzan en las colas de descarga de un archivo. Es la forma de recompensar, mediante un algoritmo meritocrático, a los usuarios que aportan recursos a la red. El sistema de gestión de la cola de descarga está basado en el tiempo de espera de un usuario en la cola de descarga de un archivo. El sistema de créditos proporciona un

18 El término hashtree se refiere a una estructura de datos que contiene los valores hash de un árbol y que se utiliza para verificar su contenido.

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

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

ratio de modificación al algoritmo de gestión de la cola de descarga, en función de la cantidad de datos transferidos entre dos clientes. Los créditos se almacenan en cada usuario para evitar que sean modificados, con la problemática de que únicamente se obtendrán créditos en los usuarios en los que se haya transferido un archivo.

La expresión de cálculo que utiliza el sistema de créditos está compuesta por dos ratios [MONK03].

2

1

2 2

Al terminar el cálculo, ambos ratios son comparados y el sistema de créditos elige el menor como ratio de modificación al algoritmo de gestión de la cola de descarga. Existen tres restricciones a este cálculo, que son las siguientes.

El ratio de modificación al algoritmo de gestión de colas es un número entre 1 y 10. Si el total subido es menor que 1 MB, entonces el ratio de modificación permanece a 1. Si el cliente no ha descargado nada, el ratio de modificación es fijado a 10.

Una excepción a esta regla se aplica sólo cuando un par es asignado como amigo después de la agregación a la lista de amigos del cliente. Esto automáticamente asigna una posición en la cola de descarga para que se pueda comenzar a descargar, independientemente de la calificación de los anteriores ratios. Sólo se puede reservar una posición para un amigo, para impedir cualquier forma de abuso.

Otra de las características de distinción es la ofuscación del protocolo. Esta función evita que las conexiones sean detectadas y, posteriormente, bloqueadas por los ISPs (Internet Service Provider). La ofuscación del protocolo es una característica que hace que eMule encubra su protocolo al comunicarse con un servidor u otros clientes. Sin ofuscación, cada comunicación de eMule tiene una estructura predeterminada que puede ser fácilmente identificada por un packet sniffer, programa

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

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

de captura de las tramas de red. Si se activa el modo ofuscado, toda la comunicación simula estar compuesta de datos aleatorios y ya no es posible realizar una identificación. Esto ayuda en situaciones en las que, mediante identificación de paquetes, el protocolo eMule es bloqueado. No hay que confundir el modo ofuscado con un modo que proporciona anonimato.

Para la identificación de archivos, estos tienen asignado un valor mediante una función hash, que identifica de forma unívoca un archivo aunque este tenga diversos nombres, de manera que un mismo archivo que tengan diferentes usuarios, aunque alguno de ellos modifique el nombre, este sigue siendo el mismo. Además, todos los archivos se separan en bloques de 9500 KB y de cada una de estas partes se calcula su valor hash, mediante el algoritmo MD4, de manera que el valor hash final del archivo es el resultado de aplicar la función hash MD4 a la concatenación de los valores hash de todas sus partes. En los elinks es imprescindible especificar el hash del archivo y también su tamaño correcto.

Como se ha detallado anteriormente, eMule dispone de dos redes, una red basada en servidores eDonkey y una descentralizada, denominada Kad. A continuación se explica el funcionamiento de cada una de ellas.

Para conectarse a la red de servidores, es necesario conocer la dirección IP del servidor. Una vez el cliente se ha conectado a un servidor, éste le comunica los archivos que quiere compartir. La lista de servidores que presenta eMule puede ser actualizada, permitiendo búsquedas más precisas y extensas y encontrar servidores más rápidos.

La red Kad es una red totalmente descentralizada, que usa una variante del protocolo Kademlia y diseñada para que eMule pueda mantenerse activo tras una posible caída de la red de servidores. Para conectarse a esta red hay que conocer la dirección IP de otro par, pero es posible conectarse a partir de los pares obtenidos de la red de servidores. Cada par conoce una pequeña parte de la red, de manera que el tamaño de la red puede crecer tanto como haga falta sin afectar al rendimiento.

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

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

Cuando un nodo se conecta, almacena los identificadores de los archivos que quiere compartir con otros pares, escogidos en función del identificador del archivo mediante tablas hash distribuidas. Cuando se quiere descargar un archivo, se localizan los pares que lo indexan y estos devuelven la lista de fuentes para este archivo concreto.

La búsqueda por nombre funciona de una manera parecida, guardando el nombre del archivo dentro de otros nodos escogidos en función de cada palabra del nombre. Una búsqueda en Kad se ejecuta siempre en toda la red.

Esta red utiliza el protocolo de nivel de transporte UDP (User Datagram Protocol) para las siguientes funciones.

Encontrar fuentes para valores hash eDonkey. Búsquedas de valores hash eDonkey basadas en palabras clave del nombre archivo. Encontrar comentarios y valoraciones de los archivos. Almacenar direcciones, comentarios y nombres de archivos.

Uno de los problemas de esta red es que ya que los nodos están comunicándose continuamente entre ellos puede producir una mayor carga en máquinas.

Como alternativa a eMule, en Abril del 2001 apareció el protocolo BitTorrent, desarrollado por Bram Cohen y liberada la primera implementación en Julio del 2001 [COHE01], actualmente mantenido por la empresa BitTorrent.

BitTorrent es un protocolo P2P de transferencia de archivos más comunes para transferir archivos grandes, algunas estimaciones otorgan la cantidad total de contenido compartido actualmente en más de 1,4 PB [ISOH08].

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

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

Diseño e implementación de un protocolo peer-to-peer Figura 10. Cantidad de contenido compartido de BitTorrent El

Figura 10. Cantidad de contenido compartido de BitTorrent

El protocolo trabaja inicialmente cuando un usuario crea un archivo y lo hace disponible a otros usuarios de la red, esto es lo que comúnmente se conoce con el nombre de semilla y permite que otros pares se puedan descargar este archivo.

Para compartir un archivo o grupo de archivos, un usuario debe crear primero un pequeño archivo con extensión .torrent. Este archivo es estático, por lo que a menudo se encuentra en páginas web o incluso se distribuye por correo electrónico. El archivo .torrent contiene la dirección de un servidor de búsqueda, o tracker, el cual se encarga de localizar posibles fuentes. Este servidor realmente se encuentra centralizado y provee estadísticas acerca del número de transferencias, el número de nodos con una copia completa del archivo y el número de nodos que poseen sólo una parte del mismo.

Los clientes que deseen descargar el archivo primero debe obtener el archivo .torrent, para poder conectarse a otros nodos de la red que tiene el archivo y así poder empezar la descarga. La estructura que forman sus conexiones es conocida con el nombre de enjambre. El archivo deseado es descargado de las fuentes encontradas por el servidor de búsqueda y, al mismo tiempo que se realiza la descarga, se comienza a subir las partes disponibles del archivo a otros pares. El hecho de compartir el archivo, incluso antes de completar la descarga, contribuye a la distribución de este ya que a medida que más pares se descarguen el archivo, la probabilidad de éxito de la descarga y la velocidad de la misma aumentan.

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

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

Diseño e implementación de un protocolo peer-to-peer Figura 11. Enjambre de BitTorrent Cuando un usuario comienza

Figura 11. Enjambre de BitTorrent

Cuando un usuario comienza la descarga de un archivo, no necesariamente se comienza por el principio, sino que se descarga por partes al azar. Luego los usuarios se conectan entre sí para la descarga. Por supuesto, inicialmente alguien debe poseer el archivo completo para comenzar el proceso. Este método produce importantes mejoras en la velocidad de transferencia cuando muchos usuarios se conectan para bajar un mismo fichero. Cuando no existan ya más nodos conectados al servidor de búsqueda con el fichero completo, existe la posibilidad de que el fichero no pueda ser completado.

La eficacia de la transferencia depende en gran medida de las políticas que los clientes usan para determinar a qué par enviar los datos. Los clientes pueden preferir enviar datos a los pares que les han envían anteriormente datos que a los nuevos pares que se han añadido al enjambre, ésta estrategia se conoce con el nombre tit for tat 19 . Para contrarrestar este efecto, el cliente BitTorrent utiliza un mecanismo, según el cual el cliente se reserva un porcentaje de su ancho de banda disponible para el envío de bloques a pares tomados al azar, con la finalidad de garantizar que pares nuevos puedan unirse al enjambre [AMIL06].

19 El término tit for tat se refiere a un estrategia en teoría de juegos, propuesta por Anatol Rapoport para el dilema del prisionero, que consiste en repetir lo que el oponente hizo en la ronda anterior.

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

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

Los archivos que se distribuyen entre los pares son tratados en bloques, normalmente, de entre 32 KB y 4 MB. El par aplica una función hash, usando el algoritmo SHA1 20 , y almacenándolo en el archivo torrent. Cuando otro par recibe un bloque del archivo que se está descargando, se le aplica la función hash, y el valor obtenido es comparado con el almacenado, para comprobar que se encuentra libre de error. El valor de comprobación que se encuentra contenido en el archivo torrent, depende de la versión del protocolo BitTorrent utilizado. Por convención, los archivos torrent tiene un apartado llamado anuncio, en el cual se especifica la URL (Uniform Resource Locator) del servidor de búsqueda, y una sección de información, la cual contiene los nombres de los archivos, sus tamaños, longitud, y el valor hash SHA1 por cada uno de los bloques. Toda esta información es usada por los clientes para verificar la integridad de los datos recibidos.

Una vez creado el archivo torrent, este es publicado en algún sitio web o en otra parte, y registrado en el servidor de búsqueda. El servidor de búsqueda mantiene una lista de clientes que se encuentran participando sobre el archivo torrent. Alternativamente, en un sistema descentralizado, cada par actúa como un servidor de búsqueda, característica implementada por clientes como µTorrent, BitComet y KTorrent a través de métodos de tablas de hash distribuidas.

A pesar de la eficacia y el alto rendimiento de las transferencias, el protocolo

BitTorrent tiene unas cuantas limitaciones, que se pasaran a detallar a continuación.

El protocolo no ofrece anonimato a los clientes, haciendo posible que se puedan

obtener las direcciones IP de los clientes que se encuentran en un enjambre. Esto puede exponer a los usuarios a posibles ataques de agentes externos o propios de la red.

Un usuario BitTorrent, a menudo, puede decidir dejar el enjambre en cuanto tenga una copia completa del archivo descargado, a este usuario se le conoce comúnmente con el nombre de leecher o sanguijuela. Si un número considerable de

20 El término algoritmo SHA1 se refiere a un algoritmo de función hash diseñado por NIST (National Institute of Standards and Technology) y NSA (National Security Agency) para el uso en comprobaciones de integridad de mensajes que produce un identificador de 160 bits.

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

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

usuarios siguen esta conducta, el número de semillas se reduce hasta que llegar a cero y por lo tanto el archivo desaparece. Algunos sitios web BitTorrent han intentado solventar este problema mediante el seguimiento de los ratios de subida y descarga de archivos. En caso de existir una diferencia considerable entre ambos ratios, los clientes obtendrán velocidades de descarga inferiores hasta que los ratios se compensen.

Ya que el protocolo BitTorrent es open source, al igual que sus clientes, han proliferado una gran cantidad de clientes basándose en el código original, disponibles en cualquier plataforma e implementados en una larga lista de lenguajes de programación. El cliente oficial de BitTorrent, BitComet, Vuze y μTorrent son los más populares entre los usuarios de este protocolo.

Algunos clientes, como Torrentflux y TorrentVolve, se pueden ejecutar directamente desde un servidor, lo que permite a empresas de hosting ofrecer velocidades superiores a los usuarios. BitLet permite a los usuarios descargar torrents directamente desde su navegador, usando un applet de Java.

Existen versiones propietarias del protocolo que implementan DRM, como es el caso de Pando.

Algunos

clientes

del

protocolo

BitTorrent

son

los

que

se

muestran

a

continuación.

NOMBRE

PLATAFORMA

LENGUAJE

TRACKER

ADMITE

DHT

TORRENTS

ACTIVOS

ABC

Windows Linux

Python

No

No

8

Ares Galaxy

Windows

Delphi

Desconocido

Desconocido

Desconocido

 

Descargas

BitComet

Windows

C++

separadas

Sí

8

 

Windows, Linux

BitTornado

MAC OS

Python

No

8

BitSpirit

Windows

C++

No

8

Ktorrent

Linux, MAC OS

C++

No

8

Lphant

Windows, Linux

C#

Desconocido

8

MAC OS

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

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

Windows, Linux

MLNet

MAC OS

Ocalm

No

No

8

Rtorrent

Linux, MAC OS

C++

No

No

8

Shareaza

Windows

C++

No

10

 

Windows, Linux

Vuze

MAC OS

Java y SWT

Integrado

Sin límite

μTorrent

Windows, Linux

C++

Integrado

8

MAC OS

Figura 12. Clientes BitTorrent

NOTA: En la tabla anterior no se han incluido todos los clientes, ya que el tamaño de la tabla habría aumentado considerablemente. Sólo se han mostrado los más populares.

El sistema de más reciente aparición ha sido Omemo, un sistema de almacenamiento virtual distribuido open source, basado en tablas de hash distribuidas, distribuido por la firma española MP2P Technologies y desarrollado por Pablo Soto.

La diferencia fundamental de Omemo con el resto de los sistemas P2P radica en que no se comparten archivos, sino espacio libre de almacenamiento. Con el hecho de aportar parte de espacio al disco, se obtienen dos beneficios a cambio, el primero, el derecho de escritura persistente en el disco y el segundo, el derecho de lectura de todos los contenidos del disco. El derecho de escritura es calculado en base a la cantidad de espacio que se aporta y al tiempo durante el que se contribuye. La principal novedad es la persistencia, no es necesario que el usuario esté conectado para que los que dispone archivos estén accesibles para el resto de la red. Omemo ofrece muchas más novedades, tantas que sus creadores lo denominan P2P 2.0.

Las características de Omemo son las siguientes [SOTO06].

Persistente. Se puede copiar algo en él, y luego desconectarse. A diferencia de los P2P actuales, el contenido que se comparte sigue disponible en Omemo cuando el usuario se desconecta.

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

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

Rápido. Se puede transferir archivos del disco con velocidades iguales o superiores a las de un servidor FTP (File Transfer Protocol) o HTTP (HyperText Transfer Protocol). Organizado. Se puede crear y destruir carpetas para organizar categóricamente los archivos. El estado actual del disco es el resultado democrático de los cambios que todos los usuarios van haciendo sobre él. Anónimo. No hay forma de conocer quién es el usuario que publica un archivo, ni quién lo descarga. El diseño lógico del disco impide a un observador externo conocer las actuaciones de otros usuarios. Buscable. Se puede buscar cualquier archivo entre todos los que hay en el disco. El horizonte buscable, a diferencia de los P2P actuales, es ilimitado. Por muy grande que sea el disco, se puede buscar en toda su estructura.

Para la búsqueda de archivos, Omemo incluye un buscador que muestra todos los resultados, salvo lo que cada usuario quiere reservar para sí mismo y los que él desee, ya que el programa permite crear carpetas de acceso restringido.

En el proceso de transferencia del archivo, este es fragmentado en paquetes de 64 KB y a cada trozo se le imprime una clave digital única, después se cifran los fragmentos y antes de lanzarlo a la red se les asigna un identificador que permite al sistema su posterior rastreo y recomposición en el archivo original. Estas medidas de seguridad hacen de Omemo el programa de intercambio más anónimo y refractario a la censura. No existe, actualmente, forma alguna de conocer quién ha subido un determinado archivo y quién se lo descarga.

Siguiendo la corriente Web 2.0, los diferentes archivos pueden ser valorados por los usuarios etiquetando cada archivo. Cuando alguien no quiere determinado material se elimina, desapareciendo de la lista del usuario pero no de la red. La combinación de votos negativos y positivos hace que unos archivos suban de puntuación y otros vayan quedando obsoletos.

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

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

2.2 CONCEPTOS Y TECNOLOGÍAS ACTUALES

Para concluir el presente estudio del estado del arte de las aplicaciones P2P, se detalla a continuación conceptos y tecnologías actuales.

2.2.1 P2P ANÓNIMO

Una red P2P anónima es un tipo particular de red P2P en la que los pares son anónimos por defecto. La principal diferencia entre las redes P2P habituales y las anónimas está en el método de encaminamiento de las respectivas arquitecturas de redes. Estas redes permiten el flujo libre de información.

En una red P2P anónima, cada par de la red tiene un pseudónimo asociado a su dirección IP, para poder ser alcanzado por otro par y así intercambiar archivos. Sin embargo, normalmente esta dirección, especialmente en redes anónimas, no contiene información alguna que pueda permitir la identificación. Por tanto, un usuario es prácticamente anónimo.

El anonimato viene de la idea en la que nadie sabe quien requiere la información, ya que es difícil determinar si un usuario ha pedido los datos para él mismo o simplemente está pidiendo datos que le ha requerido otro usuario. El resultado final es que todos los pares en una red anónima actúan como un emisor y un receptor global para mantener el anonimato.

El interés de la comunidad P2P en el anonimato ha incrementado muy rápidamente desde hace unos años por varias razones, entre ellas la desconfianza en todos los gobiernos y los permisos digitales. Tales redes suelen ser utilizadas por aquellos que comparten archivos musicales con copyright.

Los usos más frecuentes de la tecnología P2P anónima son los que se muestran a continuación.

Navegación anónima por Internet.

Bloqueo de la posibilidad del registro de visitantes de sitios web.

Evasión de la censura de ISPs.

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

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

2.2.2 REDES FRIEND-TO-FRIEND

El término friend-to-friend, en adelante F2F, fue acuñado por Dan Bricklin y hace referencia a un tipo particular de red P2P anónima en donde los pares se conectan directamente a otros pares conocidos. Las aplicaciones F2F solamente permiten la conexión con otros pares en los que el usuario confía, usando direcciones de IP o firmas digitales para las transferencias de archivos. De esta manera, los usuarios pueden descargar indirectamente archivos de otro nodo de manera anónima.

Una de las mayores ventajas de este tipo de redes es que pueden crecer en tamaño sin comprometer el anonimato del usuario. Ejemplos de este tipo de redes son ANts P2P, GNUnet, Mute y Turtle F2F.

2.2.3 PEER-TO-MAIL

Peer-to-mail, en adelante P2M, es un programa que permite almacenar y compartir archivos en cuentas de correo.

La posibilidad hoy en día de emplear cuentas privadas para el intercambio de ficheros por el aumento de la capacidad de almacenamiento, ha facilitado el uso del P2M, el cual ha surgido ante los problemas que encuentran algunos usuarios al usar programas P2P. El principal inconveniente es que en programas P2P no se consigue siempre una gran velocidad y un rango de tiempo corto para descargar un archivo. Además, las descargas en las aplicaciones P2P están reguladas por un sistema de colas, el cual ocasiona que estas sean muchas veces bastantes grandes, causando con ello una demora en la descarga.

P2M funciona de la siguiente manera, primero los archivos compartidos se dividen en segmentos que son hospedados en servidores de correo, el tamaño del segmento está condicionado por el tamaño máximo de archivo adjunto que admite el servidor de email donde son alojados. Mediante programas se accede a las cuentas creadas por los usuarios con el fin de subir los archivos a compartir y dichos programas recopilan y descargan todos los segmentos de la cuenta. Una vez descargados, el programa une todos los segmentos para restablecer el archivo íntegro tal y como se

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

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

subió al servidor. La unión de los segmentos descargados se realiza con programas externos a la aplicación P2M.

2.2.4 WEBCACHÉ

Webcaché es una característica de algunos clientes P2P de la red eDonkey que hacen uso de un proxy caché, una máquina que almacenan en su memoria lo que acaba de pasar por ella en el tránsito de un par a otro, con la finalidad de disminuir el tráfico entre estos.

Los usuarios que usan la opción webcaché de estos programas, suben una parte del archivo que comparten. De esta forma, se permite que otro usuario que pida al usuario ese trozo de archivo, en realidad le pida el mismo trozo de archivo al proxy caché, que lo tiene en su memoria, la cual es mucho más rápida.

Estas máquinas tienen un ancho de banda muy grande, más que cualquier conexión entre dos pares, con lo que se permite aprovechar la velocidad de conexión, siempre que no se colapsen.

2.2.5 PROACTIVE NETWORK PROVIDER PARTICIPATION FOR P2P

Proactive network Provider Participation for P2P, más conocido por su acrónimo P4P, es un medio utilizado por los proveedores de Internet para optimizar el tráfico de las redes P2P de sus usuarios.

Es el siguiente paso en el desarrollo de servicios P2P, ya que permite minimizar el número de saltos requeridos para las transferencias de archivos, eligiendo los pares más cercanos a otro, siempre y cuando pertenezcan al mismo proveedor.

Capítulo 3

Motivación y Objetivos del Proyecto

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

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

La búsqueda e intercambio de archivos de las actuales aplicaciones de redes P2P están muy condicionados al servidor al que se encuentre conectado el cliente, ya que diferentes conexiones entre distintos servidores producen diferentes resultados.

Para demostrar este hecho, se ha hecho uso del cliente de la red eDonkey, eMule v0.49b, y se ha buscado en dos servidores distintos un archivo del sistema operativo Ubuntu, versión 8.04 Hardy Heron, para arquitecturas AMD. Los resultados obtenidos son los que se muestran a continuación.

obtenidos son los que se muestran a continuación. Figura 13. Resultados en la conexión con el

Figura 13. Resultados en la conexión con el servidor 212.63.206.35

Resultados en la conexión con el servidor 212.63.206.35 Figura 14. Resultados en la conexión con el

Figura 14. Resultados en la conexión con el servidor 195.22.108.26

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

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

Como se puede apreciar en las dos imágenes anteriores, los resultados de la búsqueda difieren en el número de resultados, 18 para el primer caso y 10 para el segundo. Además, para resultados iguales, como sucede en el primer caso, la disponibilidad y el número de fuentes completas, atributos que reflejan el número de fuentes que tienen el archivo, también es diferente, por lo que la búsqueda y la posterior descarga del archivo dependen del servidor en el que el cliente se conecte.

Además, con el fin de reducir la cadena de búsqueda, si el usuario de la aplicación cliente introduce “Ubu”, “Ubun”, “Ubunt” o cualquier combinación que no contenga una palabra del nombre completo del archivo a buscar, “Ubuntu”, no se produce ningún resultado en ambos servidores.

Tras el breve análisis anterior, se demuestra que los resultados de las búsquedas que realiza el cliente, dependen de la conexión con el servidor, dando lugar a diferentes resultados en diferentes conexiones. Este hecho origina una preferencia por parte de los clientes en el momento de elegir el servidor al que conectarse, y por lo tanto que exista una serie de servidores preferidos. De este modo se consigue que unos servidores alcancen un gran número de conexiones con clientes, mientras que en otros el número de estas sea mínimo, provocando una ineficiente gestión y reparto de los recursos disponibles. Otra consecuencia de este hecho es el deficiente reparto de la carga de trabajo entre los servidores, ya que en aquellos en los que más conexiones haya, mayor será la carga de trabajo, mientras que los menos favorecidos apenas recibirán solicitudes de búsqueda de archivos.

Otra ineficiencia, común entre los clientes de redes P2P, es que en el momento de introducir una cadena de búsqueda para la posterior descarga de un archivo, ésta a de contener el nombre exacto del archivo, en algunos casos, o al menos una palabra completa de la totalidad del nombre del archivo a buscar, como ya se detalló con anterioridad. De esta forma se caracteriza de cierta severidad a las búsquedas en estos sistemas, obligando al usuario conocer una serie de atributos del nombre del archivo, a diferencia de las búsquedas en buscadores de Internet, que son menos rígidas en lo referente a la cadena de búsqueda.

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

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

Como ya se detalló en el estado del arte, algunas aplicaciones P2P permiten que los usuarios califiquen la calidad de un archivo mediante la escritura de comentarios sobre ese determinado archivo para que otros usuarios puedan leerlos, y así saber de antemano si el archivo tiene la calidad esperada o si está corrupto. El problema es que para leer los comentarios de un usuario, es necesario el inicio de la descarga de un archivo y la conexión a usuarios que tenga disponible este archivo para compartir y que hayan escrito comentario sobre él. Además, no todos los comentarios de la red son accesibles ya que en este tipo de aplicaciones se suelen limitar el número de conexiones y por lo tanto, indirectamente, afectan a la cantidad de comentarios a los que se puede acceder.

Después de haber analizado y detallado algunas de las carencias de los actuales clientes de búsqueda y transferencia de archivos de redes P2P, se puede concluir que existe un desequilibrio entre lo que ofrecen este tipo de aplicaciones y lo que demandan los usuarios. Por este motivo, el objetivo de este proyecto es el diseño e implementación de un protocolo P2P, que mejore el proceso de búsqueda de los archivos entre los usuarios que se encuentren conectados a la red. Se entiende por mejora la eliminación de la dependencia del proceso de búsqueda al servidor al que el usuario se encuentre conectado, obteniendo de esta forma las siguientes mejoras tanto en los servidores como en los clientes.

Aumento del número de resultados. Al eliminar la dependencia de la conexión con el servidor, el número de archivos encontrados en el proceso de búsqueda, el número de fuentes encontradas que tienen disponible el archivo para compartir y el número de comentarios de los usuarios que califican los archivos, serán mayores. Reducción del tiempo de transferencia del archivo. Dado que el número de fuentes encontradas es mayor, se reducirá considerablemente el tiempo de transferencia del archivo, ya que la probabilidad de conexión a un mayor número de pares se incrementa.

Diseño e implementación de un proto colo peer-to-peer

Diseño e implementación de un proto colo peer-to-peer

Eliminación del m antenimiento de una lista de servidores.

dependencia con de servidores en

conexión, por lo q ue se le libera de una tarea innecesaria.

Al no existir una

el servidor, los clientes no tendrán que ma ntener una lista la que elegir sus favoritos y su prioridad e n el proceso de

Óptima gestión entre un servidor

de los recursos. Al eliminar una preferen cia de conexión

u otro, las conexiones de los clientes en tre los distintos

servidores de la re d estarán más equilibradas.

Eficiente reparto de la carga de trabajo. Al realizar un gestió n óptima de los

caso los servidores que se encuentran conec tados a la red, el

búsqueda de un

recursos, en este reparto de carga

archivo entre los u suarios de la red estarán más equilibradas.

de trabajo entre estos y las solicitudes de

Para poder desarrol lar el principal objetivo del proyecto, es n ecesario que los

los clientes que

se encuentren conectados a la red P2P. Dado el gran número de clien tes de este tipo de redes, es inviable que u n servidor albergue toda ésta información, y a que manejaría una gran volumen de dat os que además estaría duplicado en el rest o de servidores.

servidores compartan la m isma información acerca de los archivos y de

Por este motivo, la arqu itectura propuesta se basa en la conexió n de todos los servidores a una red IP mu lticast, para así poder distribuir la informaci ón por medio de

mensajes sin la necesidad

de almacenarla en la base de datos de cada

uno de ellos.

mensajes sin la necesidad de almacenarla en la base de datos de cada uno de ellos.

Figura 15. Arquitectura propuesta

Capítulo 4

Análisis del Sistema

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

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

4.1 IDENTIFICACIÓN DE NECESIDADES

4.1.1 ALCANCE DEL SISTEMA

El objetivo del proyecto es el diseño e implementación de un protocolo P2P, que mejore el proceso de búsqueda de los archivos entre los usuarios que se encuentren conectados a la red, ya que, como se detalló en el capítulo anterior, en los actuales clientes de búsqueda y transferencia P2P, el proceso de búsqueda de archivos y su posterior transferencia están condicionados al servidor al que se encuentre conectado el cliente.

Para poder mejorar el proceso de búsqueda, es necesario eliminar la dependencia de los clientes al servidor que se encuentren conectados, haciendo obligatorio que los servidores compartan la misma información acerca de los archivos y de los clientes que se encuentren conectados a la red P2P. Dado el gran número de clientes de este tipo de redes, es inviable que un servidor albergue toda ésta información, ya que manejaría una gran volumen de datos que además estaría duplicado en el resto de servidores. Por este motivo, la arquitectura propuesta se basa en la conexión de todos los servidores a una red IP multicast, para así poder distribuir la información por medio de mensajes sin la necesidad de almacenarla en la base de datos de cada uno de ellos.

de mensajes sin la necesidad de almacenarla en la base de datos de cada uno de

Figura 16. Red IP multicast

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

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

Cuando un cliente de la red P2P desea realizar una búsqueda de un determinado archivo, envía una solicitud de búsqueda al servidor al que se encuentra conectado. El servidor procesa la solicitud, realizando una consulta en su base de datos, en la que están registrados todos los archivos de los clientes con los que mantiene una conexión. Al finalizar la consulta, transmite la solicitud de búsqueda del cliente a la red IP multicast para que todos los servidores, que se encuentran conectados a esta red, reciban dicha solicitud y consulten en sus bases de datos, al igual que hizo el primer servidor, para obtener los resultados que satisfacen la petición. Una vez consultada la base de datos, se envían los resultados al servidor que los solicitó para añadir esos resultados a los que ya tenía. Una vez terminado este proceso, todos los resultados se envían al cliente que inició el proceso de búsqueda.

El proceso anteriormente explicado, se realiza tanto para las búsquedas de archivos, para las búsquedas de comentarios de los archivos que comparten los clientes, como para las búsquedas de los clientes que tienen el archivo que el usuario desea descargarse.

4.1.2 TOPOLOGÍA DE USUARIOS FINALES

Hay que distinguir entre dos tipos de usuarios claramente definidos por su uso de la aplicación diseñada.

Por una parte se encuentran los administradores de los servidores de la red, personas con conocimientos de la aplicación, conocimientos de bases de datos y con derechos a acceso a esta para realizar los procesos de control y mantenimiento que crean adecuados. Además este tipo de usuario será el encargado de establecer una política, y mantener su cumplimiento, con respecto al tipo de archivos que maneje el servidor que se encuentra a su cargo.

Por otro lado, se encuentran los usuarios de la aplicación cliente, la cual es utilizada para buscar y transferir archivos con otros usuarios de la red.

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

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

4.1.3 RESTRICCIONES

No existe ningún tipo de restricción de tipo económica, ya que estas no son considerables en el desarrollo del proyecto.

Sin embargo, sí existen restricciones de carácter temporal, ya que el proyecto ha de ser presentado en Junio del 2009, la planificación de este está condicionada a esta fecha.

Con respecto a restricciones tecnológicas, dado que el lenguaje a utilizado para la implementación del protocolo ha sido Java, las máquinas en las que se ejecute tanto el cliente como el servidor, han de tener instaladas una implementación de la Máquina Virtual Java. Con respecto al sistema operativo, al haber elegido un lenguaje multiplataforma, no existe ninguna restricción en lo referente al entorno de ejecución de la aplicación.

4.2 ANÁLISIS DE REQUISITOS

4.2.1 CONTEXTO GENERAL DEL SISTEMA

Este contexto general del sistema está representado mediante un diagrama de presentación, con símbolos y figuras, donde se muestra la iteración del sistema con el cliente, y las relaciones entre ambos.

del sistema con el cliente, y las relaciones entre ambos. Figura 17. Contexto general del sistema
del sistema con el cliente, y las relaciones entre ambos. Figura 17. Contexto general del sistema
del sistema con el cliente, y las relaciones entre ambos. Figura 17. Contexto general del sistema

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

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

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

realizar una búsqueda, envía una solicitud al servidor al que se encuentra conectado. El servidor procesa la solicitud, consultando en su base de datos, en la que están registrados todos los archivos de los clientes con los que mantiene una conexión. Al finalizar la consulta, transmite la solicitud del cliente a la red IP multicast para que todos los servidores, que se encuentran conectados a esta red, la reciban y consulten en sus bases de datos, al igual que lo hizo el primer servidor, para obtener de esta forma más resultados que satisfacen la petición. Una vez consultada la base de datos, envían los resultados al servidor que los solicitó para añadir esos resultados a los que ya tenía. Una vez terminado este proceso, todos los resultados se envían al cliente que inició el proceso de búsqueda.

El proceso anterior, se realiza tanto para las búsquedas de archivos, como para las búsquedas de comentarios de los archivos que comparten los clientes, como para las búsquedas de los clientes que tienen el archivo que el usuario desea descargarse.

Después de que el cliente obtenga los resultados de los clientes que tienen un determinado archivo disponible para su transferencia, éste realiza una conexión con cada uno de ellos para obtener las partes del archivo que necesite.

con cada uno de ellos para obtener las partes del archivo que necesite. Figura 18. Conexiones

Figura 18. Conexiones entre clientes de la red

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

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

4.2.2 ÁMBITO DEL SISTEMA

Partiendo de los objetivos señalados en el anterior capítulo, se definen a continuación, las entidades principales del proyecto.

Hermes. Es la aplicación cliente que ejecuta el usuario para la búsqueda y

posterior transferencia de archivos. Mantiene conexiones con otros pares de la red para la transferencia de archivos, ya sea porque los haya solicitado este

u otro par.

Servidor. Es la entidad a la los clientes que se encuentran conectados para solicitar determinados servicios, ya sean de búsqueda de archivos, comentarios o clientes que ofrecen un determinado archivo. Además mantiene un conexión con la red IP multicast para enviar la solicitud del cliente al resto de los servidores que se encuentran conectados a la red. Delphic. Es la base de datos en la cual se encuentran registrados los usuarios conectados a la red y los archivos que comparten, así sus comentarios. Es consultada por la aplicación servidora para satisfacer las peticiones de los clientes.

4.2.3 ÁMBITO DEL CLIENTE

Partiendo de los objetivos señalados en el capítulo anterior, los requisitos identificados en la aplicación cliente, son lo que se muestran a continuación.

Eliminación de lista de servidores. Con la finalidad de eliminar el mantenimiento de la lista de servidores por parte del cliente, y la elección de sus favoritos, este recibirá la información necesaria acerca de los servidores que se encuentran conectados a la red, para su agregación automática en la lista de servidores. Limitación de búsquedas. Con el fin de que los resultados de las búsquedas se

ciñan más a los requisitos del usuario, este podrá introducir el tipo de archivo

a buscar, obteniendo de esta forma un conjunto de resultados más limitado a las necesidades del cliente.

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

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

Transferencias simultáneas. Para poder reducir el tiempo de las transferencias, los clientes mantendrán distintas conexiones entre los pares de la red para así poder mantener transferencias paralelas, tanto de subida de un archivo como de descarga. Control de errores de conexión. Con el objetivo de controlar los posibles errores de las conexiones entre clientes, si ocurriese alguna desconexión imprevista de alguno de estos, el resto de los clientes mantendrán la conexión con los clientes a los que se encuentran conectados, sin afectar a las comunicaciones ni a los datos transferidos. Incremento paulatino del tamaño del fichero temporal. Con el fin de realizar una correcta gestión del espacio del disco duro del usuario, el tamaño del archivo temporal asociado a una descarga, se incrementará a medida que la descarga avanza y no se establecerá al tamaño del archivo original, como sucede en los actuales clientes. Previsualización de los archivos. Con la finalidad de eliminar los archivos corruptos, los clientes podrán reproducir los archivos multimedia que se encuentran descargando sin la necesidad de que estos estén completamente descargados. Será requisito indispensable en este caso, que el cliente disponga de la una aplicación instalada en su equipo que permita la reproducción de archivos multimedia.

Para el desarrollo del cliente se ha elegido una arquitectura de tres capas, con el objetivo de reducir las dependencias y mantener acotado el impacto de los cambios. Los elementos agrupados en una misma capa pueden comunicarse entre sí. Cada capa presta sus servicios a la capa superior y depende de los servicios prestados por la inferior.

Esta descomposición separa los diferentes módulos de los que consta la aplicación, proporcionando transparencia para modificar el sistema. Cada subsistema engloba una funcionalidad diferente de la aplicación. La independencia entre los subsistemas identificados permite realizar modificaciones sobre cualquier capa sin afectar a la interfaz del resto de componentes.

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

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

Las capas identificadas en el ámbito del cliente son las que se muestran a continuación.

ámbito del cliente son las que se muestran a continuación. Figura 19. Capas de la aplicación

Figura 19. Capas de la aplicación cliente

GUI. Es la capa más cercana al usuario. Recoge la interfaz gráfica que este utilizará para interactuar con el sistema y redirige sus peticiones a la capa de lógica. Lógica. Recoge toda la lógica del cliente, necesaria para la gestión de los archivos locales, las transferencias de archivos en la red y las solicitudes de servicios a la capa de comunicaciones. Comunicaciones. Recoge la implementación del protocolo desarrollado, y las comunicaciones tanto con el servidor al que el usuario se encuentra conectado, como las comunicaciones con el resto de los clientes para la transferencia de archivos.

4.2.4 ÁMBITO DEL SERVIDOR

Partiendo de los objetivos señalados en el capítulo anterior, los requisitos identificados en la aplicación servidor, son lo que se muestran a continuación.

Comunicación entre servidores. Con la finalidad de que las búsquedas sean independientes del servidor al que se esté conectado, los servidores distribuirán una lista en la que estén registrados los usuarios conectados a la red y los archivos que comparten, así como sus comentarios. Gestión de comentarios. Para otorgar una mayor información a los clientes con respecto a los archivos que se descargan, los servidores de la red gestionarán los comentarios de los usuarios con el fin de que éstos puedan solicitar esta información como si se tratase de un recurso más de la red.

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

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

Gestión de errores. Para conseguir un mantenimiento correctivo del sistema, los posibles errores que sucedan en el servidor, tras una solicitud de un cliente, se registrarán en un archivo log.

Para el desarrollo del servidor se ha elegido, al igual que el cliente, una arquitectura de tres capas, con el objetivo de reducir las dependencias y mantener acotado el impacto de los cambios.

Las capas identificadas en el ámbito del servidor son las que se muestran a continuación.

del servidor son las que se muestran a continuación. Figura 20. Capas de la aplicación servidor

Figura 20. Capas de la aplicación servidor

Comunicaciones. Recoge la implementación del protocolo desarrollado, y las comunicaciones tanto con el resto de los servidores de la red IP multicast, como las comunicaciones con los clientes que se encuentran conectados a él. Lógica. Recoge toda la lógica del servidor, necesaria para la gestión las solicitudes de los clientes y las solicitudes de servicios a la capa de acceso a la base de datos, DAO. DAO. Esta capa utiliza objetos DAO (Data Access Object) para abstraer y encapsular todo el acceso a la información contenida en la base de datos. Este conjunto de objetos gestiona la conectividad con la base de datos, exponiendo una interfaz más simple, actuando como adaptadores entre el componente de la lógica y la base de datos.

4.2.5 DECISIONES DE DISEÑO

El lenguaje de programación Java proporciona dos clases para la implementación de sockets. Estas clases son Socket y DatagramSocket. La principal diferencia entre

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

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

estas dos clases está en el uso del protocolo de transporte, mientras Socket hace uso del protocolo TCP (Transmission Control Protocol), DatagramSocket hace uso de UDP.

TCP proporciona una cantidad considerablemente mayor de servicios a las aplicaciones que UDP, ya que se trata de un protocolo orientado a conexión, a diferencia de UDP.

Las principales características de este protocolo son las que se detallan a continuación [GARC05].

Control de flujo. Mediante el uso de ventanas de envío y la identificación de paquetes transmitidos, se proporciona un modo para que dos sistemas cooperen activamente en la transmisión de paquetes para evitar exceso de flujo y pérdida de paquetes y adaptarse a la congestión de la red. Detección y corrección de errores. Mediante una utilidad de código de paridad, checksum 21 , números de secuencia, confirmaciones y temporizadores de retransmisión se asegura la integridad de los paquetes, dando lugar a que no existan rechazos. La retransmisión de los paquetes corrompidos o perdidos se puede manejar de una manera oportuna y eficiente. Reconocimiento del paquete recibido. El envío de un acknowledgement 22 por parte del emisor, permite al emisor saber que el receptor ha recibido los paquetes. Si los paquetes no son notificados, el transmisor puede reenviar los paquetes.

Como contrapartida, el protocolo TCP, al precisar de fases de establecimiento de la conexión y liberación, conlleva muchos más controles que el protocolo UDP, llegando a aumentar el tiempo de procesamiento considerablemente.

21 El término checksum se refiere a una forma de control de redundancia empleada en comunicaciones y en almacenamiento de datos que consiste en el almacenamiento de la suma de bytes para su posterior comparación.

22 El término acknowledgement se refiere a un mensaje enviado por el receptor al emisor indicando bien que éste está listo para recibir una transmisión o que una transmisión fue recibida sin error.

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

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

A pesar del inconveniente anterior, se ha implementado la comunicación entre cliente y servidor y entre clientes haciendo uso de la clase Socket, y por consiguiente del protocolo TCP, ya que se ha considerado que las características que aporta este protocolo son más significativas que el inconveniente de su uso.

Ya que la arquitectura propuesta entre los servidores de la red P2P es una arquitectura basada en una red IP multicast, se ha hecho uso de la única clase que proporciona el lenguaje de programación Java para la implementación de conexiones a este tipo de redes. Esta clase es MulticastSocket, y es un caso particular de la clase DatagramSocket con capacidades adicionales para la conexión a grupos de redes IP multicast [MICRO04]. Por este motivo el uso de UDP como protocolo de transporte en las comunicaciones de los servidores conectados a la red IP multicast ha sido establecida por el lenguaje de programación utilizado.

Para la identificación de los archivos que los clientes ponen a disposición de la red P2P, ha sido necesario el uso de un sistema de funciones hash criptográficas para asegurar que la identificación se realiza de forma unívoca.

Actualmente existen varios algoritmos hash, entre los que se encuentra SHA1. Este algoritmo procesa la información de un archivo en bloques de 512 bits y produce un valor de 160 bits, lo que le otorga una mayor seguridad que algoritmos que produces valores hash de 128 bits, como es el caso de RIPEMD 23 (RACE Integrity Primitives Evaluation Message Digest). Además, hasta hoy día, no se han registrado ataques contra este algoritmo, comprometiendo su resistencia, como sí sucede con otros como MD5. En el año 2005, Xiaoyun Wang y Hongbo Yu de la Universidad Shandong, China, publicaron un artículo en el cual se describía la forma de encontrar dos secuencias diferentes de 128 bits con el mismo valor hash MD5 [WANG04].

Los hechos anteriormente detallados han sido los motivos de elección del algoritmo SHA1 como función hash para el cálculo de identificadores de los archivos de la red P2P.

23 El término RIPEMD se refiere a un algoritmo de función hash diseñado por Hans Dobbertin, Antoon Bosselaers y Bart Preneel para el uso en comprobaciones de integridad de mensajes que produce un identificador de un archivo de 128 bits.

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

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

4.3 METODOLOGÍA

Para la realización del proyecto se ha aplicado la metodología UML (Unified Modeling Language) en su versión 2.0, ya que se utiliza un lenguaje que permite de forma gráfica visualizar, especificar, construir y documentar un sistema [OMG09].

Además, ofrece un estándar para describir el modelo de un sistema, incluyendo aspectos conceptuales como reglas de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, modelos de bases de datos y componentes reutilizables.

4.3.1 DIAGRAMA DE DOMINIO

Un

diagrama

de

dominio

muestra

los

conceptos

básicos

del

dominio,

sus

propiedades más importantes y las relaciones entre dichos conceptos.

El diagrama de dominio del sistema es el que se muestra a continuación.

y las relaciones entre dichos conceptos. El diagrama de dominio del sistema es el que se
Diseño e implementación de un protocolo peer-to-peer

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

Diseño e implementación de un protocolo peer-to-peer Figura 21. Diagrama de dominio del sistema 53
Diseño e implementación de un protocolo peer-to-peer Figura 21. Diagrama de dominio del sistema 53

Figura 21. Diagrama de dominio del sistema

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

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

4.3.2 DIAGRAMA DE CASOS DE USO

Un diagrama de casos de uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.

El diagrama de casos de uso para el usuario de la aplicación cliente es el que se muestra a continuación.

Conectar a la red P2P Buscar archivos en la red P2P Buscar comentarios de un
Conectar a la red
P2P
Buscar archivos en
la red P2P
Buscar comentarios
de un archivo
Eliminar resultados
de una búsqueda
Descargar archivo
de la red P2P
Previsualizar
archivo
Usuario
Añadir comentario
a un archivo
Ver comentarios de
un archivo local
Eliminar comentario
de un archivo local
Recargar archivos
locales

Figura 22. Diagrama de casos de uso del usuario de la aplicación cliente

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

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

Seguidamente, se detalla cada uno de los casos de uso descritos en el diagrama anterior.

CASOS DE USO.

- Conectar a la red P2P. Conexión a la red P2P para poder comenzar con la búsqueda de archivos o continuar con las transferencias pendientes.

- Buscar archivos en la red P2P. Búsqueda de archivos en la red P2P introduciendo el nombre del archivo o parte de él, con la posibilidad de limitación de la búsqueda, seleccionando el tipo de archivo a buscar.

- Buscar comentarios de un archivo. Una vez obtenidos los resultados de una búsqueda, búsqueda de los comentarios con los que otros usuarios han calificado un determinado archivo.

- Eliminar resultado de una búsqueda. Eliminación de los resultados de una búsqueda en caso de que estos no sean satisfactorios para el usuario o por cualquier motivo no sean necesarios.

- Descargar un archivo de la red P2P. Descarga de un archivo seleccionado de entre los resultados de una búsqueda o descarga de los archivos pendientes.

- Previsualizar archivo. Previsualización de un archivo en estado de descarga, una vez iniciada esta y con al menos el primer trozo del archivo descargado (RN01).

- Añadir comentario. Insertar la evaluación de un archivo y su comentario de un archivo descargado o en estado de descarga.

- Ver comentarios de un archivo local. Visualización de los comentarios de los archivos que el usuario pone a disposición del resto de usuarios de la red P2P.

- Eliminar comentario de un archivo local. Eliminación, por cualquier motivo que considere el usuario, de un comentario de un archivo local.

- Recargar archivos locales. Recarga de los archivos locales y sincronización con el servidor al que el usuario se encuentra conectado, por si el usuario ha eliminado un archivo o introducido uno nuevo.

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

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

REGLAS DE NEGOCIO.

- RN01. Prioridad de partes de un archivo. Con la finalidad de que el archivo pueda ser previsualizado, es necesario que la primera parte, y en algunos casos la última, esté completamente descargada. Por este motivo, esta primera parte tendrá mayor prioridad, seguida de la última y a continuación del resto.

4.3.3 DIAGRAMA DE PAQUETES

Los diagramas de paquetes reflejan la organización de los subsistemas en que se descompone el sistema y las dependencias entre ellos. Representa una visión fundamental para el control de alto nivel de un sistema.

El diagrama de paquetes es el que se muestra a continuación.

diagrama de paquetes es el que se muestra a continuación. Figura 23. Diagrama de paquetes A

Figura 23. Diagrama de paquetes

A continuación se detalla cada uno de los paquetes que aparecen en el diagrama anterior.

Paquete gui. Contiene la interfaz gráfica del usuario y gestiona las acciones de este sobre cada una de sus componentes.

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

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

Paquete client. Contiene toda la lógica del cliente en clases denominadas gestores, como son los gestores de transferencias, comentarios, archivos locales y demás. Paquete constants. Contiene la definición de las constantes usadas por la aplicación, como definición de directorios, ficheros necesarios para la ejecución y tipos de datagramas y paquetes. Paquete útil. Contiene las definiciones de los conceptos del dominio del sistema. Paquete packets. Contiene la definición de los paquetes que se transmiten en la comunicación del cliente con el servidor y el cliente con el resto de los clientes de la red P2P. Paquete data. Contiene la información de los datagramas que se transmiten en la comunicación entre los servidores de las red IP multicast. Paquete server. Contiene toda la lógica del servidor para el servicio de solicitudes y la gestión del fichero de control de errores. Paquete dao. Contiene la abstracción del acceso a la base de datos por parte del servidor.

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

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

4.3.4 DIAGRAMA DE CLASES

A continuación se detallan cada una de las clases de cada unos de los paquetes anteriores.

Las clases del paquete gui son las que se muestran a continuación.

anteriores. Las clases del paquete gui son las que se muestran a continuación. Figura 24. Clases

Figura 24. Clases del paquete gui

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

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

Las clases del paquete client son las que se muestran a continuación.

Las clases del paquete client son las que se muestran a continuación. Figura 25. Clases del

Figura 25. Clases del paquete client

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

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

Las clases del paquete constants son las que se muestran a continuación.

Las clases del paquete constants son las que se muestran a continuación. Figura 26. Clases del

Figura 26. Clases del paquete constants

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

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

Las clases del paquete util son las que se muestran a continuación.

peer-to-peer Las clases del paquete util son las que se muestran a continuación. Figura 27. Clases

Figura 27. Clases del paquete util

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

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

Las clases del paquete packets son las que se muestran a continuación.

Las clases del paquete packets son las que se muestran a continuación. Figura 28. Clases del

Figura 28. Clases del paquete packets

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

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

Las clases del paquete data son las que se muestran a continuación.

peer-to-peer Las clases del paquete data son las que se muestran a continuación. Figura 29. Clases

Figura 29. Clases del paquete data

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

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

Las clases del paquete server son las que se muestran a continuación.

Las clases del paquete server son las que se muestran a continuación. Figura 30. Clases del

Figura 30. Clases del paquete server

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

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

Las clases del paquete dao son las que se muestran a continuación.

del paquete dao son las que se muestran a continuación. Figura 31. Clases del paquete dao

Figura 31. Clases del paquete dao

4.3.5 DISEÑO DE LA BASE DE DATOS

A continuación se detallan las tablas y relaciones que componen la base de datos de la aplicación.

TABLA EXTENSIONS.

- Descripción: contiene las extensiones de los archivos.

- Relación con: ninguna tabla.

- Sentencia de creación: CREATE TABLE DELPHIC.EXTENSIONS(

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

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

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

EXTENSIONS

PK

EXTENSION: varchar(6)

TYPE: varchar(8)

TABLA SHARES. - Descripción: contiene los archivos de los usuarios conectados a la red. -
TABLA SHARES.
- Descripción: contiene los archivos de los usuarios conectados a la red.
- Relación con: ninguna tabla.
- Sentencia de creación: CREATE TABLE DELPHIC.SHARES(
NAME VARCHAR(256) NOT NULL,
SIZE BIGINT NOT NULL,
HASH CHAR(40) NOT NULL,
EXTENSION VARCHAR(6) NOT NULL,
COUNTER INT NOT NULL DEFAULT 0,
PRIMARY KEY(NAME,HASH)
)ENGINE=INNODB DEFAULT CHARSET=latin1;
TABLA CLIENTS.

- Descripción: contiene la información de los clientes conectados a la red.

- Relación con: COMMENTS.

- Sentencia de creación: CREATE TABLE DELPHIC.CLIENTS(

IP VARCHAR(15) NOT NULL, HASH CHAR(40) NOT NULL, NAME VARCHAR(256) NOT NULL, PRIMARY KEY(IP,HASH) )ENGINE=INNODB DEFAULT CHARSET=latin1;

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

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

Diseño e implementación de un protocolo peer-to-peer TABLA COMMENTS. - Descripción: contiene los comentarios de los

TABLA COMMENTS.

- Descripción: contiene los comentarios de los usuarios conectados a la red.

- Relación con: CLIENTS.

- Sentencia de creación:

CREATE TABLE DELPHIC.COMMENTS(

NCOMMENT INT NOT NULL AUTO_INCREMENT, CLIENTIP VARCHAR(15) NOT NULL, HASH CHAR(40) NOT NULL, COMMENT VARCHAR(120), EVALUATION TINYINT, PRIMARY KEY(NCOMMENT), INDEX (CLIENTIP,HASH), FOREIGN KEY(CLIENTIP,HASH) REFERENCES DELPHIC.CLIENTS(IP,HASH) ON DELETE CASCADE)ENGINE=INNODB DEFAULT

CHARSET=latin1;

COMMENTS

PK

NCOMMENT: int

FK1,I1

FK1,I1

CLIENTIP: varchar(15) HASH: char(40) COMMENT: varchar(120) EVALUATION: tinyint

Capítulo 5

Protocolo del Sistema

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

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

5.1 PROTOCOLO ENTRE CLIENTE Y SERVIDOR

5.1.1 SOLICITUD DE CONEXIÓN A LA RED PEER-TO-PEER

Cuando un cliente se conecta la red P2P, se envía un paquete a la dirección IP del servidor para que se contemple la nueva agregación de este cliente, registrando en la base de datos la dirección del cliente, los archivos que comparte y sus comentarios. El servidor acredita al nuevo cliente con el correspondiente paquete de contestación.

cliente con el correspondiente paquete de contestación. Figura 32. Solicitud de conexión a la red P2P

Figura 32. Solicitud de conexión a la red P2P

PAQUETE REQUEST_CONNECT.

-

Implementado por la clase: ConnectPacket.

Datos. La dirección IP del cliente y los archivos que pone a disposición de la red P2P. PAQUETE REPLY_ CONNECT.

-

- Implementado por la clase: StandardPacket.

- Datos. Sin datos. El tipo de paquete transmitido es la propia confirmación del protocolo.

5.1.2 SOLICITUD DE BÚSQUEDA DE ARCHIVOS

Cuando un cliente solicita una búsqueda de archivos, se envía un paquete a la dirección IP del servidor al que se encuentra conectado para que consulte su base de datos. El servidor contesta con los resultados que satisfacen los requisitos de búsqueda del archivo, tanto los suyos como los que provienen de la red IP multicast.

archivo, tanto los suyos como los que provienen de la red IP multicast. Figura 33. Solicitud
archivo, tanto los suyos como los que provienen de la red IP multicast. Figura 33. Solicitud
archivo, tanto los suyos como los que provienen de la red IP multicast. Figura 33. Solicitud
archivo, tanto los suyos como los que provienen de la red IP multicast. Figura 33. Solicitud
archivo, tanto los suyos como los que provienen de la red IP multicast. Figura 33. Solicitud
archivo, tanto los suyos como los que provienen de la red IP multicast. Figura 33. Solicitud
archivo, tanto los suyos como los que provienen de la red IP multicast. Figura 33. Solicitud

Figura 33. Solicitud de búsqueda de archivos

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

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

PAQUETE REQUEST_SEARCH.

-

Implementado por la clase: RequestSearchPacket.

Datos. La secuencia de la cadena de búsqueda y el tipo de archivo a buscar. PAQUETE REPLY_SEARCH.

-

- Implementado por la clase: ReplySearchPacket.

- Datos. Los archivos que satisfacen los requisitos de búsqueda.

5.1.3 SOLICITUD DE BÚSQUEDA DE COMENTARIOS

Cuando un cliente solicita una búsqueda de comentarios de un archivo determinado, se envía un paquete a la dirección IP del servidor al que se encuentra conectado para que consulte su base de datos. El servidor contesta con los resultados que satisfacen los requisitos de búsqueda de la solicitud, tanto los suyos como los que provienen de la red IP multicast.

los suyos como los que provienen de la red IP multicast. Figura 34. Solicitud de búsqueda
los suyos como los que provienen de la red IP multicast. Figura 34. Solicitud de búsqueda
los suyos como los que provienen de la red IP multicast. Figura 34. Solicitud de búsqueda
los suyos como los que provienen de la red IP multicast. Figura 34. Solicitud de búsqueda
los suyos como los que provienen de la red IP multicast. Figura 34. Solicitud de búsqueda
los suyos como los que provienen de la red IP multicast. Figura 34. Solicitud de búsqueda
los suyos como los que provienen de la red IP multicast. Figura 34. Solicitud de búsqueda

Figura 34. Solicitud de búsqueda de comentarios

PAQUETE REQUEST_COMMENTS.

- Implementado por la clase: RequestCommentsPacket.

- Datos. El valor de la función hash que identifica un archivo en la red

P2P.

PAQUETE REPLY_ COMMENTS.

- Implementado por la clase: ReplyCommentsPacket.

- Datos. Los comentarios que satisfacen los requisitos de búsqueda.

5.1.4 SOLICITUD DE BÚSQUEDA DE CLIENTES

Cuando un cliente solicita una búsqueda de otros clientes que tienen disponible un archivo determinado para su transferencia, se envía un paquete a la dirección IP del servidor al que se encuentra conectado para que consulte su base de datos. El servidor

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

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

contesta con las direcciones IP de los clientes que satisfacen los requisitos de búsqueda de la solicitud, tanto las que tiene registradas en sus base de datos como las que provienen de la red IP multicast.

de datos como las que provienen de la red IP multicast. Figura 35. Solicitud de búsqueda
de datos como las que provienen de la red IP multicast. Figura 35. Solicitud de búsqueda
de datos como las que provienen de la red IP multicast. Figura 35. Solicitud de búsqueda
de datos como las que provienen de la red IP multicast. Figura 35. Solicitud de búsqueda
de datos como las que provienen de la red IP multicast. Figura 35. Solicitud de búsqueda
de datos como las que provienen de la red IP multicast. Figura 35. Solicitud de búsqueda

Figura 35. Solicitud de búsqueda de comentarios

PAQUETE REQUEST_COMMENTS.

- Implementado por la clase: RequestIPsPacket.

- Datos. El valor de la función hash que identifica un archivo en la red

P2P.

PAQUETE REPLY_ COMMENTS.

- Implementado por la clase: ReplyIPsPacket.

- Datos. Las direcciones IP de los clientes que tienen disponible un archivo determinado para su transferencia.

5.1.5 SOLICITUD DE SINCRONIZACIÓN

Cuando un cliente ha terminado de descargar completamente un archivo de la red P2P, se envía un paquete a la dirección IP del servidor al que se encuentra conectado para que añada a la disponibilidad del archivo a este cliente.

que añada a la disponibilidad del archivo a este cliente. Figura 36. Solicitud de sincronización de
que añada a la disponibilidad del archivo a este cliente. Figura 36. Solicitud de sincronización de
que añada a la disponibilidad del archivo a este cliente. Figura 36. Solicitud de sincronización de
que añada a la disponibilidad del archivo a este cliente. Figura 36. Solicitud de sincronización de
que añada a la disponibilidad del archivo a este cliente. Figura 36. Solicitud de sincronización de

Figura 36. Solicitud de sincronización de archivos

PAQUETE REQUEST_SYNCHRONIZE.

- Implementado por la clase: SynchronizePacket.

- Datos. El archivo descargado del cliente.

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

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

5.1.6 SOLICITUD DE DESCONEXIÓN DE LA RED PEER-TO-PEER

Cuando un cliente se desconecta la red P2P, se envía un paquete a la dirección IP del servidor para que se contemple la desconexión de este cliente, eliminando los registros de la base de datos, los archivos que comparte y sus comentarios. El servidor acredita la desconexión con el correspondiente paquete de contestación.

con el correspondiente paquete de contestación. Figura 37. Solicitud de des conexión a la red P2P
con el correspondiente paquete de contestación. Figura 37. Solicitud de des conexión a la red P2P
con el correspondiente paquete de contestación. Figura 37. Solicitud de des conexión a la red P2P
con el correspondiente paquete de contestación. Figura 37. Solicitud de des conexión a la red P2P
con el correspondiente paquete de contestación. Figura 37. Solicitud de des conexión a la red P2P
con el correspondiente paquete de contestación. Figura 37. Solicitud de des conexión a la red P2P
con el correspondiente paquete de contestación. Figura 37. Solicitud de des conexión a la red P2P

Figura 37. Solicitud de desconexión a la red P2P

PAQUETE REQUEST_COMMENTS.

-

Implementado por la clase: StandardPacket.

Datos. La dirección IP del cliente que se desconecta de la red P2P. PAQUETE REPLY_ COMMENTS.

-

- Implementado por la clase: StandardPacket.

- Datos. Sin datos. El tipo de paquete transmitido es la propia confirmación del protocolo.

5.2 PROTOCOLO ENTRE SERVIDORES

5.2.1 SOLICITUD DE CONEXIÓN A LA RED MULTICAST

Cuando un servidor se conecta la red IP multicast, se envía un datagrama a la dirección de esta red para que el resto de los servidores contemplen la nueva agregación del servidor. El resto de los servidores conectados a la red IP multicast, acreditan a este nuevo servidor con el correspondiente datagrama de contestación.

servidor con el correspondiente datagrama de contestación. Figura 38. Solicitud de conexión a la red IP

Figura 38. Solicitud de conexión a la red IP multicast

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

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

DATAGRAMA REQUEST_JOIN.

-

Implementado por la clase: RequestJoinData.

Datos. La dirección IP y el puerto asignado a la red IP multicast del servidor que solicita la conexión. DATAGRAMA REPLY_JOIN.

-

- Implementado por la clase: ReplyJoinData.

- Datos. La dirección IP y el puerto asignado a la red IP multicast del servidor que contesta a la solicitud de conexión.

5.2.2 SOLICITUD DE BÚSQUEDA DE ARCHIVOS

Cuando un servidor solicita una búsqueda de archivos, se envía un datagrama a la dirección de la red IP multicast para que el resto de los servidores consulten sus bases de datos. El resto de los servidores contestan con los resultados que satisfacen los requisitos de búsqueda del archivo.

que satisfacen los requisitos de búsqueda del archivo. Figura 39. Solicitud de búsqueda de archivos a

Figura 39. Solicitud de búsqueda de archivos a la red IP multicast

DATAGRAMA REQUEST_SEARCH.

-

Implementado por la clase: RequestSearchData.

Datos. La secuencia de la cadena de búsqueda y el tipo de archivo a buscar. DATAGRAMA REPLY_ SEARCH.

-

- Implementado por la clase: ReplySearchData.

- Datos. Los archivos que satisfacen los requisitos de búsqueda.

5.2.3 SOLICITUD DE BÚSQUEDA DE COMENTARIOS

Cuando un servidor solicita una búsqueda de comentarios de un archivo determinado, se envía un datagrama a la dirección de la red IP multicast para que el

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

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

resto de los servidores consulten sus bases de datos. El resto de los servidores contestan con los resultados que satisfacen los requisitos de búsqueda de la solicitud.

que satisfacen los requisitos de búsqueda de la solicitud. Figura 40. Solicitud de búsqueda de comentarios

Figura 40. Solicitud de búsqueda de comentarios a la red IP multicast

DATAGRAMA REQUEST_SEARCH.

-

Implementado por la clase: RequestCommentsData.

Datos. El valor de la función hash que identifica un archivo en la red. DATAGRAMA REPLY_ SEARCH.

-

- Implementado por la clase: ReplyCommentsData.

- Datos. Los comentarios que satisfacen los requisitos de búsqueda.

5.2.4 SOLICITUD DE BÚSQUEDA DE CLIENTES

Cuando un servidor solicita una búsqueda de clientes que tienen disponible un archivo determinado para su transferencia, se envía un datagrama a la dirección de la red IP multicast para que el resto de los servidores consulten sus bases de datos. El resto de los servidores contestan con las direcciones IP de los clientes que satisfacen los requisitos de búsqueda de la solicitud.

que satisfacen los requisitos de búsqueda de la solicitud. Figura 41. Solicitud de búsqueda de direcciones

Figura 41. Solicitud de búsqueda de direcciones IP a la red IP multicast

DATAGRAMA REQUEST_IPS.

- Implementado por la clase: RequestIPsData.

- Datos. El valor de la función hash que identifica un archivo en la red.

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

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

DATAGRAMA REPLY_ IPS.

- Implementado por la clase: ReplyIPsData.

- Datos. Las direcciones IP de los clientes que tienen disponible un archivo determinado para su transferencia.

5.3 PROTOCOLO ENTRE CLIENTES

Cuando un cliente se conecta a otro par de la red P2P al que ha solicitado la descarga de un determinado archivo, su petición es insertada en la cola de descargas del cliente que sirve, para su posterior procesamiento. Cuando esta solicitud es atendida, el cliente que sirve el archivo envía un mensaje al cliente que solicita para que le indique el identificador de la parte del archivo que necesita.