# 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).

Nota 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:

1. El código del cliente llama a un **procedimiento *stub*** (*stub* del cliente local).
2. 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*).
3. El *stub* del cliente se pone en contacto con el sistema de comunicación del ordenador local, que suele utilizar [**TCP/IP**](https://www.ionos.es/digitalguide/servidores/know-how/tcpip/) o [**UDP/IP**](https://www.ionos.es/digitalguide/servidores/know-how/udp-user-datagram-protocol/) para el subsiguiente intercambio de mensajes entre el cliente y el servidor.
4. 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).
5. El *stub* del servidor transfiere los parámetros descodificados, efectuando la **llamada a procedimiento del servidor a nivel local**.
6. El **valor de la función** resultante se comunica al *stub* del servidor.
7. 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.

[![Imagen: Esquema gráfico de la tecnología RPC](https://www.ionos.es/digitalguide/fileadmin/_processed_/4/4/csm_EN-rpc_542bc17b7a.webp "Esquema gráfico de la tecnología RPC")](https://www.ionos.es/digitalguide/fileadmin/DigitalGuide/Schaubilder/EN-rpc.png) Esquema gráfico de la tecnología RPC ## 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](https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/web-services/ "Web services")** (por ejemplo, como protocolo [XML-RPC](https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/que-es-xml-rpc/ "¿Qué es 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](https://www.ionos.es/digitalguide/servidores/know-how/cloud-computing/ "Cloud computing"), los sistemas bancarios o los sistemas de reservas** turísticas, así como las [**bases de datos**](https://www.ionos.es/digitalguide/hosting/cuestiones-tecnicas/bases-de-datos/ "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](https://www.ionos.es/digitalguide/online-marketing/vender-en-internet/blockchain/ "Blockchain") (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](https://www.ionos.es/digitalguide/servidores/know-how/el-sistema-operativo/ "El sistema operativo")** 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](https://www.ionos.es/digitalguide/servidores/know-how/dos-y-ddos-un-vistazo-a-ambos-patrones-de-ataque/), etc.

Nota 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.


This is a markdown version of: [https://www.ionos.es/digitalguide/servidores/know-how/que-es-rpc/](https://www.ionos.es/digitalguide/servidores/know-how/que-es-rpc/) for AI/LLM consumption.