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).
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.
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:
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.
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.
El acceso remoto a sistemas informáticos a distancia ha sido, desde siempre, una parte importante de las redes bien organizadas. Los administradores gestionan y se ocupan de los participantes de manera individual y el hecho de trabajar desde cualquier lugar ha mejorado gracias a la posibilidad de acceder de manera remota a la información de las empresas. Telnet es uno de los primeros protocolos...
En la época de los ordenadores centrales y de las primeras redes de pequeña envergadura, los terminales fueron un componente decisivo para la utilización conjunta de recursos de hardware y software. El hecho de que los terminal servers, las instancias gestoras centrales de dicho tipo de redes, todavía sigan utilizándose cuando las aplicaciones se ponen a disposición de varios usuarios no es algo...
Ofrece un servicio fiable y de alto rendimiento a tus clientes con un pack hosting de IONOS.
