Introducción El siguiente trabajo muestra el desarrollo y puesta

Introducción
El siguiente trabajo muestra el desarrollo y puesta en funcionamiento de la simulación del
algoritmo de Lamport para sincronización de relojes. Este algoritmo prefiere no usar los relojes
físicos como punto de comparación para establecer un orden entre procesos, sino el orden en que
llegan.
El paso de mensajes es el método utilizado para implementar este algoritmo.
Marco Teórico
Sincronización de relojes en SOD
Cuando se desfasa el reloj de una computadora, no es tan grave considerando que todos los
procesos de esa computadora utilizan el mismo reloj. Habrá, dentro de todo, una consistencia
interna. Pero al trabajar con varias máquinas nos enfrentamos con el problema de sincronizar los
relojes entre ellas.
Las diferencias de oscilación entre los distintos relojes generan valores distintos para el
mismo momento de tiempo: es lo que llamamos distorsión del reloj.
Algoritmo de Lamport
Lamport desarrolló su algoritmo en el año 1978 y lo perfeccionó en 1990. En primer lugar
señala que la sincronización no debe ser absoluta, sólo entre procesos que la necesitan. Si 2
procesos no interactúan, aunque estén en distintas máquinas, no la necesitan.
En segundo lugar señala que no es tan importante la hora en que se producen los eventos,
si no, el orden. Por ejemplo, entre dos procesos A y B importaría si un evento de A ocurrió antes o
después que un evento en B, no la hora exacta de ocurrencia.
Además, lo importante es que se logre una sincronización de hora aunque no refleje la hora
real (las máquinas pueden estar sincronizadas como si fueran las 9.30 aunque en realidad sean las
10...).
Por esto se habla de relojes lógicos. Cuando además se exige que la sincronización coincida
con el tiempo real, hablamos de relojes físicos. El algoritmo de Lamport sincroniza relojes físicos.
El algoritmo parte definiendo una relación “ocurre antes de”, que nota .. Por ejemplo,
ab indica “a ocurre antes de b”.
Analicemos las dos situaciones que se pueden presentar:
1. Si a y b son eventos del mismo proceso y a ocurre antes de b, entonces ab.
2. Si a es el evento que envía un mensaje a un proceso y b es el evento de recepción del
mensaje por parte de otro proceso, entonces ab debe ser verdadero pues siempre enviar debe ser
anterior a recibir.
Otra característica a destacar es la transitividad de la relación. Si ab y bc, entonces ac.
Cuando los eventos son concurrentes no se necesita aclarar cuál de ellos ocurrió
primero. Es decir: si x e y son eventos en procesos diferentes que no intercambian mensajes ni
siquiera a través de un tercero, no importa si xy o si yx.
Lo importante para la implementación del algoritmo es que dado a, se encuentre un
valor de tiempo C(a), de manera tal que si ab entonces C(a) < C(b).
Si a es el evento de enviar un mensaje y b es el evento de recibir un mensaje, donde a
y b ocurren en máquinas diferentes, de ver ser C(a) < C(b).
C siempre debe ir hacia delante, es decir, ser creciente. Si se corrige, siempre debe ser
sumando un valor positivo.
El gráfico representa 3 procesos P0, P1 y P2, en 3 máquinas diferentes. Cuando el reloj
marca 6 en el proceso P0, marca 8 el de P1 y 10 el de P2.
Cuando P0 envía un mensaje A a P1 el tiempo que tarda depende de cual reloj elegimos. El
reloj de P1 lee 16 cuando llega. Considerando que el mensaje porta el tiempo de envío del mensaje
(6), P1 según su marca (16) determinará que el envío tardó 10 marcas de reloj. Si analizamos que
desde P1 sale un mensaje a las 24 y el P2 marca 40 a su llegada, el tiempo de envío fue de 16.
Si bien estos valores no son reales, respetan la relación ab entonces C(a) < C(b).
Veamos ahora otro caso que involucra envíos de P2 a P1 y de P1 a P0.
- Un mensaje C que va de P2 a P1, sale en 60 y llega en 56.
- Un mensaje D que sale de P1 en 64 y llega a P0 en 54.
En estos casos no se cumple ab entonces C(a) < C(b). Si el evento en P2 sale en 60, debe llegar a
P1 en 61 o más. Lo mismo ocurre con el evento P1 a P0: si salió en 64 debe llegar en un número
posterior mayor.
La solución de Lamport consiste en que si el evento sale en el momento 60, debe llegar
en 61 o más. Cada mensaje porta el tiempo de envío (de salida, según el emisor). Al llegar al
receptor, si el valor de reloj del receptor es menor, se le asigna una unidad más que el tiempo de
envío, es decir, 61.
En el caso del envío de P1 a P0 el 54 que muestra el gráfico se transformará en 70.
Veamos como queda el gráfico luego del cambio de valores:
La solución debe respetar que dos eventos del tipo que estamos analizando no pueden
ocurrir en el mismo tiempo. SI un proceso envía dos mensajes aunque sean muy seguidos uno de
otro, debe haber una marca (tick) de reloj entre ambos.
Además, si dos eventos ocurren en el mismo tiempo, por ejemplo 20, uno será 20.1 y el otro 20.2.
Resumiendo, las condiciones para la asignación de tiempos a los eventos que ocurren en un SOD
son:
1. Si a ocurre antes de b en el mismo proceso, C(a) < C(b).
2. Si a y b son eventos de envío y recepción de mensajes, C(a) < C(b)..
3. Para todos los eventos a y b, C(a) =/ C(b).
Código fuente y explicación
Receive
Explicación:
Esta parte del código simula un reloj de tiempo en minutos,
que se presenta en un indicador llamado milisecond timer.
Debido a que cuenta en milisegundos lo divido entre 60000
para convertirlo en minutos y presentarlo en un indiciador
llamado Minutos.
Teniendo un pequeño retardo de 60 milisegundos.
Convierto los minutos presentados en el indicador Minutos en
string para usarlos posteriormente en el código de sender.
Descripción de los objetos utilizados
El funcionamiento básico de receiver (resivir) es:
1. Se abre el puerto 61557 UDP Open de la computadora local, por la cual va a llegar el
dato de la computadora remota.
2. Se ejecuta el objeto UDP read que es que saca la información del puerto, lo saca en
formato string (identificado por una línea color rosa).
3. Se calcula la longitud de la información leída, con el objeto string lenght.
4. Si el resultado es diferente de cero, o sea, si se mandó algo, entonces, se concatena un valor
vacío, con el valor del mensaje y una indicación de fin de línea.
5. Este mensaje enviado, que es un numero originalmente, pero leído del UDP read como
string, lo convertimos a numero de nuevo.
6. Este numero, que es la hora de envío del mensaje (Sendme Hour) la comparamos con la
hora que tenemos localmente. Si la hora de envió es mayor que la de recepción …
a. Y la diferencia entre las dos horas es menor que 1 ( 60 segundos).
i. Manda un mensaje: “Estamos sincronizados”.
b. La diferencia es mayor de 1 …
i. Muestra el mensaje: “Adelante este reloj x+1 minutos”.
Donde :
X: Diferencia entre la hora de envío y recepción.
7. Después de realizar todo esto, se cierra el puerto udp con el objeto UPD Close.
8. Y si por alguna razon el puerto udp local no se pudo abrir, manda un mensaje de error.
El funcionamiento de sender (enviador) es:
1.- Se abre el puerto local numero 61556 por el cual se va a enviar el mensaje (Local port)
y se conecta como dato al objeto UDP Open, que es el que va a abrir el puerto local para
que salga el mensaje.
2.- Se especifica el Remote Host al cual se va a enviar y tiene una constante con el puerto
por el cual se va a recibir la información en la computadora remota, que es el 64557. Estos
datos se introducen en el objeto UDP writer.
3.- El mensaje que se envía es la hora simulada, convertida en formato string y que se
muestra en el indicador tipo string, llamado Data send.
4.- Si existiera un erro al abrir el puerto de salida, marca un error.
5.- Se cierra el puerto udp con el objeto UPD Close.
Pantallas (funcionamiento)
Receive
Sender
Agradecimientos
Al profesor Miguel Ángel López, maestro del Instituto Tecnológico de Tijuana.
Al Ingeniero de aplicaciones de National Instrument, Benjamín C.
http://forums.ni.com/ni/board/message?board.id=6170&message.id=1818
Conclusión
La sincronización de relojes no es un proceso fácil de diseñar e implementar.. Se requiere
de tomar en cuanta factores como ….
- La congestión de la red.
- Si se envían uno o varias veces el mismo mensaje.
- Si se requiere mensaje de respuesta de recibido.
Además de el proceso ya por demás difícil, de sincronizar o verifica que los procesos lleven
un orden para que no haya perdida o inconsistencia de información.