Resumo

  • O conflito era entre mudança e previsibilidade: o servidor podia escolher uma porta livre, mas o cliente precisava saber onde chamá-lo; reservar uma porta fixa para cada programa transferiria a coordenação para o espaço compartilhado de portas.
  • O portmapper da RFC 1057 criou um ponto local estável para consultar o destino escolhido. A resposta confirmava um registro naquela máquina, não a disponibilidade do serviço nem a identidade de quem atendia.

O serviço podia mudar de porta; a consulta, não

Considere uma situação hipotética: após reiniciar o serviço de arquivos, o servidor escolhe outra porta livre e um cliente continua tentando a antiga. O programa pedido continua o mesmo, mas a chamada já não sabe onde encontrá-lo. Exigir um número fixo para cada programa evitaria essa surpresa ao custo de coordenar uma lista crescente em um espaço compartilhado e limitado. A tensão entre destino móvel, ponto de consulta estável e verificação da resposta é a questão arquitetural que este mecanismo deixa visível; isso não implica uma linhagem direta para sistemas posteriores.

A RFC 1057, publicada pela Sun Microsystems em junho de 1988, documentou outra organização. O número e a versão do programa indicavam o serviço desejado; TCP ou UDP indicava o transporte. Um portmapper local, acessível pela porta conhecida 111, associava esses identificadores à porta escolhida pelo servidor. O cliente consultava o mapper primeiro e só então contatava o serviço. A chamada RPC e a descoberta do destino eram etapas separadas.

PMAPPROC_SET registrava o serviço. O servidor informava ao mapper da mesma máquina o número do programa, a versão, o protocolo de transporte e a porta de escuta. O mapper recusava uma segunda entrada para a mesma combinação de programa, versão e protocolo. Quando o serviço terminava, PMAPPROC_UNSET removia o registro. O cliente consultava PMAPPROC_GETPORT; o valor zero significava que não havia entrada para aquela combinação.

A divisão de trabalho era curta: o serviço escolhia onde escutar, o mapper tornava essa escolha consultável em um endereço previsível, e o cliente usava a porta recebida. A instância podia mudar de lugar enquanto o ponto de consulta permanecia conhecido.

O que a resposta não confirmava

A resposta do mapper refletia apenas o registro em sua tabela local. A RFC 1057 não transforma GETPORT em um teste de saúde de ponta a ponta, prova de que a rota está aberta ou declaração criptográfica sobre o processo na porta. O cliente ainda precisa se conectar, fazer a chamada RPC e interpretar a resposta. Se o serviço parar e a entrada permanecer, a consulta pode funcionar e a conexão seguinte falhar. Se o registro não existir, há um problema de vinculação do serviço.

“Encontrado” soa mais definitivo que “registrado”. O número da porta informa onde o serviço foi cadastrado para escutar; não garante que os pacotes chegarão, que o serviço aceitará aquele cliente ou que a rotina solicitada será executada. A RFC trata autenticação e semântica do transporte separadamente. O portmapper não substitui nenhuma delas.

A tabela tampouco era um registro global de programas RPC. Ela ficava na máquina que hospedava o serviço. O cliente precisava obter o endereço da máquina de outra fonte e então perguntar ao mapper local qual porta usar. A descoberta ficava repartida entre camadas: nome ou configuração fornecia o host; número e versão selecionavam a interface; o mapper entregava o destino de transporte.

A RFC também especificou PMAPPROC_DUMP, para listar os registros, e PMAPPROC_CALLIT, para apoiar chamadas em broadcast. O cliente enviava o pedido ao endereço de broadcast na porta fixa do mapper. Cada mapper que o recebesse podia chamar o serviço registrado localmente. A especificação dizia que só haveria resposta se a execução fosse bem-sucedida; caso contrário, o mapper ficava em silêncio. Isso permitia tentar o mesmo serviço em máquinas com portas diferentes, mas não garantia entrega nem fornecia a lista completa de todos os que receberam o pedido.

Os números de programa também tinham uma divisão de coordenação. A RFC 1057 separou faixas definidas pela Sun, por usuários, transitórias e reservadas. O identificador lógico não precisava ser o mesmo que o porto de transporte variável: um número nomeava o programa RPC, enquanto outro valor, resolvido localmente, apontava onde a instância ativa escutava.

Da porta TCP/UDP ao endereço universal

A versão inicial do portmapper lidava diretamente com portas TCP e UDP. Em 1995, a RFC 1833 descreveu a versão 2 do Port Mapper e as versões 3 e 4 do RPCBIND. A necessidade permanecia: o servidor podia escolher seu endereço de transporte dinamicamente, mas o cliente precisava de um ponto de consulta conhecido no endereço do servidor. O RPCBIND representava endereços de transporte como cadeias universais e incluía um identificador de rede, ampliando a vinculação além dos portos TCP/UDP.

Esse documento posterior ajuda a delimitar a escolha de 1988. A RFC 1057 não prendia um programa RPC a um único porto. Ela definia um ponto de encontro para associar programa e versão a uma escuta específica do transporte. A RFC 5531, posterior, também separa o protocolo das mensagens RPC dos mecanismos de vinculação e rendezvous.

O benefício era preciso: com uma convenção comum de consulta, o cliente não precisava conhecer antecipadamente a porta do serviço. Isso economizava portas fixas e deixava cada instância escolher localmente. Em troca, acrescentava uma conversa antes da chamada e exigia um estado que acompanhasse a inicialização, o registro, a parada e a remoção do serviço.

As RFCs descrevem o desenho, não a escala de implantação histórica nem sua confiabilidade medida. Elas não dizem quantos registros obsoletos ocorreram ou quanto tempo sistemas específicos levaram para corrigi-los. A conclusão segura é arquitetural: o portmapper tornava um destino RPC localizável por meio de um ponto estável na máquina; alcance, autenticação e execução continuavam dependendo dos passos seguintes.

Documentos primários: RFC 1057 — RPC versão 2; RFC 1833 — protocolos de vinculação para ONC RPC; RFC 5531 — ONC RPC versão 2.