Hispanopedia WikiYMODEM es un protocolo de transferencia de archivos utilizado entre microcomputadoras conectadas mediante módems . Se utilizaba principalmente para transferir archivos desde y hacia sistemas de tablones de anuncios . Chuck Forsberg desarrolló YMODEM como una extensión de XMODEM y se implementó por primera vez en su programa CP/M YAM . Inicialmente conocido también como YAM, Ward Christensen , autor del XMODEM original, le dio formalmente el nombre de "YMODEM" en 1985 .
YMODEM extendió XMODEM de tres maneras, combinando características presentes en otras variantes extendidas de XMODEM. Al igual que XMODEM-CRC, YMODEM reemplazó la suma de verificación de 8 bits con una verificación de redundancia cíclica (CRC) de 16 bits , pero la convirtió en la forma de corrección predeterminada en lugar de opcional. De TeLink, añadió el encabezado "bloque 0" que enviaba el nombre y el tamaño del archivo, lo que permitía transferencias por lotes (varios archivos en una sola sesión) y eliminaba la necesidad de agregar relleno al final del archivo. Finalmente, YMODEM permitió aumentar el tamaño del bloque de los 128 bytes de datos originales a 1024, como en XMODEM-1k , lo que mejoró considerablemente el rendimiento en módems más rápidos.
Forsberg diseñó el estándar con todas estas características como opciones de ejecución, lo que permitía que un único controlador de protocolo recurriera a XMODEM-CRC o incluso a XMODEM al conectarse a sistemas que no fueran YAM. Creía que los programadores querrían implementar tantas de estas características como fuera posible en cualquier plataforma. Se sintió consternado al descubrir que la mayoría de las implementaciones solo ofrecían un tamaño de bloque de 1k con CRC-16, sin implementar el "bloque 0" y manteniendo el nombre YMODEM. El resultado fue el lanzamiento de numerosas implementaciones de YMODEM incompatibles entre sí, y el uso del nombre YMODEM Batch para indicar claramente las versiones que sí admitían el estándar completo.
Características
XMODEM
El protocolo XMODEM original era muy sencillo, y esa es la razón de su éxito: podía implementarse en prácticamente cualquier máquina de la época, incluso en aquellas con procesadores y almacenamiento muy limitados. Funcionaba dividiendo los datos a enviar en paquetes de 128 bytes , añadiendo una cabecera de 3 bytes y un pie de página con suma de comprobación de 1 byte , y enviando los paquetes resultantes de 132 bytes en orden. El ordenador receptor recalculaba la suma de comprobación a partir de los 128 bytes de datos y, si coincidía con la suma de comprobación enviada en el pie de página, enviaba un ACK ; de lo contrario, un NAK . Cuando el remitente recibía un ACK, enviaba el siguiente paquete, mientras que un NAK hacía que reenviara el anterior.
El protocolo presentaba varios problemas. El uso de una suma de verificación simple implicaba que algunos errores comunes podían pasar desapercibidos. El pequeño tamaño de los paquetes y la necesidad de esperar la confirmación (ACK) o la confirmación negativa (NAK) provocaban un rendimiento lento en enlaces de alta velocidad o con latencia significativa. Finalmente, dado que la transferencia no incluía detalles del archivo, cada archivo debía iniciarse manualmente, lo que podía resultar tedioso al transferir muchos archivos pequeños.
A principios de la década de 1980 se desarrollaron soluciones a estos problemas. XMODEM-CRC reemplazó la suma de verificación con una verificación de redundancia cíclica (CRC) de 16 bits, mucho más resistente a los errores comunes. XMODEM-1k amplió el tamaño del paquete de 128 bytes a 1024, mejorando el rendimiento en conexiones de alta velocidad, mientras que otros, como WXMODEM y SEAlink, introdujeron sistemas de ventana deslizante para combatir tanto el rendimiento como la latencia, a costa de una mayor complejidad. Otros, como TeLink y MODEM7, añadieron información de archivos para que una sola transferencia pudiera contener varios archivos, permitiendo el envío de lotes de archivos con un solo comando.
YMODEM
Chuck Forsberg , autor del programa CP/M "Yet Another Modem" (YAM), decidió escribir un controlador de protocolo único que admitiera muchas más funciones que XMODEM y lo llamó YMODEM. Al iniciar una transferencia, los usuarios podían indicar las opciones que deseaban en la línea de comandos; por ejemplo, indicar que querían usar CRC. El protocolo se diseñó para intentar usar este método, pero adaptándose automáticamente a las capacidades implementadas por el software remoto.
Abortar
Un problema del XMODEM original era que no existía una forma definida de abortar la transferencia una vez iniciada. La solución habitual consistía en enviar mensajes NAK a cada paquete subsiguiente si el usuario lo solicitaba. Dado que el protocolo XMODEM establecía un límite de diez mensajes NAK para abortar un envío, y cada paquete podía tardar un segundo en enviarse, esto implicaba un retraso de diez segundos durante el cual el remitente enviaba continuamente datos que simplemente se ignoraban.
Algunas implementaciones habían añadido la capacidad de enviar un CAN en lugar de un ACK o un NAK al final de un paquete recibido para indicar una interrupción. Desafortunadamente, existía la posibilidad de que un CAN generado por ruido en la línea provocara una interrupción. Por lo tanto, YAM modificó ligeramente este comportamiento para requerir dos CAN consecutivos, lo que provocaría inmediatamente una "interrupción controlada" en el extremo del remitente.
CRC
La compatibilidad con CRC se introdujo en XMODEM-CRC. Este fue un cambio muy sencillo al protocolo original: si se solicitaba, el receptor intentaba iniciar la transferencia enviando una C inicial en lugar de una NAK . Si el remitente remoto admitía la opción CRC, comenzaba a enviar paquetes con normalidad, pero con un CRC de 16 bits en el pie de página en lugar de la suma de verificación de 1 byte. YAM admitía esta opción sin modificaciones.
1k
Los paquetes de 1024 bytes se introdujeron en XMODEM-1k. [ 1 ] Esta versión no cambió el carácter de activación del receptor, por lo que el remitente no tenía forma de saber si el receptor admitía paquetes más grandes. En cambio, XMODEM-1k se presentaba como un protocolo separado en ambos extremos de la conexión. Cuando se iniciaba dicha conexión, el remitente podía elegir enviar 1024 bytes en un paquete o 128, indicando el mayor con un carácter STX en el encabezado en lugar del SOH normal . Normalmente, solo los últimos paquetes usarían los paquetes más pequeños, para evitar enviar grandes cantidades de relleno. 1k también asumía CRC para todas las conexiones. YAM admitía 1k sin cambios.
Paquete cero
Para admitir las transferencias automatizadas de correo FidoNet , MODEM7 introdujo la capacidad de enviar el nombre del archivo como texto plano antes de enviar el primer bloque de datos. Esto no era fiable, y TeLink lo mejoró colocando el nombre del archivo, y opcionalmente otros datos como la fecha de creación y la longitud del archivo, en un paquete completo de 128 bytes. XMODEM iniciaba las transferencias con el paquete número uno, por lo que TeLink enviaba este paquete como el número cero. Este "paquete cero" o "bloque cero" se generalizó en otros sistemas FidoNet como SEAlink y otros.
YAM admitía el formato de paquete cero, pero muchas implementaciones de terceros de YMODEM lo ignoraban. Cuando una implementación intentaba enviar el paquete cero a una versión que no lo admitía, el receptor rechazaba el paquete, ya que el paquete cero no es válido. El remitente interpretaba entonces el rechazo como un error de transmisión e intentaba enviar el paquete de nuevo, repitiendo el proceso diez veces antes de fallar.
Por razones que no están del todo claras, muchas implementaciones de YMODEM no implementaron esta función. Al desconocerla, enviaban un NAK , lo que provocaba una serie de intentos de reenvío antes de que la transferencia fallara. Esto significaba que si el usuario optaba por utilizar una versión de YMODEM compatible con una versión no compatible, las transferencias fallarían. Sin embargo, dichas versiones no compatibles eran comunes.
Como resultado, era común ver tanto YMODEM como YMODEM Batch listados como dos protocolos distintos. La similitud entre XMODEM-1k y estos YMODEM no conformes generó aún más confusión, hasta el punto de que a menudo se los catalogaba erróneamente como si fueran el mismo.
Soporte de transmisión
YMODEM-G es una variante de transmisión que se utiliza para conexiones sin errores. No espera a recibir un ACK antes de enviar el siguiente paquete; se utiliza XON/XOFF para el control de flujo . El protocolo es más rápido que YMODEM porque no introduce latencia entre paquetes, pero no tiene capacidad para corregir errores. Depende de que la conexión subyacente esté libre de errores, [ 1 ] como es el caso de los módems que admiten MNP, por ejemplo.
Normalmente, una transferencia YMODEM se inicia cuando el receptor envía una C para indicar que desea usar el formato de 128 bytes con CRC, o NAK si desea usar el sistema de suma de verificación original. Cuando se desea el protocolo g, la transferencia se activa enviando una G. Si el remitente no admite el protocolo g, lo considera un error y lo ignora; pero si lo admite, comienza a enviar paquetes en un flujo continuo. Solo espera un ACK después de recibir el último paquete, lo cual se indica mediante la presencia de un carácter EOT en los datos. YMODEM-g asume que hay 1k paquetes disponibles.
Sin embargo, a pesar de que este protocolo era potencialmente más rápido que ZMODEM, su uso seguía siendo escaso. Esto se debía en parte a la falta de otras funcionalidades, pero también a un problema más grave. Antes de la aparición del UART 16550 , existía un riesgo considerable de desbordamiento de búfer en el puerto serie . Si bien YMODEM-g lo detectaba, no podía corregirse, ya que no es posible la retransmisión de bloques. El receptor tenía que cancelar y reiniciar toda la transmisión desde el principio. ZMODEM , en cambio, cuenta con la capacidad de reanudar la transferencia, lo que lo hacía más atractivo.
Referencias
- Referencia del protocolo XMODEM/YMODEM por Chuck Forsberg , 10 de octubre de 1985
- Referencia del protocolo XMODEM / YMODEM por Chuck Forsberg , 18 de junio de 1988 (documento reformateado el 14 de octubre de 1988) (versión HTML con problemas de texto)
- protocolos de transferencia de archivos BBS