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.
¿Qué es RPC?
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).
La RPC ha sido especialmente concebida para comunicar varios ordenadores, aunque también puede participar en la comunicación entre diferentes procesos dentro de un único sistema coherente.
Stub del cliente y stub del servidor: funcionamiento de RPC
Las llamadas a procedimiento remoto siempre se ejecutan siguiendo un patrón determinado: por ejemplo, un cliente contacta con un servidor de base de datos central para buscar una pieza de repuesto. El servidor remoto revisa entonces la base de datos y envía el resultado al cliente. Este último procesa los datos recibidos y muestra, por ejemplo, una lista con los datos del inventario en un software de gestión.
En la implementación de una Remote Procedure Call, en el lado del emisor y del receptor participan unas instancias especiales llamadas stubs. El stub del cliente actúa como sustituto del procedimiento del servidor remoto en el lado del cliente, mientras que el stub del servidor sustituye al código del cliente que realiza la llamada en el lado del servidor. Disfrazando el “alejamiento” del código en el otro lado, los stubs simulan operar como una unidad local funcional. Al mismo tiempo, actúan como interfaces de procedimiento. La secuencia típica de una llamada RPC podría resumirse en los siguientes pasos:
- El código del cliente llama a un procedimiento stub (stub del cliente local).
- Sobre la base de los parámetros transferidos en la llamada a procedimiento, el stub del cliente genera un mensaje apto para enviarse que se adhiere al protocolo RPC. Durante la transferencia, se lleva a cabo una serialización en la cual los datos estructurados se traducen a una forma de representación secuencial. Este proceso también se conoce como marshalling (del inglés marshal, que significa presentar u ordenar).
- El stub del cliente se pone en contacto con el sistema de comunicación del ordenador local, que suele utilizar TCP/IP o UDP/IP para el subsiguiente intercambio de mensajes entre el cliente y el servidor.
- Cuando el mensaje enviado llega al destinatario, el stub del servidor lleva a cabo el llamado demarshalling o unmarshalling, es decir, que desempaqueta los parámetros que contiene el mensaje (basado en el RPC protocol).
- El stub del servidor transfiere los parámetros descodificados, efectuando la llamada a procedimiento del servidor a nivel local.
- El valor de la función resultante se comunica al stub del servidor.
- Ahora, el proceso se lleva a cabo en dirección contraria: se genera un mensaje que cumpla con el protocolo RPC, el servidor y el cliente se comunican y el valor de retorno se transfiere al código del cliente en espera. La aplicación continúa ejecutándose en el ordenador de origen.
Clústeres de ordenadores y cloud computing: ámbitos de uso de RPC
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.
¿Qué ventajas tiene RPC?
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.
¿Qué inconvenientes tiene RPC?
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.
Algunos de los problemas derivados de la sincronicidad entre cliente y servidor en general pueden resolverse con conceptos de RPC asíncrona. Con este método, el cliente no tiene que esperar una respuesta del servidor, sino que puede continuar con el flujo del programa y realizar otras operaciones después de la llamada. En este caso, el cliente procesa la respuesta del servidor más adelante. Sin embargo, programar llamadas RPC asíncronas es muy complejo y requiere mucho tiempo.