Remote Procedure Call: comunicación en sistemas cliente-servidor

La RPC o Remote Procedure Call (en español, llamada a procedimiento remoto) es una herramienta básica para establecer estructuras colaborativas y operativas en redes y arquitecturas cliente-servidor. Sigue leyendo si quieres saber cómo colaboran los ordenadores remotos mediante RPC, en qué niveles tiene lugar el proceso y en qué ámbitos se utiliza esta tecnología actualmente.

La llamada a procedimiento remoto es una tecnología que regula la comunicación entre procesos, es decir, el intercambio de información entre procesos de sistema. En 1984, los informáticos Andrew Birrell y Bruce Nelson definieron a la RPC como un mecanismo síncrono “que transfiere el flujo de control y los datos entre dos espacios de direcciones a través de una red de banda estrecha como llamada a proceso”. Al traspasar el espacio de direcciones, los procesos pueden iniciarse en un ordenador remoto conectado a la red y pueden incluirse instancias externas en procesos de cálculo y procesamiento de datos de manera operativa. El proceso de comunicación con RPC consta del envío de parámetros y el retorno de un valor de función. A menudo, no se limita a una sola llamada, ya que en la práctica se procesan muchas solicitudes en paralelo.

En última instancia, el concepto subyacente a la llamada a procedimiento remoto tiene como objetivo armonizar los niveles de procesamiento: idealmente, para los programadores y usuarios, no debería suponer ninguna diferencia de qué llamada a procedimiento se trate. En otras palabras: las llamadas remotas deberían ser tan fáciles de implementar como las locales (principio de transparencia), al menos en teoría. En las redes y arquitecturas cliente-servidor, las llamadas RPC suponen un proceso de comunicación bidireccional orientada a solicitudes y complementan la comunicación basada puramente en mensajes, que sigue el paradigma de entrada y salida (uso de funciones de E/S).

Actualmente, las llamadas RPC se utilizan en muchos ámbitos: son uno de los componentes fundamentales de los servicios web (por ejemplo, como protocolo XML-RPC para llamadas a funciones remotas a través de HTTP) y hacen posibles las aplicaciones distribuidas, en las que diferentes ordenadores comparten los recursos disponibles y las tareas entrantes. Entre otras, aquí se incluyen los servicios informáticos en la nube, los sistemas bancarios o los sistemas de reservas turísticas, así como las bases de datos. Otros campos de aplicación son los clústeres de ordenadores (clústeres de alta disponibilidad), las redes entre iguales descentralizadas y las cadenas de bloques (por ejemplo, de las criptomonedas), que también suelen trabajar con la tecnología RPC.

Asimismo, las Remote Procedure Calls son básicas para el funcionamiento de los sistemas operativos actuales: por ejemplo, Windows las utiliza en muchas rutinas que se llevan a cabo constantemente, como el servicio de fax, la cola de impresión o las conexiones de red configuradas, que utilizan un servicio de sistema denominado “llamada a procedimiento remoto”.

En el mundo de Unix y Linux, tiene un papel importante el Network File System (NFS), o sistema de archivos de red, desarrollado por Sun Microsystems. Este sistema utiliza las RPC entre cliente y servidor para montar el conjunto de archivos de un ordenador remoto en un ordenador local, es decir, para que estos estén disponibles en el segundo de forma parcial o completa, lo que permite al usuario administrar los archivos ubicados en un dispositivo remoto como si los tuviera en su propio ordenador. Estableciendo permisos, se regulan los derechos de lectura y escritura de los archivos. El Network Information System (NIS), o sistema de información de red, también utiliza RPC y, por lo tanto, permite administrar los sistemas Unix y Linux de forma centralizada.

El protocolo RPC gestiona la comunicación entre procesos de manera fiable y requiere un tiempo de procesamiento relativamente corto. Así, se facilita mucho la programación de procesos de comunicación entre ordenadores remotos, porque, por ejemplo, no es necesario tener en cuenta las características más complejas de la red que se utiliza. RPC permite además una modularización coherente: los procesos pueden distribuirse, aligerando así la carga de los ordenadores. Las redes y los sistemas distribuidos funcionan de forma más eficiente gracias al repartimiento del trabajo mediante el uso de plataformas especializadas para tareas concretas (por ejemplo, servidores de bases de datos), y todas las partes implicadas pueden conectarse a la red desde cualquier lugar del mundo. Otras ventajas son la excelente escalabilidad de las arquitecturas cliente-servidor implementadas, así como la posibilidad de trabajar en la nube fácilmente.

Una de las desventajas de RPC es que no existe un estándar unificado para esta tecnología. Las diferentes implementaciones, la mayoría específicas de cada empresa (por ejemplo, ONC-RPC de Sun), no suelen ser compatibles entre sí. Además, los niveles de transferencia de los sistemas basados en RPC conllevan una cierta pérdida de velocidad, al contrario que las llamadas a procedimiento puramente locales. Como el cliente y el servidor utilizan diferentes entornos de ejecución para sus respectivas rutinas, el uso de recursos (por ejemplo, archivos) también se vuelve más complejo. Por lo tanto, el protocolo RPC no resulta muy adecuado para transferir grandes cantidades de datos.

La división en diferentes instancias de procesamiento también vuelve el sistema más susceptible a errores. Los mensajes pueden perderse durante el proceso de comunicación (por un error de red o el fallo de algún nodo) o pueden ocurrir retrasos e interrupciones que produzcan complicaciones como problemas de timing, dobles ejecuciones redundantes (por ejemplo, de llamadas a procedimiento) o asincronías no deseadas en la comunicación entre los dispositivos. Con la RPC síncrona, el cliente podría verse afectado por algún problema del servidor (por ejemplo, una caída) si el proceso solicitante espera en vano el valor de retorno. Por otro lado, el servidor se ralentiza si la respuesta del cliente se retrasa o no llega en absoluto. Esta susceptibilidad a los errores puede influir mucho en los procesos, especialmente en las arquitecturas grandes con un alto grado de división de tareas.

Debido a todas estas posibles causas de error, hay que dominar la semántica especial de los errores de la RPC, lo que vuelve la programación relativamente más compleja. Los desarrolladores deben lidiar con los aspectos relacionados con la seguridad de los sistemas distribuidos y su comunicación a través de RPC y UDP/IP o TCP/IP –seguridad de red, piratería, ataques de denegación de servicio, etc.