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  |