Resumen

  • Kermit nació en Columbia en 1981 para resolver el intercambio de archivos entre los ordenadores centrales y las microcomputadoras que empezaban a usar estudiantes y personal.
  • Su núcleo de paquetes confirmados funcionaba sobre líneas seriales; las convenciones de caracteres, registros y opciones negociadas trataban diferencias que la conexión física no podía resolver.

La primera demostración de transferencia Kermit conectó dos programas Kermit-20 mediante un cable null-modem entre puertos seriales del mismo DECSYSTEM-20. El proyecto Kermit la describió después como una prueba de concepto: copiar un archivo dentro de un solo ordenador era más sencillo. La prueba importante llegó unas semanas más tarde. En un extremo había un DEC-20 con TOPS-20; en el otro, un Intertec Superbrain con CP/M-80. Cambiaban el procesador, el sistema operativo y la forma de representar los archivos. Enviar bytes era apenas la parte visible del problema.

En Columbia cambiaba quién necesitaba acceder a los sistemas. Las microcomputadoras se extendían por laboratorios, departamentos, hogares y residencias universitarias, mientras que muchos archivos y servicios seguían en los sistemas centrales de tiempo compartido. En un artículo preparado en 1983, Frank da Cruz y Bill Catchings explicaron que los identificadores estudiantiles asignados por curso o periodo no garantizaban espacio de disco duradero. Una microcomputadora con disquete podía conservar el trabajo localmente, siempre que existiera una forma fiable de moverlo entre el equipo pequeño y el ordenador central.

Es el relato de un problema institucional, no una medición de todas las universidades.

La línea hacía más difícil el intercambio. Una conexión serial asíncrona común ofrecía poca defensa contra ruido, caracteres perdidos, búferes desbordados o caídas intermitentes de portadora. Kermit dividió la transferencia en paquetes y convirtió cada uno en parte de una conversación. El emisor empezaba con un paquete Send-Init que anunciaba parámetros. El receptor respondía con los suyos. Un encabezado identificaba el archivo; paquetes de datos llevaban sus partes; otros marcaban el final del archivo y de la transmisión. Los acuses permitían avanzar. Una respuesta negativa o un tiempo de espera agotado provocaba un reenvío.

El mecanismo básico era deliberadamente pequeño. La secuencia avanzaba módulo 64 para que ambos programas reconocieran qué unidad se había confirmado y detectaran una etapa perdida o repetida durante el intercambio. Un control aritmético obligatorio de un carácter ayudaba a detectar paquetes alterados. No era una suma criptográfica moderna ni identificaba a la persona sentada en un terminal. Daba a los programas una oportunidad de detectar algunos errores de transmisión y volver a intentarlo. La fiabilidad dependía de la cooperación de los extremos, no de que el cable se volviera confiable.

El reto de Kermit iba más allá del cable. Dos máquinas podían intercambiar ASCII y seguir interpretando los archivos de manera distinta. DEC-20 y CP/M tenían entornos diferentes; los mainframes IBM añadían otras limitaciones. Un archivo podía contener registros, no una secuencia indiferenciada de bytes. También variaban las codificaciones de texto y el terminal del ordenador central podía repetir caracteres, ajustar líneas, cambiar mayúsculas o consumir controles. Tratar la conexión como un conducto transparente podía alterar el archivo antes de guardarlo.

Kermit introdujo una representación común para la transferencia y conversiones explícitas en cada extremo. El formato básico de paquetes usaba caracteres imprimibles; los caracteres de control dentro de los datos podían representarse como secuencias imprimibles. Cada programa traducía ese intercambio a las convenciones locales de almacenamiento. El manual limita con precisión la suposición compartida: ASCII por una línea serial asíncrona común. No volvía iguales a los ordenadores; proporcionaba un idioma limitado para intercambiar archivos pese a diferencias de almacenamiento, codificación y terminal.

También debía funcionar una pareja de programas con capacidades desiguales. El manual de noviembre de 1983 dice que el desarrollo estaba distribuido y no había una versión fija que pudiera imponerse a quienes implementaban Kermit. Definió funciones básicas y opciones; el intercambio inicial permitía anunciar capacidades. El objetivo declarado era que una implementación básica pudiera comunicarse con otra más avanzada. Es intención de diseño, no evidencia de que todos los pares de programas fueran interoperables.

El núcleo pequeño no congeló el protocolo. Las versiones posteriores añadieron paquetes largos, verificaciones más fuertes y ventanas deslizantes dúplex. El manual atribuye el desarrollo de ventanas a un grupo de The Source Telecomputing en 1985–86. Resolvía otra condición de rendimiento: esperar un acuse después de cada paquete podía desperdiciar tiempo en caminos con demora. La función se negociaba; un receptor que no la admitía podía quedarse con el intercambio básico. Esa ampliación pertenece a la evolución posterior, no a la primera transferencia de 1981.

La cronología del proyecto registra en 1984 un sitio FTP de Kermit y la lista Info-Kermit en ARPANET. La red facilitó la distribución y el debate del programa, pero el problema inicial seguía siendo concreto: una persona quería llevar un archivo de un ordenador a otro. Kermit no era una norma de Internet ni reemplazaba los protocolos de red. Cubría otra tarea: hacer posible la transferencia entre sistemas que se comunicaban por una línea serial o, más adelante, por un servicio de red.

La historia muestra que conectividad e interoperabilidad no significan lo mismo. La portadora puede unir dos terminales sin hacer compatibles sus archivos; una verificación puede detectar algunos daños sin autenticar al emisor; una especificación común puede permitir el intercambio sin que todos adopten cada opción. Kermit convirtió esas costuras en una conversación explícita que podía implementarse.

Fuentes