Apuntes_Victoria_26-02-07

Hoy veremos, entre otras cosas, por qué los sistemas distribuidos son tan buenos, y lo son por varias razones:
 * Por su buena **relación prestaciones/precio**.
 * Se puede conseguir **prestaciones** que no se podrían conseguir con computadores aislados. Vimos, por ejemplo, el otro día, el MareNostrum, que está formado por la unión de varios ordenadores, y se basa en la existencia de un middleware que hace que parezca que se trata de un único ordenador.
 * Son muy **fiables**, porque si falla un ordenador del cluster otro hace su función. La mayoría de los sistemas son **redundantes**. Por ejemplo, los servidores Web habitualmente tienen un frontend que reciben la petición y esa petición es atendida por distintos procesos http. Existen varios, de modo que si uno falla los otros pueden atender los procesos del que ha fallado. Los servidores Web suelen tener, además, varios bases de datos asociadas.

A continuación hacemos el primer bloque de ejercicios de autoevaluación.


 * 1) Ejemplos de sistemas P2P: PPLife, Joost (es un sistema parecido a YouTube, de distribución de vídeos, pero P2P, y es exclusivo para los sistemas Mac), Napster (aunque realmente no era puro. Tenía unos servidores centralizados para buscar la información, pero la información se transfería P2P), los servicios de mensajería instantánea (aunque la autenticación no lo es). Sin embargo, Google talk, no es P2P porque todo pasa por los servidores de Google.
 * 2) Vamos a identificar productos para crear cluster de computadores: el profesor ha propuesto openmosix, que se usa en muchas instalaciones comerciales.
 * 3) Producto para sistemas Grid: son productos que usan middleware. El único que conocemos es IGV, que es un producto que GridSystem ha liberado últimamente, y lo usan sobre todo empresas de farmacia... Podemos ver información del producto en el enlace: http://www.gridsystems.com/

En esta asignatura nos centraremos en la **computación masiva**. Trataremos sobre todo de paralelizar algortimos, que es el gran reto de la computación distribuida.

__Características de la computación distribuida__

En la computación distribuida hay muchísimas cosas a tener en cuenta:
 * La red es **no fiable**. Cuando haya un error en la red no se debría descolgar la aplicación, y los errores son muy frecuentes y pueden ocurrir en cualquier nivel.
 * Además, no se debe suponer que la **latencia** es nula, sino que existe y es variable en función del enlace. Un ancho de banda alta no supone necesariamente una latencia baja. En una red distribuida, cada nodo puede estar en un nivel de profundiad distinto. Evitaremos las aplicaciones síncronas porque desperdiciaríamos mucho tiempo.
 * El **ancho de banda no es infinito!** La red se va a saturar, más tarde o más temprano, aún en sistemas P2P puros como Gnutella, que se descubrió que cuando se superaba un número de nodos la red se saturaba.
 * La red **no es segura** a nivel de clientes, siempre tendremos que asumir que los clientes están engañando. En SETI@home, por ejemplo, se comprobaba que los datos que se mandaban eran ciertos.
 * La **topología cambia** continuamente en sistemas distribuidos. De hecho, una vez por ejemplo se cayeron varios servidores DNS de la Universidad de Granada y nadie se dio cuenta.
 * No es cierto que haya un solo **administrador** en una red distribuida.
 * Enviar un paquete por la red tiene cierto **coste**: cuesta capacidad, ancho de banda..., y todo esto tendremos que tenerlo en cuenta al enviar algo.
 * No se debe suponer que la red es homogénea. De hecho, es sumamente **heterogénea**.Ni siquiera debemos suponer que es homogénea en órdenes de magnitud, porque pueden haber conectados equipos de muy distinas características.

Las Características de un sistema distribuido deben ser:
 * **Transparencia**: los recursos estarán identificados por url.
 * Deben estar especificados por **protocolos abiertos**.
 * Los sistemas deben ser **escalables**. Se suele buscar el escalado lineal, que cuando se añade un nodo más, se produce una mejora en las prestaciones de 1, si se añaden 10, se consigue una mejora de 10.
 * T**olerancia a fallos**.
 * La pertenencia a la red debe ser **segura**, de modo que no haya intrusiones y se garantice una determinada QoS a todos los usuarios.

¿Cómo se consigue todo esto? Generalmente se usan recursos remotos (RPC). A veces también se realizan llamadas a objetos remotos.

(Ahora el profresor ha explicado CORBA, pero me he perdido... )

DCOM, es el sistema que utiliza Microsoft para acceder a objetos remotos, pero está siendo sustitudo por .Net, que se basa en la existencia de una máquina virtual sobre la que se pueden utilizar muchos lenguajes (filosofía parecida a Java). Sin embargo, .Net, pese a que es estándar, es muy dependiente de Microsoft.

RMI, invocación de métodos remotos, tiene un problema, y es que es específico de Java. Esto implica que no se puede llamar a una función RMI con C o Perl.

Actualmente se está usando el lenguaje XML. AJAX es una tecnología que combina XML en el cliente y Javascript en el servidor, y lo estudiaremos en el primer taller.

Se están popularinzando muchos las interfaces simples, como REST. Es una forma muy simple de acceder y se puede utlizar desde cualquier lenguaje. **Las peticiones son sin estado y sin memoria**. Se está haciendo muy popular y se usa, por ejemplo, en el servicio GEONames, que devuelve las coordenadas para un pueblo determinado. Funciona poniendo el URL y especificando los parámetros. Vamos a ver un ejemplo de un programa que utiliza esto (el programa está escrito en Perl). El programa son únicamente 4 líneas:

code
 * 1) !/usr/bin/perl

use LWP::Simple; # La directiva use equivale a import de Java. Estamos importando de forma general, ¡# aunque se puede hacer de forma selectiva. use URI::Escape; # Para codificar en URI.
 * 1) Busca pueblos de Granada y devuelve la long/lat

my $pueblo = uri_escape( shift ); # shift coge el primer elemento de una matriz, en este caso el primer #argumento de la línea de comandos, y se pasa a una variable local

my $resultado = get("http://ws.geonames.org/search?q=$pueblo&country=Spain"); # Se crea una cadena en la        # que $pueblo tiene su valor. Lo que estamos haciendo es bajarnos la página Web.

my ($lat, $lng) = ( $resultado =~ m{ ([\d\-\.]+) \s+ ([\d\-\.]+) }gs );
 * 1) Se trata de una expresión regular que coge una parte del fichero y lo mete en los varaibles.

print "La latitud y longitud de $pueblo es $lat:$lng\n"; code
 * 1) Se imprime.

Con este programa comprobamos lo sencillo que es acceder a procedimientos remotos.

¿Cómo se haría esto en Ruby?

code
 * 1) !/usr/bin/ruby

require 'net/http' require 'uri'

pueblo = ARGV[0] respuesta = Net::HTTP.get( URI.parse( URI.escape('http://ws.geonames.org/search?q='+pueblo+'&country=ES') ) ) respuesta =~ / ([^<]+)<\/lat>\s+ ([^<]+)<\/lng>/ print "Las coordenadas de #{pueblo} son latitud=#$1 y longitud=#$2" code Comentarios del programa: En la primera línea cogemos el argumento A continuación pasamos la cadena a formato URI. En la tercera hacemos de nuevo uso de una expresión regular, y finalmente interpolamos e imprimimos.

Este programa es mucho más compacto y elegante, no tiene puntos y comas, símbolo del dolar....

¿Cómo se haría esto en Java? Sería mucho más largo, por eso solemos utilizar lenguajes de script.

Hay otros tipos de interfaces abiertos como SOAp... Todo esto permite crear los mashups, que son combinaciones de aplicaciones de Internet, crean una combinación de la interfaz de varias aplicaciones distintas.

A continuación tenemos el siguiente bloque de ejercicios.

__Tipos de sistemas de computación distribuida.__

Los sistemas de computación distribuida tienen tres fases:


 * 1) **Descrubrimiento**: cómo se descubre a qué recurso tienes que conectarte. En la Web descubrimos los servicios a través de los buscadores, por ejemplo.
 * 2) **Disponibilidad**: puede estar centralizada o distribuida. En Gnutella, las búsquedas están centralizadas pero la disponibilidad, descarga, es distribuida.
 * 3) **Comunicación**: puede ser sin mediar (sólo intervienen dos pares) o mediada, como Google Talk.

Dependiendo de estos tres parámetros podemos distinguir distintos tipos de sistemas distribuidos. Por ejemplo, en Bittorrent se descubre un enlace con un buscador, el descubrimienro de recursos es pues centralizado. Chord es un sistema en el que cada nodo de la red tiene un hash y el descrubrimienro se hace teniendo en cuenta esa distribución en árbol de las tablas de hash. En el descubrimiento de recursos es necsario conocer ese hash. SETI@home tiene descubrimiento centralizado y en general todo es centralizado.


 * La idea con la que nos debemos quedar es que existen sistemas P2P que realmente lo son, y otros que, aunque se llamen P2P, no satisfacen las características. Para saber si un sistemas es P2P o no debemos estudiar las propiedades anteriores.**

Tercer bloque de ejercicios. 1- Buscar en Gnutella, en Bittorrent y en eMule algo que esté muy demandado (por ejemplo, primera temporada de House) y comparar tiempos. Cuando el bitácora esté preparado comentaremos los resultados obtenidos.