Llamada a procedimiento remoto
Mecanismo que permite al software ejecutar un procedimiento remoto

En computación distribuida , una llamada a procedimiento remoto ( RPC ) es cuando un programa de computadora hace que un procedimiento (subrutina) se ejecute en un espacio de direcciones diferente (comúnmente en otra computadora en una red de computadoras compartidas ), que se escribe como si fuera una llamada a procedimiento normal (local), sin que el programador escriba explícitamente los detalles para la interacción remota. Es decir, el programador escribe esencialmente el mismo código ya sea que la subrutina sea local al programa que se ejecuta o remota. Esta es una forma de interacción cliente-servidor (el que llama es cliente , el ejecutor es servidor ), generalmente implementada a través de un sistema de paso de mensajes de solicitud-respuesta . En el paradigma de programación orientada a objetos , las RPC se representan mediante la invocación de método remoto (RMI). El modelo RPC implica un nivel de transparencia de ubicación, es decir, que los procedimientos de llamada son en gran medida los mismos ya sean locales o remotos, pero por lo general, no son idénticos, por lo que las llamadas locales se pueden distinguir de las llamadas remotas. Las llamadas remotas suelen ser órdenes de magnitud más lentas y menos confiables que las llamadas locales, por lo que distinguirlas es importante.

Las RPC son una forma de comunicación entre procesos (IPC), en la que los distintos procesos tienen distintos espacios de direcciones: si están en la misma máquina host, tienen espacios de direcciones virtuales distintos, aunque el espacio de direcciones físicas sea el mismo; mientras que si están en diferentes hosts, el espacio de direcciones físicas también es diferente. Se han utilizado muchas tecnologías diferentes (a menudo incompatibles) para implementar el concepto.

Historia y orígenes

Los protocolos de solicitud-respuesta datan de los inicios de la computación distribuida a fines de los años 1960, las propuestas teóricas de llamadas a procedimientos remotos como modelo de operaciones de red datan de los años 1970 y las implementaciones prácticas datan de principios de los años 1980. A Bruce Jay Nelson se le atribuye generalmente la invención del término "llamada a procedimiento remoto" en 1981. [1]

Las llamadas a procedimientos remotos que se utilizan en los sistemas operativos modernos tienen sus orígenes en el sistema de multiprogramación RC 4000 [2] , que utilizaba un protocolo de comunicación de solicitud-respuesta para la sincronización de procesos. [3] La idea de tratar las operaciones de red como llamadas a procedimientos remotos se remonta al menos a la década de 1970 en los primeros documentos de ARPANET . [4] En 1978, Per Brinch Hansen propuso Distributed Processes, un lenguaje para computación distribuida basado en "solicitudes externas" que consisten en llamadas a procedimientos entre procesos. [5]

Una de las primeras implementaciones prácticas fue en 1982 por Brian Randell y colegas para su Conexión Newcastle entre máquinas UNIX. [6] Esto fue seguido pronto por "Lupine" por Andrew Birrell y Bruce Nelson en el entorno Cedar en Xerox PARC . [7] [8] [9] Lupine generó automáticamente stubs, proporcionando enlaces de tipo seguro, y utilizó un protocolo eficiente para la comunicación. [8] Uno de los primeros usos comerciales de RPC fue por Xerox bajo el nombre de "Courier" en 1981. La primera implementación popular de RPC en Unix fue RPC de Sun (ahora llamado ONC RPC), utilizado como base para Network File System (NFS).

En la década de 1990, con la popularidad de la programación orientada a objetos , se implementó ampliamente un modelo alternativo de invocación de método remoto (RMI), como en Common Object Request Broker Architecture (CORBA, 1991) y la invocación de método remoto de Java. Las RMI, a su vez, perdieron popularidad con el auge de Internet, particularmente en la década de 2000.

Paso de mensajes

RPC es un protocolo de solicitud-respuesta. El cliente inicia una RPC y envía un mensaje de solicitud a un servidor remoto conocido para ejecutar un procedimiento específico con los parámetros proporcionados. El servidor remoto envía una respuesta al cliente y la aplicación continúa su proceso. Mientras el servidor procesa la llamada, el cliente se bloquea (espera hasta que el servidor haya terminado de procesarla antes de reanudar la ejecución), a menos que el cliente envíe una solicitud asincrónica al servidor, como una XMLHttpRequest. Existen muchas variaciones y sutilezas en las distintas implementaciones, lo que da como resultado una variedad de protocolos RPC diferentes (incompatibles).

Una diferencia importante entre las llamadas a procedimientos remotos y las llamadas locales es que las llamadas remotas pueden fallar debido a problemas de red impredecibles. Además, los que llaman generalmente deben lidiar con tales fallas sin saber si el procedimiento remoto fue realmente invocado. Los procedimientos idempotentes (aquellos que no tienen efectos adicionales si se los llama más de una vez) se manejan fácilmente, pero siguen existiendo suficientes dificultades como para que el código para llamar a procedimientos remotos a menudo se limite a subsistemas de bajo nivel cuidadosamente escritos.

Secuencia de eventos

  1. El cliente llama al stub del cliente. La llamada es una llamada a un procedimiento local, con parámetros insertados en la pila de la forma habitual.
  2. El stub del cliente empaqueta los parámetros en un mensaje y realiza una llamada al sistema para enviar el mensaje. El empaquetado de los parámetros se denomina serialización.
  3. El sistema operativo local del cliente envía el mensaje desde la máquina cliente a la máquina servidor.
  4. El sistema operativo local en la máquina servidor pasa los paquetes entrantes al stub del servidor.
  5. El stub del servidor descomprime los parámetros del mensaje. La descompresión de los parámetros se denomina desagrupación.
  6. Finalmente, el stub del servidor llama al procedimiento del servidor. La respuesta sigue los mismos pasos en sentido inverso.

Mecanismos de contacto estándar

Para permitir que distintos clientes accedan a los servidores, se han creado varios sistemas RPC estandarizados. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) para permitir que varias plataformas llamen al RPC. Los archivos IDL se pueden utilizar para generar código que sirva de interfaz entre el cliente y los servidores.

Análogos

Las implementaciones y análogos de RPC notables incluyen:

Específico del idioma

  • La API de invocación de método remoto de Java (Java RMI) de Java proporciona una funcionalidad similar a la de los métodos RPC estándar de Unix.
  • Go proporciona el paquete rpc para implementar RPC, con soporte para llamadas asincrónicas.
  • Los objetos de red de Modula-3, que fueron la base para el RMI de Java [10]
  • RPyC implementa mecanismos RPC en Python , con soporte para llamadas asincrónicas.
  • Ruby distribuido (DRb) permite que los programas Ruby se comuniquen entre sí en la misma máquina o a través de una red. DRb utiliza la invocación de método remoto (RMI) para pasar comandos y datos entre procesos.
  • Erlang está orientado a procesos y soporta de forma nativa la distribución y las RPC a través del paso de mensajes entre nodos y procesos locales por igual.
  • Elixir se basa en la VM Erlang y permite la comunicación de procesos (procesos Elixir/Erlang, no procesos del sistema operativo) de la misma red de manera inmediata a través de agentes y paso de mensajes.
  • Tarpc, el marco RPC de Rust de Google, permite a los desarrolladores definir la estructura de los mensajes utilizando las estructuras y características de Rust, en lugar de usar protobuf. [11]

Específico de la aplicación

  • El formato de mensaje de acción (AMF) permite que las aplicaciones de Adobe Flex se comuniquen con back-ends u otras aplicaciones que admiten AMF.
  • La llamada a función remota es la interfaz estándar de SAP para la comunicación entre sistemas SAP. RFC invoca una función para que se ejecute en un sistema remoto.

General

  • NFS (Network File System) es uno de los usuarios más destacados de RPC
  • Computación en red abierta (RPC) , de Sun Microsystems (también conocida como Sun RPC)
  • El programa IPC de código abierto D-Bus proporciona una función similar a CORBA.
  • SORCER proporciona la API y el lenguaje orientado al esfuerzo (EOL) para una invocación de método federado
  • XML-RPC es un protocolo RPC que utiliza XML para codificar sus llamadas y HTTP como mecanismo de transporte.
  • JSON-RPC es un protocolo RPC que utiliza mensajes codificados en JSON.
  • JSON-WSP es un protocolo RPC que está inspirado en JSON-RPC.
  • SOAP es un sucesor de XML-RPC y también utiliza XML para codificar sus llamadas basadas en HTTP.
  • Plataforma de computación distribuida Internet Communications Engine (Ice) de ZeroC .
  • Marco de trabajo Etch para crear servicios de red.
  • Protocolo y marco Apache Thrift.
  • CORBA proporciona invocación de procedimientos remotos a través de una capa intermedia denominada agente de solicitud de objetos .
  • Libevent proporciona un marco para crear servidores y clientes RPC. [12]
  • Windows Communication Foundation es una interfaz de programación de aplicaciones en el marco .NET para crear aplicaciones conectadas y orientadas a servicios.
  • Microsoft .NET Remoting ofrece funciones de RPC para sistemas distribuidos implementados en la plataforma Windows. Ha sido reemplazado por WCF .
  • Microsoft DCOM utiliza MSRPC, que se basa en DCE/RPC
  • El entorno de computación distribuida DCE/RPC de la Open Software Foundation (también implementado por Microsoft).
  • El paquete Google Protocol Buffers (protobufs) incluye un lenguaje de definición de interfaz utilizado para sus protocolos RPC [13], de código abierto en 2015 como gRPC. [14]
  • WAMP combina RPC y publicación-suscripción en un único protocolo independiente del transporte.
  • Google Web Toolkit utiliza una RPC asincrónica para comunicarse con el servicio del servidor. [15]
  • Apache Avro proporciona RPC donde el cliente y el servidor intercambian esquemas en el protocolo de enlace de conexión y no se requiere generación de código.

Véase también

Referencias

  1. ^ Bruce Jay Nelson (mayo de 1981). Llamada a procedimiento remoto (tesis doctoral). Xerox Palo Alto Research Center. PARC CSL-81-9 (también CMU-CS-81-119).
  2. ^ "Per Brinch Hansen • IEEE Computer Society". www.computer.org . Consultado el 15 de diciembre de 2015 .
  3. ^ Brinch Hansen, Per (1969). Software informático RC 4000: Sistema de multiprogramación (PDF) . Copenhague, Dinamarca: Regnecentralen.
  4. ^ James E. White (23 de diciembre de 1975). "Un marco de trabajo de alto nivel para el uso compartido de recursos en red". RFC 707 . Augmentation Research Center . doi : 10.17487/RFC0707 . Consultado el 11 de julio de 2011 .
  5. ^ Brinch Hansen, Per (noviembre de 1978). "Procesos distribuidos: un concepto de programación concurrente" (PDF) . Comunicaciones de la ACM . 21 (11): 934–941. CiteSeerX 10.1.1.107.3108 . doi :10.1145/359642.359651. S2CID  11610744. 
  6. ^ Brownbridge, David R.; Marshall, Lindsay F.; Randell, Brian (1982). "The Newcastle Connection" (PDF) . Software: Practice and Experience . 12 (12): 1147–1162. doi :10.1002/spe.4380121206. S2CID  1840438. Archivado desde el original (PDF) el 2016-08-16 . Consultado el 2016-08-16 .
  7. ^ Birrell, Andrew D.; Nelson, Bruce Jay (1984). "Implementación de llamadas a procedimientos remotos" (PDF) . ACM Transactions on Computer Systems . 2 : 39–59. doi :10.1145/2080.357392. S2CID  11525846.
  8. ^ ab "1994 – Andrew Birrell, Bruce Nelson: Remote Procedure Call". Cita del premio Software System Award . Association for Computing Machinery . Archivado desde el original el 2 de abril de 2012. Consultado el 11 de julio de 2011 .
  9. ^ "Premio del Salón de la Fama de SIGOPS". Grupo de Interés Especial sobre Sistemas Operativos . Association for Computing Machinery . Consultado el 11 de julio de 2011 .
  10. ^ La A a la Z de los lenguajes de programación: Modula-3 - La A a la Z de los lenguajes de programación Archivado el 5 de enero de 2009 en Wayback Machine . Computerworld. Consultado el 17 de julio de 2013.
  11. ^ tarpc, Google, 2 de noviembre de 2023 , consultado el 2 de noviembre de 2023
  12. ^ libevent: Página principal. Monkey.org. Recuperado el 17 de julio de 2013.
  13. ^ "Protocol Buffers - Formato de intercambio de datos de Google". Sitio web del proyecto Google . Consultado el 1 de noviembre de 2011 .
  14. ^ "gRPC, marco de trabajo universal de RPC de código abierto". Sitio web del proyecto de Google . Consultado el 7 de septiembre de 2016 .
  15. ^ "Google Web Toolkit". Sitio web del proyecto Google . Consultado el 1 de noviembre de 2011 .
  • RFC 5531: especifica la versión 2 de ONC RPC (cuarta versión RFC publicada)
  • RFC 1831: especifica la versión 2 de ONC RPC (tercera versión RFC publicada)
  • RFC 1057: especifica la versión 2 de ONC RPC (segunda versión RFC publicada)
  • RFC 1050: especifica la versión 2 de ONC RPC (primera versión RFC publicada)
  • Llamadas a procedimientos remotos (RPC): un tutorial sobre ONC RPC a cargo del Dr. Dave Marshall de la Universidad de Cardiff
  • Introducción a la programación RPC: una introducción para desarrolladores a RPC y XDR, de la documentación de SGI IRIX.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Llamada_a_procedimiento_remoto&oldid=1252731264"