6.2.

2 Relojes vectoriales
Los relojes lgicos de Lamport dieron pie a una situacin en la que
todos los eventos de un sistema distribuido se ordenan
completamente segn la propiedad de que:
Si el evento a ocurri antes que el evento b,
Entonces a tambin estar posicionado en un orden anterior a
b,
Es decir, C(a) C (b).
Mensajes enviados por los tres procesos:
T env(mi) al tiempo lgico en que se envi el mensaje mi.
T rec(mi) al tiempo de recepcin. Por construccin, sabemos
que para cada mensaje.
T env(mi) < T rec(mj).

mi = m1 y mj = m3, eventos ocurridos en el proceso P2,

m3 en realidad fue enviado despus de la recepcin del
mensaje m1.
m3 dependi de lo recibido con el mensaje m1.
T rec (m1) < T env(m2).
m2 no tiene que ver con la recepcin de m1.
Los relojes de Lamport no capturan la causalidad. La causalidad
puede capturarse mediante los relojes vectoriales.
Reloj Vectorial: Los relojes vectoriales se construyen de manera que
cada proceso Pi mantenga un vector VCi con las dos siguientes
propiedades:
1. VCi[i] es el nmero de eventos que han ocurrido hasta el
momento en Pi. En otras palabras, VCi[i] es el reloj lgico del
proceso Pi.
2. Si VCi[j] = k, entonces Pi sabe que han ocurrido k eventos en
Pj. As, ste es el conocimiento de Pi del tiempo local en Pj.

Propiedades:
La primera propiedad se mantiene incrementando VCi[i] ante la
ocurrencia de cada nuevo evento en el proceso Pi.
La segunda propiedad se mantiene encimando los vectores
junto con los mensajes que se envan.
Pasos de la Segunda Propiedad
1. Antes de ejecutar un evento (es decir, enviar un mensaje por la
red, entregar un mensaje a una aplicacin, o algn otro evento
interno), Pi ejecuta VCi[i] VCi[i] _ 1.
2. Cuando el proceso Pi enva un mensaje m a Pj, ste establece
el registro de tiempo de m, ts (m), igual a VCi despus de haber
ejecutado el paso anterior.
3. Una vez que se recibe el mensaje m, el proceso Pj ajusta su
propio vector configurando VCj[k] mx{VCj[k], ts(m)[k]} para
cada k, despus de lo cual ejecuta el primer paso y libera el
mensaje a la aplicacin.
Imposicin de la comunicacin causal: Al utilizar relojes
vectoriales, ahora ya es posible garantizar que un mensaje sea
entregado slo si todos los mensajes que causalmente lo preceden
tambin han sido recibidos. Para lograr tal esquema, supondremos
que los mensajes se transmiten dentro de un grupo de procesos.
Transmisin causalmente ordenada: Es ms dbil que la
transmisin totalmente ordenada que explicamos antes. En
especfico, si dos mensajes no estn relacionados de ninguna manera,
no nos interesa el orden en que se entregan a las aplicaciones;
pueden incluso entregarse en diferente orden en diferentes
ubicaciones.
Ejemplo:
Tres procesos P0, P1, y P2, En el tiempo local (1, 0,0), P1 enva un
mensaje m a los otros dos procesos. Despus de que lo recibe P1,
este ltimo decide enviar m*, el cual llega a P2 ms rpido que m. En
ese punto, la entrega de m* es retrasada por P2 hasta que m. haya
sido recibida y entregada a la capa de aplicacin de P2.

Una nota sobre la entrega ordenada de mensajes

Existen dos problemas principales con dejar que el middleware trate
con el ordenamiento de mensajes.
1. El middleware no puede decir qu contiene un mensaje, slo
captura la potencial causalidad.
Ejemplo: Dos mensajes del mismo remitente, totalmente
independientes, siempre sern marcados segn la causalidad
relacionada por la capa middleware. Este mtodo es excesivamente
restrictivo y puede ocasionar problemas de eficiencia.
2. No toda la causalidad puede captarse. El sistema del tablero de
comunicacin no capta esta causalidad.
Una desventaja de tener nicamente soluciones al nivel de aplicacin
es que el desarrollador se ve obligado a concentrarse en las
cuestiones que no se relacionan de inmediato con la funcionalidad
central de la aplicacin.
Ejemplo: El ordenamiento puede no ser el problema ms importante
cuando se desarrolla un sistema de mensajes tal como un tablero
electrnico de comunicacin, tener una capa de comunicacin
subyacente que maneje el ordenamiento puede resultar conveniente.
Abordaremos el argumento fin a fin varias veces, principalmente
cuando tratemos con la seguridad en los sistemas distribuidos.

11.5.1 Semntica de archivos compartidos

Cuando dos o ms usuarios comparten el mismo archivo al mismo
tiempo, es necesario definir con precisin la semntica de lectura y
escritura para evitar problemas.
La semntica establece normalmente que una operacin read sigue
a una operacin write.
La operacin read Regresa el valor que se acaba de escribir.
Asimismo, ocurren dos operaciones write en rpida sucesin,
seguidas por una operacin read, el valor ledo es el valor guardado
por la ltima operacin de escritura. De hecho, el sistema hace que
se cumpla un ordenamiento en tiempo absoluto en todas las
operaciones y siempre regresa el valor ms reciente.
Semntica UNIX:
Este mtodo de semntica UNIX (excepto por el problema mnimo de
que las demoras pueden provocar que una read ocurrida un
microsegundo despus de una write llegue primero al servidor, y que,
por tanto, se obtenga el valor viejo).
Todas las operaciones read y write se van directamente al
servidor de archivos, el cual las procesa estrictamente en
secuencia.
Una solucin alternativa es hacer ms flexible la semntica del
compartimiento de archivos. En lugar de requerir que una
operacin read vea los efectos de todas las operaciones previas
write, se puede establecer una regla que diga: Los cambios a
un archivo abierto inicialmente son visibles slo para el proceso
(o la mquina) que lo modific.
Semntica de Sesin:
La mayora de los sistemas distribuidos implementan semntica de
sesin. Esto significa que, aunque en teora siguen el modelo de
acceso remoto, la mayora de las implementaciones utilizan cachs
locales, que efectivamente implementan el modelo de carga y
descarga.
Con la semntica de sesin surge la pregunta acerca de qu
sucede si dos o ms clientes, al mismo tiempo, estn
guardando en el cach y modificando el mismo archivo.
Una solucin es decir que puesto que cada archivo se cierra en
su oportunidad, su valor es regresado al servidor, por ello el
resultado final depende de qu solicitud de cierre es la ms
recientemente procesada por el servidor.
Una solucin menos agradable, aunque ms fcil de
implementar, es decir que el resultado final es uno de los
candidatos, pero dejar la alternativa de cul sin especificar.

Semntica de compartimiento de archivos:

En un sistema distribuido es hacer que todos los archivos sean
inmutables. No existe, por tanto, ninguna forma de abrir un
archivo para escribir.
Las nicas operaciones en archivos son crate y read. Lo que s
es posible es crear un archivo enteramente nuevo e ingresarlo
al sistema de directorio con el nombre de un archivo previo
existente, que entonces se vuelve inaccesible (por lo menos con
ese nombre). Por tanto, aunque llega a ser imposible modificar
el archivo x, sigue siendo posible reemplazar atmicamente x
con uno nuevo.
Un problema un tanto ms difcil es qu hacer si un archivo es
reemplazado mientras otro proceso est ocupado leyndolo.
Una solucin es disponer las cosas de algn modo para que el
lector contine utilizando el archivo viejo, aun cuando ya no se
encuentre en el directorio, en forma similar al modo en que
UNIX permite a un proceso que tiene un archivo abierto
continuar utilizndolo, incluso despus de que ha sido borrado
de todos los directorios.
Otra solucin es detectar que el archivo ha cambiado y hacer
que fallen intentos subsiguientes de leerlo.
Una cuarta forma de ocuparse de los archivos compartidos en
un sistema distribuido es utilizar transacciones atmicas.
Si dos o ms transacciones se inician al mismo tiempo, el
sistema garantiza que el resultado final ser el mismo como si
se estuvieran ejecutando en algn orden secuencial (no
definido).

11.6.1 Almacenamiento en la memoria cach del lado del

cliente
Para ver cmo se realiza el almacenamiento en la memoria cach del
lado del cliente en la prctica, regresemos a los sistemas ejemplo NFS
y Coda.

Almacenamiento en la memoria cach en NFS

El almacenamiento en la memoria cach en NFSv3 se dej
principalmente fuera del protocolo. Este mtodo conduce a la
implementacin de diferentes polticas de almacenamiento en
la memoria cach, la mayora de las cuales nunca garantizan
consistencia.
El NFSv4 resuelve algunos de estos problemas de consistencia,
pero esencialmente contina dejando que la consistencia de la
memoria cach sea manejada en una forma dependiente de
una implementacin.

Cuando un cliente cierra el archivo, el NFS requiere que si las

modificaciones se han llevado a cabo, los datos guardados en
cach sean devueltos de inmediato al servidor. Este mtodo
corresponde a la implementacin de semnticas de sesin tal
como se vio con anterioridad.
El NFS requiere que siempre que un cliente abra un archivo
previamente cerrado que haya sido guardado (en parte) en
cach, el cliente debe revalidar de inmediato los datos
guardados en cach.
La revalidacin ocurre al verificar cundo fue modificado por ltima
vez el archivo e invalidando la memoria cach en caso de que
contenga datos obsoletos.
El servidor se encarga de verificar si la apertura de un archivo debe
tener xito o no, por ejemplo, porque las reservaciones de
compartimiento tienen que ser tomadas en cuenta.
El servidor seguir manejando las solicitudes de bloqueo de clientes
ubicados en otras mquinas simplemente con negar el acceso al
archivo a esos clientes.

El almacenamiento en la memoria cach del lado del cliente es crucial

para la operacin de Coda por dos razones.

En primer lugar, la finalidad del almacenamiento en cach es

lograr escalabilidad.

En segundo lugar, el almacenamiento en cach proporciona un

alto grado de tolerancia a fallas ya que el cliente se vuelve
menos dependiente de la disponibilidad del servidor.
Actualiza su copia local del archivo:
Cuando un cliente actualiza su copia local del archivo por primera
vez, lo notifica al servidor, el cual, a su vez, enva un mensaje de
invalidacin a los dems clientes. Tal mensaje de invalidacin se
conoce como ruptura del retorno de llamada, porque el servidor
desechar entonces la promesa de retorno de llamada que mantena
para el cliente al que acaba de enviar una invalidacin.
En ese caso puede utilizarlo siempre que el servidor an mantenga su
promesa de devolucin de llamada en relacin con el archivo para ese
cliente. El cliente deber comprobar con el servidor si la promesa
sigue siendo vlida. De ser as, no existe la necesidad de transferir el
archivo otra vez del servidor al cliente.
Almacenamiento de dispositivos porttiles:
Almacenamiento en la memoria cach del lado del cliente para
dispositivos porttiles Un importante desarrollo para muchos sistemas
distribuidos es que ya no se puede asumir que muchos dispositivos de
almacenamiento estn permanentemente conectados al sistema a
travs de una red.
En lugar de eso, los usuarios tienen varios tipos de dispositivos
de almacenamiento semipermanentemente conectados, por
ejemplo, mediante bases o estaciones. Ejemplos tpicos
incluyen PDA, computadoras porttiles y tambin dispositivos
multimedia porttiles tales como reproductores de pelculas y
audio.
En la mayora de los casos, se utiliza un modelo explcito de
carga y descarga para mantener los archivos en dispositivos de
almacenamiento porttiles. Las cosas se simplifican si el

dispositivo de almacenamiento es visto como parte del sistema

de archivo distribuido.
Existen varias tcnicas para garantizar con una alta probabilidad de
xito que probablemente los archivos a utilizar en realidad s estn
guardados localmente en el dispositivo.
Comparado con el mtodo de transferencia de datos segn la
demanda inherente a la mayora de los esquemas de
almacenamiento en memoria cach, en estos casos se tendran
que desplegar tcnicas de prebsqueda de archivos.
Sin embargo, para muchos dispositivos de almacenamiento

porttiles, es de esperarse que el usuario utilizar programas

especiales para preinstalar archivos en el dispositivo.