Sistemas Distribuidos II

1. Sistemas Distribuidos II Comunicación en los sistemas distribuidos M.C. Nancy Aguas García

2. Introducción • La diferencia más importante entre un sistema distribuido y un sistema de un único procesador es la comunicación entre procesos • 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.

3. Introducción • 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.

4. Introducción • 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.

5. Comunicación en Sistemas Distribuidos Permite la interacción entre aplicaciones y servicios del sistema. Modelos de comunicación entre procesos: • Memoria compartida (Sólo uni/multiprocesador no distribuido). • Paso de mensajes. El nivel de abstracción en la comunicación: • Paso de mensajes puro (Cliente-Servidor). • Llamadas a procedimientos remotos. • Modelos de objetos distribuidos.

6. Factores de Comunicación Los diferentes mecanismos de comunicación se caracterizan por los siguientes factores: • Rendimiento: Latencia, radio de transferencia, ancho de banda, ... • Escalabilidad: Número de elementos activos. • Fiabilidad: Pérdida de mensajes. • Seguridad:Cifrado, certificación, ... • Movilidad: Equipos móviles. • Calidad de Servicio: Reserva y garantía de anchos de banda. • Comunicación en grupo: Multicast.

7. Niveles de Comunicación 1) Paso de mensajes puros. Aplicaciones en red. 2) Funcionalidades de comunicación de bajo nivel. Sistemas Operativos Distribuidos. 3) Llamadas a procedimientos remotos y objetos distribuidos. Aplicaciones y Servicios App./Servicios App./Servicios Interfaz y Lógica de Comunicación RMI/RPC Protocolo y Representación API (sockets) TCP/UDP TCP/UDP ATM/Ethernet

8. Primitivas de Comunicación Cada una de las funciones de comunicación de una tecnología determinada. Las primitivas básicas son: • Envío: send(destino,mensaje). • Recepción: receive(fuente,mensaje). Otras primitivas: • Conexión: connect(destino). • Desconexión: close(). Cada una de las primitivas tiene las siguientes características: • Bloqueantes vs No-bloqueantes. • Síncronas vs Asíncronas. • Fiables vs No-fiables.

9. Bloqueantes vs. No-bloqueantes Las características de bloqueo son: • Primitivas bloqueantes: La operación bloquea al elemento que la solicita hasta que ésta sea completada. • Primitivas no-bloqueantes: La operación no detiene la ejecución del elemento que la solicita. Las llamadas no bloqueantes tienen distinto sentido dependiendo de la primitiva que se trate: • Envío no bloqueante: El emisor almacena el dato en un buffer del núcleo (que se encarga de su transmisión) y reanuda su ejecución. • Recepción no bloqueante: Si hay un dato disponible el receptor lo lee, en otro caso indica que no había mensaje.

10. Síncronas vs. Asíncronas Esta característica afecta no tanto a la primitiva como a la transmisión en sí. • Comunicación síncrona: Envío y recepción se realizan de forma simultanea. • Comunicación asíncrona: El envío no requiere que el receptor este esperando. La comunicación asíncrona usa un buffer de almacenamiento. Implica ciertas condiciones de bloque en envío y recepción.

11. Fiabilidad El envío fiable de datos garantiza que un mensaje enviado ha sido recibido por el receptor. Implica la retransmisión de mensajes de validación (ACKs). La fiabilidad la puede garantizar: • El protocolo de comunicación (TCP si y UDP no). • Los elementos emisor y receptor.

12. Primitivas de Comunicación EMISOR RECEPTOR 8 5 RED 7 6 Núcleo Emisor ACK Núcleo Receptor 1 4 msg 2 3 • Envío no bloqueante: [1:8] El emisor continua al pasar el mensaje al núcleo. • Envío bloqueante: [1:2:7:8] El emisor espera a que el núcleo transmita por red el mensaje. • Envío bloqueante fiable: [1:2:3:6:7:8]: El emisor espera a que el núcleo receptor recoge el mensaje. • Envío bloqueante explícito: [1:2:3:4:5:6:7:8]: Idem al anterior, pero es la aplicación receptora la que confirma la recepción. • Petición-Respuesta: [1:2:3:4:<servicio>:5:6:7:8]: El emisor espera a que el receptor procese la operación para reanudar la ejecución.

13. Direccionamiento Información válida para la identificación de elementos del sistema. Posibles receptores de un mensaje. Mecanismos: • Dirección dependiente de la localización: • Por ejemplo: dirección máquina + dirección puerto local. • No proporciona transparencia. • Dirección independiente de la localización (dir. lógica): • Facilita transparencia. • Necesidad de proceso de localización: • Mediante broadcast. • Uso de un servidor de localización que mantiene relaciones entre direcciones lógicas y físicas. • Uso de cache en clientes para evitar localización.

14. Protocolos con capas • 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.

15. Protocolos con capas • 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?.

16. Protocolos con capas • La ISO (Organización Internacional de Estándares) desarrolló un modelo de referencia que: • 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)

18. Protocolos con capas • 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.

19. Protocolos con capas

20. Protocolos con capas • El “modelo OSI” distingue entre dos tipos generales de protocolos: • Orientados hacia las conexiones: • Antes de intercambiar los datos, el emisor y el receptor: • Establecen en forma explícita una conexión. • Probablemente negocien el protocolo a utilizar. • Al finalizar, deben terminar la conexión. • El teléfono es un sistema de comunicación orientado hacia la conexión. • Sin conexión: • No es necesaria una configuración de antemano. • El emisor transmite el primer mensaje cuando está listo. • El depósito de una carta en un buzón es una comunicación sin conexión.

21. Protocolos con capas • Cada capa proporciona una interfaz con la otra capa por encima de ella; la interfaz consiste de un conjunto de operaciones para definir el servicio que la capa está preparada para ofrecer a sus usuarios. El protocolo de la capa “n” utiliza la información de la capa “n”. • Cada protocolo de capa se puede cambiar independientemente de los demás: • Esto es de fundamental importancia. • Confiere gran flexibilidad. • La colección de protocolos utilizados en un sistema particular se llama una “suite de protocolo” o “pila de protocolo”.

22. Modelo Cliente - Servidor • El “modelo de la OSI” es una solución elegante y realmente aplicable en muchos casos, pero tiene un problema: • La existencia de los encabezados genera un “costo” adicional de transmisión. • Cada envío de un mensaje genera: • Proceso en media docena de capas. • Preparación y agregado de encabezados en el camino hacia “abajo”. • Eliminación y examen de encabezados en el camino hacia “arriba”.

23. Modelo Cliente - Servidor • Con enlaces del orden de decenas (o centenas) de miles de bits / segundo y cpu poderosas: • La carga de procesamiento de los protocolos no es significativa. • El factor limitante es la capacidad de las líneas. • Ej.: redes de área extendida (WAN). • Con enlaces del orden de millones de bits / segundo y computadoras personales: • La carga de procesamiento de los protocolos sí es frecuentemente significativa. • El factor limitante no es la capacidad de las líneas. • Ej.: redes de área local (LAN).

24. Modelo Cliente - Servidor • La mayoría de los sistemas distribuidos basados en LAN no utilizan los protocolos de capas completos, sí utilizan un subconjunto de toda una pila de protocolos. El “modelo OSI” no dice nada acerca de la forma de estructurar al sistema distribuido. • El “modelo cliente - servidor” tiene como idea fundamental la estructuración del S. O. como: • Un grupo de procesos en cooperación, llamados servidores, que ofrecen servicios a los usuarios. • Un grupo de procesos usuarios llamados clientes.

25. Modelo Cliente - Servidor • El “modelo cliente - servidor” se basa en un “protocolo solicitud / respuesta”: • Es sencillo y sin conexión. • No es complejo y orientado a la conexión como OSI o TCP / IP. • El cliente envía un mensaje de solicitud al servidor pidiendo cierto servicio.

26. Modelo Cliente - Servidor • El servidor: • Ejecuta el requerimiento. • Regresa los datos solicitados o un código de error si no pudo ejecutarlo correctamente. • No se tiene que establecer una conexión sino hasta que ésta se utilice. • La pila del protocolo es más corta y por lo tanto más eficiente. • Si todas las máquinas fuesen idénticas solo se necesitarían tres niveles de protocolos

27. Modelo Cliente - Servidor

28. Implantación del Modelo C-S • Las principales opciones de diseño analizadas se resumen en: • Direccionamiento: • Número de máquina. • Direcciones ralas de procesos. • Búsqueda de nombres en ASCII por medio del servidor. • Bloqueo: • Primitivas con bloqueo. • Sin bloqueo, con copia al núcleo. • Sin bloqueo, con interrupciones.

29. Implantación del Modelo C-S • Almacenamiento en buffers: • No usar el almacenamiento en buffers, descartar los mensajes inesperados. • Sin almacenamiento en buffers, mantenimiento temporal de los mensajes inesperados. • Buzones. • Confiabilidad: • No confiable. • Solicitud - reconocimiento - respuesta - reconocimiento. • Solicitud - respuesta - reconocimiento.

30. Implantación del Modelo C-S • En el caso de mensajes compuestos por varios paquetes, el reconocimiento puede ser: • Por paquete individual: • Ante la pérdida de un paquete, solo retransmite ése paquete. • Requiere más paquetes en la red. • Por mensaje completo: • La recuperación es compleja ante la pérdida de un paquete. • Requiere menos paquetes en la red.

31. Implantación del Modelo C-S • Otro aspecto interesante de la implementación es el protocolo subyacente utilizado en la comunicación c-s. Los principales tipos de paquetes son los siguientes: • Req: • Solicitud. • De cliente a servidor. • El cliente desea servicio. • Rep: • Respuesta. • De servidor a cliente. • Respuesta del servidor al cliente.

32. Implantación del Modelo C-S • Ack: • Reconocimiento. • De cualquiera de ellos a algún otro. • El paquete anterior que ha llegado. • Aya: • ¿Estás vivo?. • De cliente a servidor. • Verifica si el servidor se ha descompuesto. • Iaa: • Estoy vivo. • De servidor a cliente. • El servidor no se ha descompuesto.

33. Implantación del Modelo C-S • Ta: • Intenta de nuevo. • De servidor a clientes. • El servidor no tiene espacio. • Au: • Dirección desconocida. • De servidor a cliente. • Ningún proceso utiliza esta dirección.

35. Los modelos de comunicación basados en c-s con paso de mensajes responden al esqueleto: msg CLIENTE SERVIDOR msg Send(msg) Send(msg) Receive(msg) msg Mensaje msg,reply; msg=<dato a trasmitir> send(msg); receive(reply); if(isOK(reply)) <operación correcto> else <error en operación> ... Mensaje op,ack; receive(op); if(validOp(op)) ack=<operación OK> else ack=<operación ERROR> send(ack); ...

36. Paso de Mensajes Cada pareja send-receive transmite un mensaje entre cliente y servidor. Por lo general de forma asíncrona. Habitualmente: • Send no bloqueante. • Receive bloqueante (pude hacerse no bloqueante). Los mensajes intercambiados pueden ser: • Mensajes de texto (por ejemplo: HTTP). • Mensajes con formato (binarios). Las aplicaciones definen el protocolo de comunicación: Petición-respuesta, recepción explícita, sin/con confirmación, ...

37. Mensajes Texto Estructura del Mensaje: • Cadenas de caracteres. • Por ejemplo HTTP: “GET //www.itcancun.edu.mx HTTP/1.1” Envío del Mensaje: send(“GET // www.itcancun.edu.mx HTTP/1.1”); El emisor debe hacer un análisis de la cadena de caracteres transmitida.

38. Mensajes Binarios Estructura del Mensaje: struct mensaje_st { unsigned int msg_tipo; unsigned int msg_seq_id; unsigned char msg_data[1024]; }; Envío del Mensaje: struct mensaje_st confirm; confirm.msg_tipo=MSG_ACK; confirm.msg_seq_id=129; send(confirm);

39. Formatos de Representación Para la transmisión de formatos binarios tanto emisor y receptor deben coincidir en la interpretación de los bytes transmitidos. Problemática: • Tamaño de los datos numéricos. • Ordenación de bytes. • Formatos de texto: ASCII vs EBCDIC. Arquitectura little-endian Arquitectura big-endian 0 0 0 5 0 1 2 3 0 0 0 5 Dato a enviar: 5 Valor: 5x224+0x216+0x28+0 3 2 1 0 0 0 0 5 Dato a recibido: 83.886.080 Valor: 0x224+0x216+0x28+5

40. Berkeley Sockets Aparecieron en 1981 en UNIX BSD 4.2 • Intento de incluir TCP/IP en UNIX. • Diseño independiente del protocolo de comunicación. Un socket es punto final de comunicación (dirección IP y puerto). Abstracción que: • Ofrece interfaz de acceso a los servicios de red en el nivel de transporte. • Representa un extremo de una comunicación bidireccional con una dirección asociada.

41. Berkeley Sockets Sujetos a proceso de estandarización dentro de POSIX (POSIX 1003.1g). Actualmente: • Disponibles en casi todos los sistemas UNIX. • En prácticamente todos los sistemas operativos: • WinSock: API de sockets de Windows. • En Java como clase nativa.

42. Conceptos Básicos en Sockets • Dominios de comunicación. • Tipos de sockets. • Direcciones de sockets. • Creación de un socket. • Asignación de direcciones. • Solicitud de conexión. • Preparar para aceptar conexiones. • Aceptar una conexión. • Transferencia de datos. 1.- Creación del socket 913367377 2.- Asignación de dirección 3.- Aceptación de conexión

43. Dominios de Comunicación • Un dominio representa una familia de protocolos. • Un socket está asociado a un dominio desde su creación. • Sólo se pueden comunicar sockets del mismo dominio. • Los servicios de sockets son independientes del dominio. Algunos ejemplos: • PF_UNIX (o PF_LOCAL): comunicación dentro de una máquina. • PF_INET: comunicación usando protocolos TCP/IP.

44. Tipos de Sockets • Stream (SOCK_STREAM): • Orientado a conexión. • Fiable, se asegura el orden de entrega de mensajes. • No mantiene separación entre mensajes. • Si PF_INET se corresponde con el protocolo TCP. • Datagrama (SOCK_DGRAM): • Sin conexión. • No fiable, no se asegura el orden en la entrega. • Mantiene la separación entre mensajes. • Si PF_INET se corresponde con el protocolo UDP. • Raw (SOCK_RAW): • Permite el acceso a los protocolos internos como IP.

45. Direcciones de Sockets • Cada socket debe tener asignada una dirección única. • Dependientes del dominio. • Las direcciones se usan para: • Asignar una dirección local a un socket (bind). • Especificar una dirección remota (connect o sendto). • Se utiliza la estructura genérica de dirección: • struct sockaddr mi_dir; • Cada dominio usa una estructura específica. • Uso de cast en las llamadas. • Direcciones en PF_INET (struct sockaddr_in). • Direcciones en PF_UNIX (struct sockaddr_un).

46. Direcciones de Sockets en PF_INET Una dirección destino viene determinada por: • Dirección del host: 32 bits. • Puerto de servicio: 16 bits. Estructura struct sockaddr_in: • Debe iniciarse a 0 (bzero). • sin_family: dominio (AF_INET). • sin_port: puerto. • sin_addr: dirección del host. Una transmisión está caracterizada por cinco parámetros únicos: • Dirección host y puerto origen. • Dirección host y puerto destino. • Protocolo de transporte (UDP o TCP).

47. Obtención de la Dirección del Host Usuarios manejan direcciones en forma de texto: • decimal-punto: 138.100.8.100 • dominio-punto: laurel.datsi.fi.upm.es • Conversión a binario desde decimal-punto: int inet_aton(char *str,struct in_addr *dir) • str: contiene la cadena a convertir. • dir: resultado de la conversión en formato de red. • Conversión a binario desde dominio-punto: struct hostent *gethostbyname(char *str) • str: cadena a convertir. • Devuelve la estructura que describe al host.

48. Creación de un Socket La función socket crea uno nuevo: int socket(int dom,int tipo,int proto) • Devuelve un descriptor de archivo (igual que un open de archivo). • Dominio (dom): PF_XXX • Tipo de socket (tipo): SOCK_XXX • Protocolo (proto): Dependiente del dominio y del tipo: • 0 elige el más adecuado. • Especificados en /etc/protocols. El socket creado no tiene dirección asignada.

49. Asignación de Direcciones La asignación de una dirección a un socket ya creado: int bind(int s,struct sockaddr* dir,int tam) • Socket (s): Ya debe estar creado. • Dirección a asignar (dir): Estructura dependiendo del dominio. • Tamaño de la dirección (tam): sizeof(). Si no se asigna dirección (típico en clientes) se le asigna automáticamente (puerto efímero) en la su primera utilización (connect o sendto).

50. Asignación de Direcciones (PF_INET) Direcciones en dominio PF_INET • Puertos en rango 0..65535. • Reservados: 0..1023. • Si se le indica el 0, el sistema elige uno. • Host: una dirección IP de la máquina local. • INADDR_ANY: elige cualquiera de la máquina. Si el puerto solicitado está ya asignado la función bind devuelve un valor negativo. El espacio de puertos para streams (TCP) y datagramas (UDP) es independiente.