Resumo

  • Um ACK que cruzava a retransmissão podia fazer os dois lados repetirem seus pacotes atuais e levar a duplicação adiante pelo restante da transferência.
  • O RFC 1123 mandou o emissor DATA ignorar ACKs duplicados; o risco era o congestionamento impedir a conclusão, não alterar um arquivo já recebido por inteiro.

A economia de um bloco por vez

Em 1981, a segunda revisão do Trivial File Transfer Protocol estabeleceu uma troca deliberadamente pequena: um cliente pede a leitura ou a gravação de um arquivo, recebe blocos de dados e confirma cada um. O tamanho padrão era de 512 bytes. O emissor mantinha apenas o bloco em andamento, e o receptor indicava que podia seguir. Isso limitava memória e simplificava a implementação, características valiosas para uma máquina que precisava buscar o próprio sistema antes de estar plenamente inicializada.

Em 1989, o RFC 1123 descreveu a inicialização em rede local como o uso principal do TFTP e observou que sua pequena implementação cabia em EPROM. BOOTP podia entregar os parâmetros de configuração e o TFTP transportar a imagem. Essa proximidade operacional não tornava os dois protocolos intercambiáveis: uma configuração correta não garantia que o arquivo chegaria sem sofrer os efeitos do atraso.

Como o TFTP usava UDP, a aplicação precisava decidir quando repetir um pacote. Se o ACK esperado não chegasse dentro do prazo, o DATA pendente podia ser enviado outra vez. Uma perda era o caso simples. A dificuldade surgia quando o pacote continuava a caminho e só chegava depois do timeout.

Quando um ACK velho muda o estado atual

Considere A enviando DATA 20 e B respondendo ACK 20. O primeiro ACK atrasa. A repete DATA 20; B reconhece que já recebeu o bloco e envia ACK 20 de novo. O primeiro ACK finalmente chega, então A avança para DATA 21. Quando o segundo ACK antigo chega, a regra original manda A retransmitir o DATA que está mantendo agora, o bloco 21. B recebe duas cópias e gera dois ACKs 21. Um ACK que atravesse a próxima mudança de bloco pode provocar a repetição do DATA 22.

O efeito não é simplesmente reproduzir um pacote perdido. Uma resposta antiga é aplicada ao estado novo de cada ponta. A duplicação passa a produzir outra duplicação. Robert Braden deu a esse padrão o nome de “Sorcerer’s Apprentice syndrome” no RFC 1123. Seu exemplo afirma que os pacotes restantes podem ser duplicados até que a perda de um datagrama interrompa a cadeia.

Isso ameaça a conclusão do arquivo, não necessariamente sua integridade. O RFC diz que um arquivo transferido até o fim permanece correto. Mas a sequência de pacotes desperdiça capacidade e prolonga a transferência; sob atraso e congestionamento, o emissor pode acabar desistindo por timeout. O protocolo era confiável no sentido de retransmitir, mas a própria regra de retransmissão podia piorar a possibilidade de terminar.

A rede passa a alimentar o problema

A rede podia criar um ciclo de realimentação. Congestionamento alongava a demora do ACK; o timeout produzia DATA extra; esses DATA provocavam mais ACKs e ocupação do caminho. O RFC advertia sobre congestionamento adicional e novos atrasos. Isso não demonstra que toda transferência lenta sofria a síndrome nem atribui a ela uma interrupção histórica específica: identifica um mecanismo que depende da sequência de estados.

O mesmo documento exigia timers adaptativos e recomendava backoff exponencial, mas ajustar prazos não eliminava a causa. A correção normativa era mais precisa: o emissor DATA não deveria retransmitir o bloco atual ao receber um ACK duplicado. Assim, um ACK antigo deixava de ordenar uma nova cópia do bloco seguinte. O receptor podia até dispensar seu timer de ACK, embora pudesse mantê-lo para substituir uma confirmação realmente perdida; o emissor ainda precisava do timer de retransmissão.

Corrigir uma resposta, preservar o desenho

Em maio de 1992, Noel Chiappa incorporou a correção à revisão do protocolo. O RFC 1350, publicado em julho, substituiu o RFC 783 e registrou esse trabalho. A ordem importa: os requisitos para hosts de 1989 já definiam a reação obrigatória; a revisão posterior consolidou a mudança na especificação do TFTP. Essas datas não comprovam quando cada implementação mudou.

As opções posteriores atacaram outra limitação. Blocos maiores e uma janela de vários blocos em trânsito elevam o desempenho quando parar a cada ACK é caro. Não substituem a regra contra responder a um ACK duplicado com o DATA atual. O caso mostra que uma arquitetura mínima pode economizar espaço no pacote e concentrar o risco nas transições de estado. A solução preservou o modelo de um bloco por vez e retirou uma resposta que tornava a repetição contagiosa.

Sources