Resumo

  • O Kermit surgiu na Columbia em 1981 para atender à troca de arquivos entre computadores centrais e microcomputadores usados por estudantes e funcionários.
  • Seu núcleo de pequenos pacotes confirmados funcionava em linhas seriais; convenções para caracteres, registros e opções negociadas tratavam diferenças que a conexão física não resolvia.

Na primeira demonstração de transferência Kermit, dois programas Kermit-20 trocaram um arquivo por um cabo null-modem entre portas seriais do mesmo DECSYSTEM-20. O Kermit Project depois chamou isso de prova de conceito: copiar um arquivo dentro de uma só máquina era mais fácil. O teste importante ocorreu algumas semanas mais tarde. De um lado, um DEC-20 com TOPS-20; do outro, um Intertec Superbrain com CP/M-80. Processador, sistema operacional e representação de arquivos eram diferentes. Enviar bytes era apenas a parte visível do problema.

Na Columbia, o perfil de uso dos computadores estava mudando. Microcomputadores chegavam aos laboratórios, departamentos, casas e residências estudantis, enquanto arquivos e serviços continuavam nos sistemas centrais de tempo compartilhado. Em um artigo preparado em 1983, Frank da Cruz e Bill Catchings contaram que os identificadores estudantis eram atribuídos por curso ou período e não garantiam espaço em disco por tempo indeterminado. Uma máquina pequena com disquete podia guardar os trabalhos localmente, desde que houvesse um meio confiável de transferi-los entre o computador pessoal e o sistema central.

Esse relato documenta uma necessidade institucional, não mede todas as universidades.

A linha serial tornava a tarefa mais difícil. Conexões assíncronas comuns ofereciam pouca proteção contra ruído, perda de caracteres, estouro de buffers ou queda intermitente da portadora. O Kermit dividiu a transferência em pacotes e fez de cada pacote parte de um diálogo. O emissor começava com um pacote Send-Init, que anunciava parâmetros. O receptor respondia com os seus. Um cabeçalho nomeava o arquivo, pacotes de dados levavam as partes e mensagens separadas indicavam o fim do arquivo e da transmissão. O reconhecimento permitia avançar; uma negativa ou o esgotamento do tempo levava à retransmissão.

O mecanismo básico era intencionalmente pequeno. O número de sequência avançava módulo 64, permitindo que os dois programas identificassem a unidade reconhecida e percebessem uma etapa perdida ou duplicada durante a sessão. Uma verificação aritmética obrigatória de um caractere ajudava a detectar pacotes alterados. Não era um checksum criptográfico moderno nem identificava quem estava no terminal remoto. Dava aos programas uma forma de encontrar alguns erros de transmissão e tentar novamente. A confiabilidade vinha da cooperação dos extremos, não de uma linha serial que tivesse se tornado confiável.

O desafio de interoperabilidade do Kermit também estava acima da linha. Duas máquinas podiam trocar ASCII e ainda interpretar arquivos de maneiras diferentes. DEC-20 e CP/M tinham ambientes distintos; os mainframes IBM acrescentavam outras limitações. Um arquivo podia ser organizado em registros, e não como um fluxo simples de bytes. Codificações de texto variavam; um terminal de mainframe podia ecoar caracteres, quebrar linhas, converter maiúsculas/minúsculas ou consumir controles. Tratar a conexão como um canal transparente podia alterar o conteúdo antes de gravá-lo no destino.

O Kermit definiu uma representação comum para a transferência e conversões explícitas nas duas pontas. A sintaxe básica dos pacotes usava caracteres imprimíveis; bytes de controle dentro dos dados podiam ser codificados como sequências imprimíveis. Cada programa convertia então o formato de troca para as convenções locais de arquivo. O manual limita a premissa compartilhada: ASCII em uma linha serial assíncrona comum. Ele não tornava todos os computadores iguais; oferecia uma linguagem limitada para que trocassem arquivos apesar das diferenças de armazenamento, codificação e terminal.

As implementações também tinham capacidades diferentes. O manual de novembro de 1983 afirma que o desenvolvimento era distribuído e desorganizado, sem uma versão fixa que pudesse ser imposta a quem implementava o protocolo. Ele definiu funções básicas e opções; o intercâmbio inicial informava as capacidades de cada lado. A meta declarada era permitir que uma implementação simples funcionasse com outra mais avançada. Isso expressa a intenção de projeto, não comprova que todos os pares de programas fossem interoperáveis.

O núcleo pequeno não congelou o protocolo. Versões posteriores acrescentaram pacotes longos, verificações mais fortes e janelas deslizantes em duplex. O manual atribui essa extensão a um grupo da The Source Telecomputing em 1985–86. Ela enfrentava uma condição diferente de desempenho: esperar o reconhecimento de cada pacote podia desperdiçar tempo em caminhos com atraso relevante. A opção era negociada; um receptor sem suporte podia permanecer no modo básico. Essa evolução posterior não deve ser projetada sobre a primeira transferência de 1981.

A linha do tempo do projeto registra que, em 1984, havia um site FTP do Kermit e uma lista Info-Kermit na ARPANET. A rede facilitou distribuir o programa e discutir seu desenvolvimento, mas a necessidade original continuava concreta: alguém precisava levar um arquivo de um tipo de computador a outro. O Kermit não era um padrão da Internet nem substituía protocolos de rede. Fazia outro trabalho: viabilizava a transferência entre sistemas ligados por linha serial e, mais tarde, também por serviços de rede.

Essa história mostra que conectividade e interoperabilidade não são sinônimos. A portadora pode ligar dois terminais sem tornar seus arquivos compatíveis; uma checagem de pacote pode detectar parte dos danos sem autenticar o emissor; uma especificação comum pode permitir a troca sem garantir que todas as implementações adotem cada opção. O Kermit tornou essas emendas explícitas e implementáveis.

Fontes