Comunicación en Sistemas Distribuidos

Sistemas de Operación II
Comunicación en Sistemas
Distribuidos
Prof. Carlos Figueira
Basado en material de
Yudith Cardinale (USB)
Andrew Tanembaum y Marteen van Steen
Contenido
●
Protocolos de Comunicación
●
Propiedades Fundamentales de los Protocolos
●
Tipos de Protocolos de Transporte
●
Construcción de Bloques para la Comunicación
●
Modelo Cliente-Servidor (Operaciones
Remotas)
●
RPC (Remote Procedure Call)
●
Comunicación en grupo
Carlos Figueira/USB
2
Protocolos de Comunicación
●
Comunicación en Sistemas Distribuidos: pase
de mensajes
●
●
memoria distribuida, múltiples elementos que
pueden fallar independientemente
Funciones de mecanismos de comunicación:
●
Permitir com. entre procesos en máquinas diferentes
●
Protección contra fallas
●
Soporte para estructurar modularmente aplic. distr.
●
Esconde distinción entre comunicación remota y
local, permite reconfiguración estática y dinámica
Carlos Figueira/USB
3
Protocolos de comunicación
●
Especificación de mecanismos de
comunicación. Ejemplos
●
●
●
Modelo OSI de ISO. Marco para definir estándares
de comunicación de computadores heterogéneos.
Modelo ATM (Asynchronous Transfer Mode)
Especifica la forma como debe desarrollarse la
comunicación (formato, contenido y significado
de los mensajes intercambiados)
Carlos Figueira/USB
4
Protocolos en capas (OSI)
Carlos Figueira/USB
5
Protocolos por capas
●
Aplicación (ftp, correo-e, ssh)
●
Presentación (tipología del mensaje)
●
Sesión (facilidades de sincronización)
●
Transporte (TCP, UDP)
●
Red (X.25, IP, ATM)
●
Enlace de datos (control de errores, IEEE 802)
●
Físico (RS-232, 802.3)
Carlos Figueira/USB
6
Componentes de mensaje
Carlos Figueira/USB
7
Propiedades fundamentales de los
protocolos
●
●
●
Las redes pueden fallar, los mensajes se
pierden
Si un mensaje se pierde, se puede corregir
retransmitiéndolo (necesita temporizadores,
confirmación del receptor)
Si todos los mensajes se pierden ...
Carlos Figueira/USB
8
Protocolos: fallas del servidor
●
●
●
Si el cliente no recibe respuesta, reenvía
solicitud
El servidor puede recordar por donde iba
●
Si no recuerda, puede realizarlo dos veces!
●
¿Qué debemos hacer, solicitar otra vez o no?
Tipos de protocolo:
●
Entregan mensaje “al menos una vez”
●
Entregan mensaje “a lo sumo una vez”
Carlos Figueira/USB
9
Protocolos “al menos una vez”
●
●
●
Si no hay falla, entregan mensaje una sola vez
Ante fallas, pueden entregar un mensaje más
de una vez (por retransmisión)
Se usan cuando la operación es idem-potente
(realizarla una vez o varias da el mismo
resultado)
●
Esconden fallas de comunicación y servidores
●
Ejemplo: NFS
Carlos Figueira/USB
10
Protocolos “a lo sumo una vez”
●
●
●
●
●
Detectan si la red o el servidor fallan y lo reportan.
Operan en un contexto de sesión – una asociación
entre dos procesos durante la cual ambos mantienen
el estado del protocolo.
Cuando se pierde el estado del protocolo, se termina la
sesión.
No se reciben mensajes en una sesión diferente a la
sesión en la que se envió.
Las sesiones tienen identificadores únicos: etiqueta de
tiempo (timestamps), número aleatorio (nonce)
Carlos Figueira/USB
11
Tipos de protocolos de transporte
●
●
Un único protocolo de comunicación no es
suficiente para la diversidad de aplicaciones.
Cuatro clases:
●
●
●
●
Operaciones remotas (cliente-servidor, o solicitudrespuesta). Ej: RPC, RMI
Protocolos de transferencia de datos en masa. Ej:
protocolos de transferencia de archivos
Comunicación uno a muchos: difusión (broadcast),
comunicación multi-puntos (multicast)
Comunicación de medios continuos (streaming)
Carlos Figueira/USB
12
Heterogeneidad
●
●
●
●
Los protocolos deben tomar en cuenta que las
máquinas pueden tener diferentes arquitecturas
Se requiere traducir estructuras de datos de una
máquina a representaciones independientes de
la máquina (universales)
El emisor traduce a representación universal; el
receptor traduce de ésta a su esquema propio.
Si máquinas son iguales, puede omitirse.
Puede negociarse antes de transmitir, o enviar
datos junto con id. de arquitectura
Carlos Figueira/USB
13
Operaciones remotas
●
●
Forma más básica y utilizada en sistemas
distribuidos. Se hace una solicitud (desde el
cliente) y se recibe la respuesta (desde el
servidor)
Ejemplos:
●
RPC: llamada a procedimientos remotos
●
RMI: Invocación de métodos remotos
Carlos Figueira/USB
14
Diseño primitivas de comunicación
●
●
●
Bloqueantes (síncronas) vs. no bloqueantes
(asíncronas)
Bloqueante: el proceso emisor se bloquea
hasta que el receptor ejecuta primitiva de
recepción. Idem para el receptor
No bloqueante: el emisor continúa una vez que
el núcleo copia mensaje a su espacio.
Carlos Figueira/USB
15
Diseño primitivas de comunicación
●
●
Bloqueante:
●
Ventajas: programación más sencilla
●
Desventajas: bloqueo, no aprovecha paralelismo
No bloqueante:
●
●
●
Ventajas: paralelismo ejecución/transmisión
Desventajas: programador debe verificar si mensaje
ha llegado (receptor) o ha sido enviado por núcleo
(emisor)
Primitivas: wait, test, conditional-receive (espera un
tiempo o falla), interrupción
Carlos Figueira/USB
16
Diseño primitivas de comunicación
●
●
¿Cómo resolver el problema de la pérdida de
mensajes?. ¿Qué garantía tiene un proceso de
que el mensaje fue entregado?
Primitivas confiables vs. no confiables. Cuatro
enfoques:
●
●
Send no confiable. Es responsabilidad del usuario
ACK (confirmaciones) a nivel de núcleo entre emisor
y receptor
●
Un ACK sólo
●
Temporizadores: para retransmitir, para enviar ACK
Carlos Figueira/USB
17
Llamada a procedimiento remoto
●
●
Consiste en protocolo de comunicación (usa
protocolo de
transporte y rutinas para
ensamblar datos a transferir) que permite que
los programas llamen a procedimientos en
otras máquinas, de manera transparente
Requiere rutinas de emulación (Stubs) en
cliente
y
el
servidor,
procesos
de
empaquetamiento
(marshall)
y
desempaquetamiento
(unmarshall)
de
parámetros y resultado
Carlos Figueira/USB
18
Ej. count = read (fd, buf, nbytes)
Carlos Figueira/USB
19
Extremos (stubs) cliente/servidor
Carlos Figueira/USB
20
Secuencia RPC
●
●
●
●
●
El procedimiento en el cliente llama al extremo
cliente de la manera usual
El extremo cliente construye un mensaje y
llama al SO local
El SO del cliente envía mensaje al SO remoto
El SO remoto entrega mensaje al extremo
servidor
El extremo servidor desempaca parámetros y
llama al servidor
Carlos Figueira/USB
21
Secuencia RPC
●
●
(cont.) El servidor realiza la operación y retorna
resultado al extremo servidor
El extremo servidor lo empaca en un mensaje y
llama al SO local
●
El SO del servidor envía mensaje al SO del cliente
●
SO de cliente entrega mensaje a extremo cliente
●
El extremo cliente desempaca el resultado y
retorna al procedimiento cliente
Carlos Figueira/USB
22
Heterogeneidad: big vs. little endian
Carlos Figueira/USB
23
Pase de parámetros RPC
●
●
●
●
Por valor, no hay problema
Por referencia: prohibirlas o copiar-enviarrestituir (se sustituye copia local por copia
recibida desde servidor)
Apuntadores a estructuras complejas: pasar
estructura completa, o pasar datos a medida
que servidor requiera
Tipos definidos por el usuario: descomponer en
tipos básicos
Carlos Figueira/USB
24
Soporte de RPC
●
●
●
Procesamiento de interfaz: integrar
mecanismos RPC en lenguaje convencional
Manejo de comunicaciones
Asociación (binding): localizar servidor
apropiado para un servicio
Carlos Figueira/USB
25
Procesamiento de interfaz
●
Existen lenguajes especializados para interfaces: IDL
(Interface Definition Languages). Ej: SUN RPC, DCE
Ejemplo de una especificación para un servidor de archivos:
# include <header.h>
●
specification of file_server, version 3.1:
long read(in char name[MAX_PATH], out char
buf[BUF_SIZE], in long bytes, in long position);
Carlos Figueira/USB
26
Compilador de IDL
●
●
●
●
Genera un procedimiento extremo cliente para
cada procedimiento especificado en interfaz
Genera procedimiento extremo servidor
Genera operaciones de empaquetamiento y
desempaquetamiento en cada extremo
Provee esqueleto de servicio, el cuerpo es
desarrollado por programador
Carlos Figueira/USB
27
Carlos Figueira/USB
28
Asociación en RPC
●
●
●
●
Especifica cómo se establece relación entre
procedimiento remoto y el que lo llama
Se forma cuando dos aplicaciones han hecho
conexión lógica y están preparadas para
intercambiar comandos y datos
El servidor se registra con el conector con su
interfaz (nombre, parámetros, versión, etc.)
El conector está en un puerto conocido
Carlos Figueira/USB
29
RPC: Semántica ante fallas
CLIENTE
call read
SERVIDOR
B
STUB
Call
STUB
A
read
C
E
return
return
D
return
kernel
kernel
RED
Carlos Figueira/USB
30
RPC: Semántica ante fallas
●
●
Cliente no puede localizar servidor (reporta
falla)
Mensaje solicitud se pierde: Expira
temporizador antes que llegue respuesta o
ACK
●
●
Núcleo retransmite hasta que haya confirmación (al
menos una vez)
Núcleo reporta falla (a lo sumo una vez)
Carlos Figueira/USB
31
RPC: Semántica ante fallas
●
Se pierde respuesta:
●
●
●
Expira temporizador y no se recibe ACK (en
servidor). Se retransmite ACK
¿Se perdió el mensaje o es lento el servidor? Si la
operación no es idem-potente, puede traer
problema (ej. Transacción bancaria)
Solución: enumerar mensajes
Carlos Figueira/USB
32
RPC: Semántica ante fallas
●
Se cae el servidor (en B, C o D)
●
●
●
●
El cliente no recibe respuesta, retransmite solicitud
En casos 1 (B) y 3 (D, se reenvía respuesta) no hay
problema
En caso 2 (C), puede haber problemas si servidor
no puede recuperar (rollback)
Se cae el cliente: se pierden las respuestas, se
deben manejar los cálculos huérfanos
Carlos Figueira/USB
33
Interfaces de Comunicación: socket
●
Librería de sockets
Carlos Figueira/USB
34
Interfaces de Comunicación: socket
Carlos Figueira/USB
35
Interfaces de Comunicación: MPI
Carlos Figueira/USB
36
Comunicación en grupo
●
●
Un mensaje puede ser enviado a múltiples
receptores en una sola operación
Grupo: colección de procesos que actúan
juntos en algún sistema o forma especificada
por usario
●
●
Son dinámicos
R
Implementación depende del
hardware
R
S
R
Carlos Figueira/USB
R
R
37
Comunicación en grupo
●
Se requieren mecanismos par administrar grupos
y miembros de grupos
●
●
●
Se utilizan direcciones especiales para Difusión y
Multipunto
Alternativa: transmitir mensajes por separado
Es útil para construir sistemas
●
Tolerantes a fallas en servidores replicados
●
Localizar objetos en servicios distribuidos
●
Mejor desempeño a través de datos replicados
●
Actualización múltiple
Carlos Figueira/USB
38
Comunicación en grupo: aspectos
de diseño
●
Grupos cerrados vs Grupos abiertos
●
Grupos jerárquicos vs Grupos de amigos
●
Miembros del grupo
●
Direccionamiento de grupos
●
Primitivas send y receive
●
Atomicidad
●
Ordenamiento de mensajes
●
Solapamiento de grupos
Carlos Figueira/USB
39