ZMODEM es un protocolo de transferencia de archivos desarrollado por Chuck Forsberg en 1986, en un proyecto financiado por Telenet para mejorar la transferencia de archivos en su red X.25 . Además de un rendimiento drásticamente mejorado en comparación con los protocolos anteriores, ZMODEM ofrecía transferencias reiniciables, inicio automático por parte del remitente, un CRC expandido de 32 bits y comillas de caracteres de control que admiten transferencias limpias de 8 bits , lo que permite su uso en redes que no pasar caracteres de control.
Protocolo de comunicación | |
Propósito | Protocolo de transferencia de archivos |
---|---|
Desarrollador (es) | Chuck Forsberg |
Introducido | 1986 |
Puerto (s) | Ninguno |
Hardware | modems |
A diferencia de la mayoría de los protocolos de transferencia desarrollados para los sistemas de tablones de anuncios (BBS), ZMODEM no se basó directamente ni fue compatible con el seminal XMODEM . Se habían desarrollado muchas variantes de XMODEM para abordar una o más de sus deficiencias, y la mayoría seguían siendo compatibles con versiones anteriores y completarían con éxito las transferencias con implementaciones XMODEM "clásicas". Esta lista incluye el propio YMODEM de Forsberg .
ZMODEM evitó la compatibilidad con versiones anteriores a favor de producir un protocolo radicalmente mejorado. Funcionó tan bien o mejor que cualquiera de las variedades de alto rendimiento de XMODEM, lo hizo en enlaces que antes no funcionaban en absoluto, como X.25, o tenían un rendimiento deficiente, como los módems Telebit , e incluían funciones útiles que se encuentran en pocos o ningún otro protocolo. ZMODEM se hizo extremadamente popular en los sistemas de tablones de anuncios (BBS) a principios de la década de 1990, convirtiéndose en un estándar tan extendido como lo había sido antes XMODEM.
Mejoras
Transmisión
Generalmente, los protocolos de transferencia de archivos dividen un archivo en una serie de paquetes y luego los envían uno por uno al receptor. La parte principal del paquete, la carga útil , es una cierta cantidad de bytes del archivo que se envía. Después de la carga útil viene una suma de comprobación o verificación de redundancia cíclica (CRC) que se puede utilizar para 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 retraso conocido como latencia que interfiere con este proceso. Incluso si el receptor envía el ACK inmediatamente, la demora en las líneas telefónicas significa que siempre habrá algún tiempo antes de que el remitente lo reciba y envíe el siguiente paquete. A medida que aumentan las velocidades del módem , este retraso representa un número cada vez mayor de paquetes que podrían haberse enviado durante el retraso, disminuyendo la eficiencia del canal .
XMODEM utilizó cargas útiles de 128 bytes con un encabezado de tres bytes y una suma de comprobación de un byte para un total de 132 bytes por paquete. En la era de los módems de 300 bps, 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 aumentan las velocidades, el problema se vuelve más problemático; a 2400 bps, un paquete tarda aproximadamente 1 ⁄ 2 para enviar, aproximadamente 1 ⁄ 5 del ancho de banda disponible se desperdicia esperando los ACK . A 9600 bps, un paquete requiere solo 0,13 segundos para enviarse, por lo que Se desperdicia 1 ⁄ 2 del ancho de banda.
Una solución a este problema es el uso de una ventana deslizante . Estos protocolos abordan la latencia al permitir que el remitente continúe enviando una cantidad de paquetes sin esperar un ACK . El número de paquetes que permite continuar es la "ventana", que normalmente estaba 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, que es el caso de XMODEM en líneas telefónicas convencionales. Sin embargo, no es suficiente abordar latencias más largas que se encuentran en llamadas telefónicas en el extranjero o servicios X.25 como PC Pursuit , donde las latencias son del orden de un segundo o más. En otros casos, donde el canal inverso era mucho más lento que el de envío, como fue el caso de los módems Telebit o US Robotics , incluso el pequeño número de ACK s podría abrumar el canal de retorno y hacer que la transferencia se detuviera.
ZMODEM abordó estos problemas eliminando la necesidad de ACK , permitiendo que el remitente envíe datos continuamente siempre que el receptor no detecte errores. Solo tenían que enviarse los NAK , si y solo si había un problema. Dado que ZMODEM se usaba a menudo en enlaces con corrección de errores incorporada, como X.25, el receptor a menudo no enviaba un solo mensaje al remitente. Como resultado, el sistema enviaría el archivo completo en una secuencia continua, y ZMODEM se refería a sí mismo como un "protocolo de transmisión".
El rendimiento de ZMODEM mejoró tanto con respecto a los protocolos comunes anteriores que generalmente reemplazó incluso a los protocolos especiales como YMODEM-g , que no incluían corrección de errores en absoluto y, en cambio, se basaban en enlaces sin errores mantenidos por los módems. Aunque YMODEM-g era más rápido, la falta de otras características, como transferencias reiniciables, lo hacía menos atractivo.
Reanudar
XMODEM, y la mayoría de los protocolos basados en él, administraban el orden de los paquetes prefijando los datos con un número de paquete del 1 al 255. Las versiones con ventana usaban este número de paquete para indicar qué paquetes se habían recibido correctamente o especificar uno que no. Dado que los paquetes tenían una longitud de 128 bytes, esto significaba que la cantidad máxima de datos que se podían transferir antes de que se transfirieran los números de paquetes era de 32 kB.
ZMODEM reemplazó el número de paquete con la ubicación real en el archivo, indicada por un número de 32 bits. Esto le permitió enviar mensajes NAK que rebobinaban la transferencia hasta el punto de falla, independientemente de la longitud del archivo. Esta misma función también se utilizó para reiniciar las transferencias si fallaban o se interrumpían deliberadamente. En este caso, el receptor buscaría ver cuántos datos se habían recibido previamente y luego enviaría un NAK con esa ubicación, lo que activará automáticamente al remitente para que comience desde ese punto.
Autoencendido
Gestión simplificada de inicio automático al permitir que la máquina emisora inicie la transferencia. Anteriormente, el usuario tenía que solicitar primero el archivo al remitente, colocarlo en un estado de "espera", luego regresar a su programa local e invocar un comando para iniciar la transferencia. Con la transferencia automática, simplemente solicitaban el archivo, el remitente activaba automáticamente la transferencia en el programa del usuario.
Variaciones
Aparecieron varias versiones modificadas de ZMODEM. ZedZap era una variante de ZMODEM con bloques de 8 kbyte para un mejor rendimiento en módems de alta velocidad. LeechZmodem era una variante traviesa de ZMODEM (entre derivados similares de XMODEM y YMODEM) que engañaba las cuotas de descarga de BBS . ADONTEC creó en 2002 y 2007 una extensión compatible con versiones anteriores de ZMODEM con longitudes de bloque de 32 kbytes y 64 kbytes para aumentar el rendimiento en conexiones libres de errores de alta velocidad como las redes ISDN o TCP / IP.
Las implementaciones de ZMODEM más notables fueron de Chuck Forsberg's Omen Technology, Inc. Estas incluyeron DSZ (DOS Send ZMODEM), GSZ (Graphical Send ZMODEM) y el ubicuo (l) rzsz para variantes de Unix.
En tiempos más actuales, los desarrolladores de Synchronet han creado una implementación moderna de X / Y / ZMODEM llamada SEXYZ, basada libremente en el paquete zmtx / zmrx, que se ejecuta de forma nativa en las variantes de Windows y Unix, admite nombres de archivo largos y transferencias de datos más rápidas y confiables . La implementación de ZMODEM de SEXYZ también se ha incorporado al proyecto SyncTERM. Synchronet, SEXYZ y SyncTERM son proyectos de código abierto, multiplataforma y centrados en BBS.
El propio Forsberg recopiló una serie de mejoras en ZMODEM-90. El primero de ellos es MobyTurbo, que eliminó las cotizaciones de control para mejorar aún más el rendimiento, aproximadamente un 15%. Incluso en las redes que "comen" los caracteres de control, ZMODEM-90 se puede adaptar para citar solo aquellos caracteres que la red realmente come, a diferencia de todos los posibles. Una mejora similar permite que ZMODEM-90 funcione en redes de 7 bits, mientras que los protocolos anteriores (con la notable excepción de Kermit ) exigían 8 bits en un grado u otro. Finalmente, ZMODEM-90 incluye un sistema básico de compresión de codificación de longitud de ejecución para mejorar aún más el rendimiento en archivos sin comprimir.
Limitaciones
- Algunos de los paquetes ZMODEM (por ejemplo, ZACK, ZRPOS) incorporan un desplazamiento de bytes dentro del archivo transferido como un entero sin signo de 32 bits. Este diseño limita la viabilidad de ZMODEM para transferir solo archivos de forma confiable con un tamaño inferior a 4 GB.
- Aunque el protocolo podría permitirlo, la implementación de referencia (l) rzsz no puede codificar caracteres arbitrarios sin control (por ejemplo, '~') que a menudo son utilizados por programas de conexión TCP / IP como telnet y ssh como "escape terminal" del lado del cliente. caracteres. Los usuarios deben deshabilitar la función de escape del terminal para lograr transferencias confiables a través de este tipo de enlaces, por ejemplo, ssh -e none user @ hostname.