SISTEMAS DISTRIBUIDOS

TEMA 3.1: RPC (Remote Procedure Call)

1. Conceptos básicos
Las Llamadas a Procedimientos Remotos son un mecanismo para invocar procedimientos en
espacios de direcciones diferentes (en la misma o distinta máquina). Fue propuesta en 1984 por
Birrell y Nelson, quien sugirió permitir que los programas llamaran a procedimientos ubicados
en otras máquinas.

Aunque la idea básica parece sencilla, existen varios problemas. Por ejemplo, debido a que el
procedimiento que llama y el procedimiento llamado se ejecutan en espacios de direcciones
diferentes, existen complicaciones con los parámetros y resultados. No obstante, la mayoría de
estos problemas son manejables y la RPC es una técnica que constituye el núcleo de muchos
SSDD.

Las RPCs llegaron a su culminación con DCE (Distributed Computing Envorinment), y actualmente
soportan una variedad de estilos de comunicación diferentes y han evolucionado hacia
orientación a objetos (Invocación de métodos remotos, RMI)

1.1 Aspectos Relacionados con las RPC´s

 Las RPCs ofrecen una interfaz sencilla para construir aplicaciones distribuidas sobre TCP / IP.

 Las RPCs se enmarcan en el nivel de sesión en el modelo OSI y en la capa de aplicación en

el modelo de TCP/IP. Consecuentemente, son independientes del protocolo de transporte y
la fiabilidad depende del protocolo de transporte utilizado (TCP, UPD).

1
 La versión 2 de RPC, descrita en la RFC 1057, fue estandarizada por Sun Microsystems.
-Se ocupa de especificar e interpretar los mensajes.
-No se ocupa de cómo realizar el intercambio de mensajes entre los procesos,
restricciones de la capa de transporte y biding entre un cliente a un servicio.

La sintaxis y el formato de los mensajes se define mediante IDL (Interface Definition Language).

 -Una RPC tiene dos participantes:

-Un cliente (activo) que envía una RPC al servidor.
-Un servidor (pasivo) que calcular un resultado y lo devuelve al cliente. El servidor puede
soportar más de una versión de un programa remoto, que implemente uno o más
procedimientos remotos.

Un procedimiento remoto, sus parámetros y resultados se especifican en un fichero de

especificación del protocolo escrito en el lenguaje de especificación RPC y XDR.

2. Funcionamiento de las RPCs

En primer lugar, el proceso que realiza la llamada empaqueta los argumentos en un mensaje, se
los envía a otro proceso y espera el resultado. Por otro lado, el proceso que ejecuta el
procedimiento extrae los argumentos del mensaje, realiza la llamada de forma local, obtiene el
resultado y se lo envía de vuelta al proceso que realizó la llamada.

2.1 Invocación Local.

En un programa que solo implica a un único proceso, una llamada a un procedimiento del tipo
función(arg1, arg2) implica un salto en el flujo de ejecución al código de dicho procedimiento.

Una técnica para controlar la ejecución de llamas a procedimientos y los retornos de éstos, es
utilizar una pila. En ella se apila la dirección de retorno (siguiente instrucción a ejecutar en el
regreso de la llamada) y el conjunto completo de parámetros que se desean pasar al
procedimiento llamado.

2
 2.2 Invocación Remota
El objetivo de las RPCs es acercar la semántica de las llamadas a procedimientos convencionales
a un entorno distribuido. Es decir, la idea tras la RPC es hacerla parecer como una llamada local,
deseamos que sea transparente -el procedimiento de llamada no debe advertir que el
procedimiento llamado se ejecuta en una máquina diferente-.

Para lograr la transparencia

de las RPCs se usa el
concepto de stub (se traduce
como cabos o suplentes). Los
stub son piezas de código
usados por el cliente y el
servidor como sustitutos de
alguna otra funcionalidad.

Los cabos se generan

automáticamente por el
software de RPC y son
independientes de la
implementación que se haga
del cliente y del servidor, sólo
depende de la interfaz.

- En el cliente, el stub tiene las siguientes funciones:

-Suplanta (es intermediario) el procedimiento a ejecutar.

-Localiza el servidor.

-Empaqueta los parámetros y construye el mensaje.

-Envía el mensaje al servidor.

-Espera la recepción de la respuesta y obtiene el resultado.

-En el servidor, el stub tiene las siguientes funciones:

-Recibe los parámetros desde el cliente y los desempaqueta.

-Localiza el procedimiento local que realiza el trabajo.

-Realiza la llamada local con los parámetros.

-Recoge el resultado, lo empaqueta y lo envía de vuelta al cliente.

3
 3. Semántica de invocación RPC
En llamadas a procedimientos remotos hay operaciones que pueden repetirse sin ningún tipo
de daño (idempotentes). Sin embargo, otras operaciones son no-idempotentes y no pueden
repetirse. Por ejemplo, la transferencia de una cuenta bancaria a otra.

Como consecuencia de ello, la semántica de los sistemas RPC puede clasificarse de varias
manearas:

 maybe. (quizás) El stub cliente envía una petición y se queda a la espera un

determinado tiempo. Si no llega la respuesta dentro del tiempo de espera,
continua su ejecución. El cliente no tiene realimentación en caso de fallo (no
sabe que pasó) . Es decir, el procedimiento remoto puede ejecutarse una vez o
ninguna vez, y el cliente podría recibir una respuesta o ninguna.

Esta semántica es admisible en aplicaciones donde se tolere la pérdida de

peticiones y la recepción de respuestas con retraso.

 at-least-once (al menos una vez). El cliente envía una petición y queda a la
espera un tiempo. Si no llega respuesta o ACK dentro del tiempo de espera,
repite la petición. Por tanto, el procedimiento remoto puede ejecutarse
repetidas veces y el cliente puede recibir varias respuestas.
Solo es aplicable cuando se usan exclusivamente operaciones idempotentes
(repetibles)

 at-most-once (a lo sumo una vez). El cliente envía la petición y queda a la

espera un tiempo. Si no llega la respuesta o el ACK dentro del tiempo de espera,
repite la petición. El servidor filtra las peticiones duplicadas y guarda el historial
con las respuestas enviadas, entonces el procedimiento remoto sólo se ejecuta
una vez o no llega a ejecutarse ninguna. El cliente sólo recibe respuesta o una
indicación de que no se ha ejecutado el procedimiento remoto.

 exactly-one. (exactamente una vez) Cada llamada se lleva a cabo exactamente

una vez (ni más ni menos).

http://www.wikiwand.com/es/Llamada_a_procedimiento_remoto

4
 4. Patrones de llamada RPC

4.1 Request (R)

-En este tipo de RPC, la llamada a
procedimiento no retorna nada. Se
denomina RPC asíncrona porque el
cliente no espera la respuesta del
servidor.

-No hace falta implementar timeouts

o retransmisiones.

-Algunos middlewares de objetos lo llaman “oneway”.

4.2 Request-reply (RR)

-En este tipo de RPC, la respuesta del
servidor actúa también como ACK
para la petición del cliente.

- El cliente mantiene un temporizador

para reenviar la petición si no ha
recibe la respuesta del servidor antes
de que expire el temporizador.

-El único ACK que podría recibir el servidor es una nueva petición del cliente.

4.3 Request-Reply-Ack(RRA)
-El cliente envía un ACK para cada respuesta del servidor, pero solo si se han recibido todas las
respuestas previas.

5
 5. Consideraciones de diseño.

5.1 Lenguaje de Definición de interfaces.

Un Lenguaje de Definición de Interfaz (IDL) permite especificar el formato de los
procedimientos remotos y otras opciones de comunicación. La interfaz es el “contrato”
compartido por el cliente y el programa servidor, y debe especificar:

-Nombre de servicio que utilizan los clientes y servidores.

-Nombres de procedimientos.

-Parámetros de entrada y salida de los procedimientos.

-Tipos de datos de los argumentos.

Los compiladores pueden diseñarse para que los clientes y servidores se escriban en lenguajes
diferentes.

-Tipos de IDL:

-Integrado con un lenguaje de programación (Cedar, Argus)

-Lenguaje de definición de interfaces específico para describir las interfaces entre los
clientes y servidores (RPC de Sun)

5.2 Generador de Stubs

5.3 Tipos de parámetros
-Parámetro de entrada (in). Parámetro que se envía del cliente al servidor.

-Parámetro de salida (out). Parámetro que se envía del servidor al cliente.

-Parámetro de entrada/salida (inout)

5.4 Transferencia de parámetros

Una de las funciones de los cabos (stubs) es empaquetar los parámetros en un mensaje:
serialización. Hay que tener en cuenta algunos problemas con la representación de los datos:

6
 -Servidor y cliente pueden ejecutar en máquinas con arquitecturas diferentes
(ordenamiento de bytes diferente).

-Problemas con los punteros. Una dirección solo tiene sentido dentro de un espacio de
direcciones.

Ejemplos de esquemas de representación de datos:

-XDR (eXternal Data Representation) es un estándar que define la representación de

tipos de datos.

-Representación común de datos de CORBA (CDR).

-Serialización de objetos de Java.

-XML (eXtensible Makup Languaje) es un metalenguaje basado en etiquetas definida por

W3C.

5.5 Protocolo de comunicación

5.6 Enlace entre el cliente y el servidor
La comunicación de bajo nivel entre cliente y servidor por medio de paso de mensajes (por
ejemplo, sockets) requiere enlazar al cliente y el servidor. Esto implica localizar al servidor que
ofrece un determinado servicio. Para hacer esto posible, el servidor debe registrar su dirección
en un servicio de nombres (binder).

El enlazador dinámico (binder) es el servicio que mantiene una tabla de traducciones entre
nombres de servicio y direcciones. Incluye funciones para registrar y eliminar un nombre de
servicio, y para buscar la dirección correspondiente a un nombre de servicio.

7
El enlazador dinámico puede ser localizado por el stub del cliente porque se ejecuta en una
dirección fija de un computador fijo. El sistema operativo se encarga de indicar su dirección
difundiendo un mensaje (broadcast) cuando los procesos comienzan su ejecución.

Tipos de enlace:
-Enlace no persistente: el binding entre el cliente y el servidor se establece en cada RPC.
Este tipo de enlaces es más tolerante a fallos y permite migración de servicios.

-Enlace persistente: El binding se mantiene después de la primera RPC. Es útil en

aplicaciones con muchas RPC repetidas, pero da problemas si los servidores cambian de
lugar.

-Modelos híbridos.

5.7 Fallos relacionados con RPCs

 El cliente no es capaz de localizar al servidor.

¿Posibles causas? El servidor puede estar caído o el cliente puede estar usando una versión
antigua del servidor.

¿Cómo indicar el error al cliente? Se puede devolver un código de error (-1) o elevar una
excepción.

 Pérdidas de mensajes de cliente.

Es la más fácil de tratar. Se activa una alarma (timeout) después de enviar el mensaje y, si
pasado el timeout no se recibe una respuesta se retransmite el mensaje.

 Pérdidas del mensaje de respuesta.

8
Son más difíciles de tratar. Se pueden emplear alarmas y retransmisiones, pero:

- ¿Se perdió la petición?

- ¿Se perdió la respuesta?

- ¿El servidor va lento?

Algunas operaciones pueden repetirse y devolverán el mismo resultado (operaciones

idempotentes). Como decíamos, una transferencia bancaria no es idempotente, una suma de
dos números sí.

La solución con operaciones no idempotentes es descartar peticiones ya ejecutadas. Para ello,

se puede añadir un número de secuencia en el cliente o un campo en el mensaje que indique si
es una petición original o una retransmisión.

 Fallos en los servidores

El cliente no puede distinguir si el servidor ha llegado a ejecutar la operación o no. Hay
diferentes alternativas que hacer en el cliente (semánticas de invocación, punto 3)

 Fallos en los clientes.

Ocurre cuando la computación está activa, pero ningún cliente espera los resultados. Es lo que
se denomina computación huérfana. Esto supone un gasto de ciclos de CPU. Además, si el cliente
rearranca y ejecuta de nuevo a la RPC se pueden crear confusiones.

6. Programación con RPCs

El programador debe proporcionar:

-La definición de la interfaz (IDL), que incluye los nombres de los procedimientos,
parámetros que el cliente pasa al servidor y resultados que devuelve el servidor al cliente.

-El código del cliente.

-El código del servidor.

El compilador de IDL genera el resguardo (stub) del cliente y el resguardo (stub) del servidor.

9
 7. RPCs de Sun Microsystems
-Las RPC de Sun Microsystems fueron una de las primeras implementaciones comerciales de
RPC. La RFC 1831 describe Sun RPC, que se diseñó para la comunicación cliente -servidor en el
sistema de archivos NFS.

-Sun RPC se denomina a menudo ONC-RPC (Open Network Computing).

-Utiliza la semántica de llamada al menos una vez.

-Los diseñadores tienen la opción de utilizar llamadas a procedimientos remotos sobre UDP o
TCP, teniendo en cuenta que cliente y servidor deben de estar de acuerdo sobre el protocolo de
transporte a utilizar.

-El sistema Sun RPC proporciona un lenguaje de interfaz denominado XDR y un compilador de
interfaces llamado rpcgen cuyo uso está orientado al lenguaje de programación C.

7.1 Lenguaje XDR

El lenguaje XDR (eXternal Data Representation), diseñado originalmente para representaciones
externas de datos se extendió a lenguajes de definición de interfaces.

En XDR, una interfaz contiene:

-Un número de programa.

-Un número de versión del programa.

-Un conjunto de procedimientos remotos.

-Los procedimientos solo aceptan un parámetro de entrada (se encapsulan en

una estructura)

-Los parámetros de salida se devuelven mediante un único resultado.

El lenguaje ofrece una notación para definir constantes, definición de tipos, estructuras y
programas.

Ejemplo “Hello World “ con RPC.

10
El compilador de interfaces rpcgen genera el código en lenguaje C para:

-Stub del cliente.

-Stub del servidor y procedimiento principal (main) del servidor.

-Fichero de cabecera (.h) con los tipos de datos de usuario y prototipos de

procedimientos.

Opcionalmente Makefile y esqueletos del servidor.

7.2 Identificación de llamadas RPC.

Un mensaje de llamada de RPC se identifica unívocamente mediante tres campos enteros sin
signo:

(NUM-PROG, NUM-VERSION, NUM-PROCEDURE)

NUM-PROG: es el número de programa remoto. Se define en la RFC 1831.

NUM-VERSION: es el número de versión. La primera implementación de un protocolo debe ser

la 1.

NUM-PROCEDURE: es el número de procedimiento remoto. Se especifican por el programador.

7.3 El servicio portmapper

El enlace (binding) en las RPC de Sun se realiza mediante un proceso denominado portmapper.
En cada nodo se ejecuta un proceso portmapper en un puerto bien conocido (111) y, cada
ejemplar del portmapper almacena el número de programa, número de versión y número de
puerto en uso por cada servicio que se ejecuta localmente.

Cuando arranca un servidor registra en el portmapper su número de programa, número de

versión y número de puerto. Cuando un cliente necesita invocar un procedimiento remoto,
envía una petición al portmapper con el número de programa y número de versión, y el
portmapper le responde con el puerto del servidor.

11
8. Evolución de las RPCs

9. Rendimiento: sockets vs. RPCs

12