apuntes_alexbm8_23_02_09

**Clase del 23 de Febrero de 2009**
Comenzamos la clase viendo el resumen de la clase anterior de alexbm8, el ejercicio 3 del bloque 1.1 de [|draxus] y los apuntes de una [|alumna] del año anterior sobre productos para sistemas grid, más en concreto sobre [|Cóndor]. A continuación comentamos la estructura de la [|primera práctica] de la asignatura, que se puede resumir básicamente en buscar 5 URLs relacionados con la asignatura. Para poder entregarla es necesario darse antes de alta en el sistema de entrega de prácticas de la asignatura (como login usar el correo institucional de la UGR). Para ver que estamos dados de alta, pinchamos sobre "[|Modificar datos personales]", donde podemos ver y editar nuestra información. La fecha de entrega de esta práctica es el 4 de Marzo de 2009.

Hecho esto se continuó con el tema de introducción, comentando las metas a conseguir con los sistemas distribuidos. Básicamente son las siguientes: Todas estas características no vienen en los SO por defecto, sino que deben ser añadidas. Para poder llevar a cabo un sistema distribuido se necesita hacer uso de servicios remotos, para la cual se usa [|RPC] (aunque existen otras tecnologías como DCOM, .Net o RMI de Java), que nos permite acceder con una interfaz rica a un procedimiento remoto. Este protocolo es esencial, por ejemplo, en [|NFS] (mediante el cual podemos conectarnos a directorios como si fuesen locales). RPC está directamente relacionado con la representación externa de los datos, pues debe permitir que sistemas con tratamiento interno de los datos diferente (pensar en [|"little endian" y "big endian"]) puedan comunicarse entre sí. También es muy importante la serialización o [|marshalling] (en Java "serialize"). A la hora de programa aplicaciones en sistemas distribuidos, se necesita una API. Existen varios estándares, uno de los más antiguos es CORBA, actualmente usado por [|Telefónica]. CORBA implementa la llamada remota a objetos, no a procedimientos, y es un lenguaje complejo (se podría decir que es el equivalente del COBOL para interfaces remotas). Hoy día es mucho más popular XML, gracias a su estilo de programación "basado en documento". XML es en realidad un metalenguaje, es decir, se utiliza para definir otros lenguajes, por lo que representa un sistema completo de programación. Otras interfaces más simples que también tienen éxito son las REST, donde las llamadas a procedimientos se encuentran en las URIs. Ejemplo de programas que pueden interactuar con la metodología REST son PERL o el elegante [|RUBY], con los cuales se comentó un programa ejemplo que devolvía la latitud y longitud de un pueblo o ciudad. Con este tipo de interfaces abiertos se pueden crear los llamados [|mashups], que combinan distintos servicios abiertos de Internet para ofrecer un nuevo servicio. Esta idea entra dentro de la filosofía de la web 2.0, donde se pretende crear una constelación de servicios que se puedan combinar entre sí. En el apartado 1.4 vimos alguna terminología relacionada con la computación distribuida. En primer lugar, tenemos que en función de cómo se descubre un recurso, el sistema podrá ser centralizado o distribuido. [|Napster] era un sistema centralizado, y por eso fue fácil acabar con él. Otro ejemplo de sistemas centralizados son los servicios de mensajería, aunque existen algunos, como [|Jabber] (aplicación OpenSource de mensajería instantánea que usa el protocolo [|XMPP]) donde la autenticación es centralizada pero la comunicación es distribuida. En general, los sistemas centralizados son menos robustos y menos escalables. Otro concepto importante es la disponibilidad, la cual está íntimamente ligada a si el recurso se encuentra alojado en un único emplazamiento o en múltiples lugares. Los [|aceleradores de descargas] pueden basarse precisamente en esto para lanzar varias peticiones a localizaciones diferentes, aunque también pueden (gracias a TCP) lanzar varios clientes en paralelo de forma que cada cliente descargue un fragmento del archivo total, y después se reensamble. Por último, se comentó cómo el recurso consultado debe propagarse a través de la red, existiendo la posibilidad de que la comunicación sea directa entre pares como en las redes P2P o a través de nodos intermedios, los llamados //brokers//. Una de las posibles utilidades de estos nodos intermedios es garantizar el anonimato de las comunicaciones mediante la modificación de las cabeceras correspondientes. Para finalizar, se comentaron las características principales de algunos sistemas de computación distribuída como [|BitTorrent] (donde la localización, comunicación y la disponibilidad son distribuidas, necesitan los trackers para efectuar búsquedas), Chord (usado principalmente en investigación y totalmente descentralizado) y SETI@Home (sistema totalmente centralizado, usa la técnica de //farming//).
 * Transparencia
 * Apertura: debemos usar protocolos abiertos, por ejemplo, los sistemas grid suelen usar [|SOAP].
 * Escalabilidad: el sistema no debe fallar con el incremento del número de nodos. Esta es una de las grandes ventajas de las redes P2P ya comentadas anteriormente.
 * Seguridad: engloba múltiples aspectos, pero algunos de ellos son, sin duda, la imposibilidad de que un nodo acapare todos los recursos de la red (evitar ataques de DoS), evitar que los usuarios se apropien de recursos privilegiados, etc.