Llamadas a Procedimientos Remotos- RPC
Se analizan tres aspectos que son importante para comprender este concepto:
- el estilo de programación promovido por RPC - programación con interfaces;
- la semántica de llamadas asociada con RPC;
- la transparencia y su relación con las llamadas a procedimientos remotos.
Programación con Interfaces
La interfaz de un módulo especifica los procedimientos y las variables a las que se pueden acceder a través de otros módulos. En sistemas distribuidos las interfaces son programas distribuidos donde los módulos se ejecutan en procesos separados. En el modelo clienteservidor, en particular, cada servidor proporciona un conjunto de procedimientos que están disponibles para uso de los clientes, [1] [2].
- No hay detalle de implementación lenguaje de programación. Hay una evolución del software
- No hay acceso a variables mediante ejecución de procesos remotos ni mecanismos pase de parámetros (llamada por valor o referencia)
- Direcciones en procesos locales no son válidas en los procesos remotos
- Mecanismo RPC se integra con el lenguaje de programación e incluye la notación para la definición de interfaces con mensajes input/output
- Escrita en variedades de lenguajes, C++, Java, Python
- Lenguajes de definición de interfaces (IDL) están diseñados para permitir que los procedimientos implementados en distintos lenguajes puedan ser invocados por otros
Semántica de llamadas de RPC
La operación doOperation se puede implementar de diferentes maneras para proporcionar diferentes garantías de entrega en el mensaje (Figura 1). Las principales opciones son:
- Reintentar mensaje de solicitud: controlar si se retransmite el mensaje de solicitud hasta se recibe una respuesta o supone que el servidor ha fallado.
- Filtrado duplicado: controlar cuándo se usan las retransmisiones y si se debe filtrar solicitudes duplicadas en el servidor.
- Retransmisión de resultados: controlar si se debe mantener un historial de mensajes de resultados para permitir que los resultados perdidos se retransmitan sin volver a ejecutar las operaciones en el servidor.
 |
| Figura 1. Semántica de llamadas RPC. Adaptado de [2] |
Por ejemplo, con una semántica Puede-ser, el invocador de la llamada recibe un resultado, en cuyo caso el invocador de la llamada sabe que el procedimiento se ejecutó al menos una vez, o una excepción que le informa que no se recibió ningún resultado. La semántica Al-menos-una-vez, puede ser lograda mediante la retransmisión de mensajes de solicitud, que enmascara las fallas de omisión del mensaje de solicitud o resultado. La semántica puede sufrir lo siguiente tipos de falla:
- fallas de bloqueo cuando falla el servidor que contiene el procedimiento remoto;
- fallas arbitrarias: en los casos en que el mensaje de solicitud se retransmite, el servidor puede recibirlo y ejecutar el procedimiento más de una vez, posiblemente causando valores incorrectos para ser almacenados o devueltos.
Con una semántica como-máximo-una-vez, la persona que llama recibe un resultado, en cuyo caso la persona que llama sabe que el procedimiento se ejecutó exactamente una vez, o una excepción que le informa que no se recibió ningún resultado, entonces el procedimiento ha sido ejecutados ya sea una vez o no lo ha sido.
Transparencia
La elección de si el RPC debe ser transparente también está disponible para los diseñadores de IDL (Interface Definition Language). Por ejemplo, en algunos IDL, una invocación remota puede generar una excepción cuando el cliente no puede comunicarse con un procedimiento remoto. Esto requiere que el programa cliente maneje tales excepciones, permitiéndole lidiar con tales fallas. Un IDL también puede proporcionar una facilidad para especificar la semántica de llamada de un procedimiento. Esto puede ayudar al diseñador del servicio; por ejemplo, si se elige la semántica de llamada al menos una vez para evitar los gastos generales de una vez como máximo, las operaciones deben diseñarse para que sean idempotentes.
Implementación de RPC
La llamada a procedimiento remoto (RPC) es una técnica orientada a la construcción de aplicaciones distribuidas basadas en cliente-servidor. Se basa en la extensión de la llamada de procedimiento local de manera que el procedimiento llamado no necesita existir en el mismo espacio de direcciones que el procedimiento de llamada. Los dos procesos pueden estar en el mismo sistema, o pueden estar en diferentes sistemas con una red que los conecta.
En la Figura 3 se muestra lo que ocurre cuando se hace una llamada a un proceso remoto:
 | ||
| Figure 3: Llamada a Procedimiento Remoto. |
- El entorno de llamada se suspende, los parámetros del procedimiento se transfieren a través de la red al entorno donde se ejecutará el procedimiento.
- Cuando finaliza el procedimiento y produce sus resultados, estos se transfieren de vuelta al entorno de llamada, donde se reanuda la ejecución como si regresara de una llamada de procedimiento regular.
Arquitectura RPC
En la Figura 4 se muestra un esquema de los componentes de la arquitectura de RPC. El cliente que accede a un servicio incluye un procedimiento stub para cada procedimiento definido en la interfaz de servicio. El procedimiento stub se comporta como un procedimiento local para el cliente, pero en lugar de ejecutar la llamada, ordena (empaqueta) el identificador del procedimiento y los argumentos en un mensaje de solicitud, que envía a través de su módulo de comunicación al servidor.
 | |||
|
Cuando llega el mensaje de respuesta, el módulo de comunicación desarma (desempaqueta) los resultados. El proceso del servidor contiene un despachador junto con un procedimiento de código auxiliar del servidor y un procedimiento de servicio para cada procedimiento en la interfaz de servicio. El despachador selecciona uno de los procedimientos stub del servidor, según el identificador de procedimiento en el mensaje de solicitud.
El procedimiento de stub del servidor luego desarma (desempaqueta) los argumentos en el mensaje de solicitud, llama al procedimiento del servicio correspondiente y calcula los valores de retorno para el mensaje de respuesta.
Los procedimientos de servicio implementan los procedimientos en la interfaz de servicio. Los procedimientos de stub de cliente y servidor y el despachador puede ser generado automáticamente por un compilador de interfaz a partir de la definición de interfaz del servicio.
RPC puede implementarse para tener una de las opciones de semántica de invocación o llamadas, generalmente se elige al menos una vez o como máximo una vez. Para lograr esto, el módulo de comunicación implementará las opciones de diseño deseadas en términos de retransmisión de solicitudes, tratamiento de duplicados y retransmisión de resultados.
Bibliografia:
96 Chapter 5. Comunicación entre Procesos Remotos
