Resumo

  • Voluntários publicavam descrições estruturadas de hosts e conexões em comp.mail.maps, fornecendo ao pathalias dados para calcular rotas de correio.
  • O mapa não era uma topologia oficial em tempo real: cada site podia acrescentar informações próprias, e a exatidão dependia dos operadores que relatavam mudanças.

Uma rota podia listar máquinas sucessivas, mas alguém precisava saber quais delas aceitariam encaminhar a mensagem. Em janeiro de 1984, uma sessão Birds-of-a-Feather da USENIX reuniu mais de trinta voluntários para criar e manter um mapa UUCP. A história posterior do projeto conta que o pathalias já calculava rotas, mas faltava um mapa completo como entrada. Os participantes chamaram a iniciativa de UUCP Project e começaram a publicar atualizações regionais no grupo da Usenet comp.mail.maps. Quando o financiamento inicial da USENIX terminou, o trabalho continuou de forma voluntária.

O mapa não era um roteador central que escolhia o caminho de todas as máquinas. Cada entrada descrevia um site: nome do host, organização, contato, equipamentos, conexões e o custo ou a frequência informados pelos responsáveis. Um README reproduzido, datado de julho de 1985, explica que o pathalias processava o mapa compartilhado junto com um arquivo local Path.*. Assim, cada instalação calculava suas próprias rotas. O documento comum indicava conexões possíveis; as condições e decisões locais determinavam quais entrariam no caminho calculado.

As conexões tinham custos bem diferentes. Algumas usavam uma rede local ou circuito dedicado; outras dependiam de uma ligação urbana, uma chamada interurbana ou uma discagem noturna. O README atribuía custos aproximados ao pathalias com base sobretudo no tempo decorrido, não apenas na velocidade. Um enlace mais lento, mas frequente, podia ser preferível a outro rápido e caro. O cálculo modelava o custo de transportar correio; não media latência IP nem garantia que o destino estivesse acessível naquele momento.

Os mantenedores também restringiam o que publicar. Organizações com muitas máquinas internas eram incentivadas a listar alguns gateways e guardar os detalhes locais em um suplemento privado. A regra era registrar hosts alcançáveis pela UUCP, não qualquer computador da rede interna. A entrada servia aos programas de correio e a quem procurava um contato. Não provava uma ligação IP direta, um serviço em funcionamento ou participação na Internet global.

Um artigo australiano de 1988 mostra um uso concreto. Desde 1986, informações dos nós ACSnet eram reunidas no arquivo aus.map, mantidas em um host identificado e parcialmente adaptadas para a distribuição mundial da UUCP. Na Universidade de Sydney, scripts coletavam as mensagens da Usenet, descompactavam arquivos e montavam um índice pesquisável. O mapa respondia a perguntas que os arquivos de estado da rede não cobriam, como quem operava um computador ou qual Unix ele usava. O autor o descreve como complemento, não substituto desses arquivos.

As 266 entradas citadas eram do ACSnet, não da rede mundial UUCP. O artigo também registra a dificuldade de obter dados de novos nós: uma máquina silenciosa podia estar temporariamente fora do ar ou já ter desaparecido. Algumas relações de troca de notícias eram consideradas as informações menos confiáveis do mapa. Uma descrição compartilhada facilitava observar a rede, mas não eliminava a incerteza sobre quem ainda existia.

Em novembro de 1990, um post na Usenet mostrou um ciclo local mais automatizado: coletar comp.mail.maps, descompactar os arquivos, rodar o pathalias diariamente pelo cron, atualizar um arquivo local de rotas e avisar o administrador por email quando houvesse erros. A automação reduzia o intervalo entre publicação e uso, mas não tornava os registros verdadeiros por definição. Em uma discussão de 1987 sobre redirecionamento dinâmico, participantes alertaram que as bases de rotas não eram atualizadas a tempo de garantir que intervenções não criassem loops.

A realização não foi produzir um mapa central definitivo. Foi dividir o trabalho: voluntários reuniam descrições, a Usenet transportava atualizações, scripts locais as processavam e cada site calculava rotas segundo as próprias condições. A rede de armazenamento e encaminhamento se tornou mais legível sem fingir que um arquivo público substituía o conhecimento operacional de cada conexão.

Fontes