YMÓDEM

YMODEM es un protocolo de transferencia de archivos utilizado entre microcomputadoras conectadas entre sí mediante módems . Se utilizaba principalmente para transferir archivos hacia y desde sistemas de tablones de anuncios . YMODEM fue desarrollado por Chuck Forsberg como una expansión de XMODEM y se implementó por primera vez en su programa CP/M YAM . Inicialmente también conocido como YAM, recibió formalmente el nombre de "YMODEM" en 1985 de manos de Ward Christensen , autor del XMODEM original.

YMODEM extendió XMODEM de tres maneras, combinando características encontradas en otras variedades extendidas de XMODEM. Al igual que XMODEM-CRC, YMODEM reemplazó la suma de comprobación de 8 bits con una verificación de redundancia cíclica (CRC) de 16 bits , pero la convirtió en la forma predeterminada de corrección en lugar de opcional. De TeLink agregó el encabezado "bloque 0" que enviaba el nombre y el tamaño del archivo, lo que permitió transferencias por lotes (múltiples archivos en una sola sesión) y eliminó la necesidad de agregar relleno al final del archivo. Finalmente, YMODEM permitió que el tamaño del bloque se aumentara de los 128 bytes de datos originales a 1024, como en XMODEM-1k , lo que mejoró enormemente el rendimiento en módems más rápidos.

Forsberg creó el estándar con todas estas características como opciones de tiempo de ejecución, lo que permite que un único controlador de protocolo recurra a XMODEM-CRC o incluso a XMODEM cuando se conecta a sistemas que no sean YAM. Creía que los programadores querrían implementar tantas de estas características como fuera posible en cualquier plataforma dada. Se sintió consternado al descubrir que la mayoría de las implementaciones en realidad no proporcionaban más que un tamaño de bloque de 1k con CRC-16, no lograban implementar el "bloque 0" y seguían utilizando el nombre YMODEM. El resultado fue el lanzamiento de muchas implementaciones de YMODEM mutuamente incompatibles y el uso del nombre YMODEM Batch para indicar claramente las versiones que sí admitían el estándar completo.

El XMODEM original era un protocolo muy simple y esa es la razón de su éxito; podía implementarse prácticamente en 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, agregando un encabezado de 3 bytes y un pie de página con una suma de comprobación de 1 byte , y enviando los paquetes resultantes de 132 bytes en orden. El equipo 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 de vuelta un ACK y, si no coincidía, un NAK . Cuando el remitente recibía un ACK, enviaba el siguiente paquete, mientras que un NAK hacía que volviera a enviar el último.

El protocolo tenía varios problemas. El uso de una simple suma de comprobación implicaba que algunos errores comunes podían pasar desapercibidos. El pequeño tamaño de los paquetes y el requisito de esperar el ACK o NAK provocaban un rendimiento lento en enlaces de mayor velocidad o con una latencia significativa. Por último, como la transferencia no contenía detalles del archivo, cada archivo debía iniciarse manualmente, lo que podía ser una tarea ardua cuando se transferían muchos archivos pequeños.

A principios de los años 80 se desarrollaron soluciones a estos problemas. XMODEM-CRC sustituyó la suma de comprobación por una comprobación de redundancia cíclica (CRC) de 16 bits, que era mucho más resistente a los errores comunes. XMODEM-1k amplió el tamaño de los paquetes de 128 bytes a 1024, mejorando el rendimiento en conexiones de mayor velocidad, mientras que otros, como WXMODEM y SEAlink, introdujeron sistemas de ventana deslizante para combatir tanto el rendimiento como la latencia, a costa de cierta complejidad. Otros, como TeLink y MODEM7, añadieron información de archivo para que una única transferencia pudiera contener varios archivos, lo que permitía enviar lotes de archivos con un único comando.

Chuck Forsberg , autor del programa CP/M "Yet Another Modem", o YAM, decidió escribir un controlador de protocolo único que admitiera muchas funciones en comparación con XMODEM y lo llamó YMODEM. Cuando los usuarios iniciaban una transferencia podían indicar qué opciones querían en la línea de comandos, por ejemplo, diciendo que querían usar CRC. El protocolo se escribió de manera que intentara este estilo, pero que retrocediera elegantemente para adaptarse a las capacidades que implementara el software remoto.

Un problema con el XMODEM original era que no había una manera definida de abortar la transferencia una vez comenzada. La solución normal era enviar NAK a cada paquete subsiguiente si el usuario lo solicitaba. Dado que el protocolo XMODEM definía un límite de diez NAK para abortar un envío, y cada paquete podía tardar un segundo en enviarse, esto significaba que había una demora de diez segundos en la que el remitente enviaba continuamente datos que simplemente se ignoraban.

Algunas implementaciones habían agregado la capacidad de enviar un CAN en lugar de un ACK o NAK al final de un paquete recibido para indicar un aborto. Desafortunadamente, existía la posibilidad de que un CAN pudiera generarse por ruido en la línea y desencadenar un aborto. Por lo tanto, YAM modificó esto ligeramente para requerir dos CAN consecutivos, lo que realizaría inmediatamente un "aborto elegante" en el extremo del remitente.

La compatibilidad con CRC se había introducido en XMODEM-CRC. Se trataba de un cambio muy simple en el protocolo original: si se lo solicitaba, el receptor intentaría activar la transferencia enviando una C inicial en lugar de una NAK . Si el remitente remoto admitía la opción CRC, comenzaría a enviar paquetes de forma normal, pero con una CRC de 16 bits en el pie de página en lugar de la suma de comprobación de 1 byte. YAM admitía esta opción sin cambios.

Los paquetes de 1024 bytes se habían introducido en XMODEM-1k. ^[1] Esta versión no cambió el carácter de activación del receptor, por lo que no había forma de que el remitente supiera si el receptor admitía paquetes más grandes. En cambio, XMODEM-1k se presentó como un protocolo separado en ambos extremos de la conexión. Cuando se iniciaba una conexión de este tipo, el remitente podía elegir enviar 1024 bytes en un paquete o 128, indicando el más grande 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 asumió CRC para todas las conexiones. YAM admitió 1k sin cambios.

Para permitir transferencias automáticas de correo FidoNet , MODEM7 introdujo la capacidad de enviar el nombre del archivo como texto simple antes de enviar el primer bloque de datos. Esto no era confiable y TeLink lo mejoró al colocar 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 número cero. Este "paquete cero" o "bloque cero" se volvió común 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 reconocía, el receptor, naturalmente, rechazaba el paquete, ya que el paquete cero es ilegal. El remitente entonces veía el rechazo como un error de transmisión e intentaba enviar el paquete nuevamente, intentándolo diez veces antes de fallar.

Por razones que no están del todo claras, muchas implementaciones de YMODEM no implementaron esta característica. Como no estaban al tanto de ella, enviaban un NAK , lo que desencadenaba una serie de intentos de reenvío antes de fallar. Esto significaba que si el usuario optaba por utilizar un YMODEM compatible con una versión no compatible, las transferencias fallarían. Sin embargo, estas versiones no compatibles eran comunes.

Como resultado, era común ver que tanto YMODEM como YMODEM Batch aparecían como dos protocolos separados. La confusión se agravó por la similitud entre XMODEM-1k y estos YMODEM no compatibles, que eran tan similares que a menudo se los enumeraba incorrectamente como el mismo.

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; XON/XOFF se utiliza para el control de flujo . El protocolo es más rápido que YMODEM porque no se introduce latencia entre paquetes, pero no tiene capacidad para corregir errores. Depende de que la conexión subyacente esté libre de errores, ^[1] que es el caso de los módems que admiten MNP, por ejemplo.

Normalmente, una transferencia YMODEM se iniciaría mediante el envío de una C por parte del receptor para indicar que desea utilizar el formato de 128 bytes con CRC, o NAK si desea utilizar el sistema de suma de comprobación original. Cuando se desea el protocolo g, la transferencia se activa enviando una G. Si el remitente no admite el protocolo g, considera que se trata de un error y lo ignora, pero si admite g, comienza a enviar paquetes en un flujo continuo. Solo espera un único ACK después de recibir el paquete final, lo que se indica mediante la presencia de un carácter EOT en los datos. YMODEM-g supone que hay 1k paquetes disponibles.

Sin embargo, a pesar de que este protocolo era potencialmente más rápido que ZMODEM , todavía se usaba raramente. Esto se debía en parte a la falta de otras funciones, pero también a un problema más serio. Antes de la aparición del UART 16550 , existía un riesgo sustancial de desbordamiento del búfer en el puerto serie . Aunque YMODEM-g lo detectaría, no se podría corregir ya que no es posible la retransmisión de bloques. El receptor tendría que cancelar y reiniciar toda la transmisión desde el principio. ZMODEM , por otro lado, tiene capacidad de reanudación de transferencia, lo que lo hizo más atractivo.

• 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)