Chamada de procedimento remoto - Remote procedure call

Na computação distribuída , uma chamada de procedimento remoto ( RPC ) é quando um programa de computador faz com que um procedimento ( sub-rotina ) seja executado em um espaço de endereço diferente (comumente em outro computador em uma rede compartilhada), que é codificado como se fosse normal ( chamada de procedimento local), sem que o programador codifique explicitamente os detalhes da interação remota. Ou seja, o programador escreve essencialmente o mesmo código, quer a sub-rotina seja local para o programa em execução ou remota. Esta é uma forma de interação cliente-servidor (o chamador é o cliente, o executor é o servidor), geralmente implementada por meio de um sistema de troca de mensagens de solicitação-resposta. No paradigma de programação orientada a objetos, RPCs são representados por invocação de método remoto (RMI). O modelo RPC implica um nível de transparência de localização , ou seja, que os procedimentos de chamada são basicamente os mesmos, sejam locais ou remotos, mas geralmente não são idênticos, de modo que as chamadas locais podem ser distinguidas das remotas. As chamadas remotas são geralmente muito mais lentas e menos confiáveis ​​do que as chamadas locais, portanto, distingui-las é importante.

RPCs são uma forma de comunicação entre processos (IPC), em que diferentes processos têm diferentes espaços de endereço: se na mesma máquina host, eles têm espaços de endereço virtual distintos, embora o espaço de endereço físico seja o mesmo; enquanto se eles estiverem em hosts diferentes, o espaço de endereço físico é diferente. Muitas tecnologias diferentes (muitas vezes incompatíveis) foram usadas para implementar o conceito.

História e origens

Os protocolos de solicitação-resposta datam do início da computação distribuída no final dos anos 1960, as propostas teóricas de chamadas de procedimento remoto como o modelo de operações de rede datam dos anos 1970 e as implementações práticas datam do início dos anos 1980. Bruce Jay Nelson é geralmente responsável por cunhar o termo "chamada de procedimento remoto" em 1981.

As chamadas de procedimento remoto usadas em sistemas operacionais modernos têm suas raízes no sistema de multiprogramação RC 4000 , que usava um protocolo de comunicação de solicitação-resposta para sincronização de processos. A ideia de tratar as operações de rede como chamadas de procedimento remoto remonta pelo menos aos anos 1970, nos primeiros documentos da ARPANET . Em 1978, Per Brinch Hansen propôs Processos Distribuídos, uma linguagem para computação distribuída baseada em "solicitações externas" consistindo em chamadas de procedimento entre processos.

Uma das primeiras implementações práticas foi em 1982 por Brian Randell e colegas para sua conexão Newcastle entre máquinas UNIX. Isso foi logo seguido por "Lupin" de Andrew Birrell e Bruce Nelson no ambiente Cedar no Xerox PARC . Lupin gerou stubs automaticamente, fornecendo ligações seguras de tipo e usou um protocolo eficiente para comunicação. Um dos primeiros usos comerciais do RPC foi pela Xerox sob o nome de "Courier" em 1981. A primeira implementação popular do RPC no Unix foi o RPC da Sun (agora chamado ONC RPC), usado como base para o Network File System (NFS).

Na década de 1990, com a popularidade da programação orientada a objetos , um modelo alternativo de invocação de método remoto (RMI) foi amplamente implementado, como na Common Object Request Broker Architecture (CORBA, 1991) e invocação de método remoto Java . Os RMIs, por sua vez, caíram em popularidade com o surgimento da Internet, principalmente nos anos 2000.

Passagem de mensagem

RPC é um protocolo de solicitação-resposta . Um RPC é iniciado pelo cliente , que envia uma mensagem de solicitação a um servidor remoto conhecido para executar um procedimento especificado com os parâmetros fornecidos. O servidor remoto envia uma resposta ao cliente e o aplicativo continua seu processo. Enquanto o servidor está processando a chamada, o cliente é bloqueado (ele espera até que o servidor conclua o processamento antes de retomar a execução), a menos que o cliente envie uma solicitação assíncrona ao servidor, como um XMLHttpRequest . Existem muitas variações e sutilezas em várias implementações, resultando em uma variedade de protocolos RPC diferentes (incompatíveis).

Uma diferença importante entre chamadas de procedimento remoto e chamadas locais é que as chamadas remotas podem falhar devido a problemas de rede imprevisíveis. Além disso, os chamadores geralmente precisam lidar com essas falhas sem saber se o procedimento remoto foi realmente invocado. Procedimentos idempotentes (aqueles que não têm efeitos adicionais se chamados mais de uma vez) são facilmente manipulados, mas permanecem dificuldades suficientes para que o código para chamar procedimentos remotos seja freqüentemente confinado a subsistemas de baixo nível cuidadosamente escritos.

Sequência de eventos

  1. O cliente chama o stub do cliente . A chamada é uma chamada de procedimento local, com parâmetros colocados na pilha da maneira normal.
  2. O stub do cliente empacota os parâmetros em uma mensagem e faz uma chamada de sistema para enviar a mensagem. Empacotar os parâmetros é chamado de empacotamento .
  3. O sistema operacional local do cliente envia a mensagem da máquina cliente para a máquina servidor.
  4. O sistema operacional local na máquina do servidor passa os pacotes de entrada para o stub do servidor .
  5. O stub do servidor descompacta os parâmetros da mensagem. Desembalar os parâmetros é chamado unmarshalling .
  6. Finalmente, o stub do servidor chama o procedimento do servidor. A resposta segue as mesmas etapas na direção reversa.

Mecanismos de contato padrão

Para permitir que diferentes clientes acessem os servidores, vários sistemas RPC padronizados foram criados. A maioria deles usa uma linguagem de descrição de interface (IDL) para permitir que várias plataformas chamem o RPC. Os arquivos IDL podem então ser usados ​​para gerar código para fazer a interface entre o cliente e os servidores.

Análogos

Implementações e análogos RPC notáveis ​​incluem:

Específico do idioma

  • Java 's Java remoto Método invocação API (Java RMI) proporciona uma funcionalidade semelhante aos métodos Unix RPC padrão.
  • Go fornece pacote rpc para implementação de RPC, com suporte para chamadas assíncronas.
  • Objetos de rede do Modula-3 , que eram a base para o RMI do Java
  • RPyC implementa mecanismos RPC em Python, com suporte para chamadas assíncronas.
  • Ruby distribuído (DRb) permite que programas Ruby se comuniquem entre si na mesma máquina ou em uma rede. O DRb usa a invocação de método remoto (RMI) para passar comandos e dados entre os processos.
  • Erlang é orientado a processos e oferece suporte nativo à distribuição e RPCs por meio da passagem de mensagens entre os nós e os processos locais.
  • O Elixir se baseia na VM Erlang e permite a comunicação do processo (processos Elixir / Erlang, não processos do sistema operacional) da mesma rede pronta para uso por meio de agentes e passagem de mensagens.

Específico do aplicativo

Em geral

  • NFS ( Network File System ) é um dos usuários mais proeminentes de RPC
  • Chamada de procedimento remoto Open Network Computing , da Sun Microsystems
  • O programa IPC de código aberto D-Bus oferece funções semelhantes ao CORBA .
  • SORCER fornece a API e a linguagem orientada ao esforço (EOL) para uma chamada de método federado
  • XML-RPC é um protocolo RPC que usa XML para codificar suas chamadas e HTTP como mecanismo de transporte.
  • JSON-RPC é um protocolo RPC que usa mensagens codificadas em JSON
  • JSON-WSP é um protocolo RPC que usa mensagens codificadas em JSON
  • SOAP é um sucessor do XML-RPC e também usa XML para codificar suas chamadas baseadas em HTTP.
  • Zeroc 's Motor Comunicações Internet (Ice) distribuídos plataforma de computação.
  • Estrutura do Etch para construir serviços de rede.
  • Protocolo e estrutura do Apache Thrift .
  • CORBA fornece invocação de procedimento remoto por meio de uma camada intermediária chamada de agente de solicitação de objeto .
  • Libevent fornece uma estrutura para a criação de servidores e clientes RPC.
  • O Windows Communication Foundation é uma interface de programação de aplicativos na estrutura .NET para a construção de aplicativos conectados e orientados a serviços.
  • O Microsoft .NET Remoting oferece recursos RPC para sistemas distribuídos implementados na plataforma Windows. Ele foi substituído pelo WCF .
  • O Microsoft DCOM usa MSRPC que é baseado em DCE / RPC
  • Ambiente de computação distribuída DCE / RPC da Open Software Foundation (também implementado pela Microsoft).
  • O pacote do Google Protocol Buffers (protobufs) inclui uma linguagem de definição de interface usada para seus protocolos RPC de código aberto em 2015 como gRPC .
  • O WAMP combina RPC e Publicação-Assinatura em um único protocolo independente de transporte.
  • O Google Web Toolkit usa um RPC assíncrono para se comunicar com o serviço do servidor.
  • Apache Avro fornece RPC onde cliente e servidor trocam esquemas no handshake de conexão e geração de código não é necessária.
  • O RPC incorporado é uma implementação de RPC leve desenvolvida pela NXP, visando núcleos CortexM primários
  • O KF Trusted Execution Environment usa proxy e empacotamento de objetos para comunicar objetos em sandboxes
  • msgpack-rpc é uma implementação RPC leve usando MessagePack para serializar dados. É usado no editor de texto Neovim .

Veja também

Referências

links externos