Resumo

  • O Cronus precisava descobrir recursos em outra LAN sem pedir aos operadores dos gateways que redesenhassem o serviço. No RFC 947, hosts selecionavam e repetiam as mensagens de descoberta.
  • Essa liberdade de configuração teve uma conta concreta: o encaminhador em um host compartilhado acordava para todo pacote UDP recebido, mesmo quando a maioria não seria retransmitida.

A pergunta que o gateway não repetia

Quando o Cronus procurava um recurso, nem sempre sabia a qual computador pedir. Uma difusão local permitia fazer a pergunta a vários hosts e reunir informações sobre servidores. Ao distribuir os participantes por redes físicas distintas, surgiu um paradoxo operacional: os gateways podiam levar tráfego até um endereço conhecido, mas a pergunta necessária para descobrir esse endereço ficava presa à Ethernet de origem. Sem algum mecanismo adicional, uma parte do sistema podia continuar alcançável e, ainda assim, invisível para a busca de recursos.

Ken Lebowitz e David Mankins descreveram essa dificuldade e a solução testada no RFC 947, de junho de 1985. O Cronus usava TCP e UDP. Muitas de suas difusões interessavam apenas a uma parcela dos hosts que as ouviam. Os autores consideravam a multidifusão mais adequada a esse público restrito, mas ela não estava disponível em algumas implementações de rede usadas por eles. O problema prático, portanto, era prolongar uma ferramenta existente sem obrigar a infraestrutura comum a adotar uma função especializada.

O encaminhador ficava num host da LAN de origem. Entre os pacotes UDP difundidos localmente, escolhia apenas os que correspondiam a portas ou endereços de destino configurados. A escolha, portanto, acontecia antes de atravessar a rede.

Ao iniciar, lia um arquivo com os endereços dos repetidores remotos e as classes de pacote destinadas a cada um. Tentava abrir uma conexão TCP com cada repetidor; se ela falhasse, tentava de novo periodicamente. O pacote escolhido seguia encapsulado numa mensagem para o outro lado.

Na LAN distante, o repetidor o emitia usando o endereço local de difusão e preservava o endereço de origem do pacote inicial. O percurso inteiro precisava funcionar, mas a decisão sobre o que levar continuava nas mãos de quem configurava o Cronus.

O mesmo arquivo podia indicar um host que não fosse repetidor. Nesse caso, o encaminhador trocava o destino de difusão pelo endereço desse host e enviava um datagrama unicast. A alternativa evidencia o caráter seletivo da solução. O trajeto podia atravessar gateways, mas quem escolhia quais mensagens mereciam atravessá-lo e como seriam entregues no fim eram os processos configurados nos hosts.

Por que não instalar o recurso no gateway?

Os autores analisaram essa opção expressamente. Os gateways precisariam manter tabelas de destinatários e receber atualizações por uma extensão do protocolo de controle. A distinção entre mensagens úteis e inúteis poderia depender de informação de uma camada mais próxima da aplicação. Também não havia garantia de que gateways de outros fabricantes incluíssem a função. Havia, por fim, um descompasso de administração: o responsável pelo gateway subjacente podia ser diferente de quem alterava a configuração do Cronus. Colocar o repetidor no equipamento de rede mudaria quem tinha condições de ajustar o serviço.

O núcleo do Cronus apresentava outro custo. Todos os núcleos participantes teriam de conhecer os endereços dos demais, impondo limites à flexibilidade da configuração, e o mecanismo ficaria mais específico àquele sistema. Escolher processos em hosts não eliminava compromissos; apenas os situava onde o aplicativo podia governá-los.

Reenviar uma difusão também abre caminho para que ela volte ao próprio encaminhador. Para reduzir esse risco, o processo não estabelecia conexão com um repetidor na mesma LAN e recusava pacotes cuja origem não pertencesse à LAN de onde ele encaminhava. São as precauções documentadas, sem prova de ausência de todo ciclo ou de autenticação do remetente. A preservação do endereço de origem exigiu ainda uma capacidade especial na implementação TCP/IP da BBN, permitindo que processos privilegiados enviassem com o endereço de outro host. O campo preservado não certificava identidade.

Um êxito com limites e custos visíveis

O arranjo relatado ligava duas Ethernets fisicamente separadas por outras duas LANs. As mensagens passavam por pelo menos dois gateways. Os processos foram executados num VAX com 4.2BSD UNIX e software de rede da BBN; segundo os autores, a extensão havia funcionado por alguns meses para os seus fins. Esse testemunho descreve uma configuração, não a difusão do método pela Internet nem uma avaliação independente de desempenho.

O texto é mais preciso sobre o custo. O encaminhador em espaço de usuário acordava quando qualquer pacote UDP chegava ao host compartilhado e só então descartava os que não precisava repetir. Os autores discutiram transferir a filtragem para o núcleo, mantendo a configuração e o reenvio no programa de usuário. Planejavam, alternativamente, levar o serviço a um microcomputador de tempo real dedicado. O RFC não relata a conclusão de nenhuma dessas mudanças.

O RFC 919 já observava que cada host que recebe uma difusão tem trabalho a fazer; o RFC 922 tratava da difusão IP com sub-redes. O caso Cronus acrescenta uma distinção operacional: ampliar o alcance exige escolher tráfego, atribuir autoridade para essa escolha e pagar pela inspeção. O posterior RFC 1112, sobre multidifusão IP, não documenta o destino dessa instalação específica.

Fontes