Desarrollo de una aplicación BitTorrent (en Pharo-Smalltalk)
Trabajo Final de Grado
David Gracia Celemendi
Director: Jordi Delgado Pin Departamento de Ciencias de la Computación (CS)
Fecha de defensa: octubre de 2015
Titulación: Grado en Ingeniería Informática Especialidad: Computación
Facultad de Informática de Barcelona (FIB) página en blanco
1 Resumen Desde principios del 2000, el uso de redes peer-to-peer ha experimentado un gran crecimiento. Gran parte del tráfico de Internet lo generan las apli- caciones BitTorrent. BitTorrent especifica un protocolo para el intercambio de ficheros usando un modelo peer-to-peer que se caracteriza por su gran escalabilidad y robustez. Este proyecto consiste en el desarrollo de una apli- cación BitTorrent desde cero con el sistema Pharo-Smalltalk. Primero se hace un repaso a la historia del intercambio de ficheros desde sus inicios hasta la actualidad. Después se comparan las redes cliente-servidor con las redes peer-to-peer, y se distingue dentro de éstas últimas entre redes estruc- turadas y redes no estructuradas. Se da una explicación del funcionamiento de BitTorrent y, por último, se profundiza en el diseño y la implementación de la aplicación.
Abstract Since 2000 peer-to-peer networks use has increased very fast. Most Internet traffic is generated by BitTorrent applications. BitTorrent specify a file sharing protocol over peer-to-peer model whose strength is scalability and robustness. This project is about developing a BitTorrent application from scratch with Pharo-Smalltalk system. First of all, a file sharing history review is done from beginning up to now. Next, client-server and peer- to-peer models are compared, and peer-to-peer networks are classified in unstructured and structured. A brief summary of BitTorrent operation is done and, at the end, report go into detail about design and implementation of the application.
Keywords. peer-to-peer, p2p, bittorrent, swarming, smalltalk, pharo.
Agradecimientos
Gracias a Jordi Delgado por su ayuda durante el desarrollo del proyecto y en la elabora- ción de la memoria.
2 Índice
1. Introducción 7 1.1. Formulación del problema ...... 7 1.2. Actores implicados ...... 8 1.3. Objetivos generales ...... 8 1.4. Objetivos técnicos ...... 8 1.5. Sobre el proyecto y el formato de la memoria ...... 9
2. Contexto 10 2.1. Redes peer-to-peer ...... 10 2.1.1. Descubrimiento de recursos ...... 12 2.1.2. Aplicaciones ...... 14 2.2. Historia del intercambio de ficheros ...... 15 2.3. BitTorrent ...... 19 2.3.1. Funcionamiento ...... 19 2.3.2. Implementaciones existentes y últimos avances ...... 21
3. Metodología 22 3.1. Seguimiento ...... 22 3.2. Estilo de programación ...... 23 3.3. Validación del software ...... 23
4. Visión global de la aplicación 23
5. Diseño e implementación 26 5.1. Bencoding ...... 26 5.2. Los metadatos ...... 28 5.3. Acceso físico a los torrents ...... 29 5.4. Los nodos de la red ...... 31 5.5. Descubrimiento de peers ...... 31 5.5.1. Tracker HTTP ...... 31 5.5.2. Tracker UDP ...... 34 5.5.3. La clase BtMultitracker ...... 40 5.6. Control de las piezas ...... 41 5.7. Comunicación peer-to-peer ...... 42 5.7.1. Mensajes ...... 42 5.7.2. Sistema de colas ...... 46 5.7.3. La clase BtRemotePeer ...... 47
3 5.8. Piezas temporales ...... 49 5.9. Algoritmo de bloqueo ...... 50 5.10. Algoritmo de selección de piezas ...... 51 5.10.1. Rarest first ...... 51 5.10.2. Random ...... 51 5.10.3. Most common first ...... 52 5.10.4. Lower first ...... 52 5.11. End Game ...... 52 5.12. Conteo de las piezas en la red ...... 52 5.13. La clase BtRemotePeerCollection ...... 53 5.14. La clase BtTorrent ...... 55 5.14.1. Proceso: Validación incial ...... 56 5.14.2. Proceso: Tracker requesting ...... 56 5.14.3. Proceso: Choking ...... 57 5.14.4. Proceso: Optimistic Choking ...... 58 5.14.5. Proceso: Tratamiento de mensajes entrantes ...... 59 5.14.6. Proceso: Petición de bloques ...... 60 5.15. La clase BtLocalPeer ...... 62 5.15.1. Proceso: Escucha de puerto ...... 63 5.15.2. Proceso: Gestión de torrents ...... 64 5.15.3. Justificación de la necesidad de BtLocalPeer ...... 65
6. Planificación 66 6.1. Planificación inicial ...... 66 6.2. Modificaciones a la planificación inicial ...... 69
7. Presupuesto y sostenibilidad 69 7.1. Identificación de recursos y estimación de costes ...... 69 7.2. Viabilidad económica ...... 70 7.3. Impacto social y ambiental ...... 70
8. Conclusiones 71
9. Posibles ampliaciones 71
Adenda 73
A. Manual de usuario 73 A.1. Instalación de Pharo ...... 73 A.2. Ejecución de Pharo ...... 73
4 A.3. Importación de la librería ...... 74 A.4. Pruebas ...... 76 A.4.1. Pruebas unitarias ...... 76 A.4.2. Prueba global ...... 77
Acrónimos 80
Glosario 81
Referencias 88
5 Índice de figuras
1. BitTorrent. Proceso que siguen las propuestas de ampliación . . . .9 2. Comparación entre las arquitecturas cliente-servidor y peer-to-peer . 11 3. En Freenet, backtracking usado para encontrar un recurso ...... 12 4. Comparación topológica. Red peer-to-peer no estructurada. Red peer-to-peer estructurada ...... 13 5. Amiexpress ...... 15 6. Jerarquía de warez scene ...... 16 7. Usenet ...... 17 8. Funcionamiento de una red BitTorrent ...... 19 9. Perspectiva del peer local en el enjambre ...... 20 10. Diagrama de clases simplificado de la aplicación ...... 24 11. Ejemplo de colección de ficheros de un torrent...... 30 12. Jerarquía de clases de los nodos de la red ...... 32 13. Jerarquía de clases de los paquetes UDP ...... 36 14. Diagrama de Gantt del proyecto ...... 68 15. Selección de imagen en Pharo (Linux Mint) ...... 74 16. Menú global de Pharo ...... 75 17. Añadir un repositorio HTTP público a Pharo ...... 75 18. Exploración del paquete BitTalk en Pharo ...... 76 19. Captura de imágen de Pharo mostrando cómo ejecutar todas las pruebas unitarias de una vez ...... 77 20. Ejecución del código de la prueba global ...... 78
Índice de tablas
1. Características. Redes no estructuradas y estructuradas ...... 14 2. Planificación de las tareas ...... 67 3. Presupuesto ...... 70
6 1. Introducción
1.1. Formulación del problema
Este Trabajo de Fin de Grado (TFG) consiste en el desarrollo de una aplicación BitTorrent1 en el sistema Pharo-Smalltalk. BitTorrent es un protocolo diseñado para el intercambio de ficheros sobre una red peer-to-peer (P2P) que se usa para distribuir gran cantidad de información por Internet. Smalltalk es un estándar, públicamente disponible desde 1980[4], que define las especificaciones de un sistema computacional que dispone de
una biblioteca (generalmente grande) de objetos que viven dentro del sistema y se comunican mediante mensajes;
un fichero llamado «imagen» que contiene el estado del sistema;
un lenguaje de programación (también llamado Smalltalk) completamente orientado a objetos, con tipado dinámico y reflexivo;
un entorno de desarrollo, compilación y ejecución;
y una máquina virtual que se encarga de interpretar todos los mensajes y actualizar el estado del sistema y los objetos.
Se puede considerar a un sistema Smalltalk como un mundo virtual donde existen objetos «vivos» que se comunican. Estos objetos pueden ser creados, modificados y eliminados sin necesidad de detener o reiniciar el sistema. Una implementación de Smalltalk es cualquier sistema que cumpla las especi- ficaciones del estándar. La implementación que se va a usar en este proyecto es Pharo (versión 3.0).
1La expresión común para referirse a este tipo de programas es «cliente BitTorrent», pero es incorrecta porque en estas redes no existen los roles exclusivos de cliente y servidor: solo existen peers. En este documento se reserva el uso de «peer» para el concepto abstracto de nodo participante en la red, y el de «aplicación BitTorrent» para el programa que ejecutan los peers
7 1.2. Actores implicados
Las siguientes personas están implicadas o se ven afectadas por el desarrollo del proyecto:
Autor del proyecto: David Gracia Celemendi.
Director del proyecto: Jordi Delgado Pin. Miembro del Consejo de Di- rección del European Smalltalk User Group (ESUG) y Coordinador de l’Associació Smalltalk.cat. Se encargará de supervisar los aspectos técnicos del proyecto.
Comunidad de usuarios y desarrolladores de Pharo-Smalltalk. Se beneficiarán de la primera librería que implementa BitTorrent en esta co- munidad. La librería supondrá una base para desarrollar otros proyectos relacionados con BitTorrent y redes P2P.
1.3. Objetivos generales
Los objetivos principales del proyecto son:
Diseñar e implementar el conjunto de clases que representen la naturaleza y el funcionamiento de las redes BitTorrent.
El diseño y la implementación deben ser fácilmente comprensibles y amplia- bles por cualquier desarrollador de Pharo-Smalltalk que conozca el funcio- namiento de BitTorrent.
1.4. Objetivos técnicos
BitTorrent está compuesto por una serie de documentos llamados BitTorrent En- hancement Proposal (BEP) que detallan el funcionamiento del protocolo. Un BEP es una propuesta de ampliación de alguna parte de BitTorrent, que especifica una nueva funcionalidad o comportamiento de la red o de los actores implicados. Todos los BEP pueden encontrarse en http://www.bittorrent.org/beps/bep_0000. html. Estas propuestas están sujetas a un proceso de ampliación que establece que una propuesta debe pasar por unas fases antes de ser considerada definitiva por el Benevolent Dictator for Life (BDFL) y creador de BitTorrent, Bram Cohen.
8 Figura 1: Proceso que siguen las propuestas de ampliación
Existen varios BEP utilizados por muchas aplicaciones BitTorrent que todavía se encuentran en fase de borrador (Draft) o solo han sido aceptados (Accepted) sin llegar a ser definitivos (Final). Incluso hay otros que, a pesar de no tener siquiera borrador, son utilizados en las aplicaciones BitTorrent más populares. Los objetivos técnicos del proyecto son implementar los siguientes BEP:
BEP3 Núcleo de BitTorrent, en fase definitiva.
BEP5 Implementa distributed hash table (DHT) para aumentar la descentraliza- ción de BitTorrent, en fase de borrador.
1.5. Sobre el proyecto y el formato de la memoria
El desarrollo de la aplicación carece de análisis y especificación de requisitos ya que el protocolo ya está especificado y definido. En esta memoria se explica en detalle el diseño y la implementación. No es objetivo de la memoria expli- car la especificación y el funcionamiento del protocolo, pero se profundizará en él cuando sea necesario para justificar las decisiones de diseño.
El trabajo de este proyecto ha consistido en diseñar e implementar desde cero el protocolo BitTorrent en Pharo-Smalltalk sin usar en absoluto otros trabajos o librerías preexistentes.
Se adjuntará código de la aplicación como recurso explicativo del diseño y la implementación. Si la aplicación se hubiera programada en un lenguaje como C/C++ o Java, se habría descartado hacerlo, pero Smalltalk permite crear lenguajes específicos de dominio (en inglés domain-specific language (DSL)) con una sintaxis tan expresiva que puede leerse casi como si fuera lenguaje natural.
9 Pharo-Smalltalk tiene un entorno gráfico que, junto con la reflexión, permite examinar la estructura interna y el estado de los objetos en tiempo real. Aunque desarrollar una interfaz gráfica de usuario (en inglés graphical user interface (GUI)) no era uno de los objetivos técnicos, es posible usar la aplicación con pocas instrucciones y observar en tiempo real el estado de la aplicación con el entorno gráfico de Pharo-Smalltalk.
2. Contexto
2.1. Redes peer-to-peer
El criterio de clasificación de redes que probablemente las separa en los dos grupos más significativos es quién sirve los recursos disponibles. Estos dos grupos son las redes cliente-servidor y las redes P2P. Schollmeier[13] define las redes cliente- servidor como
Arquitectura de red que consiste en un sistema de alto de rendimiento, el servidor, y varios sistemas habitualmente de menor rendimiento, los clientes. El servidor es el único proveedor de servicios. Los clientes solo consumen servicios sin compartir ninguno de sus recursos.
Y las redes P2P como
Arquitectura de red donde los participantes comparten parte de sus recursos hardware (tiempo de procesador, espacio de almacenamiento, ancho de ban- da, dispositivos. . . ). Estos recursos son necesarios para proveer el servicio que ofrece la red y son accesibles directamente por cualquier participante sin necesidad de otra entidad mediadora. Los participantes de estas redes son tanto proveedores como consumidores de servicios.
10 (a) Arquitectura cliente-servidor (b) Arquitectura peer-to-peer
Figura 2: Comparación entre las arquitecturas cliente-servidor y peer-to-peer
Un concepto íntimamente relacionado con las redes P2P es el de supercapa (en inglés overlay). Una supercapa es una capa de aplicación virtual, o red lógica, que ofrece servicios normalmente no disponibles en la capa física subyacente[14]. Las redes P2P en realidad son supercapas de Internet formadas por las conexiones entre los peers. Las siguientes características se encuentran en la mayoría de redes P2P. Aunque a menudo no se cumplen de forma completa o absoluta. Conectividad Todos los nodos están interconectados. Descentralización El comportamiento de la red P2P está determinado princi- palmente por la acción colectiva de los peers. Simetría Los nodos asumen roles equivalentes. Participación libre Cada peer puede unirse y abandonar la supercapa cuando quiera. Escalabilidad Las supercapa puede llegar a tener millones de nodos debido a que la carga de trabajo se reparte de forma homogénea entre los peers. Estabilidad Las redes P2P toleran situaciones de churn. Churn es el término usado para referirse a la situación donde los peers de la supercapa se unen y abandonan la red con mucha frecuencia. Robustez El funcionamiento de las redes P2P no depende de la existencia de un nodo especial o punto vulnerable.
11 2.1.1. Descubrimiento de recursos
Dentro de las redes P2P existen dos grandes categorías: estructuradas y no es- tructuradas. Lo que las diferencia es cómo los peers descubren los recursos en la supercapa. Las redes P2P no estructuradas se basan en supercapas aleatorias en las que los recursos son descubiertos ha- ciendo backtracking, flooding o usando caminos aleatorios (random walks en inglés)[7]. Backtracking es un algorit- mo que busca todas las soluciones posi- bles (o una parte) de algunos problemas computacionales. Flooding es un algo- ritmo de encaminamiento en el que ca- da nodo reenvía cada paquete recibido por todas sus conexiones menos por la que ha llegado. La figura 3 muestra la típica secuen- cia de mensajes de petición que se da en Freenet. El usuario inicia una peti- ción de información en el peer A, el cual reenvía la petición a B, entonces B la reenvía a C. El peer C no puede reen- viar la petición a ningún peer más y Figura 3: En Freenet, backtracking usado devuelve un error a B. El peer B prue- para encontrar un recurso ba su segunda opción, el peer E, el cual reenvía la petición a F, que reenvía a B. Entonces B detecta el bucle y devuelve un error de petición a F, el cual no es capaz de reenviar la petición a ningún peer más y la petición vuelve atrás, hacia E. Entonces el peer E prueba su segunda opción, el peer D, el cual tiene la información deseada. Finalmente, la información encontrada es devuelta a través de E, B y A. El uso de esta técnica, igual que con flooding y caminos aleatorios, es muy costoso porque las peticiones de contenido poco común tienen que ser reenviadas a un gran número de peers antes de encontrar el recurso deseado. Además, los peers tienen que procesar muchas peticiones de información aunque no tengan el recurso deseado. El uso de este tipo de técnicas hace que la topología de la supercapa sea totalmente aleatoria, sin ninguna forma en particular, de ahí el término «no estructurada». En estas redes, la información popular es fácil de encontrar, pero es proba- ble que un peer no encuentre el recurso que busca si es muy raro. Debido a la
12 falta de estructuración, estas redes son fáciles de construir y resistentes a situacio- nes de churn[14]. Ejemplos de redes no estructuradas son Freenet[2], Gnutella, y FastTrack.
(a) Topología de una red P2P no estructu- (b) Topología de una red P2P estructurada rada (distributed hash table)
Figura 4: Comparación toplógica entre una red P2P no estructurada y una red P2P estructurada
Una red P2P estructurada es una supercapa en la que los peers mantienen la información de encaminamiento y localización de los recursos de forma cooperati- va. Esta estrategia normalmente asegura que los recursos son encontrados en un número de pasos acotado superiormente aunque sean extremadamente raros. La mayoría de este tipo de redes usan DHT. Una DHT consiste en una tabla con registros
13 P2P no estructurado P2P estructurado Construcción de la super- alta flexibilidad baja flexibilidad capa Recursos indexados localmente indexados en una DHT Mensajes de petición backtracking, flooding y número de reenvíos acota- caminos aleatorios do Localización probable garantizada Coste de búsqueda impredecible acotado Coste de mantenimiento bajo moderado de la supercapa Tolerancia a churn y fallos alta moderada Aplicabilidad pequeña escala y redes al- gran escala y redes relati- tamente dinámicas vamente estables
Tabla 1: Comparación entre las características de las redes no estructuradas y las redes estructuradas
2.1.2. Aplicaciones
Las aplicaciones más importantes que se le ha dado a las redes P2P son las si- guientes:
Intercambio de ficheros. Es el uso de P2P más extendido. El protocolo más popular es BitTorrent (http://www.bittorrent.org).
P2PTV. Son aplicaciones diseñadas para retransmitir vídeo en tiempo real sobre redes P2P. El contenido retransmitido normalmente son canales de tele- visión alrededor de todo el mundo. StreamRoot (https://www.streamroot. io) es un ejemplo.
Osiris Serverless Portal System. Es un sistema que permite la publicación y mantenimiento de sitios webs sobre redes P2P. Este tipo de webs son inmunes a los ataques de denegación de servicio (http://www.osiris-sps.org).
Invisible Internet Project (I2P) es una supercapa P2P de Internet que pro- porciona cierto grado de anonimato a sus usuarios (https://geti2p.net).
Sistemas de monedas criptográficas digitales como Bitcoin[10] y Peercoin[6] funcionan sobre redes P2P.
14 2.2. Historia del intercambio de ficheros
La historia del intercambio de ficheros ha pasado por diversas épocas marcadas principalmente por los sistemas que se han utilizado. Aunque el intercambio de ficheros y las redes P2P actualmente son dos conceptos estrechamente relacionados, no siempre ha sido así. A continuación se hace un breve resumen de estas épocas.
Bulletin Board System (década de los 70) El Bulletin Board System (BBS) es considerado en gran parte el inicio del intercambio de ficheros digitales tal y como lo conocemos hoy en día. BBS es un servidor que permite a usuarios conectarse al sistema usando un terminal. Una vez dentro del sistema, el usuario puede realizar una serie de operaciones como subir y descargar software y ficheros, leer noticias y boletines, e intercambiar mensajes con otros usuarios vía correo electrónico y chat. Hoy en día todavía existen algunos BBS en funcionamiento.
Figura 5: AmiExpress (1992). Aplicación BBS para Commodore Amiga
Warez scene (década de los 70) Warez scene es una comunidad clandestina y oculta al gran público, especializada en la distribución de material con derechos de autor, incluyendo programas y series de televisión, películas, música, videoclips, videojuegos, aplicaciones, ebooks y pornografía. Empezó a emerger en la década de los 70. Inicialmente usaban BBS privados para publicar su material, pero pos- teriormente pasaron a usar los topsites, servidores File Transfer Protocol (FTP) clandestinos, altamente secretos y con gran ancho de banda capaces de transferir un Blu-ray en cuestión de segundos y almacenar terabytes de información. En esta comunidad primero los release groups publican cierto contenido multi- media en un topsite y lo anuncian a través de Internet Relay Chat (IRC). Una vez el material ha sido publicado, los courier groups, que tienen acceso a los topsites transportan las publicaciones de un topsite a otro topsite, normalmente usando FlashXP. Con esta operación, los courier groups obtienen el derecho a descargar
15 tres veces lo que han subido, siempre y cuando el contenido sea original. De esta forma, los courier groups compiten por ser los primeros en transportar las publi- caciones entre topsites. Gracias a la naturaleza descentralizada de este sistema, el sistema de recompensas y la posibilidad de partir los ficheros en trozos mediante RAR, las publicaciones rápidamente están disponibles para toda la comunidad de warez scene. Sin embargo, debido al alto hermetismo de este tipo de distribución, es difícil para muchos usuarios conse- guir acceso a los topsites. Hoy en día siguen existiendo algunos.
Usenet: los orígenes de la descentralización (fi- nales de los 70) Usenet es un sistema mundial distri- buido de debate y discusión. Sus usuarios pueden leer y enviar mensajes (llamados articles o posts, y colectiva- mente llamados news) según categorías, conocidas como newsgroups. Los servidores redistribuyen los mensajes a otros servidores creando múltiples copias. Usenet es el precursor de los foros web que son ampliamente usados en la actualidad y puede ser visto como un híbrido entre gestor de correo electrónico y foro web. La mayor dife- rencia entre BBS y Usenet es la ausencia de un servidor o administrador central. Aunque Usenet ha existido desde finales de los 70, la práctica de intercambio de ficheros no se extendió hasta mucho más tarde. En 1993, Eugene Roshal creó la tecnología RAR, la cual permitía a los usuarios partir Figura 6: Jerarquía de los ficheros en trozos y posteriormente reconstruirlos. warez scene Gracias a la naturaleza descentralizada de Usenet y a RAR, la velocidad y la eficiencia de la distribución de ficheros aumentó muchísimo permitiendo no tener que redistribuirlos íntegramente en caso de errores. Usenet aún se usa en la actualidad. Sin embargo, se usa mayoritariamente para el intercambio de ficheros antes que para su propósito original, el cual ha sido desplazado por los foros web y IRC.
IRC (1988) IRC fué creado por Jarkko Oikarinen en agosto de 1988 para re- emplazar un programa de un BBS cuyo propósito original era la mensajería ins- tantánea, pero durante la década de los 90 se popularizó su uso como medio de intercambio de ficheros. Hoy en día, IRC todavía es ampliamente usado para su propósito original de chat. También se usa como mecanismo de impulso o punto
16 de arranque para algunos sistemas de intercambio de ficheros.
Hotline (1997) Durante un periodo breve de tiempo Hotline fué un medio de intercambio de ficheros muy popu- lar que usaba una arquitectura cliente- servidor. Al principio, Hotline tuvo mu- cho éxito, sin embargo su uso rápida- mente perdió fuerza debido a varias complicaciones, entre ellas el cifrado del código fuente por parte del funda- dor, Adam Hinkley, antes de abando- nar la compañía. Hacia finales de los 90, Hotline empezó a desvanecerse, coinci- diendo con la aparición de otros siste- mas emergentes. Hoy en día, su uso es casi inexistente.
Napster (1999) Naspter llevó el Figura 7: Una red Usenet con servido- intercambio de ficheros, en concreto res y clientes. Los puntos azules, verdes MP3, a las grandes masas. Existía un y rojos de los servidores representan los servidor central que los usuarios con- grupos que gestionan. Las flechas entre sultaban para encontrar los peers que servidores indican intercambios de infor- tenían el fichero MP3 que querían. En- feeds mación entre grupos de discusión ( ). tonces los peers se ponían en contacto Las flechas entre clientes y servidores in- e intercambiaban el fichero íntegramen- dican que un usuario está suscrito a un te. El sistema era P2P, aunque también grupo. tenía una parte centralizada ya que de- pendía del servidor donde se encontra- ba la base datos que controlaba qué canciones tenía cada peer. En el año 2000 la compañía discográfica estadounidense A&M Records y otras compañías demandaron a Napster a través de la Recording Industry Association of America (RIAA) por vulnerar derechos de autor protegidos por la Digital Mi- llennium Copyright Act (DMCA). El tribunal encargado del caso sentenció que Napster era culpable y fue obligado a restringir el acceso a todo el material pre- sente en su red que vulnerase esos derechos, pero no fue capaz y tuvo que detener el servicio en julio de 2001. Al año siguiente, en 2002, Napster entró en bancarrota y fue vendida a otra compañía.
17 Diversificación de los sistemas P2P (a principios del 2000) Durante el litigio entre Napster y la RIAA en el año 2000, aparecieron los sistemas eDon- key2000, Gnutella y Freenet. eDonkey2000 podía intercambiar ficheros de gran tamaño, pero también de- pendía de un servidor central como Napster. Este sistema fue el primero en aplicar el concepto de swarming, que permitía descargar trozos del fichero de distintos peers simultáneamente para acelerar la descarga. Gnutella era un sistema que no necesitaba ningún servidor central, por lo que no tenía un punto vulnerable y era más difícil detener sus servicios. Freenet también carecía de servidor central, pe- ro además ofrecía un mayor grado de anonimato a sus usuarios que los sistemas anteriores. En 2001, se publicó el protocolo FastTrack cuya implementación más popu- lar fue Kazaa. Este protocolo no era totalmente descentralizado como Gnutella y Freenet, ya que existían unos supernodos cuya función era aumentar la eficiencia de la red. El cierre de Napster en 2001 propició que muchos de sus usuarios se pasaran a otros sistemas P2P y el uso de este tipo de redes siguió creciendo. Audiogalaxy (1998) creció en popularidad, y el protocolo BitTorrent y la aplicación LimeWire (Gnutella) fueron publicados. En 2002, la RIAA demandó a Audiogalaxy y consi- guió detener sus servicios. Hasta su decadencia en 2004, Kazaa fue la aplicación de intercambio de ficheros más popular a pesar de sus litigios en los Países Bajos, Australia y los Estados Unidos. Debido a la dificultad de acabar con los sistemas P2P descentralizados, en 2002, la RIAA comenzó a demandar a los usuarios de Kazaa gracias a que los Internet service provider (ISP) o proveedores de servicio a Internet facilitaban su identidad y se produjeron las primeras multas a usuarios. Durante 2002 y 2003 se crearon múltiples servicios web que permitían a los usuarios de BitTorrent introducirse en sus redes, incluyendo Suprnova.org, isoHunt, TorrentSpy y The Pirate Bay. Este último sufrió redadas en 2006 y 2014. En 2005, la compañia desarrolladora de eDonkey2000, MetaMachine, fue obli- gada a dejar de ofrecer su software como resultado de una demanda impuesta por la RIAA. Ese mismo año, la aplicación BitTorrent Azureus (ahora conocida como Vuze) fue la primera en implementar DHT dentro de la comunidad BitTorrent, he- cho que le dió mucha popularidad a este tipo de redes ayudando a que se acabaran convirtiendo en las redes P2P más usadas a nivel mundial.
Sistemas de alojamiento de archivos (principios y mediados de los 2000) Paralelamente a la difusión de los sistemas P2P, algunos sistemas de alojamiento de archivos se hicieron muy populares, como Megaupload, Rapidshare y Hotfile (entre otros). La gran ventaja de estos sistemas era su gran facilidad de uso.
18 Los usuarios solo tenían que subir archivos a un servidor y compartir la Uniform Resource Locator (URL) con otros usuarios para que los descargaran mediante Hypertext Transfer Protocol (HTTP). Normalmente, las URL eran compartidas en foros de Internet. Era práctica común premiar a aquellos usuarios cuyos enlaces eran más veces descargados, así que era habitual partir los ficheros en trozos como en la época de los topsites y Usenet, solo que en este caso por motivos estrictamente de provecho. Estos sistemas también fueron objetivo de gobiernos y otras organizaciones como RIAA y Motion Picture Association of America (MPAA). El caso más famoso fue el cierre de Megaupload y arresto de su fundador Kim Dotcom el 19 de enero de 2012. Justo un año después, el 19 de enero de 2013, Kim Dotcom lanzó un nuevo servicio de alojamiento de archivos llamado Mega.
2.3. BitTorrent 2.3.1. Funcionamiento
BitTorrent es un protocolo P2P diseña- do para el intercambio de ficheros (nor- malmente de gran tamaño). BitTorrent crea una supercapa no estructurada so- bre Internet. Usa la técnica de swar- ming como ya hacía la red eDonkey, es decir, parte la información que se quiere compartir en piezas pequeñas (256 KiB - 4 MiB) de igual tamaño y los peers de la red descargan y suben estas partes simultáneamente de y hacia múltiples peers acelerando enormemente la des- carga. A diferencia de los sistemas de intercambio de ficheros anteriores, Bit- Torrent no crea una red única donde se comparten todos los ficheros en el mun- do, sino que crea una red separada por cada contenido o recurso distinto (estos recursos únicamente identificables reci- Figura 8: Funcionamiento de una red Bit- ben el nombre de torrents). Torrent que comparte un torrent de 5 pie- En una red BitTorrent participan zas. En la red participan 4 peers (tres lee- dos tipos de nodos: los peers y el trac- chers y un seeder) y un tracker. En verde, ker. Los peers son los encargados de las piezas que tiene cada peer. distribuir las piezas por la red, y el trac-
19 ker simplemente registra y coordina a los peers participantes. El conjunto de todos los peers de una red se llama en- jambre o swarm. Los peers normalmente son clasificados como seeders o leechers. Los primeros son peers que tienen todas las piezas del torrent, mientras que los segundos son peers que aún les faltan piezas por descargar. Esta distinción es solo teórica ya que a efectos prácticos todos los peers de la red tienen el mismo rol y capacidades. Los peers solo se comunican con el tracker cuando quieren unirse a la red o quieren pedir más peers con los que intercambiar piezas. Cuando un peer quiere unirse a una red BitTorrent, lo primero que hace es descargar un fichero .torrent. Este fi- chero contiene los metadatos esenciales para el funcionamiento de la red. Ade- más, estos metadatos identifican de for- ma única al torrent. Entre otras cosas, contienen la dirección URL del tracker, la colección de ficheros que forman el torrent, el tamaño de las piezas y el resumen de cada una de ellas, nece- sario para verificar su integridad. Una vez el peer tiene el fichero .torrent, co- necta con el tracker mediante HTTP para «anunciarse», es decir, para que el tracker sepa que hay un nuevo peer que quiere participar en la red. Acto seguido, el tracker devuelve una lista con la información de contacto de otros Figura 9: Perspectiva del peer local en el peers (dirección Internet Protocol (IP) enjambre. y puerto) para que pueda conectarse con ellos e intercambiar piezas. Estos ficheros .torrent normalmente se encuentran en páginas web que actúan como di- rectorios de torrents. En la figura 8 se puede ver un ejemplo de cómo funciona el swarming en BitTorrent. El peer B, que solo tiene las piezas 1 y 4, descarga la pieza 3 del peer C. Éste último, al mismo tiempo está descargando las piezas 2 y 4 de los peers D y A, respectivamente. Por último, el peer D descarga las piezas 1 y 3 de B y A, respectivamente. Es importante recalcar que un peer cualquiera normalmente no conoce a todos los peers del enjambre, ya que suelen ser más que el número de conexiones simul- táneas que el sistema del peer local puede soportar. Pero técnicamente hablando, es posible que un peer pida al tracker todos los peers del enjambre. Otra cuestión
20 es que sea capaz de abrir una conexión con cada uno de ellos simultáneamente. Y si es capaz, que el ancho de banda de su conexión a Internet permita recibir paquetes de información de todas las conexiones a la vez. Los enjambres pueden llegar a ser realmente grandes. Por ejemplo, el enjambre más grande en la historia de BitTorrent se dio en 2014 con 193.000 peers. La figura 8 es útil para tener una visión global del funcionamiento de BitTo- rrent, pero no se corresponde con la perspectiva de un peer cualquiera. Lo que ve el peer local en realidad es una red como la de la figura 9 donde solo conoce a una parte del enjambre. Dicho de otra forma, cada peer conoce un grupo particular de vecinos. Estos vecinos pueden coincidir con los de otros peer, pero en principio es por pura casualidad.
2.3.2. Implementaciones existentes y últimos avances
A lo largo de todos los años que diferentes aplicaciones BitTorrent han estado en funcionamiento, la comunidad BitTorrent ha propuesto nuevos BEP que amplían las funcionalidades del protocolo. Algunas propuestas han sido tan bien valoradas por la comunidad que se han convertido en práctica de facto, incluso teniendo solamente estatus de borrador o aceptadas, sin llegar a ser definitivas (ver figura 1). Estos son los avances tecnológicos más significativos hasta la fecha. uTorrent Transport Protocol (uTP) (BEP29) Es un protocolo implementa- do sobre User Datagram Protocol (UDP) y diseñado para sustituir a Trans- mission Control Protocol (TCP) y así evitar sus problemas inherentes de congestión y al mismo tiempo mantener la fiabilidad y el orden de la infor- mación.
Magnet Uniform Resource Identifier (URI) (BEP9) El esquema Magnet URI permite a los peers unirse a la red sin descargar el fichero .torrent.
DHT (BEP5) Con las DHT los peers son capaces de localizar los recursos de la red sin consultar al tracker.
Peer Exchange (PEX) A pesar de que su uso es extendido, no existe propuesta oficial. Permite que un peer conozca otros peers a través de sus vecinos. Sigue siendo necesario consultar inicialmente al tracker para unirse a la red.
Web seeding (BEP17, BEP19) Permite a los peers descargar el fichero de un servidor HTTP/FTP (además de la opción P2P).
Tracker UDP Permite realizar la comunicación entre los peers y el tracker sobre UDP. Disminuye hasta un 50 % el tráfico entre los peers y el tracker.
21 Descubrimiento de peers locales No existe propuesta oficial. Es una forma de descubrir otros peers que se encuentran en la local area network (LAN) o red de área local del peer aprovechando su gran ancho de banda y al mismo tiempo minimizando el tráfico que sale hacia Internet.
Super-seeding (BEP16) Es una técnica que ayuda a los leechers a que se con- viertan en seeders más rápidamente. Es útil cuando solo hay un seeder en la red.
Multitracker (BEP12) Permite el uso de múltiples trackers coordinados (y de repuesto, en caso de que uno falle).
Actualmente existen dos librerías que son usadas por aplicaciones BitTorrent:
libtorrent es una librería multiplataforma de código abierto escrita en C++. Su primera publicación fue en 2005. Las características implementadas más notables son DHT, uTP, Web seeding y PEX. Algunas aplicaciones imple- mentadas con esta librería son Deluge, Tribler, qBittorrent, Free Download Manager, BitLord, rTorrent y el videojuego World of Tanks.
MonoTorrent es otra librería multiplataforma de código abierto escrita en C# basada en Mono (una implementación de .NET Framework). Su primera publicación fue en 2010. Moonson es un aplicación basada en esta librería.
Además, también existen otras aplicaciones con sus propias implementaciones como BitTorrent(Mainline) (C++), uTorrent (C++), Vuze (Java), Transmission (C, Objective-C), WebTorrent (JavaScript, WebRTC), Shareaza (C++), Tixati (C++), BitComet (C++) y MLDonkey (OCaml, C y ensamblador). Actualmente no existe ninguna implementación BitTorrent en Pharo de la que se pueda aprovechar su código para el proyecto. Pero sí que pueden ser útiles otras implementaciones como las mencionadas arriba a la hora de tener referencias sólidas y fiables sobre cómo diseñar la aplicación.
3. Metodología
3.1. Seguimiento
En el desarrollo del software se usará una metodología incremental, de abajo arriba, partiendo de los sistemas más pequeños e independientes, creando otros sistemas más grandes y complejos en forma de prototipos. Se iterará este ciclo hasta pro- ducir el prototipo final. Como mínimo, se celebrará una reunión con el director del proyecto tras la finalización de cada prototipo para evaluar el estado de la
22 aplicación. El director del proyecto también podrá supervisar en todo momento el estado del software a través de http://smalltalkhub.com, un repositorio online para proyectos Smalltalk, donde se irán actualizando las diferentes versiones de la aplicación.
3.2. Estilo de programación
En el desarrollo del software se seguirán los patrones de diseño del libro Smalltalk Best Practice Patterns[5]. Además se hará énfasis en producir código que cumpla los siguientes principios generales de programación, que son especialmente útiles para este proyecto.
Minimalismo Dividir las funcionalidades lo máximo posible para tener métodos pequeños y altamente reusables.
Código autocomentado Elegir el nombre de las clases, métodos y variables de tal forma que el código sea fácilmente comprensible sin necesidad de comen- tarios explícitos.
3.3. Validación del software
El software será validado mediante pruebas unitarias. Estas pruebas unitarias serán automatizadas para que las pueda reproducir cualquier usuario fácilmente. Además se incluirán otras pruebas sobre el funcionamiento general de la aplicación. Las instrucciones para ejecutar estas pruebas se encuentran en el apartado A.4 de la adenda.
4. Visión global de la aplicación
En este apartado se hace un resumen en alto nivel del diseño y el funcionamiento de la aplicación con el objetivo de dar una visión global introductoria. El método a utilizar en la explicación va a ser empezar por la clase que representa el sistema más grande, es decir, la que representa la aplicación en sí, y a continuación explicar superficialmente los subsistemas que contiene. La clase principal es BtLocalPeer, que representa la aplicación BitTorrent que ejecuta el peer local. Puede parecer de entrada que el nombre escogido no es el apropiado para representar la aplicación, pero como se explica en los objetivos generales del proyecto, lo que se persigue es representar virtualmente, dentro de Smalltalk, la naturaleza de las redes BitTorrent. Y esta naturaleza se basa en objetos (peers) que interaccionan entre sí a través de mensajes, por lo que se ha
23 decidido llevar también este enfoque a una elección de nombres que ayude a ver estas redes como objetos con entidad propia que se comunican. Como se pretende que solo pueda existir una sola aplicación al mismo tiempo, esta clase es de instancia única. Esta clase contiene una colección de objetos BtTorrent. Un objeto BtTorrent representa la tarea de descarga y compartición de un torrent cualquiera. La razón para que BtLocalPeer contenga una colección de torrents es poder realizar ope- raciones globales sobre todos los torrents, como iniciarlos y detenerlos todos a la vez, o imponer un límite global de conexiones simultáneas en la aplicación.
Figura 10: Diagrama de clases simplificado de la aplicación
El primero de los elementos que contiene BtTorrent es un objeto BtMetainfo, que representa los metadatos contenidos en el fichero .torrent, sin el cual no es posible unirse a la red e intercambiar piezas con otros peers. El siguiente objeto que contiene es una colección de objetos BtFile. Cada torrent está compuesto por una serie de ficheros cuyas rutas y tamaños aparecen en los metadatos. De hecho, el torrent es considerado como un único fichero, resultado de la concatenación de los ficheros mencionados en el orden en que aparecen en los metadatos. Esta colección de objetos BtFile lo que permite es acceder a las piezas de este gran fichero de forma totalmente independiente a los ficheros que lo componen, sin importar cuantos ficheros haya implicados. Durante la compartición del torrent también es necesario llevar un control de las piezas que tiene cada peer del vecindario (tanto del local como de los remotos). Esta funcionalidad es necesaria porque, de no llevar este control, el peer local no
24 sabría qué piezas pedir a otros peers. De esto se encarga la clase BtBitfield, que es un campo de bits tan grande como piezas haya en el torrent. Cada objeto BtTorrent contiene una instancia de esta clase ya que cada torrent es un conjunto de ficheros distinto. Este tipo de objetos también los contienen las instancias de la clase BtRemotePeer, que representa los peers remotos del vecindario, para los que también es necesario llevar un control de las piezas que tienen. Los objetos BtRemotePeer representan las conexiones del peer local con los peers remotos. Se podría haber elegido como nombre para estos objetos «BtConnection» o algo similar, pero, como en el caso de BtLocalPeer, se ha elegido el nombre que denota la naturaleza de objetos con los que se puede interaccionar. Cada BtTorrent tiene su propia colección de peers remotos (o conexiones). Otro tipo de objetos con los que interacciona el peer local son los trackers, representados por la clase BtTracker. Por cada torrent, siempre existe como mí- nimo un tracker que se encarga de introducir y dar a conocer los peers dentro del enjambre dedicado a un torrent concreto. Así que cada BtTorrent contiene un BtTracker como mínimo (también existe el concepto de multitracker, ver apartado 5.5.3). La unidad mínima de información útil del torrent no es la pieza, sino el bloque. Cuando los peers intercambian información útil (octetos del torrent), no intercam- bian piezas íntegras, sino que intercambian pequeñas porciones de estas piezas: bloques. Para no tener que estar accediendo constantemente al disco físico, estos bloques se guardan temporalmente en la memoria volátil del sistema. Una vez se dispone de todos los bloques de una pieza, entonces se valida calculando su resu- men y se escribe en disco, y se libera la memoria volátil. Cada BtTorrent tiene una colección de objetos BtTemporaryPiece, donde se guardan los bloques temporales. Por último, los objetos BtTorrent también contienen una instancia de BtPiecesOnNetwork. La responsabilidad de esta clase es llevar un control de la «distribución» de las piezas en el vecindario. Dicho de otra forma, por cada pieza, cuántas copias hay en el vecindario. Además, también ofrece la posibilidad de or- denar las piezas según varios criterios. La necesidad y utilidad de este sistema se explica en el apartado 5.12. En el siguiente apartado se profundiza en el funcionamiento de la aplicación siguiendo el sentido inverso al que se ha usado en este apartado. Empezando por los subsistemas más pequeños e independientes, y terminando por los sistemas más complejos y dependientes hasta llegar a la aplicación en sí. Esta metodología es, precisamente, la que se ha utilizado en el desarrollo de la aplicación (de abajo arriba), y también es la más idónea para explicarla con un gran grado de detalle.
25 5. Diseño e implementación
En este apartado se explica el diseño e implementación de la aplicación BitTorrent. Aunque el objetivo no es explicar en detalle el protocolo, sí que será necesario pro- fundizar un poco en su funcionamiento en algunas partes para que se comprendan determinadas decisiones de diseño.
5.1. Bencoding
Los metadatos del fichero .torrent vienen codificados en un sistema de codificación especial diseñado para BitTorrent que se llama bencoding. Los tipos de datos que soporta son cadenas de caracteres, enteros, listas y diccionarios.
Las cadenas de caracteres se codifican en secuencias de octetos de la forma
Los enteros se codifican en secuencias de octetos de la forma i
Las listas se codifican en secuencias de octetos de la forma l
Los diccionarios se codifican en secuencias de octetos de la forma d
Como es necesario que la aplicación pueda leer y escribir estos metadatos, tiene que implementar dos operaciones: codificar los tipos de datos en una secuencia de octetos y decodificar una secuencia de octetos en los tipos de datos que correspon- da. Los métodos encargados de llevar a cabo estas operaciones se han añadi- do a las clases estándar String, Integer, OrderedCollection, Dictionary, ByteArray y PositionableStream. Para codificar, las clases String, Integer, OrderedCollection y Dictionary tienen el método bencoded que codifica las instancias de esas clases en secuencias de octetos. En el siguiente ejemplo las se- cuencias de octetos resultantes se convierten a cadenas de caracteres (asString) para que los resultados sean legibles.
26 ’hello world’ bencoded asString. −>’11:hello world’ 3567 bencoded asString. −>’i3567e’ (OrderedCollection with: 3567 with:’hello world’) bencoded asString. −>’li3567e11:hello worlde’ d:=Dictionary new. d at:’key1’ put:’value1’. d bencoded asString. −>’d4:key16:value1e’ Del mismo modo, la clase ByteArray tiene un método con el nombre bedecoded que implementa la función inversa. ’hello world’ bencoded bedecoded. −>’hello world’ 3567 bencoded bedecoded. −> 3567 (OrderedCollection with: 3567 with:’hello world’) bencoded bedecoded. −> an OrderedCollection(3567’hello world’) d:=Dictionary new. d at:’key1’ put:’value1’. d bencoded bedecoded. −> a Dictionary(’key1’−>’value1’)
La clase ByteArray (como todas las subclases de Collection) tiene un incove- niente: si queremos decodificar varios datos seguidos necesitamos devolver, a parte del dato decodificado, la posición del array donde termina éste para decodificar el dato siguiente a partir de la siguiente posición. Inicialmente, la decodificación la hacía ByteArray pero posteriormente se trasladó esta funcionalidad a la clase PositionableStream (subclase de Stream) para evitar este inconveniente. Las ins- tancias de Stream son wrappers de colecciones que permiten leer los elementos de la colección subyacente al mismo tiempo que avanza la posición de lectura hasta el elemento posterior al último leído. Por tanto, el método ByteArray>>bedecoded2 simplemente invoca al método PositionableStream>>bedecoded. ByteArray>>bedecoded ^self readStream bedecoded Entonces PositionableStream se encarga de decodificar el tipo de dato que corresponda: 2Clase>>metodo es la forma de Pharo para referirse al método metodo de la clase Clase.
27 PositionableStream>>bedecoded elem := self peek asCharacter. ^ elem = $i ifTrue: [ self bedecodeInteger ] ifFalse: [ elem isDigit ifTrue: [ self bedecodeString ] ifFalse: [ elem = $l ifTrue: [ self bedecodeList ] ifFalse: [ elem = $d ifTrue: [ self bedecodeDictionary ] ifFalse: [ self error:’Unknown bencoded form’]]]]
5.2. Los metadatos
Los metadatos, como ya se ha explicado en el apartado 2.3.1, contienen la in- formación esencial para el funcionamiento de la red BitTorrent. En realidad, los metadatos son un diccionario «bencodificado» que contiene las siguientes claves: announce Cadena de caracteres codificada que representa la URL del tracker info Diccionario codificado que contiene las claves descritas abajo
El diccionario info contiene las siguientes claves: name Cadena de caracteres que representa el nombre sugerido para el fichero o directorio compartido. piece length Entero que especifica el tamaño en octetos de las piezas en que es partido el torrent. La última pieza puede tener un tamaño diferente. pieces Concatenación de los resúmenes (o funciones hash) de las piezas.
También hay otra clave dentro de info que puede ser length o files. Es length cuando el torrent es un solo fichero y su valor es un entero que representa el tamaño del fichero en octetos. Es files cuando el torrent es una colección de ficheros y su valor es una lista de diccionarios que contienen las siguientes claves: length Entero que representa el tamaño del fichero path Una lista de cadenas de caracteres que representa la ruta del fichero, empe- zando por el directorio más alto y acabando con el nombre del fichero
28 Cuando el torrent es una colección de ficheros, se trata como un solo fichero resultado de la concatenación de todos los ficheros en el orden en que aparecen en files. Cada torrent es identificado de forma única en Internet con el resumen del diccionario info. La clase BtMetainfo, subclase de Dictionary, representa los metadatos. Los metadatos de un torrent son nombrados en la documentación del protocolo co- mo «metainfo», por eso se ha elegido este nombre y de ahora en adelante nos referiremos a los metadatos así. Respecto a la metainfo, solo hay dos situaciones posibles en una red BitTorrent: o bien que el creador de ésta sea el usuario de la aplicación porque quiere compartir unos ficheros de su sistema; o bien que el usuario quiera descargar unos ficheros cuya metainfo ha sido creada por otro usuario de la red. En el primer caso, la forma de generar la metainfo asociada a un fichero o directorio de ficheros del sistema es la siguiente. metainfo:= BtMetainfo new. metainfo buildOn:’/myFiles/directoryToShare’ asFileReference . metainfo writeToFile:’/myFiles/myMetainfo.torrent’ asFileReference. En cambio, en el segundo caso solo querremos leer el fichero .torrent y decodi- ficar el diccionario que recibe BtMetainfo>>from: como argumento. metainfoFile:=’/myFiles/someMetainfo.torrent’ asFileReference . metainfo:= BtMetainfo from: (metainfoFile readStreamDo:[:x | x binary ; bedecoded]).
5.3. Acceso físico a los torrents
Los ficheros de un torrent vienen definidos en la metainfo, en ella aparecen sus rutas y el tamaño que cada uno debe tener al finalizar la descarga. Las rutas de los ficheros obviamente son relativas, ya que la ruta absoluta dependerá del sistema de ficheros donde se almacenen. Una aplicación BitTorrent debe tener un sistema de acceso físico a estos ficheros tanto para escribirlos en disco como para leerlos, ya que el peer local envía y recibe piezas a otros peers. El protocolo especifica que los ficheros que componen un torrent deben tratarse como un sólo fichero resultado de la concatenación de todos ellos en el orden en que aparecen en la metainfo. Así que es posible que un fichero empiece en una pieza determinada y termine en otra que se encuentra 4 piezas más allá, como pasa en el segundo fichero de la figura 11. Aunque también es posible que empiece y termine en la misma pieza si el fichero es lo suficiente pequeño. Por tanto, el sistema de acceso físico debe ser capaz de acceder a cualquier porción contigua de la información sin importar cuantos ficheros haya implicados. Este sistema se ha implementado en el paquete BitTalk-DataAccess y está compuesto por las clases
29 BtFile y BtFileCollection.
Figura 11: Ejemplo de colección de ficheros de un torrent de 10 piezas y 4 ficheros. Las piezas tienen un tamaño de 512 KiB menos la última, de 264 KiB.
La clase FileReference es una clase estándar de Pharo que sirve para re- presentar rutas de ficheros. Esta clase dispone del método size que devuelve el tamaño del fichero en cada momento, pero en una descarga BitTorrent además es necesario saber su tamaño final esperado para saber en qué posición de la colección de ficheros hay que leer y escribir cada pieza. Por eso, la clase BtFile representa las instancias de ficheros que se espera que acaben teniendo un tamaño máximo. Esta clase contiene dos variables de instancia: reference (apunta a un objeto FileReference) y finalSize (apunta a un entero). La primera guarda la ruta y la segunda el tamaño máximo permitido. Este tipo de objetos son precisamente los que se especifican en la metainfo, puesto que inicialmente estarán vacíos y al finalizar la descarga habrán alcanzado el tamaño definido en la metainfo. La clase BtFileCollection (subclase de OrderedCollection) representa las instancias de colecciones ordenadas de ficheros, que es precisamente lo que son los ficheros especificados en la metainfo. Las instancias de esta clase tratan sus elementos como si fueran un solo fichero. Con los métodos readOffset:amount: y writeOffset:data: es posible escribir y leer cualquier porción de la concatenación de ficheros dado un offset y, o bien una cantidad de octetos solicitada en caso de lectura, o bien un ByteArray en caso de escritura. Estos métodos de acceso se encargan de abrir y cerrar solamente aquellos ficheros que hay que acceder para leer o escribir la secuencia de octetos solicitada. Esta clase también dispone del método allSha1SplitEvery: cuyo paráme- tro es un entero que define cada cuántos octetos de información se calcula- rá el resumen de la colección de ficheros. Por ejemplo, este método lo utiliza BtMetainfo>>buildOn:pieceLength: para calcular los resúmenes de las piezas resultantes de un directorio de ficheros a partir del cual quiere construirse su me- tainfo. Hay que destacar que las clases BtFile y BtFileCollection no solo sirven para el protocolo BitTorrent, sino que pueden usarse para cualquier concatenación de ficheros que deba tratarse como una sola secuencia de octetos, por lo que la clase BtFileCollection podría ampliarse para que pudiera realizar otras operaciones que satisficieran otras necesidades a parte de las de BitTorrent.
30 5.4. Los nodos de la red
Todos los nodos implicados en una red BitTorrent tienen en común que tienen un dominio (ya sea nombre o dirección IP) y un puerto. La clase encargada de representar a cualquier nodo de la red es BtNode y tiene como variables de instancia un BtDomain y un puerto. Pero no todos los nodos son iguales, existen peers y trackers. Ambos tipos comparten las características de BtNode pero cada uno tiene sus particularidades. Estas particularidades las representan las clases BtPeer y BtTracker, ambas subclases de BtNode. La clase BtPeer tiene dos subclases: BtLocalPeer y BtRemotePeer. El peer local es una instancia de BtLocalPeer. Los peers remotos que el local puede llegar a conocer y conectar con ellos son instancias de BtRemotePeer. Esta clasificación es necesaria porque la instancia (única) de BtLocalPeer representa a la aplicación BitTorrent del sistema local, y las instancias de BtRemotePeer representan las conexiones que tiene el peer local con los peers remotos. Se podría haber llamado a la primera clase «BtApplication» y a la segunda «BtPeerConnection» (o algo similar), pero la intención es respetar el «espíritu» de la orientación a objetos y elegir los nombres que ayuden a ver de forma clara que dentro de Smalltalk hay una serie de objetos interpretando el papel de los nodos de la red y que interaccionan entre sí. La clase BtTracker también tiene dos subclases: BtHTTPTracker y BtUDPTracker. Esta clasificación es necesaria ya que no todos los trackers fun- cionan de la misma forma, unos trabajan sobre HTTP y otros sobre UDP. Las instancias de BtHTTPTracker reciben consultas HTTP mientras que con las ins- tancias de BtUDPTracker la interacción es radicalmente distinta. Todas estas dife- rencias son transparentes para el peer local ya que la forma de comunicarse con los trackers es invocando los métodos abstractos announce y scrape de BtTracker. Estos métodos realizan unas operaciones que son comunes de todos los trackers, independientemente del protocolo que usen. Este diseño nos permite crear una red BitTorrent virtual dentro Smalltalk que representa en tiempo real la red física conocida por el peer local. En esta red virtual los nodos de la red física se representan como objetos de Smalltalk capaces de interaccionar entre sí. Y todos los mensajes que viajan entre ellos se traducen en el envío de mensajes entre objetos dentro de Smalltalk.
5.5. Descubrimiento de peers 5.5.1. Tracker HTTP
La forma principal de interacción entre los peers y el tracker viene definida en el BEP3. Esa parte del protocolo especifica que esta comunicación debe efectuarse
31 Figura 12: Jerarquía de clases de los nodos de la red. mediante consultas HTTP GET. Y detalla qué deben contener estas consultas y que información debe responder el tracker. Todas las clases implicadas directamen- te en este protocolo se encuentran en el paquete BitTalk-HTTPTrackerProtocol. Existen dos tipos de operaciones: announce y scrape. El significado de la ope- ración announce es que el peer local comunica al tracker que quiere conocer cierta cantidad de peers remotos. Además, el peer local también puede querer informar de que se ha producido un evento concreto como la finalización de la descarga o el abandono de la red. Por tanto, existen dos tipos de información en esta operación: la petición del peer local y la respuesta del tracker. La petición es una consulta GET en la que se especifica una query string con una serie de campos y valores que le dan al tracker cierta información sobre el peer que realiza la consulta. En la query string aparecen, entre otros valores, el info_hash (el resumen del diccionario info que identifica al torrent), el puerto que usa el peer local para el tráfico BitTorrent, el número de peers remotos que desea y los octetos que le quedan por descargar hasta completar el torrent. En la siguiente URL aparece en negrita una posible query string: http://tracker.com/announce?port=60513&numwant=50&info_hash=. . .
La clase que representa estos campos y valores es BtHTTPAnnounceQuery y sus variables de instancia son cada uno de los campos que deben o pueden rellenarse en una query string. El método asString convierte la instancia en una cadena de caracteres con la misma forma que la del ejemplo de arriba en negrita. La información relevante de la respuesta HTTP se encuentra en el cuerpo del mensaje (tras la línea en blanco) y es un diccionario «bencodificado». En la clave peers de este diccionario se encuentra una lista de diccionarios cuyas claves son
32 peer id, ip y port. Pero esta forma de expresar peers se ha quedado obsoleta de facto, puesto que se suele usar por defecto otra forma más compacta para ex- presarlos (BEP23). Esta mejora consiste en sustituir el diccionario de peers por una concatenación de grupos de 6 octetos, donde los 4 primeros octetos expre- san la dirección IP y los 2 últimos el puerto. Así, el peer local puede intentar conectar con los peers con esas direcciones. Como esta información es un dic- cionario, puede representarse con un Dictionary, en concreto con la subclase BtHTTPAnnounceResponseBody. Todas las instancias de BtTracker tienen una variable para guardar una pe- tición de announce (announceRequest) y otra para guardar una respuesta de announce (announceResponse). La clase BtTracker tiene el método abstracto announce implementado por su subclase BtHTTPTracker:
1 BtHTTPTracker>>announce 2 httpGET := self newGET: path query: announceRequest asString . 3 response:= self sendGET: httpGET . 4 self updateAnnounceResponse: response. En el código de arriba se pueden ver todos los pasos de la operación announce. En la línea 2 se forma el mensaje GET a partir de la query string. En la línea 3 el método sendGET: envía la petición y devuelve la respuesta del tracker. Y en la línea 4 el método updateAnnounceResponse: recupera el diccionario «bencodificado» del cuerpo de la respuesta, lo decodifica para obtener un BtAnnounceResponseBody y lo guarda en la variable de instancia announceResponse. La operación scrape, sin embargo, tiene un significado distinto. En este caso el peer local no quiere darse a conocer ni conocer otros peers, sino que desea conocer las estadísticas de ciertos torrents que el tracker conoce. El funcionamiento es el mismo que el de la operación announce, así que el diseño también es el mismo. Pero en este caso, la query string solo está formada por los valores info_hash de los torrents sobre los que el peer local quiere conocer sus estadísticas. Un posible ejemplo sería este: http://tracker.com/scrape?info_hash=. . . &info_hash=. . . &info_hash=. . .
La clase que representa este tipo de query string es BtHTTPScrapeQuery, la cual tiene una variable de instancia que es una colección de info_hash. El tracker responde un diccionario «bencodificado» con las estadísticas de cada to- rrent (el nombre, número de seeders, número de leechers y números de veces que ha registrado descargas completadas). Esta información se representa con la clase BtHTTPScrapeResponseBody, subclase de Dictionary. Las instancias de BtTracker también tienen dos variables para guardar la petición (scrapeRequest) y respuesta (scrapeResponse) de scrape. Del mismo modo que con la operación announce, la clase BtHTTPTracker implementa el método abstracto scrape:
33 BtHTTPTracker>>scrape httpGET := self newGET: self asString asZnUrl asZnUrlScrape pathPrintString query: scrapeRequest asString. response := self sendGET: httpGET. self updateScrapeResponse: response Como se puede ver, esta implementación es análoga a la del método announce.
5.5.2. Tracker UDP
Aunque el núcleo de BitTorrent (BEP3) especifica solamente el funcionamiento de los trackers sobre HTTP, la realidad es que una aplicación BitTorrent que solo implemente este tipo de comunicación no podrá unirse a la mayoría de las redes presentes en Internet. La gran mayoría de los ficheros .torrent que existen tienen trackers UDP en su metainfo. Y la tendencia es usar cada vez más UDP en detrimento de HTTP. Esta propuesta de ampliación del protocolo (BEP15) se hizo para evitar el overhead que tiene TCP debido a la necesidad de abrir y cerrar una conexión, y asegurar el orden y la fiabilidad de la información transferida. Usando el protocolo HTTP (que usa TCP), en una petición announce con una respuesta de 50 peers, el número de octetos enviados y recibidos son alrededor de 1206. El protocolo UDP, en la misma operación, usa 4 paquetes y alrededor de 618 octetos, reduciendo el tráfico casi un 50 %. Para un peer este ahorro puede ser insignificante, pero para un tracker que sirve a millones de peers supone una gran diferencia. En este protocolo existen cuatro tipos de operaciones: connect, announce, scrape y error. La primera operación que se realiza es la operación connect. En esta operación el tracker envía un identificador de conexión (connectionID) al peer, el cual deberá utilizar en todas las operaciones posteriores. Cada vez que el tracker recibe una petición, comprueba el connectionID y, si no coincide con el que le suministró, ignora la petición. El peer tiene permitido usar este identificador de conexión hasta un minuto después de recibirlo y los trackers solo pueden responder a peticiones con identificadores de conexión de hasta dos minutos de vida. En caso de que una conexión expire, el peer debe realizar una operación connect de nuevo. Las operaciones announce y scrape tienen el mismo significado que en el pro- tocolo HTTP y la operación error solo la utiliza el tracker para comunicar al peer que se ha producido un error y porqué. UDP no es un protocolo fiable. Esto significa que no retransmite los paquetes perdidos por sí solo, sino que es la aplicación la responsable de ello. Siguiendo esta idea, si el peer no ha recibido una respuesta después de 15 · 2n segundos, debe retransmitir la petición, donde n empieza siendo 0 y se incrementa después de cada intento hasta llegar a 8 (3840 segundos).
34 Las clases implicadas en este protocolo se encuentran en el paquete BitTalk-UDPTrackerProtocol. Todas las operaciones se llevan a cabo con el in- tercambio de paquetes UDP entre el peer y el tracker, y estos paquetes se han representado en la clase BtUDPPacket. Todos estos paquetes tienen en común que contienen un identificador único de operación (id) y un número que establece el código o tipo de operación (actionCode), ambos representados con enteros de 32 bits. Los códigos de operación son: 0 - connect, 1 - announce, 2 - scrape y 3 - error. La combinación de estos dos números se ha representado en la clase BtUDPTransaction cuyas variables de instancia son id y actionCode. Y todas las instancias de BtUDPPacket tienen una variable de instancia transaction que apunta a un objeto BtUDPTransaction. Cada operación consta de un paquete de petición (request) enviado por el peer y de un paquete de respuesta (response) enviado por el tracker (excepto la operación error, que solo tiene paquete de respuesta). Todos los paquetes request tienen en común que contienen un número de co- nexión (connectionID) además de la información de BtUDPPacket por lo que los paquetes request son representados en la clase BtUDPConnectRequest (subclase de BtUDPPacket) con una variable de instancia connectionID. Si el paquete request en cuestión es de la operación connect entonces no contiene ninguna información más a parte del número de conexión. En cambio, si el paquete es de la operación an- nounce o scrape, tiene cierta información particular. Esta información se representa en las clases BtUDPAnnounceRequest y BtUDPScrapeRequest, ambas subclases de BtUDPConnectRequest. La información particular de estos dos últimos tipos de pa- quetes es la misma que contienen BtHTTPAnnounceQuery y BtHTTPScrapeQuery, respectivamente. Por otro lado, se encuentran los paquetes response de cada operación. En este caso, estos paquetes no comparten información a parte de la de BtUDPPacket así que simplemente cada tipo de repuesta se representa con una de las cla- ses BtUDPConnectResponse, BtUDPAnnounceResponse, BtUDPScrapeResponse y BtUDPErrorResponse, todas ellas subclases de BtUDPPacket. En el caso particular de BtUDPScrapeResponse, la respuesta contiene 3 en- teros de 32 bits por cada torrent consultado que informan del número de see- ders, el número de veces que el tracker ha registrado el evento de descar- ga completada y el número de leechers (en este orden). En total, el trac- ker responde una secuencia de 3n enteros donde n es el número de torrents consultados. La clase BtUDPScrapeTorrentStat representa la estadística de un torrent que devuelven los trackers UDP y tiene las variables de instancia seeders, completed y leechers. La clase BtUDPScrapeResponse, por tanto, contiene una colección de BtUDPScrapeTorrentStat en la variable de instancia scrapeTorrentStatCollection.
35 Figura 13: Jerarquía de clases de los paquetes UDP.
Todas las clases explicadas hasta ahora sirven para representar la informa- ción de las operaciones como objetos dentro de Smalltalk, pero esta información viaja por la red como secuencias de octetos, así que es necesario un sistema de codificación y decodificación que permita transformar estos objetos en secuencias de octetos y viceversa. En primer lugar, la clase BtUDPPacket, todas sus subcla- ses y las clases BtUDPTransaction y BtUDPScrapeTorrentStat tienen el método asByteArray que convierte la información que representan en una secuencia de octetos tal y como especifica el protocolo. En el siguiente trozo de código se puede ver la implementación del método asByteArray en la clase BtUDPTransaction. BtUDPTransaction>>asByteArray ^(actionCode asByteArrayOfSize: 4) , (id asByteArrayOfSize: 4) Este método lo invoca a su vez el método BtUDPPacket>>asByteArray ya que todos los paquetes UDP contienen como mínimo la información de una operación (transaction). BtUDPPacket>>asByteArray ^transaction asByteArray En el siguiente trozo de código se puede ver la implementación de BtUDPConnectRequest>>asByteArray. Como todos los paquetes request compar- ten la información de BtUDPPacket, este método invoca al método asByteArray de la superclase y concatena el resultado con la información específica de este tipo de paquetes en el orden que establece el protocolo. BtUDPConnectRequest>>asByteArray ^ (connectionID asByteArrayOfSize: 8) , (super asByteArray) Análogamente, el método BtUDPAnnounceRequest>>asByteArray invoca al método de la superclase BtUDPConnectRequest porque todas las peticiones de announce comparten la información de BtUDPConnectRequest. Una vez tiene la
36 información de la superclase en forma de octetos, los concatena con la información específica de este tipo de paquetes en el orden que determina el protocolo. BtUDPAnnounceRequest>>asByteArray ^ super asByteArray , ( infoHash asByteArrayOfSize: 20) , ( peerID asByteArrayOfSize: 20) , [...] ( numWant asByteArrayOfSize: 4) , ( node port asPortNumber ) . Las implementaciones de asByteArray de los demás tipos de paquetes que no aparecen aquí siguen el mismo diseño. Hemos visto que las implementaciones de asByteArray convierten la información de los paquetes UDP en secuencias de octetos, pero también es necesaria la función inversa: convertir las secuencias de octetos pro- cedentes del tracker en instancias de las clases BtUDPConnectResponse, BtUDPAnnounceResponse, BtUDPScrapeResponse o BtUDPErrorResponse. El diseño de esta funcionalidad es idéntico al del bencoding (ver apartado 5.1); el método ByteArray>>decodeUDPResponse invoca a PositionableStream>>decodeUDPResponse, ByteArray>>decodeUDPResponse ^self readStream decodeUDPResponse que se encarga de decodificar el tipo de respuesta en función del código de opera- ción: PositionableStream>>decodeUDPResponse actionCode:= (self next: 4) asInteger. 4 timesRepeat: [ self back ]. actionCode = (BtUDPTransaction announceActionCode) ifTrue:[^self decodeUDPAnnounceResponse]. actionCode = (BtUDPTransaction connectActionCode) ifTrue:[^self decodeUDPConnectResponse]. actionCode = (BtUDPTransaction scrapeActionCode) ifTrue:[^self decodeUDPScrapeResponse]. actionCode = (BtUDPTransaction errorActionCode) ifTrue:[^self decodeUDPErrorResponse]. La clase BtUDPTracker representa la «conexión UDP» del peer con el tracker. Aunque también puede interpretarse como la representación del tracker UDP físico dentro de Smalltalk, con el que el peer local puede interaccionar a través de los métodos announce y scrape. Los objetos principales que contiene una instancia de BtUDPTracker son una instancia de la clase Socket en la variable de instancia socket y una instancia de BtUDPTransactionQueue en la variable de instancia transactionQueue.
37 La variable socket se inicializa como un socket UDP que el peer local puede utilizar para enviar y recibir paquetes con los métodos sendPacket: y receivePacket. BtUDPTracker>>sendPacket: aPacket socket sendData: aPacket asByteArray toHost: domain address asIPv4 port: port.
BtUDPTracker>>receivePacket packetSize := 0. bufferIn := ByteArray new: 2000. packetSize := socket receiveDataInto: bufferIn fromHost: domain address asIPv4 port: port ]. packet := (bufferIn copyFrom: 1 to: packetSize) decodeUDPResponse. ^ packet
La clase BtUDPTransactionQueue es una cola (subclase de SharedQueue) en cuyas instancias el peer puede introducir las operaciones pendientes de realizar. Como se ha dicho más arriba la instancia del tracker UDP contiene el objeto transactionQueue, este objeto es necesario puesto que en un momento deter- minado el peer puede querer realizar más de una operación. Por ejemplo, puede querer realizar una operación connect, una operación announce y una operación scrape. El objeto BtUDPTracker es el encargado de ir accediendo a la cola para realizar las operaciones pendientes en el orden que se introdujeron. Este tipo de cola tiene la particularidad que cada vez que se añade una operación connect, ésta pasa a la primera posición ya que mantener una conexión viva es más prioritario que realizar cualquier otra operación puesto que sin conexión el tracker no servirá ninguna pe- tición excepto la de connect. Así que siempre que hay una operación connect en la cola, se encuentra en la primera posición. Para conseguir este funcionamiento espe- cífico, BtUDPTransactionQueue, en su inicialización, sustituye la colección subya- cente (instancia de OrderedCollection) por una instancia de SortedCollection y usa la función de comparación BtUDPTransaction>>priorOrEqualTo: como criterio de ordenación que asegura el orden deseado, como se puede ver en los siguientes trozos de código. BtUDPTransactionQueue>>initialize super initialize. items := SortedCollection sortBlock: [ :a :b | a priorOrEqualTo: b ]
BtUDPTransaction>>priorOrEqualTo: anotherTransaction ^actionCode = ConnectActionCode or:[ anotherTransaction actionCode ~= ConnectActionCode] Además, el objeto BtUDPTracker se encarga de eliminar de la cola la operación pendiente que se satisface cada vez que llega una respuesta. Para ello, decodifica el mensaje entrante para recuperar el objeto BtUDPTransaction que contiene y así
38 poder encontrarlo en la cola. Para que la comunicación entre el peer y el tracker funcione, el objeto BtUDPTracker necesita enviar los paquetes pendientes y recibir las respuestas constantemente, además de controlar si hay que restablecer la conexión o si ha pasado el tiempo suficiente antes de volver a enviar una petición. Para ello, ini- cia dos procesos independientes que solo terminan cuando se invoca el método BtUDPTracker>>terminate. El contenido del bloque de ejecución del proceso de envío de paquetes (definido en la variable sending3) es el siguiente. [ self secondsToNextAttempt <= 0 ifTrue: [ self dequeueAndSendNextPacket ] ifFalse: [ self waitForNextAttempt ] ] repeat Se puede observar que solo envía peticiones si ha pasado el tiempo suficiente (secondsToNextAttempt <= 0) y espera hasta que se pueda enviar la siguiente petición pendiente. En caso de poder enviar otra petición, el proceso invoca a dequeueAndSendNextPacket. BtUDPTracker>>dequeueAndSendNextPacket self isConnectionAlive ifFalse: [ self reestablishConnection ]. packet := self dequeueNextRequest. packet ifNotNil: [ self sendPacket: packet ] Este método, antes de enviar cualquier petición, comprueba que la conexión no haya expirado. En caso de que haya expirado, añade una nueva petición de connect a la cola invocando el método reestablishConnection y el criterio de ordenación asegura que será la primera petición en enviarse aunque se hayan añadido otras previamente. El proceso de recibir paquetes (definido en la variable receiving) invoca el método receiveAndHandleNextPacket constantemente, como se puede ver en su bloque de ejecución. [ self receiveAndHandleNextPacket ] repeat
BtUDPTracker>>receiveAndHandleNextPacket self handleReceivedPacket: self receivePacket Este último método invoca a receivePacket, que no devuelve un pa- quete hasta que no haya recibido uno. A continuación se invoca el método handleReceivedPacket: con el paquete entrante como argumento y éste actuali- za el estado de la conexión en función del tipo del paquete y la información que contiene. 3En Smalltalk todo son objetos, incluso los procesos
39 5.5.3. La clase BtMultitracker
La mayor debilidad de las redes BitTorrent es el tracker. Si el tracker deja de fun- cionar ya sea por error o por acciones malintencionadas, la red entera desaparece. El BEP12 es una propuesta de ampliación que intenta paliar esta vulnerabilidad. Esta medida consiste en que varios trackers puedan servir a la misma red coordinadamente de forma que si un tracker no puede responder, otro tracker pueda seguir realizando la misma función. Es bastante común la situación en que los trackers solitarios de los ficheros .torrent que incluyen múltiples trackers adicionales no sean accesibles. Así que una aplicación BitTorrent que no implemente esta ampliación tendrá bastantes dificultades para unirse a muchos enjambres, puesto que la mayoría de ficheros .torrent incluyen la opción multitracker. Para que esta mejora funcione, primero hay que modificar el diccionario me- tainfo para que los peers sepan las URL de los trackers adicionales que pueden con- sultar. Esta información aparece en una nueva clave del diccionario (al mismo nivel de la clave announce) con el nombre announce-list y apunta a una lista de listas de URL. A estas listas se les da el nombre de tiers (capas o niveles en castellano). Más adelante se explica el porqué de estos tiers. Si la aplicación es compatible con esta funcionalidad y esta nueva clave se encuentra en la metainfo, entonces ignora la clave announce y solo usa las URL apuntadas por announce-list. Los tiers de trackers son usados secuencialmente; todas las URL de un tier deben ser comprobadas antes de usar el siguiente tier. Dentro de cada tier, las URL se comprueban en orden aleatorio. Por lo que es responsabilidad de la aplicación mezclarlas aleatoriamente antes de usar el tier por primera vez. Si la aplicación conecta satisfactoriamente con un tracker, su URL se mueve a la primera posición del tier. A continuación se muestran unos ejemplos de valores de announce-list y cómo la aplicación debe usarlos. En estos ejemplos, se supone que la aplicación ya ha mezclado todas las URL dentro cada tier. d[‘announce-list’]=[ [tracker1], [backup1], [backup2] ]
En este caso, primero se prueba tracker1. Si no responde, se intenta con backup1. Si tampoco responde, se intenta con backup2. Y se sigue probando todos los tiers en el orden que aparecen mientras no responda ningún tracker. Este caso se da cuando los trackers son estándar y no pueden coordinarse para compartir información. d[‘announce-list’]=[[tracker1, tracker2, tracker3]]
En este caso, primero se intenta conectar con tracker1. Si no se puede, se intenta con tracker2. Si éste sí responde, entonces la lista pasa a ser [tracker2, tracker1, tracker3]. Y este es el nuevo orden en que la aplicación procesa la lista en el
40 próximo intento. Si más adelante ni tracker2 ni tracker1 responden pero tracker3 sí, entonces la lista pasa a ser [tracker3, tracker2, tracker1] y será procesada en este orden en el próximo intento. Cuando hay varios trackers dentro de un tier, como en este ejemplo, significa que son capaces de coordinarse para compartir información. Además, el hecho de mezclarlos ayuda a balancear la carga de trabajo. d[‘announce-list’]=[[tracker1, tracker2], [backup1,backup2]]
En este caso, la aplicación intenta acceder a los trackers del primer tier como en el ejemplo anterior. Si todos los trackers fallan, entonces pasa a probar el siguiente tier y lo reordena de la misma forma que en el ejemplo anterior si es necesario. Esta estructura de trackers es representada con la clase BtMultitracker. Esta clase encapsula una OrderedCollection que contiene los tiers (también OrderedCollection’s). El método shuffle mezcla los elementos de todos los tiers; el método selectNext selecciona el siguiente tracker del tier actual o selec- ciona el primero del siguiente si el tracker es el último del tier actual; el método moveCurrentToFirst mueve el tracker actual a la primera posición del tier donde se encuentra; los métodos selectFirst y selectLast devuelven el primer tracker del primer tier y el último tracker del último tier, respectivamente; y el método current devuelve el tracker seleccionado en el instante de invocarlo. Con estos métodos, la aplicación ya dispone de una interfaz para manipular la estructura de los multitracker.
5.6. Control de las piezas
En el enjambre, el peer local debe mantener el control de las piezas que tiene y las piezas que tienen los peers remotos conocidos. Tener esta información es esencial para saber qué piezas pedir a otros peers y al mismo tiempo poder comunicar a los demás peers qué piezas tiene para que se las puedan pedir. La clase encargada de llevar este control es BtBitfield. Esta clase encapsula un ByteArray en el que el bit de mayor peso del primer octeto controla si el peer en cuestión tiene la primera pieza (con índice 0), mientras que el bit de menor peso del último octeto hace lo mismo con la última pieza. Además dispone de todos los métodos necesarios para consultar o modificar cualquier bit. El método BtBitfield>>interestingBitfield: recibe como argumento otro BtBitfield y responde otra instancia de la misma clase pero solo con los bits a 1 si el receptor del mensaje los tenía a 0 y el argumento a 1. En otras palabras, el receptor responde un BtBitfield indicando las piezas que le faltan y el argumento sí tiene. Esto se consigue aplicando la función booleana (a ⊕ b) ∧ b bit a bit a cada octeto, lo que en Pharo se expresa así:
41 BtBitfield>>interestingBitfield: [...] newByte := (byte bitXor: anotherByte) bitAnd: anotherByte. [...] ^ newBitfield Con este método es posible saber qué piezas pedir a cada peer. Por cada torrent que gestiona, el peer local tiene un objeto BtBitfield para controlar qué piezas tiene, y una colección de peers remotos que contienen un objeto BtBitfield cada uno de ellos, que pueden ser accedidos para actualizarlos. De esta forma el peer local puede mantener un control de sus piezas y las de los vecinos.
5.7. Comunicación peer-to-peer
La comunicación P2P es la parte del protocolo que se produce a partir del momento en que un peer ha conseguido la dirección IP y puerto de otro peer e intenta estable- cer una conexión con la intención de intercambiar piezas. El núcleo de BitTorrent (BEP3) especifica la forma estándar en que se producen estas conexiones, que es sobre TCP. Estas conexiones son simétricas, es decir, el formato de los mensajes es independiente del sentido en el que viajan. Esto es así porque a ambos extremos de la conexión se encuentran dos nodos con roles y capacidades equivalentes. Existen dos conceptos que determinan el estado de una conexión entre dos peers. Estos conceptos son nombrados en el protocolo como choked y interested. La traducción literal de choked es «obstruido», pero de ahora en adelante nos referiremos a este concepto como bloqueado o no aceptado. Cuando un peer A bloquea a otro peer B significa que A no enviará ninguna pieza a B mientras no lo desbloquee. La traducción de interested es «interesado». Cuando un peer A está interesado en otro peer B significa que B tiene piezas que A no tiene. Por cada conexión, el peer local debe guardar ambos estados para los dos extremos de la conexión. Es decir, si el peer local bloquea al peer remoto y si es interesante; y viceversa. Las conexiones empiezan por defecto con el peer remoto bloqueado y siendo no interesante. En el apartado 5.9 se explica qué papel juega el bloqueo en una red BitTorrent.
5.7.1. Mensajes
El mecanismo para establecer una conexión P2P en BitTorrent es mediante un handshake entre los dos extremos. Primero, el peer que quiere iniciar la conexión
42 envía un mensaje que consta de la siguiente información.
Un octeto con el valor 19 en decimal, indicando la longitud de la cadena de caracteres que da nombre al protocolo.
La cadena «BitTorrent protocol», de la longitud indicada en el primer octeto.
Ocho octetos reservados para posibles ampliaciones del protocolo.
El valor info_hash (20 octetos) que identifica al torrent de forma única.
El peer_id (20 octetos) que el peer envía al tracker en la operación announce.
Entonces, el peer receptor del mensaje envía el mismo mensaje pero cambiando el valor peer_id con el suyo propio. Los peers deben comprobar que la informa- ción de los mensajes que reciben en el handshake es correcta y que el info_hash corresponde con alguno de los torrents que está compartiendo. En caso contrario, deben cerrar la conexión. Suponiendo que el handshake ha tenido éxito, a partir de ese momento la conexión P2P ha sido establecida y los peers pueden empezar a compartir sus piezas. Estas piezas son nombradas por su índice (la primera pieza tiene el índice 0). Hasta ahora solo se ha mencionado que los torrents se parten en piezas de igual tamaño y que éstas se transfieren entre los peers de la red. Pero eso es una simplificación del funcionamiento de BitTorrent. En realidad, la unidad mínima de información útil es el bloque. Si entendemos una pieza como una secuencia de octetos, un bloque es una parte contigua de tamaño variable de una pieza. Durante la vida de la conexión P2P, los peers están autorizados a enviarse una serie de mensajes, todos ellos con la siguiente forma.
La primera parte son 4 octetos que indican la longitud total del mensaje (sin incluir esta parte) en decimal; el tipo del mensaje (decimal) es 1 octeto; y por último, la información útil es una secuencia de octetos de tamaño variable (en función del tipo de mensaje). A continuación se detalla el contenido y significado de cada tipo de mensaje. keep alive: <0> Se envía para mantener la conexión viva si ningún otro mensaje ha sido enviado durante 2 minutos. choke: <1><0> El emisor comunica al receptor que lo ha bloqueado, es decir, que no le servirá ninguna petición de bloque pendiente o futura.
43 unchoke: <1><1> El emisor comunica al receptor que lo ha desbloqueado y que responderá las peticiones de bloques. interested: <1><2> El emisor comunica al receptor que está interesado en alguna de sus piezas. not interested: <1><3> El emisor comunica al receptor que no está interesa- do en ninguna de sus piezas. have: <5><4><índice de pieza> El índice de pieza son 4 octetos en deci- mal. El emisor comunica al receptor que tiene una pieza determinada. Este mensaje lo envía el peer local a todos los peers conocidos cada vez que con- sigue descargar una pieza nueva. bitfield: <1+X><5>
Como en otras partes de la implementación, es necesario un conjunto de clases que representen estos mensajes dentro de Smalltalk como objetos y un sistema
44 para, por un lado, codificar estos objetos en secuencias de octetos para ser enviadas a la red y, por otro lado, decodificar las secuencias de octetos que contienen estos mensajes obteniendo los objetos que los representan. Todas las clases implicadas directamente en la comunicación P2P se encuentran en el paquete BitTalk-P2P. Los mensajes intercambiados durante el handshake son distintos a los mensajes enviados después ya que no comparten forma. Así que la clase BtHandshakeMessage representa los mensajes del handshake y la clase BtMessage representa a todos los mensajes enviados después del handshake, que sí comparten forma. La clase BtHandshakeMessage tiene como variables cada una de las partes que se envían en el mensaje del handshake como se puede ver en su definición. Object subclass: #BtHandshakeMessage instanceVariableNames:’protocolIdentifier infoHash peerID protocolBehaviour’ classVariableNames:’ProtocolIdentifier’ category:’BitTalk −P2P’ Y el método BtHandshakeMessage>>asByteArray codifica sus instancias en secuencias de octetos listas para ser enviadas a la red. Con el método ByteArray>>decodeHandshake se realiza la operación inversa. Como pasa con el bencoding y los paquetes de la comunicación con los trackers UDP, este método invoca a PositionableStream>>decodeHandshake. La clase BtMessage tiene las variables de instancia type, que representa el tipo del mensaje, y payload, que representa la información útil. No tiene ninguna va- riable de instancia para guardar la longitud del mensaje ya que ésta depende de las otras dos, y es calculada y codificada en el método BtMessage>>asByteArray. Es- te método codifica cada una de las partes que componen un mensaje en secuencias de octetos como se ve en su implementación. BtMessage>>asByteArray | bytesPayload length message | length := type ifNil: [ 0 ] ifNotNil: [ 1 ]. bytesPayload := payload ifNil: [ ByteArray new ] ifNotNil: [ payload asByteArray ]. length := length + bytesPayload size. message := OrderedCollection new. message addAll: (length asByteArrayOfSize: 4). type ifNotNil: [ message add: type ]. message addAll: bytesPayload. ^ message asByteArray La última parte, el payload o información útil, es representada por la clase BtMessagePayload y tiene una subclase por cada tipo de payload que puede enviar- se. Esta clase tiene el método abstracto asByteArray ya que la forma de codificar la información del payload depende de su tipo. Estos tipos son BtBitfieldPayload (para el mensaje bitfield), BtBlockDescriptionPayload (para los mensajes re- quest y cancel), BtBlockPayload (para el mensaje piece) y BtHavePayload (para
45 el mensaje have). Cada tipo de payload tiene sus propias variables de instancia porque la información que contienen es distinta. Por tanto, cada tipo tiene su pro- pia implementación de asByteArray. En los siguientes trozos de código podemos ver las implementaciones de BtBlockDescriptionPayload y BtBlockPayload. BtBlockDescriptionPayload>>asByteArray | bytes | bytes := OrderedCollection new. bytes addAll: (index asByteArrayOfSize: 4); addAll: (begin asByteArrayOfSize: 4); addAll: (length asByteArrayOfSize: 4). ^ bytes asByteArray
BtBlockPayload>>asByteArray | bytes | bytes := OrderedCollection new. bytes addAll: (index asByteArrayOfSize: 4); addAll: (begin asByteArrayOfSize: 4); addAll: block. ^ bytes asByteArray
El proceso inverso (decodificar secuencias de octetos en instancias de BtMessage) lo hace el método ByteArray>>decodeMessage. Como en los anteriores sistemas de codificación mencionados, este método invoca a PositionableStream>>decodeMessage.
5.7.2. Sistema de colas
En cada conexión P2P es necesaria una estructura de cola para almacenar los obje- tos BtMessage pendientes de enviar y otra para almacenar los objetos BtMessage entrantes procedentes del peer remoto. La clase BtMessageQueue, subclase de SharedQueue, cumple esta función. Se ha decidido heredar las propiedades de SharedQueue porque estas colas son accedidas por más de un proceso a la vez y este tipo de cola garantiza exclusión mutua. Además, el uso de estas colas permite no tener que enviar directamente los mensajes request por el socket que gestiona la conexión P2P. Esto es importante, por ejemplo, cuando el peer local recibe un mensaje choke. En tal caso, todos los mensajes request de la cola de salida pue- den ser descartados ya que no serán respondidos. Sucede lo mismo a la inversa, cuando el peer local envía el mensaje choke a un peer remoto. El primero debe descartar todos los mensajes piece salientes pendientes de enviar, así como todos los mensajes request entrantes porque no los va a responder. Sin el uso de estas colas, no se podría evitar el envío de estos mensajes innecesarios. Aún así, no se
46 puede impedir completamente el envío de mensajes innecesarios a la red, ya que siempre es posible que algunos mensajes ya hayan sido extraídos y tratados an- tes de poder impedirlo. Los métodos encargados de descartar estos mensajes son discardAllPieces y discardAllRequests. Estas colas también disponen de una serie de optimizaciones implementadas en el método BtMessageQueue>>nextPut: que se explican a continuación. Cada vez que se añade un mensaje choke/unchoke o interested/not interested, todos los mensajes de estos tipos son eliminados de la cola, respectivamente. Esto es posible hacerlo porque en una sucesión de estos tipos de mensajes, el último en llegar anula a los anteriores puesto que representa el último estado deseado por el peer emisor. Cada vez que se añade un mensaje cancel, elimina todos los requests de la cola que concuerdan con la descripción de bloque del cancel, puesto que éste los anula y ya no es necesario tratarlos. Cada vez que se añade un mensaje not interested, elimina todos los requests porque el emisor de estos mensajes ya no quiere los bloques descritos por esos requests.
5.7.3. La clase BtRemotePeer
La clase BtRemotePeer representa las conexiones P2P. Aunque una conexión P2P dentro de Smalltalk también puede verse como el objeto que representa al peer remoto en el otro extremo de la conexión y con el cual se puede interaccionar enviando y recibiendo mensajes. Las principales variables de esta clase son las siguientes.
socketStream. Un objeto SocketStream sobre TCP para enviar y recibir los mensajes P2P.
bitfield. Un objeto BtBitfield para llevar el control de las piezas del peer remoto.
unfulfilledOutgoingRequests. Una OrderedCollection que contiene las peticiones pendientes de respuesta del peer local hacia el peer remoto. Esta colección es necesaria para no duplicar peticiones en la red. Los elementos de unfulfilledOutgoingRequests son instancias de la clase BtBlockRequest, que representa las peticiones de bloque. Sus variables de instancia son pieceIndex, offset y length (la información que describe un bloque).
inMessageQueue. Un objeto BtMessageQueue para guardar los mensajes en- trantes pendientes de tratar.
47 outMessageQueue. Un objeto BtMessageQueue para guardar los mensajes salientes pendientes de enviar.
Como ya se ha dicho anteriormente, el peer local puede bloquear/desbloquear y poner como interesante/no interesante al peer remoto de cada conexión; y el peer remoto hace lo mismo con el peer local. Estos estados se controlan con las variables de instancia isAccepted y isInteresting para los estados que determina el peer local, y acceptsMe y isInterested para los estados que determina el peer remoto. Las instancias de BtRemotePeer tienen dos procesos que se ejecutan indefinida- mente mientras la conexión está viva. Estos procesos son el de enviar los mensajes (variable sending) y el de recibirlos (variable receiving). El proceso de enviar mensajes invoca el método dequeueAndSendNextMessage. BtRemotePeer>>dequeueAndSendNextMessage self ensureKeepAlive. nextMessageToSend := outMessageQueue nextOrNil. nextMessageToSend ifNotNil: [ socketStream nextPutAllFlush: nextMessageToSend asByteArray. peerLock critical: [ lastMessageSentTime := Time millisecondClockValue ] ] Este método primero añade el mensaje keep alive a la cola de salida si no se ha enviado ningún mensaje en los últimos 2 minutos. Para saber si esto es así, siempre se actualiza el tiempo del último mensaje enviado en la variable lastMessageSentTime. A continuación, extrae el siguiente mensaje pendiente de la cola de salida outMessageQueue y lo envía por el socketStream codificado en una secuencia de octetos (con el método asByteArray). El proceso de recibir mensajes invoca el método receiveAndEnqueueNextMessage. BtRemotePeer>>receiveAndEnqueueNextMessage messageReceived := [ self receiveNextMessage ] on: ConnectionTimedOut, BtMessageError do: [ :ex | ex return: nil]. messageReceived ifNotNil: [ inMessageQueue nextPut: messageReceived ] Primero recibe el siguiente mensaje entrante del socketStream con el mé- todo receiveNextMessage y seguidamente lo introduce en la cola de entrada inMessageQueue. El método receiveNextMessage, recibe los octetos del siguiente mensaje por el socketStream e invoca al método ByteArray>>decodeMessage, que es el encargado de decodificar los octetos en una instancia de BtMessage.Y ese es el objeto que devuelve, como puede verse en su implementación.
48 BtRemotePeer>>receiveNextMessage | length stream prefix | prefix := self receiveNext: 4. stream := WriteStream with: prefix. length := prefix asInteger. length > 0 ifTrue: [ stream nextPutAll: (self receiveNext: length) ]. ^ stream contents decodeMessage Adicionalmente, los objetos BtRemotePeer también tienen las variables de ins- tancia downloaded y uploaded que sirven para actualizar la cantidad de octetos descargados y subidos por el peer remoto, respectivamente. Estas variables son importantes, como se verá más adelante, en el algoritmo de bloqueo.
5.8. Piezas temporales
Como se ha dicho anteriormente, la unidad mínima de información útil que se envía es el bloque. El tamaño de bloque que la mayoría de implementaciones usan es 16 KiB y también es el que se usa por defecto en esta implementación. Cuando el peer local recibe un bloque tiene que decidir qué hacer con él: o bien lo escribe directamente en la parte del disco que le corresponde, o bien lo conserva en la memoria volátil del sistema hasta que tenga todos los bloques que forman una pieza, y entonces escribe la pieza en disco y borra los bloques de la memoria volátil. En esta implementación se ha decidido conservar los bloques en la memoria volátil por una cuestión de eficiencia. En Pharo-Smalltalk, como en otros sistemas y lenguajes, es mucho más costoso realizar muchas escrituras de poca información que realizar una única escritura de toda la información a la vez. La clase encargada de guardar los bloques antes de escribirlos en disco es BtTemporaryPiece. Las instancias de esta clase contienen una colección ordenada cuyos elementos son bloques (instancias de ByteArray). Y su tamaño es el cociente entre el tamaño de la pieza que representa y el tamaño de los bloques que esté usando el peer local para el torrent que está descargando. La forma de acceder a los bloques es mediante los métodos at: y at:put:. El primer parámetro en ambos casos es el offset que ocupa dentro de la pieza; en el caso de escritura, el segundo parámetro son los octetos a escribir. Además, también es necesario saber si los bloques han sido pedidos a otro peer para no pedirlo por duplicado. El estado de los bloques se controla con los métodos requestedAt:, setRequest: y clearRequest:, los cuales reciben un offset.
49 5.9. Algoritmo de bloqueo
Durante la compartición de torrent, el peer local está recibiendo constantemente múltiples peticiones de bloque procedentes de los peers de su vecindario. El peer local tiene que poner un límite al número peers a los que envía bloques. Es decir, tiene que decidir qué peers va a bloquear y cuales no. Hay varios motivos para hacerlo. El primero es que el control de congestión de TCP se comporta bastante mal cuando se envían (o se suben) mensajes por muchas conexiones a la vez. El segundo es que es necesario establecer una política de reciprocidad u «ojo por ojo, diente por diente» para evitar que peers egoístas (o free riders), aquellos que descargan de otros peers pero no corresponden compartiendo sus recursos, puedan aprovecharse de los demás. Por defecto, el protocolo establece que el peer local sirva a los 4 peers remotos más generosos, es decir, aquellos peers de los que ha conseguido descargar más bloques. Esta decisión es revaluada cada 10 segundos para evitar lo que se conoce como fibrillation, lo que pasa cuando un peer entra en un estado en el que es bloqueado y desbloqueado sucesivamente con tanta frecuencia que el enjambre pierde eficiencia. Cuando el peer local ha descargado el torrent completamente ya no tiene nada que descargar, así que ya no puede decidir en función de la generosidad de los demás peers. En este caso el peer local debe desbloquear los 4 peers a los que más bloques ha enviado. Este algoritmo de bloqueo supone un problema para los peers que acaban de unirse a la red y no tienen piezas, puesto que nunca serán desbloqueados por otros peers debido a que son considerados los más egoístas (no han compartido nada todavía). Para solucionarlo, el protocolo establece una algoritmo adicional para desbloquear de forma optimista (optimistic unchoking). En todo momento, el peer local tiene desbloqueado a un peer remoto aleatorio independientemente de lo generoso que sea, y esta decisión se toma cada 30 segundos. Tiempo suficiente para que el peer nuevo consiga descargar una pieza que pueda compartir con otros peers, y así poder ser considerado menos egoísta, y por tanto, desbloqueado. Con este algoritmo los peers nuevos tienen tres veces más de posibilidades de ser desbloqueados de forma optimista que los demás. Además, este desbloqueo optimista ofrece al peer local la posibilidad de encontrar nuevas conexiones con mejores tasa de descarga que las desbloqueadas por el algoritmo de bloqueo que se basa en la reciprocidad. Teóricamente, se puede dar el caso que un peer esté bloqueado por todos sus vecinos, incluso por aquellos a los que está subiendo información si el ancho de banda de subida no es suficientemente grande como para ser elegido entre los 4 primeros por alguno de sus vecinos. En este caso, el peer local lo que debe hacer es, o bien buscar nuevos peers, o bien reducir el número de peers desbloqueados. BitTorrent usa una medida «antibloqueo» (o anti-snubbing) que consiste en blo- quear a todos los peers remotos de los que no se ha descargado ningún bloque en
50 el último minuto. El algoritmo de bloqueo de BitTorrent intenta alcanzar la eficiencia u óptimo de Pareto[3]. La implementación de este algoritmo de bloqueo se encuentra en la clase BtTorrent, que se explica en el apartado 5.14.
5.10. Algoritmo de selección de piezas
Una vez que el peer local ha establecido conexiones con sus vecinos, necesita de- terminar en qué orden va a descargar las piezas disponibles (a cuales les da más prioridad) en la parte del enjambre que conoce. A continuación se explican las diferentes políticas de selección de piezas que se pueden usar en algún momento durante el tiempo que el peer local está en la red. En todas las políticas se da por sentado que las piezas que ya tiene el peer local se descartan de la selección. La im- plementación del sistema de selección de piezas se encuentra en la clase BtTorrent, que se explica en el apartado 5.14.
5.10.1. Rarest first
Esta política selecciona primero las piezas con menor número de copias en el vecin- dario. Esta política tiene tres ventajas. Primero, aumenta la probabilidad de que el peer local sea interesante para otros peers porque posee algo que los demás no tienen. Segundo, iguala la distribución de las piezas en la red, cosa que minimiza el riesgo de que el tiempo de descarga de un grupo cualquiera de peers aumente considerablemente cuando los peers que poseen una pieza muy rara abandonan la red. Tercero, esta política tiende a igualar la velocidad de propagación de todas las piezas por la red. Esta política puede ralentizar la descarga en el período inicial, cuando el peer todavía no ha descargado un cierto número pequeño de piezas. Esto se debe a dos motivos. Uno, el algoritmo de bloqueo perjudica a los peers que no tienen piezas que compartir. Y dos, cuanto más rara es una pieza más tiempo se necesita para descargarla. Por lo que la política rarest first puede ser mala justo al inicio.
5.10.2. Random
Esta política simplemente selecciona una pieza aleatoria. Puede ser útil justo en el inicio de la descarga, como alternativa a la política rarest first. Es la política estándar en el núcleo de BitTorrent (BEP3), aunque la política rarest first es la que se usa de facto durante la mayor parte de la descarga por las ventajas mencionadas arriba.
51 5.10.3. Most common first
Esta política selecciona primero las piezas más comunes. Puede ser mejor que la política random justo al inicio de la descarga si el peer local tiene muchas dificultades para conseguir su primera pieza.
5.10.4. Lower first
Es posible que una aplicación BitTorrent necesite descargar las piezas en orden estricto de índice. Esto sucede sobretodo en las aplicaciones que hacen streaming sobre BitTorrent.
5.11. End Game
Cuando el peer local se ha unido a una red BitTorrent y ha conseguido una buena tasa de descarga se debe a que está descargando un número considerable de piezas procedentes de múltiples peers remotos que lo tienen desbloqueado. A medida que el torrent se acerca al final de la descarga, la tasa de descarga disminuye. La primera explicación que cualquiera podría dar es que las últimas piezas son muy raras. Y no es así, las últimas piezas son tan comunes o más que todas las descargadas previamente porque lo asegura la política rarest first. La disminución de la tasa de descarga se debe a que el número de piezas que se buscan es tan pequeño que es mucho más difícil conocer el mismo número de peers que las tengan que cuando se buscaban muchas más piezas. Y al encontrar menos peers, la tasa de descarga disminuye. Para contrarrestar esta situación, BitTorrent establece la fase o modo End Game, que comienza cuando todos los bloques de las piezas restantes han sido pedidos. A partir de ese momento, el peer local pide todos los bloques restantes a todos los peers remotos que lo tengan desbloqueado y tengan esos bloques. Para evitar que esta situación, aunque relativamente breve, sature la red con bloques redundantes, cuando el peer local recibe un bloque, envía un cancel a todos los peers remotos a los que les pidió ese bloque.
5.12. Conteo de las piezas en la red
Cuando el peer local está conectado a otros peers, en la red pueden haber muchas piezas disponibles y, según la fase en que se encuentre la descarga del torrent, convendrá usar una política de selección de piezas u otra a la hora de elegir el orden en que se descargarán (como se explicó en el apartado 5.10). Una información esencial para llevar esto a cabo es el número de ocurrencias de las piezas en el vecindario. Así que es necesario tener un objeto al que podamos acceder para
52 que nos dé esa información y que nos permita establecer qué criterio queremos para ordenarlas en cada momento. Estas funcionalidades las ofrecen las clases BtPieceCounter y BtPiecesOnNetwork. La clase BtPieceCounter simplemente representa el contador de una pieza cu- yos miembros son dos enteros: uno para definir el índice de la pieza y otro para actualizar la cuenta. Las instancias de esta clase disponen de un método de compa- ración rarestOrEqualThan: que recibe otro BtPieceCounter como argumento y determina si el receptor aparece menos o igual veces en la red. También es posible compararlas por índice con el método lowerOrEqualThan:. La clase BtPiecesOnNetwork encapsula una SortedCollection que contiene tantas instancias de BtPieceCounter como piezas tenga el torrent que se esté compartiendo. Esta colección por defecto está ordenada utilizando la función de comparación de conteo nombrada arriba. También es posible modificar explícita- mente el tipo de ordenación que usará la colección con los métodos setIndexMode y setRarityMode. El conteo de las piezas de BtPiecesOnNetwork se actualiza con el método modifyAt:by: indicando el conteo de qué pieza va a modificarse y cuánto va a aumentar o disminuir. Esta actualización solo se produce en tres casos:
Un peer nuevo se une al vecindario, es decir, el peer local consigue establecer una conexión nueva. En tal caso, el peer remoto envía los índices de las piezas que tiene y el peer local debe aumentar en 1 el conteo de las piezas que posee este nuevo peer.
Un peer remoto envía un mensaje indicando que tiene una pieza nueva. En tal caso, hay que aumentar en 1 el conteo de la pieza cuyo índice ha llegado.
Cuando un peer remoto es descartado por el peer local, las copias de las piezas que tiene ese peer ya no están disponibles en el vecindario, así que hay que decrementar en 1 el conteo de esas piezas.
5.13. La clase BtRemotePeerCollection El peer local, por cada torrent, tiene asociada una colección de conexiones u objetos BtRemotePeer con los que intercambia mensajes y bloques. El peer local tiene que ser capaz de realizar una serie de operaciones básicas sobre estos peers como seleccionar u ordenarlos según algunos criterios. Por ejemplo, cuando tiene que decidir qué peers bloquear y cuales no, es necesario seleccionarlos según si los peers remotos están interesados o no, y ordenarlos por tasa de transferencia. Se ha decidido implementar una clase que tenga las características de SortedCollection que permita ordenar los peers remotos por tasa de transfe-
53 rencia y que además ofrezca una serie de operaciones específicas de los obje- tos BtRemotePeer. Por ello, la clase BtRemotePeerCollection es subclase de SortedCollection. Estas colecciones de peers remotos tienen dos modos: Not- CompleteMode y CompleteMode. El primero mantiene los peer remotos ordenados por tasa de subida desde el punto de vista del peer remoto, es decir, los peers que más bloques comparten con el peer local están en las primeras posiciones de la co- lección. Este criterio de ordenación es necesario usarlo cuando el peer local todavía no tiene todas las piezas del torrent. Sin embargo, cuando ya tiene todas las piezas es necesario ordenarlos por tasa de bajada. Como el peer local ya no descarga ninguna pieza, solo puede guiarse por cuanto descargan los peers remotos de él. El segundo modo se corresponde con esta última situación. La forma de establecer un modo u otro es con los métodos setCompleteMode y setNotCompleteMode. Adicionalmente también dispone de otros métodos que permiten seleccionar o descartar los peers según varios criterios que los propios nombres de los métodos in- dican claramente como selectAccepted, selectAcceptsMe, selectInterested, selectPieceOwnersOf:, selectSeeders. . . Dos de estos métodos son útiles, por ejemplo, cuando el peer local necesita seleccionar a qué peers puede pedir bloques de una determinada pieza. Tal cosa se puede conseguir con la siguiente instrucción. remotePeers selectAcceptsMe selectPieceOwnersOf: pieceIndex. Primero selecciona los peers remotos que lo tienen desbloqueado mandando el mensaje selectAcceptsMe a remotePeers. Y después, de entre esos, selecciona aquellos que poseen la pieza con índice pieceIndex. Otro método útil es ensureAcceptFirst:, que recibe un entero n y se asegura de que los primeros n peers remotos de la lista estén desbloqueados por el peer local y que el resto estén bloqueados. Este método se usa en el algoritmo de bloqueo. Los métodos doHave: y doCancel:, por ejemplo, recorren toda la lista y envían un mensaje have y cancel a cada peer, respectivamente. El primero se utiliza cuando hay que comunicar a cada peer remoto que el peer local ha descargado y validado una pieza nueva. Y el segundo se utiliza en el End Game cada vez que hay que enviar un cancel a todos los peers a los cuales se ha enviado un request repetido. Precisamente en esta última tarea, hay otro método de BtRemotePeerCollection implicado, que es selectWhoIHaveRequested:, el cual recibe un BtBlockRequest y devuelve aquellos peers de la colección a los cuales el peer local ha pedido ese bloque. En el siguiente trozo de código se puede ver cómo se realiza esta tarea combinando este último método con doCancel:. blockRequest := BtBlockRequest pieceIndex: index offset: begin length: length. (remotePeers selectWhoIHaveRequested: blockRequest) doCancel: blockRequest Primero selecciona los peers a los que ha enviado el mensaje request repre- sentado por blockRequest, y después envía un mensaje cancel a cada uno de
54 ellos.
5.14. La clase BtTorrent La clase BtTorrent representa una tarea de descarga y compartición de un torrent concreto. Sus variables más significativas son las siguientes.
metainfo. Un objeto de la clase BtMetainfo. Indispensable para unirse a una red BitTorrent.
location. Un objeto FileReference que indica la ruta del disco donde se almacena el contenido del torrent.
fileCollection. Un objeto de la clase BtFileCollection para acceder físicamente a las piezas del torrent.
tracker. Un objeto BtHTTPTracker o BtUDPTracker dependiendo de la URL que aparezca en la clave announce de metainfo.
multitracker. Un objeto BtMultitracker cuyos elementos son los trackers que aparecen en la clave announce-list de metainfo.
bitfield. Un objeto BtBitfield para llevar el control de las piezas del torrent que tiene el peer local.
piecesOnNetwork. Un objeto BtPiecesOnNetwork para llevar el conteo de las piezas en el vecindario.
remotePeers. Un objeto BtRemotePeerCollection donde guardar y mane- jar las conexiones P2P.
temporaryPieces. Un objeto OrderedCollection cuyos elementos son ins- tancias de BtTemporaryPiece, donde guardar los bloques de las piezas a medio descargar.
Las instancias de BtTorrent también disponen de una serie de procesos que se encargan de realizar todas las operaciones necesarias en la descarga y compartición del torrent. Estas instancias disponen de tres operaciones básicas implementadas en los métodos start, stop y delete. El método start inicia la compartición del torrent y ejecuta todos los procesos necesarios durante su compartición. Para ello ejecuta el proceso starting, que inicia esos procesos y termina inmediatamente. El método stop detiene la compartición del torrent y elimina todos los procesos en ejecución iniciados por la instancia. Para ello ejecuta el proceso stopping, que ejecuta el método terminateProcesses y se asegura de comunicar al tracker que
55 abandona la red. El método delete simplemente elimina los ficheros del torrent que se encuentran en el disco. En los subsiguientes apartados se explican todos los procesos implicados durante la compartición del torrent.
5.14.1. Proceso: Validación incial
Este proceso está definido en la variable initialChecking. Se ejecuta al iniciar el torrent y comprueba qué piezas ya están descargadas. El método principal de este proceso es checkPieces. BtTorrent>>checkPieces bitfield clearAll. 0 to: metainfo numPieces − 1 do: [ :index | | piece | piece := fileCollection readOffset: index ∗ metainfo pieceLength amount: (metainfo pieceLengthOf: index). piece ifNotNil: [ (SHA1 hashStream: piece readStream) = (metainfo sha1Of: index) ifTrue: [ bitfield set: index ] ] ] Este método primero pone todos los bits de bitfield a 0 y después com- prueba pieza por pieza si su resumen concuerda con el que aparece en metainfo. En caso afirmativo, pone su bit a 1. Para acceder a las piezas utiliza el objeto fileCollection.
5.14.2. Proceso: Tracker requesting
Este proceso está definido en la variable trackerRequesting y se encarga de determinar si es necesario realizar operaciones announce ya sea por que el peer local necesita más peers remotos a los que conectarse o porque se ha producido un evento determinado. Hace uso de los objetos tracker y multitracker. Su bloque de ejecución es el siguiente. [ self shouldAnnounce ifTrue: [ self doAnnounce ]. (Delay forSeconds: 1) wait ] repeat Este bucle primero comprueba si es necesario realizar una operación announce. En caso afirmativo, invoca el método doAnnounce.
56 BtTorrent>>doAnnounce self selectLastTracker. [ self selectNextTracker. self updateAnnounceRequest. self currentTracker announce ] doWhileTrue: [ self announceHasFailed ]. self moveCurrentTrackerToFirstInTier. self updateRemotePeers Este método recorre la lista del multitracker mientras ninguna petición obten- ga una respuesta satisfactoria. En cuanto la operación tiene éxito, mueve el tracker que ha respondido a la primera posición de su tier e invoca updateRemotePeers. Este último método se encarga de recuperar las direcciones IP y puertos de los peers remotos que se encuentran en la respuesta del tracker e intenta abrir cone- xiones con ellos (respetando el número máximo de conexiones simultáneas que se encuentra en la variable maxConnections). Los métodos selectLastTracker, selectNextTracker y moveCurrentTrackerToFirstInTier solo tienen efecto si el objeto metainfo tiene clave announce-list y si el torrent está usando el «modo multitrac- ker». El método currentTracker devuelve el objeto tracker o el tracker seleccionado de multitracker dependiendo del modo en que esté el torrent. La forma de gestionar el modo de interacción con el(los) tracker(s) es con los métodos supportMultitracker, setMultitrackerMode, setSingletrackerMode y isInMultitrackerMode.
5.14.3. Proceso: Choking
Este proceso está definido en la variable choking y se encarga de bloquear y desbloquear a los peers remotos según el algoritmo de bloqueo «ojo por ojo, diente por diente» que marca el protocolo. [ self updateChokingStatus. remotePeers doRestartMeasuringRates. (Delay forSeconds: 10) wait ] repeat
57 1 BtTorrent>>updateChokingStatus 2 candidates := remotePeers reject: [ :peer | peer isLucky ]. 3 candidatesThatDontCompete := candidates select: [ :peer | peer isInterested not or: [ peer isSnubber ] ]. 4 candidatesThatDontCompete ensureNotAccept. 5 competitors := candidates difference: candidatesThatDontCompete. 6 self isComplete 7 ifTrue: [ competitors setCompleteMode ] 8 ifFalse: [ competitors setNotCompleteMode ]. 9 max := competitors size min: maxPeersAccepted. 10 competitors ensureAcceptFirst: max El proceso invoca, cada 10 segundos, el método que actualiza el estado blo- queado/desbloqueado de los peers vecinos (updateChokingStatus). Este método primero selecciona los candidatos a ser bloqueados/desbloqueados descartando los peers que están desbloqueados de forma optimista en la línea 2. De estos, seleccio- na los que seguro no van a competir porque no están interesados en el peer local o le hacen snubbing, y son bloqueados si no lo estaban ya (líneas 3 y 4). En la línea 5 selecciona los peers que van a competir por ser desbloqueados calculando la diferencia entre los candidatos iniciales y los peers que no compiten. A conti- nuación, ordena la colección resultante dependiendo de la fase de compartición en que se encuentre el torrent (líneas 6-8). Después desbloquea los primeros max peers de la colección y el resto son bloqueados (líneas 9 y 10). Por último, el proceso pone a 0 las cantidades de octetos descargados y subidos de cada peer conocido para poder medir las tasas de transferencia de cada periodo de bloqueo/desbloqueo (remotePeers doRestartMeasuringRates).
5.14.4. Proceso: Optimistic Choking
Este proceso está definido en la variable optimisticChoking y se encarga de bloquear y desbloquear a los peers remotos según el algoritmo de bloqueo optimista que marca el protocolo. [ self updateLuckyPeer. (Delay forSeconds: 30) wait ] repeat
58 1 BtTorrent>>updateLuckyPeer 2 oldLuckyPeer := remotePeers detectLucky. 3 candidates := oldLuckyPeer 4 ifNil: [ remotePeers rejectAccepted ] 5 ifNotNil: [ remotePeers rejectAccepted add: oldLuckyPeer; yourself ]. 6 newLuckyPeer := [ candidates atRandom ] on: Error do: [ :ex | ex return: nil]. 7 oldLuckyPeer ~= newLuckyPeer 8 ifTrue: [ 9 oldLuckyPeer notAccept; isLucky: false. 10 newLuckyPeer accept; isLucky: true] El proceso invoca el método updateLuckyPeer cada 30 segundos. Este método primero selecciona los candidatos a ser desbloqueados de forma optimista (líneas 2- 5). Después selecciona aleatoriamente de entre los candidatos el nuevo peer que va a ser desbloqueado (línea 6). Si es diferente al antiguo, entonces éste es bloqueado y el nuevo desbloqueado (líneas 7-10).
5.14.5. Proceso: Tratamiento de mensajes entrantes
Este proceso está definido en la variable receiving y se encarga de tratar todos los mensajes entrantes de cada conexión. [ peersToDiscard := OrderedCollection new. remotePeers do: [ :peer | peer secondsSinceLastReceivedMessage > BtMessage connectionTimeOut ifTrue: [ peersToDiscard add: peer ] ifFalse: [ | message | message := peer nextReceivedMessage. message ifNotNil: [ self handleReceivedMessage: message remotePeer: peer ] ] ]. [ peersToDiscard isEmpty ] whileFalse: [ self discardRemotePeer: (peersToDiscard remove: peersToDiscard first) ] ]. Processor yield. true ] whileTrue En cada iteración del bucle, recorre la lista de peers remotos y trata el primer mensaje entrante de cada peer. En caso de que el peer local no haya recibido ni un solo mensaje durante los últimos 2 minutos (BtMessage connectionTimeOut) lo añade a una colección temporal de peers que serán descartados al final de la iteración. El método encargado de tratar los mensajes es handleReceivedMessage:remotePeer: que recibe un mensaje y un peer re- moto como parámetros. En función del tipo de mensaje, este método invoca a uno de los métodos restantes del protocolo handling received messages
59 (es un grupo de métodos dentro de la clase BtTorrent). Por ejemplo, si el mensaje recibido es un request, invoca handleReceivedRequest:remotePeer:, que accede a fileCollection para leer el bloque solicitado y lo añade a la cola de salida del peer (o conexión P2P) que lo ha solicitado con el método BtRemotePeer>>sendPiece:begin:block:
5.14.6. Proceso: Petición de bloques
Este proceso está definido en la variable requesting y se encarga de solicitar los bloques de las piezas a los peers remotos y de decidir la prioridad de las piezas a la hora de ser descargadas. En total, es capaz de usar 4 políticas de selección de piezas diferentes.
Rarest first Cuando se usa esta política, las piezas son seleccionadas con el méto- do rarestPiecesOnNetwork, que devuelve una colección de índices de piezas ordenada ascendientemente por número de ocurrencias en el vecindario. Most common first Cuando se usa esta política, las piezas son seleccionadas con el método mostCommonPiecesOnNetwork, que devuelve una colección de índices de piezas ordenada descendientemente por número de ocurrencias en la red. Lowest first Cuando se usa esta política, las piezas son seleccionadas con el mé- todo lowestPiecesOnNetworkGreaterThan:, que devuelve una colección de índices de piezas ordenada ascendientemente y mayores que el entero que recibe. Random Cuando se usa esta política, las piezas son seleccionadas con el método randomPiecesOnNetwork, que devuelve una colección de índices de piezas ordenada de forma aleatoria.
Todos los métodos nombrados arriba acceden al objeto piecesOnNetwork, que es el que mantiene el control de las ocurrencias de las piezas en la red. Y todos tienen en común que descartan las piezas sin ocurrencias o que el peer local ya tiene, ya que esas piezas no le interesan. Independientemente de las políticas de selección de piezas, los objetos BtTorrent pueden usar dos modos de descarga, cada uno con propósitos distintos.
Smart (BtTorrent>>setSmartMode). Este modo tiene como objetivo descargar el torrent de la forma más rápida posible. Este modo usa la política most common first mientras no se haya descargado 4 piezas. El objetivo es ma- ximizar las probabilidades de obtener las primeras piezas. Una vez tenga 4 piezas, entonces usa la política rarest first.
60 Streaming (BtTorrent>>setStreamingMode). Este modo usa durante toda la vida del torrent la política lowest first. Este modo está pensado para los torrents que, por algún motivo, tiene sentido acceder a algunas partes del mismo sin necesidad de que la descarga haya acabado previamente.
Cuando un peer tiene una o más piezas a medio descargar, la prioridad es acabar de completar esas piezas lo antes posible para así tener más piezas que compartir y, por tanto, mejores tasas de subida que permitan al peer local ser co- rrespondido (desbloqueado) por más peers. Un peer que mantiene muchas piezas a medio descargar provoca ineficiencia en la red puesto que ralentiza la velocidad de propagación de éstas. Por tanto, el proceso de petición de bloques siempre hace una selección previa de piezas a medio descargar cuyos bloques no han sido soli- citados por completo por el peer local; sus índices pueden obtenerse invocando el método BtTorrent>>halfwayNotFullRequestedPieces. Después hace la selec- ción «normal» que se use en cada momento, que depende del modo de descarga y de la fase en que se encuentre ésta. De forma totalmente independiente a las políticas de selección y los modos de descarga, este proceso también implementa la fase End Game. En cada iteración del bucle, si el torrent se encuentra en este modo, las políticas de selección y los modos de descarga dejan de tener efecto y simplemente se solicitan todos los bloques restantes de todas las piezas a todos los peers remotos que las tengan. Hemos visto cómo este proceso selecciona las piezas que va a intentar descargar, pero falta ver cómo solicita los bloques de las piezas que ha seleccionado a los peers remotos que las tienen. El método broadcastRequestMissingBlocks: recibe una colección de índices de piezas, y solicita todos los bloques de esas piezas (que el peer local no tiene) a todos los peers remotos que los tienen. Este método es el que se invoca cuando el torrent se encuentra en la fase End Game. El método requestMissingAndNotRequestedBlocksOf: recibe una colección de índices de piezas y solicita todos los bloques de esas piezas (que el peer local no tiene) y para los que no hay una solicitud pendiente en la red. En este caso, el método asegura que no habrán dos solicitudes pendientes en la red para el mismo bloque. Este método es el que se invoca cuando el torrent no se encuentra en la fase End Game. Todos los métodos de las políticas de selección, independientemente del orden en que seleccione las piezas, tienen en común que devuelven los índices de todas las piezas restantes que no tiene el peer local. Esto significa que si no se pone ningún límite al número de peticiones de bloque salientes sin responder, supone un problema porque nada más empezar la descarga del torrent, todos los bloques serán solicitados. Teniendo en cuenta que un torrent de 1 GiB con piezas de 512 KiB y bloques de 16 KiB tiene 65536 bloques, el peer local envía 65536 peticiones en cuanto todas las piezas estén disponibles en el vecindario (hecho de lo más común puesto que con la existencia de un solo seeder se cumple esta situación). Esto
61 supone que por cada conexión de la que el peer local descargue, habrá muchas peticiones salientes sin responder. Esto supone un problema porque en caso de recibir un choke, la inmensa mayoría de estás peticiones no serán respondidas (como marca el protocolo) desperdiciando mucho ancho de banda. Para evitar este problema, este proceso hace dos cosas:
Limitar el número de peticiones sin responder por conexión a 20.
Equilibrar el número de peticiones sin responder entre conexiones. Cuando hay que pedir un determinado bloque y hay más de un peer remoto para elegir, se elige el que tenga menos peticiones pendientes.
Esta estrategia tiende a la situación en que todas las conexiones de las que el peer local está descargando alcancen el número máximo de peticiones pendientes permitidas.
5.15. La clase BtLocalPeer La clase BtLocalPeer es subclase de BtPeer. Representa la aplicación BitTorrent y su función es almacenar objetos BtTorrent para gestionarlos y recibir todas las conexiones P2P entrantes. Las principales variables de esta clase son las siguientes.
torrents. Un objeto OrderedCollection para almacenar instancias de BtTorrent.
receiverSocket. Un objeto Socket sobre TCP para recibir conexiones en- trantes.
Como esta clase representa la aplicación BitTorrent, es conveniente que solo pueda existir una instancia de esta clase dentro de Pharo-Smalltalk (lo que se conoce en inglés como singleton pattern). Para ello se ha sobrescrito el método constructor new de la superclase, que asegura que no se instanciará un nuevo objeto si ya existe otro previamente. En tal caso, devuelve ese objeto, como se puede ver en su implementación: BtLocalPeer class>>new instances := self allInstances. ^ instances ifEmpty: [ super new ] ifNotEmpty: [ instances first ] Cuando hay que añadir un nuevo torrent a la colección torrents, hay que esta- blecer en el nuevo torrent el identificador y el puerto que está usando la instancia de BtLocalPeer antes de añadirlo a la colección. De esto se encarga el método BtLocalPeer>>addTorrent:, como se ve en el siguiente trozo de código.
62 BtLocalPeer>>addTorrent: aTorrent (torrents includes: aTorrent) ifFalse: [ aTorrent id: id; port: port. torrents add: aTorrent ] La forma de iniciar y detener los torrents es accediendo a ellos con la in- terfaz estándar de torrents (que es una OrderedCollection) y usar los méto- dos BtTorrent>>start y BtTorrent>>stop, respectivamente. Además, también existe el método BtTorrent>>isActive que permite saber si el torrent en cues- tión está trabajando o no. La instancia única de BtLocalPeer ejecuta dos procesos que se inician con el método BtLocalPeer>>start. Uno se encarga de recibir las conexiones TCP entrantes, y el otro se encarga de establecer el número máximo de conexio- nes permitidas a cada torrent de la colección torrents. En cambio, el método BtLocalPeer>>stop se encarga de detener los procesos y detener todos los to- rrents que gestiona. Ambos procesos se explican en los siguientes apartados.
5.15.1. Proceso: Escucha de puerto
Este proceso se encuentra en la variable de instancia listening, y se encarga de invocar constantemente el método receiveConnection, que se encarga de escuchar el puerto usado por la aplicación y recibir las conexiones TCP entrantes que el peer local recibe durante la compartición de los torrents que gestiona.
1 BtLocalPeer>>receiveConnection 2 remotePeer := self waitForConnectionFor: 1. 3 remotePeer ifNotNil: [ 4 [ torrent := self giveHandshake: remotePeer. 5 torrent addRemotePeer: remotePeer . 6 ] forkAt: Processor userBackgroundPriority 7 ]. El método receiveConnection primero escucha el puerto que usa la aplica- ción BitTorrent durante un segundo. Si se ha producido un intento remoto de conexión, entonces el método waitForConnectionFor: devuelve un nuevo objeto BtRemotePeer que encapsula el SocketStream creado a partir del Socket de la nueva conexión remota, como puede verse en su implementación: BtLocalPeer>>waitForConnectionFor: seconds newSocket := receiverSocket waitForAcceptFor: seconds ifTimedOut: [ nil ]. ^ newSocket ifNil:[ nil] ifNotNil: [ (BtRemotePeer on: (SocketStream on: newSocket)) debug: debug ]
63 Otra vez de vuelta en receiveConnection, el método giveHandshake: recibe el peer remoto como parámetro y se encarga de realizar el handshake, y devuelve el objeto BtTorrent de la colección cuyo info_hash concuerda con el recibido durante el handshake. La conexión es rechazada si
alguna parte del handshake no es correcta,
el objeto BtLocalPeer no tiene ningún torrent con el info_hash del hands- hake o
el torrent al que va dirigido la conexión ha alcanzado el número máximo de conexiones.
Por último, el nuevo objeto BtRemotePeer es añadido al objeto torrent con el método BtTorrent>>addRemotePeer:. Para poder recibir y tratar otras conexiones TCP cuanto antes, una vez se ha recibido una nueva conexión, el resto de las instrucciones se ejecutan en un proceso nuevo (líneas 4-6) para volver a invocar waitForConnectionFor: inmediatamente. Y, así, receiverSocket puede seguir recibiendo conexiones entrantes. Como se puede ver, la instancia de BtLocalPeer solo recibe conexiones en- trantes y delega su gestión en los torrents que corresponda de forma que cada torrent es responsable de su propio conjunto de conexiones. Sin embargo, esta dependencia de los torrents en BtLocalPeer solo se da con las conexiones entran- tes. Cuando es el peer local el que inicia una conexión con un peer remoto, es la instancia de BtTorrent la responsable de hacerlo sin necesidad de que intervenga BtLocalPeer, ya que dispone del método BtTorrent>>connectTo:, que recibe un objeto BtRemotePeer y establece una conexión en una dirección IP y un puerto determinado.
5.15.2. Proceso: Gestión de torrents
Este proceso se encuentra en la variable de instancia managing, y se encarga de repartir las conexiones que puede mantener cada torrent que gestiona. La aplica- ción BitTorrent, representada por la instancia única BtLocalPeer, tiene un límite de conexiones impuesto en la variable maxConnections que no puede ser sobre- pasado por la suma de conexiones de los torrents. Esta limitación es necesaria para evitar sobrecargar el sistema. Para respetar este límite, invoca el método updateConnectionsPerTorrent cada segundo, cuya implementación se puede ver a continuación.
64 1 BtLocalPeer>>updateConnectionsPerTorrent 2 remaining := maxConnections. 3 activeTorrents := torrents select: [ :torrent | torrent isActive ]. 4 numTorrents := activeTorrents size. 5 connectionsPerTorrent := maxConnections quo: numTorrents. 6 activeTorrents do: [ :torrent | torrent maxConnections: connectionsPerTorrent ]. 7 remaining := maxConnections rem: numTorrents. 8 index := 1. 9 [ remaining > 0 and: [ index <= numTorrents ] ] 10 whileTrue: [ 11 (activeTorrents at: index) modifyMaxConnectionsBy: 1. 12 remaining := remaining − 1. 13 index := index + 1 ]
Primero selecciona los torrents de la colección que están activos (línea 3), y después asigna el número de máximo de conexiones permitidas a ca- da torrent de forma equitativa (líneas 6-13). Entonces, cada instancia de BtTorrent se encarga internamente de respetar esta restricción con el método BtTorrent>>reduceExcessOfRemotePeers, que es invocado cada vez que se in- voca BtTorrent>>maxConnections:. BtTorrent>>maxConnections: anInteger maxConnections := anInteger. self reduceExcessOfRemotePeers
5.15.3. Justificación de la necesidad de BtLocalPeer
Podría ser deseable que los torrents ni siquiera necesitaran a BtLocalPeer para recibir conexiones entrantes siguiendo el principio de que cada objeto sea respon- sable de las funciones que le corresponden. De esta forma, BtTorrent se encargaría completamente de gestionar todas sus conexiones y BtLocalPeer no intervendría en absoluto. En tal caso, cada torrent tendría su particular instancia de Socket (como el objeto receiverSocket de BtLocalPeer) para escuchar sus conexiones TCP entrantes. Lamentablemente, existe una limitación técnica que lo hace invia- ble. No es posible tener varios sockets escuchando en el mismo puerto y conseguir que cada conexión entrante la trate el socket del torrent al que va dirigida. Supo- niendo que técnicamente fuera posible, también existiría un inconveniente que no haría esta opción tan deseable. Teniendo en cuenta que las aplicaciones BitTorrent conviven con muchas más en el sistema, no sería «justo» acaparar tantos puertos como torrents se estuvieran compartiendo. Además, existe un argumento de peso a favor de la existencia de BtLocalPeer. Sin la existencia de un objeto capaz de contener varios objetos BtTorrent no es posible imponer un límite de conexiones global para evitar sobrecargar el sistema.
65 Por estos motivos, la decisión tomada ha sido implementar la clase BtLocalPeer, que representa a toda la aplicación BitTorrent.
6. Planificación
6.1. Planificación inicial
El proyecto se planificó para ser presentado en el turno de junio, comenzando el 28 de marzo (después de finalizar el GEP) y finalizando el 15 de junio, una semana antes de la fecha límite para entregar la memoria. El proyecto se dividió en cuatro tareas principales, las cuales se corresponden con las implementaciones de los diferentes prototipos previstos inicialmente:
Prototipo 1 La aplicación BitTorrent implementa bencoding, lee y genera fiche- ros .torrent, y puede comunicarse con trackers y peers remotos (que imple- menten cualquier otra aplicación BitTorrent válida).
Prototipo 2 La aplicación BitTorrent puede acceder físicamente a los torrents. La aplicación puede detenerse y reanudarse sin necesidad de volver a descargar las mismas piezas. La aplicación implementa un algoritmo de bloqueo y de selección de piezas. La aplicación puede mantener múltiples conexiones con peers remotos a la vez.
Prototipo 3 La aplicación puede gestionar varios torrents a la vez. Puede ges- tionar los directorios de descarga y limitar el ancho de banda utilizado.
Prototipo 4 (y final) La aplicación BitTorrent implementa DHT. En concreto, Mainline DHT, especificado en BEP5.
Se programó una reunión de seguimiento al finalizar cada prototipo. Además, en las tareas de los prototipos 2 y 4, que son las más largas, se programaron dos reuniones adicionales alrededor del 50 % de su realización. Solo se dispuso de un programador, por lo que no hubo posibilidad de paralelizar la programación de las tareas, resultando en una programación estrictamente secuencial. La reunión del Hito de seguimiento se programó para el 6 de mayo. En la tabla 2 se pueden ver las fechas de inicio y fin de las tareas previstas inicialmente, y en la figura 14 el correspondiente diagrama de Gantt.
66 Nombre Duración Inicio Fin Hito inicial 0d 28/03/2015 28/03/2015 Prototipo 1 10d 28/03/2015 06/04/2015 Reunión seguimiento 0d 06/04/2015 06/04/2015 Prototipo 2 30d 07/04/2015 06/05/2015 Reunión seguimiento 0d 21/04/2015 21/04/2015 Informe seguimiento 0d 29/04/2015 29/04/2015 Hito seguimiento (Reunión Director) 0d 06/05/2015 06/05/2015 Prototipo 3 10d 07/05/2015 16/05/2015 Reunión seguimiento 0d 18/05/2015 18/05/2015 Prototipo 4 30d 17/05/2015 15/06/2015 Reunión seguimiento 0d 29/05/2015 29/05/2015 Límite seguimiento turno junio 0d 29/05/2015 29/05/2015 Límite turno junio 0d 29/05/2015 29/05/2015 Reunión seguimiento 0d 15/06/2015 15/06/2015 Límite entrega memoria 0d 21/06/2015 21/06/2015 Periodo lectura 5d 29/06/2015 03/07/2015
Tabla 2: Planificación de las tareas
67 Figura 14: Diagrama de Gantt del proyecto
68 6.2. Modificaciones a la planificación inicial
La planificación inicial tuvo que modificarse dejando de implementar el BEP5 (DHT) y retrasando la presentación del proyecto al turno de octubre debido a los siguientes motivos:
Se tuvieron que implementar varios BEP inicialmente no previstos, que a priori no se consideraron necesarios por no estar especificadas en el BEP3 (el núcleo de BitTorrent), pero, de facto, totalmente necesarios para el funcio- namiento de la aplicación. Estas ampliaciones fueron los BEP23 (información de contacto compacta de los peers), BEP12 (multitracker) y BEP15 (trackers UDP).
El software, al ser una aplicación compleja y distribuida, fue necesario más tiempo del previsto para adquirir un conocimiento en profundidad del fun- cionamiento de Smalltalk, muy distinto a los lenguajes de programación y herramientas usados durante el transcurso del Grado.
7. Presupuesto y sostenibilidad
7.1. Identificación de recursos y estimación de costes
Los recursos humanos han constado de una sola persona, que ha desempeñado las funciones de Jefe de Proyecto, diseñador/programador y probador. Se ha estimado un sueldo de 40AC la hora. La impresión de la memoria se ha estimado en 10AC por copia. El consumo eléctrico del equipo de trabajo se ha calculado haciendo uso de los sitios web especializados http://www.pcsilencioso.com y http://www.extreme.outervision.com, que calculan el coste de forma precisa según el hardware del equipo. El consumo de la conexión a Internet se ha estimado convirtiendo AC/mes a AC/hora. La fuen- te usada han sido las facturas de los últimos meses previos a la realización del proyecto.
69 Unidades Precio Información de la unidad Tiempo (horas) Total Prototipo 1 1 40AC Programador. Sueldo a la hora 80AC 3200AC Prototipo 2 1 40AC Programador. Sueldo a la hora 240AC 9600AC Prototipo 3 1 40AC Programador. Sueldo a la hora 80AC 3200AC Prototipo 4 1 40AC Programador. Sueldo a la hora 240AC 9600AC Impresión de la memoria 3 10AC 30AC Costes directos 25600AC Consumo eléctrico 0.032AC Por hora. Ordenador encendido 8h/dia durante 3 meses 720 23.04AC Consumo ADSL 0.042AC Por hora. 30AC/mes = 0.042AC/h 2160 90.72AC Costes indirectos 113.76AC Contingencia (CD + CI × 0.15) 3857.06AC Reimpresión de la memoria 3 10AC Probabilidad = 0.2 6AC Imprevistos 6AC Presupuesto 29576.82AC
Tabla 3: Presupuesto
7.2. Viabilidad económica
Desde el punto de vista económico, el proyecto es totalmente viable. Solo se ha requerido una persona y un equipo de trabajo para desarrollar la aplicación. Supo- niendo que el objetivo del proyecto fuera comercial, el mercado sería global puesto que cualquier usuario con un equipo portátil o de sobremesa modesto puede par- ticipar y beneficiarse de las redes BitTorrent. Si comparamos las posibilidades potenciales de venta con la poca cantidad de recursos utilizados para desarrollar la aplicación, el proyecto es altamente rentable.
7.3. Impacto social y ambiental
La aplicación desarrollada tiene claramente ventajas e inconvenientes muy marca- dos. La principal ventaja de BitTorrent es la evolución tecnológica respecto a las redes centralizadas o cliente-servidor. Los dos principales puntos fuertes de este tipo de redes son la escalabilidad y la robustez. Mientras las redes cliente-servidor pueden colapsar llegado a cierto número de participantes, las redes BitTorrent pue- den escalar teóricamente de forma infinita ya que la carga de trabajo se reparte de forma homogénea entre todos los peers. Su naturaleza descentralizada tam- bién las hace robustas ya que no existe un punto vulnerable como con las redes cliente-servidor. Gracias a estos avances tecnológicos los usuarios pueden inter- cambiar ficheros con una seguridad muy alta de que ningún agente externo podrá impedirlo. Otra posible utilidad de la aplicación que puede ser beneficiosa para la sociedad es la de herramienta ilustrativa para la enseñanza del funcionamiento de BitTorrent o el P2P en general. Gracias a herramientas gráficas de Pharo desarrolladas por la comunidad, sería posible adaptar la aplicación sin demasiado esfuerzo para que mostrara gráficamente el funcionamiento de BitTorrent con un propósito didáctico. El principal inconveniente de BitTorrent se produce cuando se explotan sus
70 características tecnológicas para intercambiar ficheros protegidos con derechos de autor como pueden ser películas, series, videojuegos. . . Desde el punto vista ambiental, la aplicación no va a aumentar las emisiones de CO2 de una forma que pueda tenerse en cuenta, puesto que no van a encenderse muchos más ordenadores en el mundo solo para ejecutar esta aplicación, sino que los usuarios normalmente la pondrán en marcha cuando tengan su equipo personal encendido por otros motivos ajenos al intercambio de ficheros. Así que se puede afirmar que la aplicación no perjudica el medio ambiente a una escala que merezca la pena considerar.
8. Conclusiones
Al finalizar el proyecto, la aplicación BitTorrent desarrollada es totalmente funcio- nal. Cualquier usuario puede unirse a cualquier red BitTorrent con facilidad. La aplicación ha sido diseñada e implementada de forma que cualquier programador de la comunidad Pharo-Smalltalk pueda entender fácilmente su funcionamiento gracias a un lenguaje claro y altamente expresivo. También se ha conseguido re- presentar virtualmente dentro de Smalltalk la naturaleza de BitTorrent. Por tanto, Los objetivos generales del proyecto se han cumplido. Se ha implementado el BEP3 (núcleo de BitTorrent) y otras ampliaciones que han acabado siendo necesarias como los trackers UDP (BEP15) y el uso de multi- tracker (BEP12). Debido a esto y al hecho de tener que desarrollar una aplicación compleja y distribuida en un sistema muy diferente a todos los lenguajes y herra- mientas utilizadas hasta ahora como ha sido Smalltalk, no ha sido posible imple- mentar la DHT (BEP5). Aún así, la implementación de DHT se encuentra bastante avanzada en el momento de la entrega del proyecto, como se puede comprobar en el paquete BitTalk-DHT.
9. Posibles ampliaciones
Por supuesto, la primera ampliación propuesta sería acabar de implementar DHT (BEP5). Al ser la primera librería sobre BitTorrent para Pharo-Smalltalk, el rendimiento de la aplicación no ha sido una prioridad, si no que la prioridad ha sido obtener una aplicación funcional. Una posible mejora sería mejorar la eficiencia y la velocidad de descarga para llegar a ofrecer un rendimiento parecido al de otras aplicaciones BitTorrent más populares. Actualmente no existen más BEP con estatus final o aceptado que no estén im- plementados en esta aplicación. Pero existen algunos BEP con estatus de borrador
71 que se usan como si fueran definitivos. Si hubiera que elegir dos, probablemente uno sería el que sustituye la comunicación peer-to-peer sobre TCP por el protocolo uTP (BEP29), que funciona sobre UDP. De esta forma, todas las comunicacio- nes serían sobre UDP, que es a lo que tiende BitTorrent desde hace años. El otro sería implementar superseeding (BEP16), que ayuda al primer peer del la red a distribuir más rápidamente las piezas. La aplicación, actualmente tiene un límite fijo impuesto al número de peticio- nes sin responder por cada conexión. Una posible mejora sería implementar una estrategia más inteligente que adaptara en tiempo real este límite a la velocidad de subida del peer remoto. Si esto se hiciera correctamente, se maximizaría la ve- locidad de descarga y el cuello de botella dependería exclusivamente o bien de la aplicación, o bien de la velocidad de bajada de la conexión a Internet del peer local, pero no de un límite impuesto que desperdicia la potencia del peer remoto.
72 Adenda
A. Manual de usuario
A.1. Instalación de Pharo
Pharo es compatible con OS X, Windows y GNU/Linux. La versión 3.0 puede descargase de http://files.pharo.org/platform/Pharo3.0-mac.zip, http://files.pharo.org/platform/Pharo3.0-win.zip, o http://files.pharo.org/platform/Pharo3.0-linux.zip, según corresponda. Una vez descargado el fichero .zip, se extrae en un directorio cualquiera y ya estará listo para ejecutarlo.
A.2. Ejecución de Pharo
Una vez dentro del directorio «pharo3.0», solo hay que ejecutar el fichero «pharo» (la extensión depende del sistema operativo). Cuando lo hagamos, si solo existe la imagen por defecto (el fichero «Pharo3.0.image»), ejecutará esa imagen en la máquina virtual directamente. Si existen otras imágenes a parte de la menciona- da, entonces aparecerá una ventana ofreciendo la posibilidad de elegir la imagen deseada, como se puede ver en la figura 15.
73 Figura 15: Selección de imagen en Pharo (Linux Mint)
A.3. Importación de la librería
Una vez dentro de Pharo, hacemos clic izquierdo en el fondo de escritorio de Pharo para abrir el menú global (ver figura 16) y seleccionamos Monticello Browser. En la ventana del Monticello hacemos clic izquierdo en +Repository, después seleccio- namos HTTP como tipo de repositorio y copiamos y pegamos entre las comillas simples de location la siguiente URL (ver figura 17). http://smalltalkhub.com/mc/BitTalkDev/BitTalk/main
74 Figura 16: Menú global de Pharo
Figura 17: Añadir un repositorio HTTP público a Pharo
Aparecerá otra ventana con las versiones del repositorio; seleccionamos la más reciente con el ratón y hacemos clic izquierdo en Load. Después de pocos segundos
75 el repositorio ya estará en el sistema. Ahora es recomendable guardar la imagen. Como es típico en las aplicaciones de escritorio, se puede sobrescribir la imagen con la opción Save del menú global, o guardar la imagen con un nombre distinto con la opción Save as. . . . Llegados a este punto, se pueden explorar las clases de la aplicación BitTorrent abriendo el System Browser a través del menú global. Las clases de la aplicación se encuentran en el paquete BitTalk.
Figura 18: Exploración del paquete BitTalk en Pharo
A.4. Pruebas A.4.1. Pruebas unitarias
Todas las pruebas unitarias se encuentran en el paquete BitTalk-Tests. La forma más rápida de ejecutar todas las prueba de una vez es, con el System Browser abierto, hacer clic con el botón secundario del ratón sobre el paquete de pruebas y hacer clic en Run tests. . . (ver figura 19). También es posible ejecutar cada una de las clases Bt...Test por separado haciendo clic en el botón que aparece a la izquierda del nombre de la clase en cuestión. Y si se quiere ser aún más preciso, también se pueden ejecutar los métodos de prueba por separado haciendo clic en el botón a la izquierda del nombre, como con las clases.
76 Figura 19: Captura de imágen de Pharo mostrando cómo ejecutar todas las pruebas unitarias de una vez.
A.4.2. Prueba global
Para probar la aplicación lo que hay que hacer es abrir un Workspace con el menú global y pegar el siguiente código dentro de él. Una vez el código esté seleccio- nado con el ratón, hacemos clic derecho y presionamos Do it (ver figura 20). A la variable metainfoString hay que asignarle la cadena de caracteres de la ruta del fichero .torrent (pueden descargarse de http://www.legittorrents.info), y a la variable locationString hay que asignarle la cadena de caracteres de la ruta donde se quiere almacenar el torrent.
77 metainfoString:=’/path/name.torrent’. locationString:=’/path/sharing’. torrent:= BtTorrent metainfoFileString: metainfoString locationString: locationString. localPeer:= BtLocalPeer start. localPeer addTorrent: torrent. localPeer torrents last start; inspect. La última instrucción abre una ventana con la que se puede inspeccionar en tiempo real el estado interno del torrent que acabamos de añadir. Entre otras cosas, podemos ver el conjunto de peers remotos que conoce el peer local (e inspeccio- narlos a ellos también), el BtBitfield, los trackers, etc. En definitiva, se pueden examinar todos los objetos descritos en el apartado de diseño e implementación.
Figura 20: Ejecución del código de la prueba global
Si se quiere detener el torrent sin detener la aplicación, simplemente hay que acceder a él y detenerlo con localPeer torrents last stop. Sin embargo, si lo que se quiere es detener la aplicación en su totalidad, solo hay que detener al peer local con
78 localPeer stop. , y la aplicación se encargará de detener todos los torrents de su colección.
79 Acrónimos
BBS Bulletin Board System. 15, 16
BDFL Benevolent Dictator for Life. 8
BEP BitTorrent Enhancement Proposal. 8, 9, 21, 69, 71
CAN Content Addressable Network. 13
DHT distributed hash table. 9, 13, 14, 18, 21, 22, 66, 69, 71
DMCA Digital Millennium Copyright Act. 17
DSL domain-specific language. 9
ESUG European Smalltalk User Group. 8
FTP File Transfer Protocol. 15, 21, 83, 86
GUI graphical user interface. 10
HTTP Hypertext Transfer Protocol. 19–21, 31, 32, 34, 75
I2P Invisible Internet Project. 14
IP Internet Protocol. 20, 31, 33, 42, 57, 64, 86
IRC Internet Relay Chat. 15, 16, 84
ISP Internet service provider. 18
LAN local area network. 22
MPAA Motion Picture Association of America. 19
P2P peer-to-peer. 7, 8, 10–15, 17–19, 21, 42–47, 55, 60, 62, 70, 81, 82, 84, 85
PEX Peer Exchange. 21, 22
RIAA Recording Industry Association of America. 17–19
TCP Transmission Control Protocol. 21, 34, 42, 50, 62–65, 72, 83, 86
80 TFG Trabajo de Fin de Grado. 7
UDP User Datagram Protocol. 21, 31, 34–38, 45, 69, 71, 72
URI Uniform Resource Identifier. 21
URL Uniform Resource Locator. 19, 20, 28, 32, 40, 55, 74, 84 uTP uTorrent Transport Protocol. 21, 22
Glosario
A|C|D|E|F|M|P|R|S|T|W
A aplicación BitTorrent programa que ejecutan los peers en una red BitTorrent. Normalmente se usa de forma incorrecta la expresión «cliente BitTorrent» para referirse a este tipo de aplicaciones. Las redes que usan BitTorrent son P2P, donde no existen los roles exclusivos de cliente y servidor. 1, 2, 7, 9, 21, 23, 26, 29, 31, 34, 40, 62–64, 66, 71, 76 ataque de denegación de servicio ataque a un sistema que provoca la inaccesibilidad de un servicio o recurso por parte de los usuarios legítimos por el consumo del ancho de banda de la red de la víctima o sobrecarga de los recursos computacionales del sistema de la víctima. 14
B backtracking algoritmo que busca todas las soluciones posibles (o una parte) de algunos problemas computacionales. 6, 12, 14 bencoding sistema de codificación diseñado para BitTorrent. Los tipos de datos sopor- tados son cadenas de caracteres, enteros, listas y diccionarios. 26, 37, 45, 66
81 Benevolent Dictator for Life título que se otorga a ciertos individuos de la comunidad de desarrolladores de software de código abierto, normalmente fundadores de proyectos que tienen la última palabra en disputas o discusiones dentro de la comunidad. 8, 80 BitTorrent protocolo diseñado para el intercambio de ficheros sobre una red P2P que se usa para distribuir gran cantidad de información por Internet. 1, 2, 6–9, 13, 14, 18–23, 26, 28–32, 34, 40, 42, 43, 50–52, 55, 62–66, 69–72, 76, 80–84, 86 BitTorrent Enhancement Proposal propuesta de ampliación de alguna parte de BitTorrent, que especifica una nueva funcionalidad o comportamiento de la red o de los actores implicados. 8, 80 bloque parte contigua de tamaño variable de una pieza. 25, 39, 43, 44, 47, 49, 50, 52–55, 60–62 Blu-ray formato de almacenamiento digital para discos ópticos. 15 Bulletin Board System servidor que permite a usuarios conectarse al sistema usando un terminal. Una vez dentro del sistema, el usuario puede realizar una serie de operacio- nes como subir y descargar software y ficheros, leer noticias y boletines, e intercambiar mensajes con otros usuarios vía correo electrónico y chat. 15, 80
C churn término usado para referirse a la situación donde los peers de la supercapa se unen y abandonan la red con mucha frecuencia. 11, 13, 14 cliente-servidor arquitectura de red que consiste en un sistema de alto de rendimiento, el servidor, y varios sistemas habitualmente de menor rendimiento, los clientes. El servidor es el único proveedor de servicios. Los clientes solo consumen servicios sin compartir ninguno de sus recursos. 2, 10, 11, 17, 70, 83, 84
82 courier group grupo de personas que distribuyen entre topsites el material publicado por los release groups. 15, 16, 86
D distributed hash table sistema distribuido que ofrece un servicio de búsqueda similar al de las tablas de hash, en el que cada nodo de la red es responsable del mantenimiento de una parte de todas las asociaciones
E enjambre conjunto de peers participantes de una red BitTorrent. 6, 20, 21, 25, 41, 50, 51, 83
F fibrillation situación que se da cuando un peer es bloqueado y desbloqueado sucesiva- mente con tanta frecuencia que provoca ineficiencia en el enjambre. 50 fichero .torrent fichero que contiene los metadatos del torrent. 20, 21, 24, 26, 29, 34, 40, 66, 77, 86 File Transfer Protocol protocolo para tranferir ficheros de un ordenador a otro sobre una red TCP con arquitectura cliente-servidor. 15, 80 FlashXP cliente FTP que admite transferencias entre cliente y servidor, y entre servi- dor y servidor. 15 flooding algoritmo de encaminamiento en el que cada nodo reenvía cada paquete recibido por todas sus conexiones menos por la que ha llegado. 12, 14 free rider actor que consume recursos pero no sirve ninguno a cambio. 50
83 I
Internet Protocol protocolo de comunicación principal de Internet Protocol Suite. 20, 80 Internet Protocol Suite conjunto de protocolos de comunicación usado en Internet. 84, 86 Internet Relay Chat protocolo de la capa de aplicación que permite la comunicación en forma de texto. Funciona sobre una arquitectura cliente-servidor. Los clientes IRC son programas que los usuarios pueden instalar en su sistema. Estos clientes se comunican con el servidor para transferir mensajes a otros clientes. IRC está principalmente diseñado para la comunicación grupal en foros de discusión, llamados canales, pero también permite mensajería privada e intercambio de ficheros. 15, 80 Invisible Internet Project supercapa P2P de Internet que proporciona cierto grado de anonimato a sus usuarios. 14, 80
L leecher peer que no tiene todas las piezas del torrent. 19, 20, 22, 33, 35
M metadatos información esencial para el funcionamiento de una red BitTorrent. Identifi- can de forma única a los torrents. Entre otras cosas, contienen la dirección URL del tracker, la colección de ficheros que forman el torrent, el tamaño de las piezas y el resumen de cada una de ellas, necesario para verificar su integridad. 20, 24, 26, 28, 29, 83, 84 metainfo metadatos. 29, 30, 34, 40
P
84 peer nombre con que se denominan los nodos de una red con arquitectura P2P. La traducción al castellano sería «igual» o «par». 6, 7, 11–13, 17–25, 29, 31–35, 37–44, 46–64, 66, 69, 70, 72, 78, 81–86 peer-to-peer arquitectura de red donde los participantes comparten parte de sus recursos hardware (tiempo de procesador, espacio de almacenamiento, ancho de ban- da, dispositivos. . . ). Estos recursos son necesarios para proveer el servicio que ofrece la red y son accesibles directamente por cualquier participante sin necesidad de otra entidad mediadora. Los participantes de estas redes son tanto proveedores como consumidores de servicios. 2, 6, 7, 10, 11, 72, 80 pieza parte en que se divide un torrent. 19, 20, 24, 25, 28–30, 41–44, 47, 49–56, 60, 61, 66, 72, 82, 84, 85
R
RAR formato de archivo que admite compresión de la información, recuperación ante errores y partición de la información. 16 release group grupo de personas que publica material con derechos de autor en los topsites. 15, 83, 86
S seeder peer que tiene todas las piezas del torrent. 19, 20, 22, 33, 35, 61 singleton pattern patrón de diseño que limita el número de instancias de una clase a uno. 62 supercapa capa de aplicación virtual, o red lógica, que ofrece servicios normalmente no disponibles en la capa física subyacente. 11–14, 19, 82, 84
T
85 topsite término usado por la warez scene para referirse a los servidores FTP clan- destinos, altamente secretos y con gran ancho de banda utilizados por los release groups y courier groups para almacenar y distribuir ficheros. 15, 16, 19, 83, 85 torrent Puede referirse a:
1. colección de ficheros que se comparten en una red BitTorrent. 2. fichero .torrent.
. 6, 19, 20, 24, 25, 28–30, 32, 33, 35, 42, 43, 49, 50, 52–58, 60–66, 77–79, 83–85 tracker servidor que coordina la distribución de los ficheros en una red BitTorrent. 19–22, 25, 28, 31–35, 37–41, 43, 45, 55, 57, 66, 69, 71, 78, 84 Transmission Control Protocol protocolo perteneciente a la capa de transporte del Internet Protocol Suite. TCP ofrece un sistema fiable y ordenado de entrega de secuencias de bytes entre aplicaciones que se comunican sobre la red IP. 21, 80
U
Usenet sistema mundial distribuido de debate y discusión. Sus usuarios pueden leer y enviar mensajes (llamados articles o posts, y colectivamente llamados news) según categorías, conocidas como newsgroups. Los servidores redistribuyen los mensajes a otros servidores creando múltiples copias. 16, 17, 19
V vecindario conjunto de peers remotos que conoce el peer local. 24, 25, 50–53, 55, 60, 61
W
86 warez scene comunidad clandestina y oculta al gran público, especializada en la distri- bución de material con derechos de autor, incluyendo programas y series de televisión, películas, música, videoclips, videojuegos, aplicaciones, ebooks y pornografía. 6, 15, 16, 86
87 Referencias
[1] Bandara, H. M N Dilum y Anura P. Jayasumana: Collaborative applications over peer-to-peer systems-challenges and solutions. Peer-to-Peer Networking and Applications, 6(3):257–276, 2013, ISSN 19366442.
[2] Clarke, Ian, Oskar Sandberg, Brandon Wiley y Tw Hong: Freenet: A distribu- ted anonymous information storage and retrieval system. Designing Privacy Enhancing . . . , páginas 46–66, 2001. http://link.springer.com/chapter/ 10.1007/3-540-44702-4_4.
[3] Cohen, Bram: Incentives Build Robustness in BitTorrent. Works- hop on Economics of PeertoPeer systems, 6:68–72, 2003. http: //citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.1911& amp;rep=rep1&type=pdf.
[4] Goldberg, A y D Robson: Smalltalk-80: the language and its implementation. Addison-Wesley, 1983, ISBN 0-201-11371-6.
[5] Kent, B: Smalltalk Best Practice Patterns. Prentice Hall PTR, Upper Saddle River, 1997, ISBN 013476904X.
[6] King, Sunny y Scott Nadal: PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. Ppcoin.Org, 2012. http://ppcoin.org/static/ ppcoin-paper.pdf.
[7] Lua, Eng Keong Lua Eng Keong, J. Crowcroft, M. Pias, R. Sharma y S. Lim: A survey and comparison of peer-to-peer overlay network schemes. IEEE Communications Surveys & Tutorials, 7(2), 2005, ISSN 1553-877X.
[8] Malkhi, Dahlia, Moni Naor y David Ratajczak: Viceroy: A Scalable and Dy- namic Emulation of the Butterfly. Proceedings of the 21st annual ACM sym- posium on Principles of distributed computing, páginas 183–192, 2002.
[9] Maymounkov, Petar y D Mazieres: Kademlia: A peer-to-peer information sys- tem based on the xor metric. First International Workshop on Peer-to-Peer Systems, páginas 53–65, 2002, ISSN 3540441794. http://link.springer. com/chapter/10.1007/3-540-45748-8_5.
[10] Nakamoto, Satoshi: Bitcoin: A Peer-to-Peer Electronic Cash System. Consul- ted, páginas 1–9, 2008, ISSN 09254560. http://s.kwma.kr/pdf/Bitcoin/ bitcoin.pdf.
88 [11] Ratnasamy, S, P Francis, M Handley, R Karp y S Shenker: A Scalable Content Addressable Network. Informe técnico TR-00-010, University of Berkeley, CA, 2000. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.60. 3260.
[12] Rowstron, A y P Druschel: Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. IFIPACM International Conferen- ce on Distributed Systems Platforms Middleware, 11(November 2001):329– 350, 2001. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1. 1.28.5987.
[13] Schollmeier, Rüdiger.: A definition of peer-to-peer networking for the classifi- cation of peer-to-peer architectures and applications. Proceedings First Inter- national Conference on Peer-to-Peer Computing, 2001.
[14] Shen, Xuemin, John Buford, Heather Yu y Mursalin Akon: Handbook of peer- to-peer networking. Springer US, New York, 2010, ISBN 978-0-387-09750-3.
[15] Stoica, Ion, Robert Morris, David Liben-Nowell, David R. Karger, M. Frans Kaashoek, Frank Dabek y Hari Balakrishnan: Chord: A scalable peer-to-peer lookup protocol for Internet applications. IEEE/ACM Transactions on Net- working, 11(1):17–32, 2003.
[16] Wang, Liang y Jussi Kangasharju: Measuring large-scale distributed systems: Case of BitTorrent Mainline DHT. En 13th IEEE International Conference on Peer-to-Peer Computing, IEEE P2P 2013 - Proceedings, páginas 1–10, 2013, ISBN 978-1-4799-0515-7.
[17] Zhao, Ben Y., Ling Huang, Jeremy Stribling, Sean C. Rhea, Anthony D. Joseph y John D. Kubiatowicz: Tapestry: A resilient global-scale overlay for service deployment. IEEE Journal on Selected Areas in Communications, 22(1):41–53, 2004.
89