Resumo

  • Na RFC 707, James E. White propôs um Protocolo de Chamada de Procedimento comum e um ambiente de execução para reduzir a repetição de comandos e respostas nos protocolos de aplicação da ARPANET.
  • O texto relata um protótipo para um PDP-10 com TENEX, mas ressalta que chamadas remotas ainda dependem de mensagens IPC, custam mais que as locais e não representam toda forma útil de comunicação.

O protocolo também carregava um diálogo

Para renomear um arquivo, a intenção parece única. A especificação FTP de 1973 pedia, porém, dois comandos: RENAME FROM seguido de RENAME TO. O cliente precisava conduzir a sequência e lidar com as respostas. O Remote Job Entry tinha outro fluxo, no qual o servidor podia informar o andamento enquanto o trabalho continuava. Cada aplicação acabava reconstruindo sua própria gramática de pedidos, parâmetros e confirmações.

A RFC 707, A High-Level Framework for Network-Based Resource Sharing, tratou essa repetição como um problema de arquitetura. James E. White, do Augmentation Research Center do Stanford Research Institute (SRI), sugeriu mover parte dessa mecânica para uma camada comum. O programador descreveria a operação como procedimento; o ambiente de execução cuidaria do intercâmbio padronizado entre processos.

A abstração e o que havia por baixo

O Procedure Call Protocol (PCP) organizava mensagens CALL e RETURN, identificadores de transação, argumentos e resultados, e permitia mais de uma solicitação pendente. Um run-time em cada instalação prepararia o pedido, conversaria com o lado remoto e entregaria a resposta ao chamador. A proposta previa chamadas bloqueantes e não bloqueantes e até chamadas do servidor de volta ao cliente.

Isso dava uma forma mais uniforme de programar, mas não convertia a rede em memória local. O intercâmbio de mensagens continuava sendo o mecanismo real. A RFC também preservava o acesso à comunicação entre processos de menor nível: nem todo fluxo, atividade assíncrona ou diálogo de serviço cabe bem no formato de chamada e retorno.

Um sistema concreto, alcance limitado

O documento afirma que a pesquisa no ARC começou em julho de 1974, passou por três ciclos de desenho durante doze meses e produziu um protótipo de ambiente de execução para um PDP-10 rodando TENEX. A equipe diz ter desenhado, documentado e implementado o sistema; o texto descreve a versão TENEX como compatível com a especificação e dotada de um conjunto de recursos mais amplo que o apresentado.

Esse relato localiza a experiência num sistema nomeado. Não mostra quantas instalações a adotaram, se máquinas diferentes interoperaram, nem se a solução se espalhou pela ARPANET. A RFC Editor hoje classifica a RFC 707 como Legacy, com status UNKNOWN. O Datatracker observa que ela antecede o registro formal de fontes e não tem posição formal no processo atual da IETF. Essas classificações contemporâneas não são um levantamento do uso histórico.

A distância continua sendo parte da chamada

O próprio texto faz a ressalva essencial: chamadas locais são baratas; chamadas remotas não são, pois precisam de mensagens IPC. Cabe ao programador usá-las com critério. Programas distribuídos podem prosseguir de forma assíncrona, e algumas comunicações úteis não são naturalmente chamadas de procedimento. O canal de comunicação mais baixo deve continuar disponível.

Assim, a contribuição histórica documentada pela RFC 707 é uma proposta delimitada: reduzir a repetição dos diálogos de aplicação com um protocolo compartilhado e testar um run-time em TENEX. As fontes não provam que ela tenha sido implantada em toda a rede nem que tenha originado sistemas RPC posteriores. O interesse está também na fronteira que seus autores não esconderam: abstrair a chamada não é abolir o custo de executá-la à distância.

Fontes