YMODEM es un protocolo de transferencia de archivos que se utiliza entre microcomputadoras conectadas entre sí mediante módems . Se utilizó 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 . También conocido inicialmente como YAM, se le dio formalmente el nombre "YMODEM" en 1985 por Ward Christensen , autor del XMODEM original.
Protocolo de comunicación | |
Propósito | Protocolo de transferencia de archivos |
---|---|
Desarrollador (es) | Chuck Forsberg |
Introducido | 1985 |
Residencia en | XMODEM |
Influenciado | ZMODEM |
Hardware | modems |
YMODEM extendió XMODEM de tres formas, combinando características que se encuentran en otras variedades de XMODEM extendidas. Al igual que XMODEM-CRC, YMODEM reemplazó la suma de comprobación de 8 bits con una comprobación de redundancia cíclica (CRC) de 16 bits , pero la convirtió en la forma predeterminada de corrección en lugar de opcional. Desde TeLink agregó el encabezado "bloque 0" que enviaba el nombre y el tamaño del archivo, lo que permitía transferencias por lotes (múltiples 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ó 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 solo controlador de protocolo recurra a XMODEM-CRC o incluso a XMODEM cuando se conecta a sistemas que no son YAM. Creía que los programadores querrían implementar tantas de estas características como fuera posible en cualquier plataforma. Estaba consternado al descubrir que la mayoría de las implementaciones en realidad no proporcionaban más de 1k de tamaño de bloque con CRC-16, fallando en implementar el "bloque 0" mientras continuaba usando 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 aquellas versiones que admitían el estándar completo.
Características
XMODEM
El XMODEM original era un protocolo muy simple y esa es la razón de su éxito; podría implementarse en prácticamente cualquier máquina de la época, incluso aquellas con procesadores y almacenamiento muy limitados. Funcionó dividiendo los datos que se enviarían en paquetes de 128 bytes , agregando un encabezado de 3 bytes y un pie de página de suma de comprobación de 1 byte , y enviando los paquetes de 132 bytes resultantes en orden. La computadora receptora recalculó 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 y, si no coincidía, un NAK . Cuando el remitente recibió un ACK , envió el siguiente paquete, mientras que un NAK hizo que volviera a enviar el último.
Hubo varios problemas con el protocolo. El uso de una suma de comprobación simple significaba que algunos errores comunes podían pasar desapercibidos. El tamaño pequeño del paquete y el requisito de esperar el ACK o NAK condujeron a un rendimiento lento en enlaces de mayor velocidad o en aquellos con latencia significativa. Finalmente, como la transferencia no contenía detalles del archivo, todos los archivos debían iniciarse manualmente, lo que podría ser una tarea ardua cuando se estaban transfiriendo muchos archivos pequeños.
Las soluciones a estos problemas se desarrollaron a principios de la década de 1980. XMODEM-CRC reemplazó la suma de verificación con una verificación de redundancia cíclica (CRC) de 16 bits , que era mucho más resistente a los errores comunes. XMODEM-1k expandió el tamaño del paquete 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, agregaron información de archivo para que una sola transferencia pudiera contener varios archivos, lo que permite enviar lotes de archivos con un solo comando.
YMODEM
Desafortunadamente, ninguna de estas versiones expandidas incluía todas estas características. Chuck Forsberg , autor de CP / M "Yet Another Modem program", o YAM, decidió escribir un controlador de protocolo único que admitiera todas estas opciones. Cuando los usuarios iniciaban una transferencia, podían indicar qué opciones querían en la línea de comandos, por ejemplo, diciendo que deseaban utilizar CRC. El protocolo fue escrito para que intentara este estilo, pero retrocedió elegantemente para igualar las capacidades que implementó el software remoto.
Abortar
Un problema con el XMODEM original era que no había una forma definida de cancelar la transferencia una vez iniciada. La solución normal era enviar NAK a cada paquete posterior si el usuario lo solicitaba. Dado que el protocolo XMODEM definió un límite de diez NAK para abortar un envío, y cada paquete podría tardar un segundo en enviarse, esto significaba que había un retraso de diez segundos en el que el remitente enviaba continuamente datos que simplemente se ignoraban.
Algunas implementaciones habían agregado la capacidad de enviar un CAN en lugar de ACK o NAK al final de un paquete recibido para indicar un aborto. Desafortunadamente, existía la posibilidad de que se pudiera generar un CAN por ruido de línea y provocar un aborto. Por lo tanto, YAM modificó esto ligeramente para requerir dos CAN consecutivos, lo que realizaría inmediatamente un "aborto ordenado" en el extremo del remitente.
CRC
El soporte CRC se ha introducido en XMODEM-CRC. Este fue un cambio muy simple al protocolo original; si se solicita, el receptor intentaría activar la transferencia enviando una C inicial en lugar de un NAK . Si el remitente remoto admitía la opción CRC, comenzaría a enviar paquetes de forma normal, pero con un CRC de 16 bits en el pie de página en lugar de la suma de comprobación de 1 byte. YAM admitió esta opción sin cambios.
1k
Se habían introducido paquetes de 1024 bytes en XMODEM-1k. 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 inició dicha conexión, el remitente podrí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.
Paquete cero
Para admitir transferencias automáticas de correo FidoNet , MODEM7 introdujo la capacidad de enviar el nombre del archivo como texto sin formato antes de enviar el primer bloque de datos. Esto no era confiable 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 inició las transferencias con el paquete número uno, por lo que TeLink envió este paquete como el número cero. Este "paquete cero" o "bloque cero" se volvió común en otros sistemas FidoNet como SEAlink y otros.
YAM admitió el formato de paquete cero, pero muchas implementaciones de terceros de YMODEM lo ignoraron. Cuando una implementación intentó enviar el paquete cero a una versión no consciente, el receptor naturalmente NAK el paquete, ya que el paquete cero es ilegal. El remitente entonces vería el NAK como un error de transmisión e intentaría enviar el paquete nuevamente, intentando esto 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 lo sabían, enviaron un NAK , lo que provocó 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 tanto YMODEM como YMODEM Batch listados como dos protocolos separados. Se creó más confusión por la similitud entre XMODEM-1k y estos YMODEM no compatibles, que eran similares al punto de que a menudo se enumeraban incorrectamente como iguales.
Soporte de transmisión
YMODEM-g es una variante de transmisión utilizada para conexiones sin errores. No espera a que se reciba un ACK antes de enviar el siguiente paquete. 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, como es el caso de los módems que admiten MNP, por ejemplo.
Normalmente, el receptor iniciaría una transferencia YMODEM enviando 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 g-protocolo, la transferencia se activa en lugar mediante el envío de un 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 único ACK después de recibir el paquete final, lo que se indica por 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 , rara vez se usaba. Esto se debió en parte a la falta de otras funciones, pero también a un problema más grave. Antes de la aparición del UART 16550 , existía un riesgo sustancial de saturación del búfer en el puerto serie . Aunque esto sería detectado por YMODEM-g, no podría corregirse ya que no es posible la retransmisión en bloque. El receptor tendría que cancelar y reiniciar toda la transmisión desde el principio. ZMODEM, por otro lado, tiene una capacidad de transferencia de currículum que lo hizo más atractivo.
Referencias
- Referencia de protocolo XMODEM / YMODEM por Chuck Forsberg , 10 de octubre de 1985
- Referencia de 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)