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 ●

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