Sistemas Distribuidos

Transparencia:
Queremos que el usuario no note la diferencia con un sistema normal.
Transparencia de ubicacion: los usuarios no deberian saber donde estan los recursos que usan.
Transparencia de migracion: los recursos se pueden mover cuando se considere sin que el usuario lo note.
Transparencia de replicacion: los recursos pueden copiarse sin que el usuario lo note.
Concurrencia / Paralelismo

Veamos? algunos problemas de bajo nivel y algunas soluciones:
IPC: no tenemos memoria compartida. Nos tenemos que conformar con mensajes.
Broadcast: una operacion atomica. Queremos que el mensaje les llegue a todos o a ninguno. Como asegurarno? como en comunicaciones solucionamos mensajes perdidos con ACKs.
Sincronizacion de relojes: al tener varios relojes en nuestro sistema, algunos mas rapidos y otros mas lentos, necesitamos alguna forma para evitar problemas (podria haber problemas con el make, por ejemplo).
Lamport propuso una solucion basada en esta observacion: dos procesos que no interactuan no necesitan sus relojes sincronizados, si no, dados dos eventos a y b en un proceso, con a pasando antes que b, queremos que T(a) < T(b). Si a es el envio de un mensaje y b su recepcion, queremos que T(a) < T(b). Para dos eventos distintos a y b queremos T(a) != T(b). (Study lamport clock).
Exclusion mutua: como hacemos un lock? podemos usar un proceso handleador de locks, al que le haces requests por ese lock y te lo da o no. Esto tiene el problema de que si el proceso coordinador se cae, se pudre todo, un proceso que pida el lock no nota la diferencia entre "estoy muerto" y "no te voy a dar el lock todavia". Como podemos tener en cuenta esto en Erlang? 1. mandar ACKs, 2. links, la VM de Erlang implementa heartbeats. Con links podemos solucionar estoa costa de un numero indeterminado de mensajes (los heartbeats), una solucion distribuida, en cambio:
- Cuando alguien quiere entrar en una RC (region critica) le manda un aviso a todos.
- Cuando alguien recibe este aviso, si no quiere entrar, manda un OK.
- Si tambien quiere entrar, desempata por el tiempo de envio del mensaje.
Ventajas: no necesitamos mandar mensajes cuando nadie quiere entrar.
Desventajas: hay que conocer a todos los procesos de antemano.

Se puede usar un token ring tambien, nodos conectados en ronda, y solo uno tiene el token:
contras: se se cae un nodo se rompe el anillo, hay que usar ACKs y reconstruirlo en ese caso, ademas, muchos mensajes (paso del token) cuando nadie quiere entrar).

Eleccion: no hay que descartar los algoritmos centralizados que usen una especie de coordinador. Pueden ser mas simples que las versiones distributidas.
Veamos como podemos elegir un coordinador a partir de procesos iguales, cuando no sabemos quien esta vivo y quien no.
Erlang? podemos usar links, sabemos quien se cayo y quien no, y listo, problema solucionado.
Abajo de esto las VM pueden utilizar algo asi, si todas se mandan heartbeats a todas, para n maquinas tenemos O(n^2) mensajes por cada latido, si eligen una encargada, pueden reducir esto a O(n).
Algoritmo del Bully:
Cuando un proceso detecta que el coordinador no responde:
1. manda un msj de ELECCION a los prpocesos de numeros mayor.
2. si alguien le responde, se desentiende. El que respondio manda a su vez el mensaje ELECCION.
3. si nadie responde, el proceso es el que gana y asume como coordinador. Le manda un mensaje al resto avisando.
4. cuando un proceso vuelve a estar disponible, organiza una eleccion.