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 siguiente |