Resumen

  • XMODEM obligaba a compartir muy poco: 128 bytes de datos, un número de bloque y su complemento, una suma de control, confirmaciones dirigidas por el receptor y una señal de final. No dictaba cómo marcar, guardar ni presentar el archivo.
  • Ese límite permitió que programas independientes se copiaran, portaran y probaran entre sí. También dejó a la vista un control de errores modesto, la penalización de esperar tras cada bloque y la ausencia de metadatos, problemas que otras convenciones pudieron abordar sin convertir el protocolo en un servicio único.

La línea común era más pequeña que el producto

El bloque de XMODEM puede describirse sin diagrama: SOH, número de bloque, complemento a uno del número, 128 bytes de contenido y suma de control. El número empieza en uno y avanza. El complemento permite comprobar de forma barata que la cabecera no ha cambiado. La suma añade los bytes de datos y descarta el acarreo.

El receptor abre el intercambio. Cuando está preparado envía NAK; el emisor responde con el primer bloque. Si la comprobación coincide, recibe ACK y continúa. Si no, NAK solicita repetir. Al terminar los datos, el emisor manda EOT y espera la última confirmación.

Nada de eso decide qué número telefónico marcar, cómo se llama el fichero, en qué directorio se guarda, qué usuario tiene permiso o qué aspecto debe tener la pantalla. El convenio compartido comienza después de la conexión y acaba antes de la experiencia completa. Exige coincidencia sólo donde dos programas deben interpretar los mismos bytes.

Los 128 bytes tampoco fueron una medida perfecta descubierta para toda red. Correspondían al sector de los disquetes CP/M en el entorno donde Christensen trabajaba. La longitud fija simplificaba búferes y código en máquinas pequeñas, aunque obligaba a rellenar el último bloque y no comunicaba por sí misma el tamaño exacto del archivo.

Un duplicado que no duplica el archivo

El caso más instructivo aparece cuando se pierde la respuesta, no los datos. El receptor puede recibir el bloque esperado o volver a ver el anterior. Esa repetición puede significar que la primera copia llegó bien, pero el ACK de vuelta se dañó y el emisor decidió retransmitir.

Por eso el programa receptor reconoce el número previo, vuelve a confirmar y evita escribir dos veces el mismo contenido. Si llega un número distinto tanto del esperado como del anterior, la situación ya sugiere una pérdida grave de sincronización y puede requerir cancelar.

La regla consume poco estado y resuelve una ambigüedad concreta sin árbitro. Ninguna base central tiene que declarar cuál copia es verdadera. Cada extremo conserva su posición, observa el número y produce la misma reacción. La fiabilidad se construye como acuerdo sobre fallos acotados, no como promesa de que el ruido desaparecerá.

Christensen describió después su trabajo de 1977 como una solución improvisada para una necesidad personal. También sostuvo que hacerlo pronto y ponerlo de inmediato en el dominio público ayudó a que se convirtiera en estándar. Es un testimonio retrospectivo, no una demostración causal. Sin embargo, el mecanismo de adopción resulta verosímil: un programa pequeño podía leerse, copiarse, adaptarse y enfrentarse a otra implementación sin pedir acceso al dueño de una red.

El RFC documentó una práctica ya extendida

XMODEM no fue una norma creada por el IETF. El RFC 916 de 1984 proponía otro protocolo fiable para enlaces asíncronos e incluyó MODEM/XMODEM en un apéndice porque ya era habitual entre microordenadores. La práctica distribuida precedió al documento que la describía.

El RFC tampoco lo trató como solución definitiva. Señaló que el flujo era unidireccional y el paquete estaba fijado en 128 octetos; ciertos concentradores podían tener dificultades con ráfagas incluso menores. El mecanismo de parada y espera reduce el aprovechamiento a medida que crece el tiempo de ida y vuelta. La suma de control de ocho bits no detecta todos los patrones de corrupción.

La sencillez no convierte esos compromisos en virtudes eternas. Lo que hace es volverlos observables. Un operador puede medir repeticiones, rendimiento, falsos resultados de la comprobación y tratamiento del último bloque. Cuando transferencia, identidad, almacenamiento y descubrimiento se esconden dentro del mismo servicio, saber qué capa falló es mucho más difícil.

Una mejora necesitaba interlocutores, no sólo un nombre

Las prácticas posteriores incorporaron CRC-16, bloques opcionales de 1K y un bloque cero para transportar datos como nombre y tamaño. Los programas públicos de Chuck Forsberg ayudaron a extenderlas bajo denominaciones como YMODEM. El suelo reconocible de XMODEM permitió añadir capacidades sin empezar de nuevo en cada máquina.

Christensen desconfiaba de introducir directamente en el núcleo dúplex completo, varios bloques pendientes de confirmación o múltiples destinos. No negaba que las transferencias avanzadas fueran útiles. Su argumento era de supervivencia: la extrema simplicidad explicaba que el protocolo existiera en tantos equipos y programas. Si una mejora declara defectuosos de golpe a todos los pares instalados, cambia quién puede mover el suelo compartido.

La adopción voluntaria tampoco produjo orden automático. Las referencias históricas advierten de productos con el mismo nombre YMODEM y comportamientos incompatibles. La marca no era prueba. La compatibilidad debía ganarse con una secuencia de propuesta, código operativo, archivos de prueba, despliegue limitado, observación de fallos y documentación honesta de capacidades.

CBBS era un lugar; XMODEM, un paso

Después de la gran nevada de Chicago de 1978, Christensen colaboró con Randy Suess para crear CBBS. Suess aportó el hardware y Christensen el software. El sistema contestaba llamadas, almacenaba mensajes y formaba un lugar al que regresaba una comunidad. Ese logro explica el mundo social en el que circulaban archivos, pero no pertenece al formato del bloque XMODEM.

Separar ambas capas tuvo consecuencias. Distintos tablones, terminales y rutinas locales podían adoptar transferencia de ficheros sin convertirse en clientes de una única plataforma. Compartían el paso estrecho por la línea, no todo el edificio alrededor.

El legado útil no es conservar 128 como cifra sagrada. Es preguntar qué hechos deben ser comunes para que el intercambio exista y qué decisiones se han concentrado por comodidad. XMODEM fue estricto con orden, reintento y final, y permisivo con casi todo lo demás. Los extremos seguían sujetos a un convenio, pero no tenían que parecerse allí donde ese convenio no necesitaba igualdad.

Fuentes