Semntica de RPC en Presencia de Fallos El objetivo de RPC es ocultar la comunicacin al hacer que las llamadas a procedimientos remotos se parezcan

a las llamadas locales [25, Tanenbaum]. El problema se presenta cuando aparecen los errores, ya que las diferencias entre las llamadas locales y remotas no son tan fciles de encubrir. Se consideraran las siguientes situaciones: 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 despus de enviar una solicitud
SOM II 1

El Cliente No Puede Localizar al Servidor El servidor podra estar inactivo. El servidor podra estar utilizando una nueva versin de la interfaz y nuevos resguardos, que no seran compatibles con la interfaz y los resguardos del cliente. En el servidor, cada uno de los procedimientos regresa un valor: Generalmente el cdigo -1 indica un fallo. Tambin se suele utilizar una variable global (UNIX) errno a la que se asigna un valor que indica el tipo de error. Un tipo de error sera no se pudo localizar al servidor.

SOM II

Prdida de Mensajes de Solicitud

El ncleo (kernel) debe inicializar un cronmetro al enviar la solicitud; si el tiempo se termina antes de que regrese una respuesta o reconocimiento, el ncleo vuelve a enviar el mensaje. Si el mensaje realmente se perdi, el servidor no podr indicar la diferencia entre la retransmisin y el original y todo funcionar bien. Si el nmero de mensajes perdidos supera cierto lmite, el ncleo puede asumir que el servidor est inactivo y se regresa a la situacin no se pudo localizar al servidor.
SOM II 3

Prdida de Mensajes de Respuesta La prdida de respuestas genera mayores problemas que la prdida de solicitudes. Se utiliza un cronmetro: Si no llega una respuesta en un perodo razonable, se debe volver a enviar la solicitud. El problema es que el ncleo del cliente no est seguro de la razn por la que no hubo respuesta.

SOM II

Ciertas operaciones se pueden repetir con seguridad tantas veces como sea necesario sin que ocurran daos; una solicitud con esta propiedad es idempotente. Otras operaciones no son idempotentes, por ej. la transferencia de dinero: Se emite una solicitud a un servidor bancario para transferir cierta suma de dinero. La solicitud llega y se efecta pero se pierde la respuesta. El cliente considera que la solicitud se perdi y la emite nuevamente. El servidor recibe la nueva solicitud y la ejecuta al no saber que es un reenvo de la anterior.
SOM II 5

Una forma de resolver el problema consiste en lo siguiente: El ncleo del cliente asigna a cada solicitud un nmero secuencial. El ncleo del servidor mantiene un registro del nmero secuencial de recepcin ms reciente de cada uno de los ncleos de clientes que lo utilicen. El ncleo del servidor podr indicar la diferencia entre una solicitud original y una retransmisin y puede rechazar la realizacin de cualquier solicitud por segunda vez. Una proteccin adicional es tener un bit en el encabezado del mensaje para distinguir las solicitudes de las retransmisiones.
SOM II 6