INSTITUTO TECNOLGICO SUPERIOR DE

CINTALAPA

Ing. Informtica

Sistemas operativos II

Catedrtico:
Ing. Reynol farrera roque

Unidad 2: comunicacin & sincronizacin

Integrantes:
Francisco Javier del porte Prez
Suni Alexis Zavala Garca
Isidro medina Tamayo
Williams Garca Nataren
Jordn Emmanuel molina lzaro
Geidy Merari Castellanos Romero
5 semestre

grupo F

22 de septiembre del 2015

2.1 Comunicacin
Comunicacin cliente servidor sokets

Es el modelo que actualmente domina el mbito de comunicacin ya que

descentraliza los procesos y registros.
Es un sistema donde el cliente es una aplicacin en un equipo que solicita un
determinado servicio y existe un software en otro equipo que lo proporciona estos
servicios pueden ser:

Ejecucin de un programa
Acceso a una base
Acceso a dispositivos de hardware

Estos solo requieren de un medio fsico de comunicacin entre las mquinas y

depender de la naturaleza de estas para que se pueda revalidar del sistema.

SOKETS -> Designa un concepto abstracto por lo cual dos programas situada en
dos distintas computadoras pueden intercambiar cualquier tipo de datos,
generalmente de manera fiable y ordenada. Estos sokets proporcionan
comunicacin de dos vas PUNTO A PUNTO.
Para lograr un sokets es necesario que cumplan requisitos.

Que un programa sea capaz de localizar a otro.

Que ambos programas sean capaz de intercambiar informacin por lo cual

es necesario tener tres recursos.

Un protocolo de comunicaciones q permita intercambio de octetos.

Una direccin de protocolo de red
Un nmero de puerto que identifique unos programas de una computadora.

Llamada a Procedimiento Remoto

La Llamada a Procedimiento Remoto (del ingls, Remote Procedure Call, RPC) es
un protocolo de red que permite a un programa de computadora ejecutar cdigo
en otra mquina remota sin tener que preocuparse por las comunicaciones entre
ambas. El protocolo es un gran avance sobre los sockets de Internet usados hasta
el momento. De esta manera el programador no tena que estar pendiente de las
comunicaciones, estando estas encapsuladas dentro de las RPC.
Las RPC son muy utilizadas dentro de la comunicacin cliente-servidor. Siendo el
cliente el que inicia el proceso solicitando al servidor que ejecute cierto
procedimiento o funcin y enviando este de vuelta el resultado de dicha operacin
al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el
RPC de Sun denominado ONC RPC (RFC 1057), el RPC de Open Software
Foundation(OSF) denominado DCE/RPC y el "Modelo de Objetos de
Componentes Distribuidos de Microsoft" (Distributed Component Object
Model, DCOM), aunque ninguno de estos es compatible entre s. La mayora de
ellos utilizan un lenguaje de descripcin de interfaz (Interface description
language o IDL) que define los mtodos exportados por el servidor.
Hoy en da se est utilizando el XML como lenguaje para definir el IDL y
el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios
web. Ejemplos de estos pueden ser SOAP o XML-RPC.

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.
Un grupo es una coleccin de procesos que actan juntos en cierto sistema o
alguna forma determinada por el usuario.

La propiedad fundamental de todos los grupos es que cuando un mensaje se

enva al propio grupo, todos los miembros del grupo lo reciben.
Se trata de una comunicacin uno - muchos (un emisor, muchos receptores), que
se distingue de la comunicacin puntual o punto a punto (un emisor, un receptor).
Los grupos son dinmicos:
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 implantacin de la comunicacin en grupo depende en gran medida del
hardware:

En ciertas redes es posible crear una direccin especial de red a la que pueden
escuchar varias mquinas:
Cuando se enva un mensaje a una de esas direcciones se lo entrega
automticamente a todas las mquinas que escuchan a
esa direccin.

Esta tcnica se denomina multitransmisin.

Cada grupo debe tener una direccin de multitransmisin distinta.

Las redes que no soportan multitransmisin operan con transmisin simple:

Significa que los paquetes que tienen cierta direccin se entregan a todas las
mquinas.
Se puede utilizar para implantar los grupos, pero es menos eficiente que la
multitransmisin.
Cada mquina debe verificar, mediante su software, si el paquete va dirigido a ella:
En caso negativo se descarta, pero para analizarlo se gener una Interrupcin y
se dedic ciclos de cpu.
Otra solucin es implantar la comunicacin en grupo mediante la
transmisin 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 solucin vlida particularmente con grupos pequeos.

El envo de un mensaje de un emisor a un nico receptor se llama unitransmisin.

Sincronizacin Sistemas Distribuidos

La sincronizacin de relojes en un sistema distribuido consiste en garantizar que
los procesos se ejecuten en forma cronolgica y a la misma vez respetar el orden
de los eventos dentro del sistema. Para lograr esto existen
varios mtodos o algoritmos que se programan dentro del sistema operativo, entre
los cuales tenemos:
Este algoritmo est basado en el uso del tiempo coordenado universal (siglas
en ingls, UTC), el cual es recibido por un equipo dentro del sistema distribuido.
Este equipo, denominado receptor de UTC, recibe a su vez solicitudes peridicas
del tiempo del resto de mquinas del sistema a cada uno de los cuales les enva
una respuesta en el menor plazo posible informando el tiempo UTC solicitado, con
lo cual todas las mquinas del sistema actualicen su hora y se mantenga as
sincronizado todo el sistema. El receptor de UTC recibe el tiempo a travs 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 atrs:
El tiempo del receptor UTC no puede ser menor que el tiempo de la mquina que
le solicit el tiempo.
El servidor de UTC debe procesar las solicitudes de tiempo con el concepto de
interrupciones, lo cual incide en el tiempo de atencin.
El intervalo de transmisin de la solicitud y su respuesta debe ser tomado en
cuenta para la sincronizacin. El tiempo de propagacin se suma al tiempo del
servidor para sincronizar al emisor cuando ste recibe la respuesta.

Relojes Fsicos
SINCRONIZACIN DE RELOJES FSICOS
Para conocer en que hora del da ocurren los sucesos en los procesos de nuestro
sistema distribuido Q, es necesario sincronizar los relojes de los procesos Ci con
una fuente de tiempo externa autorizada. Esto es la SINCRONIZACIN
EXTERNA. Y silos relojes estn sincronizados con otro con un grado de precisin
conocido, entonces podemos medir el intervalo entre dos eventos que ocurren en
diferentes computadores llamando a sus relojes locales, incluso aunque ellos no
estn necesariamente sincronizados con una fuente externa de tiempo. Esto es
SINCRONIZACIONINTERNA. Definimos estos dos modos de sincronizacin mas
detalladamente, sobre un intervalo de tiempo real I:

Sincronizacin Externa: para una sincronizacin dada D>0, y para una fuente S de
tiempo UTC, Si (t) Ci (t)<D, para i = 1, 2,...., N y para todos los tiempos
reales ten I. Otra forma de decir esto es que los relojes Ci son precisos con el
lmite D.
Sincronizacin Interna: para una sincronizacin dada D>0, Ci(t) Cj(t) <D, para
i = 1,2,....N y para todos los tiempos reales t en I.
Los relojes que estn sincronizados internamente no estn necesariamente
sincronizados externamente, puesto que pueden desplazarse colectivamente
desde una fuente de tiempo externa incluso aunque estn de acuerdo entre si. Sin
embargo, se deduce de las definiciones que si el sistema Q est sincronizado
externamente con un lmite D entonces el mismo sistema esta sincronizado
internamente con un lmite 2D.

Relojes Lgicos
TIEMPO LGICO Y RELOJES LGICOS
Los relojes lgicos son aquellos por los cuales estn ordenados los sucesos de
Una forma nica. Para poder usaren general el tiempo fsico se debe sincronizar
perfectamente bien los relojes a lo largo de un sistema distribuido para poder as
obtener el orden de cualquier par arbitrario de sucesos que ocurran en el, pero es
poco
probable que esto ocurra por que no se puede sincronizar perfectamente los
relojes a lo
largo de un sistema distribuido.
Se puede utilizar un esquema que similar a la casualidad fsica, que se aplica en
los sistemas distribuidos, para controlar el orden de algunos sucesos que ocurren
en
diversos procesos. La cual esta basada en dos puntos sencillos y obvios.
Cuando se enva un mensaje entre procesos, el suceso de enviar el mensaje
ocurri antes del de recepcin del mismo.
Lamport llamo a la ordenacin obtenida al generalizar estas dos relaciones la
realizacin suceder antes. Tambin se le conoce como la relacin de orden casual
u ordenacin casual del mismo.
La relacin captura un flujo de informacin entre dos eventos.
La informacin puede fluir de formas distintas de la de paso de mensajes.
Por ejemplo: Si Prez presenta un mandato a su proceso para que enve un
mensaje, acto seguido telefonea a Gmez, quien ordena a su proceso que enve
otro mensaje, luego el envo del primer mensaje claramente sucedi antes que el
segundo.
Desafortunadamente, como no se ha enviado mensajes de red entre los procesos

que los
emitieron, no podemos modelar este tipo de relaciones en nuestro sistema.
Otro punto a sealar es que aun producindose la relacin sucedi antes entre
dos sucesos, el primero podra o no haber causado realmente el segundo. Un
proceso
podra recibir un mensaje y consecuentemente enviar otro mensaje, pero no que l
emite
cada cinco minutos en cualquier caso y no tiene ninguna relacin especfica con el
primer mensaje. No se ha supuesto ninguna causalidad real, pero la relacin debe
ordenar estos sucesos.
Lamport invento un mecanismo simple con el cual la relacin sucedi antes
pueda capturarse numricamente, denominado reloj lgico. Un reloj es un
contador
software que se incrementa montonamente, y sus valores no necesitan tener
relacin
alguna con el reloj fsico.
RELOJES LGICOS TOTALMENTE ORDENADOS.
Algunos pares de sucesos distintos, generados por diferentes procesos, tienen
marcas de tiempo de Lamport numricamente idnticas. Sin embargo, podemos
crear un
orden, uno para el que todos los pares de sucesos distintos estn ordenados,
teniendo en
cuenta los identificadores de los procesos en los que ocurren los sucesos.
Lamport la utilizo, para ordenar la entrada de procesos en una seccin.

Usos de la Sincronizacin
Memoria Cach
En los sistemas de archivos convencionales, el fundamento para la memoria
cach es la reduccin de la E/S de disco (lo que aumenta el rendimiento), en un
SAD el objetivo es reducir el trfico en la red. Esquema Bsico, el concepto de
memoria cach es sencillo, si los datos necesarios para satisfacer la solicitud de
acceso no se encuentran en la memoria cache, se trae una copia de servicio al
usuario y los accesos se llevan a cabo con la copia de memoria cach.
La idea es conservar all los bloques de disco de acceso mas reciente, para as
manejar localmente los accesos repetidos a la misma informacin y no aumentar
el trfico de la red. Se utiliza una poltica de reemplazo (por ejemplo, la de
utilizacin menos reciente) para limitar el tamao de la memoria cach. Polticas
de Actualizacin, la poltica empleada para escribir los bloques de datos
modificados en la copia maestra del servidor tiene un efecto decisivo sobre la
confiabilidad y el rendimiento del sistema. La poltica mas sencilla consiste en

escribir los datos directamente en el disco tan pronto se coloquen en una memoria
cach. La ventaja de la escritura directa es su confiabilidad, ya que se pierde poca
informacin si un sistema cliente falla. Sin embargo, esta poltica requiere que
cada acceso de escritura espere hasta que se enve la informacin al servidor, por
lo que representa una escritura de escaso rendimiento. La memoria cach con
escritura directa equivale a usar el servicio remoto para accesos de escritura y
explotar la memoria cache nicamente para accesos de lectura. NFS proporciona
el acceso de escritura directa.
Consistencia, una maquina cliente se enfrenta al problema de decidir si una copia
de datos en memoria cach local es consistente con la copia maestra ( y por tanto,
puede usarse). Si la maquina cliente determina que sus datos en memoria cach
estn desfasados, ya no pueden servir para los accesos y hay que colocar en la
memoria cach una copia actualizada de los datos.
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.
Algoritmo de Cristian
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. r / 2 dEs 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
que
La correccin por el tiempo del servidor y el tiempo de transmisin se hace
midiendo en el emisor: El tiempo inicial (envo) T0. El tiempo final (recepcin)
T1. Ambos tiempos se miden con el mismo reloj. El tiempo de propagacin del
mensaje ser (T1 - T0) / 2. Si el tiempo del servidor para manejar la interrupcin y

procesar el mensaje es I: El tiempo de propagacin ser (T1 - T0 - I) / 2. Para

mejorar la precisin: Se toman varias mediciones. Se descartan los valores
extremos. Se promedia el resto. El tiempo de propagacin se suma al tiempo del
servidor para sincronizar al emisor cuando ste recibe la respuesta.
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.Es adecuado cuando no se
dispone de un receptor UTC.
Al inicio de cada intervalo cada mquina transmite el tiempo actual segn su reloj.
Debido a la diferente velocidad de los relojes las transmisiones no sern
simultneas. Luego de que una mquina transmite su hora, inicializa un
cronmetro local para reunir las dems 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 dems mquinas. Otra variante es descartar los valores extremos antes
de promediar (los m mayores y los m menores). Una mejora al algoritmo
considera la correccin por tiempos de propagacin.
Varias Fuentes Externas de Tiempo
Los sistemas que requieren una sincronizacin muy precisa con UTC se pueden
equipar con varios receptores de UTC. Las distintas fuentes de tiempo generaran
distintos rangos (intervalos de tiempo) donde caern los respectivos UTC, por lo
que es necesaria una sincronizacin. Como la transmisin no es instantnea 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 dems y de
serlo lo descarta por ser un valor extremo. Calcula la interseccin (en el tiempo)
de los dems rangos. La interseccin determina un intervalo cuyo punto medio
ser el UTC y la hora del reloj interno. Se deben compensar los retrasos de
transmisin y las diferencias de velocidades de los relojes. Se debe asegurar que
el tiempo no corra hacia atrs. Se debe resincronizar peridicamente desde las
fuentes externas de UTC.
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.
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:
Si ningn otro proceso est en ese momento en esa regin crtica:
Cuando llega la respuesta el proceso solicitante entra a la regin crtica. Si un
proceso pide permiso para entrar a una regin crtica ya asignada a otro proceso:
El coordinador no otorga el permiso y encola el pedido. Cuando un proceso sale
de la regin crtica enva un mensaje al coordinador para liberar su acceso
exclusivo: El coordinador extrae el primer elemento de la cola de solicitudes
diferidas y enva a ese proceso un mensaje otorgando el permiso, con lo cual el
proceso queda habilitado para acceder a la regin crtica 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 habilitacin 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 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. 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. La menor de las marcas gana. Si el mensaje
recibido es menor el receptor enva un o.k. Si su propio mensaje tiene una marca
menor el receptor no enva nada y encola el pedido. Luego de enviar las
solicitudes un proceso: Espera hasta que alguien ms obtiene el permiso.
Cuando llegan todos los permisos puede entrar a la regin crtica. Cuando un
proceso sale de la regin crtica: Enva mensajes o.k. a todos los procesos en su
cola. Elimina a todos los elementos de la cola. La exclusin mutua queda
garantizada sin bloqueo ni inanicin. El nmero de mensajes necesarios por
entrada es 2(n - 1), siendo n el nmero 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 negacin de acceso: o Se bloquearn
los siguientes intentos de los dems procesos por entrar a todas las regiones
crticas. Se incrementa la probabilidad de fallo en n veces y tambin el trfico 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
comunicacin 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 nmero de procesos. Un importante problema adicional es
que:
Todos los procesos participan en todas las decisiones referentes a las entradas
en las regiones crticas. Se sobrecarga el sistema. Una mejora consiste en
permitir que un proceso entre a una regin crtica con el permiso de una mayora
simple de los dems procesos (en vez de todos): Luego de que un proceso
otorg el permiso a otro para entrar a una regin crtica, no puede otorgar el
mismo permiso a otro proceso hasta que el primero libere su permiso.
Estructuras de Nominacin.
Existen dos conceptos que hay que distinguir en relacin con al correspondencia
de nombres en un SAD. Transparencia de Nominacin, El nombre de archivo no
revela ningn indicio sobre de la ubicacin del almacenamiento fsico del archivo.
Independencia de Ubicacin, No es necesario modificar el nombre de un archivo
cuando cambia su ubicacin en el almacenamiento fsico.
Esquema de Nominacin.
Hay tres enfoques principales para los esquemas de nominacin en un SAD. En el
enfoque mas sencillo, los archivos se nombran con una combinacin del nombre
de su anfitrin y su nombre local, lo que garantiza un nombre nico dentro de todo
el sistema. Por ejemplo, en Ibis, un archivo se identifica de manera nica con el
Nombre Anfitrin Local, donde nombre local es una ruta semejante a las de UNIX.
El segundo enfoque popularizado por el sistema de archivos de red (NFS, Network
File System) de sun, ofrece una forma de unir directorios remotos a directorios
locales, lo que da la apariencia a un rbol de directorios coherentes.
El tercer enfoque es la estructura mas compleja y difcil de mantener en la NFS, ya
que cualquier directorio se puede unir a cualquier rbol de direcciones locales y la
jerarqua resultante puede estar poco estructurada