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 red1, 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 distribuidos1 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).
nt
Web Server
.to
rre
Tracker
Peer Nuevo
Seed
Peer
Descargando
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.
Peer Nuevo
no
un G E
ce T
?
/
… info
.. _h
as
h=
Tracker
1
an
pe
e
2
r _i
d1
int , pee
er v r _
id2
al
,
Web Server
Seed
Peer
Descargando
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
info, peer_id B
peer_id,
info, bitfi
eld
peer_id,
info, bitfi
eld
bitfield exchange
Peer Nuevo
message exchange
Seed
Peer
Descargando
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.
2.
3.
4.
Partes raras
Partes para previsualizar (películas, mp3)
Partes que sean requeridas por otros usuarios
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
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 Kademila
Red Ares
Red fastTrack
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
rre
.to
Descarga del archivo .torrent
desde el webserver.
nt
Bit 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)
ET
G
nc
ou
n
n
/a
…
h=
as
h
_
fo
in
e?
..
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
Lista con peers
Interval = 1800
Tiempo de actualización
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
Actualización al tracker
-Periodicamente (interval)
-Cuando termina de descargar
Informa:
-Bloques descargados
-Bloques subidos
-Bloques restantes
Y eventos especiales
ET
G
nc
ou
n
n
/a
…
h=
as
h
_
fo
in
e?
..
Informa bytes
downloaded, uploaded,
left=0 y
event=completed