Chamada de procedimento remoto

A ideia de RPC data de 1976, quando foi descrito no RFC 707. Um dos primeiros usos comerciais da tecnologia foi feita pela Xerox no "Courier", de 1981. A primeira implementação popular para Unix foi o Sun RPC (atualmente chamado ONC RPC), usado como base do Network File System e que ainda é usada em diversas plataformas. Outra implementação pioneira em Unix foi o Network Computing System (NCS) da Apollo Computer, que posteriormente foi usada como fundação do DCE/RPC no Distributed Computing Environment (DCE). Uma década depois a Microsoft adotou o DCE/RPC como base para a sua própria implementação de RPC, MSRPC, a DCOM foi implementada com base nesse sistema. Ainda no mesmo período da década de 1990, o ILU da Xerox PARC e o CORBA ofereciam outro paradigma de RPC baseado em objetos distribuídos, com mecanismos de herança. De forma análoga, atualmente utiliza-se XML e JSON como linguagem de descrição de interface e HTTP como protocolo de rede para formar serviços web, cujas implementações incluem SOAP, REST e XML-RPC.

O modelo de Chamada Remota de Procedimento é similar ao modelo de chamadas locais de procedimentos, no qual a rotina que invoca o procedimento coloca os argumentos em uma área de memória bem conhecida e transfere o controle para o procedimento em execução, que lê os argumentos e os processa. Em algum momento, a rotina retoma o controle, extraindo o resultado da execução de uma área bem conhecida da memória. Após isso, a rotina prossegue com a execução normal. No modelo RPC, o processo de invocação ocorre de maneira similar. Uma Thread é responsável pelo controle de dois processos: invocador e servidor. O processo invocador primeiro manda uma mensagem para o processo servidor e aguarda (autobloqueia) uma mensagem de resposta. A mensagem de invocação contém os parâmetros do procedimento e a mensagem de resposta contém o resultado da execução do procedimento. Uma vez que a mensagem de resposta é recebida, os resultados da execução do procedimento são coletados e a execução do invocador prossegue.

O protocolo RPC pode ser implementado sobre diferentes tipos de protocolos de transporte, uma vez que é indiferente a maneira de como uma mensagem é transmitida entre os processos. É importante salientar que o protocolo RPC não implementa nenhuma forma de confiabilidade e que a aplicação precisa tomar cuidados quanto ao tipo de protocolo sobre o qual RPC opera. Caso se trate de um protocolo confiável, como TCP, as preocupações com confiabilidade já são resolvidas. Por outro lado, caso a camada de transporte seja não-confiável, como UDP, mecanismos de timeout, retransmissão e detecção de duplicatas devem ser implementados, uma vez que esses serviços não são providos por RPC. Devido à independência da camada de transporte, o protocolo RPC não modifica a semântica das chamadas remotas, nem seus requisitos de execução. A semântica pode ser inferida a partir da camada de transporte em uso. Por exemplo, considere o caso em que RPC opera sobre uma camada de transporte não-confiável, como UDP. Se uma aplicação retransmite mensagens de invocação RPC, após timeouts, e não recebe respostas, não pode inferir o número de vezes em que o procedimento foi executado. Se uma mensagem é recebida, ela pode inferir que o procedimento foi executado, pelo menos, uma vez. O servidor pode efetuar o controle do número de execuções, simplesmente gravando o número do último procedimento executado com êxito, evitando assim reexecuções de uma mesma chamada.

Para permitir que os servidores sejam acessados por diferentes clientes, diversos sistemas padronizados de RPC foram criados. A maioria deles usa uma linguagem de descrição de interface (IDL) para que diferentes plataformas possam chamar procedimentos. Fazendo uso de uma ferramenta como o RPCGEN, pode-se gerar interfaces entre cliente e servidor a partir de um arquivo IDL, os chamados stubs. Como os stubs são embarcados nas aplicações cliente e servidor, a RPC não é uma camada de middleware. Na codificação, o procedimento remoto do cliente chama o stub cliente como qualquer outro procedimento local, e a implementação interna do stub cliente é responsável por iniciar o processo de transmissão para stub servidor, empacotando a chamada numa mensagem. Ao chegar, o stub servidor desempacota a mensagem e invoca localmente o procedimento, aguardando o retorno. Quando a chamada local retorna, o stub servidor é responsável por iniciar o processo de transmissão para o stub cliente, empacotando a resposta numa mensagem. Chegando, a resposta é desempacotada pelo stub cliente, sendo retornada localmente para o procedimento que realizou a chamada remota.

Diferentes implementações de chamada de procedimento remoto costumam ser incompatíveis entre si, ainda que existam exceções. Por isso, o uso de uma determinada implementação, provavelmente, resultará na dependência com o fornecedor da implementação. Essa incompatibilidade entre implementações se mostra também na disponibilidade de funcionalidades, no suporte a diferentes protocolos de rede e diferentes sistemas de arquivo. A maioria das implementações não suporta P2P e ou interação assíncrona entre cliente e servidor (por definição, a chamada remota corresponde a uma chamada local do ponto de vista da aplicação, bloqueante da mesma forma). A comunicação síncrona implica a disponibilidade constante tanto do cliente quanto do servidor.