Redes de Computadoras

Transcripción

1 Universidad Nacional de Luján Departamento de Ciencias Básicas División Estadística y Sistemas Asignatura Teleinformática y Redes Cuadernos de Tecnología en Redes de Computadoras Número 2 Editor: Lic. Fernando R. A. Bordignon Profesor Adjunto Departamento de Ciencias Básicas bordi@unlu.edu.ar Cuadernos de Tecnología en Redes de Computadoras/Universidad Nacional de Luján, n. 2, (2002), Luján:UNLu, Publicación oficial del Departamento de Ciencias Básicas de la Universidad Nacional de Luján, aprobada en el Concurso Anual de Publicaciones DCB Septiembre 2002

2 La presente obra es propiedad intelectual del autor. Prohibida su reproducción parcial o total por cualquier medio, sin permiso por escrito de su editor. 2

3 Prólogo La presente colección, que comienza con este número, tiene por finalidad servir de apoyo a estudiantes de la asignatura Teleinformática y Redes en la Carrera Licenciatura en Sistemas de Información de la Universidad Nacional de Luján, como así también de instrumento de actualización a graduados en carreras afines a la informática. Se espera que estos cuadernos sean de utilidad como elemento de actualización permanente en esta área del conocimiento de evolución continua. Con esta publicación será posible promover y difundir la tecnología de redes de datos cumpliendo con el objetivo de informar, compartiendo conocimientos e intercambiando ideas. Se hace una cordial invitación a profesores y alumnos que deseen participar con artículos, relatos de experiencias, etc., relacionados con la tecnología de redes de datos. Toda contribución debe llegar al editor por medio de correo electrónico a la cuenta bordi@unlu.edu.ar. 3

4 INDICE Artículos Sistemas de Distribución de Información en Ambientes Web Tulio Ballari Redes Compañero a Compañero: Una Alternativa al Modelo Cliente/Servidor Fernando Bordignon Gabriel Tolosa El Procesamiento Distribuido en Internet Hernan Fragatti 4

5 Resumen SISTEMAS DE DISTRIBUCIÓN DE INFORMACIÓN EN AMBIENTES WEB Ballari, Tulio L. Universidad Nacional de Luján Licenciatura en Sistemas de Información Este documento pretende mostrar en una mirada abarcativa el desarrollo actual de los sistemas de replicación y caching, pudiendo ser usado como referencia inicial al de las tecnologías pertinentes y proveyendo de un punto de partida válido para todo aquél que desee iniciarse en el tema.. En un primer momento se listarán las definiciones a los términos comunes, tras lo cual se expondrán y luego detallarán las distintas relaciones existentes entre los participantes de los sistemas de replicación y chaching. 1 Introducción Es bien conocido el fenómeno de crecimiento exponencial experimentado por la Web, así mismo como los problemas ocasionados por este. La falta de una supervisión centralizada en el desarrollo de Internet, favoreció (y favorece) su rápida evolución, pero esto también provoca que sea imposible garantizar un excelente desempeño, o lidiar en forma sistemática con los problemas de performace. En la Red actual son comunes los trastornos acarreados por la alta latencia sufrida por los clientes finales, así como la necesidad de gran cantidad de ancho de banda para las nuevas aplicaciones multimediales y de comercio electrónico basadas en Web. Sin embargo, han ido emergiendo distintos paradigmas y soluciones específicas para resolver problemas puntuales. Muchas veces se considera que la solución para estos problemas es incrementar los recursos disponibles: servidores con mayor capacidad, crear nuevos enlaces entres los nodos, comprar mayor ancho de banda, etc. Rápidamente resulta obvio que este método no siempre es económicamente o tecnológicamente factible, además del hecho que no tiene en cuenta los múltiples participantes de en cualquier simple operación en la red, la cual va ha ser tan eficiente como el menor de sus participantes. En este marco es donde caches y replicación se presentan como dos componentes fundamentales para resolver los problemas de latencia y necesidad de ancho de banda de la Web actual. 5

6 El concepto tanto detrás de los caches y de la replicación es acercar la información a los clientes, de modo que esta tenga que recorrer una menor distancia en enlaces, y exista menor posibilidad que uno de estos enlaces esté congestionado. En una transacción se han caracterizado dos puntos en los cuales se producen la mayor parte de las pérdidas de eficiencias. El denominado problema de la primer milla hace referencia a la infraestructura de las compañías/organizaciones que proveen contenido; el cual muchas veces se convierte en un cuello de botella al existir un solo punto que debe asistir a las solicitudes de todos los clientes. Debido a que la demanda no es constante, existen momentos en que la infraestructura es subutilizada, y momentos en los cuales los clientes experimentan retrasos debido a la congestión. En un marco tradicional, la única forma de solucionarlo es montar una infraestructura tan grande como se proyecta va ha ser necesaria en los momentos de mayor demanda, o resignarse a que los clientes experimenten una calidad de servicio menor en determinadas circunstancias. El modelo de la replicación viene a solucionar esta situación, permitiendo establecer múltiples servidores, lo cual elimina el único cuello de botella, permite a los clientes elegir el servidor que se encuentre más cerca o esté menos utilizado, con la disminución en el tiempo de respuesta. Sin embargo, nacen algunas complicaciones. Todos los servidores deben de ser actualizados cuando la información original cambia o los clientes obtendrán información obsoleta. Además debe existir algún mecanismo por el cual los clientes obtienen la información desde los servidores replicados (sea en forma consciente o no). El otro de los problemas caracterizado en las transacciones es el denominado problema de la última milla, el cual hace referencia al enlace que conecta los clientes finales con Internet suele ser de baja calidad, estos suelen encontrarse a una gran distancia (topológica) de los servidores, por lo que se pierde mucho tiempo en la retransmisión entre los nodos y existe una gran probabilidad que alguno de estos enlaces se encuentre congestionado. Es en este esquema en donde los caches son de mucha ayuda. Un cache es ubicado en el punto de acceso (o cerca) de los clientes a Internet, de forma que este guarda una copia temporal por cada contenido solicitado por algún cliente, de forma tal que al siguiente cliente que solicita el mismo contenido le es devuelto el alojado en el cache. Entre las ventajas de los proxy caches tenemos [1] que resuelven en forma local el 35% de las peticiones de los clientes, disminuyendo la necesidad de ancho de banda. Por esto mismo, se mejora la calidad de servicio (Q.O.S.) al aumentar el ancho de banda y disminuir la latencia experimentadas por los usuarios. También permiten recolectar información detallada sobre el uso de Internet, así como establecer políticas de acceso en forma centralizada, simplificando la administración de 6

7 una red. Como principal desventaja se tiene que el contenido devuelto puede ser obsoleto, proveyendo de información desactualizada a los clientes. La distribución del presente documento es como se detalla: Primero se expondrán las definiciones a los términos que se utilizarán durante el resto del documento. A continuación se enumerarán las distintas relaciones que se pueden caracterizar entre los participantes de una transacción; pasándose a detallar cada una de estas relaciones y los protocolos involucrados en cada caso en las secciones subsiguientes. Al final se incluye un comentario como cierre del documento. 2 Terminología A continuación se expondrán términos comunes dentro del área, tomados de RFC 3040 [2] y RFC 2616 [3]. Debido a que la documentación pertinente se encuentra en inglés, incluyo entre paréntesis el termino original en ese idioma cuando no se usa el termino original en el castellano. Cliente (Client): Un programa que establece conexiones con el propósito de enviar solicitudes. Agente de Usuario (User Agent): El cliente que inicia la solicitud. Servidor (Server): Un programa de aplicación que acepta conexiones con el objetivo de dar servicios a solicitudes mediante el envío de regreso de respuestas. Los términos cliente y servidor hacen referencia a los roles cumplidos por un programa en una conexión dada, pudiendo cualquier programa actuar tanto como cliente o como servidor frente a distintas conexiones. Servidor Original (Origin Server): El servidor en el cual un recurso es creado o reside. Proxy: Un programa intermediario que actúa tanto como cliente y servidor con el objetivo de realizar solicitudes en nombre de otros clientes. Las solicitudes son resueltas internamente o mediante el reenvío, con una posible traducción, a otros servidores. Un proxy transparente es aquel que no modifica la solicitud o la respuesta más allá de lo necesario para las acciones de autenticación y/o identificación del proxy. Un proxy no transparente es aquel que modifica la solicitud o la respuesta con el objetivo de proveer algún servicio agregado al cliente. El término proxy transparente es muchas veces usado incorrectamente para designar proxy interceptor. 7

8 Proxy Interceptor (Inteception Proxy): Proxy que no necesitan ninguna configuración en el agente de usuario. Debido a que son en cierto modo transparentes para estos, se los suele denominar proxy transparente. En el presente trabajo se seguirá el criterio de [2], en donde se reserva el nombre proxy trasparente para el indicado por el estándar [3] (como ya se discutió). El término interceptor hace referencia a que reciben paquetes redirigidos desde algún elemento de red que está realizando interceptación de trafico. Cache: El almacenamiento local de mensajes de respuestas perteneciente a un programa y los subsistemas que controlan el almacenamiento, recuperación o eliminación de estos mensajes. Tanto los clientes como los servidores puede poseer caches, aunque no deben ser usados por servidores que funcionan como túneles. Nota: Es común el uso del término cache como proxy cache Cacheable: Una respuesta es cacheable si un cache está habilitado a almacenar una copia de ella para usarla en una solicitud posterior. Las reglas que determinan la cacheabilidad de una respuesta HTTP están definidas en [3] Proxy Cache: Un proxy con un cache. Se denomina local si es aquel al que se conecta el agente de usuario e intermediario si, desde el punto de vista de un agente de usuario, no es el proxy cache local dentro del caching mesh. Cache Array: Un cluster de proxy cache, actuando lógicamente como un solo servidor y particionando el espacio de nombres de las solicitudes a través de todo el arreglo. También conocido como difuse array o cache cluster. Caching Mesh: Un conjunto poco acoplado de proxys cooperando entre sí, actuando independientemente, pero compartiendo contenidos cacheables entre sí. Gateway: Un servidor que actúa como un intermediario de algún otro servidor. A diferencia de los proxy, los gateways reciben solicitudes como si fueran el servidor original, los clientes no están consientes de estar comunicándose con un gateway. Túnel (Tunnel): Un programa intermediario que actúa como repetidor ciego entre dos conexiones. Replicación (Replication): Crear y mantener duplicados de recursos en distintas computadoras, típicamente servidores. Servidor Original Maestro (Master Origin Server): Un servidor original en el cual reside la versión definitiva de un recurso. 8

9 Servidor Original de Réplica (Replica Origin Server): Un servidor original manteniendo una copia de un recurso, pero que esta autorizado para actuar como referencia para las solicitudes de los clientes. En el presente documento se utilizarán los términos servidor original y servidor de réplica para indicar servidor original maestro y servidor original de réplica. Sustituro (Surrogate): Un gateway, ubicado junto al servidor original, o en algún otro punto de la red, que opera en su nombre y en íntima colaboración con él. Típicamente poseen un cache interno. Los proxys inversos (reverse proxy) y los aceleradores de servidor (server acelerator) son sustitutos. 3 Relaciones entre los participantes En una transacción web normal, o sea sin presencia de proxys, servidores de réplica o sustitutos, solo existen dos participantes, el cliente (típicamente un navegador) y el servidor. Los proxys se agregan hacia el extremo del cliente, reemplazando a estos frente a los servidores. Por su parte, los servidores de réplica y los sustitutos se colocan hacia el extremo del servidor, reemplazándolos frente a los clientes. Fig. 1: Comunicación normal Es posible caracterizar distintos tipos de relaciones entre los participantes, muchas veces complejas. Dentro de las relaciones de réplica encontramos: Relaciones de los clientes con los servidores de réplica. Relaciones entre réplicas. A su vez, en el área de los proxys, podemos ver: Relaciones entre clientes y proxys no interceptores. Relaciones entre clientes, sustitutos y servidores originales. Relaciones entre proxys, que pueden ser: (Caching) Proxy Meshes. 9

10 (Caching) Proxy Arrays. Relaciones entre elementos de red y proxy caches. Cada una de estas relaciones serán tratadas en los tópicos siguientes. Fig.2: Comunicación en presencia de proxys y replicación Tanto para cuando se habla de proxys como de replicación, existen dos filosofías básicas en la distribución de la información: pull y push. Las relaciones basadas en pull son aquellas en las cuales los clientes solicitan los recursos que necesitan en el momento que lo desean. En general este esquema es más simple de implementar, puede utilizar servidores sin estado, y de hecho es el utilizado más ampiamente en Internet. Tiene como desventaja el hecho que el momento en que el cliente solicita el recurso puede no ser el más oportuno para el servidor, por lo que tiende a proveer una calidad de servicio no determinística, del mejor esfuerzo. En cambio las relaciones basadas en push se caracterizan porque el servidor envía los recursos a los clientes sin que estos los soliciten. Sus desventajas incluyen la necesidad de un cliente preparado para recibir recursos sin solicitarlos; la necesidad de algún esquema adicional de registración en el servidor; este está obligado a llevar el registro del estado de los clientes; y además puede ocurrir que los clientes no hagan uso del recurso de todas formas. Su principal ventaja es que los servidores pueden elegir el mejor momento para realizar las actualizaciones, ofreciendo una calidad de servicio más estable; y no sufre los picos de sobrecarga y/o largos periodos de ociosidad como puede ocurrir en las técnicas de pull. 10

11 4 Relaciones de los clientes con los servidores de réplica. Un cliente puede comunicarse con uno o más servidores de réplica, así como con el servidor maestro. El objetivo de estas relaciones es poder encontrar el servidor original optimo para el cliente en un momento dado. La definición de optimo varia, siendo en general sinónimo de proximidad, pero también puede ser considerado como el que posee menor carga o el menor tiempo de respuesta. Una explicación detallada de estas relaciones puede encontrarse en [2]. 4.1 Navegación de Hipervínculos Es el sistema más simple. Consiste en listar en una página web los URLs de los distintos servidores de réplica, dejando al usuario elegir el cual va a usar. Probablemente sea el sistema más usado. Su seguridad se basa en la seguridad del protocolo asociado a cada URL. 4.2 Redirección HTTP a una réplica Un sistema simple de comunicar los clientes web con servidores de réplica es mediante el uso de los códigos de respuesta 302 (No encontrado) o 307 (Redirección Temporal). Este sistema se ha observado en un gran número de sitios web. Su seguridad se basa por completo en la del protocolo HTTP. 4.3 Redirección mediante DNS Tal como se describe en [4], el Servicio de Nombres de Dominio (DNS) puede ser usado para seleccionar un servidor de réplica. Cuando se realiza una solicitud de resolución de nombre, un servidor de DNS mejorado devuelve una lista de IPs de servidores de réplica ordenadas por disponibilidad. Se cree que el uso de este sistema se esta extendiendo. Su seguridad se basa por completo en la del DNS y otros protocolos involucrados en la determinación del orden de la lista. 5 Relaciones entre réplicas Estas son las relaciones existentes entre el servidor maestro y los servidores de réplica, cuyo objetivo es copiar los conjuntos de datos entre estos, manteniendo disponible en todo momento la última versión de los mismos a todos los clientes. En [2] se detalla una referencia completa. 5.1 Replicación por Lotes (Batch Driven Replication) 11

12 El servidor de réplica inicia una conexión con el servidor maestro a intervalos basado en una política definida (generalmente a una hora determinada, pero puede ser más compleja), actualizando sus archivos. Es muy usado para actualizar sitios espejo (mirrors) en Internet. Su seguridad se basa en el protocolo utilizado para la transferencia, generalmente FTP. 5.2 Replicación Bajo Demanda (Demand Driven Replication) Los servidores de réplica adquieren sus recursos a medida que estos son solicitados por sus clientes. Cuando un cliente solicita un recurso que no se encuentra en el servidor de réplica/sustituto, este realiza una petición al servidor maestro, y luego envía el recurso al cliente. Se a observado su uso en varios sitios web extensos. Su seguridad se basa en los protocolos utilizados para transferir los recursos, siendo los más usados FTP, Gopher, HTTP [3] e ICP [12]. 5.3 Replicación Sincronizada (Synchronized Replication) Los servidores de réplica y el servidor maestro (en caso de existir) cooperan entre sí usando estrategias de sincronización y protocolos de réplica específicos con el objetivo de mantener los conjuntos de datos coherentes entre sí. La coherencia varia entre alta (unos pocos minutos) a baja (hasta algunas horas). Estos sistemas solo se han observados en campus universitarios. Todos los protocolos conocidos utilizan fuertes sistemas de seguridad basados ya sea en el modelo Kerberos o de clave pública/privada de RSA. 6 Relaciones entre clientes y proxys no interceptores Un cliente puede utilizar para realizar sus solicitudes cero o más proxys. Si no se utiliza un proxy en absoluto para una solicitud dada, la comunicación se reduce a una relación entre cliente y servidor original (replica o maestro) ya vista. Además, un agente de usuario puede interactuar con un servidor adicional con el propósito de realizar la configuración automática del proxy del agente. A continuación se describen técnicas y protocolos usados para la configuración, cooperación y comunicación entre agentes de usuario y proxys [2]. 6.1 Configuración Manual de Proxy Cada usuario debe configurar su propio navegador con la información que este necesita para localizar el proxy. Posee la ventaja que todos los navegadores soportan esta técnica, pero se corre un alto riesgo de hacer algo mal, ya que cada usuario coloca sus propias preferencias. 12

13 6.2 Configuración Automática de Proxy (Proxy Auto Configuration, PAC ) Un script JavaScript es interpretado para cada URL solicitada, para determinar el proxy a utilizar (si se utiliza alguno). El formato del mismo está determinado en [5]. Los agentes de usuario deben ser configurados a mano para obtener el script durante el arranque. Tanto Microsoft Internet Explorer como Nestscape Navigator soportan esta técnica, aunque pueden realizar interpretaciones ligeramente distintas del script. Mediante el script se pueden implementar políticas comunes a una organización, las cuales pueden ser actualizadas sin intervención de los usuarios. 6.3 Cache Array Routing Protocol CARP V1.0 Los navegadores pueden usar directamente como un mecanismo de selección de proxy basado en una función hash Es necesario configurar la localización de la información del cluster. Se utilizan scripts PAC para implementarlo en los agentes de usuario, CARP es soportado por Microsoft Internet Security and Acceleration Server 2000 [6] y Squid. La especificación de CARP v1.0 se encuentra en desarrollo [7], la cual no incluye consideraciones de seguridad. 6.4 Web Proxy Auto Discovery Protocol WPAD El objetivo de WPAD es suministrar al agente de usuario una URL de donde obtener el script de PAC, para lo cual hace uso de una colección de recursos ya existentes en Internet. En [8] se especifica como utilizar cada mecanismo con este propósito; el orden en el cual deben usarse cada uno, el conjunto mínimo de mecanismos que deben tratarse por un agente WPAD y el momento en el cual se debe realizar el ciclo de descubrimiento del archivo. Los mecanismos de descubrimiento de recursos utilizados por WPAD son Dinamic Host Configuration Protocol (DHCP), Service Location Protocol (SLP), alias bien conocidos usando registros DNS A, registros DNS SRV y service: URLs en registros DNS TXT. De todos estos solo los que involucran DHCP y alias bien conocidos son obligatorios para todos los clientes WPAD. Su seguridad se basa en la de los protocolos DNS, DHCP y HTTP. 7 Relaciones entre clientes, sustitutos (surrogates) y servidores originales Un cliente puede comunicarse con cero o más sustitutos para solicitudes dirigidas a uno o más servidores originales. Cuando se utilizan sustitutos, el cliente se comunica con este como si fuera un servidor original. El sustituto 13

14 resuelve la solicitud ya sea desde su cache interno, o actuando como un gateway o túnel con el servidor original. La forma más simple de sustitutos son los aceleradores de servidores (server acelerator); también llamados proxys inversos (reverse proxy). En este esquema [1], se coloca un servidor proxy cache, el acelerador de servidor, delante de servicio web, de forma tal que los clientes accedan al acelerador en vez de a los servidores web del sitio directamente. El acelerador funcionará como un proxy cache normal, salvo que solo almacenará contenidos del sitio web al cual pertenece, trata de resolver las solicitudes de lo clientes en forma local, o la redirige al servidor web. Como ventajas tenemos que se disminuye la carga del servidor web, disminuyendo la necesidad de infraestructura. Además este esquema es adaptable al surgimiento dentro del sitio de puntos calientes, contenidos que pasan a ser muy solicitados en forma súbita y pierden su popularidad tras un periodo relativamente corto. En este esquema el (o los) acelerador de servidor pertenece a la misma organización que los servidores web, y está ubicado prácticamente a un enlace de distancia de estos, por lo cual las solicitudes de los clientes y sus respuestas aún tienen que atravesar la red entera de ida y vuelta. El siguiente paso lógico después de los aceleradores de servidores es acercar los sustitutos a los clientes. Estos servidores, llamados Puntos de presencia (point of presence, PoPs) en [9]; y Edge Servers en [10], consisten en proxys cache, pertenecientes a una tercera organización que presta este servicio, localizados lo más cercanos posibles a los puntos de accesos de los clientes, pero que funcionan como aceleradores de servidores de las empresas que han contratado el servicio. En estos esquemas debe existir un mecanismo de actualización automática de los sustitutos, así como un método de selección de los mismos en forma transparente al usuario. Hasta el momento no hay una solución estandarizada. Sin embargo, una solución intermedia relativamente simple consiste en determinar en el momento en que se solicita una página web, cuál sustituto se encuentra más cerca del cliente y devolverle a este una página en la cual todos los objetos a los que hace referencia accedan al sustituto, de forma tal que solo es necesario atravesar toda la red para la primer solicitud. Otro de los servicios ofrecidos por este tipo de empresas tiene que ver con los contenidos dinámicos. Estos contenidos, surgidos principalmente para permitir al personalización de los portales de comercio electrónico, no son cacheables. Debido a que los sitios de comercio electrónico contienen un gran porcentaje de contenido dinámico, no pueden sacarle provecho a las distintas técnicas de caching y replicación. Sin embargo, en cualquier página generada dinámicamente, existen diversas secciones, cada una de las cuales es actualizada con mayor o menor regularidad. Por ejemplo, el nombre del 14

15 usuario es muy dinámico, pero la lista de novedades del mes sólo se actualiza cada 30 días. Como solución se están desarrollando e implementando distintos esquemas que permitan la subdivisión de las páginas dinámicas en componentes, siendo cada uno de ellos cacheado en forma individual. Algunos de estos esquemas son propietarios, como [9]; pero otros se desarrollan en forma abierta, como [10]. Un sustituto colocado en los bordes de la red, y cerca de los clientes finales, es quien se encarga de realizar el ensamblaje final de la página dinámica. 8 Relaciones entre proxys La idea detrás de permitir la comunicación entre proxys cache es, por un lado aumentar la base de clientes, lo que aumenta la probabilidad de que un recurso dado ya halla sido solicitado por algún cliente cuando se lo solicita, y por el otro aumentar la capacidad de almacenamiento, lo que permite que un recurso dado permanezca en el conjunto de caches por más tiempo sin que tenga que ser retirado por falta de espacio. Dentro de las relaciones entre proxys se presentan dos esquemas básicos, proxy (cache) meshes y proxy (cache) array Los meshes son conjuntos de proxys poco acoplados, típicamente se utilizan para relacionar proxys, muchas veces pertenecientes a distintas empresas y/o instituciones, a través de WANs, por lo cual los protocolos involucrados deberán lidiar con enlaces posiblemente congestionados, altos tiempos de respuesta y reducido ancho de banda; todo esto en un entorno inseguro por naturaleza. Mientras tanto, los array son clusters de proxys cache altamente acoplados, suelen pertenecer a una sola organización, estando contenidos dentro de LANs con anchos de banda y tiempos de respuestas relativamente asegurados, en un entorno más protegido a ataques externos. A pesar de las diferencias nada impide las configuraciones mixtas, existiendo proxys cache en el mercado que implementan protocolos de ambos tipos (por ej. Squid). 8.1 Relaciones en Proxys (Cache) Mesh Dentro de los Proxy Cache Mesh pueden existen relaciones muy complejas. Las relaciones básicas son de padre hijo y entre hermanos (siblings). Un proxy cache puede solicitar un recurso ya almacenado en las caches de tanto sus padres como sus hermanos. En cambio solo puede solicitar a un proxy que actúa como padre el pedido de un recurso que no se encuentre en su caché, obligándolo a que resuelva la petición por él. No se aconseja establecer jerarquías padre hijo de más de tres niveles. Se denomina vecino a cualquier 15

16 proxy al cual se le puede preguntar sobre un recurso directamente, sin importar si es un hermano o un padre. Las posibles combinaciones son diversas. Un proxy cache puede actuar como hermano para dos proxy que poseen entre sí una relación de padre hijo; también es posible que un proxy sea tratado como un hermano para determinado tipo de solicitudes pero como un padre para otro tipo. En [11] se recopilan un conjunto de experiencias sobre disitintas configuraciones de proxy cache meshs posibles soportadas por Squid. El método para saber si un recurso se encuentra en algún cache del conjunto, y decidir a cual redirigir la solicitud depende del protocolo utilizado, siendo los más comunes ICP, Cache Digest, HTCP, y en menor medida técnicas de pre filling. Prácticamente todas las técnicas permiten realizar las consultas y/o actualizaciones tanto mediante multicast o mediante múltiples transacciones en unicast; teniendo ambos enfoques sus ventajas y desventajas. La comunicación multicast permite disminuir la cantidad de paquetes enviados, por lo cual disminuye el uso de ancho de banda. Sin embargo, si es necesaria una respuesta por parte de los receptores, esta debe realizarse en modo unicast debido a que debe ser posible identificar el origen de cada una. Por otro lado, debido a que la asociación a un canal multicast no incluye ninguna política de autenticación, por lo cual cualquiera puede acceder a los paquetes transmitidos mediante este modo, provocando un problema de seguridad. La transmisión mediante múltiples mensajes unicast aumenta el ancho de banda pero posibilita un mayor control sobre las partes intervinientes. En general, en las técnicas de pull como ICP, HTCP y Cache Digest se optará por las múltiples conexiones unicast debido a la menor vulnerabilidad de dicho enfoque. En cambio, en las técnicas de pre-filling basadas generalmente en push, sí se utilizará multicast gracias a que permite actualizar en forma simultánea a un grupo nodos. 16

17 8.1.1 Internet Cache Protocol (ICP) Fig. 3: Relaciones en un Proxys Mesh ICP, tal como es descripto en las RFC 2186 [12] y 2187 [13], tiene como objetivo el permitir a un proxy preguntarle a otros proxy cache si poseen almacenado un recurso determinado. Se trata de un protocolo ligero, con un encabezado de tamaño fijo codificado en binario, y un cuerpo opcional que consiste normalmente en una URL, utilizándose UDP como protocolo de transporte; todo ello para favorecer su rápido procesamiento. ICP fue el primer protocolo desarrollado para la comunicación entre proxys cache. ICP posee varias ventajas y desventajas. Es soportado por la mayoría de los proxy cache del mercado. Al utilizar UDP se puede medir en cierta forma la disponibilidad o congestión de un enlace mediante la pérdida de mensajes ICP, y utilizar esta información en la selección del proxy vecino al cual solicitarle el recurso. Sin embargo posee varias desventajas. Por un lado, no escala bien respecto a la cantidad de proxys interconectados [14]. La cantidad de 17

18 mensajes en una consulta es del orden n^2, para n proxys vecinos, lo que consume excesivo ancho de banda y provoca que un proxy pase la mayor parte de su tiempo procesando mensajes ICP. A su vez, como es necesario esperar las respuestas a las consultas (hasta un tiempo máximo configurable), se retrasa la obtención del recurso (aumento de latencia para el usuario) en forma innecesaria si este no se encuentra en ninguno de los proxy cache vecinos. Por otro lado, debido a que solo incluye en una consulta la URL del recurso solicitado y no todo el encabezado HTTP, puede llegarse a dar que a una respuesta afirmativa ICP provoque una petición fallida HTTP [11]. Esto ocurre si la petición HTTP incluye entidades como Etag, language-encodings, parámetros de freshness, etc., distintos a los del objeto que posee el proxy consultado. Veremos que los protocolos de caches digests y HTCP resuelven en parte estos problemas. Otra característica indeseable de ICP, presentada en [14], consiste en que el algoritmo de selección del vecino para realizar la búsqueda esta basada en el tiempo de respuesta, como medida de la congestión del enlace, asumiendo que todos las demás características (en especial ancho de banda) son similares. En situaciones donde esta suposición no se cumple el algoritmo provoca usos subóptimos o desbalanceados de los recursos. Otro grupo de problemas están relacionados con la seguridad. ICP no incluye ningún campo de autenticación o identificación del origen, basándose la identificación en el número IP del origen. Posee todos los riesgos de seguridad de UDP Hiper Text Caching Protocol (HTCP) Descripto en la RFC 2756 [15], HTCP fue desarrollado con el objetivo de solucionar algunas de las limitaciones de ICP. Sigue siendo un protocolo basado en UDP, pero incluye los campos de la cabecera HTTP utilizada para solicitar el recurso. Esto permite responder más acertadamente si el objeto que se encuentra en el cache del proxy interrogado es el que se está solicitando. Además incluye opcionalmente el uso de autenticación basada en HMAC-MD5. Sin embargo, el tiempo necesario para procesar cada mensaje es mayor que para ICP (sobre todo si se habilita la autenticación) y como se mantiene el esquema de solicitud/respuesta, se siguen teniendo los problemas de consumo de ancho de banda ante ante un gran número de proxy caches y aumento de la latencia para el caso en el cual todas las consultas resultan negativas Cache Digest 18

19 Los protocolos de cache digest surgieron como respuesta a los problemas de latencia y congestión de ICP y HTCP al aumentar la cantidad de proxy cache en los mesh. Se caracterizan por no utilizar un mecanismo de solicitud/respuesta para averiguar si un objeto se encuentra en un proxy; en su lugar los vecinos de un proxy retiran de él un resumen (digest) de las URL que contiene. Como estos resúmenes son consultados en un primer momento por un proxy para buscar cual de sus vecinos posee un recurso dado, y solo después envía una solicitud a aquel que cree que posee el recurso, o si ninguno lo posee, directamente por el camino que corresponda sin más perdida de tiempo. En [16] se describe el protocolo como es pensado por los desarrollares de Squid, en [17] se comenta un enfoque con algunas variaciones y se incluyen varias simulaciones comparando cache digests con ICP; y en [18] se presenta la implementación final utilizada en Squid, así como un experimento real en el cual se comparan cache digests e ICP. Cache digest define tanto un protocolo como la estructura de datos utilizada para construir los resúmenes. Tanto en [16] como en [17] se utilizan bloom filters, una estructura de datos comprimida con perdida de información, derivada de las tablas hash. Consiste en un array de bits, en donde la presencia de una clave dada se representa mediante la puesta a uno de N bits, resultado de la aplicación de N funciones hash a la clave. Esta estructura se caracteriza por poseer cero porcentaje de falsos negativos y un muy bajo porcentaje de falsos positivos (que depende del tamaño del array de bits, y de la cantidad de funciones hash usadas). Se utilizan las URL de los recursos como claves, codificadas en MD5. En [18] se puede observar que el uso de ancho de banda y la latencia asociada al protocolo son menores que los de ICP, aunque en el momento de intercambiar los digests el consumo de ancho de banda es superior al utilizado por ICP en cualquier instante. La cantidad de memoria necesaria en cada proxy para almacenar los resúmenes es linealmente dependiente a la cantidad de vecinos que posea. Se siguen teniendo los mismos problemas que ICP respecto a la perdida de los datos de la cabecera HTTP, lo que puede provocar que un resultado positivo en el resumen de un proxy, respecto a la URL sola, provoque una petición HTTP fallida, al utilizar todos los datos de la cabecera. Como mecanismos de seguridad para el transporte de los resúmenes se pueden utilizar cualquier método de transporte seguro bajo HTTP. Es posible un ataque caballo de Troya, cuando un proxy construye un digests alterado para manipular a sus vecinos, aunque esto es minimizado si se utiliza un modelo de transporte de resúmenes basado en pull. 19

20 8.1.4 Cache Pre-Filling Las técnicas de pre-filling se caracterizan por utilizar el modelo push o de envío de información antes de la demanda. Se suelen utilizar grupos de IP multicasts, para actualizar los caches de todos los proxys dependientes de cada fuente de datos. Este esquema es especialmente útil en el contexto de las conexiones satelitales. A pesar que varias soluciones particulares (por ej. [19], no existen estándares al respecto. 8.2 Relaciones en Proxy Cache Arrays Los proxy cache arrays son clusters de proxys cache altamente acoplados, suelen pertenecer a una sola organización, estando contenidos dentro de LANs con anchos de banda y tiempos de respuestas relativamente asegurados. El objetivo de estas técnicas es eliminar la duplicación de contenidos en los caches y aumentar el porcentaje global de aciertos en los caches Cache Array Routing Protocol (CARP) CARP es un protocolo de comunicación entre proxys cache basado hash. Su descripción se encuentra en [7], pudiéndose encontrar comentarios sobre su implementación en el Microsoft Internet Security and Acceleration Server 2000 en [6]. Define un formato para una lista, en ascii, con los proxys que forman parte del array; la cual debe estar disponible en un sitio bien conocido, denominado Array Configuration URL. También especifica una función hash que distribuye las URLs a lo largo del array. Esta función posee para cada proxy parámetros que permiten tener en cuenta las distintas capacidades de cada uno. La especificación de [7] no incluye ningún comentario acerca de la seguridad, pero la implementación de [6] utiliza las características de seguridad soportadas por el sistema operativo Microsoft Windows Relaciones entre elementos de red y proxy caches. Estas relaciones se establecen cuando un elemento de red (routers, switches, etc.) redirige parte o todo el trafico que recibe hacia un /unos proxy cache. Este tipo de relaciones se establecen en el despliegue de interception proxys y array difusos. 9.1 Web Cache Control Protocol (WCCP) Este protocolo, desarrollado por Cisco Inc., posee dos funciones principales [20], por un lado permite interceptar y redirigir el trafico que recibe un router 20

21 hacia uno o más proxys cache, haciendo control de la conectividad de los mismos. Además permite que uno de los proxy cache, el web-cache designado, pueda determinar como distribuir el tráfico redirigido a lo largo de todo el array de proxys cache. La versión 2 de este protocolo [21], como agregados más importantes, permite conectar múltiples routers, negociar el método de distribuir el tráfico, negociar la forma de redirección (a nivel de enlace, red, GREP, etc.), utilizar distintos niveles de proxy arrays, incluir autenticación en los paquetes del protocolo. En [22] se presentan distintas topologías y despliegues posibles con este protocolo, entre las que se incluyen jerarquías de caches, clustering escalable, configurar excepciones en las redirección en forma estática o dinámica, redundancia de routers, etc. 9.2 Network Element Control Protocol (NECP) Este protocolo en desarrollo [23], permite informar a los elementos de red acerca de las capacidades y disponibilidades de los proxys. A su vez le permite a estos indicar a los elementos de red qué flujos deben redirigirles, y cuando no. Basicamente soporta 3 tipos de mensajes: Estoy aquí, listo para trabajar, enviado por un proxy al elemento de red cuando se inicia; No me envien más trabajo, y Un cliente necesita conección directa en las solicitudes futuras, que es util en distintas situaciones, como cuando un servidor utiliza autenticación basada en IP, o el cliente pidió no utilizar proxy, etc. Este protocolo utiliza opcionalmente un esquema de autenticación de clave secreta basado en HMAC-SHA Discusión Durante el presente trabajo se ha intentado mostrar en una mirada abarcativa el desarrollo actual de los sistemas de replicación y caching. Esta área ha experimentado un creciente desarrollo durante los últimos años, siendo los temas en los cuales se realiza mayor investigación: Seguridad: todos los protocolos recientemente desarrollados o en desarrollo incorporan, al menos opcionalmente, mecanismos de identificación basados en criptografía. Proxys Interceptores: Se han desarrollados distintos protocolos y mecanismos que permiten eliminar la configuración de los agentes de usuarios para que estos utilicen un proxy. Sin embargo, esto agrega algunos problemas [14], sobre los cuales se está trabajando. Este tema es tratado más en profundidad en [24]. Contenido Dinámico: Debido a la cada vez mayor cantidad de sitios con contenido dinámico, se vuelve necesario la inclusión de estos dentro del 21

22 esquema de caching y replicación. Esta es una línea de investigación muy nueva, cuya idea básica es partir una página con contenido dinámico en componentes, cada uno cacheable en forma independiente, realizándose el ensamblaje en un sustituto cercano a los clientes finales. Servicios Extendidos: Esta línea de investigación, muy relacionada con la anterior, intenta incorporar en los proxys servicios adicionales a los tradicionalmente prestados, como ensamblaje de contenidos (punto anterior), detección de virus, traducción de la codificación, traducción del lenguaje humano, etc. Estos servicios no son fácilmente encuadrables ni en los clientes ni en los servidores. En [25] se describe una arquitectura y los requerimientos necesarios para extender la funcionalidad de los proxys cache con el objeto de proveer servicios generales para mediar, modificar y monitorizar recursos solicitados y respondidos. 11 Agradecimientos Quisiera agradecer primero a mi madre, por su eterna paciencia. También quisiera agradecer a Fernando Bordignon y a todo el equipo del Departamento de Sistemas de la Universidad Nacional de Luján por la ayuda prestada durante la elaboración del presente proyecto. Referencias 1. Chandhok, N. Web Distribution Systems: Caching and Replication, Noviembre Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, Enero Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. y T. Berners-Lee, "Hypertext Transfer Protocol --HTTP/1.1", RFC 2616, Junio Brisco, T., "DNS Support for Load Balancing", RFC 1794, Abril Netscape, Inc., "Navigator Proxy Auto-Config File Format", Marzo 1996, Disponible en 6. Microsoft Corporation, ISA Server 2000: Caching with Microsoft Internet Security and Acceleration Server 2000,

23 7. Valloppillil, V. y K. Ross, "Cache Array Routing Protocol", en desarrollo. 8. Gauthier, P., Cohen, J., Dunsmuir, M. y C. Perkins, "The Web Proxy Auto-Discovery Protocol", en desarrollo. 9. Aberdeen Group, Inc., Cutting the Costs of Personalization With Dynamic Content Caching, Marzo Oracle Corp., Akamai Tecnologies, Inc. ESI - Accelerating E-Business Applications Overview, Wessels, D. y K. Claffy, "ICP and the Squid Web Cache", Agosto Wessels, D. y K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, Septiembre Wessels, D. y K. Claffy, "Application of Internet Cache Protocol (ICP), Version 2", RFC 2187, Septiembre Cooper, I. y J. Dilley, "Known HTTP Proxy/Caching Problems", RFC 3143, Junio Vixie, P. y D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, Enero Hamilton, M., Rousskov, A. y D. Wessels, "Cache Digest specification - version 5", Diciembre 1998, disponible en Fan, L., Cao, P., Almeida, J. y A. Broder, "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of ACM SIGCOMM'98 pp , Septiembre Rousskov, A. y Wessels, D., Cache Digests, Abril Joe Touch, Amy S. Hughes, "The LSAM Proxy Cache - a Multicast Distributed Virtual Cache", Agosto 98, disponible en Cieslak, M. y D. Forster, "Cisco Web Cache Coordination Protocol V1.0", en desarrollo. 23

24 21. Cieslak, M., Forster, D., Tiwana, G. y R. Wilson, "Cisco Web Cache Coordination Protocol V2.0", en desarrollo. 22. Cisco System Inc., Network Caching, Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig, P., Jalan, R., Neerdaels, C., Shroeder, T. y G. Tomlinson, "NECP: The Network Element Control Protocol", en desarrollo. 24. Ballari, T. Una implementación de proxy interceptor con Linux Kernel 2.4 y Squid 2.3 Stable 4, Febrero Tomlinson, G, Orman, H., Condry, M., Kempf, J., Farber, D., Extensible Proxy Services Framework, en desarrollo. 24

25 REDES COMPAÑERO A COMPAÑERO: UNA ALTERNATIVA AL MODELO CLIENTE/SERVIDOR Fernando R. Bordignon, Gabriel H.Tolosa Universidad Nacional de Luján División Estadística y Sistemas, Luján, Argentina {bordi, tolosoft}@unlu.edu.ar Resumen Recientemente se ha producido un importante auge en el desarrollo y utilización de sistemas compañero a compañero. Este artículo expone el uso actual de tales sistemas en Internet. Se describen sus orígenes, características, tipos, arquitectura típica de un nodo, aplicaciones soportadas y tendencias de evolución. Introducción En los últimos años han surgido una serie de aplicaciones en Internet operando bajo el modelo de comunicaciones denominado compañero a compañero (P2P). Cada una de tales aplicaciones implementan un servicio que opera de manera distribuida, tomando y brindando recursos en computadoras de usuario final. El concepto de compañero a compañero no es nuevo. De forma simple se lo puede ver como la comunicación entre pares o iguales utilizando un sistema de intercambio. Software operando bajo la filosofía P2P ha ganado popularidad. Programas de mensajería tales como ICQ [ICQ] y AIM [AIM], y de intercambio de archivos, como Napster [Napster] y Gnutella [Bordignon], son los más notables y son utilizados diariamente por una importante cantidad de personas. Actualmente, tales usuarios poseen equipamiento con importante capacidad de procesamiento y almacenamiento, características aprovechadas plenamente por éstos sistemas P2P. Los sistemas P2P permiten que computadoras de usuario final se conecten directamente para formar comunidades, cuya finalidad sea el compartir recursos y servicios computacionales [FIPA] [Minar]. En general, se toma ventaja de recursos existentes en los extremos de la red, tales como tiempo de CPU y espacio de almacenamiento. Las primeras aplicaciones emergentes se orientaban a compartir archivos y a la mensajería. 25

26 IBM plantea que el modelo P2P es el resultado natural de las tendencias de descentralización en la ingeniería de software [Sunsted], e Internet determinó que aplicaciones clásicas, de tipo monolítico, cambien a esquemas descentralizados. Para Intel [Barkai] el modelo P2P provee una alternativa a la arquitectura clásica cliente/servidor. Utilizando la infraestructura actual compuesta de redes, servidores y clientes, P2P ofrece un modelo ortogonal al modelo cliente/servidor; dado que ambos coexisten, se interceptan y se complementan. En un ambiente P2P, cada computador es un compañero que provee servicios de cliente y servidor a la vez. Cada aplicación definirá que recursos tomará y que recursos brindará a la red. Orígenes de los sistemas P2P sobre Internet Cuando la agencia ARPA puso en línea las primeras computadoras estableció una red P2P, donde cada una ofrecía y tomaba a la vez recursos de las otras. Las primeras aplicaciones populares, tales como telnet y FTP, operaban bajo el esquema cliente/servidor. En un principio, aunque las aplicaciones fueran cliente/servidor, el uso de las computadoras donde residían tales clientes y servidores era simétrico, debido a que casi no existían computadoras dedicadas a tareas de servidor exclusivamente. Por otro lado, las computadoras personales ó de usuario final no existían. Sistemas propios de Internet como USENET y DNS, utilizaron la tecnología compañero a compañero [Minar] en su infraestructura. USENET Usenet es un sistema distribuido de noticias. En su infraestructura, implementa un modelo descentralizado de control, donde fundamentalmente permite la copia de archivos entre computadoras sin la existencia de un administración central. Usenet es un ejemplo de un sistema de gran escala que posee control descentralizado, dado que no existen autoridades que gerencien la publicación de noticias. Nótese el grado de descentralización del sistema en el hecho que, a los efectos de agregar nuevos grupos de noticias se realiza un proceso de votación. Sobre un servidor Usenet se implementan dos variantes del protocolo NNTP [Kantor][Horton], una destinada a la comunicación entre pares (otros servidores) y otra destinada a la comunicación con sus clientes. Cada servidor puede descargar de sus pares adyacentes, las noticias que quiera ó las que estén disponibles. Existe en cada nodo una lista de seguimiento de grupos de noticias que se utiliza, a los efectos de que se pueda actualizar la información 26

27 de los grupos que localmente se atienden. Este mecanismo evita recibir noticias duplicadas (una especie de control de ciclicidad sobre la red). Cada mensaje perteneciente a cualquier grupo de noticias lleva un identificador que lo hace único, por medio del cual los nodos y los clientes pueden administrar sus descargas a los efectos de obtener siempre las noticias nuevas. El modelo propuesto por Usenet, en vigencia desde 1979, ha demostrado ser útil y exitoso (independientemente de que hoy haya que resolver problemas como el spam), permitiendo la comunicación eficaz entre grupos de personas que forman comunidades temáticas a lo largo del mundo. DNS El sistema de nombres de dominio (DNS) [Mockapetris] [MockapetrisI] combina una red P2P conformada por el conjunto de servidores de nombres, con un modelo de información jerárquico [Minar]. Esta infraestructura permitió que DNS escale de miles de equipos en 1983 a millones actualmente. La razón por la cual surgió DNS fue a partir de buscar un mecanismo más ágil que el intercambio del archivo /etc/hosts, que contiene la asociación de nombres de equipos con direcciones de red. DNS fue desarrollado como una forma de distribuir datos plausibles de ser compartidos a lo largo de la red Internet. El espacio de nombres definido en DNS es jerárquico, y los equipos servidores de nombres operan bajo una estructura simétrica, dado que actúan como clientes y servidores a la vez. Son servidores desde el punto de vista que brindan información sobre su dominio ó eventualmente sobre otros dominios (en el caso de que dispongan de información adicional en su memoria cache), y clientes por enviar consultas a otros pares 1, en nombre de sus clientes. Analizando otros protocolos, tales como SMTP [Postel], también se puede observar que el principio de simetría clásico en entornos P2P está presente entre el conjunto de agentes que conforman la red de correo electrónico de Internet. Esto se debe a que intercambian mensajes en nombre de sus usuarios. Además, puede presentarse la situación de que un mensaje tenga que pasar por varios agentes SMTP antes de llegar al destino. Hacía una definición de Sistema P2P Tradicionalmente el modelo P2P es un tipo de red en la cual cada nodo tiene capacidades y responsabilidades equivalentes. La diferencia con la arquitectura cliente/servidor está dada porque en este caso algunos nodos están exclusivamente dedicados a brindar servicio a otros. 1 Cuando operan en modo de consulta recursiva. 27

28 La definición anterior está basada en la concepción tradicional de redes P2P, donde computadores de usuario final, generalmente en el ámbito de una red local, forman un grupo de trabajo y cada usuario puede permitir que otros compañeros accedan a sus archivos ó impresoras locales. La organización FIPA Foundation for Intelligent Pyhsical Agents [FIPA] ve los sistemas P2P como una herramienta destinada a compartir recursos y servicios computacionales por medio de intercambio directo. Las aplicaciones populares incluyen compartir archivos y procesamiento distribuido. Debido a que la computación P2P involucra la participación de los nodos de una red sin administración central, se deben considerar las siguientes cuestiones: Los nodos en una red P2P pueden ingresar y salir constantemente de forma arbitraria. La ubicación de los servicios y recursos es dinámica. Cada nodo regula su grado de participación en la red La red es un ambiente dinámico y heterogéneo. Yang [Yang] define un sistema P2P como nodos de computación distribuida con iguales roles y capacidades de intercambio de información y servicios, directamente entre ellos. La gran ventaja que aporta P2P es que los recursos de muchos usuarios y computadoras pueden unirse para producir un gran cúmulo de información y un significativo poder de cómputo. El profesor Shirky 2 [Shirky] caracteriza a la tecnología P2P como una clase de aplicaciones que toman ventaja de los recursos almacenamiento, ciclos de CPU, contenidos, presencia humana disponibles en los extremos de Internet, y define una prueba, que consta de dos preguntas, a los efectos de validar si una aplicación determinada puede ser definida como compañero a compañero: 1. Es normal que los usuarios tengan conectividad variable y se les asigne direcciones de red temporales? 2. Se da a los nodos situados en los extremos de la red un importante grado de autonomía? Según Shirky, si ambas preguntas son contestadas afirmativamente la 2 Escritor que habitualmente publica sobre aspectos sociales y económicos de las aplicaciones P2P. Coopera con O Reilly Network, New York Times, Wall Street Journal y Harvard Business Review. 28

29 aplicación es compañero a compañero. Nótese que tanto la definición como el test de Shirky son aplicables a casos particulares, como la nueva generación de sistemas que volvieron a impulsar el concepto de P2P (aplicaciones usuario final que operan en los bordes de Internet), y que pueden existir aplicaciones basadas en el modelo compañero a compañero que no cumplan sus requisitos. Como ya se mencionó, los orígenes del modelo P2P no calificarían bajo estas premisas. Bajo la óptica de los autores de este documento, en un sistema compañero a compañero los nodos intercambian coordinadamente recursos ciclos de CPU, espacio de almacenamiento, archivos en base a la comunicación directa entre ellos (los que requieren y los que poseen). Operan bajo una topología de red donde todos los participantes tienen igual acceso a todos sus pares y eventualmente pueden existir nodos con alguna capacidad especial. Los sistemas P2P utilizan la descentralización como una forma de incrementar la perfomance, escalabilidad y disponibilidad de los recursos de los nodos que conforman tal sistema. Características de los sistemas P2P La primer característica que define a un nodo en un sistema P2P, es que cumple tanto el rol de cliente como de servidor (en la terminología Gnutella se lo denomina servent, palabra que deriva de la conjunción de los términos server-client). Este modelo basado en interacciones entre pares, es una alternativa al paradigma cliente/servidor, donde cada nodo es capaz de generar y contestar consultas de otros nodos. Desde el punto de vista de la comunicación, las interacciones son simétricas. A continuación se enumeran las características deseables de un sistema P2P: Los nodos participantes deberían autónomos. Cada uno regula su grado de participación en la red, a través de definir que recursos ofrece y en que cantidad. No necesariamente los nodos deben tener una vista global del sistema. El comportamiento global emerge de las interacciones individuales. Todos los datos y servicios deberían ser accesibles por cualquier nodo. Pueden implementar un sistema de nombres alternativo al sistema 29

30 DNS, que satisfaga sus propias necesidades. Los nodos en una red P2P pueden ingresar y salir constantemente de forma arbitraria. Pueden ser nodos de usuario final que no se encuentran permanentemente conectados a la red, es decir, su conectividad es variable ó bien nodos dedicados de alta disponibilidad. La ubicación de los recursos es dinámica, ya que depende del estado del sistema en un momento del tiempo. La red es un ambiente dinámico y heterogéneo, dado que la pueden conforman nodos con conectividad variable y de diversas plataformas de hardware y software. Todo nodo en una red tiene la posibilidad de que sobre éste corra una aplicación P2P. Tipos de Redes Compañero a Compañero Si un sistema P2P está íntegramente conformado por nodos que tienen iguales roles y ninguno cumple tareas administrativas o especiales, se lo considera P2P puro o completamente descentralizado [Yang]. En cambio si algún nodo posee alguna característica diferente que le hace cumplir con tareas centralizadas, entonces al sistema se lo considera híbrido. 1. Redes Puras Es una democratización total del grupo de compañeros, cada nodo participante de la red posee las mismas capacidades que los demás, cualquier nodo puede iniciar una comunicación o una red [Yang]. Freenet [Clarke] y Gnutella son ejemplos de este modelo. No existen recursos centralizados, por ende no existen los riesgos propios de tales sistemas, en los cuales se presentan puntos críticos de falla. En general, tales redes -por su propia naturaleza- implementan mecanismos ineficientes para descubrir compañeros y localizar información. 30

31 X Y Nodo X Nodo Y Recursos a compartir Z Nodo Z 2. Redes Híbridas Sistemas como Napster y Pointera [Pointera] tienen la característica que entre los usuarios compañeros de la red existen determinados equipos que están dedicados a una función determinada, es decir ofrecen ciertos servicios de forma centralizada. Tal es el ejemplo del sistema Napster, en el cual un servidor central contiene la base de datos con información acerca de que recursos comparten los usuarios. El concepto de hibridez deriva de que algunos nodos (nodos encaminadores) proporcionan alguna funcionalidad extra a los efectos de facilitar la interconexión entre compañeros. Los nodos encaminadores, cuando actúan como catálogo de direcciones, pueden implementarse de dos formas: 1. Un compañero, en modo cliente, envía al nodo encaminador un requerimiento dado. El nodo encaminador resuelve autonomamente la consulta y obtiene, generalmente, una respuesta consistente en que nodo activo (nodo a actuar en modalidad servidor) posee el recurso solicitado, y envía el requerimiento al nodo servidor seleccionado, donde este último se comunica con el nodo originante de la consulta y le brinda el recurso solicitado. Lo anterior puede describirse como: Nodo-cliente Nodo-encaminador Nodo servidor ---> Nodo-encaminador(recibe consulta) ---> Nodo-servidor (recibe dirección del nodo-cliente que le brindará el recurso) ---> Nodo-cliente(recibe el recurso) 2. El nodo peticionante en modo cliente envía un requerimiento al nodo encaminador, este devuelve la dirección del nodo que en modalidad 31

32 servidor satisfacerá tal consulta, el nodo peticionante se comunica con el nodo que oficiará de servidor enviándole su requerimiento de recurso, finalmente el nodo servidor satisface la petición. Lo anterior podría describirse como: Nodo-cliente ---> Nodo-encaminador(recibe consulta) Nodo-encaminador ---> Nodo-cliente(recibe una dirección por respuesta pueden viajar direcciones alternativas-) Nodo-cliente ---> Nodo-servidor(recibe el requerimiento) Nodo-servidor ---> Nodo-cliente(recibe recurso solicitado) En la categoría de redes híbridas, la empresa Microsoft presenta una serie de configuraciones en su infraestructura P2P denominada.net [NET]: 2.1 Sistema con Servidor de Descubrimiento Los nodos compañeros pueden auxiliarse de un nodo servidor que brinda el servicio de descubrimiento de compañeros. Las aplicaciones, al inicializarse y al finalizar, registran su presencia y ausencia notificando al servidor. Cualquier nodo compañero puede consultar en cualquier momento al servidor central y obtener una lista de los nodos compañeros activos. Una alternativa posible destinada a dotar de una mayor disponibilidad el servicio provisto por los nodos centrales es que el contenido pueda ser replicado automáticamente, y que los nodos compañeros puedan obtener transparentemente direcciones de los servidores con réplicas. Conoce que X,Y;Z están en la red Servidor Central X Y Nodo X Nodo Y Z obtiene un recurso de X Nodo Z Z Recursos a compartir 32

33 2.2 Sistema con Servidor de Descubrimiento y Búsqueda Se basa en que al sistema con servidor de descubrimiento se le adosa el servicio de base de datos y búsqueda de recursos. Para lo cual cada nodo compañero que registre su ingreso al sistema, además debe informar que recursos comparte. Cualquier nodo, además de obtener la lista de sus compañeros, ahora puede consultar al servidor central por quien o quienes poseen un recurso determinado. Y X Z Conoce que X,Y;Z están en la red y además que recursos comparten Servidor Central X Y Nodo X Nodo Y Z obtiene un recurso de X Nodo Z Z Recursos a compartir 2.3 Sistema con Servidor de Descubrimiento, Búsqueda y Contenidos Este sistema representa un acercamiento al modelo cliente-servidor, dado que al sistema anterior se le agrega la posibilidad de que contenga réplicas de los recursos que comparten los usuarios. Donde un nodo compañero que desee un recurso puede optar por descargarlo de un nodo compañero o del servidor central. 33

34 Y X Z Conoce que X,Y;Z están en la red, además que recursos comparten y mantiene una replica de sus contenidos X Nodo X Z obtiene un recurso de X Servidor Central Z obtiene una copia de un recurso de Y Nodo Y Y Nodo Z Z Recursos a compartir Proyecto SETI@Home Varios proyectos de cómputo masivo distribuido utilizan ciclos de CPU ociosos en máquinas de usuario final. Aunque algunos proyectos no sean P2P, generalmente se los denomina como tales porque utilizan los recursos de computadoras de borde, que poseen conectividad variable y direcciones temporales de red. Los autores de este documento entienden que el proyecto SETI@home 3 [Korpela] no pertenece a ninguna categoría de red P2P, dado que no existe comunicación directa entre pares. Su infraestructura se basa en el modelo Maestro/Esclavo, donde un nodo central se encarga de repartir unidades de trabajo entre distintas computadoras de usuario final. De esta forma, cuando cada computadora cooperante detecta que tiene tiempo de CPU libre, dedica tal recurso ocioso a procesar datos a los efectos de buscar señales de inteligencia extraterrestre. 3 SETI@home es un proyecto de búsqueda de inteligencia extraterrestre de la Universidad de California en el Laboratorio para Ciencias Espaciales de Berkeley 34

35 Computador de usuario final Datos a procesar Datos procesados Computador de usuario final Datos a procesar Datos procesados Datos a procesar Datos procesados Servidor Central SETI@Home Computador de usuario final Arquitectura típica de un nodo compañero Para cumplir con sus funciones básicas, los nodos en una red compañero a compañero deberían poseer al menos cuatro módulos principales, a saber: Módulo servidor. Parte de un nodo compañero que provee acceso a datos y recursos del compañero donde se ejecuta. Módulo cliente. Parte de un nodo compañero que le permite al usuario comunicarse con otros nodos, iniciando conexiones. Módulo de datos. Parte de un nodo que almacena información sobre el estado del nodo y la red. Esta información le permitirá seleccionar el modo de operación en cada instante de tiempo, para poder alcanzar el mayor grado de autonomía posible. Módulo de encaminamiento. Parte de un nodo que tiene por función principal propagar mensajes propios y de terceros. Esta tarea será realizada según políticas de ruteo y de acuerdo a la información provista por el módulo de datos (por ejemplo, para la selección de los destinos). Módulo de comunicaciones: Brinda soporte de comunicaciones entrantes y salientes tanto al módulo servidor como al cliente. 35

36 Módulo de seguridad: Gerencia la seguridad del nodo, implementando políticas definidas. Permite la validación de mensajes, encriptación y autenticación. Puede existir ó no. Seguridad Encaminamiento Comunicaciones Datos Cliente Servidor Red P2P Nodo P2P Componentes de un nodo perteneciente a una red P2P Funciones del componente cliente Proporciona la interface de usuario. Permite enviar requerimientos Proporciona conexión con otros nodos compañeros. Funciones del componente servidor Detecta, procesa y contesta requerimientos de otros nodos. Proporciona acceso a sus recursos (Ej. archivos, tiempo de CPU, espacio en disco). Funciones del componente datos Define un esquema para el almacenamiento de datos y metadatos Satisface requerimientos de los componentes servidor y cliente. Almacena información sobre el estado del nodo y la red (Ej. lista de nodos compañeros) Funciones del componente comunicaciones Envía y recibe mensajes de los y a los componentes cliente y servidor Administra mensajes duplicados, tiempos de vida de mensajes y trata de optimizar la perfomance de la red. Acepta conexiones entrantes. Gerencia conexiones existentes. 36

37 Funcionamiento del componente seguridad Garantiza la confidencialidad e integridad de los datos. Implementa un esquema de autenticidad de nodos compañeros. La propagación de mensajes en una red descentralizada generalmente se realiza utilizando campos origen y destino. Origen Destino Largo Tipo de mensaje ID de mensaje Carga Ejemplo de una estructura de datos típica de un mensaje de red P2P Intel proporciona la idea de que debe desarrollarse un modelo de interoperabilidad entre aplicaciones P2P [Barkai], donde tal objetivo puede lograrse a través de un juego común de servicios que proporcionen la funcionalidad necesaria para operar en modo P2P, sobre los servicios proporcionados por el sistema operativo. Estos servicios comunes pueden pensarse como una capa de middleware. Una de las ventajas principales de un middleware común es que los diseñadores de aplicaciones ya no tendrán que seguir creando los mismos servicios básicos una y otra vez. Tal interoperabilidad permitirá que equipos con distintos sistemas operativos y con distintas aplicaciones, programadas en distintos lenguajes de programación, puedan comunicarse e integrarse. Aplicaciones P2P Interfases de aplicación MIDDLEWARE P2P Sistema operativo Hardware 37

38 Mecanismos de exploración Capa de middleware P2P propuesta por Intel Las redes P2P necesitan mecanismos de exploración (discovery) que sean robustos y eficientes a los efectos que las aplicaciones puedan enviar mensajes a sus pares. Se evaluan mecanismos basados en difusión (ó inundación) y en reenvío directo (forward) de mensajes (tal como es el caso de los implementados en CHORD, Pastry y CAN). Se presentan una serie de mecanismos de descubrimiento de nodos compañeros que se implementan sobre redes descentralizadas. Exploración por difusión Son modelos descentralizados destinados a la tarea de descubrir vecinos. Un ejemplo es el utilizado en Gnutella. Los nodos compañeros forman una red de recubrimiento (overlay) sobre la red de transporte. A los efectos de hallar un recurso un nodo inunda la red con su requerimiento. Los compañeros que posean tal recurso, recibirán el requerimiento y responderán debidamente. En la práctica, el área a alcanzar por un nodo está limitada, generalmente, a una serie de reenvíos 4. La robustez y el buen alcance que logra este método hace que sea un atractivo recurso para los desarrolladores. Los resultados óptimos se dan sobre redes chicas, con un limitado número de nodos, dado que adolece de problemas de escalabilidad. Por otro lado, en grandes redes, este mecanismo no garantiza siempre un funcionamiento eficiente. Exploración por encaminamiento Otra alternativa de envío de mensajes es vía encaminamiento. Un mensaje va dirigido a un nodo en particular y los nodos intermedios, que cooperan para propagar mensajes, redireccionan un único mensaje hasta llegar a destino. Para lograr este funcionamiento, los nodos en el camino deben poseer información acerca de la topología de la red. Dado que la topología de una red P2P es definida por azar y puede aceptar ciclos, los nodos intermedios pueden implementar un control para evitar reenvíos sucesivos. Esto se puede realizar utilizando una memoria cache que almacene los identificadores de los mensajes recientemente recibidos (durante 4 Similar al funcionamiento del mecanismo Time To Live del protocolo de red IP. 38

39 un lapso de tiempo) a los efectos de poder determinar repeticiones de mensajes. Por otro lado, un nodo cada vez que propaga un mensaje podría decrementar y chequear un campo tipo TTL (time to live) a los efectos de eliminar mensajes luego que han circulado durante una serie de nodos. Proyecto Chord El proyecto Chord [Dabek] es una parte de un proyecto más ambicioso denominado Sistema de Archivos Distribuido y Seguro. En Chord se implementa la búsqueda y el encaminamiento sobre una red virtual representada como espacio circular unidimensional. Cada clave puede ser localizada en O (logn) saltos, donde N es el número total de nodos en el sistema. La garantía de que se hallará al nodo deseado es una de los puntos sobresalientes de Chord. Pastry Pastry [Rowstron] es una aplicación descentralizada destinada a implementar una infraestructura de ruteo a nivel aplicación y un sistema de localización de objetos. Cada nodo es identificado en la red de aplicación por un identificador unívoco (NodeID). Los identificadores se asignan en base a una métrica de proximidad. Cada salto de un mensaje se hace en base a la selección del nodo más cercano, al nodo destino al cual debe enviarse mensaje, información extraída de la tabla de ruteo de cada nodo. Su eficiencia es O (logn). Cada nodo mantiene información sobre que nodos están operativos y sobre sus vecinos, esto lo logra por medio de mensajes de estado. Pastry es un algoritmo genérico de encaminaniento por auto-organización que puede utilizarse para almacenamiento, intercambio de datos, mensajería instantánea y sistemas de mapeo de nombres. CAN (Content-Addressable-Networks) CAN [Ratnasamy] es una malla de n nodos sobre un espacio virtual de d dimensiones. El espacio virtual coordinado es dinámicamente dividido en zonas y cada nodo conoce su zona de pertenencia en el espacio. Una coordenada espacial es utilizada para almacenar pares (clave, valor) tal que cada clave es de forma determinística mapeada en un punto P sobre la coordenada espacial, utilizando una función uniforme de hash. El dato (clave, valor) se almacena finalmente en el nodo, donde cuya zona está el punto P. Para recuperar un valor correspondiente a la clave k, cualquier nodo puede aplicar la misma función de hash para mapear k sobre el punto P y luego recuperar el valor almacenado en P de forma directa o a través de nodos vecinos en O (n 1/d ). De acuerdo a sus autores CAN es tolerante a fallas, robusto, con estrategias de auto-organización y provee un marco de 39

40 escalabilidad mayor que la existente en los métodos de inundación. Areas de aplicación Los sistemas P2P pueden aportar soluciones en muchas áreas, principalmente donde la distribución de sus componentes en una red es una característica básica del sistema. A continuación se presentan algunas áreas que aparecen como propicias para la implementación de soluciones alternativas al modelo cliente/servidor basadas en redes compañero a compañero: Trabajo en grupo: La colaboración incrementa la productividad disminuyendo el tiempo de múltiples revisiones por parte de los participantes de un proyecto. Además, permite trabajar juntos a equipos en distribuidos geográficamente, y disminuir la necesidad de almacenamiento en servidores centrales, utilizando almacenamientos locales con posibilidad de replicación automática. Groove [Groove] es una aplicación ejemplo de ambiente colaborativo, donde los usuarios pueden crear "espacios compartidos". Los objetos y el contenido dentro de dichos espacios aparecen en todas las máquinas del equipo, y cada usuario puede contribuir con los archivos o los programas de su elección. Replicación de contenidos: Una red de aplicación como la planteada puede ayudar a distribuir contenidos a través de distintas áreas geográficas. Esencialmente, pueden moverse los datos más cerca del punto donde realmente son consumidos, implementando mecanismos de replicación. Las redes de distribución de contenidos (CDN, Contents Distribution Networks), que tienen por objetivo lograr que los usuarios finales accedan más rapidamente a contenidos web, ya han comenzado a incorporar el modelo P2P, tal es el caso del sistema Swarmcast [Swarmcast]. Computación distribuida: Necesidades de procesamiento en gran escala pueden ser provistas utilizando una red de computadoras donde sus componentes puedan aportar capacidad ociosa de CPU y espacio en disco. Este servicio permite a universidades, institutos de investigación y empresas obtener un gran poder de cómputo a partir de múltiples computadoras operando en paralelo (procesamiento distribuido sobre una red débilmente acoplada) para aplicar a tareas especificas. Los resultados se pueden obtener en tiempos y costos menores. Intercambio de archivos: Permiten que usuarios de computadoras personales intercambien directamente entre ellos archivos de datos. Estas aplicaciones han obtenido una gran popularidad gracias a sistemas como Napster, Gnutella y Freenet. Actualmente, estos sistemas focalizan sus 40

41 contenidos en la distribución de archivos musicales, videos y fotografías. Mensajería instantánea: La mensajería instantánea permite la comunicación en tiempo real entre personas conectadas a la red. El intercambio se realiza al escribir mensajes o al enviar archivos. Los programas más populares son AOL Instant Messenger (AIM) e ICQ. Búsquedas: Debido a la expansión de la web, los motores de búsqueda tradicionales experimentan problemas de cobertura y de actualización de contenidos. La implementación de servicios de búsquedas distribuidas basadas en redes P2P puede mejorar esta situación, permitiendo a sus usuarios la obtención de resultados de mejor calidad. El proyecto InfraSearch fue un punto de partida en este tipo de aplicaciones. Si bien puede ser complicado realizar búsquedas de gran cobertura del espacio web, los sistemas P2P ofrecen otra visión de cómo abordar el problema y plantean soluciones para búsquedas extendidas sobre temas específicos. Comercio: Diversas compañías están experimentando con modelos de conexión directa entre usuarios a los fines de implementar sistemas de comercio electrónico. La idea es reemplazar un mercado electrónico centralizado por intercambios directos entre compradores y vendedores. La empresa Netrana está desarrollando herramientas y estrategias de comercio electrónico para situaciones que escapan al ámbito de los mercados electrónicos convencionales. Su objetivo es desarrollar una plataforma de comunicaciones que permita a los participantes llevar a cambio entre ellos esta negociación, sin la intervención de un intermediario. La empresa Biz To Peer Technologies está diseñando estrategias para proporcionar a sus usuarios herramientas de informática distribuida con el fin de establecer transacciones entre particulares de manera directa. P2P como infraestructura Varias compañías pugnan por imponer sus proyectos de infraestructura para soportar aplicaciones P2P. Microsoft propone su medioambiente de trabajo denominado.net y Sun Microsystems a JXTA. Otra compañía denominada Groove Networks presentó una plataforma descentralizada de groupware y ha incorporado servicios P2P, tales como mensajería instantánea e intercambio de archivos. Los diseñadores se encuentran construyendo aplicaciones desde el principio. Tienen que investigar, desarrollar, construir prototipos, probar y esperar ser artífices de sus éxitos y fracasos sobre esta floreciente tecnología. A los efectos de consolidar el cómputo distribuido se necesitará desarrollar 41

42 APIs y compiladores robustos desarrollados específicamente para tal ambiente. Compañías como Un a través de su plataforma JXTA [JXTA] y Microsoft con.net [NET] están intentando brindar ambientes de desarrollo unificado para construir tales aplicaciones. Seguridad La seguridad es un campo poco explorado aún en las redes P2P. Dado que este modelo distribuido y cooperativo se basa en la confianza es necesario lograr mecanismos de seguridad adaptados específicamente a P2P que aseguren la autenticidad y privacidad de las comunicaciones. Existen dos aspectos sobre este dominio, uno es la seguridad a aplicar a los grupos, donde la confianza debe primar, y se deben implementar técnicas que tiendan a denegar todo acceso a recursos a aquellos usuarios que no son de confianza ó mal intencionados; el otro aspecto es contemplar la protección contra ataques de virus, gusanos, intrusos (hombre en el medio), etc. La seguridad es un importante problema en ambientes P2P, fijese su impacto en un ambiente de cómputo distribuido donde personas mal intencionadas pueden entregar resultados fraudulentos y estropear un proyecto. La utilización de firmas digitales y encriptación resolverá la mayoría de los problemas de seguridad. Metas futuras de los sistemas P2P Anonimato, servicios anticensura, y hospedaje descentralizado de bloques de información (una misma información, partirla y distribuirla en n nodos) serán los principios de diseño en las nuevas aplicaciones. El derecho a la privacidad se garantizará implementando como una cualidad estandar de cualquier nueva aplicación. Definir maneras o formas más fáciles de encontrar información compartida, ya sea a través de normalización de formas de almacenamiento, definición de metadatos y sistemas de búsqueda distribuida. Actualmente el acceso general a espacios de almacenamiento y a ciclos de CPU se realiza bajo un riesgo de seguridad importante por parte de los usuarios. La computación distribuida necesitará definir nuevos entornos de trabajo, protocolos de comunicación y lenguajes de programación que minimicen los riesgos (ejecución de código no seguro ó acceso a información no compartida) en tales equipos. 42

43 Infraestructura de red. Modelos de ruteo en redes P2P aportan la posibilidad de ruteo por difusión (multicast). Implementándose mucho más fácil y con menos requisitos que la definida a nivel de red en Internet. Tal característica será mayormente difundida a los efectos de lograr comunicaciones más veloces y que utilicen un ancho de banda menor. Conclusiones Sistemas P2P permiten que los computadores individualmente dialoguen entre sí, hagan ejecuciones en paralelo y administren contenidos, en lugar de que lo hagan servidores centrales. La principal ventaja competitiva del modelo P2P está dada por que utiliza los recursos de las computadoras de usuarios, aquellos equipos que tradicionalmente permanecían ocultos 5 y era imposible nombrarlos y direccionarlos bajo los esquemas clásicos. La descentralización y los modelos P2P tienen, probablemente, más aplicaciones que las que al presente es posible imaginar. En el futuro, en cualquier área donde la escalabilidad y la capacidad de cómputo masivo sea importante, se implementarán sistemas descentralizados. En las redes P2P, cada usuario construye su propio espacio virtual, elige quienes serán sus interlocutores y lo que desea compartir con ellos. Este esquema brinda libertad, en base a las posibilidades de elección, dado que los usuarios eligen a que comunidades desean pertenecer y no por que sitios multimedios navegar. Los problemas claves que impiden la masificación de los sistemas P2P son: confianza mutua, seguridad de las aplicaciones e integridad de los datos. La seguridad y la privacidad se perciben como importantes barreras para que tenga lugar una adopción rápida. Bibliografía [AIM] [Barkai] American Online Inc. Página principal del software AIM D. Barkai. An introduction to Peer-to-Peer Computing. Intel Developer UpdateMagazine. Febrero, [Bordignon] F. Bordignon y G. Tolosa. "Gnutella: Distributed System for 5 Clay Shirky los definió como dark matter of Internet 43

44 Information Storage and Searching. Model Description (2001). JIT- Journal of Internet Technology. Taipei (Taiwan) Vol. 2, No. 5.. Disponible en [Clarke] I. Clarke, O. Sandberg, B. Wiley y T.W. Hong. "Freenet: A Distributed Anonymous In-formation Storage and Retrieval System". In Hannes Federrath, editor, Proceedings of the- Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, July [Dabek] F. Dabek, E. Brunskill, M. F. Kaashoek, D. Karger, R. Morris, I. Stoica y H. Balakrishnan. "Building Peer-to-Peer Systems with Chord, a Distributed Lookup Service". Proceedings of the 8th Workshop on Hot Topics in Operating Systems (HotOS-VIII), Schloss Elmau, Germany, May [FIPA] [Groove] [Horton] FIPA. FIPA Peer-to-Peer Positioning Paper. Technical Report F-OUT-00076, Foundation for Intelligent Pyhsical Agents, Diciembre Página principal del proyecto groove M. Horton y R. Adams. " Standard for Interchange of USENET Messages". RFC [ICQ] ICQ Inc. Página principal del software ICQP [JXTA] Projecto JXTA. Sun Microsystems. Disponible en. [Kantor] B. Kantor y P. Lapsley. "Network News Transfer Protocol". RFC [Korpela] E. Korpela, D. Werthimer, D. Anderson, J. Cobb y M. Lebofsky. "SETI@home - Massively Distributed Computing for SETI," Computing in Science and Engineering, vol. 3, no. 1, Jan.-Feb Disponible en [Mockapetris] P. Mockapetris "Domain Names - Concepts and Facilities". RFC

45 [MockapetrisI] P. Mockapetris "Domain Names - Implementation and Specification". RFC [Minar] N. Minar y M. Hedlund. A Network of Peers. Peer-to-Peer Models Through the History of the Internet,. A. Oram, editor,, Peer-to-Peer: Harnessing the Benefits of a Disruptive Technology cap. 1. O Reilly & Associates, Marzo [Napster] Napster Inc. Página principal del software Napster [NET] Projecto.NET. Microsoft. Disponible en [Pointera] Página principal del software Pointera [Postel] J. Postel. "Simple Mail Transfer Protocol". RFC [Ratnasamy] S. Ratnasamy, P. Francis, M. Handley y R. Karp, "A Scalable Content-Addressable Network (CAN)". Proceedings of ACM SIGCOMM [Rowstron] A. Rowstron y P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems". IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, pages , November, 2001 [Shirky] C. Shirky. What Is P2P and What Isn t?. The O'Reilly Network. Disponible en whatisp2p.html [Sunsted] T. Sunsted. "The practice of peer-to-peer computing: Introduction and history". IBM DeveloperWorks. Disponible en [Swarmcast] Página principal del software Swarmcast [Yang] B. Yang y H. Garcia-Molina. Comparing Hybrid Peer-to-Peer Systems. Proceedings of the 27 th VLDB Conference, Roma, Italia,

46 46

47 EL PROCESAMIENTO DISTRIBUIDO EN INTERNET Fragati, Hernán M. Universidad Nacional de Luján, Licenciatura en Sistemas de Información RESUMEN El procesamiento distribuido en Internet se basa en la utilización de la infraestructura que provee la red con la finalidad de resolver problemas que requieran recursos de cómputo masivo. Este documento presenta y describe los proyectos curso más relevantes. 1. Introducción El procesamiento distribuido en Internet se basa en la utilización de la infraestructura que provee Internet, haciendo uso de sus comunicaciones, protocolos y máquinas interconectadas, para distribuir trabajo de procesamiento entre los distintos nodos, que generalmente son computadoras personales a las que se les asigna una pequeña parte de un problema mayor para contribuir a su solución. Además, en este esquema, es necesario la utilización de equipos centrales o servidores que se encarguen de enviar estas pequeñas porciones del problema y recibir los resultados, para luego unirlos y obtener la solución. Esto puede verse en la figura 1 El procesamiento distribuido llego a un nivel global con la maduración de Internet en la década de Dos proyectos en Internet han probado que el concepto trabaja sumamente bien, incluso mejor de lo que muchos expertos proyectaron a principio de los 90. El primero de estos proyectos actualmente utiliza una gran cantidad de computadoras en toda la red y fue llamado distributed.net, destinado a crackear claves encriptadas. El segundo, SETI@Home, es el más exitoso y popular de los proyectos de computación distribuida, y cuenta con la mayor cantidad de voluntarios. Está orientado hacia la búsqueda se señales extraterrestres. Ambos demostraron que el procesamiento distribuido puede acelerar los resultados disminuyendo los costos, siendo una alternativa claramente 47

48 superior ante la utilización de equipos de alto poder de cálculo, a la hora de lograr mayor potencia de procesamiento. En el mundo hay más de 400 millones de computadoras conectadas en Internet, muchas con una potencia similar a las supercomputadoras de la década de Dichas computadoras muy pocas veces llegan a utilizar todo su poder de procesamiento y la mayoría del tiempo se encuentran sin uso a la espera de algún cálculo para ejecutar. Es esta potencia la que se encuentra disponible a la espera de ser usada en algún proyecto de procesamiento masivo distribuido. [1], [2], [3] 1.1. Principios generales Figura 1 Procesamiento distribuido en Internet A continuación se presentan los principios generales del procesamiento distribuido en Internet como la heterogeneidad, escalabilidad, dinamismo y adaptabilidad, que deben ser tenidos en cuenta en la construcción de algún proyecto de este tipo. [4] Heterogeneidad: un proyecto de procesamiento distribuido en Internet debe abarcar una gran variedad de recursos heterogéneos, de manera que pueda incluir la mayor cantidad de combinaciones de sistemas operativos y hardware disponibles en Internet. Escalabilidad: Un proyecto de procesamiento distribuido en Internet debe tener la capacidad de crecer desde pocas máquinas hasta millones, por lo que hay que tener en cuenta los problemas que puedan generase 48

49 en las comunicaciones y en la capacidad de trabajo del servidor al aumentar la cantidad de máquinas o unidades de procesamiento. Dinamismo y adaptabilidad: Un proyecto de procesamiento distribuido en Internet debe adaptar dinámicamente su funcionamiento de acuerdo a los recursos con que cuenta, para obtener una máxima performance ya sea en la velocidad como en la veracidad de los resultados. Estos recursos o máquinas a menudo fallan, esto hace que los resultados nunca lleguen al servidor o lleguen erróneos, ya sea por fallas en las propias máquinas, en la comunicación o por culpa de intrusos. Por lo que para solucionar estos problemas será necesario determinar un tiempo de espera para los resultados, plantearse un esquema de seguridad para controlar dichos resultados y la utilizar cálculo redundante para chequeo. 2. Antecedentes A principio de 1970 cuando las computadoras se empezaron a conectar en red, nació la idea de agrupar ciclos de CPU no utilizados. Los primeros experimentos con computación distribuida fueron los programas llamados Creepeer y Reaper que corrían sobre el predecesor de Internet, ARPANET. En 1973 el Centro de Investigación de Palo Alto Xerox (PARC) instaló la primer red de área local Ethenet y puso en ejecución el primer esfuerzo completo de procesamiento distribuido. Este primer programa, el cual fue una creación de los científicos de PARC Jhon F. Shoch y Jon A. Hupp, recorría cien computadoras conectadas por ethernet. Sus autores lo consideraban como un gusano el cual se movía de computadora a computadora utilizando los recursos desocupados para llevar a cabo algún tipo de cálculo. Dicho programa funcionaba sobre toda la red del laboratorio de PARK, se replicaba en cada memoria de las máquinas, utilizaba los recursos disponibles, se reproducía y transmitía clones a los otros nodos conectados a la red. En otro esfuerzo Richard Crandall, un distinguido científico de Apple, utilizó los recursos de procesamiento disponibles en las máquinas de la red de NeXT para llevar a cabo un trabajo en conjunto. Para esto Cradall instaló un software que permitía a las máquinas ejecutar cálculos y combinar los esfuerzos con otra máquina de la red siempre y cuando no estuviesen en uso. Su software llamado Cilia, en un primer momento estuvo enfocado en el hallazgo de grandes números primos, luego siguió con pruebas de modelos de encriptación. [3] 49

50 3. Cómo se realiza el trabajo? Para construir un sistema de procesamiento distribuido en Internet lo primero que se debe tener en cuenta es la descomposición de un problema inicial entre varios subproblemas independientes. Por ejemplo en los proyectos relacionados con encriptación de datos el problema principal consiste en encontrar una clave que permita acceder a los datos encriptados, para esto es necesario probar todo un conjunto de claves una por una. Cada clave puede ser probada independientemente de las demás, de manera que dichas claves pueden repartirse entre varias computadoras para chequear cual es la correcta y de esa forma disminuir el tiempo de procesamiento. Supóngase que se tienen dos máquinas y las claves sólo pueden estar conformadas por números, repartiendo las pares a una máquina y las impares a otra es posible dividir el tiempo necesario para chequear todas las claves por dos. Ahora para trasladar esta forma de trabajo a Internet es necesario utilizar un esquema cliente servidor, para que el servidor sea el encargado de distribuir el trabajo y los clientes de efectuarlo, dichos clientes pueden ser computadoras personales conectadas a Internet. Por ejemplo en el proyecto de chequeo de claves RC5-56 de Distributed.net se tienen 2 56 claves para probar, las cuales se reparten entre 2 28 paquetes o bloques de 2 28 claves cada uno. Una vez determinado el problema y su división en subproblemas es necesario contar con una computadora con conexión permanente a Internet, la cual hará el papel de servidor en la que se instalará un programa que distribuirá los bloques de claves a demanda. Cada participante necesitará contar con una máquina conectada a Internet con el software cliente, el cual será el encargado de conectarse con el servidor y requerir un bloque de claves para luego chequearlas. Una vez finalizado el chequeo, este se conectará nuevamente con el servidor para devolver el resultado, por ejemplo he encontrado la clave o No he encontrado la clave, y también para requerir un nuevo bloque de claves. El servidor además de la tarea descripta anteriormente, debe mantener la información sobre los bloques chequeados y sobre aquellos bloques que han sido enviados pero que todavía no se tienen respuesta. También, en el caso de que solamente aquellas personas que estén registradas en el proyecto puedan hacer uso del cliente, es posible que el servidor también mantenga estadísticas actualizadas sobre: quien el más rápido, quien ha chequeado más claves y cuantos usuarios están participando del proyecto. 50

51 Es importante que el software cliente tenga la posibilidad de funcionar solo cuando el usuario no está utilizando la máquina, para que no haga que los demás programas funcionen mas lentos e interfiera en el uso normal de las aplicaciones que utiliza el dueño de la computadora. También el cliente debe soportar la mayor cantidad posible de sistemas operativos ya que Internet se caracteriza por su gran heterogeneidad. [5] 4. Ventajas El procesamiento masivo distribuido en Internet tiene varias ventajas que hacen de este una opción a tener en cuenta a la hora de implementar un proyecto que requiera poder de cómputo, a continuación se detallan las más importantes. La utilización de ciclos de CPU ociosos sin uso es lo que destaca a este esquema, aun cuando una computadora esté aparentemente trabajando, en realidad la mayoría del tiempo no esta aprovechado todo su poder computacional, por ejemplo una persona al escribir, a lo sumo puede presionar 10 teclas por segundo, esto no es mucha distracción para un procesador que puede ejecutar 100 millones de instrucciones por segundo, en este caso el procesador gasta más tiempo preguntando que tiene que hacer dentro de un ciclo. Además son muchas las oficinas en todo el mundo donde sus computadoras con conexión a Internet permanecen encendidas toda la noche. Este es el poder que está siendo derrochado y que puede ser usado para llevar a cabo algún tipo de investigación haciendo uso del procesamiento distribuido. Otra ventaja es que al hacer uso de Internet, las unidades de procesamiento y la comunicaciones ya existen, esto permite reducir drásticamente los costos siendo muy beneficioso frente al uso de grandes equipos de procesamiento paralelo, ya que lo único que se necesita es una máquina que funcione como servidor además del software cliente que deberán usar los dueños de las máquinas que estén conectadas a Internet. También algo importante para destacar es que este esquema es escalar, ya que permite la incorporación de todas las máquinas que se deseen sin la necesidad de realizar ningún tipo de modificación importante. Son millones las computadoras que se encuentran conectadas actualmente a Internet, el procesamiento distribuido es una alternativa para unir todo el poder de cálculo de las mismas hacia la búsqueda de un objetivo.[1] [6] 51

52 5. Restricciones El procesamiento distribuido en Internet tiene sus propias restricciones y obstáculos que deben ser tenidos en cuenta. Una de las principales barreras a considerar es convencer a los dueños de las máquinas de prestar los recursos de sus computadoras para ser usados en algún proyecto de procesamiento distribuido, ya que no a todas las personas les gusta que le utilicen recursos de su máquina por temor a que ésta baje el rendimiento. Una alternativa a esto es la utilización de la llamada computación parásita, esto se refiere a la utilización de la máquina sin conocimiento, ni consentimiento del dueño, simplemente haciendo uso en forma directa de algún recurso. Otro punto a tener muy en cuenta es el ancho de banda, el cual actualmente es muy limitado haciendo que la comunicación entre máquinas tenga una importante latencia, esto obliga a que solo determinados tipos de algoritmos puedan funcionar en este esquema. Por ejemplo un algoritmo de simulación de movimiento de partículas en un campo de fuerza, como una estrella o galaxia, en donde se asigna una partícula a cada máquina y que para analizar una partícula es necesario consultar con las otras máquinas, se hace imposible su funcionamiento eficiente en Internet debido a la lentitud de la comunicación. O sea que no es recomendable utilizar en este esquema aquellos algoritmos que requieran que las unidades de procesamiento se comuniquen entre ellas, siendo imposible, sobre todo, si la comunicación necesita ser muy fluída. Los algoritmos que más se adecuan a este esquema son aquellos de granularidad gruesa en cual cuenta con un número elevado de operaciones de cómputo y como consecuencia tiene pocas operaciones de comunicación. La capacidad de memoria es otra seria restricción. Los dueños de computadoras que deseen donar ciclos de su CPU, pueden no estar de acuerdo que alguien les ocupe gran parte de su memoria o disco de su máquina. Por lo que es recomendable que el cliente haga un uso racional de los recursos, siendo lo mas conveniente hacer que funcione solamente cuando la máquina no está en uso. Un obstáculo a considerar es la gran diversidad de máquinas y sistemas operativos a que hay en Internet, esto obliga a que el cliente abarque una amplia variedad de combinaciones, haciéndose más difícil su construcción, siempre y cuando se quiera abarcar la mayor cantidad de potenciales unidades de procesamiento. [6] 52

53 6. Proyectos En la actualidad son muchos los proyectos y de diversa índole que hacen uso de los beneficios del procesamiento distribuido en Internet. Entre ellos se pueden nombrar, dentro de los relacionados con la medicina, el de Popular Power que en este momento trata de ayudar a encontrar vacunas contra la gripe, el proyecto FightAIDS@Home relacionado con la enfermedad del SIDA y el proyecto Compute Against Cancer que fue la primera iniciativa que utilizó computo distribuido en la lucha contra el cáncer. También hay proyectos sobre biología molecular y bioingenieria como Folding@Home y Genome@Home. Otros como Evolution@Home se orientan hacia la biología evolutiva. En la rama de las ciencias del espacio el mas importante es SETI@home y por el lado de la criptografía se destaca Distributed.net. En otras ramas es posible encontrar proyectos sobre matemáticas como GIMPS, en Física como Gamma Flux y sobre predicción climatográfica como Casino-21. [7] 6.1. SETI@home Introducción SETI (Search for extraterrestrial Intelligence) es un área de investigación científica cuyo objetivo es detectar vida inteligente fuera de la tierra. Para esto es importante la búsqueda y análisis de señales de radio fuera de la tierra. Fuentes naturales que emiten señales de radio ocupan bandas anchas de frecuencia, mientras que las señales generadas por el hombre tales como la televisión y la radio tienen un ancho de banda estrecho; por lo que una señal con ancho de banda estrecho desde fuera del sistema solar sería evidencia de vida extraterrestre. En 1959 Morrison y Cocconi propusieron búsquedas cerca de 1,42 GHz de la línea de hidrogeno y basándose de esto varios proyectos han comenzado a trabajar en la búsqueda de señales extraterrestres. El proyecto SETI@home difiere de otros en cuanto a la sensibilidad, cobertura de frecuencia y cobertura del cielo, sin embargo sus análisis de datos tienen una forma similar: Calcula el espectro de potencia de la señal sobre el tiempo Aplica patrones de reconocimiento al espectro de potencia para identificar señales candidatas Elimina señales candidatas que puedan ser probablemente naturales o hechas por el hombre 53

54 Además el proyecto se diferencia de los de su tipo por ser el único que hace uso de computadoras conectadas a Internet para llevar a cabo los cálculos, mientras que los otros proyectos utilizan supercomputadoras estando limitados en la velocidad de procesamiento, en comparación a la velocidad que puede lograrse con el uso de las posibles unidades de procesamiento disponibles en Internet. SETI@home utiliza estos recursos públicos de cálculo y desde que comenzó a funcionar ha acumulado mas de 3 millones de participantes. La búsqueda de SETI@home asume que una civilización extraterrestre desea hacer contacto con otras especies emitiendo señales que son fácilmente detectables y distinguibles de emisiones naturales y de radio. [8], [9] Propiedades de las tareas de cálculo SETI@home tiene una tasa fija de tareas de procesamiento; mientras los datos son registrados a una tasa constante, los tiempos de CPU por unidad de datos son apenas constantes, esto hace que si las tareas de cálculo reciben poca potencia de CPU, la cola de unidades de datos a procesar crece, disminuyendo la velocidad global del sistema. Pero si hay demasiada potencia de CPU disponible el proyecto cuenta con dos elecciones: rechazar a los participantes o procesar cada unidad de datos múltiples veces. SETI@home escogió el cálculo redundante. Esto trajo como beneficio poder detectar y descartar resultados inválidos provenientes de procesadores defectuosos o usuarios malintencionados. Un nivel de redundancia de tres es suficiente para este propósito, pero como su número de participantes y el promedio de potencia de CPU ha aumentado su nivel muchas veces excede esto. Para los casos en que se supere el nivel de redundancia es posible implementar dos alternativas: rechazar a los participantes o modificar la aplicación para utilizar más CPU por unidad de datos. SETI@home ha realizado esto último dos veces. Las tareas de cálculo que implementa SETI@home tienen varias propiedades que las hacen ideales para el procesamiento con recursos públicos: [9] Alta proporción de cálculo de datos: cada unidad de datos toma 3.9 trillones de operaciones de punto flotante. En una Pentium II 500 el cálculo 54

55 demora aproximadamente 10 horas. El proceso de recuperación y envío de datos desde el servidor involucra bajar 350Kb y subir 1Kb, a un módem de 56Kb le toma alrededor de 60 segundos, siendo un pequeño inconveniente para los participantes. Esta alta proporción mantiene el tráfico al servidor en un nivel manejable. Paralelismo independiente: las unidades de cálculo son independiente unas de otras, de esta manera las computadoras nunca se deberán comunicar con las computadoras de otros participantes. Si una computadora falla mientras procesa una unidad de trabajo, esta es eventualmente asignada a otra computadora. Tolerancia de errores y omisiones: Si una unidad de datos se analiza incorrectamente solo afecta levemente al objetivo global. La omisión es remediada la próxima vez que el telescopio rastree el mismo punto Almacenando y distribuyendo los datos El radio telescopio de Arecibo, en Puerto Rico, es utilizado por una gran variedad de investigaciones astronómicas y atmosféricas. La fuente de datos de la cual hace uso SETI@home, una la banda de frecuencia de 2.5 MHz centrada en la línea de hidrógeno (1.42 GHz), es grabada digitalmente. Las señales grabadas consisten principalmente de ruido (provenientes de fuentes celestiales y receptores electrónicos) y señales terrestres hechas por el hombre (tales como estaciones de TV, radares, satélites). Los datos son tomados a 1 bit de resolución y grabados en cartuchos de cinta lineal digital (DLT) de 35 Gb. Cada 16 horas una cinta es completada. En Berkeley los datos son divididos en unidades de trabajo, separando las señales en 256 bandas de frecuencia, cada una aproximadamente de 10 KHz de ancho, a su vez cada banda es dividida en segmentos de 107 segundos, estos segmentos o unidades de trabajo están superpuestos por 20 segundos, asegurando que cada período de emisión este contenido enteramente en al menos un segmento. Las unidades de trabajo resultante son de alrededor de 350 Kb, la suficiente cantidad de datos para mantener a una típica computadora ocupada por varias horas, pero bastante pequeños para descargar con un módem lento en unos pocos minutos. La información sobre las unidades de trabajo y cintas, así como también muchos otros aspectos del proyectos son almacenados en tablas como las siguientes. 55

56 Nombre de la tabla Descripción Número de registros User Cuenta de Usuario (nombre, password, trabajos totales) 3.1 millones Platform Compilación (CPU + sistema operativo) 175 Version Versión compilada del cliente 657 Team Grupo de usuarios 81 mil Credit Trabajos totales por país, plataforma, etc. 435 mil Tape DLT cinta de datos 565 Workunit_grp 107 segundos segmento de datos 361 mil Workunit Unidades de trabajo 92 millones Result Resultado del análisis de las unidades de trabajo 281 millones Spike Señal candidata spike 2.1 billones Gaussian Señal candidata Gaussian 171 millones Triplet Señal candidata triplet 112 millones Pulse Señal candidata pulse 99 millones Un programa servidor data/result distribuye las unidades de datos a los clientes. Este utiliza un protocolo basado en HTTP a fin de que los clientes detrás de sistemas firewalls puedan contactar al servidor. Las unidades de trabajo son enviadas por round-robin en orden FIFO. Un programa recolector de basura remueve las unidades de trabajo del disco y limpia la bandera llamada en disco de dichas unidades en la base de datos. SETI@home experimentó dos políticas para borrar las unidades de trabajo: Borrar las unidades de trabajo para las que se hayan recibido N resultados, donde N es el nivel de redundancia. Si el dispositivo que almacena las unidades de trabajo se llena, la producción de dichas unidades de trabajo es bloqueada, esto provoca que disminuya el rendimiento de todo el sistema. Borrar las unidades de trabajo que han sido enviadas M veces, donde M es ligeramente mayor que N, esto elimina la disminución en el rendimiento nombrada en el caso anterior, pero trae como consecuencia que algunas unidades de trabajo nunca tengan resultados completos, cumpliendo el nivel de redundancia. Actualmente SETI@home esta utilizando esta política. 56

57 Figura 2 Sistema de distribución de datos de SETI@home En general SETI@home ha dividido su servidor en partes, tales como el programa que divide los datos en unidades de trabajo, el programa servidor data/result y el programa recolector de basura; estos son independientes unos de otros. Este sistema de distribución de datos puede verse en la figura 2. [9] El programa cliente Actualmente SETI@home distribuye su software cliente para 47 combinaciones diferentes de CPU y sistema operativo. Los usuarios pueden descargar este software desde el sitio web de SETI@home ( Para Microsoft Windows y Apple Macintosh, el cliente se instala por defecto como un protector de pantalla, que procesa datos solamente cuando el protector de pantalla está activo, pero puede ser configurado para procesar constantemente. Para otras plataformas, el cliente básico esta basado en texto, en estas los usuarios generalmente lo corren en segundo plano. Un programa de visualización gráfica similar a las versiones para Macintosh y Windows esta disponible para sistemas UNIX y Linux que corran las X Windows. Además una amplia variedad de aplicaciones de terceros han sido desarrolladas para mostrar los datos. Este programa cliente en forma repetitiva busca una unidad de trabajo desde el equipo servidor data/result, la analiza y retorna el resultado que es una lista de señales candidatas. Dicho cliente necesita una conexión a 57

58 Internet solo mientras se comunica con el servidor. El programa periódicamente guarda su estado en un archivo en disco y lee este archivo cuando comienza a funcionar, de esta manera lleva a cabo su progreso aún si la computadora es apagada frecuentemente. Analizar una unidad de trabajo involucra una gran cantidad de cálculo, donde se buscan varios tipos de patrones tales como Spikes, Gaussian, Triplet y Pulse. El programa cliente está escrito en C++ y su estructura esta compuesta de cuatro partes: Una plataforma independiente para procesamiento distribuido (6423 líneas) Componentes para una plataforma especifica, tales como la librería gráfica (2058 líneas en al versión UNIX) El código especifico de análisis de datos (6572 líneas) Código especifico de gráficos (2247 líneas) En la mayoría de las plataformas el cliente comprende un programa principal que realiza todas las comunicaciones y el procesamiento de datos, y un programa separado que muestra gráficos. La pantalla del programa cliente se muestra en la figura 3 [8], [9] 58

59 Figura 4 Sistema de recolección y análisis de resultados Figura 3 Pantalla del programa cliente de SETI@home Recolectando y analizando resultados Una gran parte del servidor de SETI@home esta dedicado a recolectar y analizar resultados. Ver figura 4. 59

60 Cuando un cliente termina de procesar una unidad de trabajo, envía los resultados al servidor data/result. Manipular un resultado involucra dos tareas: Científica: El servidor data/result graba los resultados en un archivo de disco. El programa de procesamiento científico lee este archivo y graba los resultados para cada unidad de trabajo en la base de datos, dichos resultados son las señales encontradas. Para optimizar el rendimiento varias copias de este programa corren concurrentemente. Contabilizadora: Para cada resultado el servidor data/result agrega al archivo de log o de auditoria una línea describiendo los resultados del usuario, su tiempo de CPU, etc. Un programa de procesamiento de cuentas lee este archivo de log y acumula en una memoria cache las actualizaciones a todos lo registros relevantes de la base de datos (usuario, equipos, créditos, etc.). Cada determinados minutos los datos del cache son enviados a la base de datos y este es vaciado. El próximo paso es la verificación del resultado donde se examinan todos los resultados redundantes para cada señal, los cuales pueden diferir en cantidad de señales encontradas y en sus parámetros, en base a estas se determina un resultado único para la unidad de trabajo. Estos resultados únicos son almacenados en una base de datos separada llamada Ciencia. En la fase final las señales hechas por el hombre son identificadas y eliminadas, luego aquellas señales candidatas de frecuencia similar junto con otras que posean las mismas coordenadas del cielo pero en tiempos diferentes o que tengan suficientes méritos, son aisladas para un análisis posterior. [9] Interacción con y entre los participantes SETI@home confía principalmente en su idea de proveer información y noticias para atraer participantes. Su sitio Web informa acerca del proyecto y permite bajar su software cliente, también provee información sobre el estado científico y técnico actual de dicho proyecto, entre otras cosas muestra los líderes, basándose en las unidades de trabajo procesadas, tanto por usuarios individuales como por categorías tales como país y dominio de mail. Los usuarios pueden formar equipos para competir y son reconocidos cuando pasan determinadas cantidades de unidades calculadas, también 60

61 pueden compartir información y opiniones. El sitio provee de encuestas relacionadas al proyecto. Muchos usuarios han creado software que muestran gráficamente el progreso del trabajo y han ayudado a traducir el sitio en 30 idiomas. [9] Historia y estadísticas SETI@home ha sido concebido por David Gedye en 1995 y comenzó a trabajar en El personal del proyecto es de tres empleados full-time y varios voluntarios part-time. En mayo de 1999 SETI@home liberó las versiones clientes para Windows y Macintosh, después de una semana alrededor de personas estaban corriendo el cliente. Este número ha crecido a más de 3.13 millones en julio de Usuarios de 226 países corren el cliente y alrededor de la mitad son de EEUU. En 12 meses a partir de julio del 2000, los participantes de SETI@home han procesado 178 millones de unidades de trabajo. El promedio de rendimiento durante este período fue de TeraFlops. [9] 6.2. Distributed.net Introducción Fundado en 1997, Distributed.net ha ido creciendo hasta agrupar a miles de personas de todo el mundo que brindan sus computadoras para dar potencia a dicho proyecto. El poder de procesamiento de distributed.net para inicios del 2001 creció hasta el punto de equivaler al trabajo de PC PII 266 Mhz., trabajando 24 horas al día, los 7 días de la semana, 365 días al año. Su infraestructura ha evolucionado a través de los años logrando soportar una amplia variedad de computadoras y sistemas operativos. Distributed.net tiene como finalidad proporcionar herramientas y medios de coordinación y comunicación para llevar a cabo cálculos paralelos en busca de la solución de algún problema definido. [10] Funcionamiento Para ser parte del proyecto es necesario descargar desde su sitio un programa cliente el cual será el encargado de comunicarse a la red de distributed.net y que procesará información de los desafíos en vigor, para lo cual dicho cliente debe ser el indicado de acuerdo a los desafíos en los que se quiere participar. La mayoría de los mismos se basan en la búsqueda de claves en mensajes cifrados por la familia de algoritmos RC5 y DES realizados por la empresa RSA Security ( la cual ha sido quien ha lanzado estos retos para probar la eficiencia de 61

62 dichos algoritmos. Para llevar a cabo esta búsqueda de claves en mensajes cifrados se hace uso de la fuerza bruta utilizando el poder computacional de todas las computadoras de la red de distributred.net probando todas las claves posibles hasta encontrar la correcta. El cliente, una vez instalado, intentará conectarse a uno de los servidores de distributed.net. El servidor será el encargado de proveer un bloque de claves, siempre y cuando se esté participando en algún desafío de desencriptación, el cliente realizará los cálculos necesarios en búsqueda de la solución, para lo cual tendrá que probar una clave por vez de dicho bloque. Un bloque típico comprende 2 28 claves y aunque muchos sistemas personales tardan alrededor de 30 minutos en su procesamiento, el tiempo exacto dependerá principalmente del procesador, de la memoria y la cantidad de procesos corriendo. Un vez que el cliente haya terminado de analizar las claves, enviará los resultados al servidor el cual entregará otro bloque de claves para continuar con el análisis.[10], [11] Proyectos pasados Desafío Cs-Cipher: este reto fue organizado por CS Communication y Sistems. Distributed.net encontró la clave para desencriptar el mensaje, el 16 de enero de 2000 después de testear mas del 98% del total de claves posibles en menos de dos meses. Este desafío fue muy importante para demostrar la debilidad de la clave de 56-bit contra la fuerza bruta. [12] DES III: Este proyecto comenzó el 13 de enero de 1999 a las 9 AM. Luego de 22,5 horas con las ayuda de EFF s Deep Crack, Distributed.net finalizó exitosamente con el desafío. [12] DES II-2: Igual que su predecesor, DES II-2 fue un certamen cronometrado. Sin embargo Distributed.net no fue capaz de encontrar la clave antes Electronic Frontien Foundation. [12] DES II-1: Este desafío fue un certamen cronometrado desde los laboratorios de RSA, comenzó el 13 de enero de 1998 y concluyó el 24 de febrero de 1998 obteniéndose la clave 76 9E 8C D9 F2 2F 5D EA que sirvió para desencriptar el mensaje que decía Muchas manos hacen el trabajo. [12] RC5-56: Terminó el 22 de octubre de 1997 cuando se descubrió la clave 0x532B744CC20999, la cual sirvió para obtener el mensaje que decía: Es tiempo de migrar a una longitud de clave mas larga. [12] 62

63 Proyectos actuales RC5-64: Este proyecto es un esfuerzo cooperativo de Distributed.net para afrontar el desafío de la clave secreta de 64-bit de RSA Security Inc. La tarea involucra testear a lo sumo 2 64 ( ) claves para encontrar la que desencripte correctamente el mensaje. Este proyecto requerirá de una enorme cantidad de potencia computacional para tener éxito. Actualmente el índice de procesamiento de la red RC5 es aproximadamente de 127,24 billones de claves testeadas por segundo. [12], [13] OGR (Optimal Golomb Ruler): En matemática el término regla Golomb se refiere a un conjunto de enteros no negativos tales que dos pares de números no tengan la misma diferencia, o sea que todos los pares de números tengan diferencias distintas. Conceptualmente esto es similar a una regla construida de tal manera que ningún par de marcas sobre la línea tengan la misma distancia que otro par. Una regla Golomb óptima es la regla Golomb más corta posible para un número dado de marcas. Una regla Golomb es una forma de colocar marcas a lo largo de una línea, de tal manera que cada par de marcas tengan una única distancia lineal, por ejemplo una regla golomb de 5 marcas es: 0,1,4,9,11. La distancia de esta regla es 11 y pasa a ser una de las reglas mas cortas con 5 marcas junto con la 0,3,4,9,11. El objetivo de optimizar una regla Golomb es obtener la más corta posible mientras no se duplique ninguna distancia medida. Las dos reglas de 5 marcas nombradas anteriormente son óptimas ya que no existe otra regla de 5 marcas con una distancia menor a 11. Sin embargo descubrir y probar ORG se hace exponencialmente más difícil con el incremento de marcas siendo necesario un mayor procesamiento, esta es la razón por la que Distributed.net hace uso de la potencia computacional brindada por sus miembros para obtener la regla Golomb óptima con 24 o más marcas. Las ORG tienen muchas aplicaciones incluyendo colocación de sensores para critalografía de rayos x y radio astronomía, además juegan un rol importante en combinatorias, teoría de las comunicaciones, etc. [14] El programa cliente 63

64 El cliente es un sistema extremadamente modular con los siguientes subcomponentes primarios: [15] Núcleos. Estas son las unidades de código que hacen el trabajo principal, puede haber múltiples núcleos dentro de un cliente. Cada proyecto tiene su propia colección de núcleos, los cuales pueden ser uno o más. De esta manera el proyecto ORG tendrá su propia colección de núcleos y el proyecto RC5 tendrá otra colección. Además cada colección esta subdividida de acuerdo a un procesador especifico o familia de procesadores para lograr mayores rendimientos. De esta manera para lograr que el cliente corra en la arquitectura x86 son necesarios los núcleos para 286, 486, P5, P6, K5, K6, Cx-M1, Cx-M2, etc. Similarmente, para la arquitectura Power/Power-pc son necesarios los núcleos específicos para cada generación de procesadores Motorola. Los núcleos son controlados por un controlador de núcleos. Este controlador es responsable de: Seleccionar un núcleo apropiado Convertir datos desde un formato genérico a un tipo apropiado Controlar la CPU usada por los núcleos Cargar el núcleo con trabajo, descargarlo cuando finalice y agrupar los resultados. Generar el fin del funcionamiento del núcleo. Hay un controlador de núcleos por proyecto. La interfase para el controlador de núcleos es el controlador de ejecución. Este es el encargado de seleccionar el controlador de núcleos que estará activo, de esta manera un determinado proyecto estará trabajando de acuerdo a la disponibilidad de datos que tenga, ya que la selección de un controlador de núcleos depende de los datos que provengan del servidor, o sea que si el servidor por razones como disponibilidad de recursos y priorización envía datos de un determinado proyecto, el controlador de ejecución seleccionará para poner en funcionamiento el controlador de núcleos del proyecto al cual pertenecen los datos. 64

65 El controlador de ejecución es a su vez controlado por un hilo de ejecución principal (o por un proceso principal en el caso de un ambiente que no sea multithread), el cual realiza tareas como reabastecimiento del buffer desde la red y maneja sus propios módulos de soporte como: consola I/O, manejador de señales, proceso de log, I/O red, buffer I/O, los cuales funcionan basándose en intervalos de tiempo salvo la consola I/O, el manejador de señales y el proceso de log, que están basados en eventos Arquitectura y comunicaciones El protocolo de comunicación es TCP, contemplando el uso del protocolo Socks para ambientes donde haya sistemas firewalls. La comunicación de la red de Distributed.net se lleva a cabo utilizando peticiones basadas en un esquema similar a HTTP. El cliente envía un pedido de datos (generalmente indicando el proyecto) y el servidor entrega los datos, en caso de no contar con dichos datos envía otros alternativos de otro proyecto. Luego de realizar el procesamiento necesario el cliente envía los resultados y pide nuevos datos. El cliente también soporta la entrada de datos utilizando mail. Figura 5 Estructura del cliente de Distributed.net Los paquetes de datos que circulan por la red entre el servidor y el cliente son equivalentes a los que reciben y envían los núcleos que hacen el procesamiento a excepción que los primeros tienen el agregado de encriptación y datos adicionales para controlar la integridad. La encriptación 65