Universidad Nacional de Luján. Licenciatura en Sistemas de Información. Departamento de Ciencias Básicas. Teleinformática y Redes

Transcripción

1 Universidad Nacional de Luján Licenciatura en Sistemas de Información Departamento de Ciencias Básicas Teleinformática y Redes Redes compañero a compañero como soporte de sistemas de archivos distribuidos Alumno: BIGAL ESTEBAN (51210) Resumen. Introducción. El modelo centralizado para compartir archivos de compañero a compañero. El modelo descentralizado para compartir archivos de compañero a compañero. Instalación de Napster (modelo centralizado). Instalación de LimeWire (modelo descentralizado). Características particulares de Napster, funciones principales. Características del protocolo de cliente servidor Napster. Funciones de transferencia entre clientes y el rol del servidor: Transferencia normal de un archivo: Transferencia de un archivo solicitado en un cliente remoto detrás de un firewall. Otra posibilidad es visualizar los archivos compartidos de un cliente dado. Algunas estructuras de los mensajes mencionados hasta el momento. Referencias. Resumen. Este documento tratara de explicar el concepto de las "Redes compañero a compañero como soporte de sistemas de archivos distribuidos", su funcionamiento básico, y el acercamiento hacia aplicaciones que hoy se están utilizando basándose en este modelo. Para hacer esto se describirán los modos básicos de operación centralizado y descentralizado para este tipo de redes y se describirá un proceso de instalación de una aplicación típica centralizada y una descentraliza. Además se explicaran características particulares del protocolo utilizado por Napster, y sobre las funciones más importantes que deberán ser tenidas en cuenta. Introducción. Anteriormente, los sistemas para compartir archivos entre computadoras se limitaban a Redes de Área Local (LANs) y al intercambio de archivos con entidades o personas conocidas a travez de la Internet. Las transferencias en las LAN se realizaban via sistema incorporado o software de la red, mientras que en Internet utilizaban operaciones sobre FTP. En ese momento, una compartición de archivos par a par se limitaba a un circulo de individuos que uno conocía y que además estaban de acuerdo en compartir los archivos. Los usuarios que querían comunicarse con usuarios nuevos o desconocidos debían recurrir a tecnologías poco aceptadas y difíciles de utilizar. Hoy se han desarrollado aplicaciones avanzadas P2P para compartir archivos soportadas sobre redes compañero a compañero que han aumentado enormemente el enfoque y el alcance asociado a este tipo de desarrollos. Los dos modelos principales que han evolucionado son el centralizado y el file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (1 of 11) [15/11/2001 5:10:41 PM]

2 descentralizado. Lo más importante que incorpora este tipo de tecnología es la posibilidad de intercambiar archivos entre maquinas con poca o ninguna interacción de un servidor según sea el caso. Este tipo de modalidad se denomina Peer to Peer (Punto a Punto o Igual a Igual o Compañero a Compañero). El modelo centralizado para compartir archivos de compañero a compañero. Esta basado en un modelo Cliente-Servidor, donde un servidor central es el encargado de dirigir el tráfico de la red entre los clientes registrados en él. La utilización mas conocida de este modelo es Napster en donde un servidor central mantiene directorios de los archivos MP3 compartidos por los usuarios registrados. Y la actualización de estos se produce cada vez que un usuario se conecta y se desconecta de la red de Napster. Cuando un usuario de Napster busca un archivo, el servidor central se fija en su base de datos si puede cumplir con los requerimientos de la misma. Suponiendo que se encontraron las entradas correspondientes, el servidor central le retorna al cliente un listado. El cliente que realizo el pedido selecciona el archivo del listado recibido y en este momento se abre una conexión HTTP directa con el Host que posee el archivo y se comienza a realizar la transferencia del mismo. Una característica a tener en cuenta es que las transferencias se realizan en todos los casos directamente entre dos usuarios registrados. En todos los casos los archivos MP3 que se transfieren no están guardados en el servidor central ni en cualquier nodo intermedio. involucrados para una transferencia: Pasos El modelo descentralizado para compartir archivos de compañero a compañero. Los modelos descentralizados se basan en Gnuttella. Gnuttella se diseño originalmente por la empresa Nullsoft, (una empresa subsidiaria de America Online). La dirección de AOL ordeno detener el desarrollo de Nullsoft de los protocolos de Gnuttella poco después de que estos estuviesen disponibles al publico. Los protocolos Gnuttella estuvieron solo unas horas disponibles en el sitio Web de Slashdot ( antes de que fueran retirados [1], pero mucho usuarios ya se habían bajado la información. Los programadores aprovecharon los contenidos bajados y a través de la aplicación de técnicas de file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (2 of 11) [15/11/2001 5:10:41 PM]

3 Ingeniería Inversa desarrollaron sus propios paquetes de software de Gnuttella. Este protocolo aun se encuentra en fase de desarrollo (versión 0.4). Al contrario del modelo centralizado, una red Gnuttella no utiliza un servidor central para registrar usuarios ni mantiene una base de datos de los archivos compartidos por los usuarios. Para compartir archivos en este esquema, un usuario (gnodo1) se debe conectar a una red de computadoras provistas de un software Gnuttella Cliente-Servidor, entonces, el usuario (gnodo1) se conecta con otro usuario (gnodo2). En este caso el usuario del gnodo1 le anunciara que esta en la red Gnuttella al usuario del gnodo2. Luego el usuario del gnodo2 le avisara a todas las computadoras a las cuales el se conecta (gnodo3, gnodo4, y gnodo5) que el Gnodo1 esta vivo. Próximamente gnodo3, gnodo4, y gnodo5 avisaran a todos los gnodos a los cuales ellos se conectan que gnode1 esta vivo y así sucesivamente. El alcance de esta red es potencialmente infinito, pero esta limitado por lo que se denomina el "tiempo de vida"(ttl), es decir se contabilizan un numero determinado de capas que se pueden alcanzar. Una vez que los gnodos de la red conocen que el gnode1 esta vivo, este puede realizar solicitudes que serán tenidas en cuenta por cada uno de los gnodos conectados. Estas solicitudes le llegaran primero al gnodo2 y continuaran hacia los gnodos 3, 4 y 5 y así siguiendo. Cuando una computadora de la red puede complacer la demanda, por ejemplo el gnodo5, esta realiza un envío hacia atrás y por el mismo camino de información que contiene datos acerca del archivo (nombre, tamaño, etc.) y acerca de cómo referenciarlo para el establecimiento de una comunicación directa con él. Luego de recibir esta información, el gnodo1 esta listo para establecer una conexión directa con el gnodo5 sobre la cual se realizara la transferencia del archivo. transferencia: Pasos involucrados para una Ventajas Desventajas Aplicaciones / Protocolos file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (3 of 11) [15/11/2001 5:10:41 PM]

4 Modelo Centralizado Las búsquedas abarcan a todos los usuarios conectados registrados. Son tan comprensivas como sea posible. El sistema tiene un solo punto de ingreso para las consultas. Si se cae este punto se puede caer toda la red. Además puede darse el caso de que se provea información descatolizada o enlaces a gnodos que se desconectaron recientemente. Napster (apl) Scour Exchange (SX).(todos los archivos) Etc. Modelo Descentralizado Es mas robusto que un modelo centralizado porque elimina la confianza en servidores centrales (puntos críticos de potenciales fracasos). Las demandas se realizan en forma descentralizada Las búsquedas son más lentas porque no se cuenta con un índice general. Freenet (prot) Opennap (prot) LimeWire (apl sobre prot. gnutella) Etc. [6] Instalación de Napster (modelo centralizado). EL archivo que esta disponible hoy en el sitio de Napster para instalar la aplicación en un ordenador Windows es "napv2b10-4.exe" y se puede bajar en La instalación de esta aplicación requiere seguir una serie de pasos sencillos que se mencionaran a continuación [2]. Realizada la instalación en las carpetas indicadas mediante la ejecución del archivo mencionado anteriormente se debe abrir la aplicación por primera vez. En este momento se deberán realizar una serie de pasos conectado con el servidor de Napster para poder correr la aplicación. Se deberan aceptar las condiciones de la licencia, luego se deberá elegir la velocidad de conexión desde un combo (en mi caso seleccione 56k por módem) dependiendo del tipo de conexión que se tenga. Seguidamente se presentara un nuevo formulario para ingresar los datos personales para el registro en el servidor central. A continuación el programa de instalación le preguntara si desea que revise todas las particiones de su disco buscando archivos MP3 que se puedan compartir (yo en este caso respondí negativamente). El próximo paso será la presentación de un nuevo formulario donde se deberá escoger la carpeta del Host donde nosotros compartiremos los archivos con la comunidad de Napster (en mi caso cree una carpeta con el nombre "shared" en la ruta siguiente "c:\archivos de programa\napster\shared" y luego le indique la ruta al programa de instalación). Mas tarde aparecerá un nuevo formulario igual al anterior pero esta vez para especificar la carpeta donde los otros usuarios deberán servir los archivos(en mi caso indique la misma carpeta anterior). En este momento finaliza la configuración on line de la instalación de la aplicación. Una referencia paso a paso sobre las opciones de instalación en español se puede encontrar en En este momento se puede correr la aplicación sin necesidad de reiniciar el ordenador. Es importante aclarar que por el momento el servicio de Napster esta suspendido por problemas legales [2]. De todos modos de puede ingresar a diversos salones de Chat donde se comunican los usuarios registrados. Instalación de LimeWire (modelo descentralizado). file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (4 of 11) [15/11/2001 5:10:41 PM]

5 LimeWire es una aplicación típica que utiliza el protocolo de redes Gnutella compañero a compañero como soporte de sistemas de archivos distribuidos. La versión que instale en mi ordenador es la LimeWire 1.7 y esta disponible en al WWW para varios sistemas operativos [3]. El funcionamiento de este programa es muy bueno, y más aun si se cuenta con una conexión de descarga rápida. Los pasos necesarios para realizar la instalación con un sistema operativo Windows 98/2000 son los siguientes. Ejecutar el archivo bajado en la referencia indicada LimeWireWin.exe. A continuación deberán ser aceptados los términos de la licencia. A diferencia de napster, esta instalación creara una carpeta en "c: \archivos de prorgama\limewire\shared", donde guardaran los archivos bajados desde otros clientes y se compartirá los archivos hacia otros clientes [6]. Luego se deberá seleccionar la velocidad de la conexión pudiendo elegir entre: módem, cable/dsl,t1,o T3. En mi caso seleccione la opción módem, pero queda claro que el rendimiento de este tipo de aplicación no es muy bueno con esta velocidad. A continuación el programa de instalación buscara si esta instalado el Java2TM Runtime Environment en su sistema. Este software es necesario para poder ejecutar la aplicación. Si no esta instalado, el mismo programa de instalación lo instalara desde Internet. Esto llevara un poco de tiempo, y además puede pasar que en algún momento no se pueda bajar, entonces se deberá probar en otro (esto fue lo que me paso a mí). Bueno finalmente se podrá ejecutar la aplicación. En la figura del ejemplo se pidieron archivos MP3, pero se puede pedir cualquier tipo de archivo. file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (5 of 11) [15/11/2001 5:10:41 PM]

6 Características particulares de Napster, funciones principales. Napster es también un protocolo, con el que los clientes pueden intercambiar archivos sin necesidad de pasarlos a través de un servidor, aunque el control del protocolo lo debe realizar un servidor. La empresa Napster liberó el protocolo. Una de las aplicaciones que se desarrollaron utilizando como base estos protocolos fue "OpenNap", que extiende su funcionalidad a cualquier tipo de archivo, además de proveer un servicio de chat similar al IRC. Características del protocolo de cliente servidor Napster. Napster utiliza TCP para la comunicación cliente servidor. Los puertos que corren generalmente en los servidores son el 8888 y El puerto corriente en el servidor principal es el Los mensajes entrantes y salientes del servidor tienen el siguiente formato: Length type Data Length: es la longitud en bytes de la porción "data" del mensaje dos bytes. Type: es el tipo dos bytes. Data: es un string de ASCII plano. El formato para la longitud y el tipo, varia de lo tradicional porque el byte menos significativo va primero. Ej. En lenguaje C: Número 1 const unsigned char num[2] = { 0x01, 0x00 }; Numero 256 const unsigned char num[2] = { 0x00, 0x01 }; A diferencia del protocolo IRC, cada línea no acaba en r\n, el campo "length" especifica la cantidad de datos a leer. Funciones de transferencia entre clientes y el rol del servidor: Como se vio en el esquema aclaratorio sobre los modelos centralizados, las transferencias de datos de Napster ocurren finalmente desde un cliente a otro (compañero a compañero) y sin pasar por el servidor. Hay 4 modos para poder realizar transferencias: Upload file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (6 of 11) [15/11/2001 5:10:42 PM]

7 Download Firewalled upload Firewalled download La manera normal que tiene un cliente de Napster para bajar un archivo (download) se realiza a través de una conexión TCP al puerto de datos del cliente que tiene el archivo. Sin embargo, si el cliente que comparte el archivo solicitado está detrás de un firewall, es necesario que él lo envíe. Para esto deberá realizar una conexión TCP al puerto de datos del cliente de Napster (Napc) que quiere bajarse el archivo. Transferencia normal de un archivo: Sin tener en cuenta el modo de transferencia, el cliente que desea bajar un archivo transmitirá primero un comando search(200) o browse(211) al servidor de Napster (Los comandos que se irán mencionando serán descriptos al final). Esto provoca como resultado una lista de archivos e información sobre el cliente que comparte los archivos. Para pedir una bajada de archivos (download), el cliente que desea hacerlo envía al servidor un requerimiento get(203) para lo cual el servidor contestara con un get ack (204) conteniendo información más detallada. En este momento es donde pueden aparecer los diferentes métodos de transferencia dependiendo del get ack(204) recibido. Si en el get ack(204) viene información indicando que el puerto de datos del cliente remoto (que posee el archivo solicitado) es el 0, el cliente solicitante debe enviar un request(500) al servidor lo que causa que este le pida al cliente remoto (poseedor del archivo) que sea él, el que se encargue de enviar los datos. En esta ocasión será el cliente solicitante el que deberá esperar la conexión del cliente remoto a su propio puerto de datos y esto ocurre porque en la situación planteada el cliente remoto esta detrás de un firewall. Si el cliente que comparte los archivos no esta protegido por un firewall, será el cliente solicitante del archivo el encargado de realizar una conexión TCP al puerto de datos del cliente remoto, que vino especificado en el get ack 204 enviado por el servidor. El cliente remoto deberá aceptar la conexión e inmediatamente enviar un carácter '1 ' (ASCII 49). Una vez que el solicitante lee este caracter, debe enviar la demanda conformada por un string get en un solo paquete, y luego enviar: Nick Filename Offset Nick: nombre de usuario de Napster (solicitante) Filename: nombre del archivo deseado por el solicitante Offset: punto para el inicio de transmisión del archivo (desplazamiento) Si el byte de offset en el archivo es 0, la transferencia del archivo empieza desde el principio. (Siempre que se baje un archivo por primera vez, o sea que no es una continuación de una transferencia anterior, este byte estará en 0). Luego el cliente remoto devolverá el tamaño del archivo, o un mensaje de error tal como "demanda invalida" o "archivo no compartido". Inmediatamente después del tamaño del archivo están los datos del comienzo del archivo. Una vez que se comienza la transferencia, el cliente que se esta bajando el archivo debe notificar al servidor que el está cargando un archivo enviando el mensaje 218 al mencionado. Una vez que la transferencia se completo, el cliente solicitante envía un mensaje 219 indicando la transmisión finalizada. Si se realizan transferencias múltiples se envía un 218/219 par para cada download concurrente (esta es la forma en que el servidor controla las transferencias). De igual modo, los equipos remotos (desde nuestro punto de vista) deben enviar un mensaje 220 para cada archivo que envían y un mensaje 221 cuando el envío termina [2,4,5]. Esquema simplificado de la Transferencia normal de un archivo (download) file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (7 of 11) [15/11/2001 5:10:42 PM]

8 Transferencia de un archivo solicitado en un cliente remoto detrás de un firewall. Como se describió anteriormente, cuando ocurre esta situación, el equipo que desea realizar un download del archivo envía un mensaje 500 al servidor. Esto causa que el servidor le envíe al equipo remoto que contiene el archivo un mensaje 501 similar al mensaje 204. Una vez que el cliente remoto recibe el mensaje 501 del servidor, deberá hacer una conexión TCP al puerto de datos que el equipo solicitante establece a estos efectos (enviado en el mensaje 501). En la conexión, el cliente que posee el archivo envía un byte, el caracter ASCII, `1 '. Una vez que el equipo remoto lee este caracter, debe enviar un string send en un solo paquete y luego enviar: Nick (uploader) Filename Size Nick (uploader): nombre de usuario de Napster (poseedor del archivo). Filename: nombre del archivo que va a ser enviado. Size: tamaño del archivo en bytes. En el acuse de recibo se enviará el desplazamiento del byte sobre el cual se comenzara el traslado, o un mensaje del error como "DEMANDA INVÁLIDA". El desplazamiento del byte debe enviarse como un solo paquete en dígitos ASCII planos. También en este caso cada cliente debe notificar el servidor que ellos están haciendo "uploading" o "downloading" con los pares de comandos 218/219 (downloading) o 220/221 (uploading) en la forma que se detallo para el ejemplo anterior [2,4,5]. Esquema simplificado de la Transferencia de un archivo cuando este esta en un cliente protegido por un firewall: (en este ejemplo no se representan los juegos de mensajes y entre ambos clientes y el servidor, pero obviamente estos mensajes existen al igual que los cierres de la conexión luego de la transmisión). file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (8 of 11) [15/11/2001 5:10:42 PM]

9 Otra posibilidad es visualizar los archivos compartidos de un cliente dado. Napster 2.0 BETA 8 agrega una función que es poder visualizar los archivos directamente de cliente a cliente. Para hacer esto, un cliente usa el comando 640 <nick>. El servidor envía entonces un comando 640 < request> al cliente que se desea browsear con el nick del cliente que esta pidiendo el browseado. Si este acepta ser visualizado, envía un 641 < request> hacia atrás al servidor con el nick del cliente que realizo el pedido. El servidor envía entonces un 641 <nick> <ip> < port> al cliente que pidió el visualizado. En caso de que se produzca un error, el servidor enviará un comando 642 en contestación a la orden 640. Si la visualización fue aceptada, el cliente que realizó la solicitud es el encargado de realizar una conexión TCP al puerto de datos del cliente remoto. Después de conseguir el carácter "1", el cliente que desea ver los archivos envía un GETLIST. En este punto el cliente remoto envía su nick seguido por un (\n), <nick> LF seguido por la lista de archivos compartidos. Cada línea es terminada por un (\ln). Al final de la lista, se colocan dos caracteres(\ln) y entonces el cliente cierra la conexión. En el caso que el cliente remoto este detrás de un firewall, la lista de archivos tendrá que ser enviada al cliente que la pide. El cliente remoto hace una conexión TCP al cliente que la pide enviando SENDLIST <nick>\n seguido por la lista de archivos [2,4,5]. Algunas estructuras de los mensajes mencionados hasta el momento. 200 (0xc8) Demanda de búsqueda de cliente [CLIENTE] [FILENAME CONTAINS "nombre del artista"] MAX_RESULTS <max> [FILENAME CONTAINS "canción"] [LINESPEED <compare> <link-type>] [BITRATE <compare>" < br>"] [FREQ <compare>" <freq>"] file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (9 of 11) [15/11/2001 5:10:42 PM]

10 [VMA-FILE] [LOCAL_ONLY] El nombre del artista y la canción nombran, son tratados igualmente por el servidor. Max es un número máximo de resultados; si es mayor que 100, el servidor sólo devolverá 100 resultados. El atributo <compare> es uno de los siguiente: "AT LEAST" - "AT BEST" - "EQUAL TO"(Por lo menos, mejor, igual). <link-type> es una descripción del tipo de link. <br> es un número, en kbps.<freq> es una frecuencia de la muestra, en Hz. LOCAL_ONLY causa que el servidor solamente busque archivos el mismo servidor en lugar de buscar en todos los servidores. 211 (0xd3) Visualizar los archivos de un usuario remoto[cliente] <nick> El cliente envía este mensaje cuando quiere conseguir una lista de los archivos compartido por un cliente específico 203 (0xcb) Demanda de download [CLIENTE] <nick> "<filename>" El cliente pide descargar un archivo <filename> desde el Napc remoto<nick>. El cliente espera contestación para hacer una conexión saliente a <nick> sobre su puerto especificado de datos (anteriormente mencionado). Ejemplo: koko "C:\Archivos de programa\napster\shared\n_arch song.mp3" 204 (0xcc) Download ack [SERVIDOR] <nick> <ip> <puerto> "<filename>" <md5> <linespeed> Este mensaje es enviado por el servidor como contestación al 203 anterior. Donde <nick> es el usuario que tiene el archivo. <ip> es un entero largo que representa la dirección del IP del cliente remoto que posee el archivo. <port> es el puerto donde esta escuchando nick <nick>.<filename> es el nombre del archivo a recuperar. <md5> es la md5 suma. <linespeed> es la velocidad de conexión del usuario que posee el archivo. Ejemplo: lefty "generic band - generic song.mp3" 10fe9e623b1962da85eea61df7ac1f (0xda) Descargando archivo [CLIENTE] Este mensaje no tiene cuerpo. Un cliente envía este mensaje al servidor cuando comienza a bajarse un archivo. El servidor adiciona 1 a su contador de download asociado al cliente. 219 (0xdb) Descarga completa [CLIENTE] Este mensaje no tiene cuerpo. file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (10 of 11) [15/11/2001 5:10:42 PM]

11 Un cliente envía este mensaje al servidor cuando termina de bajarse un archivo. El servidor resta 1 a su contador de download asociado al cliente [4]. 220 (0xdc) Enviando archivo [CLIENTE] Este mensaje no tiene cuerpo. Un cliente envía este mensaje al servidor cuando comienza a enviar un archivo. El servidor adiciona 1 a su contador de upload asociado al cliente. 221 (0xdd) Envío terminado [CLIENTE] Este mensaje no tiene cuerpo. Un cliente envía este mensaje al servidor cuando termina de enviar un archivo. El servidor resta 1 a su contador de upload asociado al cliente. Referencias. 1 - Documento en línea: Gnutella: Sistema distribuido para el almacenamiento y búsqueda de información. (Descripción del modelo). Fernado R. A. Bordignon / Gabriel H. Tolosa Sitio en Internet: Sitio en Internet: download.cnet.com Documento en línea: Sitio en Internet: Articulo en Internet Los clones de Napster. file:///c /WINDOWS/Escritorio/tt/monografia2_final.htm (11 of 11) [15/11/2001 5:10:42 PM]