Um mecanismo muito genérico de aplicações cliente-servidor é disponibilizado pelo pacote RPC Chamada de Procedimento Remoto9.6. Ele foi desenvolvido pela Sun Microsystems e é uma coleção de ferramentas e bibliotecas. Aplicações importantes construídas sobre a RPC são NFS - Sistemas de Arquivos em Rede e NIS - Sistemas de Informações em Rede, ambos os quais serão melhor descritos em capítulos posteriores.
Um servidor RPC consiste de uma coleção de procedimentos que um cliente utiliza enviando uma solicitação RPC ao servidor, junto com os parâmetros do procedimento. O servidor irá acionar o procedimento indicado pelo cliente, retornando para aquele os valores obtidos, caso haja algum tenha sido retornado pelo programa acionado. Para tornar este serviço independente de plataforma, todos os dados trocados entre o cliente e o servidor são convertidos para o formato XDR - Representação Externa de Dados pelo emissor e convertido para a representação da plataforma local pelo receptor.
Algumas vezes, melhorias em uma aplicação RPC podem introduzir incompatibilidades na interface RPC. Obviamente, uma simples mudança do servidor pode trazer problemas para todas as aplicações que esperam o comportamento original. De qualquer forma, programas RPC têm números de versão definidos, normalmente iniciados por 1, e onde cada nova versão da interface incrementa a versão como em um contador. Freqüentemente, um servidor é oferecido em diversas versões simultaneamente, permitindo que os clientes possam então indicar o número da versão desejada nas suas requisições.
A comunicação de rede entre servidores RPC e cliente é bastante peculiar. Um servidor RPC oferece uma ou mais coleções de procedimentos, onde cada conjunto é chamado por um programa e é identificado por um número de programa. Uma lista mapeando o nome do serviço para o número de programa é normalmente mantida no arquivo /etc/rpc, o qual é parcialmente apresentado na figura ![[*]](cross_ref_motif.gif)
.
Em redes TCP/IP, os autores do RPC confrontaram-se com o problema de mapeamento de números de programas com serviços genéricos de rede. A solução foi definida de forma que cada servidor atende aos protocolos TCP e UDP para uma versão específica de um determinado programa. Geralmente aplicações RPC utilizarão UDP para o envio de dados e utilizarão TCP quando os dados a serem transferidos não caibam em um único datagrama UDP.
Obviamente, programas clientes têm que encontrar uma forma de saber em qual porta o programa está mapeado. Usar um arquivo de configuração para isso poderia ser um tanto inflexível, uma vez que aplicações RPC não utilizam portas reservadas. Não haveria nenhuma garantia de que a porta originalmente definida pela base de dados seria a utilizada pelo processo. Ou seja, aplicações RPC utilizam qualquer porta que possam e as registram no denominado servidor de mapeamento de portas9.7. Este age como um negociador de serviços para todos os programas RPC em execução na máquina: um cliente que deseje contactar um serviço com um determinado número de programa, irá inicialmente contactar o servidor de mapeamento de portas do servidor, o qual retornará os números das portas TCP e UDP de serviço desejado.
Este método tem uma deficiência particular, pois introduz um ponto de falha, similar ao mesmo introduzido pelo servidor inetd de serviços de Berkeley. De qualquer forma ele é um pouco pior pois o programa portmapper pode terminar anormalmente e as informações das portas RPC serão perdidas. Isso significa que os servidores RPC deverão ser reinicializados manualmente ou ainda todo o sistema deverá ser reinicializado.
No , o portmapper é chamado rpc.portmap e reside no diretório /usr/sbin. Além de estar certo de que ele é inicializado pelo programa rc.inet2, o portmapper não requer qualquer esforço de configuração.