Unidad 2 Comunicación en Sistemas Operativos Distribuidos

Sistemas operativos en ambientes distribuidos
Unidad 2
TEMA: Comunicacin en los sistemas

operativos distribuidos
Ing. Efrain Padilla Valera
Contenido
Comunicacin de procesos a travs del paso
de mensajes en sistemas distribuidos
Comunicacin Cliente Servidor, RPC,
Multicast y tolerancia a fallos
Nominacin: caractersticas y estructuras,
tipos de nombres
Sincronizacin: relojes fsicos, relojes
lgicos, usos de la sincronizacin
Instituto Tecnolgico de Tepic
Bibliografa
Distributed Systems: Concepts and Design
G. Coulouris, J. Dollimore, T. Kindberg
Addison-Wesley, 2001
Distributed Operating Systems

A. S. Tanenbaum
Prentice-Hall, 1995
Distributed Operating Systems: Concepts & Practice

D. L. Galli
Prentice-Hall, 2000
Distributed Operating Systems & Algorithms
R. Chow, T. Johnson
Traducciones al Espaol
Sistemas Distribuidos: Conceptos y Diseo
G. Coulouris, J. Dollimore, T. Kindberg
Sistemas Operativos Distribuidos

A. S. Tanenbaum
Prentice-Hall, 1996
Introduccin
Estudiaremos el nivel inferior de la Lgica de Mediacin (middleware)
Discutiremos el uso de TCP-UDP/IP desde el punto de vista del programador.

Las entidades que se comunican son procesos
sus papeles determinan cmo se comunican
es decir, sus patrones de comunicacin
2 patrones de comunicacin principales:
Comunicacin cliente-servidor
Comunicacin en grupo
Hay que disear protocolos de alto nivel que soporten dichos patrones
Objetivos
Desarrollar bloques constructivos para la IPC:
Cmo meter los datos en los mensajes
Cmo pasar los mensajes:
Qu semntica emplear
Transparencia, sincronismo, fiabilidad
Construir protocolos a la medida

de los papeles de los procesos
de los patrones de comunicacin
Comunicacin cliente-servidor
Protocolos solicitud-respuesta
Tener en cuenta los papeles de los procesos
Qu primitivas de comunicacin usar
Objetivos
Presentar la interfaz de sockets BSD para:
TCP. Abstraccin: cauce bidireccional (stream)
Informacin encauzada sin fronteras de mensaje

Uso de buffers: amortiguar diferencias de velocidad
En SD: ftp, http, telnet, smtp
Adems: entornos productor-consumidor
UDP. Abstraccin: paso de mensajes(datagramas)

Envo de un mensaje auto contenido desde un emisor hacia un receptor
En SD: DNS, NFS, NTP
En la API Java y en UNIX: destino = socket

referencia indirecta a un puerto concreto del receptor
Comunicacin
La diferencia ms importante entre un sistema distribuido y un sistema de
un nico procesador es la comunicacin entre procesos [25, Tanenbaum].
En un sistema de un solo procesador la comunicacin supone
implcitamente la existencia de la memoria compartida:
Ej.: problema de los productores y los consumidores, donde un proceso escribe en un buffer
compartido y otro proceso lee de l.
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.
Los mensajes se intercambian de diversas formas, existiendo muchas
opciones de diseo al respecto; una importante opcin es la llamada a un
procedimiento remoto.
Tambin es importante considerar las posibilidades de comunicacin entre
grupos de procesos, no solo entre dos procesos.
Protocolos basados en niveles

Debido a la ausencia de memoria compartida, toda la comunicacin en
los sistemas distribuidos se basa en la transferencia de mensajes
Cuando el proceso A quiere comunicarse con el proceso B:
Construye un mensaje en su propio espacio de direcciones.
Ejecuta una llamada al sistema para que el S. O. busque el mensaje y lo enve a
travs de la red hacia B.
Para evitar el caos, A y B deben coincidir en el significado de los bits que se
enven.
Los puntos de acuerdo necesarios incluyen lo siguiente:

Cuntos voltios hay que utilizar para un bit 0 y cuntos para un bit 1?.
Cmo sabe el receptor cul es el ltimo bit del mensaje?.
Cmo puede detectar si un mensaje ha sido daado o perdido, y qu debe
hacer si lo descubre?.
Qu longitud tienen los nmeros, cadenas y otros elementos de datos y cul es
la forma en que estn representados?.
El modelo ISO/OSI
La ISO (Organizacin Internacional de Estndares) desarroll un
modelo de referencia
Identifica en forma clara los distintos niveles.

Estandariza los nombres de los niveles.
Seala cul nivel debe realizar cul trabajo.
Este modelo se denomina modelo de referencia para interconexin

de sistemas abiertos (ISO OSI o modelo OSI) [26, Tanenbaum].
El modelo OSI est diseado para permitir la comunicacin de los
sistemas abiertos:
Son aquellos preparados para comunicarse con cualquier otro sistema abierto
mediante reglas estndar:
Establecen el formato, contenido y significado de los mensajes recibidos y enviados.
Constituyen los protocolos, que son acuerdos en la forma en que debe desarrollarse la
comunicacin
El modelo ISO/OSI y TCP/IP
Cada nivel incluye su propia cabecera / cola en

el mensaje a enviar, con los datos necesarios
para implementar su protocolo
Los protocolos de bajo nivel

Nivel fsico: Este nivel se dedica a transmitir los 0s y los 1s.
Cuntos voltios se emplearn para codificar los 0s y cuntos para los 1s

Cuntos bits/segundo
Comunicacin simplex/duplex
Tamao, forma y caractersticas de los conectores
Ejemplo: RS-232
Nivel de enlace: Asegurar transmisin libre de errores.

Agrupar bits en grupos de bits (tramas)
Aplicar cdigos de redundancia a las tramas para detectar errores.
En caso de errores, enviar mensajes de control para pedir la
retransmisin.
Nivel de red: Encaminar los mensajes de una mquina a otra.

A este nivel a los mensajes se les llama paquetes.
Ejemplo: IP, parte de la pila de protocolos de Internet.
Los protocolos de bajo nivel

Ejemplo de protocolo de enlace de datos
DATAGRAMA EN CAPA 3
Protocolos de transporte
Objetivo: Asegurar la fiabilidad de las comunicaciones
Los mensajes enviados desde las aplicaciones (o desde los niveles superiores
del modelo OSI), son divididos en paquetes, que sern reensamblados en el
destino.
Los paquetes que no lleguen a su destino, sern retransmitidos.
Ejemplos: TCP, UDP
TCP, sobre IP: ofrece mensajes fiables con conexin.

UPD, sobre IP: ofrece mensajes no fiables sin conexin. (sin retransmisiones)
Cmo funciona TCP para cliente/servidor?
a) Mensajes necesarios para hacer una peticin cliente/servidor

mediante TCP
b) Interaccin cliente/servidor mediante TTCP (Transactional TCP)
SEGMENTO EN CAPA 4
Protocolos de alto nivel

Por encima del nivel de transporte, OSI define 3 niveles ms.
En la prctica, los tres se engloban en uno slo: el nivel de
aplicacin.
Nivel de sesin: Proporciona control sobre la conversacin y
proporciona facilidades de sincronizacin. Por ejemplo para realizar
checkpoints y de esta forma tolerar fallos.
Nivel de presentacin: Dedicado a tratar el significado de la
informacin que se transmite. Por ejemplo registros en lugar de bits.
Nivel de aplicacin: Los protocolos especficos necesarios para dotar
de funcionalidad a determinado sistema: FTP, HTTP, MAIL, TELNET,
etc.
Protocolos de middleware
Middleware es software que segn en modelo OSI reside en el
nivel de aplicacin.
Sin embargo, contiene muchos protocolos de propsito general, que podrn ser
empleados por aplicaciones.
Hay multitud de protocolos que soportan gran variedad de servicios. Por ejemplo:
Protocolos de autenticacin
Protocolos de compromiso atmico
Protocolos de gestin de cerrojos distribuidos
Protocolos para proporcionar mecanismos de comunicacin de alto nivel: RPC, RMI, etc.
El modelo ISO/OSI, reescrito contemplando el nivel de middleware.
Las operaciones send y receive

El paso de un mensaje se puede soportar con dos
operaciones de comunicacin:
Send
un proceso enva un mensaje a un destino
receive
un proceso recibe el mensaje en el destino
Cada destino tiene asociada una cola

los emisores aaden mensajes a la cola
los receptores los extraen
Comunicacin sncrona y asncrona.

El paso de un mensaje
Implica: comunicacin de datos
desde el proceso emisor hacia el receptor
Puede implicar: sincronizacin de los procesos
Comunicacin sncrona:
emisor y receptor se sincronizan en cada mensaje
el send y el receive son operaciones bloqueantes
el emisor se bloquea hasta que el receptor hace receive

el receptor se bloquea hasta que llega un mensaje
Comunicacin sncrona y asncrona

Comunicacin asncrona:
el send es no bloqueante
el mensaje se copia a un buffer local y el emisor contina (aunque an no
haya un receive)
el receive puede ser bloqueante o no bloqueante

receive no bloqueante:
el receptor provee un buffer para cuando llegue el mensaje y contina tras
emitir el receive (aunque no haya mensaje)
Implica notificacin (sondeo, interrupcin)
receive bloqueante
En entornos multitarea
pocas desventajas: otras tareas pueden seguir activas
grandes ventajas: tareas receptoras sincronizadas a mensajes
entrantes
el receive no bloqueante parece ms eficiente pero es ms complejo
(interrupciones? no, gracias)
Los servidores pueden esperar indefinidamente, pero en otros casos:
temporizacin (timeout)
Los sockets
Mecanismo original de IPC en UNIX: pipes
cauce unidireccional (stream) y sin nombre
enlazan filtros, sin sincronizacin explcita
pipeline. Ej.: gunzip -c fich.tar.gz | tar xvf

un mismo padre crea los procesos filtro y los pipes
til en entornos productor-consumidor

No es til en SD:
no hay nombre no hay enlace

no hay posibilidad de envo de mensajes discretos
A partir de BSD 4.2, IPC implementada como:

llamadas al sistema: capa por encima de TCP/UDP
socket = destino de mensajes
a travs del que se pueden enviar mensajes, y por medio del cual se pueden recibir mensajes
La IPC tiene lugar entre 2 sockets

Cada socket debe estar asociado a:
un puerto local de su mquina

una direccin IP de dicha mquina
un protocolo (UDP o TCP)
Slo el proceso que posee el socket puede

recibir mensajes destinados al puerto asociado
En Java: clase InetAddress y nombramiento mediante DNS
La comunicacin mediante datagramas UDP

Datagrama:
Mensaje autocontenido no fiable desde un emisor a un receptor nico, sin
asentimientos ni reenvos
no hay garanta de la entrega
transmisin entre 2 procesos

send + receive
cada proceso debe crear un socket
y enlazarlo a un puerto local
los servidores, a un puerto de servicio determinado
los clientes, a cualquier puerto local libre
la operacin receive entrega:

el mensaje transmitido
el puerto al que est enlazado el socket emisor
Se usa comunicacin asncrona con receive bloqueante :

el send retorna tras pasar el mensaje a las capas inferiores (UDP/IP)
stas lo transmiten y lo dejan en la cola del socket asociado al puerto de destino
el receive
(pendiente o futuro) extrae el mensaje de la cola

por defecto, bloqueo indefinido; si se necesita:
multitarea crear procesos y/o hilos
espera acotada temporizacin
por defecto, se puede enviar a (y recibir de) cualquier puerto

es posible limitarlo a uno concreto: conexin
La comunicacin mediante datagramas UDP

Datagrama: Continuacin
No hay garanta de la recepcin
los mensajes se pueden perder
por errores de checksum o falta de espacio
los procesos deben proveer la calidad que deseen

Aadiendo asentimientos, se puede dar un servicio fiable sobre uno no
fiable
Por qu no usar una comunicacin perfectamente fiable?

no suele ser imprescindible
causa cargas administrativas grandes:
almacena informacin de estado en origen y destino
transmite mensajes adicionales
posible latencia para emisor o receptor
Ejemplo: C y datagramas UDP
Ejemplo: Java y UDP
Java proporciona 2 clases: DatagramPacket y DatagramSocket

DatagramPacket:
soporte a los datagramas
y el constructor que usan los emisores toma:
un mensaje, su longitud, la direccin IP de la mquina
destinataria y el nmero de puerto local del socket
destinatario
el constructor que usan los receptores toma:
un array de bytes para un mensaje y su longitud
DatagramSocket:
soporte a los sockets
el constructor que usan los servidores toma:
el nmero de puerto local que se quiere asociar
el constructor que usan los clientes
sin argumentos: elige uno cualquiera que est libre
mtodos adicionales:
send y receive: su argumento es un ejemplar de
DatagramPacket
La comunicacin mediante cauces

(streams) TCP
La abstraccin de cauce (stream) oculta:
tamao de los mensajes
los procesos leen o escriben cuanto quieren
las capas inferiores (TCP/IP) empaquetan
mensaje perdidos
mediante asentimientos y reenvos
control de flujo
evita desbordamiento del receptor
mensajes duplicados y/o desordenados

mediante identificadores de mensajes
destinatarios de los mensajes

una vez establecida una conexin, los procesos leen
y escriben del cauce sin necesidad de volver a usar sus respectivas direcciones

(streams) TCP
Dos papeles diferenciados:
cliente, crea un socket encauzado y:
solicita el establecimiento de una conexin (connect)
servidor, crea un socket de escucha

con una cola de peticiones de conexin
lo asocia a un nmero de puerto determinado
espera la llegada de peticiones de conexin
Cuando el servidor acepta una conexin:

se crea automticamente un nuevo socket encauzado
conectado al del cliente por un par de cauces (streams):
cada proceso lee de su cauce de entrada y

escribe en su cauce de salida
si un proceso cierra su socket
se transmiten a la cola del destino los datos pendientes e
indicacin de cauce roto

(streams) TCP
Bloqueo:
lectura: si no hay datos disponibles
escritura: si la cola del socket de destino est llena
Opciones para atender a mltiples clientes:

escucha selectiva (en UNIX, select)
multitarea:
se crea un nuevo proceso que atiende la conexin establecida

el proceso original sigue atendiendo el socket de escucha
multiproceso (en UNIX, fork)
hilos (threads)
Los procesos deben ocuparse de la concordancia de los datos

Si errores graves de red conexin rota
Utilizacin de TCP:
HTTP, FTP, Telnet, SMTP.

(streams) TCP
ServerAddress y ClientAddress son direcciones de socket

(streams) TCP
Socket:
soporte a los sockets encauzados
el cliente usa un constructor que:
toma como argumentos el nombre del host y el nmero de
puerto del servidor
crea el socket y
solicita automticamente la conexin
servidor: resultado del accept
mtodos: getInputStream y getOutputStream
retornan valores de tipo InputStream y OutputStream
se pueden usar como argumentos para constructores
de cauces de E/S
ej: DataInputStream y DataOutputStream
Java proporciona 2 clases:ServerSocket y Socket

ServerSocket:
soporte a los sockets de escucha (servidores)
mtodo accept:
si cola de solicitudes de conexin vaca, se bloquea
si no,
toma una solicitud
crea un ejemplar de la clase Socket
establece la conexin
con sus dos cauces
retorna una referencia al Socket creado
La Alineacin y la Representacin
Externa de Datos
La informacin almacenada dentro de los programas en ejecucin se
representa mediante estructuras de datos. La informacin transportada
en los mensajes consiste en secuencias de bytes.
Las estructuras de datos deben ser aplanadas a secuencias de bytes
para su transmisin y reconstruidas en recepcin.
Diferentes formas de representar tipos primitivos: int, float
Ejemplo: variantes en la ordenacin de enteros:
Big endian: byte ms significativo en la posicin ms baja de memoria

Little endian: byte menos significativo en la posicin ms baja de memoria
Mtodos para que 2 computadoras puedan intercambiar datos:

1. Los valores se convierten a un formato externo acordado antes de la transmisin y
se revierten al formato original en recepcin.
2. Los valores se transmiten segn el formato del emisor, junto con una indicacin de
formato utilizado y el receptor los convierte si es necesario.
La Alineacin y la Representacin
Externa de Datos
Representacin externa de datos: estndar acordado para la
representacin de estructuras de datos y valores primitivos:
Empaquetado (marshalling): convertir estructuras de datos y datos primitivos en
una representacin externa, aplanada, para ser transmitida.
Desempaquetado (unmarshalling): reconstruir las estructuras de datos y datos
primitivos a partir de una representacin externa.
Ejemplos de representacin extena de datos
SUN's External data representation (XDR)

CORBA's Common Data Representation (CDR)
Java's object serialization
ASCII (XML, HTTP)
Llamada a procedimiento remoto (RPC)

Creado por Birrel & Nelson en 1984
Permiten a los programas llamar procedimientos localizados en
otras mquinas
Un proceso x en una mquina A, puede llamar un procedimiento
localizado en una mquina B
Informacin puede llevarse del proceso invocador al invocado
dentro de los parmetros
RPC utiliza el modelo de paso de mensajes y el patrn
arquitectnico cliente/servidor para la ejecucin de procedimientos
que no residen en el mismo proceso
Ejecucin de una llamada de procedimiento local

Local Procedure Call (LPC): conocido modelo de llamadas a procedimientos locales
usado para transferir control y datos
main()
{
:
count = read(fd, bytes, buf)
:
}
Variables locales
al main
SP
main()
{
main()
{
:
:
}
Variables locales
al main
bytes
buf
fd
direccin regreso
:
:
}
Variables locales
al main
SP
SP
a) Stack antes llamada read b) Stack durante ejecucin read c) Stack despus llamada read
Ejecucin de una llamada de procedimiento local

La invocacin local a procedimientos consiste en seguir cierta
convencin (protocolo) de paso de argumentos y de cambio del
contador de programa.:
Se colocan en la pila los argumentos y el contador de programa

Se salta al procedimiento.
El procedimiento obtiene los argumentos de la pila y se ejecuta.
Los resultados del procedimiento se colocan en la pila.
Al finalizar el procedimiento se retorna al punto de origen, obteniendo el
contador de programa original de la pila.
Todo este trabajo lo hace el compilador de forma transparente al

programador!!
Si colocamos los procedimientos en mquinas diferentes a la
mquina que invoca, tendremos llamada a procedimiento remoto.
Llamadas a procedimiento remoto

Programacin estructurada
Ejecucin remota de procedimientos
No obstante, las soluciones actuales para objetos distribuidos pueden ser vistas
como una extensin de RPC. Ej: CORBA, JavaRMI (Remote Method
Invocation), .NET Remoting

Con las llamadas a procedimiento remoto hay que tener en cuenta
que queremos la misma transparencia de ubicacin que tiene el
programador que utiliza procedimientos convencionales:
Queremos ocultar al cliente el hecho de que el procedimiento est ubicado en otra
mquina.
Queremos que el programador del cliente, simplemente invoque i=suma(j,k) y por
arte de magia, la invocacin llegue a la mquina remota
Esta magia se consigue en RPC mediante los stubs.

Mquina Cliente
Mquina Servidor
stub del
cliente
call
cliente
return
Pack
parmetros
Unpack
resultado
stub del
servidor
Unpack call
parmetros
servidor
Pack
resultado return
kernel
kernel
Mensaje transportado en la red


Mquina Cliente
Mquina Servidor
mensaje
:
sum
:
4
n=sum(4,7);
:
7
:
mensaje sum(i,j)
kernel
kernel
sum
4
7
int i,j;
{
return(i+j);
}

Los stubs los debe generar el compilador.
Tanto el programador del programa cliente, como el programador
del procedimiento remoto ignoran la existencia de los stubs:
transparencia.
Ntese que el procedimiento servidor podra invocar otro
procedimiento ubicado en una tercera mquina (incluso en la
mquina cliente):
Ms que de mquina (proceso) cliente o mquina (proceso) servidora, hay que
hablar de cliente y servidor para un procedimiento en particular, puesto que el rol
cliente/servidor debe entenderse por procedimiento

Paso de Parmetros
El stub cliente debe:
Empaquetar los argumentos en un mensaje.
Enviar el mensaje de invocacin al servidor.
Esperar el mensaje de respuesta.
Desempaquetar los resultados (argumentos de salida) del mensaje de
respuesta
Devolver los resultados al cdigo que invoc al stub.
El stub servidor debe:
Esperar mensaje de invocacin

Desempaquetar los argumentos de la invocacin.
Realizar la invocacin al procedimiento local y esperar a que termine.
Empaquetar los argumentos de salida en el mensaje de respuesta.
Enviar la respuesta al cliente.

Paso de Parmetros
Adems de los parmetros, hay que pasar algo que identifique al
procedimiento que se desea invocar: por ejemplo el nombre del
procedimiento.
Esto es necesario para permitir que una mquina tenga ms de un
procedimiento invocable.

Paso de Parmetros
Al empaquetado de argumentos se le llama marshaling.
Al desempaquetado de argumentos se le llama unmarshaling.
Paso de argumentos por valor (argumentos de entrada): el
programa cliente copia los argumentos al stub, el stub lo enva por la
red, el stub servidor copia los argumentos al procedimiento remoto.
Se procede de igual forma con los argumentos de salida.
Paso de argumentos por referencia (resultados, argumentos de
salida o argumentos de entrada/salida):
Cmo se pasa un puntero? En general no se puede.
Para pasar por referencia, lo habitual suele ser pasar por valor, pero el stub
cliente debe sobrescribir los datos que reciba de la red encima de los
argumentos que recibi del programa cliente.
Cmo se sabe si los argumentos son de entrada, de salida, o de

entrada/salida? depende del lenguaje!
Por este motivo se cre IDL (Interface Definition Language): En l se especifican
argumentos in, out e inout. Con esta interfaz, el compilador crea los stubs
realizado correctamente el paso de argumentos.
Invocacin de mtodos locales y

remotos
Las invocaciones de mtodos entre objetos en diferentes procesos,
tanto si es en el mismo computador o no, se conocen como
invocaciones de mtodos remotas.
Las invocaciones entre objetos del mismo proceso son
invocaciones de mtodos locales
RMI es una extensin de invocacin a mtodos locales que
hace que un objeto que reside en un proceso pueda invocar
mtodos de otro objeto que reside en otro proceso distinto
Objeto remoto y su interfaz remota
Las interfaces especifican los tipos de los argumentos, valores

devueltos y excepciones de los mtodos de un objeto que pueden
invocarse remotamente sin indicar su implementacin
Una llamada a un procedimiento remoto (RPC) es a RMI lo que una
llamada aprocedimiento es a una invocacin al mtodo de un objeto
Invocacin de Mtodos Remotos (RMI)

Objetos distribuidos
Sistemas OO en general
Los objetos encapsulan datos (estado) y operaciones sobre los datos (mtodos).
La nica forma de acceder a los objetos es mediante llamadas a sus mtodos.
Los objetos pueden tener mltiples facetas, es decir, pueden implementar
mltiples interfaces.
Esta distincin entre objeto e interfaces es clave!
Una interfaz no es ms que la lista de los mtodos, detallando sus argumentos,
que satisface cierta clase de objetos.
Para invocar a un objeto remoto con transparencia de ubicacin (de forma similar
a RPC):
El cliente del objeto invocar a un stub cliente (llamado proxy)

El proxy enviar la invocacin al stub servidor por la red.
El stub servidor, llamado esqueleto, invocar al objeto.
Ntese que tanto el objeto remoto como el proxy implementarn la misma interfaz.
Invocacin de Mtodos remotos (RMI)

Objeto distribuido = objeto remoto + proxy + esqueleto
El proxy y el objeto remoto tienen la misma interfaz.
Para invocar un objeto remoto, el cliente invoca al proxy y la
invocacin llegar al objeto remoto.
Invocacin de Mtodos remotos (RMI)

ORB = Object Request Broker: Gestor de invocaciones a objeto.
El ORB es una capa de software que facilita el desarrollo de
aplicaciones distribuidas orientadas a objeto.
Proporciona servicios utilizados por los proxies, los esqueletos y por
el cdigo de las aplicaciones.
La misin ms importante del ORB es dirigir las invocaciones desde
los proxies a los esqueletos adecuados situados en la mquina
adecuada.
Referencias a objeto
Una de las diferencias ms importantes entre los sistemas RPC y los
sistemas OO distribuidos consiste en la posibilidad de los sistemas OO de
pasar objetos como argumento en las invocaciones.
Por valor: se copia todo el objeto y el objeto remoto que recibe la invocacin recibe una
copia del objeto.
Por referencia: el objeto remoto recibe una referencia al objeto.
En los sistemas de objetos distribuidos, es clave el paso de objetos por

referencia
Un proceso tiene que informar al ORB que dispone de un objeto invocable.
Para ello registra el objeto:
Como resultado del registro:

El ORB crea un esqueleto que permitir dirigir las invocaciones remotas al objeto
El ORB retorna una referencia al objeto. Lo habitual ser que retorne un proxy que
contendr la referencia al objeto (Oref)
Contenido de las referencias a objeto:
Direccin fsica del ORB que contiene el objeto (por ejemplo: IP + puerto)
Identificador del objeto dentro de la mquina (una mquina puede tener ms de
uno)
Interfaz que se registra (un objeto puede tener ms de una)
Paso de referencias:
Ejemplo de paso de referencias: supongamos que la mquina A
tiene una referencia a O1 y otra a O2. Supongamos que la mquina
B tiene la implementacin de O1 y la mquina C, tiene la
implementacin de O2.
Ejemplo de paso de referencias (cont): Supongamos que la mquina
A invoca al mtodo op1 de O1, pasndole como argumento el objeto
O2. Es decir, La mquina A invoca O1.op1(O2)
Como resultado, la mquina B, recibe una referencia al objeto O2

Introduccin y
Objetivos a Servicios de Nombres
Introduccin
Necesidad de nombres para:
referirse a recursos: usuarios, servicios, puertos, ordenadores, etc.

seleccionar un recurso determinado dentro de un conjunto
comunicar y compartir recursos en un sistema distribuido
comunicar usuarios en un SD
Objetivos
Conocer el Servicio de Nombres:
lo usan los procesos clientes para obtener losatributos de los recursos a
partir de sus nombres
Analizar las cuestiones de diseo:

el espacio de nombres
el mecanismo de resolucin
los mecanismos de divisin, replicacin y cache de datos
Estudiar un caso:
DNS: Internet Domain Name System
Generalidades de los servicios de

nombres
Base de datos de enlaces:
{nombres} {atributos}
Principal operacin: resolucin de un nombre

Otras operaciones: crear, listar y borrar enlaces
Nombre clave simple

mltiples componentes
Buscados en contextos: partes separadas de la BD
Espacios de nombres
Espacio de nombres: coleccin de nombres vlidos reconocidos por
un SN
Vlido se intentar buscarlo
no necesariamente enlazado
Un SN retorna atributos para los nombres vlidos enlazados a objetos

Opciones:
nombres estructurados: su estructura interna representa su posicin en una
jerarqua
nombres planos
Espacios de Nombres jerrquicos:

ms manejables que los EN planos
no hay necesidad de una autoridad central
mantienen (sin conflictos) atributos de objetos relacionados
cada parte de un nombre se resuelve de forma relativa a un contexto
los diferentes contextos se pueden gestionar de forma separada
Se pueden usar alias para facilitar el empleo de los nombres
Los nombres en DNS

En DNS: nombre = nombre de dominio
estructura de rbol:
ND = 1 o ms etiquetas separadas por .
dominio = coleccin de ND
En la prctica, slo una de uso generalizado: nombramiento en

Internet
Espacio de nombres DNS de Internet est dividido de forma:
organizativa: com, edu, gov, mil, net, org, int (USA)
y geogrfica: es, us, uk, fr
En algunos pases:
divisin organizativa debajo de la geogrfica
La administracin de los dominios se puede delegar en los sub-dominios

el nombre del sub-dominio se debe acordar con los gestores del dominio superior
Los servidores de DNS no reconocen nombres relativos
Los nombres en DNS
La resolucin de los nombres

Resolver = buscar un nombre para obtener sus atributos asociados
Es un proceso iterativo:
comenzando por un contexto inicial,
el nombre se presenta repetidamente ante sucesivos contextos de nombramiento
que establecen la correspondencia entre un nombre dado y:
un conjunto de atributos primitivos, u
otro contexto de nombramiento y un nombre derivado
Navegacin: localizacin de datos a travs de varios SN

La iterativa suele realizar un agente de usuario:
un AU en cada computadora, trabajando para los clientes de ese
computadora
comprueba la validez del nombre y va contactando a los SN determinada
informacin se aprende de un archivo de configuracin
la direccin del SN local y/o de la raz, ...
Navegacin controlada por

servidor
El AU contacta con un SN, que coordina la resolucin:
y le pasa el resultado de vuelta al AU
No recursiva:
El SN acta como el AU de la navegacin iterativa
Recursiva:
a) El SN contacta con otro SN

b) este 2 SN intenta resolver el nombre, y, si no lo tiene:
c) contacta con otro SN que almacene un prefijo (ms largo) del nombre
el proceso sigue (y vuelve) recursivamente
El mecanismo de cache
Es la llave de las prestaciones de los SN

Ayuda a mantener la disponibilidad de los servicios ante cadas
En la prctica, reduce al mnimo los accesos a los SN de alto nivel
Tiene xito porque los datos cambian infrecuentemente
Fcil detectar datos obsoletos al usarlos
La cache es la razn para que AU = proceso, y no librera:
comparticin de cache ahorro de bsquedas, aunque
impone cargas adicionales a las computadoras clientes
El Sistema de Nombres de Dominio

(DNS )
Origen del DNS
Su principal base de datos de nombramiento se usa en Internet
Esquema previo a DNS:
Archivo maestro central con nombres y direcciones de las computadoras
transferido por FTP a las computadoras que lo necesitaban
Problemas:
no creca bien para grandes nmeros de computadoras
las organizaciones locales desean administrar sus sistemas de nombres
se necesita un servicio general de nombres
Generalidades del DNS

Principales objetos nombrados:
computadoras: atributos = direcciones IP

dominios
Se puede nombrar cualquier tipo de objeto

Arquitectura libre: gran variedad de implementaciones posibles
Delegacin: cada organizacin (y suborganizacin) gestiona sus datos
Escala mundial millones de objetos
Principales mecanismos usados:
a) Particin jerrquica de la base de datos de nombramiento

b) Replicacin
c) Cache

(DNS )
Especificacin de las consultas de DNS
En DNS se pueden almacenar atributos arbitrarios
Una solicitud se especifica por:
un ND:(in-addr.arpa = ND especial: nmeros IP de redes)
una clase:
para distinguir la base de datos de Internet de otras
un tipo:
hay un {tipos} particular para cada base de datos
Principales consultas de DNS

1) Resolucin de nombres de computadoras
En general: resolucin = nombre computadora direccin IP
Ejemplo:
al programa de ftp se le da el ND nic.ddn.mil
ftp consulta al DNS:
ND = nic.ddn.mil + designacin de tipo = A
retorno: la direccin IP de esa computadora
el daemon de ftp de esa computadora debe correr en un n de puerto conocido
el programa de ftp puede construir el identificador completo del destino

(DNS )

(DNS )
Localizacin de servidor de correos
resolucin = nombre de dominio direccin IP servidor de correo
Ejemplo:
mensaje para usuario@det.uvigo.es
consulta al DNS:
ND = det.uvigo.es + designacin de tipo = MX
retorno:
lista de computadoras que aceptan correo para det.uvigo.es
Concepto de zona
Los datos de nombramiento se dividen en zonas
Cada zona contiene:
los atributos para los ND de un dominio, menos:
los sub-dominios administrados por autoridades de menor nivel
ND y direccin de SN que proveen datos autoritativos para la zona:
versiones que se puede confiar en que son razonablemente actuales
ND de SN que mantienen datos autoritativos para subdominios delegados
y las direcciones de esos SN
(DNS )
Hay 2 tipos de SN que proveen datos autoritativos de cada zona:
a) SN primario: lee directamente el archivo maestro de la zona
b) SN secundario: carga los datos desde un SN primario
esto se llama transferencia de zona
peridicamente, el SS contacta con el SP para comprobar si coinciden
si copia secundaria obsoleta:
el SP enva la ms reciente
frecuencia de comprobacin es un parmetro de zona

1 o 2 veces al da
El Sistema de Nombres de
Dominio
Todo SN puede conservar en su cache datos de otras zonas
(DNS
)
condicin: avisar al cliente de que no son datos autoritativos
tiempo-de-vida:
parmetro de zona, asociado a cada entrada

un SN no autoritativo lo anota al obtener datos de uno autoritativo
slo proporciona un dato de la cache durante ese tiempo
transcurrido: nueva consulta recontactar SN autoritativo
minimiza volumen de trfico, pero retiene la flexibilidad:
tiempo-de-vida adaptado a la variabilidad de los atributos
Los servidores de nombres. Ejemplo
Navegacin. Procesado de consultas

En DNS: AU = resolver
acepta consultas,
las formatea en los mensajes esperados en el protocolo DNS, y se comunica
con 1 o ms SN
Utiliza un simple protocolo solicitud-respuesta:

UDP sobre Internet (los SN de DNS estn en puertos conocidos)
usa temporizaciones y reenvos, y una lista de SN iniciales, en orden de preferencia
DNS admite navegacin tanto recursiva como iterativa:

cuando el resolver contacta con un SN especifica el tipo de navegacin
pero los SN no estn obligados a implementar la recursiva
Los registros de recursos

Los datos de zona se almacenan en registros de recursos
Cada registro:
se refiere a un Nombre de Dominio
es de un tipo, a elegir entre varios tipos diferentes
para la base de datos de nombramiento de Internet:

A, NS, CNAME, SOA, WKS, PTR, HINFO, MX, TXT

Unidad 2 Comunicación en Sistemas Operativos Distribuidos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Unidad 2 Comunicación en Sistemas Operativos Distribuidos

Enviado por

Direitos autorais:

Formatos disponíveis

Sistemas operativos en ambientes distribuidos

TEMA: Comunicacin en los sistemas

Instituto Tecnolgico de Tepic

Distributed Operating Systems

Distributed Operating Systems: Concepts & Practice

Sistemas Operativos Distribuidos

Instituto Tecnolgico de Tepic

Discutiremos el uso de TCP-UDP/IP desde el punto de vista del programador.

Instituto Tecnolgico de Tepic

Construir protocolos a la medida

Instituto Tecnolgico de Tepic

Informacin encauzada sin fronteras de mensaje

UDP. Abstraccin: paso de mensajes(datagramas)

En la API Java y en UNIX: destino = socket

Instituto Tecnolgico de Tepic

En un sistema distribuido no existe la memoria compartida y por ello toda

Protocolos basados en niveles

Los puntos de acuerdo necesarios incluyen lo siguiente:

Instituto Tecnolgico de Tepic

Identifica en forma clara los distintos niveles.

Este modelo se denomina modelo de referencia para interconexin

Instituto Tecnolgico de Tepic

El modelo ISO/OSI y TCP/IP

Cada nivel incluye su propia cabecera / cola en

Los protocolos de bajo nivel

Cuntos voltios se emplearn para codificar los 0s y cuntos para los 1s

Nivel de enlace: Asegurar transmisin libre de errores.

Nivel de red: Encaminar los mensajes de una mquina a otra.

Instituto Tecnolgico de Tepic

Los protocolos de bajo nivel

Instituto Tecnolgico de Tepic

Instituto Tecnolgico de Tepic

TCP, sobre IP: ofrece mensajes fiables con conexin.

Cmo funciona TCP para cliente/servidor?

Instituto Tecnolgico de Tepic

a) Mensajes necesarios para hacer una peticin cliente/servidor

Instituto Tecnolgico de Tepic

Instituto Tecnolgico de Tepic

Protocolos de alto nivel

Instituto Tecnolgico de Tepic

El modelo ISO/OSI, reescrito contemplando el nivel de middleware.

Instituto Tecnolgico de Tepic

Las operaciones send y receive

Cada destino tiene asociada una cola

Instituto Tecnolgico de Tepic

Comunicacin sncrona y asncrona.

desde el proceso emisor hacia el receptor

Puede implicar: sincronizacin de los procesos

el emisor se bloquea hasta que el receptor hace receive

Instituto Tecnolgico de Tepic

Comunicacin sncrona y asncrona

el receive puede ser bloqueante o no bloqueante

pipeline. Ej.: gunzip -c fich.tar.gz | tar xvf

til en entornos productor-consumidor

no hay nombre no hay enlace

A partir de BSD 4.2, IPC implementada como:

La IPC tiene lugar entre 2 sockets

un puerto local de su mquina

Slo el proceso que posee el socket puede

En Java: clase InetAddress y nombramiento mediante DNS

Instituto Tecnolgico de Tepic

La comunicacin mediante datagramas UDP

transmisin entre 2 procesos

la operacin receive entrega: