Resumo

  • A RFC 977 tratou o artigo duplicado como um custo dependente do enlace: pares interativos podiam comparar o que já tinham antes de enviar o texto.
  • A mesma RFC manteve o envio seguido do descarte de duplicatas nos enlaces UUCP de transação única, em que um lote podia terminar antes de uma negociação.

Em fevereiro de 1986, Brian Kantor e Phil Lapsley publicaram a RFC 977, proposta do Network News Transfer Protocol. A ideia mais reveladora não era fazer um transporte dominar a Usenet. O custo de uma duplicata dependia da conexão que a carregava. Em um fluxo interativo, dois computadores podiam comparar suas coleções e decidir o que enviar. Em um enlace que só abria uma vez por dia, a conversa necessária para decidir poderia demorar mais que a própria duplicata.

O método tradicional descrito pela RFC propagava notícias por inundação: cada site enviava artigos novos aos servidores que alimentava, e eles os repassavam adiante. Um servidor com duas fontes podia receber o mesmo artigo duas vezes. Em uma transferência agendada ou de transação única, o remetente não conseguia parar facilmente para perguntar se o destinatário já tinha o artigo. O destinatário recebia o lote e apagava os repetidos depois. Isso consumia tempo e capacidade de comunicação, mas mantinha a sessão simples.

O NNTP acrescentou uma conversa prévia. O cliente podia perguntar quais grupos eram novos, consultar os identificadores dos artigos nos grupos de seu interesse e solicitar os que ainda não possuía. Na direção inversa, um host podia informar ao vizinho os artigos que acabara de receber; o servidor identificava os que já estavam em sua coleção e os que ainda deveria enviar. O corpo do artigo deixou de ser a primeira prova de que a mensagem havia atravessado o enlace: os hosts podiam comparar identificadores antes.

A escolha dependia do caminho. A RFC 977 diz que hosts bem conectados por uma rede local ou outro enlace rápido poderiam distribuir notícias com mais eficiência pelo NNTP que por métodos tradicionais como o UUCP. Mas também explica a lógica dos lotes do UUCP: em uma conexão de transação única, sobretudo quando só havia uma sessão diária, enviar tudo e deixar o receptor descartar duplicatas podia reduzir o tempo total. Negociar de forma interativa não era sempre mais barato apenas por transmitir menos bytes.

A RFC descreve outro uso que não deve ser confundido com a troca entre sites. Uma universidade ou empresa podia manter um spool central de notícias e deixar estações de trabalho acessá-lo pela rede local. Os leitores selecionavam o que queriam em um armazenamento compartilhado, sem guardar uma cópia completa em cada máquina. Um servidor intermediário também podia armazenar em cache artigos consultados recentemente. Era uma arquitetura de acesso e armazenamento local, não uma base central única para toda a Usenet.

A RFC 850 já havia padronizado o formato dos artigos USENET, mas deixava flexíveis os métodos de transmissão: cada site escolhia equipamento, software e envio em lote. A RFC 977 trabalhou nesse ambiente diverso. Especificou um fluxo confiável para consultar, recuperar, publicar e trocar artigos, ao mesmo tempo que reconhecia a vantagem de outro transporte nas linhas intermitentes. A proposta era condicional: conversar quando a rede suportasse; manter os lotes quando economizassem tempo.

Esses documentos comprovam uma decisão de projeto, não uma migração universal. A RFC 977 não informa que parcela da Usenet adotou NNTP em 1986, não mede a economia de banda e não prova que toda implementação evitava duplicatas. Sua contribuição é mais estreita: a seleção de artigos virou uma troca entre pares, para que o destinatário pudesse dizer o que queria e o que já possuía antes de receber outra cópia.

Fontes: RFC 977, Network News Transfer Protocol; RFC 850, formato de intercâmbio de mensagens USENET; RFC 1036, formato de intercâmbio de mensagens USENET.