sistemas operativos en ambientes distribuidos unidad 2 tema: comunicación en los sistemas...

73
Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Upload: bernardo-palma-quintero

Post on 02-Feb-2016

252 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Sistemas operativos en ambientes distribuidos

Unidad 2

TEMA: Comunicación en los sistemas operativos distribuidos

Ing. Efrain Padilla Valera

Page 2: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Instituto Tecnológico de Tepic

Contenido

Comunicación de procesos a través del pasode mensajes en sistemas distribuidos

Nominación: características y estructuras, tipos de nombres

Sincronización: relojes físicos, relojes lógicos, usos de la sincronización

Comunicación Cliente – Servidor, RPC, Multicast y tolerancia a fallos

Page 3: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Instituto Tecnológico de Tepic

Bibliografía Distributed Systems: Concepts and Design

G. Coulouris, J. Dollimore, T. KindbergAddison-Wesley, 2001

Distributed Operating SystemsA. S. TanenbaumPrentice-Hall, 1995

Distributed Operating Systems: Concepts & PracticeD. L. GalliPrentice-Hall, 2000

Distributed Operating Systems & AlgorithmsR. Chow, T. JohnsonAddison-Wesley, 1997

Traducciones al Español Sistemas Distribuidos: Conceptos y Diseño

G. Coulouris, J. Dollimore, T. KindbergAddison-Wesley, 2001

Sistemas Operativos DistribuidosA. S. TanenbaumPrentice-Hall, 1996

Page 4: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Instituto Tecnológico de Tepic

Introducción

Estudiaremos el nivel inferior de la Lógica de Mediación (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 cómo se comunican es decir, sus patrones de comunicación

2 patrones de comunicación principales: Comunicación cliente-servidor Comunicación en grupo

Hay que diseñar protocolos de alto nivel que soporten dichos patrones

Page 5: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Objetivos Desarrollar bloques constructivos para la IPC:

Cómo meter los datos en los mensajes Cómo pasar los mensajes:

• Qué semántica emplear• Transparencia, sincronismo, fiabilidad

Construir protocolos a la medida de los papeles de los procesos de los patrones de comunicación

Comunicación cliente-servidor Protocolos solicitud-respuesta

• Tener en cuenta los papeles de los procesos• Qué primitivas de comunicación usar

Instituto Tecnológico de Tepic

Page 6: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Objetivos Presentar la interfaz de sockets BSD para:

TCP. Abstracción: cauce bidireccional (stream)• Información encauzada sin fronteras de mensaje• Uso de buffers: amortiguar diferencias de velocidad• En SD: ftp, http, telnet, smtp• Además: entornos productor-consumidor

UDP. Abstracción: paso de mensajes(datagramas)• Envío 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

Instituto Tecnológico de Tepic

Page 7: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Comunicación La diferencia más importante entre un sistema distribuido y un sistema de

un único procesador es la comunicación entre procesos [25, Tanenbaum]. En un sistema de un solo procesador la comunicación supone

implícitamente 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 comunicación 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 diseño al respecto; una importante opción es la “llamada a un procedimiento remoto”.

También es importante considerar las posibilidades de comunicación entre grupos de procesos, no solo entre dos procesos.

Instituto Tecnológico de Tepic

Page 8: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Protocolos basados en niveles Debido a la ausencia de memoria compartida, toda la comunicación 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 envíe a

través de la red hacia “B”. Para evitar el caos, “A” y “B” deben coincidir en el significado de los bits que se

envíen.

Los puntos de acuerdo necesarios incluyen lo siguiente: ¿Cuántos voltios hay que utilizar para un bit “0” y cuántos para un bit “1”?. ¿Cómo sabe el receptor cuál es el último bit del mensaje?. ¿Cómo puede detectar si un mensaje ha sido dañado o perdido, y qué debe

hacer si lo descubre?. ¿Qué longitud tienen los números, cadenas y otros elementos de datos y cuál es

la forma en que están representados?.

Instituto Tecnológico de Tepic

Page 9: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El modelo ISO/OSI La ISO (Organización Internacional de Estándares) desarrolló un

modelo de referencia Identifica en forma clara los distintos niveles. Estandariza los nombres de los niveles. Señala cuál nivel debe realizar cuál trabajo.

Este modelo se denomina “modelo de referencia para interconexión de sistemas abiertos” (ISO OSI o modelo OSI) [26, Tanenbaum].

El “modelo OSI” está diseñado para permitir la comunicación de los sistemas abiertos: Son aquellos preparados para comunicarse con cualquier otro sistema abierto

mediante reglas estándar: • 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 comunicación

Instituto Tecnológico de Tepic

Page 10: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El modelo ISO/OSI y TCP/IP

Instituto Tecnológico de Tepic

Cada nivel incluye su propia cabecera / cola en el mensaje a enviar, con los datos necesarios para implementar su protocolo

Page 11: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Los protocolos de bajo nivel Nivel físico: Este nivel se dedica a transmitir los 0’s y los 1’s.

Cuántos voltios se emplearán para codificar los 0’s y cuántos para los 1’s Cuántos bits/segundo Comunicación simplex/duplex Tamaño, forma y características de los conectores Ejemplo: RS-232

Nivel de enlace: Asegurar transmisión libre de errores. Agrupar bits en grupos de bits (tramas) Aplicar códigos de redundancia a las tramas para detectar errores. En caso de errores, enviar mensajes de control para pedir la

retransmisión.

Nivel de red: Encaminar los mensajes de una máquina a otra. A este nivel a los mensajes se les llama paquetes. Ejemplo: IP, parte de la pila de protocolos de Internet.

Instituto Tecnológico de Tepic

Page 12: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Los protocolos de bajo nivel Ejemplo de protocolo de enlace de datos

Instituto Tecnológico de Tepic

Page 13: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

DATAGRAMA EN CAPA 3

Instituto Tecnológico de Tepic

Page 14: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

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 serán reensamblados en el destino.

Los paquetes que no lleguen a su destino, serán retransmitidos. Ejemplos: TCP, UDP

• TCP, sobre IP: ofrece mensajes fiables con conexión.• UPD, sobre IP: ofrece mensajes no fiables sin conexión. (sin retransmisiones)

¿Cómo funciona TCP para cliente/servidor?

Instituto Tecnológico de Tepic

Page 15: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

a) Mensajes necesarios para hacer una petición cliente/servidor mediante TCP

b) Interacción cliente/servidor mediante TTCP (Transactional TCP)

Instituto Tecnológico de Tepic

Page 16: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

SEGMENTO EN CAPA 4

Instituto Tecnológico de Tepic

Page 17: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Protocolos de alto nivel Por encima del nivel de transporte, OSI define 3 niveles más.

En la práctica, los tres se engloban en uno sólo: el nivel de aplicación. Nivel de sesión: Proporciona control sobre la conversación y

proporciona facilidades de sincronización. Por ejemplo para realizar ‘checkpoints’ y de esta forma tolerar fallos.

Nivel de presentación: Dedicado a tratar el significado de la información que se transmite. Por ejemplo registros en lugar de bits.

Nivel de aplicación: Los protocolos específicos necesarios para dotar de funcionalidad a determinado sistema: FTP, HTTP, MAIL, TELNET, etc.

Instituto Tecnológico de Tepic

Page 18: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Protocolos de middleware Middleware es software que según en modelo OSI reside en el

nivel de aplicación. Sin embargo, contiene muchos protocolos de propósito general, que podrán ser

empleados por aplicaciones. Hay multitud de protocolos que soportan gran variedad de servicios. Por ejemplo:

• Protocolos de autenticación• Protocolos de compromiso atómico• Protocolos de gestión de cerrojos distribuidos• Protocolos para proporcionar mecanismos de comunicación de alto nivel: RPC, RMI, etc.

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

Instituto Tecnológico de Tepic

Page 19: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Las operaciones send y receive El paso de un mensaje se puede soportar con dos

operaciones de comunicación: Send

• un proceso envía un mensaje a un destino

receive• un proceso recibe el mensaje en el destino

Cada destino tiene asociada una cola los emisores añaden mensajes a la cola los receptores los extraen

Instituto Tecnológico de Tepic

Page 20: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Comunicación síncrona y asíncrona. El paso de un mensaje

Implica: comunicación de datos• desde el proceso emisor hacia el receptor

Puede implicar: sincronización de los procesos

Comunicación síncrona: 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

Instituto Tecnológico de Tepic

Page 21: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Comunicación síncrona y asíncrona

Comunicación asíncrona: el send es no bloqueante

• el mensaje se copia a un buffer local y el emisor continúa (aunque aún 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 continúa tras emitir el receive (aunque no haya mensaje)

• Implica notificación (sondeo, interrupción)

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 más eficiente pero es más complejo

(¿interrupciones? no, gracias)• Los servidores pueden esperar indefinidamente, pero en otros casos:

temporización (timeout)

Instituto Tecnológico de Tepic

Page 22: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Los sockets Mecanismo original de IPC en UNIX: pipes

cauce unidireccional (stream) y sin nombre enlazan filtros, sin sincronización explícita

• 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 envío 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 través 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 máquina• una dirección IP de dicha máquina• un protocolo (UDP o TCP)

Sólo el proceso que posee el socket puede recibir mensajes destinados al puerto asociado

• En Java: – clase InetAddress y nombramiento mediante DNS

Instituto Tecnológico de Tepic

Page 23: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La comunicación mediante datagramas UDP

Datagrama: Mensaje autocontenido no fiable desde un emisor a un receptor único, sin

asentimientos ni reenvíos• no hay garantía de la entrega

transmisión 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 operación receive entrega:• el mensaje transmitido

• el puerto al que está enlazado el socket emisor

Se usa comunicación asíncrona 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 temporización⇒

• por defecto, se puede enviar a (y recibir de) cualquier puerto

• es posible limitarlo a uno concreto: conexión

Instituto Tecnológico de Tepic

Page 24: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La comunicación mediante datagramas UDP

Datagrama: Continuación No hay garantía de la recepción

• los mensajes se pueden perder• por errores de checksum o falta de espacio

los procesos deben proveer la calidad que deseen• Añadiendo asentimientos, se puede dar un servicio fiable sobre uno no

fiable

¿Por qué no usar una comunicación perfectamente fiable?• no suele ser imprescindible• causa cargas administrativas grandes:

– almacena información de estado en origen y destino

– transmite mensajes adicionales

– posible latencia para emisor o receptor

Instituto Tecnológico de Tepic

Page 25: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Ejemplo: C y datagramas UDP

Instituto Tecnológico de Tepic

Page 26: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Ejemplo: Java y UDP

Instituto Tecnológico de Tepic

Java proporciona 2 clases: DatagramPacket y DatagramSocketDatagramPacket:– soporte a los datagramas – y el constructor que usan los emisores toma:• un mensaje, su longitud, la dirección IP de la máquina destinataria y el número 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 número de puerto local que se quiere asociar– el constructor que usan los clientes• sin argumentos: elige uno cualquiera que esté libre– métodos adicionales:• send y receive: su argumento es un ejemplar deDatagramPacket

Page 27: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La comunicación mediante cauces (streams) TCP

La abstracción de cauce (stream) oculta: tamaño de los mensajes

• los procesos leen o escriben cuanto quieren

• las capas inferiores (TCP/IP) empaquetan

mensaje perdidos• mediante asentimientos y reenvíos

control de flujo• evita desbordamiento del receptor

mensajes duplicados y/o desordenados• mediante identificadores de mensajes

destinatarios de los mensajes una vez establecida una conexión, los procesos leen

• y escriben del cauce sin necesidad de volver a usar sus respectivas direcciones

Instituto Tecnológico de Tepic

Page 28: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La comunicación mediante cauces (streams) TCP

• Dos papeles diferenciados: cliente, crea un socket encauzado y:

• solicita el establecimiento de una conexión (connect)

servidor, crea un socket de escucha• con una cola de peticiones de conexión

• lo asocia a un número de puerto determinado• espera la llegada de peticiones de conexión

Cuando el servidor acepta una conexión: se crea automáticamente 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

• indicación de cauce roto

Instituto Tecnológico de Tepic

Page 29: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La comunicación mediante cauces (streams) TCP

Bloqueo: lectura: si no hay datos disponibles escritura: si la cola del socket de destino está llena

Opciones para atender a múltiples clientes: escucha selectiva (en UNIX, select) multitarea:

• se crea un nuevo proceso que atiende la conexión 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 conexión rota⇒

Utilización de TCP: HTTP, FTP, Telnet, SMTP.

Instituto Tecnológico de Tepic

Page 30: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La comunicación mediante cauces (streams) TCP

ServerAddress y ClientAddress son direcciones de socket

Instituto Tecnológico de Tepic

Page 31: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La comunicación mediante cauces (streams) TCP

Instituto Tecnológico de Tepic

• ServerSocket:– soporte a los sockets de escucha (servidores)– método accept:• si cola de solicitudes de conexión vacía, se bloquea• si no,– toma una solicitud– crea un ejemplar de la clase Socket– establece la conexión» con sus dos cauces– retorna una referencia al Socket creado

• Java proporciona 2 clases:ServerSocket y Socket• Socket:– soporte a los sockets encauzados– el cliente usa un constructor que:• toma como argumentos el nombre del host y el número de puerto del servidor• crea el socket y• solicita automáticamente la conexión– servidor: resultado del accept– métodos: getInputStream y getOutputStream• retornan valores de tipo InputStream y OutputStream• se pueden usar como argumentos para constructoresde cauces de E/S– ej: DataInputStream y DataOutputStream

Page 32: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La Alineación y la RepresentaciónExterna de Datos

La información almacenada dentro de los programas en ejecución se representa mediante estructuras de datos. La información transportada en los mensajes consiste en secuencias de bytes.

Las estructuras de datos deben ser aplanadas a secuencias de bytes para su transmisión y reconstruidas en recepción.

Diferentes formas de representar tipos primitivos: int, float… Ejemplo: variantes en la ordenación de enteros:

• Big endian: byte más significativo en la posición más baja de memoria• Little endian: byte menos significativo en la posición más baja de memoria

Métodos para que 2 computadoras puedan intercambiar datos: 1. Los valores se convierten a un formato externo acordado antes de la transmisión

y se revierten al formato original en recepción. 2. Los valores se transmiten según el formato del emisor, junto con una indicación

de formato utilizado y el receptor los convierte si es necesario.

Instituto Tecnológico de Tepic

Page 33: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La Alineación y la RepresentaciónExterna de Datos

Representación externa de datos: estándar acordado para la representación de estructuras de datos y valores primitivos: Empaquetado (marshalling): convertir estructuras de datos y datos primitivos en

una representación externa, aplanada, para ser transmitida. Desempaquetado (unmarshalling): reconstruir las estructuras de datos y datos

primitivos a partir de una representación externa.

Ejemplos de representación extena de datos SUN's External data representation (XDR) CORBA's Common Data Representation (CDR) Java's object serialization ASCII (XML, HTTP)

Instituto Tecnológico de Tepic

Page 34: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamada a procedimiento remoto (RPC)

Creado por Birrel & Nelson en 1984 Permiten a los programas llamar procedimientos localizados en

otras máquinas Un proceso x en una máquina A, puede llamar un procedimiento

localizado en una máquina B Información puede llevarse del proceso invocador al invocado

dentro de los parámetros RPC utiliza el modelo de paso de mensajes y el patrón

arquitectónico cliente/servidor para la ejecución de procedimientos que no residen en el mismo proceso

Instituto Tecnológico de Tepic

Page 35: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Ejecución de una llamada de procedimiento local

Instituto Tecnológico de Tepic

Variables locales al main

Variables locales al main

Variables locales al main

bytesbuffd

dirección regreso

SP SP

SP

a) Stack antes llamada read b) Stack durante ejecución read c) Stack después llamada read

main(){ :count = read(fd, bytes, buf) :}

main(){ :count = read(fd, bytes, buf) :}

main(){ :count = read(fd, bytes, buf) :}

Local Procedure Call (LPC): conocido modelo de llamadas a procedimientos locales usado para transferir control y datos

Page 36: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Ejecución de una llamada de procedimiento local

La invocación local a procedimientos consiste en seguir cierta convención (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 máquinas diferentes a la máquina que invoca, tendremos llamada a procedimiento remoto.

Instituto Tecnológico de Tepic

Page 37: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remoto

Instituto Tecnológico de Tepic

Ejecución remota de procedimientosProgramación estructurada

No obstante, las soluciones actuales para objetos distribuidos pueden ser vistas como una extensión de RPC. Ej: CORBA, JavaRMI (Remote Method Invocation), .NET Remoting

Page 38: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remoto Con las llamadas a procedimiento remoto hay que tener en cuenta

que queremos la misma transparencia de ubicación que tiene el programador que utiliza procedimientos convencionales: Queremos ocultar al cliente el hecho de que el procedimiento está ubicado en

otra máquina. Queremos que el programador del cliente, simplemente invoque i=suma(j,k) y

por “arte de magia”, la invocación llegue a la máquina remota Esta “magia” se consigue en RPC mediante los stubs.

Instituto Tecnológico de Tepic

Page 39: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remoto

Instituto Tecnológico de Tepic

Máquina Cliente Máquina Servidor

kernel kernel

stub delcliente

stub delservidor

cliente

call

return

Packparámetros

Unpackresultado

Unpackparámetros

Packresultado

servidor

call

return

Mensaje transportado en la red

Page 40: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remoto

Instituto Tecnológico de Tepic

kernel kernel

Máquina Cliente Máquina Servidor

sum sum

47

47

mensaje mensaje sum(i,j)int i,j;{ return(i+j);}

: :n=sum(4,7); : :

Page 41: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remoto

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.

Nótese que el procedimiento servidor podría invocar otro procedimiento ubicado en una tercera máquina (incluso en la máquina “cliente”): Más que de máquina (proceso) cliente o máquina (proceso) servidora, hay que

hablar de cliente y servidor para un procedimiento en particular, puesto que el rol cliente/servidor debe entenderse por procedimiento

Instituto Tecnológico de Tepic

Page 42: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remotoPaso de Parámetros

El stub cliente debe: Empaquetar los argumentos en un mensaje. Enviar el mensaje de invocación al servidor. Esperar el mensaje de respuesta. Desempaquetar los resultados (argumentos de salida) del mensaje de

respuesta Devolver los resultados al código que invocó al stub.

El stub servidor debe: Esperar mensaje de invocación Desempaquetar los argumentos de la invocación. Realizar la invocación al procedimiento local y esperar a que termine. Empaquetar los argumentos de salida en el mensaje de respuesta. Enviar la respuesta al cliente.

Instituto Tecnológico de Tepic

Page 43: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remotoPaso de Parámetros

Además de los parámetros, 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 máquina tenga más de un procedimiento invocable.

Instituto Tecnológico de Tepic

Page 44: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Llamadas a procedimiento remotoPaso de Parámetros

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 envía 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): ¿Cómo 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.

¿Cómo 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.

Instituto Tecnológico de Tepic

Page 45: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Invocación de métodos locales yremotos

Las invocaciones de métodos entre objetos en diferentes procesos, tanto si es en el mismo computador o no, se conocen como “invocaciones de métodos remotas”.

Las invocaciones entre objetos del mismo proceso son invocaciones de métodos locales

•RMI es una extensión de invocación a métodos locales que hace que un objeto que reside en un proceso pueda invocar métodos de otro objeto que reside en otro proceso distinto

Instituto Tecnológico de Tepic

Page 46: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Objeto remoto y su interfaz remota

Las interfaces especifican los tipos de los argumentos, valores devueltos y excepciones de los métodos de un objeto que pueden invocarse remotamente sin indicar su implementación

Una llamada a un procedimiento remoto (RPC) es a RMI lo que una llamada aprocedimiento es a una invocación al método de un objeto

Instituto Tecnológico de Tepic

Page 47: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Invocación de Métodos Remotos (RMI) Objetos distribuidos

Sistemas OO en general Los objetos encapsulan datos (estado) y operaciones sobre los datos (métodos). La única forma de acceder a los objetos es mediante llamadas a sus métodos. Los objetos pueden tener múltiples facetas, es decir, pueden implementar

múltiples interfaces. Esta distinción entre objeto e interfaces es clave! Una interfaz no es más que la lista de los métodos, detallando sus argumentos,

que satisface cierta clase de objetos.

Objetos distribuidos Para invocar a un objeto remoto con transparencia de ubicación (de forma similar

a RPC):• El cliente del objeto invocará a un stub cliente (llamado proxy)• El proxy enviará la invocación al stub servidor por la red.• El stub servidor, llamado esqueleto, invocará al objeto.

Nótese que tanto el objeto remoto como el proxy implementarán la misma interfaz.

Instituto Tecnológico de Tepic

Page 48: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Invocación de Métodos remotos (RMI) Objetos distribuidos

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

invocación llegará al objeto remoto.

Instituto Tecnológico de Tepic

Page 49: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Invocación de Métodos remotos (RMI) Objetos distribuidos

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 código de las aplicaciones. La misión más importante del ORB es dirigir las invocaciones desde

los proxies a los esqueletos adecuados situados en la máquina adecuada.

Instituto Tecnológico de Tepic

Page 50: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Referencias a objeto Una de las diferencias más 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 invocación 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:

Instituto Tecnológico de Tepic

Como resultado del registro:El ORB crea un esqueleto que permitirá dirigir las invocaciones remotas al objetoEl ORB retorna una referencia al objeto. Lo habitual será que retorne un proxy que contendrá la referencia al objeto (Oref)

Page 51: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Referencias a objeto Contenido de las referencias a objeto:

Dirección física del ORB que contiene el objeto (por ejemplo: IP + puerto) Identificador del objeto dentro de la máquina (una máquina puede tener más de

uno) Interfaz que se registra (un objeto puede tener más de una)

Paso de referencias:

Instituto Tecnológico de Tepic

Page 52: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Referencias a objeto Ejemplo de paso de referencias: supongamos que la máquina A

tiene una referencia a O1 y otra a O2. Supongamos que la máquina B tiene la implementación de O1 y la máquina C, tiene la implementación de O2.

Instituto Tecnológico de Tepic

Page 53: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Referencias a objeto Ejemplo de paso de referencias (cont): Supongamos que la

máquina A invoca al método op1 de O1, pasándole como argumento el objeto O2. Es decir, La máquina A invoca O1.op1(O2)

Como resultado, la máquina B, recibe una referencia al objeto O2Instituto Tecnológico de Tepic

Page 54: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Introducción y Objetivos a Servicios de Nombres

Introducción 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 diseño:• el espacio de nombres• el mecanismo de resolución• los mecanismos de división, replicación y cache de datos

Estudiar un caso:• DNS: Internet Domain Name System

Instituto Tecnológico de Tepic

Page 55: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Generalidades de los servicios de nombres

Base de datos de enlaces: {nombres} « {atributos}

Principal operación: resolución de un nombre Otras operaciones: crear, listar y borrar enlaces

Nombre ≠ clave simple ⇒ múltiples componentes Buscados en contextos: partes separadas de la BD

Instituto Tecnológico de Tepic

Page 56: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Espacios de nombres Espacio de nombres: colección de nombres válidos reconocidos por

un SN Válido se intentará buscarlo⇒

no necesariamente enlazado

Un SN retorna atributos para los nombres válidos enlazados a objetos

Opciones: nombres estructurados: su estructura interna representa su posición en una

jerarquía nombres planos

• Espacios de Nombres jerárquicos:– más 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 nombresInstituto Tecnológico de Tepic

Page 57: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Los nombres en DNS En DNS: nombre = nombre de dominio

estructura de árbol:• ND = 1 o más etiquetas separadas por “.”

dominio = colección de ND

• En la práctica, sólo 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 geográfica: es, us, uk, fr

En algunos países:• división organizativa debajo de la geográfica

La administración 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

Instituto Tecnológico de Tepic

Page 58: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Los nombres en DNS

Instituto Tecnológico de Tepic

Page 59: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

La resolución 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

Navegación: localización de datos a través 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 información se aprende de un archivo de configuración

• la dirección del SN local y/o de la raíz, ...

Instituto Tecnológico de Tepic

Page 60: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Navegación controlada por servidor

El AU contacta con un SN, que coordina la resolución: y le pasa el resultado de vuelta al AU

No recursiva: El SN actúa como el AU de la navegación 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 (más largo) del nombre el proceso sigue (y vuelve) recursivamente

Instituto Tecnológico de Tepic

Page 61: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El mecanismo de cache Es la llave de las prestaciones de los SN Ayuda a mantener la disponibilidad de los servicios ante caídas En la práctica, reduce al mínimo los accesos a los SN de alto nivel Tiene éxito porque los datos cambian infrecuentemente Fácil detectar datos obsoletos al usarlos La cache es la razón para que AU = proceso, y no librería:

compartición de cache ahorro de búsquedas, aunque⇒ impone cargas adicionales a las computadoras clientes

Instituto Tecnológico de Tepic

Page 62: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

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 crecía bien para grandes números 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 Delegación: cada organización (y suborganización) gestiona sus datos Escala mundial millones de objetos⇒ Principales mecanismos usados:

• a) Partición jerárquica de la base de datos de nombramiento• b) Replicación• c) Cache Instituto Tecnológico de Tepic

Page 63: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El Sistema de Nombres de Dominio(DNS )

Especificación de las consultas de DNS En DNS se pueden almacenar atributos arbitrarios Una solicitud se especifica por:

• un ND:(in-addr.arpa = ND especial: números 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 DNS1) Resolución de nombres de computadoras

• En general: resolución = nombre computadora dirección IP⇒• Ejemplo:

– al programa de ftp se le da el ND nic.ddn.mil

– ⇒ftp consulta al DNS:

» ND = nic.ddn.mil + designación de tipo = A

– ⇒ retorno: la dirección 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

Instituto Tecnológico de Tepic

Page 64: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El Sistema de Nombres de Dominio(DNS )

Instituto Tecnológico de Tepic

Page 65: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El Sistema de Nombres de Dominio(DNS )

Localización de servidor de correos resolución = nombre de dominio dirección IP servidor de correo⇒ – Ejemplo:

• mensaje para [email protected]

• ⇒ consulta al DNS:

– ND = det.uvigo.es + designación 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 dirección 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

Instituto Tecnológico de Tepic

Page 66: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El Sistema de Nombres de Dominio(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• periódicamente, el SS contacta con el SP para comprobar si coinciden• si copia secundaria obsoleta:

– el SP envía la más reciente

• frecuencia de comprobación es un parámetro de zona– 1 o 2 veces al día

Instituto Tecnológico de Tepic

Page 67: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

El Sistema de Nombres de Dominio(DNS ) • Todo SN puede conservar en su cache datos de otras zonas

condición: avisar al cliente de que no son datos autoritativos tiempo-de-vida:

• parámetro de zona, asociado a cada entrada• un SN no autoritativo lo anota al obtener datos de uno autoritativo• sólo proporciona un dato de la cache durante ese tiempo• transcurrido: nueva consulta recontactar SN autoritativo⇒• minimiza volumen de tráfico, pero retiene la flexibilidad:

– tiempo-de-vida adaptado a la variabilidad de los atributos

Instituto Tecnológico de Tepic

Page 68: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Los servidores de nombres. Ejemplo

Instituto Tecnológico de Tepic

Page 69: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Navegación. 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 más SN

Utiliza un simple protocolo solicitud-respuesta: UDP sobre Internet (los SN de DNS están en puertos conocidos)

• usa temporizaciones y reenvíos, y una lista de SN iniciales, en orden de preferencia

DNS admite navegación tanto recursiva como iterativa: cuando el resolver contacta con un SN especifica el tipo de navegación pero los SN no están obligados a implementar la recursiva

Instituto Tecnológico de Tepic

Page 70: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

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

Instituto Tecnológico de Tepic

Page 71: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Instituto Tecnológico de Tepic

Page 72: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera

Instituto Tecnológico de Tepic

Page 73: Sistemas operativos en ambientes distribuidos Unidad 2 TEMA: Comunicación en los sistemas operativos distribuidos Ing. Efrain Padilla Valera