ZMODEM

Generalmente, los primeros protocolos de transferencia de archivos dividen un archivo en una serie de paquetes y los envían uno a uno al receptor. La parte principal del paquete, la carga útil , consiste en una cantidad determinada de bytes del archivo que se envía. Después de la carga útil, se incluye una suma de verificación o una comprobación de redundancia cíclica (CRC) que permite determinar si la carga útil se recibió correctamente. Si el paquete se recibe correctamente, el receptor envía un mensaje ACK y el remitente comienza a enviar el siguiente paquete.

El sistema telefónico introduce un pequeño retardo, conocido como latencia , que interfiere con este proceso. Aunque el receptor envíe el ACK inmediatamente, el retardo en las líneas telefónicas implica que siempre transcurrirá un tiempo antes de que el emisor lo reciba y envíe el siguiente paquete. A medida que aumenta la velocidad del módem , este retardo representa un número cada vez mayor de paquetes que podrían haberse enviado durante ese tiempo, lo que reduce la eficiencia del canal .

XMODEM utilizaba cargas útiles de 128 bytes con una cabecera de tres bytes y una suma de comprobación de un byte, para un total de 132 bytes por paquete. En la época de  los módems de 300 bit/s, un paquete tardaba unos cuatro segundos en enviarse, y las latencias típicas eran del orden de 1/10 de segundo, por lo que la sobrecarga de rendimiento no era significativa. A medida que aumenta la velocidad , el problema se agrava; a 2400 bit/sa ,  un paquete tarda unos 0,55  segundos en enviarse, por lo que se desperdicia aproximadamente 1/5 del ancho de banda disponible esperando las confirmaciones (ACK ). A 9600 bit/sa , un paquete requiere solo 0,13 segundos para enviarse, por lo que se desperdicia aproximadamente 1/2 del ancho de banda.  

Una solución a este problema es el uso de una ventana deslizante . Estos protocolos reducen la latencia permitiendo al remitente enviar varios paquetes sin esperar una confirmación (ACK) . El número de paquetes que permite enviar continuamente se conoce como "ventana", que generalmente oscilaba entre dos y dieciséis paquetes en la mayoría de las implementaciones. A principios de la década de 1980 aparecieron varias versiones nuevas de XMODEM con soporte para ventanas deslizantes.

Las ventanas deslizantes son útiles para latencias del orden de varias longitudes de paquete, como ocurre con XMODEM en líneas telefónicas convencionales. Sin embargo, no bastan para solucionar las latencias más largas que se producen en llamadas internacionales, conexiones satelitales o servicios X.25 como PC Pursuit , donde las latencias pueden ser del orden de un segundo o más. En otros casos, donde el canal de retorno era mucho más lento que el de envío, como sucedía con los módems Telebit o USRobotics , incluso la pequeña cantidad de ACK podría saturar el canal de retorno y provocar la pausa de la transferencia.

ZMODEM solucionó estos problemas eliminando por completo la necesidad de ACK , lo que permitía al emisor enviar datos continuamente siempre que el receptor no detectara errores. Solo se enviaban NAK si se producía algún problema. Dado que ZMODEM se utilizaba a menudo en enlaces con corrección de errores integrada , como X.25, el receptor solía no enviar ningún mensaje de vuelta al emisor. Como resultado, el sistema enviaba el archivo completo en un flujo continuo, y ZMODEM se autodenominaba un "protocolo de transmisión".

El rendimiento de ZMODEM mejoró tanto con respecto a los protocolos comunes anteriores que, en general, reemplazó incluso a protocolos especiales como YMODEM-g , que no incluían ninguna corrección de errores y, en cambio, dependían de enlaces sin errores mantenidos por los módems. Si bien YMODEM-g era más rápido (y, por lo tanto, popular entre los usuarios avanzados ), la falta de otras características, como las transferencias reiniciables, lo hacía menos atractivo.

XMODEM, y la mayoría de los protocolos basados ​​en él, gestionaban el orden de los paquetes anteponiendo a los datos un número de paquete del 1 al 255. Las versiones con ventana utilizaban este número de paquete para indicar qué paquetes se habían recibido correctamente o para especificar uno que no se había recibido. Dado que los paquetes tenían  una longitud de 128 bytes, esto significaba que la cantidad máxima de datos que se podía transferir antes de que se reiniciara el número de paquete era de 32  KB.

ZMODEM sustituyó el número de paquete por la ubicación real en el archivo, indicada por un número de 32 bits. Esto le permitía enviar mensajes NAK que rebobinaban la transferencia hasta el punto de fallo, independientemente de la longitud del archivo. Esta misma función también se utilizaba para reiniciar las transferencias si fallaban o se interrumpían deliberadamente. En este caso, el receptor comprobaba la cantidad de datos recibidos previamente y enviaba un mensaje NAK con esa ubicación, lo que activaba automáticamente al remitente para que reiniciara la transferencia desde ese punto.

El inicio automático simplificó la gestión al permitir que la máquina remitente iniciara la transferencia. Anteriormente, el usuario debía solicitar primero el archivo al remitente, lo que lo ponía en estado de espera, para luego regresar a su programa local e invocar un comando para iniciar la transferencia. Con la transferencia automática, simplemente solicitaba el archivo y el remitente activaba automáticamente la transferencia en el programa del usuario.