Resumo

  • O RFC 1235 propôs distribuição de um arquivo para muitos clientes sobre meios capazes de difusão; o projeto nasceu do boot simultâneo de estações sem disco numa rede experimental de rádio por pacotes.
  • Cada estação primeiro escutava uma transmissão em andamento. Se faltassem dados após uma pausa, pedia apenas os números dos blocos que ela própria não recebeu.

O servidor tinha uma conta simples: três estações pedem o mesmo arquivo, três transmissões individuais repetem o mesmo trabalho. John Ioannidis e Gerald Maguire Jr. publicaram o RFC 1235 em junho de 1991 para trocar a repetição por uma difusão. O meio de comunicação entregaria uma sequência de blocos a vários receptores. A economia viria dos bytes que o servidor deixaria de enviar de novo para cada máquina.

O problema imediato era o boot simultâneo de estações sem disco numa rede experimental de rádio por pacotes. Os autores também citaram atualização de software em grupo e distribuição de um objeto compartilhado numa aula eletrônica. Em todos os casos, vários clientes querem a mesma coisa. O RFC chamou esse padrão de transferência coerente. Na época, o texto via a futura disponibilidade mais ampla de IP multicast como modo de evitar que máquinas fora do grupo ouvissem uma transmissão por difusão comum.

Para entrar na transferência, a estação recebia um ticket de 32 bits ligado ao nome do arquivo, ao tamanho total e ao tamanho do bloco. Um serviço frontal adaptado de BOOTP ou TFTP poderia fazer essa associação. CFDP cuidava da distribuição dos blocos, não da tradução inicial do nome. Com o ticket, o cliente primeiro escutava: talvez o servidor já estivesse enviando o arquivo por pedido de outra estação. Se não ouvisse pacotes correspondentes dentro do prazo, enviava FULREQ e iniciava uma transmissão completa.

Os blocos saíam em pacotes UDP numerados. Cada receptor conferia o pacote e colocava os bytes na posição correta. Uma máquina podia entrar depois do início; outra podia perder um bloco no meio. Ao perceber silêncio com o arquivo ainda incompleto, cada uma mandava PARREQ com seus próprios números ausentes. O exemplo com três clientes no RFC mostra que o fluxo principal é comum, mas os mapas de faltas se separam. O servidor economiza uma cópia grande; os clientes não compartilham o mesmo histórico de recepção.

Havia espera no reparo. O servidor ignorava novas solicitações do mesmo arquivo enquanto a transmissão daquele arquivo estivesse em curso. Depois do tempo limite, o cliente tentava de novo. Os autores preferiam espaçar os pacotes a implementar controle de fluxo separado para cada participante. Sugeriram um intervalo próximo do dobro do tempo de transmissão de um pacote pela interface e relataram que, no seu ensaio, prazos de seis a oito vezes esse tempo funcionavam melhor. Uma transmissão única só é útil se os receptores conseguem acompanhá-la.

O bloco recomendado de 512 bytes mantinha o pacote abaixo dos 576 bytes de MTU mínimo IP usados no cálculo do documento. Com número de bloco de 16 bits, um arquivo lógico chegava a 32 MB; a 1024 bytes por bloco, a 64 MB. Arquivos maiores precisariam ser divididos. São limites do desenho, não uma medição do tamanho de arquivos efetivamente distribuídos.

O registro do RFC Editor mantém CFDP como Experimental. O texto menciona implementações de referência, mas não fornece uma contagem de adoção ou um resultado de boot completo. Seu detalhe histórico mais útil é o limite da economia: o servidor pode difundir um arquivo uma vez; cada estação ainda precisa demonstrar que juntou todas as peças.

Fontes