Contents

1 El FTP (File Transfer Program)

• La aplicaci’on FTP permite la transmisi’on de archivos entre hosts remotos.

  

• Utiliza TCP en ambas conexiones.
• La conexi’on de control transporta la informaci’on (en formato ASCII) necesaria para controlar la transmisi’on de archivos (login/password, comandos para movernos por el sistema de ficheros remoto y mover archivos, listar directorios, ...). El servidor recibe la informaci’on de control a trav’es del puerto 21 y utiliza el File Transfer Protocol (FTP, descrito en el RFC 959).
• La conexi’on de datos se utiliza para transferir 1 archivo (se establece una conexi’on TCP para cada archivo). El servidor utiliza para esto el puerto 20.

2 NFS (Network File System)

2.1 Caracter’isticas

• Desarrollado en 1984 por Sun Microsystems para SunOS. M’as tarde donado al public domain [1].
• Permite montar un sistema de ficheros remoto dentro del sistema de ficheros local.¹ Las aplicaciones no ven la diferencia.
• El sistema de ficheros es “exportado” por el host remoto.
• El sistema de ficheros es “montado” por el host local.
• Muchos hosts remotos pueden montar el mismo sistema de ficheros y compartir as’i datos de forma sencilla.
• Las aplicaciones locales acceden al sistema de ficheros remoto como si fuera local. En otras palabras, el NFS es completamente transparente al usuario.
• Arquitectura cliente/servidor. El servidor se monta en el host que exporta el sistema de ficheros y el cliente, en los hosts que lo montan.
• El servidor asegura la integridad de los datos en el sistema de ficheros exportado.
• El NFS utiliza un protocolo a nivel de la capa de aplicaci’on y se monta encima del sistema RPC, otro paquete de la capa de aplicaci’on [2]. Dicho protocolo es el NFSP (NFS Protocol). Actualmente cohexisten tres versiones: la 2 [3], la 3 [4] y la 4 [6].
• Los datos son transmitidos a trav’es de la red usando el sistema de representaci’on XDR (eXternal Data Representation) [5]. Esto permite que hosts de diferentes clases (con distintos SO’s, endian’s y/o longitudes de palabra) puedan intercambiar datos.

2.2 El NFSP

• Es un protocolo sin estado lo que significa que ante un fallo del sistema (por ejemplo, que el servidor NFS se cuelgue), es el cliente el que sabe c’omo recuperarse de los errores (por ejemplo, re-ejecutando la orden de escribir un fichero que no pudo ser escrito por el cuelgue del servidor).
• El protocolo se describe mediante un conjunto de procedimientos que se ejecutan sobre el sistema RPC. A continuaci’on se muestran algunos de los m’as usados:
  1. null() returns(): Hace un ping al server. Sirve para medir latencias en la red.
  2. lookup(dir_fh, name) return (fh, attr): Busca el fichero name en el directorio dir_fh y si lo encuentra, devuelve el descriptor de ese fichero fh m’as la informaci’on attr sobre los atributos del fichero.
  3. create(dir_fh, name, attr) return(new_fh, new_attr): Crea en e directorio dir_fh el fichero name con atributos attr. Si la creaci’on tiene ’exito, devuelve un nuevo descriptor de fichero new_fh que tiene los atributos new_attr.
  4. remove(dir_fh, name) returns(status): Borra el fichero name en el directorio dir_fh y devuelve verdadero si la operaci’on ha tenido ’exito.
  5. getattr(fh) returns(attr): Devuelve los atributos del fichero.
  6. setattr(fh, attr) returns(new_attr): Establece los atributos del fichero.
  7. read(fh, offset, count) returns(attr, data): Escribe en el puntero data los count bytes a partir del byte de ’indice offset del fichero fh. Se devuelve adem’as los atributos del fichero.
  8. write(fh, offset, count, data) returns(attr): Semejante al anterior m’etodo, excepto que escribimos en el fichero remoto.
  9. rename(dir_fh, name, to_fh, to_name) returns(status): Renombra el fichero name en el directorio dir_fh al fichero to_name en el directorio to_fh. Se devuelve informaci’on sobre el ’exito de la operaci’on.
  10. link(dir_fh, name, to_fh, to_name) returns(status): Crea el fichero to_name en el directorio to_fh, que es un enlace al fichero name en el directorio dir_fh.²
  11. symlink(dir_fh, name, string) returns(status): Crea un enlace simb’olico llamado name en el directorio dir_fh con el valor string.³
  12. readlink(fh) return(string): Devuelve el nombre del enlace simb’olico.
  13. mkdir(dir_fh, name, attr) returns(fh, new_attr): Crea un nuevo directorio llamado name dentro del directorio dir_fh, retorna el descriptor de ese directorio fh y los atributos new_attr con los que finalmente ha sido creado.
  14. rmdir(dir_fh, name) returns(status): Elimina un directorio vac’io llamado name que est’a dentro del directorio dir_fh y devuelve el resultado de dicha operaci’on.
  15. readdir(dir_fh, cookie, count) return(entries): En entries retorna hasta count bytes de las entradas en el directorio dir_fh. Cada entrada contiene un nombre de fichero, un identitificador y un puntero cookie a la siguiente entrada dentro del directorio. Este fichero permite en sucesivas llamadas ir recorriendo todas las entradas del directorio. Si cookie == NULL se devuelve la primera entrada.
  16. statfs(fh) return(fs_stats): Devuelve informaci’on sobre el sistema de ficheros remoto como el tama no de bloque, el n’umero de bloques libres, etc.

3 The Server Message Block (SMB) protocol

• SMB was developed by IBM in the late 1980s to describe the structure of shared network resources (directories, files, printers, etc.).
• Once the connection has been stablished, the client can access the resources on the server as if they are local.
• It is a request-response protocol.
• There is an implementatio for Microsoft Windows, Apple Macintosh and Unix systems (SAMBA).

4 Aplicaciones P2P (Peer-to-peer)

• Muy alta escalabilidad (los clientes son tambi’en servidores).
• Se utilizan para compartir archivos que residen en los hosts de los usuarios. Por esto a las aplicaciones P2P tambi’en se les llama aplicaciones de compartici’on de archivos entre iguales. Ejemplos: Napster, Gnutella, KaZaA, eMule y BitTorrent.
• Contexto complejo: t’ipicamente los hosts no permanecen todo el tiempo encendidos (ni conectados) y rara vez disponen de una direcci’on IP fija.
• Cuando un usuario busca un archivo obtiene una lista de hosts que en este momento est’an conectados y almacenan (al menos parcialmente) dicho archivo. Con esto se calcula un ’indice de accesibilidad al fichero.
• La transmisi’on (generalmente mediante TCP) de un archivo se produce directamente (sin servidores intermedios) entre uno o varios de esos hosts y el del usuario (que ha realizado la b’usqueda). Esto permite transmitir simult’aneamente distintas parte del mismo archivo mediante m’ultiples conexiones.
• En cuanto el usuario dispone de una secci’on del archivo, autom’aticamente entra a formar parte de la lista de iguales que disponen de ’el. As’i, mientras lo descarga, otros usuarios pueden comenzar a descargarlo de ’el.
• Por tanto, las aplicaciones P2P de compartici’on de archivos son altamente escalables en lo que se refiere a la cantidad de datos que pueden gestionar, porque aunque un nuevo usuario consume ancho de banda de salida de los iguales que contienen los archivos que se est’a descargando, tambi’en proporciona el suyo para que otros hagan lo mismo.
• Sin embargo, en general los sistemas P2P presentan un problema de cuello de botella en los buscadores de contenidos. A continuaci’on discutiremos las 3 estrategias existentes.

4.1 B’usqueda usando un directorio centralizado

• Ejemplos: Napster, eMule y BitTorrent.
• Existe un gran servidor (Napster) o un conjunto de servidores (parcialmente) replicados (eMule) que proporcionan servicio de b’usqueda. En el caso de BitTorrent, cada fichero .torrent especifica un servidor que no es de b’usqueda de contenidos, sino de determinaci’on de peers para ese contenido (swarm).
• Cada igual (cuando se conecta) informa al servidor de su direcci’on IP y de los contenidos que desea compartir. As’i, el servidor crea y mantiene una base de datos din’amica que relaciona cada nombre de fichero con el conjunto de IP’s de los hosts que lo contienen.

  

• Ventajas: la b’usqueda de contenidos (por parte de los iguales) es sencilla porque la base de datos est’a centralizada.
• Desventajas: el servidor central se convierte en el cuello de botella del sistema y si no existe ninguno funcionando, ning’un igual puede buscar.

4.2 B’usqueda usando un directorio descentralizado

• Ejemplos: KaZaA, Overnet, eDonkey y Kademlia (eMule).
• Un subgrupo de iguales son designados como l’ideres de grupo y cuando un nuevo igual se conecta, se le asigna uno de ellos.

  

• Cada l’ider de grupo gestiona una base de datos con la informaci’on de los peers de su grupo.
• Cuando un usuario busca, lo hace primero dentro de su grupo y obtiene una contestaci’on r’apida. Si el usuario lo solicita, puede ampliar la b’usqueda al resto de grupos ya que el l’ider de su grupo conoce a los dem’as l’ideres.
• Cuando un usuario se conecta lo hace a partir de un nodo de arranque que conoce al menos uno de los l’ideres de grupo.
• Un peer se convierte en un l’ider normalmente porque el usuario lo solicita⁴ .
• Ventajas de la b’usqueda descentralizada:
  • Las bases de datos son localmente m’as pequeñas (un l’ider s’olo se encarga de un subconjunto de los peers, generalmente los m’as pr’oximos (menos hops)).
  • El sistema es m’as escalable y resistente a fallos porque ahora la base de datos global est’a distribuida.
• Desventajas:
  • Cuando un l’ider se apaga, los peers tienen que buscar otro l’ider vecino y regenerar la base de datos local.
  • Los nodos no son todos iguales (los l’ideres, que tambi’en funcionan como peer, consumen m’as recursos).
  • Sigue existiendo la necesidad de un nodo inicial de arranque que conozca al menos un l’ider y que no puede apagarse.

4.3 B’usqueda mediante inundaci’on

• Ejemplo: Gnutella.
• No existe una jerarqu’ia de servidores (supernodos o lderes) e iguales (peers). Todos los participantes son iguales.
• Para que un nodo se conecte debe conocer, al menos, la direcci’on IP de un nodo que ya forme parte de la red de compartici’on.
• Las b’usquedas se realizan mediante inundaci’on de consultas:

  

  1. El nodo que inicia la b’usqueda pregunta primero a sus vecinos (inmediatos).
  2. Los vecinos repiten el proceso con sus vecinos inmediatos (excepto con los que le han preguntado ya por lo mismo).
  3. Los nodos que contienen el archivo buscado se lo comunican al nodo vecino que le ha preguntado la b’usqueda. Este proceso acaba cuando las contestaciones llegan hasta el nodo que inici’o la b’usqueda.
• Ventajas:
  • Todos los nodos son iguales.
  • No existen bases de datos con informaci’on de directorio.
• Desventajas:
  • El volumen de tr’afico generado por las consultas suele ser muy alto. Por este motivo el ’area de b’usqueda (n’umero de hops) suele estar limitado. Lo malo de esto es que puede ocurrir que s’olo se obtengan b’usquedas parciales.
  • Es necesario conocer un nodo de la red de compartici’on para poder formar parte de ella (http://en.wikipedia.org/wiki/Gnutella).

5 Acerca de la tasa de descarga

• La tasa de descarga de las aplicaciones P2P depende normalmente de la tasa de subida a la red. Si ’esta es alta, la de descarga tambi’en.
• Existen dos formas distintas de premiar al que m’as env’ia:
  1. Incrementando la prioridad del peer en las colas asociadas a los contenidos: “Si subes m’as, tardas menos tiempo de obtener conexiones”. Esto es lo que ocurre en eMule, por ejemplo.
  2. Conect’andote a los mejores peers: Hay protocolos, como BitTorrent, en los que no existe apenas retardo a la hora de comenzar a descargar contenidos. Cuando un nuevo peer entra en un swarm⁵ cada cierto tiempo recibe una inyecci’on de datos de hasta 5 peers que intentan con esto ganarse su “fidelidad”. De esta manera, si un peer A es generoso con otro peer B, entonces B ser’a generoso con A y ambos salen beneficiados. El resultado de esta pol’itica es que los peers del swarm que m’as entregan son tambi’en los que m’as reciben. En BitTorrent cada 30 segundos los peers prueban con un nuevo peer por si es mejor que alguno de los 4 peers con los que se est’a comunicando y si es as’i, sustituye al peor por el nuevo peer.
• En la pr’actica no debe dedicarse el 100% del ancho de banda de subida porque ahogar’iamos las conexiones TCP de descarga. T’ecnicamente lo que ocurre es que los segmentos de control de flujo que se env’ian a los peers se retrasan, provoc’andose un sobre-control del flujo.

References