Remote Procedure Call: co­mu­ni­ca­ción en sistemas cliente-servidor

La RPC o Remote Procedure Call (en español, llamada a pro­ce­di­mie­n­to remoto) es una he­rra­mie­n­ta básica para es­ta­ble­cer es­tru­c­tu­ras co­la­bo­ra­ti­vas y ope­ra­ti­vas en redes y ar­qui­te­c­tu­ras cliente-servidor. Sigue leyendo si quieres saber cómo colaboran los or­de­na­do­res remotos mediante RPC, en qué niveles tiene lugar el proceso y en qué ámbitos se utiliza esta te­c­no­lo­gía ac­tua­l­me­n­te.

La llamada a pro­ce­di­mie­n­to remoto es una te­c­no­lo­gía que regula la co­mu­ni­ca­ción entre procesos, es decir, el in­te­r­ca­m­bio de in­fo­r­ma­ción entre procesos de sistema. En 1984, los in­fo­r­má­ti­cos Andrew Birrell y Bruce Nelson de­fi­nie­ron a la RPC como un mecanismo síncrono “que tra­n­s­fie­re el flujo de control y los datos entre dos espacios de di­re­c­cio­nes a través de una red de banda estrecha como llamada a proceso”. Al traspasar el espacio de di­re­c­cio­nes, los procesos pueden iniciarse en un ordenador remoto conectado a la red y pueden incluirse in­s­ta­n­cias externas en procesos de cálculo y pro­ce­sa­mie­n­to de datos de manera operativa. El proceso de co­mu­ni­ca­ción con RPC consta del envío de pa­rá­me­tros 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 so­li­ci­tu­des en paralelo.

En última instancia, el concepto su­b­ya­ce­n­te a la llamada a pro­ce­di­mie­n­to remoto tiene como objetivo armonizar los niveles de pro­ce­sa­mie­n­to: idea­l­me­n­te, para los pro­gra­ma­do­res y usuarios, no debería suponer ninguna di­fe­re­n­cia de qué llamada a pro­ce­di­mie­n­to se trate. En otras palabras: las llamadas remotas deberían ser tan fáciles de im­ple­me­n­tar como las locales (principio de tra­n­s­pa­re­n­cia), al menos en teoría. En las redes y ar­qui­te­c­tu­ras cliente-servidor, las llamadas RPC suponen un proceso de co­mu­ni­ca­ción bi­di­re­c­cio­nal orientada a so­li­ci­tu­des y co­m­ple­me­n­tan la co­mu­ni­ca­ción basada puramente en mensajes, que sigue el paradigma de entrada y salida (uso de funciones de E/S).

Ac­tua­l­me­n­te, las llamadas RPC se utilizan en muchos ámbitos: son uno de los co­m­po­ne­n­tes fu­n­da­me­n­ta­les de los servicios web (por ejemplo, como protocolo XML-RPC para llamadas a funciones remotas a través de HTTP) y hacen posibles las apli­ca­cio­nes di­s­tri­bui­das, en las que di­fe­re­n­tes or­de­na­do­res comparten los recursos di­s­po­ni­bles y las tareas entrantes. Entre otras, aquí se incluyen los servicios in­fo­r­má­ti­cos en la nube, los sistemas bancarios o los sistemas de reservas tu­rí­s­ti­cas, así como las bases de datos. Otros campos de apli­ca­ción son los clústeres de or­de­na­do­res (clústeres de alta di­s­po­ni­bi­li­dad), las redes entre iguales de­s­ce­n­tra­li­za­das y las cadenas de bloques (por ejemplo, de las cri­p­to­mo­ne­das), que también suelen trabajar con la te­c­no­lo­gía RPC.

Asimismo, las Remote Procedure Calls son básicas para el fu­n­cio­na­mie­n­to de los sistemas ope­ra­ti­vos actuales: por ejemplo, Windows las utiliza en muchas rutinas que se llevan a cabo co­n­s­ta­n­te­me­n­te, como el servicio de fax, la cola de impresión o las co­ne­xio­nes de red co­n­fi­gu­ra­das, que utilizan un servicio de sistema de­no­mi­na­do “llamada a pro­ce­di­mie­n­to remoto”.

En el mundo de Unix y Linux, tiene un papel im­po­r­ta­n­te el Network File System (NFS), o sistema de archivos de red, de­sa­rro­lla­do por Sun Mi­cro­s­y­s­te­ms. 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 di­s­po­ni­bles en el segundo de forma parcial o completa, lo que permite al usuario ad­mi­ni­s­trar los archivos ubicados en un di­s­po­si­ti­vo remoto como si los tuviera en su propio ordenador. Es­ta­ble­cie­n­do permisos, se regulan los derechos de lectura y escritura de los archivos. El Network In­fo­r­ma­tion System (NIS), o sistema de in­fo­r­ma­ción de red, también utiliza RPC y, por lo tanto, permite ad­mi­ni­s­trar los sistemas Unix y Linux de forma ce­n­tra­li­za­da.

El protocolo RPC gestiona la co­mu­ni­ca­ción entre procesos de manera fiable y requiere un tiempo de pro­ce­sa­mie­n­to re­la­ti­va­me­n­te corto. Así, se facilita mucho la pro­gra­ma­ción de procesos de co­mu­ni­ca­ción entre or­de­na­do­res remotos, porque, por ejemplo, no es necesario tener en cuenta las ca­ra­c­te­rí­s­ti­cas más complejas de la red que se utiliza. RPC permite además una mo­du­la­ri­za­ción coherente: los procesos pueden di­s­tri­bui­r­se, ali­ge­ra­n­do así la carga de los or­de­na­do­res. Las redes y los sistemas di­s­tri­bui­dos funcionan de forma más eficiente gracias al re­pa­r­ti­mie­n­to del trabajo mediante el uso de pla­ta­fo­r­mas es­pe­cia­li­za­das para tareas concretas (por ejemplo, se­r­vi­do­res de bases de datos), y todas las partes im­pli­ca­das pueden co­ne­c­tar­se a la red desde cualquier lugar del mundo. Otras ventajas son la excelente es­ca­la­bi­li­dad de las ar­qui­te­c­tu­ras cliente-servidor im­ple­me­n­ta­das, así como la po­si­bi­li­dad de trabajar en la nube fá­ci­l­me­n­te.

Una de las de­s­ve­n­ta­jas de RPC es que no existe un estándar unificado para esta te­c­no­lo­gía. Las di­fe­re­n­tes im­ple­me­n­ta­cio­nes, la mayoría es­pe­cí­fi­cas de cada empresa (por ejemplo, ONC-RPC de Sun), no suelen ser co­m­pa­ti­bles entre sí. Además, los niveles de tra­n­s­fe­re­n­cia de los sistemas basados en RPC conllevan una cierta pérdida de velocidad, al contrario que las llamadas a pro­ce­di­mie­n­to puramente locales. Como el cliente y el servidor utilizan di­fe­re­n­tes entornos de ejecución para sus re­s­pe­c­ti­vas 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 tra­n­s­fe­rir grandes ca­n­ti­da­des de datos.

La división en di­fe­re­n­tes in­s­ta­n­cias de pro­ce­sa­mie­n­to también vuelve el sistema más su­s­ce­p­ti­ble a errores. Los mensajes pueden perderse durante el proceso de co­mu­ni­ca­ción (por un error de red o el fallo de algún nodo) o pueden ocurrir retrasos e in­te­rru­p­cio­nes que produzcan co­m­pli­ca­cio­nes como problemas de timing, dobles eje­cu­cio­nes re­du­n­da­n­tes (por ejemplo, de llamadas a pro­ce­di­mie­n­to) o asi­n­cro­nías no deseadas en la co­mu­ni­ca­ción entre los di­s­po­si­ti­vos. 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 so­li­ci­ta­n­te 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 su­s­ce­p­ti­bi­li­dad a los errores puede influir mucho en los procesos, es­pe­cia­l­me­n­te en las ar­qui­te­c­tu­ras 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 pro­gra­ma­ción re­la­ti­va­me­n­te más compleja. Los de­sa­rro­lla­do­res deben lidiar con los aspectos re­la­cio­na­dos con la seguridad de los sistemas di­s­tri­bui­dos y su co­mu­ni­ca­ción a través de RPC y UDP/IP o TCP/IP –seguridad de red, piratería, ataques de de­ne­ga­ción de servicio, etc.