Trabajo Práctico N 2 y 3 P2P File Sharing Protocols

FACULTAD DE INGENIERÍA UNIVERSIDAD DE BUENOS AIRES 66.48 Seminario de Redes de Computadora Trabajo Práctico N 2 y 3 P2P File Sharing Protocols Integrantes: - Santiago Boeri (79529) - Hernán Castagnola (79555) - Christian Picot (80297) - Tomás Shulman (84050) Profesores: - Marcelo Utard - Pablo Ronco

Introducción El objetivo de este trabajo consiste en estudiar un tipo de arquitectura muy difundida a nivel global para compartir archivos entre usuarios. Se ha dejado de lado el modelo más típico de redes: cliente servidor para enfocarse en el de pares o más conocido como P2P (peer to peer). Conceptos de File Sharing Muchos sistemas de red proporcionan la capacidad de acceder a archivos en máquinas remotas. Existe una gran variedad de enfoques para lograrlo dependiendo de las metas a optimizar. Básicamente se pueden agrupar en dos esquemas: un acceso compartido en línea (distributed file system DFS) y un acceso mediante copiado de archivo completo. El primero, un sistema de archivos distribuido, permite a varios clientes acceder en forma concurrente a un sólo archivo. Tanto su procesamiento como cualquier alteración que se le hace se efectúan directamente en el host remoto. Se dice que está integrado con los archivos locales y que su acceso es transparente (una de las ventajas más visibles). Por esta razón no hay necesidad que el usuario invoque un programa cliente especial. El mismo S.O. se encarga que el usuario no note la diferencia entre trabajar sobre un archivo local o uno accedido por este método. Ejemplos de este enfoque: Netware de Novell, SMB (Server Message Block hoy renombrado como CIFS) de Windows, NFS de Sun Microsystems, Samba de Linux. La idea básica es montar o integrar un sistema de archivos remoto en la máquina local. Una gran desventaja es justamente la concurrencia: si dos o más clientes quieren modificar un mismo archivo en el host fuente se crea un conflicto de prioridades y permisos cuya resolución depende de la implementación del protocolo en el S.O. del host remoto. El otro enfoque es aquel que permite acceder a un archivo mediante una copia transferida desde la máquina remota. Los cambios o manipulaciones que se hacen sobre el archivo sólo inciden en la copia. La gran ventaja de este enfoque es que el procesamiento, al realizarse localmente, es mucho más eficiente y rápido que si se lo hace sobre el archivo de manera remota. Alguna de las desventajas son que el usuario debe invocar un programa de propósito especial no necesariamente integrado al S.O. y tanto el cliente como la fuente deben ponerse de acuerdo respecto a autorizaciones y formatos de datos (ASCII, binario...). Ejemplos típicos de este paradigma en la arquitectura cliente servidor son el FTP, el TFTP, el SCP (secure copy mediante SSH) y el SFTP (SSH FTP). P2P es un modelo de red donde los archivos son compartidos mediante su transferencia íntegra. Por lo tanto entra dentro de este último paradigma: el de copiado de archivo. Redes P2P Son aquellas redes que no tienen clientes ni servidores fijos, sino una serie de nodos que se comportan simultáneamente como clientes y como servidores de los demás nodos de la red. Contrastando así con el modelo cliente-servidor en el cual uno y otro no pueden cambiar de roles. Cualquier nodo puede iniciar, detener o completar la transacción. La eficacia de los nodos en el enlace y transmisión de datos puede variar según su configuración local

(firewall, NAT, routers, etc.), velocidad de proceso, disponibilidad de ancho de banda de su conexión a la red y capacidad de almacenamiento en disco. Este paradigma de IPC (Inter Process Comunication) es un concepto novedoso frente a otros protocolos vistos con anterioridad como ser http. En ellos la identificación de un recurso se hace mediante una URL (una secuencia de caracteres con cierto formato para nombrar documentos mediante su ubicación física). En cambio en las redes P2P el direccionamiento y encaminamiento de los contenidos se basa en la descripción del propio recurso en lugar de su ubicación. En las redes P2P, de un momento a otro, un recurso puede ser alojado, movido o replicado en cualquier otro nodo de la red. Frente a este dinamismo característico se busca privilegiar ciertas propiedades para optimizar la transferencia: Escalabilidad. Dada la magnitud de usuarios, que se espera que tenga, es deseable que cuantos más nodos estén conectados a una red P2P mejor sea su funcionamiento aumentando los recursos totales del sistema y acentuando la cooperación entre entidades. Diferente es el caso en una arquitectura de cliente servidor con un sistema fijo de servidores, en los cuales la adición de más clientes puede significar una transferencia de datos más lenta para todos los usuarios. Robustez. La naturaleza distribuida de estas redes incrementa la robustez en caso de haber fallos en la réplica excesiva de los datos hacia múltiples destinos. Descentralización. Por definición las redes P2P son descentralizadas y todos los nodos son iguales de modo que no existan nodos con funciones especiales y que por ende sean imprescindibles para el funcionamiento de la red. Sin embargo, como se verá en los protocolos a analizar, la realidad demuestra lo contrario algunas redes P2P no cumplen esta característica: Napster, edonkey2000 o BitTorrent. Costos repartidos entre usuarios. Se comparten o donan recursos a cambio de recursos. Según la aplicación de la red 1, los recursos pueden ser archivos, ancho de banda, ciclos de proceso o almacenamiento de disco. Tener un gran repositorio distribuido utilizando P2P es mucho más barato y fácil de gestionar, que centralizar todo el almacenamiento en un gran servidor. El precio que el protocolo debe pagar es el de ser capaz de gestionar una red totalmente descentralizada en la que cualquier ordenador puede ser a su vez un servidor. Desafíos a resolver en redes P2P Las redes P2P se enfrentan a un dilema importante por su característica de redes virtuales aplicativas (entiéndase como una red de nivel superior a IP). Una gran cantidad de nodos en Internet no disponen de una dirección IP fija y muchos datagramas deben sortear obstáculos creados a partir del uso de algún tipo de Firewall o del uso de NAT. Surgen algunas preguntas: cómo se encuentra un nodo que ya esté conectado a la red P2P y cómo se conectan los nodos sin dirección IP pública entre sí. Una solución habitual es establecer una conexión a un servidor (o servidores) inicial con dirección IP bien conocida que el programa P2P tiene almacenada. Este servidor se encarga de mantener una lista con las direcciones de otros nodos que están 1 P2P no sólo es File Sharing, Ejemplo Programa SETI@Home

actualmente conectados a la red. Se dice que estos servidores cumplen la función de punto de acceso al servicio. Frente al problema de conexión cuando los nodos no tienen dirección pública se suele usar un tercer nodo con la responsabilidad de ser un proxy de la conexión. Los dos nodos se conectan al proxy, y éste envía la información que llega de un extremo al otro. Cualquier nodo con una dirección IP pública puede ser escogido como proxy de una conexión entre dos nodos. Ejemplo de esto es muy usual en las redes de telefonía IP como Skype. Una vez lograda la conectividad extremo a extremo los clientes ya tienen información suficiente para intercambiar recursos con otros nodos ya sin intervención de los servidores iniciales. Sin embargo, surge un nuevo desafío conocido como visión global: cómo hacer para solicitar el recurso buscado entre todos los nodos de la red. Existen dos filosofías posibles (que pueden ser combinadas) para lidiar con este problema: La más comúnmente usada, pero que presenta mayor consumo de ancho de banda y problemas de escalado, es la difusión o broadcast a los nodos a los que está enganchado, donde cada nodo solicitante inunda la red solicitando el contenido deseado. Esta filosofía contempla mecanismos para evitar reenvíos infinitos y bucles (TTL). Otra alternativa es que los nodos fuentes se encarguen de mantener informados a los nodos enrutadores (entiéndase servidores), para que cuando algún contenido sea solicitado, sepan dónde se encuentra. Esta alternativa presenta múltiples formas de implementarse, donde se destaca la utilización de tablas de hash distribuidos 1 o técnicas de ordenamiento estructurado (autoordenamiento). Las redes P2P presentan un extremo dinamismo en escala, topología, contenido y carga por lo tanto estas propiedades de auto-ordenamiento cooperativo son deseables, e incluso necesarias. Entre los dos modelos antagónicos (cliente servidor y completamente distribuido) existe una serie muy variada de modelos con distribución jerarquizada, donde la idea es agrupar en niveles según la capacidad de contenidos de cada participante. Esta variante es la que proporciona mejor escalamiento, ya que distribuye mejor la carga tanto de proceso y el consumo de ancho de banda de comunicaciones. Una Red P2P utiliza alguno de los recursos que los nodos están dispuestos a compartir y/ o delegar: procesamiento, almacenamiento y transmisión. Redes P2P sin estructura y Redes P2P estructuradas Sobre la base de cómo los nodos, en estas redes aplicativas, se enlazan el uno al otro se las puede diferenciar como no estructuradas o estructuradas. Una red P2P no estructurada se forma cuando los enlaces se establecen arbitrariamente. Un peer que se une a la red puede copiar enlaces existentes de otro nodo y después formar sus propios enlaces. En dicho tipo de red, si un peer desea encontrar un recurso en ella, la petición tiene que recorrer toda la red para encontrar tantos peers como sea posible, para conseguir alguno que comparta ese dato. Una desventaja importante es que los requerimientos no pueden ser resueltos siempre: en especial aquellos recursos no muy 1 Un conjunto de claves entre los nodos que participan en una red, y son capaces de encaminar eficientemente mensajes al dueño de una clave determinada. Cada nodo es análogo a una celda de una tabla hash.

populares. Además como se mencionó en la página anterior hacer flooding demuestra no ser eficiente por su alto consumo de ancho de banda y problemas de escalado con resultados de búsqueda muy pobres. Las redes P2P estructuradas superan las limitaciones de redes no estructuradas manteniendo una tabla de hash distribuida (DHT) y permitiendo que cada peer sea responsable de una parte específica del contenido en la red. Estas redes utilizan funciones de hash distribuido y asignan valores a cada contenido y a cada peer en la red. Después siguen un protocolo global en la determinación de qué peer es responsable de qué contenido. Esta manera, siempre que un peer desee buscar ciertos datos, utiliza el protocolo global para determinar el peer responsable de esos datos y después dirige la búsqueda hacia al mismo. Topologías Redes Centralizadas Corresponde a la Primera Generación de P2P File Sharing. Las transacciones se hacen a través de un único servidor que sirve de punto de enlace entre dos nodos. Los clientes se identifican al ingresar a la red en el servidor central, informándole los archivos que comparten. Cuando un solicitante busca un contenido, lo hace en el servidor central, el cual conoce completamente los archivos compartidos reduciendo la búsqueda a una búsqueda local eficiente. Cuando una fuente cambia el contenido ofrecido o se desconecta de la red, también se informa al servidor central La entrega del archivo se hace directamente entre pares. Esta topología tiene varias limitaciones: la falta de escalabilidad de un sólo servidor, enormes costos en el mantenimiento y un alto consumo de recursos del servidor. Además todas las comunicaciones (como las peticiones y encaminamientos entre nodos) dependen exclusivamente de la existencia del servidor. Si por cuestiones legales se cierra el servidor, desaparece la red. El ejemplo más paradigmático de este enfoque es Napster. Redes Puras o totalmente descentralizadas Corresponde a la Segunda Generación de P2P File Sharing que plantea por primera vez la descentralización. No se basan en ningún tipo de gestionamiento central. Los nuevos nodos que se conectan lo hacen estableciendo un enlace con otro que ya está dentro de la red. El software se distribuye con una lista de nodos que se espera estén siempre conectados y se escoge alguno al azar. Un cliente cualquiera puede estar conectado a varios otros, y recibir conexiones de nuevos nodos formando una malla aleatoria no estructurada. Todas las comunicaciones son directamente de usuario a usuario con ayuda de un nodo (que es otro usuario) quien permite enlazar esas comunicaciones. Los contenidos no son publicados sino que los nodos solicitantes realizan búsquedas en sus pares conectados. Los pares que reciben las consultas en realidad actúan como nodos fuentes contestando al solicitante original si poseen el contenido buscado ó como nodos enrutadores volviendo a propagar la consulta a sus pares.

Redes P2P híbridas, semi- centralizadas o mixtas Este tipo de red se caracteriza por tener una especie de servidor central que cumple solo la función de hub administra enrutamientos y comunicación entre nodos pero sin saber la identidad de cada nodo y sin almacenar información alguna. El servidor no comparte archivos de ningún tipo a ningún nodo. Tiene la peculiaridad de funcionar tanto de esta manera y también, en caso de que el o los servidores que gestionan todo caigan, el grupo de nodos siga en contacto a través de una conexión directa entre ellos mismos Sólo los nodos son responsables de hospedar la información. Para encontrar un archivo, el solicitante hace un query al hub. El hub, al carecer de cualquier tipo de índice de archivos compartidos forwardea la solicitud a los pares conectados. La ventaja de esta arquitectura frente a la centralizada es que el servidor central Hub es mantenido por los usuarios y no por una autoridad central. Modelo distribución jerarquizada (redes Super Peer) Dentro de la tercera generación de redes P2P para compartir archivos, existe una variante conocida como redes Super-Peer. Las redes Super-Peer presentan un nivel de jerarquía: los nodos con pocos recursos de transmisión son solo fuente/ solicitantes (llamados clientes) y están conectados a un único Super-Peer. Los nodos Super-Peer son fuente/ ruteador/ solicitantes y forman entre sí una red completamente distribuida que funciona, en general, mediante la difusión de solicitudes de contenido a todos los nodos Super- Peer. Se realiza una agrupación sintáctica del contenido (basada en el nombre o CRC del archivo) ofreciéndole a los clientes una vista consolidada del sistema, en ningún caso existe colocación física del contenido.

Bittorrent Protocol El protocolo Bittorrent es un protocolo de transferencia de archivos entre hosts, utilizando la arquitectura p2p, más precisamente P2P Hibrido, ya que es necesario un servidor de metadata. El protocolo fue desarrollado por Bram Cohen. Se basa en la distribución inicial de metadata, contenida en recursos.torrent, acerca de los archivos que contiene el recurso y una dirección de un equipo llamado Tracker, que se encarga de la distribución de las direcciones de los peers. Glosario de Bittorrent Archivo.torrent: Archivo que contiene metadata con hashing de archivos del recurso y dirección del tracker. Peer: Cliente que interviene en el intercambio de recursos. Seed: Peer que tiene todo el recurso a intercambiar completo, ya sea por ser seeder inicial o por que ya completo la descarga. Leecher: Peer que esta bajando un recurso y todavía no lo completo. Swarm: Conjunto de todos los clientes que intervienen en el intercambio de un recurso. Tracker: Equipo que hace el seguimiento de los peers y los pedazos que tiene cada peer. También se llama a los sitios que proveen el servicio de posting de los.torrent. Scrape: Pedido de estadísticas al Tracker por parte de un cliente. DHT: Distributed hash table, Tabla distribuida de Hashes. Sistema de búsqueda descentralizado Metadata contenida en un recurso.torrent: Se basa en diccionarios codificados en Bencode, que contienen claves, entre las cuales están. announce El URL del tracker info Dentro de esta sección hay diferentes claves a analizar, una para cada archivo name, nombre propuesto del archivo o directorio piece length, El tamaño de cada porción del recurso. pieces, un string que contiene todos los hashes SHA1 concatenados de cada porción. length, el largo del recurso en bytes, si esta clave esta presente significa que el recurso es un solo archivo, files, una lista de los archivos contenidos en el recurso, aparece solamente si hay más de un archivo en el recurso. Contiene un diccionario con las siguientes claves: o length, el largo del recurso en bytes. o path, una lista que contiene los subdirectorios, el ultimo item es el nombre del archivo. Anatomía de una sesión de BitTorrent: a) El archivo ya esta disponible. Ya hay 1 o más seeds. El usuario interesado en descargar el archivo/paquete de archivos obtiene el archivo.torrent, por algún medio disponible (buscador, Tracker, etc).

Web Server.torrent Tracker Peer Nuevo Peer Descargando Seed El archivo puede ser descargado y posteriormente leído por el cliente o puede ser directamente cargado al cliente. El cliente analiza el metadata y genera cada archivo y la estructura de directorios. El cliente contacta al Tracker, a través de un GET HTTP, en donde envía la siguiente información a través de variables que se agregan al recurso del announce (?<variable1>&<variable2>: info_hash, SHA1 Hash de la clave info del torrent que se intenta bajar. peer_id, Una identificación del peer que se genera de manera aleatoria. ip, Parametro opcional, generalmente lo toma del header IP, también puede ser un nombre DNS. port, Puerto donde el peer escucha. uploaded, cantidad de datos subidos, codificado en ASCII downloaded, cantidad de datos bajados, codificado en ASCII left, cantidad de datos por bajar, codificado en ASCII, event, indica la ocurrencia de un evento, puede ser: started, completed, stopped. Se asocia a la acción tomada por el usuario en el software cliente, y con la configuración del mismo. Web Server Peer Nuevo 2 peer_id1, peer_id2, interval 1 Tracker GET / announce?info_hash=.. Peer Descargando Seed

El tracker responde con un diccionario codificado en Bencode similar al del metadata presente en el torrent. Si hay un error, se devuelve un string que explica la falla al usuario, visible en el cliente de Bittorrent. Si no hay un error, se devuelve un valor de interval que especifica el tiempo de actualización con el Tracker, y una lista de peers, que incluye: peer_id, ip, y port. Con esos datos ya se pueden iniciar conexiones directamente con los peers involucrados en la transferencia. Transferencia entre peers: Las conexiones entre peers son sobre TCP. Son simétricas y los datos van en cualquier dirección, llevan datos y señalización. La información de protocolar esta dividida solamente por las sesiones TCP y no tienen otro tipo de partición a nivel de aplicación. Una vez establecida la conexión TCP, el iniciador envía un handshake que contiene: -El decimal 19 y el string BitTorrent protocol -8 bytes reservados. -20 bytes del hash SHA1 del campo info. -20 bytes del peer_id Si el otro cliente responde con la información que le corresponde, queda establecida la conexión BitTorrent. Mensajes posteriores: Si el mensaje tiene tamaño cero, es un keep-alive. Si no, comienza con un byte que indica el tipo de mensaje según esta lista: 0 - choke 1 - unchoke 2 - interested 3 - not interested 4 - have 5 - bitfield 6 - request 7 - piece 8 - cancel 'choke', 'unchoke', 'interested', y 'not interested'. no tienen payload. Web Server Tracker info, peer_id A peer_id, info, bitfield peer_id, info, bitfield info, peer_id B bitfield exchange Peer Nuevo message exchange Peer Descargando Seed

Los peers comienzan a enviarse mensajes acerca de los pedazos del recurso que posee cada uno, llamados bitfield, en donde cada índice de bit corresponde a un pedazo del recurso a enviar. Un peer mantiene dos estados para cada relación entre peers, llamados interested y choked, codificados en el byte mencionado anteriormente. Si un peer esta choked (ahogado), no recibirá datos hasta que envíe una señal de unchoked. La transferencia de datos sucede cuando un peer esta interesado (interested) y el otro peer no esta ahogado (not choked). El estado de interesado debe estar actualizado en cada mensaje. Si no hay más partes que le interesen a un peer A de otro peer B, solo en los mensajes que envía A a B setea el bit de interested en 0. Las conexiones comienzan choked y not interested por defecto. Regularmente durante la transferencia, cada peer contacta al tracker actualizando su situación con las piezas que descargo y la cantidad de tráfico descargado y compartido. Cuando un peer termina una pieza, verifica el hash que viene dentro del.torrent. Si es correcto, envía un mensaje de HAVE como broadcast a todo el swarm, así el resto de los peers que no tienen esa pieza pueden descargarla de él y el seed original puede distribuir otras piezas con más prioridad. Cuando consigue todas las piezas, informa al tracker y se desconecta de todos los seeds, para convertirse en seed el mismo. Cuando un peer es seed inicial de un torrent, simplemente descarga el archivo.torrent, queda esperando conexiones entrantes y envía actualizaciones del tracker. Algoritmos de choking El choking se hace por varias razones. El control de congestión de TCP funciona de manera ineficiente cuando se envían datos por muchas conexiones a la vez. También permite que cada peer obtenga una buena y consistente velocidad de descarga. La implementación del algoritmo de choking depende de cada cliente en particular, pero se recomienda que: o Limite la cantidad de uploads simultáneos. o Evite cambios rápidos de estados (choked-not choked), llamados fibrillation. o Debe privilegiar y tener en cuenta los peers que comparten. o Debe probar con peers nuevos para verificar si puede obtener mejores conexiones. DHT Extensión del protocolo BitTorrent utilizado para conseguir nuevas fuentes sin depender del tracker. Cada peer se transforma en un tracker. Funciona sobre UDP. Basado en Kademlia, que crea una red virtual en la cual cada nodo se asocia a un número (Node ID), que se genera aleatoriamente. Existe el concepto de distance metric entre dos nodos. Se le aplica un XOR a los node IDs y se obtiene el valor. Cada peer tiene una tabla con las direcciones de algunos otros nodos (Routing Tables). Tienen en cuenta la distancia. Básicamente un peer consulta a otros en su tabla para verificar si tienen más peers que esten manejando ese torrent. Si tienen responden con la lista de peers, si no responden con algunas entradas de su tabla que tengan mayor probabilidad de tener ese torrent. Las consultas sobre esta red son: PING, FIND_NODE, GET_PEERS, ANNOUNCE_PEER

emule Introducción emule es una aplicación popular para compartir archivos, la cual esta basada en el protocolo edonkey. El protocolo emule cuenta con cientos de servers y millones de clients. Los clientes deben conectarse a un server para acceder al servicio de red. La conexión al server se mantiene abierta siempre que el cliente este en el sistema. El server trabaja en forma centralizada y no se comunica con otros servers. Cada cliente de emule esta preconfigurado con una lista de servers y una lista de archivos compartidos en el sistema local de archivos. Un cliente usa un simple conexión TCP para conectarse a un emule server, y así acceder a la red, adquirir información acerca de archivos deseados y clientes disponibles. El cliente también usa varios cientos de conexiones TCP a otros clientes que suelen subir y bajar archivos. Cada cliente emule mantiene una cola de uploads de sus archivos compartidos. Los clientes que deseen descargar se unirán al final de una cola y avanzaran gradualmente hasta alcanzar el tope de la cola para poder empezar a descargar un archivo. Un cliente también puede descargar pedazos de un archivo que aun no han sido completados. Finalmente emule extiende las capacidades del edonkey y permite a los clientes intercambiar información acerca de servers, otros clientes y archivos. Un server de emule no almacena archivos, actúa como un índice centralizado de información acerca del lugar de los archivos. emule emplea UDP para mejorar las capacidades del cliente sobre el server y otros clientes. La capacidad del cliente para enviar y recibir mensajes UDP no es obligatoria. Conexión cliente-servidor En el inicio el cliente se conecta usando TCP a un solo emule server. El server provee al cliente de un ID, la cual es valida solo a través de la conexione cliente-servidor, durante el tiempo de vida da esa conexión. Después de establecida la conexión, el cliente envía al server su lista de archivos compartidos. El server almacena la lista en su base de datos interna, que por lo general contiene cientos de miles de archivos disponibles y clientes activos. El cliente de emule también envía su lista a descargar que contiene los archivos que desea descargar. El servidor manda al cliente una lista de otros clientes que posean los archivos que el cliente conectado desea descargar. El cliente envía pedidos de búsqueda de archivos que serán respondidos con resultados de la búsqueda. Esta pregunta será respondida con una lista de fuentes (IP y puerto) de donde el interesado puede descargar el archivo. UDP se usa para comunicarse con otros servidores y no con el que esta actualmente conectado. El propósito de los mensajes UDP es mejorar la búsqueda de archivos, mejorar la búsqueda de fuentes y finalmente el keep alive (asegurarse que todos los servidores en la lista del cliente son validos). Conexión Cliente-Cliente Un cliente se conecta con otro cliente (fuente) para descargar un archivo. Un archivo es dividido en partes que mas adelante serán fragmentadas. Un cliente puede bajarse el mismo archivo de varios clientes adquiriendo diferentes fragmentos de cada uno de ellos.

Cuando dos clientes se conectan intercambian capacidad de información y después negocian el comienzo de la descarga. Cada cliente tiene colas de descarga y por cada archivo mantiene una lista de clientes que esta esperando descargar ese archivo. Cuando la cola de descarga de un cliente se vacía, un pedido de descarga probablemente será en un comienzo de la descarga (a no ser que el usuario que pide este banneado ).Cuando la cola de descarga no esta vacía, un pedido de descarga se agregara en la cola de la descarga. No empezara una descarga si no se garantiza 2.4k bytes/seg de transferencia en la descarga. Cuando un cliente completa una parte de la descarga no notifica al resto de que pueden removerlo de la cola simplemente rechazándolo cuando alcance el tope de la cola. emule emplea un sistema de créditos para incentivar uploads. Para prevenir imitaciones de usuarios emule asegura el sistema de crédito, usando RSA clave única encriptada. Los clientes pueden usar un set de mensajes no definidos por el protocolo edonkey, llamado extensión del protocolo. La extensión del protocolo es usada por el sistema de crédito, intercambio de información general (como la actualización de lista de servidores y fuentes) y para mejorar la performance enviando y recibiendo fragmentos de archivos comprimidos. El cliente emule usa mensajes UDP de manera limitada para chequear periódicamente el estatus de los clientes de su cola de uploads. Client ID El client ID es un identificador de 4 bytes y es provisto por el servidor después del handshake. El client ID es solo válido durante el tiempo de vida de la conexión TCP. Si el cliente recibe un high ID el mismo ID será asignado por cualquier otro servidor hasta que su dirección IP cambie. La client ID esta dividida en low ID y high ID. El servidor asignara a un cliente una low ID si este no puede aceptar conexiones entrantes. Tener una low ID restringe al cliente el uso de la red emule y puede resultar en el rechazo de una conexión a un servidor. Una high ID es concedida a un cliente, que permite libremente cualquier conexión TCP entrante a un puerto del host. Un cliente con high ID no tiene restricción en el uso de la red emule. Cuando un servidor no puede abrir una conexión TCP a un puerto de un cliente emule, el cliente recibirá una low ID. Esto pasara cuando el cliente use firewall que niega conexiones entrantes. Un cliente también puede recibir low ID en los siguientes casos: Cuando un cliente esta conectado a través de NAT o un proxy server Cuando el servidor esta muy ocupado (Causando que el tiempo de conexión expire) High ID es calculado de la siguiente manera. Asumiendo que la IP del host es X.Y.Z.W. la ID será X +2^8 * Y +2^16 *Z +2^24*W. Una low ID siempre es menor que 0X10000000. Un cliente con low ID no tiene una IP publica de la cual otro cliente puede conectarse, por eso todas las conexiones deben realizarse a través de un servidor emule. Esto incrementa el overhead del servidor y resulta generalmente en el rechazo por parte de los servidores a clientes con low ID. Tampoco un low ID puede comunicarse con otro cliente low ID que no este en su mismo servidor por que emule no soporta la conexión entre servidores. Para permitir a los clientes con low ID el mecanismo de callback, fue creado. Usando este mecanismo un cliente con high ID puede preguntar a través de un servidor emule cual es el cliente low ID a conectar para poder intercambiar archivos.

User ID emule usa un sistema de créditos para incentivar a los usuarios que compartan archivos, cuanto mas archivos un usuario ``sube`` a otros clientes mas crédito recibirá y mas rápido avanzara en su cola de espera. La user ID son 128 bit GUID creado por la concatenación de números al azar. El 6to. y 15vo. bit no son generados al azar, sus valores son 14 y 111 respectivamente. Mientras que la client ID es válida únicamente dentro de la sesión cliente-servidor la user ID es única y se usa para identificar a un cliente en todas las sesiones. El user ID juega un papel importante en el sistema de créditos, que motivan a los hackers a imitar otros usuarios para reunir los privilegios concedidos por sus créditos. Emule soporta un sistema de encriptado diseñado para prevenir el fraude y la imitación. La implementación es un simple intercambio contraseña-respuesta, es implementado por RSA publico/privado clave encriptada. Identificador de Archivos Es usado para identificar unívocamente archivos en la red y para la detección y recuperación de archivos dañados. Un archivo no es identificado por su nombre, si no por un GUID (Globally Unique ID), calculado por un algoritmo (MD4) aplicado en los datos del archivo. Cada archivo es dividido en GUID de 9.28 mb, calculados separadamente, que luego todos son combinados en un único file GUID. Client Server comunicación TCP Cada cliente se conecta exactamente con un servidor usando una conexión TCP. El usuario no puede conectarse con varios servidores a la vez y no puede haber un cambio dinámico del servidor sin la intervención del usuario. Establecimiento de conexión En el establecimiento de la conexión a un servidor, el cliente puede tratar de conectarse a varios servidores en paralelos, abandonando todos después de una exitosa secuencia de logueo. Pueden haber varios casos de establecimientos de la conexión: 1- Conexión high ID 2- Conexión low ID 3- Sesión rechazada. El server rechaza al cliente. Después de un establecimiento exitoso de conexión, el cliente y el servidor intercambian varios mensajes de configuración. El cliente le ofrece al servidor su lista de archivos compartidos y luego le pide que actualice su lista de server. El servidor manda su status, versión, y envía su lista de los servers que conoce y provee un poco mas de detalles de autoidentificación. Finalmente el cliente pregunta por fuentes y el servidor contesta con una serie de mensajes, uno por cada archivo que esta en la lista de descarga del cliente.

Búsqueda de Archivos La búsqueda de archivos es inicializada por el usuario. Un pedido de búsqueda es enviado al servidor que responde con un resultado de la búsqueda. Cuando hay muchos resultados el mensaje de búsqueda es comprimido, luego el usuario elije descargar una o mas filas. El cliente pide fuentes para los archivos que eligió y el servidor responde con una lista de fuentes por cada uno de los archivos solicitados. Hay una secuencia complementaria de mensajes UDP que mejoran la habilidad del cliente para localizar fuentes de su lista de búsqueda. El cliente emule comienza un intento de conexión y lo suma a su lista de fuentes. El orden en el cual las fuentes son contactadas, es el orden en el cual fueron recibidas por el cliente emule. Mecanismo de Callback Fue diseñado para superar la incapacidad de clientes con low ID, de aceptar conexiones entrantes y por eso compartir sus archivos con otros clientes. El mecanismo es simple: Permite al servidor que ya tiene una conexión TCP abierta con el cliente con low ID, mandarle un mensaje de pedido de callback, proveyéndolo con la IP y el puerto del cliente con high ID, para así poder conectarse directamente con el cliente con high ID, sin seguir agregando overhead con el servidor. Obviamente solo un cliente con high ID puede pedirle a un cliente con low ID el callback. Comunicación UDP Cliente-Servidor El cliente y el servidor utilizan el servicio poco confiable de UDP para keep alive y mejoras en la búsqueda. La cantidad de paquetes UDP generados por un cliente emule, pueden alcanzar el 5% del total de numero de paquetes enviados por un cliente emule. Los paquetes UDP son disparados al expirar un tiempo, cada 100 ms. Keep Alive server e informador de estatus El cliente periódicamente verifica el estatus de los servidores en su lista de servidores. No se envían más que una docena de paquetes por hora de verificación de estatus. Cada vez que mando un paquete de verificación de estatus se incrementa un contador en el cliente. Cada mensaje recibido del servidor el cliente resetea el contador. Si el contador alcanza un valor limite (configurable) el servidor es considerado muerto y se remueve de la lista de servidores en el cliente. Mejora en la Búsqueda de Archivos El cliente emule puede ser configurado para mejorar su búsqueda de archivos usando UDP. El formato de la búsqueda por UDP, es casi idéntico al pedido de búsqueda utilizado en TCP. El servidor responde solo si ha encontrado resultados. Los paquetes de búsqueda UDP son enviados a todos los servidores en la lista de servidores del cliente. Comunicación TCP Cliente-Cliente Después de registrarse al servidor y pedirle por archivos y fuente, el cliente emule necesita contactarse a otros clientes para poder descargar archivos. Una conexión TCP dedicada, es creada por cada archivo-cliente. Las conexiones se cierran cuando no hay actividad en el socket por un determinado tiempo (40 seg. por default) o cuando el peer ha cerrado la conexión.

Handshake Inicial El handshake inicial es simétrico, ambos lados envían la misma información al otro. Los clientes intercambian información acerca del otro que incluyen identificación, versión y capacidad de información. Identificación Segura del Usuario Es parte de la extensión emule. En caso de que el cliente soporte identificación segura, esta toma lugar después del handshake inicial. El propósito de la ID segura es prevenir imitación de usuarios. Se utiliza el sistema de intercambio de contraseña con intercambio de clave pública. Sistema de crédito El propósito del sistema de créditos es motivar a los usuarios a compartir sus archivos. Cuando un cliente sube archivos a su peer el cliente que descarga actualiza sus créditos de acuerdo a la cantidad de datos transferidos. Los créditos de una transferencia se mantienen localmente por el cliente que descarga y serán efectivos cuando el cliente que realiza el upload pida descargar a ese cliente específico. Los créditos son calculados como el mínimo de: 1. uploaded total _ 2/downloaded total Cuando downloaded total es zero la expresión vale 10 2. sqrt(uploaded total + 2) Cuando uploaded total es menor a 1 la expresión vale 1 En cualquier caso los créditos no pueden superar los 10 y ser menor que 1 Pidiendo Archivos Inmediatamente después de establecida la conexión el cliente envía numerosos mensajes de pedido refiriéndose a los archivos que desea descargar. Administración de la cola de uploads Por cada archivo que se esta subiendo, el cliente mantiene una cola de orden de prioridad creciente. En las posiciones superiores de la cola de espera están los clientes con mayor puntaje. El puntaje se calcula como: puntaje = (rating por segundos en la cola)/100 o 0xFFFFFF en caso de que el cliente que esta bajando sea un "amigo. El rating inicial es 100 excepto para usuarios ``banneados`` que reciben 0. El rating es modificado por los créditos que tiene el cliente que descarga o por la prioridad de subida que es establecida por el cliente que sube. Cuando el puntaje del cliente en la cola alcanza el valor más alto que el resto de los clientes, este empieza a bajar el archivo. Un cliente continuara bajando el archivo hasta que: *El cliente que sube es cerrado por el usuario. * El cliente que descarga tiene todas las partes que necesita.

*El cliente que descarga es reemplazado por otro cliente que tenga mayor prioridad que el. Para permitir a los clientes que recién empiezan a bajar puedan conseguir algunos megabytes de datos antes de ser reemplazados, emule otorga un rating inicial de 200 en los primeros 15 min. de descarga. Transferencia de Datos Paquete de Datos Una parte de un archivo puede contener entre 5000 y 15000 bytes. Para evitar la fragmentación, las partes de los archivos son enviadas en pedazos, cada pedazo en un paquete TCP por separado. El tamaño máximo por pedazo es de 1300 bytes (solamente para el payload). A veces los mensajes de datos son divididos en varios paquetes TCP.El primer paquete contiene el overhead del mensaje de la parte del archivo enviándose, el resto de los paquetes solo contienen datos. Eligiendo que Parte bajar emule elige selectivamente el orden de las partes a bajar para maximizar el rendimiento del ancho de banda y de las partes a compartir. Cada archivo es dividido en partes de 9.8 mb y cada uno de ellos en bloques de 180 kb. El orden de que parte empezar a bajar es determinado por el cliente. El cliente quien descarga puede descargar una única parte de cada fuente en cualquier momento y todos los bloques que son pedidos a la misma fuente residen en la misma parte. El siguiente principio se aplica (en este orden) para descargar una parte: 1. Partes raras 2. Partes para previsualizar (películas, mp3) 3. Partes que sean requeridas por otros usuarios 4. Completar una parte antes de empezar a bajar otra Este criterio de frecuencias define tres zonas: muy rara, rara y común. Dentro de cada zona, el criterio tiene un peso específico usado para calcular el rating de la parte. Las partes con menor puntuación son descargadas primero. La siguiente lista especifica el rango de valores acordes al principio descripto arriba: 0-9999 partes muy raras no pedidas y pedidas 10000-19999 partes raras no pedidas y previews 20000-29999 partes comunes no pedidas casi completas 30000-39999 partes raras pedidas 40000-49999 partes incompletas comunes

Otros protocolos: A continuación enunciaremos otros protocolos conocidos, con algunas aplicaciones que los utilizan. Una vez presentados los protocolos, se procederá a describir las características principales de cada uno de ellos. Red Gnutella BearShare (Windows) Shareaza (Windows) imesh (Windows) LimeWire (Multiplataforma) Mutella (GNU/Linux, Unix) gtk-gnutella (GNU/Linux, Unix) Otros Red Gnutella2 Red Kademila Red Ares Red fasttrack Shareaza (Windows) Morpheus (Windows) imesh (Windows) Gnucleus (Windows) gtk-gnutella (GNU/Linux, Unix) Otros MLDonkey (GNU/Linux, Windows) amule (Multiplataforma) emule (Windows) Otros Ares Galaxy (GNU/Linux, Windows) Warez P2P (Windows) Kceasy (Windows) Otros MLDonkey (GNU/Linux, Windows) imesh (Windows) Kazaa (Windows) Otros Red Direct Connect Linux DC++ (GNU/Linux) DC++ (Windows) ShakesPeer (mac Os X) Otros

Red Gnutella Características principales Red P2P pura: Todos los miembros tienen la misma función, peso e importancia dentro de la red. Es una red descentralizada: no existe un servidor central de búsqueda. Estructura basada en nodos: Todos los hosts que se conectan a la red son denominados de esa manera. Red confiable: Dada su naturaleza de red distribuida, la caída de algunos de sus componentes no debilita su funcionamiento. Utiliza conexiones sobre el protocolo TCP para unirse a la red y comunicarse con los otros nodos. Utiliza protocolo http para transferir los archivos entre nodos. Red Gnutella2 Características principales Abandona Red P2P pura: Los miembros se dividen en HUBS y LEAVES. Es una red descentralizada: no existe un servidor central de búsqueda. Abandona estructura en nodos: Se dividen en los elementos indicados anteriormente. LEAVES: Mantienen una o dos conexiones con los HUBS. HUBS: Mantienen cientos de conexiones con LEAVES y varias con otros HUBS. Red confiable: Dada su naturaleza de red distribuida, la caída de algunos de sus componentes no debilita su funcionamiento. Utiliza sesiones sobre el protocolo UDP para unirse a la red y comunicarse con los otros HUBS/LEAVES.

Red Kademila Características principales Red P2P pura: Todos los miembros tienen la misma función, peso e importancia dentro de la red. Es una red descentralizada: no existe un servidor central de búsqueda. Red basada en tablas de hash distribuidas. Red confiable: Dada su naturaleza de red distribuida, la caída de algunos de sus componentes no debilita su funcionamiento. Utiliza sesiones sobre el protocolo UDP para unirse a la red y comunicarse con los otros nodos. Cada nodo es identificado con un ID y cada valor almacenado en las tablas es denominado KEY y es generalmente un puntero a un archivo. Red Ares Características principales Originalmente perteneciente a la red gnutella, abandona dicha estructura para basarse en una de hojas y supernodos. Es una red descentralizada: no existe un servidor central de búsqueda. Cliente popular en redes universitarias dada la dificultad de detectar el protocolo. Red confiable: Dada su naturaleza de red distribuida, la caída de algunos de sus componentes no debilita su funcionamiento. Utiliza conexiones sobre el protocolo TCP para unirse a la red y comunicarse con los otros nodos y sesiones sobre el protocolo UDP para transferir archivos. El sistema de descarga es basado en Hashlinks (identificadores únicos de archivos).

Red Fasttrack Características principales Es una red descentralizada: no existe un servidor central de búsqueda. Utiliza la estructura de clientes y supernodos. Cualquier usuario puede convertirse en supernodo, actuando temporalmente como un servidor de índices. Red confiable: Dada su naturaleza de red distribuida, la caída de algunos de sus componentes no debilita su funcionamiento. Utiliza el protocolo HTTP para realizar la transferencia de los archivos. Soporta la bajada de múltiples fuentes, pero al no ser robusta la implementación permite realizar ataques a la red e infectarla con archivos falsos. Red Direct Connect Características principales Es una red centralizada: los clientes se conectan a un HUBS central desde donde gestionan las bajadas de archivos. Utiliza el concepto de slots para que los clientes administren las conexiones que permiten con los demás usuarios. Los clientes pueden conectarse en modo pasivo o activo : La restricción para el pasivo es que solo puede conectarse a un cliente en modo activo. Utiliza conexiones sobre el protocolo TCP para unirse a los hubs y bajar información y sesiones sobre el protocolo UDP para realizar búsquedas. El sistema de descarga es Cliente-Cliente sin intermediario. Cada HUB crea sus propias reglas y requisitos que los clientes deben cumplir para permanecer en él.

Capturas de tráfico emule Client- Server comunicación TCP Conexiones entrantes permitidas High ID Conexiones entrantes no permitidas Low ID

Intercambio de mensajes a nivel de aplicación emule entre cliente y servidor Busqueda de archivos

Client- Server comunicación UDP Mensajes Keep-Alive Mensajes Get Sources (para pedir mas fuentes de un recurso que se esta descargando)

Cliente Cliente -Hello -Hello Answer

Bit Torrent Descarga del archivo.torrent desde el webserver..torrent

Comunicación con el Tracker. Envío de información a traves de un GET http con variables pasadas como parametro (url?variable=valor) GET /announce?info_hash=.. uploaded=0 downloaded=0 left=399813 event=started

Respuesta http con la información solicitada. C9 = 201 fd = 253 81 = 129 c1 = 193 b2ea = 45802 Interval = 1800 Tiempo de actualización Lista con peers

Comunicación entre peers info, peer_id A info, peer_id B bitfield exchange message exchange

Maquinas de estados Estado inicial: Choked (Seed) Not Interested (Peer) Comienza la transmision: Unchoked (Seed) Interested (Peer) Request Piece (Peer)

Comienza la transferencia de datos entre los peers Mensaje tipo Piece. Pueden ser varios paquetes IP y juntos forman un segmento TCP y una bloque a nivel BitTorrent. (16KB) Cuando finaliza una pieza (se completan todos los bloques de la pieza), hace el request de otra y se envía un have al swarm informando que ya tiene una pieza para compartir