Unidad 2 1 PDF

Comunicacin
La diferencia ms importante entre un sistema distribuido y

un sistema de un nico procesador es la comunicacin entre
procesos.
En un sistema de un solo procesador la comunicacin supone
implcitamente la existencia de la memoria compartida.
En un sistema distribuido no existe la memoria compartida y por
ello toda la naturaleza de la comunicacin entre procesos debe
replantearse.
Los procesos, para comunicarse, deben apegarse a reglas

conocidas como protocolos.
Para los sistemas distribuidos en un rea amplia, estos
protocolos toman frecuentemente la forma de varias capas y
cada capa tiene sus propias metas y reglas.
21/09/16
Unidad 2 Comunicacin en los

sistemas operativos distribuidos
Comunicacin
Para lograr la distribucin de procesos se requiere de
mecanismos que permitan coordinar y controlar la
ejecucin de procesos en ambientes no centralizados,
ya sean de manera local y remota.
Los primeros protocolos para la distribucin de
procesos remotos fueron para mquinas homogneas.
PROTOCOLOS CON CAPAS

Debido a la ausencia de memoria compartida, toda la
comunicacin en los SD se basa en la transferencia de
mensajes. Cuando el proceso A quiere comunicarse con
el proceso B, construye primero un mensaje en su
propio espacio de direcciones. Entonces ejecuta una
llamada al sistema para que el SO busque el mensaje y
lo envi a travs de la red hacia B.
Aunque esta idea bsica suena muy sencilla, para evitar
el caos, A y B deben coincidir en el significado de los
bits que se enven.
Para facilitar el trabajo con los distinto niveles y

aspectos correspondientes a la comunicacin, la
Organizacin Internacional de Estndares [International
Standards Organization (ISO)] ha desarrollado un
modelo de referencia que identifica en forma cara los
distintos niveles, les da nombres estandarizados y
seala cul nivel debe realizar cada trabajo.
Este modelo se llama el Modelo de Referencia para
Interconexin de Sistemas abiertos (modelo OSI).
Capa fsica. Se preocupa por la transmisin de los

ceros y unos.
Capa de enlace de datos. Agrupa los bits en unidades,
que a veces se llaman marcos, y revisar que cada
marco se reciba en forma correcta.
Capa de red. Su tarea principal es la cuestin de la
eleccin de la mejor ruta (ruteo).
Capa de transporte. Divide un mensaje en pequeas
partes (paquetes), asigna a c/u un numero secuencial y
despus los enva.
Capa de sesin. Proporciona el control del dialogo, con el fin de

mantener un registro de la parte que est hablando en cierto
momento y proporciona facilidades de sincronizacin.
Capa de presentacin. Se preocupa por el significado de los bits.

Es posible definir registros que contengan campos como estos:
nombres, direcciones; y que el emisor notifique al receptor que un
mensaje contiene un registro particular en cierto formato.
Capa de aplicacin. Es una coleccin de varios protocolos para

actividades comunes, como el correo electrnico, la transferencia
de archivos y la conexin entre terminales remotas a las
computadoras
MODELO CLIENTE - SERVIDOR

El modelo OSI slo se enfoca hacia un pequeo
aspecto: llevar los bits del emisor hacia el receptor (y en
los niveles superiores, su significado). No dice nada
acerca de la forma de estructurar al SD. Se necesita
algo adicional.
Ese algo adicional es el modelo cliente servidor, con la
idea de estructurar el SO como un grupo de procesos en
cooperacin, llamados servidores, que ofrezcan
servicios a los usuarios, llamados clientes.
Para evitar un gasto excesivo en los protocolos orientados hacia la

conexin como OSI o TCP/IP, lo usual es que el modelo clienteservidor se base en un protocolo solicitud/respuesta sencillo y sin
conexin.
El cliente enva un mensaje de solicitud al servidor para pedir cierto

servicio. El servidor hace el trabajo y regresa los datos solicitados o
un cdigo de error para indizar la razn por la cual un trabajo no se
pudo llevar a cabo.
Sockets
Los sockets son el mecanismo de sincronizacin
distribuida ms importante.
Se les denomina conectores por que pueden unir un proceso
cliente y un proceso servidor, de manera semejante a como
se puede unir un enchufe de un dispositivo elctrico con su
respectivo zcalo.
Comunicacin con cliente servidor

(sockets)
Los sockets no son ms que puntos o mecanismos de
comunicacin entre procesos que permiten que un proceso
hable (emita o reciba informacin) con otro proceso incluso
estando estos procesos en distintas mquinas. Esta
caracterstica de interconectividad entre mquinas hace que el
concepto de socket nos sea de gran utilidad.
21/09/16

Un socket es el sistema de comunicacin entre

ordenadores lo que un buzn o un telfono es al sistema de
comunicacin entre personas: un punto de comunicacin entre
dos agentes (procesos o personas respectivamente) por el cual
se puede emitir o recibir informacin. La forma de referenciar
un socket por los procesos implicados es mediante un
descriptor del mismo tipo que el utilizado para referenciar
ficheros.
21/09/16

La comunicacin entre procesos a travs de sockets

se basa en la filosofa Cliente-Servidor: un proceso en esta
comunicacin actuar de proceso servidor creando un
socket cuyo nombre conocer el proceso cliente, el cual
podr "hablar" con el proceso servidor a travs de la
conexin con dicho socket nombrado.
El proceso crea un socket sin nombre cuyo valor de
vuelta es un descriptor sobre el que se leer o escribir,
permitindose
una
comunicacin
bidireccional,
caracterstica propia de los sockets y que los diferencia de
los pipes, o canales de comunicacin unidireccional entre
procesos de una misma mquina.
21/09/16

Sockets
Los sockets trabajan sobre la capa 4 (Transporte) del
modelo OSI, aunque algunos autores la ubican en la
capa 5 (Sesin).
Para la comunicacin de procesos remotos se necesita
conocer la direccin de la mquina destino y el puerto
donde se va a escuchar.
Funciones de un servidor
1. Abrir el canal de comunicacin e informar a la red su
direccin y su disposicin para aceptar peticiones de
servicio.
2. Esperar a que un cliente pida un servicio
3. Atender un cliente (servidor interactivo) a la vez o crear
un proceso hijo (servidor concurrente)
4. Volver al punto 2 para esperar nuevas peticiones.
Funciones de un cliente
1. Abrir el canal de comunicaciones y conectarse a
la direccin del servidor.
2. Enviar al servidor un mensaje de peticin de
servicio y esperar hasta recibir la respuesta.
3. Cerrar el canal de comunicaciones y terminar la
ejecucin.
Primitivas de sockets en el cliente

Las primitivas de sockets pueden ser
bloqueantes y no bloqueantes
socket();
connect();
write();
read();
close();
Diagrama de Sockets Stream
Primitivas de sockets en el servidor

Las primitivas son para comunicacin orientada
a conexin (Stream)
socket();
bind();
listen();
accept();
read();
write();
Primitivas de sockets en el servidor

Las primitivas son para comunicacin entre
procesos no orientada a conexin
(Datagramas).
socket();
bind();
recvfrom();
sendto();
Sockets
Para establecer una comunicacin a travs de
sockets se necesitan 5 requerimientos:
Direccin del servidor
Puerto del servidor
Direccin del cliente
Puerto del cliente
Canal de comunicacin abierto
import java.io.*; import java.net.*; class Cliente

{
static final String HOST = localhost;
static final int PUERTO=5000;
public Cliente( )
{
try
{
Socket skCliente = new Socket( HOST , Puerto );
Input Stream aux = skCliente.getInputStream();
Data Input Stream? flujo = new Data Input Stream( aux );
);
skCliente.close();
}
catch( Exception e )
{
System.out.println( e.getMessage() );
}
}
public static void main( String[] arg )
{
new Cliente();
}
}
System.out.println( flujo.readUTF()
RPC
En 1984 Birell y Nelson idearon el modelo de RPC a semejanza del

llamado de procedimientos locales (LPC).
Lo que ellos sugirieron fue permitir que los programas llamaran a

procedimientos ubicados en otras maquinas.
Cuando un proceso de la maquina A llama a un procedimiento de la

maquina B, el proceso que llama desde A se suspende, y la ejecucin del
procedimiento llamado ocurre en B. la informacin puede transportarse en
los parmetros desde quien llama hasta el que el llamado, y puede regresar
en el procedimiento resultante.
La Comunicacin: RPC
La RPC no son mas que operaciones remotas disfrazadas de una interfaz

procedural.
Estructura de las RPC
La aplicacin cliente llama a

una subrutina que se ejecuta en
otra aplicacin: la rutina de
servicio en el servidor.
Si las aplicaciones cliente y

servidor formaran parte del
mismo proceso, el cliente
llamara directamente a la rutina
que ejecuta l servicio; sin
embargo aqu el cliente tiene
que llamar a otra subrutina que
se denomina stub del cliente.
Esta subrutina tiene la misma

interfaz que la rutina de servicio
del servidor.
RPC
El nivel de transparencia en RPC es muy alto
ya que el usuario no tiene que ver con detalles
de conexin.
La simplicidad de toda esta heterogeneidad en
el llamado a un procedimiento remoto es
realizado por los stubs (resguardos) tanto en el
cliente como en el servidor.
RPC
Para la transferencia de datos entre los stubs,
se necesita de un proceso de empacar
desempacar los parmetros y resultados.
Los stubs se comunican con los ncleos de
cada proceso logrando una transparencia muy
alta.
RPC
La secuencia de mensajes RPC es la siguiente:
1. El procedimiento cliente llama al stub del cliente de la
manera usual.
2.El stub del cliente construye un mensaje y hace un
sealamiento al ncleo.
3.El ncleo enva el mensaje al ncleo remoto.
RPC
4. El ncleo remoto proporciona el mensaje al stub del
servidor.
5. El stub del servidor desempaca los parmetros y
llama al servidor.
6. El servidor realiza el trabajo y regresa el resultado al
stub.
7. El stub del servidor empaca el resultado en un
mensaje y hace un sealamiento al ncleo.
RPC
8. El ncleo remoto enva el mensaje al ncleo del
cliente.
9. El ncleo del cliente da el mensaje al stub del
cliente.
10. El stub desempaca el resultado y lo regresa al
cliente.
21/09/16

RPC
La semntica de fallas de RPC es la siguiente:
1. El cliente no puede localizar al servidor.
2. Se pierde el mensaje de solicitud del cliente al servidor
3. Se pierde el mensaje de respuestas del servidor al cliente.
4. El servidor falla antes de recibir una solicitud.
5. El cliente falla despus de enviar una solicitud.
Comunicacin en grupo
Una hiptesis subyacente e intrnseca de RPC es que la
comunicacin solo es entre dos partes: el cliente y el servidor.
A veces existen circunstancias en las que la comunicacin es entre
varios procesos y no solo dos:
Ej.: un grupo de servidores de archivo que cooperan para ofrecer

un nico servicio de archivos tolerante a fallos:
Sera recomendable que un cliente enve el mensaje a todos
los servidores para garantizar la ejecucin de la solicitud
aunque alguno falle.
RPC no puede controlar la comunicacin de un servidor con

muchos receptores, a menos que realice RPC con cada uno en
forma individual.
21/09/16

21/09/16

34
Comunicacin en Grupo
Se define a un grupo como un conjunto de
procesos que actan entre ellos en cierto sistema.
Los grupos son dinmicos, ya que pueden aceptar
nuevos procesos o estos pueden dejar a su grupo.
Los grupos pueden ser abiertos o cerrados
dependiendo de cmo es el paso de mensajes entre
los elementos del grupo.
En base a su organizacin los grupos pueden ser
de compaeros (cuando todos los procesos son
iguales y para hacer elecciones hacen recuento de
votos) o Jerrquico (donde existe un proceso
coordinador y el resto son trabajadores).
Cuando entran nuevos procesos o se salen del
grupo, se debe garantizar que los mensajes lleguen
a los procesos que actualmente conforman el
grupo.
Comunicacin en grupo
Una de las mayores problemticas con respecto a la
comunicacin en Sistemas Distribuidos es la forma en
como podemos comunicar varios procesos
distribuidos a la vez.
La comunicacin tradicional es del tipo puntual
(unicast) o bien hacia todos con el uso de la difusin
(broadcast).
El problema radica en que al hacer un broadcast los
mensajes llegan hacia todas las mquinas y no hay
forma alguna de discriminar hacia un grupo
determinado de procesos.
Por otra parte, el hacer broadcast est limitado en
muchas redes como Internet donde no existe, por este
motivo suele utilizarse la tcnica de multicast.
El problema del multicast es que se
necesitan de direcciones IP especiales
(Clase D) para poderse llevar acabo. En la
prctica se utiliza muy poco y en lugar se
usa comunicacin con datagramas hacia un
grupo de procesos donde la parte ms
importante es la coordinacin entre
procesos.
Tolerancia a fallos
La difusin de los sistemas distribuidos incrementa la
demanda de sistemas que esencialmente nunca fallen.
Los sistemas tolerantes a fallos requerirn cada vez
ms una considerable redundancia en hardware,
comunicaciones, software, datos, etc. La rplica de
archivos sera un requisito esencial.
Tambin debera contemplarse la posibilidad de que
los sistemas funcionen an con la carencia de parte de
los datos. Los tiempos de fallo aceptables por los
usuarios sern cada vez menores.
21/09/16

Se dice que un sistema falla cuando no cumple su

especificacin. En algunos casos, como en un
sistema de ordenamiento distribuido de productos en
un supermercado, una falla podra provocar la falta
de algunos productos en la tienda.
En otros casos, como en un sistema distribuido para
el control de trfico areo, una falla podra ser
catastrfica. Como las computadoras y los sistemas
distribuidos se utilizan cada vez ms en misiones
donde la seguridad es crtica, la necesidad de
soportar las fallas cada vez es mayor.
21/09/16

Un desperfecto de un sistema ocurre cuando el sistema no

desempea estos servicios de la manera especificada. Un
estado errneo en un sistema es un estado en el cual
podra conducir a un fallo en el sistema.
Un fallo es una condicin fsica anormal, las causas de un
fallo incluyen: errores de diseo (como errores en la
especificacin del sistema o en la implementacin),
problemas de fabricacin, deterioro por el uso u otros
problemas externos (como condiciones ambientales
adversas,
interferencia
electromagntica,
entradas
imprevistas o el mal uso del sistema). Un error es una parte
del estado del sistema la cual difiere de los valores
esperados.
21/09/16

Tolerancia a fallos
La tolerancia a fallas es considerada la principal
caracterstica que debe de tener un sistema
distribuido para alcanzar el principio de
transparencia.
Para lograr la tolerancia a fallos se necesita de una
buena comunicacin entre procesos distribuidos y
sobretodo de una correcta coordinacin entre
procesos.
Tolerancia a fallos
Un Sistema Distribuido en base a la coordinacin
de sus procesos puede ser:
Asncrono: no hay coordinacin en el tiempo.
Sncrono: se suponen lmites mximos para el
retraso de mensajes.
El primer factor a tomar en cuenta es que el canal
de comunicacin este libre de errores (canal
confiable).
Tolerancia a Fallos
Para garantizar que el canal sea confiable se debe
de realizar lo siguiente:
Retransmisin de mensajes.
Debe haber redundancia de canales
La entrega de un paquete sea dentro de un
tiempo lmite especificado
En general, se considera que los canales de
comunicacin son fiables y que cuando falla la
comunicacin es debido a la cada del proceso.
Tolerancia a Fallos
Las fallas de particin son las fallas de
comunicacin ms importantes ya que fragmentan
la red en pequeas reas llamadas particiones
haciendo imposible el manejo de la consistencia
de los datos.
Son difciles de detectar ya que no son visibles
para todos los nodos de la red.
Tolerancia a Fallas
Las fallas de particin pueden ser muy
comunes por lo que los sistemas de
archivos deben tener un mecanismo que
permita reintegrar los datos una vez
eliminada la particin.
Esta idea atrado como consecuencia el uso
de sistemas de archivos con soporte a
desconexin, los cuales son tiles en
entornos de cmputo mvil.
Tolerancia a Fallos
Tolerancia a Fallos
Tolerancia a Fallos
Para prevenir errores se utilizan los
Detectores de Fallo, los cuales son procesos
que nos indican la presencia de fallos en un
sistema.
Los detectores de fallos no son
necesariamente exactos y la mayora de ellos
se consideran Detectores de Fallo No
Fiables
Tolerancia a Fallos
Este tipo de detectores se basan en que si en un
tiempo mximo predefinido no reciben mensajes
de los nodos, los consideran sospechosos, aunque
no necesariamente han fallado, esto puede ocurrir
debido a retrasos en la transmisin.
Un Detector de Fallas Fiable detecta los fallos en
un sistema en forma exacta y normalmente
requieren de hardware y software adicional.
Sincronizacin
Sincronizacin es la forma de forzar un orden
parcial o total en cualquier conjunto de evento
Se utilizan algoritmos distribuidos para sincronizar
el trabajo comn entre los procesos-
RELOJES FSICOS
El objetivo de la sincronizacin de relojes es
ordenar los eventos en forma cronolgica para
saber cundo se efectu un evento (fecha,
hora, proceso a realizar y computadora que lo
hizo).
Diferencias de relojes internos en una red
8:06
8:05
8:12
8:13
La idea es proveer de un nico bloque de

tiempo para el sistema. Los procesos pueden
usar la marca fsica del tiempo provista o leda
de un reloj central para expresar algn orden en
el conjunto de acciones que inician.
La principal ventaja de este mecanismo es la
simplicidad,
aunque
existen
varios
inconvenientes: el correcto registro del tiempo
depende en la posibilidad de recibir
correctamente y en todo momento, el tiempo
actual desplegado por el reloj fsico.
Los errores de transmisin se convierten en un

impedimento para el orden deseado, el grado de
exactitud depende de las constantes puestas en el
sistema.
Los valores de tiempo asignados a los eventos no
tienen porqu ser cercanos a los tiempos reales en los
que ocurren.
En ciertos sistemas es importante la hora real del reloj:
Se precisan relojes fsicos externos (ms de uno).
Se deben sincronizar:
Con los relojes del mundo real.
Entre s
Sincronizacin de relojes
Hay 2 tipos de sincronizacin 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.
Sincronizacin del Tiempo

Se utiliza ms el trmino cronmetro que reloj para
medir el tiempo en sistemas distribuidos.
Aun considerando un tiempo uniforme existen
problemas cuando se sincronizan cronmetros a
travs de la red:
No se puede calcular con exactitud el tiempo que
tardar una respuesta en llegar
Relojes fsicos.
El algoritmo de Lamport proporciona un orden de eventos sin ambigedades,
pero:
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 fsicos externos (ms de uno).
Se deben sincronizar:
Con los relojes del mundo real.
Entre s.
La medicin del tiempo real con alta precisin no es sencilla. Desde antiguo el
tiempo se ha medido astronmicamente.
Se considera el da solar al intervalo entre dos trnsitos consecutivos del sol,
donde el trnsito del sol es el evento en que el sol alcanza su punto
aparentemente ms alto en el cielo.
21/09/16

El segundo solar se define como 1 / 86.400 de un da solar.

Como el perodo de rotacin de la tierra no es constante, se considera el
segundo solar promedio de un gran nmero de das.
Los fsicos definieron al segundo como el tiempo que tarda el tomo de cesio
133 para hacer 9.192.631.770 transiciones:
Se tom este nmero para que el segundo atmico coincida con el segundo
solar promedio de 1958.
La Oficina Internacional de la Hora en Pars (BIH) recibe las indicaciones de
cerca de 50 relojes atmicos en el mundo y calcula el tiempo atmico
internacional (TAI).
Como consecuencia de que el da solar promedio (DSP) es cada vez mayor, un
da 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).
21/09/16

59
El Instituto Nacional del Tiempo Estndar (NIST) de EE. UU. y

de otros pases:
Operan estaciones de radio de onda corta o satlites de
comunicaciones.
Transmiten pulsos UTC con cierta regularidad establecida (cada
segundo, cada 0,5 mseg, etc.).
Se deben conocer con precisin la posicin relativa del emisor y
del receptor:
Se debe compensar el retraso de propagacin de la seal.
Si la seal se recibe por mdem tambin se debe compensar
por la ruta de la seal y la velocidad del mdem.
Se dificulta la obtencin del tiempo con una precisin
extremadamente alta.
21/09/16

RELOJES LGICOS
Casi todas las computadoras tienen un circuito
para el registro del tiempo.
En realidad no son relojes en sentido usual.
Cronmetro sera una mejor palabra.
Un cronmetro de computadora es por lo general
un cristal de cuarzo trabajando con precisin.
Cuando se mantiene sujeto a tensin, un cristal de
cuarzo oscila con frecuencia bien definida, que
depende del tipo de cristal, la forma en que se
corte y la magnitud de la tensin.
A cada cristal se le asocian dos registros, un

contador y un registro mantenedor. Cada oscilacin
del cristal disminuye en 1 al contador. Cuando el
contador toma el valor 0, se genera una interrupcin y
el contador se vuelve a cargar mediante el registro
mantenedor.
De esta forma, es posible programar un cronmetro
de modo que genere una interrupcin 60 veces por
cada segundo o con cualquier frecuencia que se
desee. Cada interrupcin recibe el nombre de marca
de reloj.
Tan pronto se comienza a trabajar con varias

mquinas, cada una con su propio reloj, la
situacin es distinta.
Aunque la frecuencia de un oscilador de cristal es
muy estable, es imposible garantizar que los
cristales de computadoras distintas oscilen
precisamente con la misma frecuencia.
La diferencia entre los valores del tiempo se llama
distorsin del reloj.
Para sincronizar los relojes lgicos, Lamport defini la relacin 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 relacin transitiva:
Si a > b y b > c, entonces a > c.
Si dos eventos x e y estn 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 estn 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 atrs (decreciente).
El algoritmo de Lamport asigna tiempos a los eventos.
21/09/16

Consideramos tres procesos que se ejecutan en diferentes

mquinas, cada una con su propio reloj y velocidad:
El proceso 0 enva 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, tardara un
tiempo negativo, lo cual es imposible.
El mensaje d de 1 a 0 sale en 64 y llega en 54.
Lamport utiliza la relacin ocurre antes de:
Si c sale en 60 debe llegar en 61 o en un tiempo posterior.
Cada mensaje acarrea el tiempo de envo, 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 ms que el tiempo de
envo.
21/09/16

21/09/16

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 envo y recepcin de un mensaje, C(a) < C(b).

Para todos los eventos a y b, C(a) es distinto de C(b).
21/09/16

Uso de la sincronizacin
Se dispone del hardware y software
necesarios para la sincronizacin de relojes a
gran escala (es decir, en todo Internet). Con
esta nueva tecnologa, es posible mantener
millones de relojes sincronizados con UTC,
con precisin de unos cuantos milisegundos.
Apenas comienzan a aparecer nuevos
algoritmos que utilizan relojes sincronizados.
Resumiremos dos de los ejemplos analizados
por Liskov (1993)
Entrega de mensajes a lo ms uno

Nuestro primer ejemplo se refiere a la forma de reforzar la
entrega de a lo ms un mensaje a un servidor, incluso en
presencia de fallas.
El mtodo tradicional es que cada mensaje tenga un
nmero de mensaje, y que cada servidor guarde los
nmeros de los mensajes que ha visto, de modo que pueda
establecer diferencia entre los mensajes nuevos y las
retrasmisiones.
El problema con el algoritmo es que si un servidor falla y
vuele a arrancar, pierde su tabla con los nmeros de
mensajes.
Consistencia del cach en base en el

reloj
El segundo ejemplo se refiere a la
consistencia del cach en un sistema
distribuido de archivos. Por razones de
desempeo, es deseable que los clientes
puedan ocultar archivos de manera local. Sin
embargo, el ocultamiento introduce una
potencia inconsistente si dos clientes
modifican el mismo archivo al mismo tiempo.
La solucin usual consiste en distinguir entre ocultar

un archivo para su lectura o para su escritura.
La desventaja de este esquema es que si un cliente
tiene un archivo oculto para lectura, antes de que otro
cliente pueda obtener una copia para escritura, el
servidor tiene que solicitar al cliente de lectura que
invalide su copia, incluso si la copia se realiz unas
cuantas horas antes.
Este costo adicional se puede eliminar mediante los
relojes sincronizados.
Manejo de cache
La cach es un rea de memoria utilizada
para agilizar los procesos de lecturaescritura.
El ejemplo ms conocido es la cach de los
servidores Proxy Web, los cuales almacenan
las pginas visitadas por los usuarios. As
cuando un cliente pide una pgina, se revisa
si est en la cache agilizando la navegacin
y reduciendo el ancho de banda.
Exclusin mutua
La exclusin mutua garantiza que slo un
proceso est en una regin crtica.
La exclusin mutua en sistemas distribuidos
basa su funcionamiento en variantes de
sistemas centralizados.
Cuando un proceso distribuido desea entrar a
una regin crtica debe de enviar la solicitud a
todos los dems procesos recibiendo
respuestas de todos.
Si otro proceso hace la solicitud al mismo

tiempo se tomar como criterio de
desempate la marca de tiempo o prioridad.
Existen varias formas de exclusin mutua
Exclusin mutua en anillo: similar al manejo
de redes con topologa fsica y lgica en anillo
(TokenRing, TokenBus) teniendo un mensaje
especial llamada token para poder entrar a la
seccin crtica.
Exclusin mutua en anillo
Exclusin Mutua
Cuando un proceso debe leer o
actualizar ciertas estructuras de datos
compartidas: Primero ingresa a una regin
crtica para lograr la exclusin mutua y
garantizar que ningn otro proceso utilizar las
estructuras de datos al mismo tiempo.
En sistemas monoprocesadores las
regiones crticas se protegen con semforos,
monitores y similares. En sistemas distribuidos
la cuestin es ms compleja.
21/09/16

Un Algoritmo Centralizado
La forma ms directa de lograr la exclusin 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 regin crtica:
Enva un mensaje de solicitud al coordinador:

Indicando la regin crtica.
Solicitando permiso de acceso.
Si ningn otro proceso est en ese momento en esa regin
crtica:
El coordinador enva una respuesta otorgando el permiso.
21/09/16

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 cul ocurri
primero.
Cuando un proceso desea entrar a una regin crtica:
Construye un mensaje con el nombre de la regin crtica,

su nmero de proceso y la hora actual.
Enva el mensaje a todos los dems procesos y de manera
conceptual a l mismo.
Se supone que cada mensaje tiene un reconocimiento.
21/09/16
Si el receptor no est en la regin crtica y no desea entrar a ella,

enva de regreso un mensaje o.k. al emisor.
Si el receptor ya est en la regin crtica no responde y encola la
solicitud.
Si el receptor desea entrar a la regin crtica pero an no lo logr,
compara: La marca de tiempo del mensaje recibido con, La
marca contenida en el mensaje que envi a cada uno.
Comunicacin en grupos (Algoritmos Para

la Sincronizacin de Relojes)
Si una mquina tiene un receptor de UTC, todas las
mquinas deben sincronizarse con ella. Si ninguna mquina tiene
un receptor de UTC:
Cada mquina lleva el registro de su propio tiempo.
Se debe mantener el tiempo de todas las mquinas tan cercano
como sea posible.
Se supone que cada mquina tiene un cronmetro que provoca una
interrupcin h veces por segundo. Cuando el cronmetro se
detiene, el manejador de interrupciones aade 1 a un reloj en
software. El reloj en software mantiene un registro del nmero de
marcas (interrupciones) a partir de cierta fecha acordada antes; al
valor de este reloj se lo llama C.
21/09/16

Algoritmo de Cristian
Es adecuado para sistemas en los que: una mquina tiene un

receptor UTC, por lo que se la llama despachador del tiempo.
El objetivo es sincronizar todas las mquinas con ella. Cada
mquina enva un mensaje al servidor para solicitar el tiempo
actual, peridicamente, en un tiempo no mayor segundos. El
despachador del tiempo responde prontamente con un mensaje
que contiene el tiempo actual CUTC. Cuando el emisor obtiene la
respuesta puede hacer que su tiempo sea CUTC.
Un gran problema es que el tiempo no puede correr hacia atrs:

CUTC no puede ser menor que el tiempo actual C del emisor.
La atencin del requerimiento en el servidor de tiempos requiere

un tiempo del manejador de interrupciones.
Tambin se debe considerar el tiempo de transmisin.
21/09/16

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 peridico de todas las
mquinas para preguntarles el tiempo.
Con las respuestas:
Calcula un tiempo promedio.
Indica a las dems mquinas que avancen su reloj o
disminuyan la velocidad del mismo hasta lograr la
disminucin requerida.
Es adecuado cuando no se dispone de un

receptor UTC.
21/09/16

Algoritmos de eleccin
Una forma ms sencilla de llevar acabo la
sincronizacin es a travs de la eleccin de un
coordinador encargado de centralizar la decisin de
dar acceso a la regin crtica.
Existen varios algoritmos. Entre ellos el del granduln.
Este algoritmo consiste en que un proceso enva la
solicitud si nadie responde se convierte en
coordinador, si varios responden ser coordinador
aquel que tenga mayor prioridad.
Algoritmo del Granduln
Algoritmo de Eleccin en anillo

Los procesos se ordenan en forma jerrquica.
Cuando un proceso detecta un fallo, enva un
mensaje a los dems, cada nodo empieza a
destapar su candidatura, al regresar el token
al nodo origen se determina quien gan y se
distribuye el mensaje
Transacciones Atmicas
Un esquema para garantizar la adecuada
sincronizacin de la informacin en sistemas
centralizados como distribuidos son el uso de
transacciones.
Las transacciones manejan 4 propiedades bsicas:
atmicas, consistentes, aisladas y durables (ACID
por sus siglas en ingls).
Las primitivas de las transacciones son:

BEGIN_TRANSACTION
(inicio
de
transaccin)
END_TRANSACTION (fin de transaccin)
ABORT_TRANSACTION
(deshacer
operacin)
READ (leer datos de un archivo u objeto)
WRITE (escribir datos a un archivo u objeto)
Interbloqueo
Surge cuando un proceso busca el recurso
ocupado por otro proceso y a su vez este
proceso busca otro recurso, formado una
cadenita que al final se cierra, por lo cual
ningn proceso puede avanzar.
Se manejan variantes de algoritmos
centralizados para tratar de detectar,
prevenir y eliminar interbloqueos.
Una forma de evitar interbloqueos es a travs

de la replicacin de recursos. El problema
radica en si los recursos son modificados, la
informacin tiene que ser reintegrada en las
dems rplicas.
Se utilizan varias estrategias para el manejo de los

bloqueos:
1. El algoritmo del avestruz (ignorar el problema).
2. Deteccin (permitir que ocurran los bloqueos,
detectarlos e intentar recuperarse de ellos).
3. Prevencin (lograr estticamente que los bloqueos
sean imposibles sean imposibles desde el punto de
vista estructural).
4. Evitarlos (evitar los bloqueos mediante la
asignacin cuidadosa de los recursos).

Unidad 2 1 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 2 1 PDF

Cargado por

Copyright:

Formatos disponibles

Comunicacin

La diferencia ms importante entre un sistema distribuido y

Los procesos, para comunicarse, deben apegarse a reglas

Unidad 2 Comunicacin en los

PROTOCOLOS CON CAPAS

Para facilitar el trabajo con los distinto niveles y

Capa fsica. Se preocupa por la transmisin de los

Capa de sesin. Proporciona el control del dialogo, con el fin de

Capa de presentacin. Se preocupa por el significado de los bits.

Capa de aplicacin. Es una coleccin de varios protocolos para

MODELO CLIENTE - SERVIDOR

Para evitar un gasto excesivo en los protocolos orientados hacia la

El cliente enva un mensaje de solicitud al servidor para pedir cierto

Comunicacin con cliente servidor

Unidad 2 Comunicacin en los

Un socket es el sistema de comunicacin entre

Unidad 2 Comunicacin en los

La comunicacin entre procesos a travs de sockets

Unidad 2 Comunicacin en los

Primitivas de sockets en el cliente

Diagrama de Sockets Stream

Primitivas de sockets en el servidor

Primitivas de sockets en el servidor

import java.io.*; import java.net.*; class Cliente

En 1984 Birell y Nelson idearon el modelo de RPC a semejanza del

Lo que ellos sugirieron fue permitir que los programas llamaran a

Cuando un proceso de la maquina A llama a un procedimiento de la

La RPC no son mas que operaciones remotas disfrazadas de una interfaz

Estructura de las RPC

La aplicacin cliente llama a

Si las aplicaciones cliente y

Esta subrutina tiene la misma

Unidad 2 Comunicacin en los

Ej.: un grupo de servidores de archivo que cooperan para ofrecer

RPC no puede controlar la comunicacin de un servidor con

Unidad 2 Comunicacin en los

Unidad 2 Comunicacin en los

Unidad 2 Comunicacin en los

Se dice que un sistema falla cuando no cumple su

Unidad 2 Comunicacin en los

Un desperfecto de un sistema ocurre cuando el sistema no

Unidad 2 Comunicacin en los

La idea es proveer de un nico bloque de

Los errores de transmisin se convierten en un

Sincronizacin del Tiempo

Unidad 2 Comunicacin en los

El segundo solar se define como 1 / 86.400 de un da solar.

Unidad 2 Comunicacin en los

El Instituto Nacional del Tiempo Estndar (NIST) de EE. UU. y

Unidad 2 Comunicacin en los

A cada cristal se le asocian dos registros, un

Tan pronto se comienza a trabajar con varias

Unidad 2 Comunicacin en los

Consideramos tres procesos que se ejecutan en diferentes

El proceso 0 enva el mensaje a al proceso 1 cuando el reloj

Unidad 2 Comunicacin en los

Unidad 2 Comunicacin en los

Este algoritmo cumple nuestras necesidades para el tiempo global,

Entre dos eventos cualesquiera, el reloj debe marcar al menos

Con este algoritmo se puede asignar un tiempo a todos los eventos

Si a y b son el envo y recepcin de un mensaje, C(a) < C(b).

Unidad 2 Comunicacin en los

Entrega de mensajes a lo ms uno

import java.io.; import java.net.; class Cliente