Los servicios de comunicación entre procesos son la base de los sistemas distribuidos al permitir que dos procesos colaboren para lograr una tarea Hay dos mecanismos básicos de comunicación entre procesos
1- Comunicación entre procesos a nivel del sistema operativo (sin red) Permiten la comunicación entre dos procesos en el mismo ordenador Ejemplos: Colas de mensajes, semáforos, memoria compartida, etc. No vamos a utilizarlos en este curso
2- Comunicación entre procesos a través de una red Permiten la comunicación entre dos procesos que residan en la misma red En este caso, la comunicación se produce a través del intercambio de mensajes entre un emisor y un receptor El intercambio puede ser uno-a-uno (unicast – unidifusión) o uno-a-grupo (multicast – multidifusión)
Comunicación entre procesos
Cuando un ordenador tiene soporte de red, ofrece una API que proporciona los servicios de comunicaciones Estas APIs tratan de proporcionar una interfaz abstracta al programador Toda API debe proporcionar, al menos, cuatro tipos de operaciones al desarrollador ENVIAR: Es una primitiva que invoca el proceso emisor con el propósito de transmitir datos a un proceso receptor. Esta primitiva debe permitir identificar al proceso receptor así como especificar los datos a transmitir RECIBIR: Es una primitiva que invoca el proceso receptor con el objetivo de aceptar datos de un proceso emisor. Debe permitir identificar al proceso receptor así como especificar el área de memoria en la que se almacenará la información recibida Inicio de la conexión: Para mecanismos de comunicación orientados a conexión, deben existir primitas que permitan que la conexión se establezca. Lo habitual es que existan dos de ellas: ESPERAR-CONEXIÓN: Es una primitiva invocada por un proceso que está dispuesto a recibir la conexión de otro proceso de forma pasiva. INICIAR-CONEXIÓN: Esta primitiva es invocada por un proceso que quiere iniciar una conexión de manera activa con otro proceso. Es necesario identificar al proceso remoto DESCONECTAR: En comunicaciones orientadas a conexión, cualquiera de los dos extremos de una conexión establecida pueden liberarla invocando esta primitiva Elementos básicos de una API de IPC para redes
Si observamos detenidamente la API básica que hemos definido vemos que
Para que un mensaje pueda transferirse realmente, necesitamos que Toda llamada ENVIAR en un extremo, debe tener una llamada RECIBIR en el otro
Para que una conexión pueda establecerse realmente, necesitamos que Toda llamada INICIAR-CONEXIÓN debe tener un ESPERAR-CONEXIÓN asociada
¿Cómo logran los procesos ponerse de acuerdo para coordinar sus llamadas? Más aún … ¿Qué tenemos que hacer cuando en el código que desarrollamos para que los programas se coordinen al ejecutarse como procesos? Sincronización de los procesos remotos Proceso E Proceso R ENVIAR RECIBIR? Proceso E Proceso R INICIAR ESPERAR?
Definición de Sincronizar: “Hacer que coincidan en el tiempo dos o más fenómenos”
¿Cómo sincronizamos la ejecución de ENVIAR en un proceso con la ejecución de RECIBIR en el otro?
El mecanismo de sincronización más sencillo es el de utilizar comandos bloqueantes
Un comando bloqueante es aquel que bloquea al proceso que lo invoca hasta que se verifica una cierta condición, momento en el que el proceso para a estar Listo
Para el envío de un mensaje, el primer proceso que alcanza el comando ENVIAR/RECIBIR se bloquea hasta que el otro proceso “lo alcanza”
Para el establecimiento de una conexión, el proceso que invoca ESPERAR se bloquea hasta que otro proceso invoca INICIAR Sincronización de los procesos remotos
Las operaciones de IPC que bloquean al proceso llamante se llaman síncronas Una operación bloqueante solo se desbloquea cuando sucede el evento esperado en el extremo remoto. Es decir, garantizamos que hay una sincronización Existen multitud de APIs de IPC síncronas y es posible programar con ellas Existen también APIs de IPC asíncronas, en las que las llamadas no se bloquean En estos casos, es responsabilidad del programador lograr la sincronización
¿Por qué puede querer alguien llamadas asíncronas? Para evitar bloqueos indefinidos Para mejorar las prestaciones y no desperdiciar ciclos de reloj Ejemplo: programa que recibe de muchas fuentes y almacena paquetes
while(true){ int resultado = recibir(paquete); if(resultado == -1) continue; else almacena(paquete); }
El programador debe saber si trabaja con llamadas síncronas o asíncronas Envío y recepción síncronas
Al desarrollar programas distribuidos, es necesario codificar tanto la parte receptora como la parte emisora ¿qué modelo hay que usar en cada caso? La sincronía/asincronía de las llamadas depende del servicio subyacente Para comprenderlo, necesitamos realizar diagramas de eventos Llamadas síncronas y asíncronas Evento Tiempo Periodo suspendido Proceso E Proceso R Mensaje Obligatorio
El Proceso R (receptor) se bloquea al invocar RECIBIR El Proceso E (emisor) se bloquea al invocar ENVIAR El Proceso R puede continuar ejecutando cuando ha terminado de recibir el mensaje El Proceso E requiere un acuse de recibo (ACK) confirmando una recepción correcta para poder desbloquearse Enviar síncrono y recibir síncrono Proceso E Proceso R ENVIAR RECIBIR Asentimiento El asentimiento forma parte del protocolo que implementa el servicio ICP (es transparente para el programador) El mecanismo enviar-síncrono/recibir-síncrono es aconsejable cuando la lógica de la aplicación de ambos procesos necesita que los datos enviados se reciban antes de continuar con el procesamiento Este mecanismo es utilizado cuando el servicio IPC es de transporte fiable orientado a conexión (p.e. TCP) La realidad puede ser un poco más complicada (bufferes intermedios de recepción, ACKs perdidos, etc)
El Proceso R (receptor) se bloquea al invocar RECIBIR El Proceso E (emisor) no se bloquea al invocar ENVIAR El Proceso E envía el mensaje y continúa sin esperar El Proceso E no requiere un acuse de recibo (ACK) confirmando la recepción Enviar asíncrono y recibir síncrono Proceso E Proceso R ENVIAR RECIBIR Este esquema es apropiado cuando la lógica de la aplicación emisora no depende de la recepción de los datos en el otro extremo Este esquema suele utilizarse cuando el mecanismo IPC subyacente no garantiza que los datos enviados sean, realmente, entregados al receptor (p.e. UDP)
El Proceso R (receptor) no se bloquea al invocar RECIBIR El Proceso E (emisor) se bloquea al invocar ENVIAR El Proceso E envía el mensaje y se bloquea El Proceso E requiere un acuse de recibo (ACK) para desbloquearse Hay 3 escenarios Enviar síncrono y recibir asíncrono Escenario 1 Los datos ya han llegado al Proceso R cuando se invoca RECIBIR En este caso, los datos se entregan al Proceso R inmediatamente Un ACK desbloquea al Proceso E Proceso E Proceso R ENVIAR RECIBIR Asentimiento
Escenario 2 Cuando el Proceso R invoca RECIBIR, los datos no han llegado El Proceso R no recoge ningún dato Para evitar un bloqueo indefinido del Proceso E, es necesario invocar RECIBIR nuevamente Enviar síncrono y recibir asíncrono Cont En este tipo de escenario el receptor se programa como un bucle en el que, cada cierto tiempo, se chequea si hay nuevos datos recibidos A esta técnica se le denomina polling Cuando los datos son finalmente recibidos, el Proceso E puede desbloquearse Proceso E Proceso R ENVIAR RECIBIR Asentimiento RECIBIR RECIBIR
| Página siguiente |