Resumo

  • O RFC 966 propôs um endereço para um conjunto de hosts com participação dinâmica. O cliente poderia procurar um serviço sem ter a lista atual de servidores.
  • O grupo era aberto para remetentes de fora. Enviar ao grupo, encontrar um membro e obter uma resposta continuavam sendo resultados distintos.

O usuário não chegava a abrir um arquivo ou aplicativo: sem encontrar o servidor de inicialização, sua estação sem disco parava antes dessa etapa. Para o operador, a troca de uma só máquina podia se transformar em uma busca por todos os clientes presos ao endereço anterior. Reconfigurar cada um exigia trabalho; recorrer a broadcast fazia hosts sem resposta processarem a pergunta. No RFC 966, de dezembro de 1985, Steve Deering e David Cheriton sugeriram um endereço para a função procurada, não para o servidor de ontem. O grupo poderia até ficar vazio: a proposta preservava o lugar de perguntar, não a certeza de atendimento. Era um projeto aberto à discussão, não um levantamento de implantação.

Havia duas tarefas nessa mesma proposta. A primeira era física: uma única mensagem poderia chegar a vários membros do grupo, poupando cópias enviadas pelo cliente. A segunda era de descoberta: o cliente podia mandar a pergunta ao endereço do grupo sem saber qual servidor possuía a resposta. A multidifusão transportaria a pergunta; a chamada ligação distribuída ocorreria quando um servidor capaz de atender se identificasse pela resposta. O texto cita grupos permanentes de servidores de nomes e de inicialização. Num exemplo, vários servidores recebem a pergunta por um arquivo, e aquele que reconhece o nome responde diretamente. É um exemplo de projeto, não a prova de que um serviço específico tenha funcionado dessa maneira.

O endereço de grupo e a população do grupo não tinham o mesmo tempo de vida. A proposta permitia até zero membros, deixava um host participar de vários grupos e previa grupos temporários que terminariam com a saída do último integrante. As operações CreateGroup, JoinGroup e LeaveGroup descreviam essas mudanças. Um identificador permanente poderia manter a função inteligível ao cliente mesmo que nenhum servidor estivesse presente naquele instante. Estabilidade do nome não significava disponibilidade.

O adjetivo aberto não dispensava todos os controles. Significava que um remetente não precisava ser integrante para enviar um datagrama ao grupo. Caso contrário, a estação procurando um servidor de inicialização teria de fingir que já era um deles. O RFC tratava à parte da restrição de participação por uma chave de acesso. Entrar como receptor, enviar como cliente e ter uma solicitação aceita pela aplicação são decisões com provas diferentes.

Havia uma conta operacional por trás da conveniência. Os gateways precisariam manter registros das redes com membros ativos e disseminar mudanças. O próprio RFC reconhecia que a consistência desses registros distribuídos ainda era um problema aberto. Os autores desejavam que algumas transmissões repetidas não deixassem sistematicamente um membro sem receber, qualidade chamada cobertura. Mesmo assim, a notificação de falha era uma dica, não um comprovante obrigatório. Um pacote endereçado ao grupo não demonstrava que todos o receberam ou que o serviço trabalhou.

O RFC 988 substituiu a proposta em 1986 e formulou uma regra esclarecedora: num grupo permanente, permanente é o endereço, não o conjunto de participantes. O RFC 1112, de 1989, manteve a diferença e descreveu a entrega como melhor esforço, sem garantia de chegada íntegra a todos ou de ordem igual. A sequência mostra a continuidade da ideia, não a implantação universal do desenho inicial.

O avanço histórico foi poder publicar onde fazer uma pergunta sem fixar quem responderia. A rede passou a acomodar um serviço cujo elenco muda, mas deixou para evidências separadas a participação atual, o encaminhamento e a resposta recebida.

Fontes e limites

Este relato usa somente os originais RFC 966, RFC 988, RFC 1112 e o antecedente sobre broadcast RFC 919. Eles não medem primeiro uso, taxa de adoção ou sucesso de uma aplicação particular.