Llamada a procedimiento remoto (RPC)
¿cómo especifica el cliente la dirección del servidor?
mediante la conexión dinámica
se emplea una especificación de un servidor: nombre, versión y servicios que proporciona
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);
…
La especificación es usada por los stubs cliente y servidor. Cuando un programa (cliente o servidor) va a hacer uso de alguno de los servicios de esta especificación el correspondiente stub se linka con él
Llamada a procedimiento remoto (RPC)
El servidor envía un mensaje a un programa llamado conector para darle a conocer –exportar- su nombre, versión y dirección (IP, p.ej.)
Cuando el cliente llama a un procedimiento remoto por primera vez, envía un mensaje al conector, solicitando la importación de la versión 3.1 de la interfaz file_server
Si no está el servidor, o no tiene esa versión, la llamada del cliente fracasa
En caso contrario, se envía al cliente la dirección en la que podrá conectar con el servidor
Llamada a procedimiento remoto (RPC)
Fallos que se pueden dar:
El cliente no puede localizar al servidor
Se pierde el mensaje de solicitud del cliente al servidor
Se pierde el mensaje de respuesta del servidor al cliente
El servidor falla antes de recibir una solicitud
El cliente falla después de enviar una solicitud
Comunicación en grupo
La comunicación es entre un grupo de procesos
Cuando un emisor envía, el mensaje lo reciben todos los miembros de un grupo
Los grupos se entienden como dinámicos, se pueden crear y destruir grupos. Un proceso puede ser miembro de varios grupos, se puede unir a uno y dejar otro
Algunas redes permiten diferentes tipos de broadcasting, lo que facilita la implementación de comunicación en grupo
Comunicación en grupo
Los grupos pueden ser:
abiertos: no-miembros pueden enviar al grupo
cerrados: solo los miembros pueden enviar al grupo
Los miembros del grupo pueden ser iguales, o bien existe un miembro coordinador o líder
De existir, los envíos se hacen al coordinador, que decide a qué miembro reenviar
Atomicidad: cuando se envía un mensaje a un grupo, llega a todos los miembros o no llega a ninguno
La atomicidad es una propiedad deseable
Comunicación en grupo
¿cómo asegurar la atomicidad?
La única forma de garantizar que cada miembro reciba el mensaje es pedirle que devuelva un reconocimiento al recibirlo
pero ¿y si aun así falla alguna máquina?
Una solución:
El emisor envía un mensaje a todos los miembros. Se activan cronómetros y se reenvía el mensaje en los casos necesarios
Cuando un miembro recibe el mensaje, si lo ha visto ya lo descarta. Si no, lo envía a todos los miembros del grupo (usando también cronómetros y retransmisiones)
Comunicación en grupo
Otra propiedad deseable es la del ordenamiento de mensajes
Supongamos 5 miembros. Los miembros 0,1,3 y 4 pertenecen a un mismo grupo
A la misma vez, los miembros 0 y 4 desean enviar un mensaje al grupo. Podrían enviarlos en este orden:
0
1
2
3
4
0
1
2
3
4
5
Comunicación en grupo
¿cómo reciben los mensajes los miembros 1 y 3?
El miembro 1 recibe los mensajes en este orden:
mensaje de 0
mensaje de 4
El miembro 3 recibe los mensajes en este orden:
mensaje de 4
mensaje de 0
No se cumple el ordenamiento de mensajes!
Esto puede ser fatal: imaginemos que fueran operaciones sobre un base de datos replicada en los miembros 1 y 3
Comunicación en grupo
Aunque se cumpla el ordenamiento de mensajes hay situaciones problemáticas
Supongamos dos grupos solapados. A y D quieren enviar a la vez un mensaje a sus compañeros de grupo:
A
B
C
D
0
1
2
3
 Página anterior | Volver al principio del trabajo | Página siguiente  |