UNIDAD 2 Comunicación en los sistemas operativos distribuidos.

Los sistemas distribuidos están basados en las ideas básicas de transparencia, eficiencia, flexibilidad, escalabilidad y fiabilidad. Sin embargo estos aspectos son en parte contrarios, y por lo tanto los sistemas distribuidos han de cumplir en su diseño el compromiso de que todos los puntos anteriores sean solucionados de manera aceptable.
Llamada a procedimiento remoto (RPC)
En el anterior epígrafe hemos estudiado un modelo de interacción entre los procesos de un sistema distribuido que es el modelo cliente-servidor. Para implementarlo, el sistema dispone de dos llamadas al sistema, send y receive, que las aplicaciones utilizan de forma conveniente. Estas primitivas, a pesar de constituir la base de la construcción de los sistemas distribuidos, pertenecen a un nivel demasiado bajo como para programar de forma eficiente aplicaciones distribuidas.

2.1.1. Comunicación con los clientes-Servidor (Socket)

Origen de los socket tuvo lugar en una variante del sistema operativo Unix conocida como BSD Unix. En la universidad de Berkeley, en los inicios del Internet, pronto se hizo evidente que los programadores necesitarían un medio sencillo y eficaz para escribir programas capaces de intercomunicarse entre sí. Esta necesidad dio origen a la primera especificación e implementación de sockets.
Cliente-Servidor es el modelo que actualmente domina el ámbito de comunicación, ya que descentraliza los procesos y los recursos. Es un Sistema donde el cliente es una aplicación, en un equipo, que solicita un determinado servicio y existe un software, en otro equipo, que lo proporciona.
Los servicios pueden ser;
a)Ejecución de un programa. b)Acceso a una Base de Datos. c)Acceso a un dispositivo de hardware.
Solo se requiere un medio físico de comunicación entre las maquinas y dependerá de ala naturaleza de este medio la vialidad del sistema.
Definición de Socket: designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiarse cualquier flujo de datos, generalmente de manera fiable y ordenada.
Los sockets proporcionan una comunicación de dos vías, punto a punto entre dos procesos. Los sockets son muy versátiles y son un componente básico de comunicación entre interprocesos e intersistemas. Un socket es un punto final de comunicación al cual se puede asociar un nombre.
Para lograr tener un socket es necesario que se cumplan ciertos requisitos
1.Que un programa sea capaz de localizar al otro. 2.Que ambos programas sean capaces de intercambiarse información.
Por lo que son necesarios tres recursos que originan el concepto de socket
a)Un protocolo de comunicaciones, que permite el intercambio de octetos.
b)Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora.
c)Un número de puerto, que identifica a un programa dentro de una computadora. Con un socket se logra implementar una arquitectura cliente-servidor. la comunicación es iniciada por uno de los programas (cliente). Mientras el segundo programa espera a que el otro inicie la comunicación (servidor). Un Socket es un archivo existente en el cliente y en el servidor.
si un socket es un punto final de un puente de comunicaron de dos vías entre dos programas que se comunican a través de la red, ¿Cómo funciona?. Normalmente, un servidor funciona en una computadora específica usando un socket con un número de puerto especifico. El cliente conoce el nombre de la maquina (hostname) o el IP, en la cual el servidor esta funcionando y el numero del puerto con el servidor esta conectado.
Si el cliente lanza una demanda de conexión y el servidor acepta la conexión, este abre un socket en un puerto diferente, para que pueda continuar escuchando en el puerto original nuevas peticiones de conexión, mientras que atiende a las peticiones del cliente conectado. El cliente y el servidor pueden ahora comunicarse escribiendo o leyendo en sus respectivos sockets.

2.1.2 Comunicación con RPC

RCP (REMOTE PROCEDURE CALL)
El mecanismo general para las aplicaciones cliente-servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fue desarrollado por Sun Microsystems y es una colección de herramientas y funciones de biblioteca.
Un servidor RPC consiste en una colección de procedimientos que un cliente puede solicitar por el envío de una petición RPC al servidor junto con los parámetros del procedimiento. El servidor invocará el procedimiento indicado en nombre del cliente, entregando el valor de retorno, si hay alguno. Para ser independiente de la máquina, todos los datos intercambiados entre el cliente y el servidor se convierten al formato External Data Representation (XDR) por el emisor, y son reconvertidos a la representación local por el receptor. RPC confía en sockets estándar UDP y TCP para transportar los datos en formato XDR hacia el host remoto. Sun amablemente a puesto RPC en el dominio público; se describe en una serie de RFCs.
Un servidor RPC ofrece una o más colecciones de procedimientos; cada conjunto se llama un programa y es identificado de forma única por un número de programa.
La llamada remota toma 10 pasos, en el primero de los cuales el programa cliente (o procedimiento) llama al procedimiento stub enlazado en su propio espacio de direcciones. Los parámetros pueden pasarse de la manera usual y hasta aquí el cliente no nota nada inusual en esta llamada ya que es una llamada local normal.
El stub cliente reúne luego los parámetros y los empaqueta en un mensaje. Esta operación se conoce como reunión de argumentos (parameter marshalling). Después que se ha construido el mensaje, se lo pasa a la capa de transporte para su transmisión (paso 2). En un sistema LAN con un servicio sin conexiones, la entidad de transporte probablemente sólo le agrega al mensaje un encabezamiento y lo coloca en la subred sin mayor trabajo (paso 3). En una WAN, la transmisión real puede ser más complicada. Cuando el mensaje llega al servidor, la entidad de transporte lo pasa al stub del servidor (paso 4), que desempaqueta los parámetros. El stub servidor llama luego al procedimiento servidor (paso 5), pasándole los parámetros de manera estándar. El procedimiento servidor no tiene forma de saber que está siendo activado remotamente, debido a que se lo llama desde un procedimiento local que cumple con
todas las reglas estándares. Únicamente el stub sabe que está ocurriendo algo
particular.
Después que ha completado su trabajo, el procedimiento servidor retorna (paso 6) de la misma forma en que retornan otros procedimientos cuando terminan y, desde luego, puede retornar un resultado a un llamador. El stub servidor empaqueta luego el resultado en un mensaje y lo entrega a la interfaz con transporte (paso 7), posiblemente mediante una llamada al sistema, al igual que en el paso 2. Después que la respuesta retorna a la máquina cliente (paso 8), la misma se entrega al stub cliente (paso 9) que desempaqueta las respuestas. Finalmente, el stub cliente retorna a su llamador, el procedimiento cliente y cualquier valor devuelto por el servidor en el paso 6, se entrega al cliente en el paso 10. El propósito de todo el mecanismo de la es darle al cliente (procedimiento cliente) la ilusión de que está haciendo una llamada a un procedimiento local. Dado el éxito de la ilusión, ya que el cliente no puede saber que el servidor es remoto, se dice que el mecanismo es transparente. Sin embargo, una inspección más de cerca revela algunas dificultades en alcanzar la total transparencia.

2.1.3 Comunicación en grupo
La comunicación en grupo tiene que permitir la definición de grupos, así como características propias de los grupos, como la distinción entre grupos abiertos o que permiten el acceso y cerrados que lo limitan, o como la distinción del tipo de jerarquía dentro del grupo. Igualmente, los grupos han de tener operaciones relacionadas con su manejo, como la creación o modificación.
Sincronización
La sincronización en sistemas de un único ordenador no requiere ninguna consideración en el diseño del sistema operativo, ya que existe un reloj único que proporciona de forma regular y precisa el tiempo en cada momento. Sin embargo, los sistemas distribuidos tienen un reloj por cada ordenador del sistema, con lo que es fundamental una coordinaciónentre todos los relojes para mostrar una hora única. Los osciladores de cada ordenador son ligeramente diferentes, y como consecuencia todos los relojes sufren un desfase y deben ser sincronizados continuamente. La sincronización no es trivial, porque se realiza a través de mensajes por la red, cuyo tiempo de envío puede ser variable y depender de muchos factores, como la distancia, la velocidad de transmisión o la propia saturación de la red, etc.
El reloj
La sincronización no tiene por qué ser exacta, y bastará con que sea aproximadamente igual en todos los ordenadores. Hay que tener en cuenta, eso sí, el modo de actualizar la hora de un reloj en particular. Es fundamental no retrasar nunca la hora, aunque el reloj adelante. En vez de eso, hay que ralentizar la actualización del reloj, frenarlo, hasta que alcance la hora aproximadamente. Existen diferentes algoritmos de actualización de la hora, tres de ellos se exponen brevemente a continuación.
Algoritmo de Lamport
Tras el intento de sincronizar todos los relojes, surge la idea de que no es necesario que todos los relojes tengan la misma hora exacta, sino que simplemente mantengan una relación estable de forma que se mantenga la relación de qué suceso ocurrió antes que otro suceso cualquiera.
Este algoritmose encarga exclusivamente de mantener el orden en que se suceden los procesos. En cada mensaje que se envía a otro ordenador se incluye la hora. Si el receptor del mensaje tiene una hora anterior a la indicada en el mensaje, utiliza la hora recibida incrementada en uno para actualizar su propia hora.
Algoritmo de Cristian
Consiste en disponer de un servidor de tiempo, que reciba la hora exacta. El servidor se encarga de enviar a cada ordenador la hora. Cada ordenador de destino sólo tiene que sumarle el tiempo de transporte del mensaje, que se puede calcular de forma aproximada.
Algoritmo de Berkeley
La principal desventaja del algoritmo de Cristian es que todo el sistema depende del servidor de tiempo, lo cual no es aceptable en un sistema distribuido fiable.
El algoritmo de Berkeley usa la hora de todos los ordenadores para elaborar una media, que se reenvía para que cada equipo actualice su propia hora ralentizando el reloj o adoptando la nueva hora, según el caso.
Comunicación en Grupo
Una hipótesis subyacente e intrínseca de RPC es que la comunicación solo es entre dos partes: el cliente y el servidor [25, Tanenbaum].
A veces existen circunstancias en las que la comunicación es entre varios procesos y no solo dos (ver Figura 8.11 [25, Tanenbaum]):

• Ej.: un grupo de servidores de archivo que cooperan para ofrecer un único servicio de archivos tolerante a fallos:
• Sería recomendable que un cliente envíe el mensaje a todos los servidores para garantizar la ejecución de la solicitud aunque alguno falle.
• RPC no puede controlar la comunicación de un servidor con muchos receptores, a menos que realice RPC con cada uno en forma individual.

Un grupo es una colección de procesos que actúan juntos en cierto sistema o alguna forma determinada por el usuario.
La propiedad fundamental de todos los grupos es que cuando un mensaje se envía al propio grupo, todos los miembros del grupo lo reciben.
Se trata de una comunicación uno - muchos (un emisor, muchos receptores), que se distingue de la comunicación puntual o punto a punto (un emisor, un receptor).
Los grupos son dinámicos:

• Se pueden crear y destruir.
• Un proceso se puede unir a un grupo o dejar a otro.
• Un proceso puede ser miembro de varios grupos a la vez.

La implantación de la comunicación en grupo depende en gran medida del hardware:

• En ciertas redes es posible crear una dirección especial de red a la que pueden escuchar varias máquinas:
• Cuando se envía un mensaje a una de esas direcciones se lo entrega automáticamente a todas las máquinas que escuchan a esa dirección.
• Esta técnica se denomina multitransmisión.
• Cada grupo debe tener una dirección de multitransmisión distinta.

Las redes que no soportan multitransmisión operan con transmisión simple:

• Significa que los paquetes que tienen cierta dirección se entregan a todas las máquinas.
• Se puede utilizar para implantar los grupos, pero es menos eficiente que la multitransmisión.
• Cada máquina debe verificar, mediante su software, si el paquete va dirigido a ella:
• En caso negativo se descarta, pero para analizarlo se generó una interrupción y se dedicó ciclos de cpu.

Otra solución es implantar la comunicación en grupo mediante la transmisión por parte del emisor de paquetes individuales a cada uno de los miembros del grupo:

• En vez de un paquete se precisan “n” paquetes.
• Es menos eficiente que las soluciones anteriores.
• Es una solución valida particularmente con grupos pequeños.
• El envío de un mensaje de un emisor a un único receptor se llama unitransmisión.

Aspectos del Diseño de la Comunicación en Grupo
En la comunicación en grupo también se presentan posibilidades tales como [25, Tanenbaum]:

• Almacenamiento en buffers vs. el no almacenamiento.
• Bloqueo vs. no bloqueo.

Además existen otras posibilidades que no se dan en la comunicación entre un emisor y un solo receptor.

Grupos Cerrados Vs. Grupos Abiertos
En los grupos cerrados:

• Solo los miembros del grupo pueden enviar hacia el grupo.
• Los extraños no pueden enviar mensajes al grupo como un todo, peor pueden enviar mensajes a miembros del grupo en lo individual.

En los grupos abiertos:

• Cualquier proceso del sistema puede enviar a cualquier grupo.

Los grupos cerrados se utilizan generalmente para el procesamiento paralelo:

• Ej.: un conjunto de procesos que trabajan de manera conjunta, tienen su propio objetivo y no interactúan con el mundo exterior.

Cuando la idea de grupo pretende soportar servidores duplicados:

• Es importante que los procesos que no sean miembros (clientes) puedan enviar hacia el grupo.
• Podría ser necesario que los miembros del grupo utilizaran la comunicación en grupo.

Grupos de Compañeros Vs. Grupos Jerárquicos
En algunos grupos todos los procesos son iguales:

• No existe distinción de jerarquías.
• Son los grupos de compañeros.

En otros grupos existe cierto tipo de jerarquía:

• Son los grupos jerárquicos.
• Ej.: un proceso es el coordinador y todos los demás son los trabajadores.
• Una solicitud de un trabajo que se genere en un cliente externo o en uno de los procesos trabajadores:
• Se envía al coordinador.
• El coordinador decide cuál de los trabajadores es el más adecuado para llevarla a cabo y se la envía.

Cada tipo de grupo tiene sus ventajas y desventajas:

• Respecto del grupo de compañeros:
• Es simétrico y no tiene un punto de fallo.
• Si uno de los procesos falla, el grupo se reduce pero puede continuar.
• Para tomar decisiones grupales se producen retrasos debidos a la comunicación entre los miembros del grupo.
• Respecto del grupo jerárquico:
• La pérdida del coordinador lleva al grupo a un alto total, lo que es una desventaja.
• En condiciones normales, el coordinador funciona correctamente y toma decisiones sin molestar a los demás procesos.

Un ej. de grupo jerárquico podría ser un programa de ajedrez en paralelo:

• El coordinador:
• Toma el tablero actual.
• Genera todos los movimientos válidos a partir de él.
• Los envía a los trabajadores para su evaluación.
• Controla la estrategia de búsqueda.
• Desarrolla el árbol del juego.
• Los trabajadores:
• Al procesar las evaluaciones generan nuevos tableros.
• Los tableros se envían al coordinador.
• Al quedar inactivos, solicitan al coordinador un nuevo tablero en el cual trabajar.

Membresía del Grupo
La comunicación en grupo requiere cierto método para:

• Creación y eliminación de grupos.
• Unión y separación de procesos a grupos.

Una posibilidad es tener un servidor de grupos al cual enviar todas las solicitudes:

• Es un método directo, eficiente y fácil de implementar.
• La desventaja es el punto de fallo que representa la administración centralizada de los grupos.

Otra posibilidad es la administración distribuida de las membresías a grupos:

• En un grupo abierto, un proceso extraño puede enviar un mensaje a los integrantes del grupo para anunciar su presencia.
• En un grupo cerrado se precisa algo similar, ya que se debe contemplar la admisión de nuevos miembros al grupo cerrado.
• Al salir de un grupo, el proceso debe comunicarlo a los demás del grupo que deja.

Un aspecto problemático se presenta cuando un miembro falla, saliendo por lo tanto del grupo:

• No hay un anuncio apropiado de este hecho.
• Los demás miembros del grupo lo deben descubrir de forma experimental; luego se lo puede eliminar del grupo.

Otro aspecto importante es que la entrada y salida al grupo debe sincronizarse con el envío de mensajes:

• Un proceso que se unió a un grupo debe recibir todos los mensajes que se envíen al mismo.
• Un proceso que ha salido de un grupo:
• No debe recibir más mensajes del grupo.
• El grupo no debe recibir más mensajes del proceso.
• Los otros miembros no deben recibir más mensajes del proceso saliente.
• Una forma de garantizar que una entrada o salida se integra al flujo de mensajes en el lugar correcto es convertir esta operación en un mensaje a todo el grupo.

Un aspecto crítico resulta cuando fallan tantas máquinas que el grupo ya no puede funcionar:

• Se necesita cierto protocolo para reconstruir el grupo.
• Alguno de los procesos deberá tomar la iniciativa.
• El protocolo deberá resolver la situación que se presenta cuando dos o más procesos intentan al mismo tiempo reconstruir el grupo.

Direccionamiento al Grupo
Los grupos deben poder direccionarse, al igual que los procesos.
Una forma es darle a cada grupo una dirección única, similar a una dirección de proceso.
Si la red soporta multitransmisión:

• La dirección del grupo se puede asociar con una dirección de multitransmisión.
• Cada mensaje enviado a la dirección del grupo se podrá multitransmitir.

Si la red no soporta multitransmisión:

• Se tendrá que utilizar transmisión simple.
• Cada núcleo lo recibirá y extraerá la dirección del grupo.
• Si ninguno de los procesos en la máquina es un miembro del grupo, se descarta la transmisión.
• En caso contrario se transfiere a todos los miembros del grupo.

Si la red no soporta multitransmisión ni transmisión simple:

• Se tendrá que utilizar unitransmisión.
• El núcleo de la máquina emisora deberá contar con una lista de las máquinas que tienen procesos pertenecientes al grupo.
• Deberá enviar a cada máquina un mensaje puntual.

Un segundo método de direccionamiento de grupo consiste en pedirle al emisor una lista explícita de todos los destinos:

• Ej.: lista de direcciones IP.
• El parámetro de la llamada send que especifica el destino es un apuntador a una lista de direcciones.
• La desventaja consiste en que los procesos del usuario (los miembros del grupo) deben tener conocimiento de quién es miembro de cada grupo:
• No es transparente.
• Los procesos del usuario deben actualizar las listas de miembros.

Un tercer método es el de direccionamiento de predicados (predicate addressing):

• El mensaje se envía a todos los miembros del grupo (o a todo el sistema) mediante uno de los métodos anteriores.
• El mensaje contiene un predicado (expresión booleana) para ser evaluado.
• El predicado puede utilizar el número de máquina del receptor, sus variables locales u otros factores.
• Si el valor del predicado es “verdadero” se acepta el mensaje y se descarta si es “falso”.
• Permite enviar un mensaje solo a aquellas máquinas que tengan al menos “x” mb de memoria libre y se puedan ocupar de un nuevo proceso.
• Primitivas Send y Receive
  El envío de un mensaje a un grupo no se puede modelar como una llamada a un procedimiento.
  Con la comunicación en grupo existen en potencia “n” respuestas diferentes y no resulta aplicable el esquema de RPC.
  Se utilizan llamadas explícitas para el envío y recepción (modelo de un solo sentido).
  Si se unifican las primitivas puntuales y grupales para send:

• Uno de los parámetros indica el destino:
• Si es una dirección de un proceso, se envía un único mensaje a ese proceso en particular.
• Si es una dirección de grupo (o un apuntador a una lista de destinos), se envía un mensaje a todos los miembros del grupo.
• Un segundo parámetro apunta al mensaje por enviar.

Si se fusionan las primitivas puntuales y grupales para receive:

• La operación concluye cuando llega un mensaje puntual o un mensaje de grupo.

Si es necesario que las respuestas estén asociadas a solicitudes previas:

• Se envía un mensaje.
• Se efectúa varias veces un proceso get_reply para recolectar todas las respuestas, una a la vez.
• Atomicidad
  La mayoría de los sistemas de comunicación en grupo están diseñados para que los mensajes enviados al grupo lleguen correctamente a todos los miembros o a ninguno de ellos:

• Esta propiedad de “todo o nada” en la entrega se llama atomicidad o transmisión atómica.
• Facilita la programación de los sistemas distribuidos.
• Es de gran importancia para garantizar la consistencia de las bases de datos y de los archivos distribuidos y duplicados.

La única forma de garantizar que cada destino recibe todos sus mensajes es pedirle que envíe de regreso un reconocimiento después de recibir el mensaje:

• Esto funciona si las máquinas no fallan.
• Si fallan:
• Algunos miembros del grupo habrán recibido el mensaje y otros no; esto es inaceptable.
• Los miembros que no recibieron el mensaje ni siquiera saben que les falta algo, por lo que no pedirán una retransmisión; además, si pudieran detectar el faltante pero fallara el emisor, no podrán recibir el mensaje.

Una solución puede llegar del algoritmo de Joseph y Birman:

• Demuestra la posibilidad de la transmisión atómica.
• El emisor comienza con el envío de un mensaje a todos los miembros del grupo.
• Los cronómetros se activan y se envían las retransmisiones en los casos necesarios.
• Cuando un proceso recibe un mensaje:
• Si no recibió ya este mensaje particular:
• Lo envía a todos los miembros del grupo:
• Con cronómetros y retransmisiones en los casos necesarios.
• Si ya recibió este mensaje particular:
• No se efectúan envíos y el mensaje se descarta.

Este algoritmo asegura que todos los procesos sobrevivientes obtendrán el mensaje, independientemente del número de máquinas que fallen o el número de paquetes perdidos.

Ordenamiento de Mensajes
El ordenamiento de los mensajes es un aspecto fundamental en la comunicación en grupo.
Ej.: consideramos 5 máquinas, cada una con un proceso:

• Los procesos se identifican como 0, 1, 2, 3 y 4.
• Los procesos 0, 1, 3 y 4 pertenecen al mismo grupo.
• Los procesos 0 y 4 desean enviar un mensaje al grupo simultáneamente:
• Supongamos que no se dispone de multitransmisión ni de transmisión simple.
• Cada proceso debe enviar 3 mensajes independientes (unitransmisión).
• El proceso 0 envía a los procesos 1, 3 y 4.
• El proceso 4 envía a los procesos 0, 1 y 3.
• Una posible secuencia de intercalación de los mensajes es la siguiente:
• 0 a 1; 4 a 0; 4 a 1; 4 a 3; 0 a 3; 0 a 4.

El problema es que cuando dos procesos contienden por el acceso a una LAN, el orden de envío de los mensajes no es determinista.
En el ejemplo anterior, los procesos 1 y 3 reciben los mensajes de los procesos 0 y 4 en distinto orden:

• Si los procesos 0 y 4 intentan actualizar el mismo registro de una base de datos, los procesos 1 y 3 terminarán con distintos valores finales.

Un sistema debe tener una semántica bien definida con respecto al orden de entrega de los mensajes.
La mejor garantía es la entrega inmediata de todos los mensajes, en el orden en que fueron enviados:

• Todos los mensajes destinados a un grupo deben entregarse antes de comenzar a entregar la siguiente serie de mensajes.
• Todos los receptores reciben todos los mensajes en el mismo orden.
• Es esquema se denomina ordenamiento con respecto al tiempo global.

Una variante al esquema anterior es el ordenamiento consistente:

• Si dos mensajes “a” y “b” se envían muy cercanos en el tiempo, el sistema:
• Elige uno de ellos como el “primero”.
• Lo envía a todos los miembros del grupo.
• Luego envía el otro mensaje.
• Se garantiza que los mensajes lleguen a todos los miembros del grupo en el mismo orden:
• Dicho orden podría no ser aquel con el que fueron enviados.

Grupos Traslapados
Un proceso puede ser miembro de varios grupos a la vez, pero esto puede generar un nuevo tipo de inconsistencia.
Ej.: supongamos que:

• El grupo 1 está formado por los procesos “A”, “B” y “C”.
• El grupo 2 está formado por los procesos “B”, “C” y “D”.
• Cada uno de los procesos “A” y “D” decide de manera simultánea enviar un mensaje a sus grupos respectivos.
• El sistema utiliza el ordenamiento con respecto al tiempo global dentro de cada grupo.
• Se utiliza la unitransmisión.
• El orden de los mensajes es el siguiente:
• “A” a “B”; “D” a “B”; “D” a “C” y “A” a “C”.
• Se da la situación de que dos procesos, “B” y “C”, reciben los mensajes en un orden distinto.

El problema es el siguiente:

• Existe un ordenamiento con respecto al tiempo global dentro de cada grupo.
• No existe coordinación entre varios grupos.
• Resulta muy complicado implantar el orden con respecto al tiempo entre los distintos grupos, pero no siempre es necesario hacerlo.
• Escalabilidad
  Es necesario considerar cómo funcionarán los algoritmos cuando se tienen los siguientes casos:

• Grupos con centenas o miles de miembros.
• Centenas o miles de grupos.
• Utilización de varias LAN y compuertas (gateways) conectadas, es decir interred (internetwork).
• Diseminación de grupos en varios continentes.

Las compuertas pueden afectar la multitransmisión y el hecho requerido por algunas redes de tener un solo paquete en la red en un instante dado.

2.1.4 Tolerancia a fallos
Que el sistema de archivos sea tolerante a fallos implica qué el sistema debe guardar copias del mismo archivo en distintos ordenadores para garantizar la disponibilidad en caso de fallo del servidor original.
Se debe aplicar un algoritmo que nos permita mantener todas las copias actualizadas de forma constante, o un método alternativo que solo nos permita al archivo actualizado como invalidar el resto de copias cuando en cualquiera de ellas se vaya a realizar una operación de escritura.
•
FACTORES QUE AFECTAN LA FIABILIDAD EN LOS SISTEMAS
•
TECNICAS QUE PERMITEN TOLERAR FALLOS EN EL SISTEMA ALGUNOS FALLOS EN EL FUNCIONAMIENTO DE UN SISTEMA PUEDEN ORIGINARSE POR:
•
Especificaciones impropias o con errores.
•
Diseño deficiente e la creación del software y/o el hardware.
•
Deterioros o averías en al hardware.
Interferencias en las comunicaciones (temporales o permanentes).
1. Fallos temporales o transitorios: Desaparecen por si solos al cabo de un
tiempo.
2. Fallos permanentes: Duran hasta que se raparan.
3. Fallos intermitentes: Ocurren solo de vez en cuando.
PREVENCION Y TOLERANCIA A FALLOS
Existen dos formas de aumentar la fiabilidad de un sistema.
1. Prevención de fallos: Se trata de evitar que se implementen sistemas que
pueden introducir fallos.
2. Tolerancia a fallos: Se trata de conseguir que el sistema continué funcionando
correctamente aunque se presenten algunos fallos.
En ambos casos el objetivo es desarrollar sistemas con modos de fallos bien definidos.
HARDWARE:
•
Utilización de componentes fiables.
•
Técnicas rigurosas de ensamblaje de subsistemas.
SOFTWARE:
•
Especificación rigurosa de requisitos.
•
Métodos de diseños comprobados.
•
Lenguajes con abstracción de datos y modularidad.
LA REALIZACION SE BASA EN DOS ETAPAS
1. Evitación de fallos: impedir que se introduzcan fallos durante la construcción
del sistema.
2. Eliminación de fallos: consiste en encontrar y corregir los fallos que se
producen en el sistema una vez construido.
TECNICAS DE ELIMINACION DE FALLOS
Comprobaciones:

Revisiones del diseño.
Verificación de los programas.

Inspección del código.

Pruebas:

Son necesarias pero insuficientes.
Nunca llegan a ser exhaustivas

Solo sirven para mostrar que hay errores pero no que no los hay.

Los errores de especificaciones no se detectan.

LIMITACIONES DE LA PREVENCION DE FALLOS

Los componentes del hardware fallan a pesar de las técnicas de prevención.

La prevención es insuficiente si la frecuencia o la duración de las reparaciones es corta.

No se puede detener el sistema para efectuar reparaciones.

La alternativa es utilizar técnicas de tolerancia a fallos.

TOLERANCIA A FALLOS

Tolerancia completa: el sistema continúa funcionando durante un tiempo sin perder funcionabilidad.

Degradación elegante: El sistema sigue funcionando con una pérdida parcial de funcionabilidad hasta que se repare el fallo.

Parada segura: el sistema se detiene en un estado que asegura la integridad del entorno hasta que se repare el fallo.

2.2 Sincronización en Sistemas Distribuidos
Además de la comunicación, es fundamental la forma en que los procesos [25, Tanenbaum]:

• Cooperan.
• Se sincronizan entre sí.

Ejemplos:

• Forma de implantar las regiones críticas.
• Forma de asignar recursos en un sistema distribuido.

Los problemas relativos a las regiones críticas, exclusión mutua y la sincronización:

• Generalmente se resuelven en sistemas de una sola cpu con métodos como los semáforos y los monitores:
• Se basan en la memoria compartida.
• No son aplicables a sistemas distribuidos.

Otro problema de gran importancia es el tiempo y la forma de medirlo, ya que juega un papel fundamental en algunos modelos de sincronización.
Algoritmos para la Sincronización de Relojes
La sincronización de relojes en un sistemadistribuido consiste en garantizar que los procesosse ejecuten en forma cronológica y a la misma vez respetar el orden de los eventosdentro del sistema. Para lograr esto existen varios métodos o algoritmos que se programan dentro del sistema operativo, entre los cuales tenemos:

• Este algoritmo está basado en el uso del tiempocoordenado universal (siglas en inglés, UTC), el cual es recibido por un equipo dentro del sistema distribuido. Este equipo, denominado receptor de UTC, recibe a su vez solicitudes periódicas del tiempo del resto de máquinasdel sistema a cada uno de los cuales les envía una respuesta en el menor plazo posible informando el tiempo UTC solicitado, con lo cual todas las máquinas del sistema actualicen su hora y se mantenga así sincronizado todo el sistema. El receptor de UTC recibe el tiempo a través de diversos medios disponibles, entre los cuales se menciona las ondas de radio, Internet, entre otros.

Un gran problema en este algoritmo es que el tiempo no puede correr hacia atrás:

• El tiempo del receptor UTC no puede ser menor que el tiempo de la máquina que le solicitó el tiempo.
• El servidorde UTC debe procesar las solicitudes de tiempo con el concepto de interrupciones, lo cual incide en el tiempo de atención.
• El intervalo de transmisión de la solicitud y su respuesta debe ser tomado en cuenta para la sincronización. El tiempo de propagación se suma al tiempo del servidor para sincronizar al emisorcuando éste recibe la respuesta.

Algoritmo de Cristian
Un sistema distribuido basado en el algoritmo de Berkeley no dispone del tiempo coordenado universal (UTC); en lugar de ello, el sistema maneja su propia hora. Para realizar la sincronización del tiempo en el sistema, también existe un servidor de tiempo que, a diferencia del algoritmo de Cristian, se comporta de manera activa. Este servidor realiza un muestreo periódicodel tiempo que poseen algunas de las máquinas del sistema, con lo cual calcula un tiempo promedio, el cual es enviado a todas las máquinas del sistema a fin de sincronizarlo.
Algoritmo de Berkeley
En el algoritmo de Cristian el servidor de tiempo es pasivo.
En el algoritmo de Berkeley el servidor de tiempo:

• Es activo.
• Realiza un muestreo periódico de todas las máquinas para preguntarles el tiempo.
• Con las respuestas:
• Calcula un tiempo promedio.
• Indica a las demás máquinas que avancen su reloj o disminuyan la velocidad del mismo hasta lograr la disminución requerida.

Es adecuado cuando no se dispone de un receptor UTC.

Varias Fuentes Externas de Tiempo
Los sistemas que requieren una sincronización muy precisa con UTC se pueden equipar con varios receptores de UTC.
Las distintas fuentes de tiempo generaran distintos rangos (intervalos de tiempo) donde “caerán” los respectivos UTC, por lo que es necesaria una sincronización.
Como la transmisión no es instantánea se genera una cierta incertidumbre en el tiempo.
Cuando un procesador obtiene todos los rangos de UTC:

• Verifica si alguno de ellos es ajeno a los demás y de serlo lo descarta por ser un valor extremo.
• Calcula la intersección (en el tiempo) de los demás rangos.
• La intersección determina un intervalo cuyo punto medio será el UTC y la hora del reloj interno.

Se deben compensar los retrasos de transmisión y las diferencias de velocidades de los relojes.
Se debe asegurar que el tiempo no corra hacia atrás.
Se debe resincronizar periódicamente desde las fuentes externas de UTC.
Exclusión Mutua
Cuando un proceso debe leer o actualizar ciertas estructuras de datos compartidas [25, Tanenbaum]:

• Primero ingresa a una región crítica para lograr la exclusión mutua y garantizar que ningún otro proceso utilizará las estructuras de datos al mismo tiempo.

En sistemas monoprocesadores las regiones críticas se protegen con semáforos, monitores y similares.
En sistemas distribuidos la cuestión es más compleja.
Un Algoritmo Centralizado
La forma más directa de lograr la exclusión mutua en un sistema distribuido es simular a la forma en que se lleva a cabo en un sistema monoprocesador.
Se elige un proceso coordinador.
Cuando un proceso desea ingresar a una región crítica:

• Envía un mensaje de solicitud al coordinador:
• Indicando la región crítica.
• Solicitando permiso de acceso.
• Si ningún otro proceso está en ese momento en esa región crítica:
• El coordinador envía una respuesta otorgando el permiso.
• Cuando llega la respuesta el proceso solicitante entra a la región crítica.

Si un proceso pide permiso para entrar a una región crítica ya asignada a otro proceso:

• El coordinador no otorga el permiso y encola el pedido.

Cuando un proceso sale de la región crítica envía un mensaje al coordinador para liberar su acceso exclusivo:

• El coordinador extrae el primer elemento de la cola de solicitudes diferidas y envía a ese proceso un mensaje otorgando el permiso, con lo cual el proceso queda habilitado para acceder a la región crítica solicitada.

Es un esquema sencillo, justo y con pocos mensajes de control.
La limitante es que el coordinador puede ser un cuello de botella y puede fallar y bloquear a los procesos que esperan una respuesta de habilitación de acceso.
Un Algoritmo Distribuido
El objetivo es no tener un único punto de fallo (el coordinador central).
Un ej. es el algoritmo de Lamport mejorado por Ricart y Agrawala.
Se requiere un orden total de todos los eventos en el sistema para saber cuál ocurrió primero.
Cuando un proceso desea entrar a una región crítica:

• Construye un mensaje con el nombre de la región crítica, su número de proceso y la hora actual.
• Envía el mensaje a todos los demás procesos y de manera conceptual a él mismo.
• Se supone que cada mensaje tiene un reconocimiento.

Si el receptor no está en la región crítica y no desea entrar a ella, envía de regreso un mensaje o.k. al emisor.
Si el receptor ya está en la región crítica no responde y encola la solicitud.
Si el receptor desea entrar a la región crítica pero aún no lo logró, compara:

• La marca de tiempo del mensaje recibido con,
• La marca contenida en el mensaje que envió a cada uno.
• La menor de las marcas gana.
• Si el mensaje recibido es menor el receptor envía un o.k.
• Si su propio mensaje tiene una marca menor el receptor no envía nada y encola el pedido.

Luego de enviar las solicitudes un proceso:

• Espera hasta que alguien más obtiene el permiso.
• Cuando llegan todos los permisos puede entrar a la región crítica.

Cuando un proceso sale de la región crítica:

• Envía mensajes o.k. a todos los procesos en su cola.
• Elimina a todos los elementos de la cola.

La exclusión mutua queda garantizada sin bloqueo ni inanición.
El número de mensajes necesarios por entrada es “2(n - 1)”, siendo “n” el número total de procesos en el sistema.
No existe un único punto de fallo sino “n”:

• Si cualquier proceso falla no responderá a las solicitudes.
• La falta de respuesta se interpretará como negación de acceso:
• Se bloquearán los siguientes intentos de los demás procesos por entrar a todas las regiones críticas.

Se incrementa la probabilidad de fallo en “n” veces y también el tráfico en la red.
Se puede solucionar el bloqueo si:

• El emisor espera y sigue intentando hasta que regresa una respuesta o,
• El emisor concluye que el destinatario está fuera de servicio.

Otro problema es que:

• Se utilizará una primitiva de comunicación en grupo o,
• Cada proceso debe mantener la lista de miembros del grupo, incluyendo los procesos que ingresan, los que salen y los que fallan.
• Se complica para gran número de procesos.

Un importante problema adicional es que:

• Todos los procesos participan en todas las decisiones referentes a las entradas en las regiones críticas.
• Se sobrecarga el sistema.

Una mejora consiste en permitir que un proceso entre a una región crítica con el permiso de una mayoría simple de los demás procesos (en vez de todos):

• Luego de que un proceso otorgó el permiso a otro para entrar a una región crítica, no puede otorgar el mismo permiso a otro proceso hasta que el primero libere su permiso.

Un Algoritmo de Anillo de Fichas (Token Ring)
Los procesos se organizan por software formando un anillo lógico asignándose a cada proceso una posición en el anillo.
Cada proceso sabe cuál es el siguiente luego de él.
Al inicializar el anillo se le da al proceso “0” una ficha (token) que circula en todo el anillo, que se transfiere del proceso “k” al “k + 1” en mensajes puntuales.
Cuando un proceso obtiene la ficha de su vecino verifica si intenta entrar a una región crítica:

• En caso positivo:
• El proceso entra a la región crítica, hace el proceso necesario y sale de ella.
• Después de salir pasa la ficha a lo largo del anillo:
• No se puede entrar a una segunda región crítica con la misma ficha (token o permiso).
• En caso negativo:
• La vuelve a pasar.

En un instante dado solo un proceso puede estar en una región crítica.
Si la ficha se pierde debe ser regenerada, pero es difícil detectar su perdida:

• La cantidad de tiempo entre las apariciones sucesivas de la ficha en la red no está acotada, por ello es difícil decidir si está perdida o demorada en algún proceso que no la libera.

La falla de un proceso es detectada cuando su vecino intenta sin éxito pasarle la ficha:

• Se lo debe eliminar del grupo y pasar la ficha al siguiente proceso activo.
• Todos los procesos deben mantener la configuración actual del anillo.

Algoritmos de Elección
Son los algoritmos para la elección de un proceso coordinador, iniciador, secuenciador, etc. [25, Tanenbaum].
El objetivo de un algoritmo de elección es garantizar que iniciada una elección ésta concluya con el acuerdo de todos los procesos con respecto a la identidad del nuevo coordinador.
El Algoritmo del Grandulón o de García-Molina
Un proceso “P” inicia una elección cuando observa que el coordinador ya no responde a las solicitudes.
“P” realiza una elección de la siguiente manera:

• Envía un mensaje elección a los demás procesos con un número mayor.
• Si nadie responde asume que gana la elección y se convierte en el nuevo coordinador.
• Si un proceso con un número mayor responde, toma el control y el trabajo de “P” termina.

Un proceso puede recibir en cualquier momento un mensaje elección de otros procesos con un número menor:

• Envía de regreso un mensaje o.k. al emisor para indicar que está vivo y que tomará el control.
• Realiza una elección salvo que ya esté haciendo alguna.

En cierto momento todos los procesos han declinado ante uno de ellos, que será el nuevo coordinador, que envía un mensaje coordinador a todos los procesos para anunciarlo.
Si un proceso inactivo se activa realiza una elección:

• Si él tiene el número más alto será el nuevo coordinador:
• Siempre gana el proceso que posee el número mayor, de ahí el nombre “algoritmo del grandulón”.

Un Algoritmo de Anillo
Se supone que los procesos tienen un orden físico o lógico, es decir que cada proceso conoce a su sucesor.
Cuando algún proceso observa que el coordinador no funciona:

• Construye un mensaje elección con su propio número de proceso.
• Envía el mensaje a su sucesor.
• Si el sucesor está inactivo:
• El emisor va hacia el siguiente número del anillo o al siguiente de éste.
• Continúa hasta localizar un proceso en ejecución.
• En cada paso, al emisor añade su propio número de proceso a la lista en el mensaje.
• En cierto momento el mensaje regresa al proceso que lo inició:
• El proceso lo reconoce al recibir un mensaje con su propio número de proceso.
• El mensaje de elección se transforma en mensaje coordinador y circula nuevamente:
• Informa a los demás procesos:
• Quién es el coordinador, es decir, el miembro de la lista con el número mayor.
• Quiénes son los miembros del nuevo anillo.
• Concluida la ronda de información el mensaje coordinador se elimina y continúan los procesos.

Transacciones Atómicas
Las técnicas de sincronización ya vistas son de bajo nivel [25, Tanenbaum]:

• El programador debe enfrentarse directamente con los detalles de:
• La exclusión mutua.
• El manejo de las regiones críticas.
• La prevención de bloqueos.
• La recuperación de fallas.

Se precisan técnicas de abstracción de mayor nivel que:

• Oculten estos aspectos técnicos.
• Permitan a los programadores concentrarse en los algoritmos y la forma en que los procesos trabajan juntos en paralelo.

Tal abstracción la llamaremos transacción atómica, transacción o acción atómica.
La principal propiedad de la transacción atómica es el “todo o nada”:

• O se hace todo lo que se tenía que hacer como una unidad o no se hace nada.
• Ejemplo:
• Un cliente llama al Banco mediante una PC con un módem para:
• Retirar dinero de una cuenta.
• Depositar el dinero en otra cuenta.
• La operación tiene dos etapas.
• Si la conexión telefónica falla luego de la primer etapa pero antes de la segunda:
• Habrá un retiro pero no un depósito.
• La solución consiste en agrupar las dos operaciones en una transacción atómica:
• Las dos operaciones terminarían o no terminaría ninguna.
• Se debe regresar al estado inicial si la transacción no puede concluir.

El Modelo de Transacción
Supondremos que [25, Tanenbaum]:

• El sistema consta de varios procesos independientes que pueden fallar aleatoriamente.
• El software subyacente maneja transparentemente los errores de comunicación.

2.2.1 Relojes Lógicos
Las computadoras poseen un circuito para el registro del tiempo conocido como dispositivo reloj [25, Tanenbaum].
Es un cronómetro consistente en un cristal de cuarzo de precisión sometido a una tensión eléctrica que:

• Oscila con una frecuencia bien definida que depende de:
• Al forma en que se corte el cristal.
• El tipo de cristal.
• La magnitud de la tensión.
• A cada cristal se le asocian dos registros:
• Registro contador.
• Registro mantenedor.
• Cada oscilación del cristal decrementa en “1” al contador.
• Cuando el contador llega a “0”:
• Se genera una interrupción.
• El contador se vuelve a cargar mediante el registro mantenedor.
• Se puede programar un cronómetro para que genere una interrupción “x” veces por segundo.
• Cada interrupción se denomina marca de reloj.

Para una computadora y un reloj:

• No interesan pequeños desfasajes del reloj porque:
• Todos los procesos de la máquina usan el mismo reloj y tendrán consistencia interna.
• Importan los tiempos relativos.

Para varias computadoras con sus respectivos relojes:

• Es imposible garantizar que los cristales de computadoras distintas oscilen con la misma frecuencia.
• Habrá una pérdida de sincronía en los relojes (de software), es decir que tendrán valores distintos al ser leidos.

La diferencia entre los valores del tiempo se llama distorsión del reloj y podría generar fallas en los programas dependientes del tiempo.
Lamport demostró que la sincronización de relojes es posible y presentó un algoritmo para lograrlo.
Lamport señaló que la sincronización de relojes no tiene que ser absoluta:

• Si 2 procesos no interactúan no es necesario que sus relojes estén sincronizados.
• Generalmente lo importante no es que los procesos estén de acuerdo en la hora, pero sí importa que coincidan en el orden en que ocurren los eventos.

Para ciertos algoritmos lo que importa es la consistencia interna de los relojes:

• No interesa su cercanía particular al tiempo real (oficial).
• Los relojes se denominan relojes lógicos.

Los relojes físicos son relojes que:

• Deben ser iguales (estar sincronizados).
• No deben desviarse del tiempo real más allá de cierta magnitud.

Para sincronizar los relojes lógicos, Lamport definió la relación ocurre antes de (happens-before):

• Si “a” y “b” son eventos en el mismo proceso y “a” ocurre antes de “b”, entonces “a –> b” es verdadero.
• “Ocurre antes de” es una relación transitiva:
• Si “a –> b” y “b –> c”, entonces “a –> c”.
• Si dos eventos “x” e “y” están en procesos diferentes que no intercambian mensajes, entonces “x –> y” no es verdadero, pero tampoco lo es “y –> x”:
• Se dice que son eventos concurrentes.

Necesitamos una forma de medir el tiempo tal que a cada evento “a”, le podamos asociar un valor del tiempo “C(a)” en el que todos los procesos estén de acuerdo:

• Se debe cumplir que:
• Si “a –> b” entonces “C(a) < C(b)”.
• El tiempo del reloj, “C”, siempre debe ir hacia adelante (creciente), y nunca hacia atrás (decreciente).

El algoritmo de Lamport asigna tiempos a los eventos.
Consideramos tres procesos que se ejecutan en diferentes máquinas, cada una con su propio reloj y velocidad (ver Figura 9.1 [25, Tanenbaum]):

• El proceso “0” envía el mensaje “a” al proceso “1” cuando el reloj de “0” marca “6”.
• El proceso “1” recibe el mensaje “a” cuando su reloj marca “16”.
• Si el mensaje acarrea el tiempo de inicio “6”, el proceso “1” considerará que tardó 10 marcas de reloj en viajar.
• El mensaje “b” de “1” a “2” tarda 16 marcas de reloj.
• El mensaje “c” de “2” a “1” sale en “60” y llega en “56”, tardaría un tiempo negativo, lo cual es imposible.
• El mensaje “d” de “1” a “0” sale en “64” y llega en “54”.
• Lamport utiliza la relación “ocurre antes de”:
• Si “c” sale en “60” debe llegar en “61” o en un tiempo posterior.
• Cada mensaje acarrea el tiempo de envío, de acuerdo con el reloj del emisor.
• Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se envió el mensaje:
• El receptor adelanta su reloj para que tenga una unidad más que el tiempo de envío.

Este algoritmo cumple nuestras necesidades para el tiempo global, si se hace el siguiente agregado:

• Entre dos eventos cualesquiera, el reloj debe marcar al menos una vez.
• Dos eventos no deben ocurrir exactamente al mismo tiempo.

Con este algoritmo se puede asignar un tiempo a todos los eventos en un sistema distribuido, con las siguientes condiciones:

• Si “a” ocurre antes de “b” en el mismo proceso, “C(a) < C(b)”.
• Si “a” y “b” son el envío y recepción de un mensaje, “C(a) < C(b)”.
• Para todos los eventos “a” y “b”, “C(a)” es distinto de “C(b)”.

2.2.2 Relojes Físicos
El algoritmo de Lamport proporciona un orden de eventos sin ambigüedades, pero [25, Tanenbaum]:

• Los valores de tiempo asignados a los eventos no tienen porqué ser cercanos a los tiempos reales en los que ocurren.
• En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj:
• Se precisan relojes físicos externos (más de uno).
• Se deben sincronizar:
• Con los relojes del mundo real.
• Entre sí.

La medición del tiempo real con alta precisión no es sencilla.
Desde antiguo el tiempo se ha medido astronómicamente.
Se considera el día solar al intervalo entre dos tránsitos consecutivos del sol, donde el tránsito del sol es el evento en que el sol alcanza su punto aparentemente más alto en el cielo.
El segundo solar se define como 1 / 86.400 de un día solar.
Como el período de rotación de la tierra no es constante, se considera el segundo solar promedio de un gran número de días.
Los físicos definieron al segundo como el tiempo que tarda el átomo de cesio 133 para hacer 9.192.631.770 transiciones:

• Se tomó este número para que el segundo atómico coincida con el segundo solar promedio de 1958.

La Oficina Internacional de la Hora en París (BIH) recibe las indicaciones de cerca de 50 relojes atómicos en el mundo y calcula el tiempo atómico internacional (TAI).
Como consecuencia de que el día solar promedio (DSP) es cada vez mayor, un día TAI es 3 mseg menor que un DSP:

• La BIH introduce segundos de salto para hacer las correcciones necesarias para que permanezcan en fase:
• El sistema de tiempo basado en los segundos TAI.
• El movimiento aparente del sol.
• Surge el tiempo coordenado universal (UTC).

El Instituto Nacional del Tiempo Estándar (NIST) de EE. UU. y de otros países:

• Operan estaciones de radio de onda corta o satélites de comunicaciones.
• Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.).
• Se deben conocer con precisión la posición relativa del emisor y del receptor:
• Se debe compensar el retraso de propagación de la señal.
• Si la señal se recibe por módem también se debe compensar por la ruta de la señal y la velocidad del módem.
• Se dificulta la obtención del tiempo con una precisión extremadamente alta.

Algoritmos con Promedio
Los anteriores son algoritmos centralizados.
Una clase de algoritmos descentralizados divide el tiempo en intervalos de resincronización de longitud fija:

• El i -ésimo intervalo:
• Inicia en “T0 + i R” y va hasta “T0 + (i + 1) R”.
• “T0” es un momento ya acordado en el pasado.
• “R” es un parámetro del sistema.

Al inicio de cada intervalo cada máquina transmite el tiempo actual según su reloj.
Debido a la diferente velocidad de los relojes las transmisiones no serán simultáneas.
Luego de que una máquina transmite su hora, inicializa un cronómetro local para reunir las demás transmisiones que lleguen en cierto intervalo “S”.
Cuando recibe todas las transmisiones se ejecuta un algoritmo para calcular una nueva hora para los relojes.
Una variante es promediar los valores de todas las demás máquinas.
Otra variante es descartar los valores extremos antes de promediar (los “m” mayores y los “m” menores).
Una mejora al algoritmo considera la corrección por tiempos de propagación.

2.3 Usos De La Sincronización Manejo De Cache Comunicación En Grupo Exclusión Mutua Elección Transacciones Atómicas E Interbloqueo

            Enfoque iniciado por el cliente, el cliente inicia una comprobación de validez, en la cual se pone en contacto con el servidor y comprueban si los datos locales son consistentes con la copia maestra.

            Enfoque iniciado por el servidor, el servidor anota, para cada cliente, las partes de los archivos que coloca en memoria cache, y cuando detecta una inconsistencia, debe reaccionar. Una posible fuente inconsistencia ocurre cuando dos clientes, que trabajan en modos conflictivos, colocan en memoria caché un archivo.

            Cada interrupción añade 10 mseg al tiempo. 

            Para atrasar solo agregaría 9 mseg. 

            Para adelantar agregaría 11 mseg. 

            Calcula un tiempo promedio. 

            Indica a las demás máquinas que avancen su reloj o disminuyan la velocidad del mismo hasta lograr la disminución requerida. 

            Inicia en “T0 + i R” y va hasta “T0 + (i + 1) R”. 

            “T0” es un momento ya acordado en el pasado. 

            “R” es un parámetro del sistema. 

            Indicando la región crítica. 

            Solicitando permiso de acceso. 

            El coordinador envía una respuesta otorgando el permiso. 

            El programador debe enfrentarse directamente con los detalles de: 

            La exclusión mutua. 

            El manejo de las regiones críticas. 

            La prevención de bloqueos. 

            La recuperación de fallas. 

            Oculten estos aspectos técnicos. 

            Permitan a los programadores concentrarse en los algoritmos y la forma en que los procesos trabajan juntos en paralelo. 

            O se hace todo lo que se tenía que hacer como una unidad o no se hace nada. 

            Ejemplo: 

            Un cliente llama al Banco mediante una PC con un módem para: 

            Retirar dinero de una cuenta. 

            Depositar el dinero en otra cuenta. 

            La operación tiene dos etapas. 

            Si la conexión telefónica falla luego de la primer etapa pero antes de la segunda: 

            Habrá un retiro pero no un depósito. 

            La solución consiste en agrupar las dos operaciones en una transacción atómica: 

            Las dos operaciones terminarían o no terminaría ninguna. 

            Se debe regresar al estado inicial si la transacción no puede concluir.