Resumo

  • A RFC 913 propôs modos ASCII, Binary e Continuous para um protocolo simples de transferência de arquivos. Uma página TOPS-20 com 512 palavras de 36 bits gera, nos exemplos do texto, 2560, 2048 e 2304 bytes de oito bits.
  • Binary envia quatro bytes de cada palavra e deixa os quatro bits finais; Continuous atravessa as fronteiras entre palavras e leva toda a sequência. A conclusão do transporte depende do fluxo escolhido, não garante que todas as unidades de armazenamento tenham viajado.

O programa informa que terminou. Ótimo: terminou de mandar o quê? Em setembro de 1984, Mark Lottor colocou a pergunta dentro da RFC 913. Seu Simple File Transfer Protocol, um SFTP antigo no TCP 115, não era o protocolo posterior associado a SSH apesar da sigla igual. A proposta queria algo mais útil que TFTP e mais fácil de implementar que FTP, usando uma conexão TCP. Havia acesso por usuário, conta e senha, além de operações com diretórios e arquivos. A palavra que decidia a carga era TYPE.

O exemplo escolhe uma máquina TOPS-20. Cada palavra de armazenamento tem 36 bits; uma página contém 512 palavras, totalizando 18 432 bits. Em ASCII, a palavra fornece cinco caracteres de sete bits. São 35 bits de texto; o último fica de fora. Cada caractere viaja num byte de oito bits com o bit superior zerado, e os finais de linha locais viram CRLF pelas regras NETASCII. Multiplique cinco por 512 e saem 2560 bytes. Para transportar texto entre sistemas diferentes, esse tratamento pode ser o objetivo. Para preservar todos os bits da página, é a escolha errada.

Binary parece prometer a cópia integral, mas a descrição é mais específica. O modo tira quatro bytes de oito bits de cada palavra de 36: 32 bits seguem, quatro ficam. A página, então, tem 2048 bytes transmitidos. A importância dos bits ausentes depende de como aquele arquivo foi gravado; o documento não relata uma perda ocorrida em determinada instalação. Mostra que “binário” não é sinônimo de “todos os bits da palavra”. A etiqueta descreve unidades de transporte. Se a origem guardava informação nos quatro bits restantes, eles não entraram no pacote.

Continuous resolve a questão de outra maneira. Desenrola as palavras como uma fita única e encaixa a ponta de uma na seguinte: os quatro bits restantes da primeira palavra juntam-se aos quatro iniciais da segunda para formar um byte. Assim, os 18 432 bits da página viram 2304 bytes de oito bits. Em computadores cujas palavras já têm largura múltipla de oito, a RFC espera que Binary e Continuous sejam iguais. No TOPS-20, a diferença é concreta. Um modo seleciona quatro bytes por palavra; o outro não deixa a borda da palavra decidir o que pode passar. O destino ainda precisará interpretar a sequência que recebeu.

O protocolo tornava essa decisão fácil de esquecer. Comandos tinham quatro letras ASCII e terminavam em NUL. Sem TYPE explícito, valia Binary. Depois do acesso, o servidor podia listar, mudar e renomear diretórios, excluir, receber e enviar arquivos. Tudo podia correr normalmente: conexão estável, resposta positiva, número exato de bytes. O defeito possível estava antes da viagem, no acordo sobre qual representação o programa deveria produzir. A confirmação do servidor fechava a operação; não assinava um atestado sobre cada bit da fonte.

A ficha do RFC Editor hoje classifica a proposta como histórica. Os três tamanhos são exemplos aritméticos, não estatísticas de arquivos danificados. Mesmo assim, uma página que pode chegar como 2560, 2048 ou 2304 bytes dá uma lição bastante prática. O significado do arquivo é decidido entre o disco de origem, o modo de transferência e o software de destino. Quatro bits podem perder a viagem sem que a rede tenha atrasado um segundo.