XMODEM es un protocolo simple de transferencia de archivos desarrollado como un truco rápido por Ward Christensen para su uso en su programa terminal MODEM.ASM de 1977 . Permitía a los usuarios transmitir archivos entre sus computadoras cuando ambas partes usaban MODEM. Keith Petersen hizo una actualización menor para activar siempre el "modo silencioso" y llamó al resultado XMODEM. [3]
XMODEM, como la mayoría de los protocolos de transferencia de archivos, divide los datos originales en una serie de " paquetes " que se envían al receptor, junto con información adicional que permite al receptor determinar si ese paquete se recibió correctamente. Si se detecta un error, el receptor solicita que se reenvíe el paquete. Una serie de paquetes defectuosos provoca que se cancele la transferencia.
XMODEM se volvió extremadamente popular en el mercado de los primeros sistemas de tableros de anuncios (BBS), en gran parte porque era fácil de implementar. También era bastante ineficiente y, a medida que aumentaba la velocidad del módem, este problema llevó al desarrollo de varias versiones modificadas de XMODEM para mejorar el rendimiento o solucionar otros problemas con el protocolo. Christensen creía que su XMODEM original era "el programa más modificado en la historia de la informática". [4]
Chuck Forsberg recopiló una serie de modificaciones comunes en su protocolo YMODEM , pero una implementación deficiente provocó una mayor fractura antes de que fueran reunificadas por su posterior protocolo ZMODEM . ZMODEM se hizo muy popular, pero nunca reemplazó por completo a XMODEM en el mercado de BBS.
El XMODEM original utilizaba un paquete de datos de 128 bytes, el tamaño de bloque básico utilizado en los disquetes CP/M . El paquete tenía como prefijo un encabezado simple de 3 bytes que contenía un carácter, un "número de bloque" del 1 al 255 y el número de bloque "inverso": 255 menos el número de bloque. La numeración de bloques comienza con 1 para el primer bloque enviado, no con 0. El encabezado fue seguido por los 128 bytes de datos y luego una suma de verificación de un solo byte . La suma de comprobación era la suma de los 128 bytes de datos del paquete módulo 256. Por tanto, el paquete completo tenía 132 bytes de longitud y contenía 128 bytes de datos de carga útil , para una eficiencia total del canal de aproximadamente el 97%.<SOH>
El archivo fue marcado como "completo" con un carácter enviado después del último bloque. Este carácter no estaba en un paquete, sino que se envió solo como un solo byte. Dado que la longitud del archivo no se envió como parte del protocolo, el último paquete se completó con un "carácter conocido" que podía descartarse. En la especificación original, el valor predeterminado era o 26 decimal, que CP/M utilizaba como marcador de fin de archivo dentro de su propio formato de disco. El estándar sugería que se podía usar cualquier carácter para el relleno, pero no había forma de cambiarlo dentro del protocolo mismo: si una implementación cambiaba el carácter de relleno, solo los clientes que usaran la misma implementación interpretarían correctamente el nuevo carácter de relleno.<EOT><SUB>
Los archivos se transfirieron un paquete a la vez. Cuando se recibió, el receptor calculó la suma de verificación del paquete y la comparó con la recibida del remitente al final del paquete. Si los dos coincidían, el receptor enviaba un mensaje al remitente, que luego enviaba el siguiente paquete en secuencia. Si había un problema con la suma de comprobación, el receptor enviaba un archivo . Si se recibía un, el remitente volvía a enviar el paquete y continuaba intentándolo varias veces, normalmente diez, antes de abortar la transferencia.<ACK><NAK><NAK>
También se envió A <NAK>si el receptor no recibió un paquete válido en diez segundos mientras aún esperaba datos debido a la falta de un <EOT>carácter. También se utilizó un tiempo de espera de siete segundos dentro de un paquete, para proteger contra caídas de conexiones a mitad del paquete.
Los números de bloque también se examinaron de forma sencilla para comprobar si había errores. Después de recibir un paquete con éxito, el siguiente paquete debería tener un número superior. Si en cambio recibía el mismo número de bloque, esto no se consideraba grave, se daba a entender que <ACK>no había sido recibido por el remitente, que luego había reenviado el paquete. Cualquier otro número de paquete indicaba que se habían perdido paquetes.
Las transferencias eran impulsadas por el receptor; el transmisor no enviaría ningún dato hasta que <NAK>el receptor enviara una inicial. Este era un resultado lógico de la forma en que el usuario interactuaba con la máquina emisora, que estaría ubicada de forma remota. El usuario navegaría hasta el archivo solicitado en la máquina emisora y luego le pediría a esa máquina que lo transfiera. Una vez que se emitió este comando, el usuario ejecutaría un comando en su software local para comenzar a recibir. Dado que se desconocía el retraso entre solicitar el archivo al sistema remoto y emitir un comando local para recibirlo, XMODEM permitió hasta 90 segundos para que el receptor comenzara a emitir solicitudes de paquetes de datos.
Aunque XMODEM era lo suficientemente robusto como para que en 1982 un periodista transmitiera historias desde Pakistán a los Estados Unidos con un Osborne 1 y un acoplador acústico a través de líneas telefónicas de mala calidad, [5] el protocolo tenía varios defectos.
XMODEM fue escrito para máquinas CP/M y lleva varias marcas de ese sistema operativo . En particular, los archivos en CP/M siempre eran múltiplos de 128 bytes y su final estaba marcado dentro de un bloque con el <EOT>carácter. Estas características fueron trasplantadas directamente a XMODEM. Sin embargo, otros sistemas operativos no presentaban ninguna de estas peculiaridades, y la introducción generalizada de MS-DOS a principios de la década de 1980 llevó a que XMODEM tuviera que actualizarse para notar un <EOT> o <EOF> como marcador de fin de archivo.
Durante algún tiempo se sugirió que se debería admitir el envío de un <CAN>carácter en lugar de un <ACK>o <NAK>para poder cancelar fácilmente la transferencia desde el extremo receptor. Asimismo, al <CAN>recibirse en lugar del <SOH>indicado el remitente desea cancelar la transferencia. Sin embargo, este personaje podría "crearse" fácilmente mediante simples errores relacionados con el ruido de lo que debía ser un <ACK>o <NAK>. Se propuso un sistema doble <CAN>para evitar este problema, pero no está claro si se implementó ampliamente.
XMODEM fue diseñado para ser simple, sin mucho conocimiento de otros protocolos de transferencia de archivos, que de todos modos eran bastante raros. Debido a su simplicidad, había una serie de errores muy básicos que podían provocar que una transferencia fallara o, peor aún, dar como resultado un archivo incorrecto que pasaba desapercibido para el protocolo. La mayor parte de esto se debió al uso de una simple suma de verificación para la corrección de errores, que es susceptible de perder errores en los datos si se invierten dos bits, lo que puede ocurrir con una ráfaga de ruido adecuadamente corta. Además, un daño similar al encabezado o a la suma de verificación podría provocar una transferencia fallida en los casos en que los datos en sí no estuvieran dañados.
Muchos autores introdujeron extensiones a XMODEM para abordar estos y otros problemas. Muchos pidieron que estas extensiones se incluyeran como parte de un nuevo estándar XMODEM. Sin embargo, Ward Christensen se negó a hacer esto, ya que fue precisamente la falta de estas características y la codificación asociada necesaria para respaldarlas lo que llevó al uso generalizado de XMODEM. Como explicó:
Otro problema con XMODEM era que requería que la transferencia fuera dirigida por el usuario en lugar de automatizada. Normalmente, esto significaba que el usuario navegaría en el sistema del remitente para seleccionar el archivo que deseaba y luego usaría un comando para poner ese sistema en el modo "listo para enviar". Luego activarían la transferencia desde su extremo usando un comando en su emulador de terminal. Si el usuario quisiera transferir otro archivo, tendría que repetir este proceso nuevamente.
Para las transferencias automatizadas entre dos sitios, con el tiempo se implementaron varios complementos al protocolo XMODEM. Por lo general, asumían que el remitente continuaría enviando un archivo tras otro, y el receptor intentaría activar el siguiente archivo enviando un mensaje NAKnormalmente al comienzo de una transferencia. Cuando se NAKagotó el tiempo de espera, se podría suponer que no había más archivos o que el enlace estaba roto de todos modos.
MODEM7 , también conocido como lote MODEM7 o Batch XMODEM , fue la primera extensión conocida del protocolo XMODEM. Una transferencia de archivos XMODEM normal comienza cuando el receptor envía un solo NAKcarácter al remitente, que luego comienza a enviar uno SOHpara indicar el inicio de los datos y luego paquetes de datos.
MODEM7 cambió este comportamiento solo ligeramente, al enviar el nombre del archivo, en formato de nombre de archivo 8.3 , antes del archivo <SOH>. Cada carácter se envió individualmente y el receptor tuvo que repetirlo como una forma de corrección de errores. Para una implementación de XMODEM no consciente, estos datos simplemente se ignorarían mientras se espera que SOHlleguen, por lo que los caracteres no se repetirán y la implementación podría recurrir a XMODEM convencional. Con el software "consciente", el nombre del archivo podría usarse para guardar el archivo localmente. Las transferencias podrían continuar con otro <NAK>, cada archivo se guarda con el nombre que se envía al receptor.
Jerry Pournelle en 1983 describió MODEM7 como "probablemente el programa de comunicaciones por microcomputadora más popular que existe". [6]
MODEM7 envió el nombre del archivo como texto normal, lo que significaba que podría corromperse por los mismos problemas que XMODEM intentaba evitar. Esto llevó a la introducción de TeLink por parte de Tom Jennings , autor de los anuncios publicitarios originales de FidoNet .
TeLink evitó los problemas de MODEM7 estandarizando un nuevo "paquete cero" que contiene información sobre el archivo original. Esto incluía el nombre, el tamaño y la marca de tiempo del archivo , que se colocaron en un bloque XMODEM normal de 128 bytes. Mientras que una transferencia XMODEM normal comenzaría con el remitente enviando el "bloque 1" con un <SOH>encabezado, el paquete de encabezado de TeLink estaba etiquetado como "bloque 0" y comenzaba con un <SYN>. El paquete contenía la fecha y hora de creación del archivo, el nombre del archivo de hasta 16 caracteres, el tamaño del archivo como un valor de 4 bytes y el nombre del programa que envía el archivo. [7]
Una implementación normal de XMODEM simplemente descartaría el paquete, suponiendo que el número del paquete había sido dañado. Pero esto provocaba un posible retraso si el paquete se descartaba, ya que el remitente no podía saber si el receptor había respondido con un <NAK>porque no entendía el paquete cero o porque había un error de transmisión. Como TeLink normalmente solo lo usaba el software FidoNet , que lo exigía como parte de los estándares FidoNet, esto no presentaba un problema en el mundo real ya que ambos extremos siempre admitirían este estándar. [7]
El sistema básico "bloque 0" se convirtió en un estándar en la comunidad FidoNet y fue reutilizado por varios protocolos futuros como SEAlink y YMODEM .
La suma de comprobación utilizada en el protocolo original era extremadamente simple y los errores dentro del paquete podían pasar desapercibidos. Esto llevó a la introducción de XMODEM-CRC por John Byrns, [8] [9] que utilizaba un CRC de 16 bits en lugar de la suma de comprobación de 8 bits. Los CRC codifican no sólo los datos del paquete, sino también su ubicación, lo que le permite detectar los errores de sustitución de bits que se perderían con una suma de comprobación. Estadísticamente, esto hizo que la probabilidad de detectar un error de menos de 16 bits de longitud fuera del 99,9969%, e incluso mayor para cadenas de bits de error más largas. [10]
XMODEM-CRC fue diseñado para ser compatible con versiones anteriores de XMODEM. Para hacer esto, el receptor envió un Ccarácter (C mayúscula) en lugar de un <NAK>para iniciar la transferencia. Si el remitente respondía enviando un paquete, se suponía que "conocía" XMODEM-CRC y el receptor continuaba enviando el Cpaquete. Si no llegaba ningún paquete, el receptor asumía que el remitente no conocía el protocolo y enviaba un mensaje <NAK>para iniciar una transferencia XMODEM "tradicional". [10]
Desafortunadamente, este intento de compatibilidad con versiones anteriores tuvo un inconveniente. Dado que era posible que el Ccarácter inicial se perdiera o se corrompiera, no se podía asumir que el receptor no soportaba XMODEM-CRC si fallaba el primer intento de activar la transferencia. Así, el receptor intentó iniciar la transferencia tres veces con C, esperando tres segundos entre cada intento. Esto significaba que si el usuario seleccionaba XMODEM-CRC mientras intentaba hablar con cualquier XMODEM, como estaba previsto, había un posible retraso de 10 segundos antes de que comenzara la transferencia. [10]
Para evitar el retraso, el remitente y el receptor generalmente enumerarían XMODEM-CRC por separado de XMODEM, lo que permitiría al usuario seleccionar XMODEM "básico" si el remitente no lo incluyera explícitamente. Para el usuario medio, XMODEM-CRC era esencialmente un "segundo protocolo" y se trataba como tal. Sin embargo, esto no fue cierto para los remitentes de correo FidoNet, donde CRC se definió como el estándar para todas las transferencias TeLink. [7]
Dado que el protocolo XMODEM requería que el remitente se detuviera y esperara un mensaje <ACK>o <NAK>del receptor, tendía a ser bastante lento. En la era de los módems de 300 bit/s, el paquete completo de 132 bytes requería poco más de 3,5 segundos para enviarse (132 bytes * (8 bits por byte + 1 bit de inicio + 1 bit de parada) / 300 bits por segundo). Suponiendo que al receptor le toma 0,2 segundos <ACK>regresar al remitente y que el siguiente paquete comienza a llegar al receptor (0,1 segundos en ambas direcciones), el tiempo total para un paquete sería de 3,7 segundos, poco más del 92% del rendimiento.
El tiempo del proceso <ACK>/ <NAK>era una función fija de la red de comunicaciones subyacente, no del rendimiento de los módems. A medida que aumentaba la velocidad del módem, el retraso fijo crecía en proporción al tiempo necesario para enviar el paquete. Por ejemplo, a 2400 bit/s los paquetes tardaron sólo 0,44 segundos en enviarse, por lo que si el <ACK>/ <NAK>todavía tardó 0,2 segundos en regresar a la máquina del usuario, el rendimiento ha caído por debajo del 60%. A 9600 bit/s está por debajo del 30%: se pasa más tiempo esperando la respuesta del necesario para enviar el paquete.
Se introdujeron varias versiones nuevas de XMODEM para abordar estos problemas. Al igual que las extensiones anteriores, estas versiones tendían a ser compatibles con versiones anteriores del XMODEM original y, al igual que esas extensiones, esto llevó a una mayor fractura del panorama XMODEM en el emulador de terminal del usuario. Al final surgieron decenas de versiones de XMODEM.
WXmodem , abreviatura de "Windowed Xmodem", es una variante de XMODEM desarrollada por Peter Boswell en 1986 para su uso en líneas de alta latencia, específicamente sistemas públicos X.25 y PC Pursuit . Estos tienen latencias que son mucho más altas que el servicio telefónico tradicional , lo que conduce a una eficiencia muy pobre en XMODEM. Además, estas redes suelen utilizar caracteres de control para el control de flujo y otras tareas, en particular XON/XOFF detendrá el flujo de datos. Finalmente, en el caso de un error que requería un reenvío, a veces era difícil saber si se SOHtrataba de un indicador de paquete o de más ruido. WXmodem adaptó XMODEM-CRC para abordar estos problemas. [10]
Un cambio fue escapar de un pequeño conjunto de caracteres de control : DLE, y . Estos se escaparon insertando un delante de ellos y luego modificando el carácter aplicando XOR con 64. En teoría, esto significaba que el paquete podría tener hasta 264 bytes si originalmente constaba enteramente de caracteres que requerían escape. Estos caracteres insertados y modificados no forman parte del cálculo del CRC; se eliminan y convierten en el extremo receptor antes de calcular el CRC. [10]XONXOFFSYNDLE
Además, todos los paquetes tenían el prefijo de un SYNcarácter, lo que significaba que la entrada del paquete era SYNSOH, lo que reducía la posibilidad de que un mensaje perdido SOHse confundiera con un encabezado de paquete en varios casos de error. Un archivo sin escape SYNencontrado en el cuerpo de un paquete fue un error. [10]
El cambio principal en WXMODEM es el uso de una ventana deslizante para mejorar el rendimiento en enlaces de alta latencia. Para ello, los ACKmensajes iban seguidos del número de paquete que enviaban ACKo NAKenviaban. El receptor no tiene que recibir ACKtodos los paquetes; está permitido ACKcualquier número entre uno y cuatro paquetes. Se supone que existe un ACKnúmero de secuencia con el cuarto paquete para ACKlos cuatro paquetes. Un error hace NAKque se envíe un inmediatamente, con todos los paquetes de ese número y después de ser reenviado. [10]
Requerir ACKcada cuatro paquetes hace que el sistema funcione como si tuviera un tamaño de paquete de 512 bytes, pero en caso de error, normalmente solo requiere reenviar 128 bytes. Además, reduce cuatro veces la cantidad de datos que fluyen en dirección inversa. Esto tiene poco interés en el funcionamiento dúplex completo de un módem típico, pero es importante en sistemas semidúplex como los modelos Telebit que tienen una velocidad de 19 kB en una dirección y 75 bits/s en el canal de retorno.
Uno de los primeros anuncios publicitarios de terceros para el sistema FidoNet fue SEAdog , escrito por el mismo autor que el entonces popular formato de compresión de datos .arc . SEAdog incluyó una amplia variedad de mejoras, incluido SEAlink , un protocolo de transferencia mejorado basado en el mismo concepto de ventana deslizante que WXmodem. [11] Se diferenciaba de WXmodem principalmente en los detalles.
Una diferencia es que SEAlink admitía el "paquete cero" introducido por TeLink, que es necesario para funcionar como reemplazo directo de TeLink en sistemas FidoNet donde se esperaba el encabezado. ACKs y NAKs se ampliaron a "paquetes" de tres bytes, comenzando con ACKo NAK, luego el número de paquete, luego el complemento del número de paquete, de la misma manera que el encabezado del paquete XMODEM original. El tamaño de la ventana normalmente se establecía en seis paquetes. [11]
No se esperaba que SEAlink funcionara a través de X.25 o enlaces similares y, por lo tanto, no realizó el escape. Esto también era necesario para que el paquete cero funcionara correctamente, ya que este estándar utilizaba el SYNcarácter que WXmodem había reutilizado. [11] Además de estos cambios, agregó un modo "Overdrive" para enlaces semidúplex. Esto suprimió los ACK de los paquetes que se transfirieron con éxito, lo que de hecho hizo que la ventana tuviera un tamaño infinito. Este modo se indicaba mediante una bandera en el bloque cero. [11]
Posteriormente, SEAlink agregó una serie de otras mejoras y fue un protocolo útil de propósito general. Sin embargo, seguía siendo poco común fuera del mundo de FidoNet y rara vez se veía en el software de cara al usuario.
Otra forma de resolver el problema del rendimiento es aumentar el tamaño del paquete. Aunque el problema fundamental de la latencia persiste, la velocidad a la que se convierte en un problema es mayor. XMODEM-1K con paquetes de 1024 bytes fue la solución más popular. En este caso, el rendimiento a 9600 bit/s es del 81%, dadas las mismas suposiciones anteriores.
XMODEM-1K era una versión ampliada de XMODEM-CRC, que indicaba el tamaño de bloque más largo en el remitente al iniciar un paquete con el <STX>carácter en lugar de <SOH>. Al igual que otras extensiones XMODEM compatibles con versiones anteriores, se pretendía que se pudiera iniciar una transferencia de -1K con cualquier implementación de XMODEM en el otro extremo, retrocediendo las funciones según fuera necesario.
XMODEM-1K fue originalmente una de las muchas mejoras a XMODEM introducidas por Chuck Forsberg en su protocolo YMODEM . Forsberg sugirió que las diversas mejoras eran opcionales y esperaba que los autores de software implementaran tantas como fuera posible. En cambio, generalmente implementaron lo mínimo, lo que llevó a una profusión de implementaciones semicompatibles y, finalmente, a la división del nombre "YMODEM" en "XMODEM-1K" y una variedad de YMODEM. Por lo tanto, XMODEM-1K en realidad es posterior a YMODEM, pero de todos modos sigue siendo bastante común.
NMODEM es un protocolo de transferencia de archivos desarrollado por LB Neal, quien lo lanzó en 1990. NMODEM es esencialmente una versión de XMODEM-CRC que utiliza bloques más grandes de 2048 bytes, a diferencia de los bloques de 128 bytes de XMODEM. NMODEM se implementó como un programa separado, escrito en Turbo Pascal 5.0 para la familia de computadoras compatibles con IBM PC . El tamaño del bloque se eligió para que coincida con el tamaño de clúster común del sistema de archivos FAT MS-DOS en los discos duros actuales , lo que simplifica el almacenamiento en búfer de datos para escribir. [12] [13]
En conexiones confiables (libres de errores), es posible eliminar la latencia "reconociendo previamente" los paquetes, una técnica conocida más generalmente como " suplantación de protocolo ". Esto normalmente se logra en el hardware del enlace, en particular en los módems Telebit. Los módems, cuando se activaba la opción, notarían el encabezado XMODEM e inmediatamente enviarían un archivo ACK. Esto haría que el programa XMODEM emisor enviara inmediatamente el siguiente paquete, haciendo que la transferencia fuera continua, como una ventana de tamaño infinito. Los módems también suprimen el ACKenvío del software XMODEM en el otro extremo, liberando así el canal de retorno de baja velocidad.
El sistema también se puede implementar en el propio protocolo y las variaciones de XMODEM ofrecen esta característica. En estos casos, el receptor enviaría el ACKpaquete tan pronto como comenzara el paquete, de la misma manera que los módems Telebit. Dado que esta característica es sólo una alteración del comportamiento del lado del receptor, no requiere ningún cambio en el protocolo por parte del remitente. YMODEM formalizó este sistema.
Este concepto debe contrastarse con el utilizado en SEAlink, que cambia el comportamiento en ambos lados del enlace. En SEAlink, el receptor deja de enviar mensajes ACKpor completo y el remitente cambia su comportamiento para no esperarlos.