Geek & Roll

… O por qué el .torrent debe morir y dar paso al siguiente escalón evolutivo.

Recientemente The Pirate Bay, uno de los sitios con más cojones que existe en el planeta, anunció que relegaría el uso de archivos .torrent y se enfocaría principalmente en los llamados magnet links. Sus argumentos son muy válidos, e inmediatamente se dejaron venir olas de desinformación. Que si The Pirate Bay habían doblado las manitas y cedieron ante la presión de alguna organización. Que si SOPA. Que si PIPA. Que si es el fin del mundo como lo conocemos, o por lo menos del P2P facilitado por el protocolo Bittorrent.

Nada de eso puede estar más alejado de la verdad. Como todo, el uso de la Distributed Hash Table (DTH) y Magnet Links sobre los ya tradicionales archivos .torrent tiene sus ventajas y desventajas que es lo que precisamente vamos a explorar aquí.

Durante mis estudios de maestría, hice investigación en el tema de las redes inalámbricas de sensores (WSN por sus siglas en Inglés) y cómo múltiples dispositivos de bajo poder de procesamiento, podían colaborar para cubrir una área extensa. Esto tiene retos interesantes muy bien documentados en la literatura, pero una de las cosas que más llamó mi atención es la diseminación de datos entre los pares que forman la red. Estamos hablando de una red creada impromptu, sin infraestructura previa, que necesita compartir datos de manera continua. Tal vez definirla como una red P2P tenga sentido, pero quiero dejar al lado las connotaciones negativas que arrastra este término, similar a lo que sucede con “Pirata” o “Nazi”.

En aquella época pensaba en una WWW descentralizada. La arquitectura actual de Internet ha pasado la prueba de escalabilidad: millones de nodos conectados, compartiendo millones y millones de paquetes. Además, cualquiera puede entrarle al juego, conectarse y compartir. Sin embargo uno de los servicios clave de Internet, o por lo menos de los más populares, es completamente centralizado. Estoy hablando de la Web y protocolos relacionados. La “simplicidad” en la arquitectura de la Web es tanto su mayor bendición, como su talón de Aquiles ya que la hace altamente vulnerable a distintos ataques. Los ataques de negación de servicio (DoS, infames ahora gracias en parte al colectivo Anonymous) son un ejemplo claro, aunque en este caso la solución no está al nivel de la implementación de la Web, sino dos capas más abajo (o 3 si consideran HTTP como capa de aplicación o de presentación) en la capa de transporte.

Otro ataque menos complejo (y menos efectivo) es el que enmarca la referida como ley “SOPA”. Esto no es más que eliminar el registro DNS de un sitio determinado. Una vez que esta eliminación sea diseminada en la mayoría de los servidores DNS que forman la World Wide Web, prácticamente nadie podría acceder al sitio atacado via URL. El sitio seguiría existiendo y sería accesible via IP, solo el nombre que hace referencia al sitio dejaría de funcionar. Una Web descentralizada resolvería estos problemas; una Web que no dependiera de un solo servidor central para operar. Donde fuera posible hacer privadas secciones de la Web, o conectarlas a la nube para formar parte de la Web pública. Donde todo, desde la resolución de nombres hasta las peticiones HTTP se basen en un protocolo P2P y no en un servidor central. Una Web imposible de censurar, controlada por todos y por nadie. Una Web apoyada en redes centradas al contenido como fue propuesto por Ted Nelson e investigado por Van Jacobson.

Lo que tenemos actualmente
Internet no fue concebido para una Web de tal naturaleza. En sus orígenes, Internet fue concebido para habilitar la transferencia de datos no solo entre computadoras incompatibles, sino también entre distintas redes de computadoras. Esta red de redes proporciona un medio adecuado para la comunicación de datos entre dos computadoras que se encuentran, posiblemente, distribuídas alrededor del mundo. Sin embargo, con el uso masivo que se le da a Internet actualmente, el problema básico que se trató de solucionar con la arquitectura de Internet ha cambiado. El nuevo modelo de uso de Internet impone otro tipo de retos a la arquitectura unicast y multicast sobre la que está basado, caracterizándose por:

• Contar con un gran número de clientes autónomos comunicándose entre sí (hasta el punto de agotar las direcciones IPv4).
• Variar el número de clientes en cualquier momento (Móviles, Tablets, Consolas y Refrigeradores, todos conectándose a la red).
• Contar con una distribución geográfica amplia.
• Contar con patrones de interacción entre los clientes dinámicos e impredecibles (como Twitter cuando hay un desastre natural o un evento inesperado).
• Generar tráfico en grandes cantidades.

Ejemplos de aplicaciones que utilizan a Internet con este nuevo modelo incluyen aplicaciones Web populares, redes de intercambio de información, agregadores de noticias, redes inalámbricas de sensores, descubrimiento de servicios y juegos masivos multijugador, entre otras. ¿Qué tienen en común estas aplicaciones? que el flujo de comunicación se determina por los intereses específicos de quien recibe información, contrario a lo que sucede actualmente en Internet, donde se utiliza una dirección específica asignada por quien envía los datos.

Van Jacobson propone una red en donde cualquier dispositivo que pueda mover datos, y tenga datos válidos, tenga la oportunidad de atender la petición. En dicha red se eliminan dos cosas:

1. La rigidez de la pila TCP/IP. Si un punto final de la comunicación entre A y B es eliminado, todos los puntos intermedios se reconfiguran automáticamente para seguir moviendo datos.
2. El flujo de datos se determina por intereses y no por direcciones IP. Esto ayuda a eliminar la congestión por peticiones muy populares. Una petición muy popular puede ser el disco mas reciente de la banda en el último grito de la moda, o dos millones de script kiddies atacando a la víctima de la semana de Anonymous.

Actualmente existen aplicaciones que implementan algunas de las ideas expuestas en la teoría de redes centradas al contenido. Estas aplicaciones crean una capa sobre la red existente (denominada overlay) y proporcionan servicios orientados al contenido, utilizando como transporte a la pila TCP/IP. Uno de estos overlays es precisamente Bittorrent.

Bittorrent como overlay centrado al contenido
Bittorrent es un protocolo de aplicación, es decir forma parte de la capa 6 en el modelo OSI. Bittorrent sirve para la distribución de archivos de gran tamaño sin la necesidad de un repositorio central. ¿Suena conocido? Los clientes inician una transferencia conectándose a un servidor central, que les comparte información de otros clientes que se encuentran compartiendo el mismo archivo. Una vez obtenida esta información, los clientes se conectan entre si para iniciar la transferencia.

Analicemos un poco más de cerca cómo se inicia una transferencia:

1. El cliente descarga un archivo (el .torrent) que contiene metadatos sobre los archivos a transferir, y la localización de uno o más servidores a los cuales el cliente se debe conectar para obtener información sobre otros clientes descargando el mismo archivo.
2. El cliente lee el .torrent y se conecta a los servidores ahí listados (el tracker).
3. Al conectarse a un tracker, este envía información sobre otros clientes interesados en el mismo archivo.
4. El cliente recibe la información enviada por el tracker, y se conecta a los otros clientes interesados en el mismo archivo.
5. Los clientes comienzan a compartir el archivo sin intervención del tracker.

El overlay creado por los nodos participantes en una transferencia Bittorrent forman una arquitectura híbrida descentralizada, en donde el tracker facilita la comunicación entre los distintos clientes. Una vez que varios clientes se conectan entre si, se elimina la necesidad del tracker siempre y cuando los clientes mantengan su conexión. Si eliminas el tracker, ningún otro cliente puede unirse a la red formada por los clientes conectados (llamada swarm o enjambre).

Ya podemos determinar dos puntos críticos de Bittorrent:

1. La dependencia del tracker. Sin este servidor central, otros clientes no pueden unirse al enjambre y no pueden iniciarse otras transferencias.
2. La dependencia del .torrent para obtener información del tracker. Este es un punto crítico ya que los archivos deben ser encontrados y descargados por los clientes para iniciar así una transferencia. Ya se ha probado (por medio de demandas a The Pirate Bay y otros) que el simple hecho de indexar y facilitar archivos .torrent es peligroso (legalmente hablando) aún cuando en tu servidor no se encuentre ningún archivo con copyright. Tener metadatos (pero no los datos mismos) de localizaciones de servidores con clientes que se encuentran descargando archivos con copyright, es suficiente para hacerte acreedor a una demanda. No se diga ya hostear un tracker…

Mejorando Bittorrent. Magnet Links y Distributed Hash Table.
Eliminando los dos puntos críticos expuestos anteriormente, Bittorrent se convierte en un overlay completamente descentralizado. ¿Pero cómo pueden encontrarse los clientes entre ellos, sin la existencia de un servidor central que los coordine? Tanto los Magnet Links como la Distributed Hash Table (DHT) juegan un papel determinante en la descentralización de Bittorrent.

El concepto de una DHT no es nuevo, su investigación y desarrollo fue motivado en parte por las redes P2P como GNUtella y Napster. Dos aproximaciones muy distintas al mismo problema:

• Los clientes de Napster, al conectarse enviaban al servidor una lista con los archivos compartidos. Las búsquedas se realizaban en el servidor único y dirigían al autor de la búsqueda hacia el nodo que contenía el recurso compartido.
• Los clientes de GNUtella, en vez de enviar la búsqueda a un único servidor central, utilizaban un mecanismo de flooding o “inundación” que enviaba la búsqueda a todos los nodos de la red. Esto evita el servidor central, pero es mucho menos eficiente.

Bittorrent adoptó una DHT para sustituir o complementar el tracker. De hecho, algunos clientes Bittorrent permiten al usuario evitar el uso del tracker, y solo recibir clientes que vengan directamente de la DHT. La implementación de la DHT de Bittorrent es basada en Kademlia. Los nodos que forman el overlay se comunican utilizando UDP y son asignados un ID, y es este mismo ID el que es utilizado por la red para localizar el valor buscado (usualmente un hash de un archivo). Las búsquedas son restringidas a O(log(n)) nodos, por aquello de la eficiencia.

Todo bien, pero aún es necesario que un cliente se conecte al enjambre formado por la DHT. A esto se le conoce como proceso de inicialización o bootstrap. En esta fase, el cliente necesita conocer la dirección IP de alguno de los nodos participantes, quien se encargará de diseminar el ID del nuevo nodo al resto de la red.

Aún eliminando la necesidad del tracker con la DHT, queda el inconveniente del proceso de inicialización, para lo cual el .torrent sigue siendo necesario. Para solucionar este inconveniente se desarrollaron los Magnet Links. Un Magnet Link en realidad es un esquema URI nuevo. ¿Un que? Un esquema URI se refiere a la estructura para nombrar recursos de manera uniforme. Seguramente se habrán topado con direcciones como file:, news:, http:, ftp:, mailto:, entre otros. Bueno pues esto forma parte de un esquema de nombramiento regulado por la IANA, y tiene una estructura fija.

Entonces, el esquema URI Magnet forma lo que llamamos Magnet Links, que son utilizados principalmente para referirnos a recursos disponibles para ser descargados de redes P2P. Un Magnet Link, contrario a un link regular, apunta a un archivo basado en su contenido o metadatos y no en donde se encuentra el archivo. Si encontramos similitudes con el contenido de un archivo .torrent, no es ninguna casualidad. Al igual que la investigación y el desarrollo de las DHT, el esquema Magnet fue desarrollado como parte de otros esquemas URIs utilizados en los proyectos eDonkey2000 (esquema ed2k:) y Freenet (esquema freenet:).

Un Magnet Link contiene uno o mas parámetros, que le indican al cliente de donde iniciar la descarga. Por ejemplo, un link puede contener el nombre del archivo, su tamaño en bytes, el hash del archivo, un link Web tradicional que se considere aceptable para descargar el archivo, palabras clave para realizar búsquedas del archivo, la dirección de un tracker Bittorrent, entre otras cosas. Ventajas del uso de magnet links sobre archivos .torrent es que pueden ser compartidos simplemente copiando y pegando el text en correos o mensajería instantánea, en comparación de los archivos .torrent en donde se tiene que enviar el archivo para iniciar la transferencia.

The Pirate Bay elimina el uso de .torrent
Lo que nos lleva finalmente a la decisión de The Pirate Bay de dejar de ofrecer archivos .torrent como fuente de información principal (los .torrent siguen estando disponibles, pero no son la opción por defecto) para conectarse a un enjambre, favoreciendo a los Magnet Links.

La decisión anterior les ahorra mucho ancho de banda ya que no se tienen que descargar archivos .torrent. Además los Magnet Links son mas difíciles de bloquear, y aún no se ha probado en la corte que tener Magnet Links en una página sea algo ilegal (aunque seguramente no tardarán en probarlo).

Pero mucho más importante que esto es el paso que se da hacia un overlay completamente descentralizado, en donde no sea necesario el tracker ni el uso de archivos .torrent por los usuarios (en realidad el protocolo Bittorrent depende de los archivos .torrent, pero usando Magnet Links los usuarios no tienen que descargar el archivo manualmente). Si, sigue existiendo la necesidad de un directorio en donde se puedan buscar Magnet Links, y el bootstrap es mas lento, pero el ahorro de ancho de banda, además de descentralizar la localización del .torrent justifica su uso.

Conclusión
Como vemos, es posible actualmente usar Bittorrent para compartir archivos de gran tamaño de manera descentralizada. Esto tiene la gran ventaja de ser menos propenso a ataques de censura (como SOPA y PIPA) y permite distribuir la carga de distribución entre los mismos clientes, en vez de en un solo servidor central.

En mi opinión, el futuro de la red es hacia una red completamente descentralizada, centrada al contenido. Ya sea implementada a nivel físico, o como un overlay sobre la existente. Las redes centradas al contenido se presentan como una evolución a la estructura tradicional de las redes actuales. No es que la solución actual (el protocolo TCP/IP) no sirva, sino que el problema original ha cambiado. La necesidad actual es una forma de diseminar datos y no de simplemente tener conversaciones entre dos puntos finales. La diferencia entre diseminación y conversación es que una diseminación puede ser uno a uno, uno a muchos o muchos a muchos. Claramante se observa que una conversación es solamente un caso especial (uno a uno) de una diseminación.

Una red centrada al contenido como la que propone Jacobson soluciona, por diseño, muchos de los problemas con los que se enfrenta Internet actualmente (siendo la censura uno de ellos). El hecho de que los datos mismos puedan ser validados y no se dependa de la seguridad del canal por el cual fueron transmitidos permite una diseminación oportunista, es decir, una red en donde cualquier dispositivo capaz de mover datos puede y será utilizado. La diseminación oportunista haría prácticamente imposible situaciones como la negación de servicio por parte de proveedores de Internet, o la eliminación de la neutralidad de Internet. Los usuarios se vuelven administradores de sus propios canales de comunicación, ya que pueden solicitar solo aquel contenido que le interesa, y la prioridad de éste (deseo obtener el correo electrónico de mi lugar de trabajo, y el noveno juego de la serie mundial de béisbol). La habilidad de definir solamente el contenido de interés elimina ataques del tipo negación del servicio ya que los altos volúmenes de tráfico no solicitado nunca llegarían a los canales de comunicación de la víctima si éste no lo solicita explícitamente.

A lo largo de la historia, hemos visto como la guerra impulsa a la ciencia. Por un Internet libre, abierto, neutro y sin censura.