Resumo

  • O ETFTP juntava packets em buffers e bursts para levar muitos dados numa ativação cara do canal; o receptor respondia ao buffer e enumerava somente os packets ausentes.
  • CONTROL_OK, CONTROL_RESEND, o maior CONTROL consecutivo e NULL-ACK eram recibos locais. Nenhum deles sozinho comprovava o arquivo inteiro, a identidade do par, segurança ou a causa da perda.
  • Os resultados de 1993 descreviam um arranjo ponto a ponto de 16 kbps. A própria RFC dizia que não havia validação por senha e que a segurança fora ignorada no protótipo.

O custo estava na troca de direção

No caminho tático descrito, rádio e equipamento criptográfico levavam cerca de 1,25 segundo para sincronizar antes de transmitir. A propagação via satélite acrescentava aproximadamente 500 milissegundos ao percurso de ida e volta. Como o enlace era semidúplex, cada resposta exigia desmontar um sentido e preparar o outro.

O ETFTP amortizou essa virada. Lia o arquivo em buffers, separava cada buffer em blocks, transformava blocks em DATA packets e reunia packets em bursts. LDATA marcava o último block do buffer. Em vez de confirmar packet a packet, o receptor enviava CONTROL_OK quando a unidade estava completa ou CONTROL_RESEND com o número do buffer e uma relação explícita dos packet numbers faltantes.

Esse mecanismo localizava a evidência. RESEND descrevia buracos na imagem atual do buffer. OK aceitava aquela unidade. O fim do arquivo ainda dependia da sequência distinta QUIT e DONE.

Adaptar não era diagnosticar

Cada escala tinha um efeito. Buffer maior significava menos confirmações e mais memória. Burst maior mantinha o transmissor acionado, mas podia pressionar filas intermediárias. Packet maior economizava overhead, porém tornava cada erro binário mais caro.

Se metade ou mais dos blocks exigisse retransmissão, a autoadaptação primeiro reduzia o packet size pela metade, depois diminuía o burstsize e, por fim, oferecia um burstrate próximo ao tight timer observado. Com 99% de entrega sem reenvio, o packet size podia subir. CONTROL_OK oferecia os novos valores; NULL-ACK confirmava a aceitação do remetente.

Na linguagem de Minimum Initial Specification, isso era um núcleo compartilhado estreito: buffer, packet, lista de ausência, valor e fronteira. A confirmação, contudo, não provava execução. Somente o burst seguinte revelava se os dois lados aplicaram a mudança no mesmo ponto.

Um prefixo consecutivo não era o arquivo

DATA e LDATA levavam o maior número consecutivo de CONTROL recebido. O campo dizia que um prefixo da conversa de controle fora observado sem lacunas. Não abrangia mensagens futuras, dados ainda não denunciados como ausentes, conteúdo gravado em disco nem a conclusão da transferência.

Os timers também não carregavam causalidade. O modelo dependia de baudrate informado, radiodelay fornecido ou medido e uma espera que crescia cinco segundos após cada timeout repetido. A expiração registrava uma expectativa frustrada. Não separava BER, disputa pelo meio, estouro de fila, parâmetro errado ou lentidão da aplicação. Uma lista RESEND dizia o que faltava ao receptor, não por que faltava.

Running-Code Primacy ajuda a manter a distinção: o documento estabelece o significado do recibo; packets posteriores e estado observado mostram se a transição realmente aconteceu.

O alcance termina no banco de ensaio

As tabelas usaram um arquivo de 101.306 bytes, enlace cifrado de 16 kbps, radiodelay de dois segundos e várias combinações de buffer, packet e burst. Os rádios estavam ligados por cabo coaxial, formando o que os autores chamaram de enlace “clean” com BER 10e-5. O maior resultado foi 10.432 bps com buffer de 131.072 bytes, packets de 2.048 bytes e dezesseis packets por burst; o tempo incluía conexão, recuperação e encerramento.

Isso não demonstrava uso difundido, multicast, justiça num canal partilhado ou desempenho diante de tecnologias modernas. A RFC alertou que o p-persistence máximo do ponto a ponto não serviria com mais usuários. Também deixou uma divergência: definiu packet size ajustável entre 16 e 1.448 bytes úteis, enquanto as tabelas incluíram 2.048. A divergência faz parte da fonte.

Nenhum recibo resolvia o problema de segurança. O ETFTP não validava usuário e senha, repetia as falhas de TFTP e executava um servidor experimental pertencente a root e setuid root. A RFC admite que o tema foi deixado de lado. Checksum, portas, connection ID e sequência vinculavam mensagens; não autenticavam pessoas nem autorizavam arquivos.

A contribuição histórica da RFC 1986 foi expor o preço da alternância física e transformá-lo em escolha protocolar. Uma direção longa carregava o buffer; uma resposta curta nomeava os buracos. Essa eficiência só permanece inteligível quando cada prova conserva o seu tamanho: buffer aceito, transferência fechada, causa identificada e parte autenticada são fatos diferentes.

Fontes