Llamada a procedimiento remoto

1. Worldwidelegecy description Mecanismo para permitir que el software ejecute 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 otro computadora en una red compartida), que se codifica como si fuera una llamada de procedimiento normal (local), sin que el programador codifique 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 para el programa en ejecución o remota. Esta es una forma de interacción cliente-servidor (la persona que llama es el cliente, el ejecutor es el servidor), normalmente implementada a través de un sistema de paso de mensajes de solicitud-respuesta. En el paradigma de la programación orientada a objetos, las RPC se representan mediante la invocación de métodos remotos (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 mucho más lentas y menos fiables que las llamadas locales, por lo que es importante distinguirlas.

Los RPC son una forma de comunicación entre procesos (IPC), en la que diferentes procesos tienen diferentes espacios de direcciones: si están en la misma máquina host, tienen distintos espacios de direcciones virtuales, aunque el espacio de direcciones físico sea el mismo; mientras que si están en diferentes hosts, el espacio de direcciones físicas 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 la década de 1960, las propuestas teóricas de llamadas a procedimientos remotos como modelo de operaciones de red datan de la década de 1970 y las implementaciones prácticas datan de principios de la década de 1980. A Bruce Jay Nelson generalmente se le atribuye haber acuñado el término "llamada a procedimiento remoto" en 1981.

Las llamadas a procedimientos remotos que se usan en los sistemas operativos modernos se remontan al sistema de multiprogramación RC 4000, que usaba un protocolo de comunicación de solicitud-respuesta para la sincronización de procesos. 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. En 1978, Per Brinch Hansen propuso Distributed Processes, un lenguaje para computación distribuida basado en "solicitudes externas" que consiste en llamadas de procedimiento entre procesos.

Una de las primeras implementaciones prácticas fue en 1982 por parte de Brian Randell y colegas para su Newcastle Connection entre máquinas UNIX. A esto pronto le siguió "Lupin" por Andrew Birrell y Bruce Nelson en el ambiente Cedar en Xerox PARC. Lupin generó automáticamente stubs, proporcionando enlaces de tipo seguro y usó un protocolo eficiente para la comunicación. Uno de los primeros usos comerciales de RPC fue por Xerox bajo el nombre "Courier" en 1981. La primera implementación popular de RPC en Unix fue RPC de Sun (ahora llamado ONC RPC), que se utilizó 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étodos remotos (RMI), como en Common Object Request Broker Architecture (CORBA, 1991) y la invocación de métodos remotos de Java. Las RMI, a su vez, perdieron popularidad con el auge de Internet, particularmente en la década de 2000.

Transmisión de mensajes

RPC es un protocolo de solicitud-respuesta. El cliente inicia una RPC, que 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 está bloqueado (espera hasta que el servidor haya terminado de procesar antes de reanudar la ejecución), a menos que el cliente envíe una solicitud asíncrona al servidor, como XMLHttpRequest. Hay muchas variaciones y sutilezas en varias 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, las personas que llaman generalmente deben lidiar con tales fallas sin saber si realmente se invocó el procedimiento remoto. Los procedimientos idempotentes (aquellos que no tienen efectos adicionales si se les llama más de una vez) se manejan fácilmente, pero persisten 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 cliente. La llamada es una llamada de procedimiento local, con parámetros empujados a la pila de la manera normal.
2. El problema cliente empaqueta los parámetros en un mensaje y hace una llamada del sistema para enviar el mensaje. Empaquetar los parámetros se llama marshalling.
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 del servidor pasa los paquetes entrantes al problema del servidor.
5. El stub servidor desempaqueta los parámetros del mensaje. Desempaquetar los parámetros se llama unmarshalling.
6. Finalmente, el stub del servidor llama el procedimiento del servidor. La respuesta traza los mismos pasos en la dirección inversa.

Mecanismos de contacto estándar

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

Analógicos

Las implementaciones y análogos notables de RPC incluyen:

Específico del idioma

• Java Remote Method Invocation (Java RMI) API proporciona funcionalidad similar a los métodos estándar Unix RPC.
• Go proporciona 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
• RPyC implementa mecanismos RPC en Python, con apoyo para llamadas asincrónicas.
• Distribuido Ruby (DRb) permite que los programas de Ruby se comuniquen entre sí en la misma máquina o en una red. DRb utiliza la invocación de método remoto (RMI) para pasar comandos y datos entre procesos.
• Erlang está orientado al proceso y apoya nativamente la distribución y los RPC mediante mensajes que pasan entre los nodos y los procesos locales por igual.
• Elixir se construye en la parte superior de la Erlang VM y permite la comunicación de procesos (Procesos Elixir/Erlang, no procesos OS) de la misma red fuera de la caja a través de Agentes y mensajes pasando.

Específico de la aplicación

• Action Message Format (AMF) permite que las aplicaciones de Adobe Flex se comuniquen con back-ends u otras aplicaciones que admiten AMF.
• Función remota Call es la interfaz SAP estándar para la comunicación entre sistemas SAP. RFC llama una función a ejecutar en un sistema remoto.

Generales

• NFS (Network File System) es uno de los usuarios más destacados de RPC
• Open Network Computing Remote Procedure Call, by Sun Microsystems
• El programa IPC de código abierto D-Bus proporciona una función similar a CORBA.
• SORCER proporciona la API y el lenguaje orientado a la extinción (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 por JSON
• JSON-WSP es un protocolo RPC que utiliza mensajes codificados por JSON
• SOAP es un sucesor de XML-RPC y también utiliza XML para codificar sus llamadas basadas en HTTP.
• La plataforma de computación distribuida de ZeroC Internet Communications Engine (Ice).
• Etch framework for building network services.
• Protocolo y marco de Apache Thrift.
• CORBA proporciona invocación de procedimiento remoto a través de una capa intermedia llamada Solicitud de objeto broker.
• Libevent proporciona un marco para crear servidores y clientes RPC.
• Windows Communication Foundation es una interfaz de programación de aplicaciones en el. Marco NET para la construcción de aplicaciones conectadas y orientadas al servicio.
• Microsoft.NET La eliminación ofrece instalaciones RPC para sistemas distribuidos implementados en la plataforma Windows. Ha sido superada por WCF.
• El DCOM de Microsoft utiliza MSRPC que se basa en DCE/RPC
• The Open Software Foundation DCE/RPC Distributed Computing Environment (también implementado por Microsoft).
• Protocolo de Google El paquete Buffers (protobufs) incluye un lenguaje de definición de interfaz utilizado para sus protocolos RPC de código abierto en 2015 como gRPC.
• WAMP combina RPC y Publish-Subscribe en un único protocolo agnóstico de transporte.
• Google Web Toolkit utiliza un RPC asincrónico para comunicarse al servicio del servidor.
• Apache Avro proporciona RPC donde los esquemas de intercambio de cliente y servidor en el apretón de manos y generación de código no es necesario.