Resumo

  • O XMODEM compartilhava somente um bloco de 128 bytes, número e complemento do bloco, uma verificação simples, respostas ACK/NAK conduzidas pelo receptor e um encerramento por EOT. Não controlava a chamada, o disco nem a experiência do usuário.
  • Essa limitação baixou o custo de implementações independentes e tornou os problemas observáveis. O checksum era fraco, a espera após cada bloco perdia eficiência com latência e faltavam metadados, mas sucessores podiam melhorar esses pontos sem exigir uma plataforma única.

O receptor dá a partida

O gesto inicial do XMODEM vem de quem recebe. Depois de um intervalo sem dados, o programa receptor envia NAK para anunciar que está pronto. O emissor responde com SOH, número do bloco, complemento de um desse número, 128 bytes de dados e um checksum. O receptor refaz a conta: ACK aceita; NAK pede repetição.

O número começa em um e avança a cada bloco. O complemento oferece uma conferência barata do cabeçalho. O checksum soma os bytes de dados e descarta o excesso. Quando o arquivo termina, o emissor envia EOT e espera o último reconhecimento.

Essa sequência não diz qual número telefônico chamar, onde procurar o arquivo, que nome conservar, quem pode entrar nem qual mensagem mostrar na tela. O protocolo começa depois de a conexão existir e termina antes de o produto ficar completo. Sua autoridade alcança apenas os bytes que os dois programas precisam interpretar do mesmo modo.

Os 128 bytes tinham uma origem material: o setor de disco do ambiente CP/M em que Christensen trabalhava. Um tamanho fixo facilitava buffers e rotinas em computadores pequenos. Em compensação, o último bloco precisava de preenchimento, e a extensão original não levava por conta própria o tamanho exato do arquivo.

Quando a repetição significa sucesso anterior

Uma confirmação danificada cria uma dúvida. O primeiro bloco pode ter chegado perfeitamente, mas o ACK de volta se perde. Sem saber disso, o emissor repete. O receptor então vê novamente o número que acabou de processar.

A regra do XMODEM trata esse bloco anterior como repetição recuperável. O receptor confirma de novo, mas não grava uma segunda cópia dos dados. Um número que não seja o esperado nem o imediatamente anterior indica outro tipo de perda de sincronismo e pode exigir cancelamento.

O acordo resolve uma ambiguidade limitada sem consultar uma fonte central da verdade. Basta a memória do estado anterior, o número recebido e uma resposta determinada. Confiabilidade, aqui, não significa impedir todo ruído; significa que duas implementações independentes reagem de maneira compatível ao mesmo ruído.

Christensen recordou o trabalho de 1977 como uma solução improvisada para uma necessidade pessoal. Afirmou também que concluí-lo cedo e colocá-lo imediatamente em domínio público ajudou a torná-lo um padrão. É a memória do autor, não um teste causal. Ainda assim, a economia é plausível: código curto podia ser copiado, lido, adaptado a outra máquina e testado contra um par sem permissão de um dono de rede.

Um padrão de fato, não uma norma criada por RFC

O XMODEM não nasceu como padrão do IETF. Em 1984, o RFC 916 propôs outro protocolo confiável para comunicação assíncrona e incluiu MODEM/XMODEM no apêndice porque já era comum entre microcomputadores. O documento observou uma prática que se espalhara por implementações.

Ele registrou limitações concretas. Os dados fluíam numa direção, o pacote era fixo em 128 octetos e alguns concentradores intermediários tinham dificuldade até com rajadas menores. A parada para aguardar ACK depois de cada bloco desperdiça mais capacidade conforme cresce o tempo de ida e volta. O checksum de oito bits não encontra todo padrão de corrupção.

Ser pequeno não tornou o protocolo ideal para qualquer rede. Tornou seus compromissos localizáveis. Era possível medir repetição, vazão, falhas da verificação e tratamento do bloco final. Num serviço que mistura identidade, armazenamento, busca e transferência, localizar a origem de um fracasso costuma ser muito mais difícil.

Extensões precisavam funcionar com alguém

Convenções posteriores acrescentaram CRC-16, blocos opcionais de 1K e um bloco zero para informações como nome e tamanho. Programas públicos de Chuck Forsberg ajudaram essas práticas a viajar sob nomes como YMODEM. A base reconhecível permitia introduzir uma capacidade sem redesenhar tudo.

Christensen resistia a colocar no núcleo transmissão full duplex, vários blocos ainda não confirmados ou múltiplos destinos. Não era uma condenação de transferências mais sofisticadas. Ele via na simplicidade extrema uma causa da sobrevivência do protocolo em tantas máquinas e aplicações. Se a novidade declara todos os pares existentes inválidos, ela também decide unilateralmente quem controla o piso comum.

A adoção voluntária, porém, não impediu confusão. Referências da época alertam que produtos chamados YMODEM podiam exibir comportamentos incompatíveis. O nome não demonstrava nada. A compatibilidade precisava passar por proposta, código executável, arquivos de teste, implantação limitada, observação de erros, rótulos de capacidade e documentação fiel.

CBBS oferecia o lugar que o bloco não oferecia

Após a nevasca de Chicago em 1978, Christensen e Randy Suess criaram o CBBS: Suess cuidou do hardware, Christensen do software. O sistema atendia chamadas, guardava mensagens e formava um lugar social ao qual as pessoas voltavam. Esse episódio situa o XMODEM no mundo da cultura discada, mas não faz parte do formato do bloco.

O BBS era um serviço; XMODEM era uma passagem para o arquivo. Manter essa diferença permitiu que quadros de avisos, terminais e rotinas locais variados incorporassem transferência sem se transformar em clientes de uma única plataforma. A linha comum podia ser uma, enquanto os produtos permaneciam muitos.

O número 128 não é uma receita eterna. O legado está no método de delimitação: exigir identidade de comportamento onde a interoperabilidade precisa dela e manter escolhas locais onde ela não precisa. As pontas não eram livres para ignorar ordem, verificação e término. Eram livres para continuar diferentes em todo o resto.

Fontes