Llamada a procedimiento remoto

La mayoría de programas modernos presentan una estructura modular, en la que una función puede ser utilizada mediante una interfaz, la cual enmascara dicho procedimiento pudiéndose cambiar su funcionalidad sin que afecte a la forma en la que es llamada. Estos módulos pueden comunicarse entre sí mediante RPC de tal manera que las interacciones quedan controladas a través de las interfaces de los módulos, aunque varíe su implementación interna.

En un programa distribuido, por ejemplo, con arquitectura cliente-servidor, el servidor proporciona a los clientes un listado de los módulos que están disponibles para su uso, así como los argumentos necesarios para realizar una correcta llamada a los mismos. De esta forma el cliente únicamente debe preocuparse de la interfaz, no necesita saber detalles de la implementación del módulo, como por ejemplo el lenguaje de programación, o la plataforma en la que el servicio fue implementado, de esta manera se soluciona el problema de la heterogeneidad de los sistemas distribuidos actuales.

Por otro lado, si un módulo que se ejecuta en un proceso necesita acceder a variables de otro módulo que se ejecuta en otro proceso, no puede acceder a ellas, ya que el paso de argumentos por referencia no está permitido. Como consecuencia de esto último, los parámetros de salida van en un mensaje de respuesta. Una excepción es CORBA que puede acceder a las variables de un módulo situado en otro proceso mediante los métodos getter y setter.

Los creadores de RPC, Birrell y Nelson, intentaron hacer las llamadas a procedimiento remoto lo más parecidas a las locales, de tal manera que no hubiese una distinción entre una llamada local y una llamada remota. Las transformaciones de la representación de los datos a un formato adecuado, el llamado marshalling, así como otros procedimientos de paso de mensaje se ocultan al programador. RPC se centra en ofrecer transparencia en la localización y el acceso, ocultando la localización física de los métodos.

Sin embargo, las llamadas a procedimientos remotos son más vulnerables a fallar que las locales, ya que implican una conexión a red y otro ordenador con otro proceso. Eso hace que se tenga más dificultad en determinar qué ha podido ocasionar un fallo.

También hay que tener en cuenta que las llamadas RPC tienen una latencia superior. Esto se debe tener en cuenta reduciendo lo mínimo posible este tipo de llamadas o haciendo que el procedimiento que realiza la llamada RPC sea capaz de abortarla en el caso de que tarde demasiado tiempo. Si se hace lo segundo, es importante que el servidor restaure la información a como estaba antes de la llamada.

Existe una discusión entre los programadores de cómo de transparente tiene que ser una llamada RPC. Por ejemplo, los creadores del lenguaje de programación Argus (Liskov y Scheifler) afirmaban que las llamadas RPC deberían ser diferentes que las locales, y como consecuencia de ello en Argus hicieron las llamadas remotas explícitas al programador.[3] La conclusión general a la que se ha llegado es que la sintaxis entre una llamada local y una remota debería ser igual, y que la diferencia entre una y otra debería ser explicada en sus interfaces.

• Procedimiento remoto puede ejecutarse una vez o ninguna vez.
• El cliente puede recibir una respuesta o ninguna.

Funcionamiento

1. El cliente envía una petición y se queda a la espera un tiempo determinado.
2. Si no llega la respuesta dentro del tiempo de espera, continúa su ejecución.
3. El cliente no tiene realimentación en caso de fallo (no sabe que pasó).

Sólo admisible en aplicaciones donde se tolere la pérdida de peticiones y la recepción de respuestas con retraso (fuera de orden).

• Procedimiento remoto se ejecuta una o más veces.
• El cliente puede recibir una o más respuestas.

Funcionamiento

1. El cliente envía una petición y queda a la espera un tiempo.
2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
3. El servidor no filtra peticiones duplicadas (el procedimiento remoto puede ejecutarse repetidas veces).
4. El cliente puede recibir varias respuestas.

Sólo es aplicable cuando se usan exclusivamente operaciones idempotentes (repetibles). Nota: una operación es idempotente si se puede ejecutar varias veces resultando el mismo efecto que si se hubiera ejecutado sólo una. En ocasiones una operación no idempotente puede implementarse como una secuencia de operaciones idempotentes. Admisible en aplicaciones donde se tolere que se puedan repetir invocaciones sin afectar a su funcionamiento.

• El procedimiento remoto se ejecuta exactamente una vez o no llega a ejecutarse ninguna.
• El cliente recibe una respuesta o una indicación de que no se ha ejecutado el procedimiento remoto.

Funcionamiento

1. El cliente envía la petición y queda a la espera un tiempo.
2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
3. El servidor filtra las peticiones duplicadas y guarda historial con las respuestas enviadas (servidor con memoria). El procedimiento remoto sólo se ejecuta una vez.
4. El cliente sólo recibe una respuesta si la petición llegó y se ejecutó el procedimiento, si no recibe informe del error.