Introducción y objetivos La sincronización - GTI

E.E. Telecomunicación Curso 12/13 

Tema 6. El Tiempo. La Coordinación Distribuida. 

La Comunicación de Grupo 

1. Introducción y objetivos 

2. Sincronización 

3. Algoritmos de sincronización 

4. Tiempo lógico 

5. Coordinación distribuida 

6. Comunicación de grupo 

Tema 6 El tiempo y la coordinación distribuida 1 

Introducción y objetivos 

• Tiempo: herramienta para ordenar 

acontecimientos 

• Evento: acontecimiento que aparenta ocurrir 

indivisiblemente 

– ejemplo: recibir un mensaje de red 

– evento mínimo: ejecución instrucción de ensamblador 

• Resolución temporal: período entre dos 

actualizaciones consecutivas del reloj 

• Aplicación del tiempo en Sistemas Distribuidos: 

– mantenimiento consistencia de objetos replicados 

– autenticación, etc. 

• Necesidad de un tiempo único ⇒ sincronización de 

relojes 


Introducción y objetivos 


La sincronización 


Sistemas Operativos Distribuidos y de Tiempo Real 1


La sincronización 

• Sincronización en un paso ⇒ deriva de los relojes 

– necesidad de sincronización periódica ⇒ necesidad de 

referencia temporal 

• sincronización interna ⇒ precisión limitada por paso de 

mensajes 

• sincronización externa ⇒ fuente externa fiable (UTC) 

• UTC (tiempo universal coordinado): 

– tiempo atómico internacional ⇒ segundo normalizado 

(9.192.631.770 Cs 133 ) 

– emisión de señales desde estaciones terrenas y satélite 

– problemas: 

• precisión de las señales recibidas 

• mala o nula recepción en interiores 

⇒ necesidad de conjugar las dos técnicas (interna y 

externa) 


Compensación de la deriva del reloj. 2 

• Si S tiene que dar el tiempo real después 

de N períodos: 

T SKEW = (1 + a) * h + b 

T REAL + N = (1 + a) * (h + N) + b 

• Resolviendo las ecuaciones, obtenemos: 

a = (T REAL - T SKEW) / N 

b = T SKEW - (1 + a) * h 



• Definiciones: 

– S : tiempo dado a las aplicaciones (reloj sw) 

– H : tiempo del reloj hw 

– d : factor compensador 

– S(t) = H(t) + d(t), donde: 

• d(t) = a * H(t) + b 

– T SKEW : valor reloj sw cuando H == h 

– T REAL : tiempo real cuando H == h 

– Pueden darse las 2 circunstancias: 

• (T SKEW > T REAL) ó (T SKEW < T REAL) 



Compensación por atraso Compensación por adelanto 




Algoritmos de sincronización 


Método de Cristian. 2 

• Servidor único de tiempo: puede conectarse a 

UTC 

– el proceso P envía mensaje m s solicitando el tiempo 

al servidor S 

– S envía el tiempo en m r 

– P ajusta su reloj utilizando el tiempo recibido en m r 

• Problemas: 

– sincronización del servidor con el receptor UTC 

• si lo hay 

– duración variable del tiempo de transmisión de los 

mensajes en la red, y del tiempo de respuesta del 

servidor 



Sistemas Operativos Distribuidos y de Tiempo Real 3 

Cliente 

P 

m s 

m r 

Método de Cristian.1 

Servidor de tiempo 

S 

Descripción del algoritmo de Cristian. 1 

• T ciclo = T tx (m s ) + T proc (S) + T tx (m r ) 

• P guarda el T ciclo 

– se necesita suficiente estabilidad reloj de P 

• Sea t el tiempo devuelto por S en m r . 

• P ajustará su reloj según: 

t final = t + T ciclo /2 

• Los tiempos de transmisión de los mensajes 

son: 

T tx (m s ) = t min + x 

T tx(m r ) = t min + y 

– donde t min es el tiempo mínimo de transmisión en la 

red 

Tema 6 El tiempo y la coordinación distribuida 12


Descripción del algoritmo de Cristian. 2 

• El verdadero valor del reloj de S cuando P recibe 

m r estará en el rango: 

reloj ∈ [t + t min , t + T ciclo - t min ] 

• Precisión de la aproximación: 

± (T ciclo /2 - t min ) 

• Puntos débiles: 

– problemas del servidor único: sobrecarga y caída 

⇒ solución: grupo de servidores sincronizado 

– problema del servidor impostor 

⇒ solución: autenticación del servidor 

– problema del servidor con reloj que falla 

⇒ solución: algoritmo de Berkeley 


Algoritmo de Berkeley. 2 

• Desarrollado para el UNIX BSD 

• Orientado a la sincronización interna 

• Se elige a un ordenador coordinador para 

que actúe como maestro 

• El maestro interroga a los esclavos que se 

quiere que estén sincronizados 

• El maestro estima el valor de los relojes de 

los esclavos (como en el de Cristian) 


inicio sondeo 

respuesta 

envío desfase 


Esclavo Maestro 



• Con los valores estimados y el suyo propio, el 

maestro realiza un promediado de los tiempos 

⇒ se cancelan en media los efectos de la deriva 

• Este promediado es tolerante a fallos: elimina 

lecturas de relojes que han derivado mucho 

• El maestro envía a los esclavos la cantidad 

(positiva ó negativa) con que debe ajustar su 

reloj: 

⇒ se elimina la influencia del tiempo de transmisión 

• Si el maestro falla: 

⇒ un esclavo debe ser elegido como maestro 




Protocolo de Tiempo de Red: NTP 

• Diseñado para distribuir el tiempo sobre un conjunto de 

redes interconectadas (Mills, 1991) 

• Adoptado como estándar para sincronización de relojes 

a través de Internet 

• Propiedades del NTP: 

– proveer un servicio que permita a clientes a lo largo de 

Internet estar sincronizados con precisión con el UTC 

– proveer un servicio fiable que pueda sobrevivir a pérdidas 

largas de conectividad 

– permitir que los clientes puedan resincronizarse con la 

suficiente frecuencia 

– uso de técnicas de autenticación para verificar el origen 

de los datos 


NTP : estructura de la sub-red de sincronización. 2 

• Servidores primarios (estrato 1) conectados a UTC 

• Servidores secundarios (estratos superiores) 

sincronizados en último lugar con los primarios 

• El nivel más bajo (nº de estrato más alto ⇒ hojas) 

de la sub-red lo constituyen los servidores de 

tiempo de las máquinas de los usuarios 

• Los relojes son menos precisos cuanto mayor es el 

número de estrato ⇒ NTP tiene en cuenta el T ciclo 

total del mensaje hasta la raíz (estrato 1) 

• En caso de fallo ⇒ reorganización de la sub-red 

– implica resincronización 


NTP : estructura de la sub-red de sincronización. 1 



1 

2 2 

3 3 3 

NTP 

• Modos de sincronización entre servidores: 

– Modo multicast: diseñado para redes locales 

⇒ precisión baja, pero generalmente suficiente 

– Llamada a procedimiento: similar al de 

Cristian 

⇒ mayor precisión (usado si el hw no soporta 

multicast) 

– Modo simétrico: diseñado para servidores 

maestros (estratos más bajos, y los que dan 

servicio a LAN) 

⇒ precisión máxima 

• Transmisión de mensajes no fiable 

mediante UDP en todos los modos 



Servidor B 

Servidor A 

Algoritmo de sincronización. 1 

• B, al enviar m’, le pone 3 sellos temporales: T i-1 , T i-2 y 

T i-3 : 

– T i-3 : hora en que A transmitió el último mensaje que B 

recibió 

– T i-2 : hora en que B recibe el último mensaje de A 

– T i-1 : hora en que B transmite este mensaje m' 

• Además A tiene T i : hora en que A recibe el mensaje m' 

– suponiendo que no se pierde 


• Obtenemos: 

m 

T i-3 

T i-2 

T i-1 

m’ 

T i 


T i-2 = T i-3 + t Tx + o ⇒ T i-2 - T i-3 = t Tx + o = a 

T i = T i-1 + t' Tx - o ⇒ T i - T i-1 = t' Tx - o = b 

d i = t Tx + t' Tx = a + b 

• por tanto, la mejor aproximación que se 

puede conseguir es: 

o i = (a - b) / 2 = (o + t Tx + o - t’ Tx) / 2 = 

o + (t Tx - t’ Tx) / 2 

• y el error de la estimación vale: 

error = | o - o i | = | t Tx - t’ Tx | / 2 



• Aunque se pierda un mensaje, los 3 sellos 

que lleva m' son válidos 

• Definiciones: 

– T B y T A : horas de los servidores 

– o : offset real de B respecto de A (T B - T A ) 

– o i : estimación del offset real entre los dos 

relojes 

– d i : tiempo total de transmisión para los 2 

mensajes 

– t Tx : tiempo real de transmisión para m 

– t' Tx : tiempo real de transmisión para m' 



• Este error sería 0 si ambos tiempos de 

transmisión fuesen idénticos. 

• Su valor máximo vendrá dado por: 

max (error) = max (| t Tx - t' Tx | / 2) ≤ d i / 2 

• y como: 

o = o i - (t Tx - t’ Tx ) / 2 

• entonces: 

o i - d i / 2 ≤ o ≤ o i + d i / 2 




NTP. Filtrado de datos. 1 

• Los servidores NTP almacenan los pares {o i , d i} 

que estiman o 

• A d i se le llama dispersión de filtro, y es la calidad 

de la estimación: 

– a mayor d i ⇒ menor precisión 

• Se almacenan los 8 pares {o i , d i } más recientes, 

se elige el par con menor d j , y se usa o j como 

estimación de o 

• El servidor NTP se sincroniza utilizando varios 

servidores. A cada uno de ellos le aplica el filtrado 

de datos 


NTP. Estado 

• En Noviembre de 2009: 

– 192 servidores primarios públicos sincronizados 

con UTC, y 

– 338 servidores secundarios públicos (estrato 2) 

sincronizados con los primarios 

– dando sincronización a entre 10 y 20 millones 

de clientes y servidores a lo largo de Internet 

• Precisión de la estimación (típica) respecto 

a UTC: 

– menos de 1 ms. en LANs y 

– algunas decenas de ms. en WANs 


NTP. Filtrado de datos. 2 

• Al resultado anterior se le aplica un algoritmo de 

selección de compañero: 

– este algoritmo favorece a los servidores con un número 

de estrato inferior 

– dispersión de sincronización: suma de las sucesivas 

dispersiones de filtro entre este servidor y la raíz 

(estrato 1) 

– los servidores intercambian las dispersiones de 

sincronización en los mensajes ⇒ puede calcularse la 

dispersión de sincronización total con el UTC 

• Los servidores secundarios se conectan con 1 

compañero del mismo estrato y 2 del 

inmediatamente inferior 


El tiempo lógico 




La relación sucedió-antes. 1 

• Relojes no perfectamente sincronizados ⇒ no se 

puede garantizar el orden de un par de eventos 

arbitrarios utilizando el tiempo físico 

– Lamport (1978) 

• El orden de los eventos es crítico en ciertas 

aplicaciones 

– sucesivas actualizaciones de objetos replicados 

• Lamport introduce el principio de causalidad física 

para definir la relación sucedió-antes (happenedbefore). 

Se basa en: 

– si dos eventos ocurren en el mismo ordenador, entonces 

ocurrieron en el orden en el cual han sido observados 

– cuando un mensaje se envía entre ordenadores, el evento 

de enviar el mensaje ocurre antes del evento de recibir el 

mensaje 



• Si a → b ⇒ ∃ un conjunto de eventos {e 1 ..., e n} tal 

que: 

– a = e 1 , b = e n. 

– donde, para todo par (e i , e i+1): 

• o bien e i y e i+1 se observan en ese orden en un 

mismo ordenador p, 

• o ∃ m tal que: e i = send(m), e i+1 = rcv(m). 

– La secuencia {e i} no tiene por qué ser única 

• Limitación: no se pueden ordenar todos los eventos 

– usuario de R llama por teléfono en e a usuario de P 

solicitándole un envío (suceso b). 

• Entonces e causa b, pero no (e → b) 



• Se denota como a → p b si dos eventos a y b 

ocurren en un mismo ordenador p, y a se 

observa antes que b 

• Se expresa la relación sucedió-antes con “→“ 

a → b ⇔ a sucedió antes que b 

• Definición formal de la relación sucedió-antes: 

HB1: si existe un ordenador p tal que a → p b, 

entonces a → b 

HB2: para cualquier mensaje m: send(m) → rcv(m), donde 

send(m) es el evento de enviar el mensaje, y rcv(m) 

es el evento de recibir el mensaje 

HB3: si a, b y c son eventos tales que a → b y b → c, 

entonces a → c 




P 

Q 

R 

a 

e 

b 

c 

Relación sucedió-antes. Ejemplo 

• a → b, pues ocurren en este orden en P 

• b → c, pues son envío y recepción de un mensaje 

• aplicando HB3 llegamos a: a → f 

• no (a → e) y no (e → a) ⇒ a || e 

(a y e son concurrentes) 

d 

f


El reloj lógico 

• Concepto desarrollado por Lamport 

• Permite capturar numéricamente la relación 

sucedió-antes 

• Es un contador software que se incrementa 

monótonamente y no tiene ninguna relación 

con el reloj físico 

• Notación: 

– C p : reloj lógico del ordenador p 

– C(a) : sello temporal del evento a 


P 

Q 

R 

a 

1 

e 

1 

b 

2 

c 

3 

Relojes lógicos. Ejemplo 

• En general: 

– a → b ⇒ C(a) < C(b) 

– C(a) < C(b) NO ⇒ a → b 

• En el ejemplo: C(e) < C(b), pero: e || b 


d 

4 

f 

5 

Reglas de funcionamiento de los relojes lógicos 

LC1: C p se incrementa antes de sellar cada 

evento que suceda en el ordenador p 

⇒ C p = C p + 1 



LC2: 

a) Cuando un ordenador p envía un mensaje 

m, envía el valor t = C p 

b) Al recibir {m, t}, un ordenador q calcula C q 

= max(C q ,t) y entonces aplica LC1 antes de 

poner el sello temporal al evento rcv(m) 

Ordenación total 

• Los relojes lógicos imponen solamente un orden 

parcial: eventos distintos generados por 

ordenadores diferentes pueden tener sellos 

temporales idénticos 

– En el ejemplo: C(a) = C(e) 

• Puede conseguirse una ordenación total teniendo en 

cuenta los identificadores de los ordenadores en los 

que sucedieron los eventos 

• Se define un nuevo sello temporal global: {C i , p i } 

• {C i , p i } < {C j , p j } ⇔ 

a) C i < C j , ó bien 

b) C i = C j y p i 



La coordinación distribuida 


La coordinación distribuida. 2 

• Pero otros servidores no incluyen sincronización: 

– Ejemplo: Sun NFS 

⇒ necesitan servicio de exclusión mutua (p.ej. daemon 

lockd) 

– Para este caso se requiere un mecanismo de exclusión 

mutua distribuida: dar a un único proceso el derecho de 

acceder temporalmente a los recursos compartidos 

• En otros casos se necesita elegir a un único 

proceso de un conjunto para que desarrolle un 

papel privilegiado durante un largo tiempo 

⇒ algoritmo de elección 

– Ejemplo: el maestro del método de Berkeley 


La coordinación distribuida. 1 

• Los procesos distribuidos necesitan a menudo 

coordinar sus actividades 

⇒ exclusión mutua de los procesos distribuidos 

– Ejemplo: reservas de billetes de avión 

• En los SD para solucionar el problema de la 

exclusión mutua no se pueden utilizar: 

– ni variables compartidas 

– ni facilidades dadas por un único núcleo central 

• Algunos servidores implementan sus propios 

cerrojos para sincronizar los accesos a los recursos 

que gestionan 


La exclusión mutua distribuida 

• Exigencias: 

ME1: seguridad ⇒ en todo momento, como 

máximo hay un solo proceso ejecutando la 

región crítica 

ME2: vitalidad ⇒ a todo proceso que lo solicita se 

le concede la entrada en la región crítica en 

algún momento: 

• evita el abrazo mortal (deadlock) y 

• la inanición (starvation) 

ME3: ordenación ⇒ la entrada en la región crítica 

debe concederse según la relación sucedióantes 




Algoritmo del servidor central 

• Servidor central ⇒ concede permisos 

– Respuesta: en forma de testigo que concede acceso a la RC 

– Al salir de la RC, el proceso devuelve el testigo al servidor 

• Suponiendo que no hay caídas y no se pierden 

mensajes: 

⇒ se cumplen ME1 y ME2 

⇒ ME3 está asegurada en el orden de llegada de los 

mensajes al servidor 

• Problemas: 

– todas las solicitudes se envían al servidor ⇒ cuello de 

botella 

– caída o fallo del servidor ⇒ elección de nuevo servidor 

⇒ ME3 no asegurada 

– caída o fallo del proceso en la RC 


Algoritmos basados en relojes lógicos 

• Dos suposiciones: 

– cada proceso conoce la dirección de los 

demás 

– cada proceso posee un reloj lógico 

• Tres algoritmos: 

– Lamport 

– Ricart y Agrawala 

– basado en anillo 




P 1 

1. Solicitud 

de testigo 

SERVIDOR 

P 2 

2 4 

2 

Servidor central. Ejemplo 

2. Liberación 

de testigo 

P 3 

Cola de solicitudes 

3. Concesión 

de testigo. 

P 4 

P3 está P usando el recurso 

4 usa el recurso 

El algoritmo de Lamport. 1 

• Cada proceso mantiene una cola de 

solicitudes independiente. 

– está ordenada según la relación sucedió-antes 

• Para que un proceso obtenga el recurso 

son necesarios 3(n-1) mensajes 

– siendo n el número de procesos 



Cuando el proceso P i quiere solicitar el recurso: 

envía el sello temporal {C i , P i} a los demás procesos y 

pone el mensaje en su cola de solicitudes 

Cuando P j recibe {C i , P i}: 

lo coloca en su cola y 

envía asentimiento sellado a P i 

El algoritmo de Lamport. 2 

A P i se le concede recurso cuando: 

su sello temporal {C i , P i} es el primero de su cola, y 

P i ha recibido asentimientos sellados después de C i de los demás procesos 

Cuando P i quiere liberar el recurso: 

envía un mensaje de liberación sellado a los demás procesos, y 

elimina el sello {C i , P i} de su cola 

Cuando P j recibe el mensaje de liberación de P i: 

borra el sello {C i , P i} de su cola 


Algoritmo de Ricart y Agrawala. 1 

• Idea básica: cuando un proceso quiere 

entrar en la Región Crítica 

– les pregunta a los demás si puede entrar 

• Cuando todos los demás le contesten: 

entra 

• Como en Lamport, el acceso se obtiene a 

través de un testigo. 

• Cada proceso guarda el estado del testigo: 

liberado, solicitado, retenido 


P Ack 13,Q Acc 14,Q Q 



14 10 Q P 

14 Q 

Acc 10,P 

Lib 20,P 

Acc 10,P 

Algoritmo de Lamport. Ejemplo 

Lib 20,P 

Ack 17, R 

Ack 21, Q 

R 

14 10 Q P 

Acc 14,Q 

14 10 Q P 

14 Q 

Ack 16, R 

14 Q 

P usa el recurso Q usa el recurso 

En la inicialización: 

estado = liberado; 

Para obtener el testigo: 

estado = solicitado; 

envía la solicitud a los demás procesos mediante multicast; 

C i = sello temporal de la solicitud; 

Espera hasta que se reciban n-1 respuestas; 

estado = retenido; 

Al recibir una solicitud {C i ,p i } en p j (i ≠ j) 

if ((estado == retenido) || ((estado == solicitado) && ({C j , p j } < {C i , p i }))) 

mete la solicitud de p i en la cola y no contesta; 

else 

contesta inmediatamente a p i ; 

Para liberar el testigo: 

estado = liberado; 

Contestación a todas las solicitudes de la cola; 




41 

P 1 

Respuesta 

P 2 tiene el testigo 

41 

34 

Respuesta 

Ricart y Agrawala. Ejemplo 


41 

P 2 

Respuesta 

34 

34 

P 3 

Algoritmo basado en anillo. 1 

• La exclusión se logra por la obtención de un 

testigo 

• Anillo lógico ⇒ se crea dando a cada proceso la 

dirección de su vecino 

El testigo está siempre circulando por el anillo. 

Cuando un proceso recibe el testigo: 

si no quiere entrar en la RC ⇒ lo envía a su vecino 

si quiere entrar en la RC ⇒ lo retiene 

Al salir de la RC: 

lo envía a su vecino 

• Se verifican ME1 y ME2, pero no se asegura ME3 

• Obtención del recurso ⇒ de 1 a (n-1) mensajes 



• Número de mensajes necesarios para obtener el 

recurso: 

– sin soporte multicast: 2(n-1) 

– con soporte multicast: n 

– el algoritmo fue refinado hasta n mensajes sin soporte 

multicast (Raynal, 1988) 

• Problemas (tanto Lamport como Ricart y Agrawala): 

– Algoritmos más costosos que el del servidor central 

– Pese a ser algoritmos distribuidos, el fallo de cualquier 

proceso bloquea el sistema 

– Los procesos implicados reciben y procesan cada solicitud: 

igual o peor congestión que el servidor central 


Algoritmo basado en anillo. 2 



P1 

TESTIGO 

P2 

TESTIGO 

P3 

P4 

TESTIGO 

TESTIGO 

TESTIGO


Algoritmo basado en anillo. Problemas 

• Se carga la red aun cuando ningún 

proceso quiera entrar en la RC 

• Si un proceso cae ⇒ reconfiguración 

– si además tenía el testigo: 

• elección para regenerar el testigo 

• asegurarse de que el proceso ha caído ⇒ varios 

testigos 

• Problema desconexión o rotura de la red 


Algoritmos de elección 


Discusión de los algoritmos descritos 

• Ninguno puede tratar el problema de la 

caída de un ordenador o proceso 

• El del servidor central es el que tiene 

menor número de mensajes, pero supone 

un cuello de botella 

• Conclusión: es preferible que el servidor 

que gestiona el recurso implemente 

también la exclusión mutua 


Algoritmos de elección 

• Una elección es un procedimiento para elegir 

a un proceso dentro de un grupo 

– ejemplo: elegir a un proceso que sustituya a 

uno especial (coordinador, maestro, ...) 

cuando éste cae 

• Principal exigencia ⇒ elección única incluso si 

varios procesos lanzan el algoritmo de 

elección de manera concurrente 

• Dos algoritmos: 

– Algoritmo del matón (bully): Silberschatz 

– Algoritmo basado en anillo: Chang y Roberts 




Algoritmo del matón. 1 

• Requisito: todos los miembros del grupo deben 

conocer las identidades y direcciones de los demás 

miembros 

• El algoritmo selecciona al miembro superviviente 

con mayor identificador 

• Los procesos pueden caer durante la elección 

• Se supone comunicación fiable 

• Hay 3 tipos de mensajes: 

– mensaje de elección (election): para anunciar una 

elección 

– mensaje de respuesta (answer) a un mensaje de elección 

– mensaje de coordinador (coordinator): anuncia identidad 

de nuevo coordinador 


elección 

elección 

P1 

elección 

respuesta 

P2 

respuesta 

P3 

elección 

P4 

P1 

Temporización... 

elección 

elección 

P2 P3 P4 

respuesta 

elección 

elección 

elección 

P1 P2 P3 

respuesta 

Finalmente... 

Algoritmo del matón. Ejemplo 

P1 P2 P3 P4 

coordinador 


P4 

Un proceso inicia una elección al darse cuenta de que el coordinador ha caído: 

envía mensaje de elección a los procesos con identificador mayor que el suyo 

espera algún mensaje de respuesta: 

si vence temporizador ⇒ el proceso se erige como coordinador y envía mensaje de 

coordinador a todos los procesos con identificadores más bajos 

si recibe alguna respuesta ⇒ espera mensaje de coordinador. 

si vence temporizador, lanza una nueva elección 

Si un proceso recibe un mensaje de coordinador: 

guarda el identificador y trata a ese proceso como nuevo coordinador 

Si un proceso recibe un mensaje de elección: 

contesta con un mensaje de respuesta y lanza una elección, 

(si no ha lanzado ya antes una) 

Cuando un proceso se reinicia: 

lanza una elección a menos que sea el de identificador más alto 

(en cuyo caso se erigiría como nuevo coordinador) 

Algoritmo del matón. 2 

• Número de mensajes para elegir coordinador: 

– caso mejor: se da cuenta el segundo más alto ⇒ (n-2) mensajes 

– caso peor: se da cuenta el más bajo ⇒ O(n 2 ) mensajes 


Elección basada en anillo. 1 

• Anillo lógico: 

– cada proceso sólo sabe comunicarse con su vecino 

• Se elige al proceso con identificador más alto 

• Se supone procesos estables durante la elección 

• Tanenbaum (1992): 

– variante donde los procesos pueden caer 

• Número de mensajes para elegir coordinador: 

– peor caso: lanza elección sólo el siguiente al futuro 

coordinador ⇒ (3n-1) mensajes 

– mejor caso: lanza elección el futuro coordinador ⇒ 2n 

mensajes 




Inicialmente todos los procesos son no-candidatos: 

Cualquiera puede empezar una elección: 

se marca como candidato 

envía mensaje de elección con su identificador 

Cuando un proceso recibe un mensaje de elección: 

si identificador del mensaje es mayor que el suyo ⇒ envía mensaje a sus vecinos 

si es menor: 

si es no-candidato ⇒ sustituye el identificador y envía mensaje al vecino 

y se marca como candidato 

si es candidato ⇒ no envía nada 

si es el suyo 

se marca como no-candidato 

envía mensaje de elegido a su vecino añadiendo su identidad 

Cuando un proceso recibe un mensaje de elegido: 

si el identificador del mensaje no es el suyo 

se marca como no-candidato 

lo envía a su vecino 

si es el suyo 

lo extrae del anillo 

Elección basada en anillo. 2 


Comunicación de grupo 




28 

elección elegido 

28 

4 

9 

28 

15 

3 

C 

28 

3 

28 

Elección en anillo. Ejemplo 

17 

C 

C 

28 

C 

28 17 28 

24 

1 

28 

24 

• Envío simple (unicast): 

– 1 emisor, 1 receptor 

• Envío múltiple (multicast): 

– 1 emisor, múltiples receptores 

– Grupo de envío múltiple: 

• conjunto de procesos que 

– pueden enviar mensajes 

– recibirán los mensajes enviados 

– Habitualmente, sin conexión 

• Modelo de API: 

– Se necesitan operaciones para: 

• Incorporarse y darse de baja del grupo 

• Enviar y recibir mensajes 

28 

24 

Comunicación de grupo 



Comunicación de grupo y fiabilidad 

• Los mensajes se pueden retardar, perder, ... 

• Diferentes aplicaciones, diferentes necesidades 

respecto a la fiabilidad 

• Comunicación de grupo No Fiable: 

– Puede que algún proceso no reciba algún mensaje, o lo 

reciba más de una vez, ... 

• Comunicación de grupo Fiable: 

– Garantiza la entrega segura: todo proceso recibe una y 

sólo una copia de todo mensaje, y esa copia es correcta 

– Son posibles varias ordenaciones: 

• Sin orden 

• En orden de envío, o FIFO 

• En orden causal 

• En orden atómico 


Comunicación de grupo fiable en orden de envío (FIFO) 

• Se garantiza que: 

– Si el proceso A envía los mensajes m a1 y m a2, en ese orden, 

entonces a cada proceso del grupo de envío múltiple se le 

entregarán los mensajes en ese orden. 

• Ejemplo 1: 

– Si A envía m 1-m 2-m 3 ⇒ A, B y C recibirán: m 1-m 2-m 3 

• No hay garantías respecto al orden de mensajes 

enviados por procesos diferentes: 


m a2 

m a1 

A 

C 

B 

m b1 

m b2 

• Es posible que: 

– A reciba 

• m a1-m a2-m b1 -m b2 

– B reciba 

• m a1 -m b1 -m a2 -m b2 

– C reciba 

• m b1- m a1-m a2-m b2 


Comunicación de grupo fiable sin orden 

• No hay ninguna garantía sobre el orden de 

entrega 

– Dados n mensajes, cada proceso puede recibirlos en 

cualquiera de las n! posibles permutaciones 

• Ejemplo: 

• Es posible que: 

– A, B y C reciban lo 

mismo: m 1-m 2-m 3 

• Pero también que: 

– A reciba m 1-m 3-m 2 

– B reciba m 3-m 2-m 1 

– C reciba m 2-m 1-m 3 



m 1 

m 2 

m 3 

A B 


– Si A envía m a 

– B responde a m a con m b 

– y C responde a m a con m c 

C 

Comunicación de grupo fiable en orden causal 


– Si el mensaje m 1 sucedió-antes que el mensaje m 2 (m 1 → m 2), 

entonces a cada proceso del grupo de envío múltiple se le 

entregará m 1 antes que m 2 


– Si A envía ma – B responde a ma con m 

ma → mb → mc b 

– y C responde a mb con mc ⇒ todos los procesos del grupo recibirán: ma-mb-mc m a → m b y m a → m c 

pero: m b || m c 

⇒ algunos procesos del grupo pueden recibir: m a-m b-m c 

⇒ pero otros pueden recibir: m a-m c-m b 




– Si A envía m a 

– B envía m b 

– y C envía m c 

Comunicación de grupo fiable en orden atómico 


– Todos los procesos reciben todos los mensajes en 

exactamente el mismo orden 

– que no tiene por qué ser FIFO ni causal 


– Si A envía m a1 y después m a2 

– B responde a m a1 con m b 

– y C responde a m b con m c 

6 posibles permutaciones 

m a -m b -m c o m a -m c -m b o m b -m a -m c o 

m a -m c -m a o m c -m a -m b o m c -m b -m a 

⇒ todos los procesos del grupo recibirán la misma 

en A: m a1 –m a2 

en B: m a1 –m b 

en C: m b –m c 

⇒ opciones: m a1 -m a2 -m b -m c o m a1 -m b -m a2 -m c o m a1 -m b -m c -m a2 

⇒ todos los procesos del grupo recibirán la misma 


La API Java para comunicación de grupo 

• Extensión de UDP 

• Independiente del sistema subyacente 

– mrouters de Internet, difusión de Ethernet, ... 

• Una clase adicional a las conocidas: 

– MulticastSocket: 

• Deriva de DatagramSocket, a la que añade: 

– joinGroup: método para unirse a un grupo 

– leaveGroup: método para abandonar un grupo 

– setTimeToLive: método para ajustar el tiempo-de-vida 

• Se envía mediante send: 

– no es necesario haberse unido al grupo 

• Se recibe mediante receive: 

– sólo los miembros del grupo 


Direcciones IP de envío múltiple 

• En IPv4, un grupo de envío múltiple se especifica por: 

– un número de puerto normal de UDP y 

– una dirección IP de clase D 

• las 2 28 direcciones que empiezan por 1110 

• autoridad que asigna y gestiona: IANA 

• se puede usar de la 224.0.0.1 a la 239.255.255.255 

• ejemplos: 

– 224.0.0.1: todas las máquinas de esta subred 

– 224.0.1.84: jini-announcement 

• se puede obtener una dirección transitoria en tiempo de ejecución 

mediante SAP (protocolo de anuncio de sesión) 

• Los paquetes de propagan por “saltos” 

– peligro: paquetes circulando indefinidamente 

– solución: asignar un tiempo-de-vida (ttl) a los mensajes 

• valor en [0,255] 

• 0: misma máquina, 1: misma subred, ... 

• 255: envío múltiple no restringido 


import java.net.*; 

import java.io.*; 

Emisor de comunicación en grupo en Java 

public class EmisorGrupo { 

public static void main(String args []) { 

// Los argumentos dan el mensaje y la dirección IP de envío múltiple 

try{ 

InetAddress grupo = InetAddress.getByName(args[0]); 

int puerto = 6789; 

int miPuerto = 9876; 

MulticastSocket elSocket = new MulticastSocket(miPuerto); 

elSocket.setTimeToLive(32); //restringida a máquinas de la misma zona 

byte [] msjEnv= args[1].getBytes(); 

DatagramPacket paqEnv = 

new DatagramPacket(msjEnv, args[1].length(), grupo, puerto); 

elSocket.send(paqEnv); 

elSocket.close(); 

} catch(UnknownHostException e) { 

System.out.println(″Desconocido: ″ + e.getMessage()); 

} catch(SocketException e) { 

System.out.println(″Socket: ″ + e.getMessage()); 

} catch(IOException e) { 

System.out.println(″E/S: ″ + e.getMessage()); 

} 

} 

} 




import java.net.*; 

import java.io.*; 

Receptor de comunicación en grupo en Java 

public class ReceptorGrupo { 

public static void main(String args []) { 

// El argumento da la dirección IP de envío múltiple 

try{ 

InetAddress grupo = InetAddress.getByName(args[0] ); 

int puerto = 6789; 

MulticastSocket elSocket = new MulticastSocket(puerto); 

elSocket.joinGroup(grupo); 

byte [] msjRec = new byte[1000] ; 

DatagramPacket paqRec= new DatagramPacket(msjRec, msjRec.length); 

elSocket.receive(paqRec); 

System.out.println(new String(msjRec)); 

elSocket.close( ); 

} catch(SocketException e) { 

System.out.println(″Socket: ″ + e.getMessage()); 

} catch(IOException e) { 

System.out.println(″E/S: ″ + e.getMessage()); 

} 

} 

} 


La API Java y la fiabilidad 

• La API de Java se basa en Datagramas 

UDP: 

– proporciona una comunicación de grupo No 

Fiable 

– En procesos que no estén en la misma LAN, 

• Puede haber mensajes perdidos, duplicados, 

desordenados, ... 

– Para aplicaciones que exijan fiabilidad: 

• Una capa por encima 

• Existen paquetes que aumentan la fiabilidad 

– JRM, Totem, RMF, ...

Introducción y objetivos La sincronización - GTI

Create successful ePaper yourself

Delete template?

Save as template?