2.2.2 Relojes lógicos.

•Internamente cada computadora contiene un reloj físico, el cual cuenta la frecuencia de las oscilaciones de un cristal para medir el tiempo a través de una estampa o marca de tiempo.

•

•Cada máquina puede interpretar de forma distinta los pulsos de reloj, aunque la diferencia puede ser prácticamente nula, después de un tiempo se pueden ver los efectos.

•Una forma más sencilla de sincronizar el tiempo de sistemas distribuidos es a través del uso de relojes lógicos.

•

•Un reloj lógico es una convención utilizada para ponerse de acuerdo en cuestión del tiempo.

•Un ejemplo es el UTC (Universal Time Coordinated) que se basa en relojes atómicos coordinados con el astronómico.

2.2.1 Relojes físicos.

•El objetivo de la sincronización de relojes es ordenar los eventos en forma cronológica para saber cuándo se efectuó un evento (fecha, hora, proceso a realizar y computadora que lo hizo).

•Hay 2 tipos de sincronización del reloj:

•

•Externa: Cuando se toma el reloj de un dispositivo externo a la computadora.

•Interna: Se toman los relojes internos de las computadoras con cierto margen de atraso/adelanto de los mismos.

•Problemática de sincronización del tiempo: el tiempo es relativo…

•Se utiliza más el término cronómetro que reloj para medir el tiempo en sistemas distribuidos.

•

•Aun considerando un tiempo uniforme existen problemas cuando se sincronizan cronómetros a través de la red:

•No se puede calcular con exactitud el tiempo que tardará una respuesta en llegar

2.1.4 Tolerancia a fallos.

•La tolerancia a fallas es considerada la principal característica que debe de tener un sistema distribuido para alcanzar el principio de transparencia.

•

•Para lograr la tolerancia a fallos se necesita de una buena comunicación entre procesos distribuidos y sobretodo de una correcta coordinación entre procesos

•Un Sistema Distribuido en base a la coordinación de sus procesos puede ser:

–Asíncrono: no hay coordinación en el tiempo.

–Síncrono: se suponen límites máximos para el retraso de mensajes.

•El primer factor a tomar en cuenta es que el canal de comunicación este libre de errores (canal confiable).

•Para garantizar que el canal sea confiable se debe de realizar lo siguiente:

–Retransmisión de mensajes.

–Debe haber redundancia de canales

–La entrega de un paquete sea dentro de un tiempo límite especificado

•

En general, se considera que los canales de comunicación son fiables y que cuando falla la comunicación es debido a la caída del proce

2.1.3 Comunicación en grupo.

•Se define a un grupo como un conjunto de procesos que actúan entre ellos encierto sistema.

•Los grupos son dinámicos, ya que pueden aceptar nuevos procesos o estos pueden  dejar a su grupo.

Los grupos pueden ser abiertos o cerrados dependiendo de cómo es el paso de mensajes entre los elementos del grupo. 

2.1.2 Comunicación con RPC.

•El problema del manejo de procesos distribuidos con sockets radica en que se basa en el flujo de E/S, haciendo los programas más difíciles de estructurar.

•

•En 1984 Birelly y Nelson idearon el modelo de RPC a semejanza del llamado de procedimientos locales (LPC).

2.1.1 Comunicación Con Cliente Servidor (Sockets).

Comunicación con cliente
servidor (sockets).

El proceso para la creacion de un servicio siempre comienza   con la creacion del Socker. Asi como el cliente necesita llamadas especificas en determinados mometos, el servidor trabajo de modo similar pero añade unas pocas llamadas extras al sistema. El servidor utiliza la llamada del sistema Socket(), pero debe hacer un trabajo extra que era opcional para el cliente, 

el cliente   simpre realiza un a conexión activa porque la persigue energicamente
los servidores por   otro lado necesitan proporcionar un numero   de puesto especifico y consiste a los programas clientes si les va a prestar servicio. El programa servido que escriba debera utilizar las llamadas de sistema socker(), bind(), listen(), accept(). Y mientras el programa cliente es una conexión activa,el servidor es una conexión   pasiva. Las llamadas de isistemas() y accept() crean una coneccion solo cuando el cliente pide una conexión (similar a la accion de responder al timbre de un telefono

El ejemplo de servidor escucha en un socket (puerto 8000) esperando peticiones entrantes. Cualquier programa, como el client.c de ejemplo, puede conectar con este ser­vidor y pasarle hasta 16.384 hytes de datos
El servidor trata los datos como datos ASCII y los convierte en mayúsculas antes de pasárselos a! programa cliente.
Estos dos sencillos programas se pueden volver a utilizar fácilmente cuando se escriban programas cliente-servidor basados en socket

Los servidores que pueden recibir muchas peticiones simultáneas utilizan fork para crear un proceso separado para la administración de peti­ciones de servicio constitucionalmente caras. 
server.c crea un socket permanente para la escucha de peticiones de ser­vicio; cuando un cliente conecta con el servidor, se crea un socket temporal. Cada vez que un cliente conecta con un servidor, se abre un nuevo socket temporal entre el cliente y el servidor.

2.2 Sincronización.