Hispanopedia Wiki
Articulo de referencia

XMODEM

[https://books.google.com/books?id=9eJxx_ZGKngC&dq=%22Ward+Christensen%22&pg=PA451 Telecommunications: XMODEM: A Standard Is Born], By Alfred Glossbrenner, PC Mag, 17 April 1984...

Hispanopedia WikiContenido en espanolLectura gratuita

XMODEM es un protocolo de transferencia de archivos simple desarrollado rápidamente por Ward Christensen para su programa de terminal MODEM.ASM de 1977. Permitía a los usuarios transmitir archivos entre sus computadoras cuando ambas utilizaban MODEM. Keith Petersen realizó una pequeña actualización para activar siempre el "modo silencioso" y denominó al resultado XMODEM. [ 3 ] [ 4 ]

XMODEM, al igual que la mayoría de los protocolos de transferencia de archivos, divide los datos originales en una serie de " paquetes " que se envían al receptor, junto con información adicional que le permite determinar si el paquete se recibió correctamente. Si se detecta un error, el receptor solicita que se reenvíe el paquete. Una secuencia de paquetes erróneos provoca la interrupción de la transferencia.

XMODEM se hizo extremadamente popular en el mercado inicial de sistemas de tablón de anuncios (BBS), principalmente por su sencillez de implementación. También era bastante ineficiente, y a medida que aumentaba la velocidad de los módems, este problema llevó al desarrollo de varias versiones modificadas de XMODEM para mejorar el rendimiento o solucionar otros problemas del protocolo. [ 4 ] Christensen creía que su XMODEM original era "el programa más modificado en la historia de la informática". [ 5 ]

Chuck Forsberg recopiló varias modificaciones comunes en su protocolo YMODEM , pero una mala implementación provocó una mayor fragmentación antes de que se unificaran con su posterior protocolo ZMODEM . ZMODEM se hizo muy popular, pero nunca llegó a reemplazar por completo a XMODEM en el mercado de los BBS.

Estructura del paquete

El XMODEM original utilizaba un paquete de datos de 128 bytes, el tamaño de bloque empleado en los disquetes CP/M . El paquete iba precedido de una cabecera simple de 3 bytes que contenía un carácter, un número de bloque del 1 al 255 y su inverso (255 menos el número de bloque). La numeración de los bloques comenzaba en 1 para el primer bloque enviado, no en 0. A la cabecera le seguían los 128 bytes de datos y, a continuación, una suma de comprobación de un byte . Esta suma era la suma de los 128 bytes de datos del paquete módulo 256. Por lo tanto, el paquete completo tenía una longitud de 132 bytes y contenía 128 bytes de datos útiles , lo que resultaba en una eficiencia total del canal de aproximadamente el 97 %.<SOH>

El archivo se marcó como "completo" con un carácter enviado después del último bloque. Este carácter no estaba en un paquete, sino que se enviaba solo como un byte. Dado que la longitud del archivo no se enviaba como parte del protocolo, el último paquete se rellenaba con un "carácter conocido" que podía descartarse. En la especificación original, este carácter era por defecto 0,26 decimal, que CP/M utilizaba como marcador de fin de archivo en su propio formato de disco. El estándar sugería que se podía usar cualquier carácter para el relleno, pero no había forma de modificarlo dentro del protocolo ; si una implementación cambiaba el carácter de relleno, solo los clientes que usaran la misma implementación interpretarían correctamente el nuevo carácter.<EOT><SUB>

Detalles de la transferencia

Los archivos se transferían paquete por paquete. Al recibirlos, el receptor calculaba la suma de verificación del paquete y la comparaba con la recibida del remitente al final del paquete. Si coincidían, el receptor enviaba un mensaje al remitente, quien a su vez enviaba el siguiente paquete en secuencia. Si había algún problema con la suma de verificación, el receptor enviaba un error . Si se recibía un error, el remitente reenviaba el paquete [ 4 ] y continuaba intentándolo varias veces, normalmente diez, antes de abortar la transferencia.<ACK><NAK><NAK>

También se enviaba una <NAK>alerta si el receptor no recibía un paquete válido en diez segundos, aunque seguía esperando datos debido a la falta de un <EOT>carácter. Además, se utilizaba un tiempo de espera de siete segundos dentro de cada paquete para evitar la pérdida de conexiones durante la transmisión.

Los números de bloque también se examinaron de forma sencilla para detectar errores. Tras recibir un paquete correctamente, el siguiente debía tener un número uno más. Si, en cambio, recibía el mismo número de bloque, no se consideraba un problema grave; se entendía que <ACK>el remitente no lo había recibido y, por lo tanto, había reenviado el paquete. Cualquier otro número de bloque indicaba que se habían perdido paquetes.

Las transferencias eran gestionadas por el receptor; el transmisor no enviaba datos hasta que <NAK>el receptor enviaba una solicitud inicial. Esto era una consecuencia lógica de la interacción del usuario con la máquina emisora, que se encontraba remotamente. El usuario navegaba hasta el archivo solicitado en la máquina emisora ​​y luego le pedía que lo transfiriera. Una vez emitida esta orden, el usuario ejecutaba un comando en su software local para comenzar a recibir. Dado que se desconocía el tiempo transcurrido entre la solicitud del archivo al sistema remoto y la emisión del comando local para recibir, XMODEM permitía hasta 90 segundos para que el receptor comenzara a enviar solicitudes de paquetes de datos.

Problemas

Aunque XMODEM era lo suficientemente robusto como para que un periodista en 1982 transmitiera historias desde Pakistán a los Estados Unidos con un Osborne 1 y un acoplador acústico a través de líneas telefónicas de mala calidad, [ 6 ] el protocolo tenía varios defectos.

Problemas menores

XMODEM fue escrito para máquinas CP/M y presenta varias características propias de ese sistema operativo . En particular, los archivos en CP/M siempre eran múltiplos de 128 bytes, y su final se marcaba dentro de un bloque con el <EOT>carácter. Estas características se incorporaron directamente a XMODEM. Sin embargo, otros sistemas operativos no presentaban ninguna de estas peculiaridades, y la introducción generalizada de MS-DOS a principios de la década de 1980 obligó a actualizar XMODEM para que reconociera el carácter <EOT>o<EOF> como marcador de fin de archivo.

Durante un tiempo se sugirió que se admitiera el envío de un carácter en lugar de un o para abortar fácilmente la transferencia desde el extremo receptor. De igual manera, un recibido en lugar del indicaba que el remitente deseaba cancelar la transferencia. Sin embargo, este carácter podía "crearse" fácilmente mediante simples errores relacionados con el ruido en lo que se pretendía que fuera un o . Se propuso un doble para evitar este problema, pero no está claro si se implementó ampliamente.<CAN><ACK><NAK><CAN><SOH><ACK><NAK><CAN>

Problemas importantes

XMODEM se diseñó para ser simple, sin mucho conocimiento de otros protocolos de transferencia de archivos, que de todos modos eran bastante raros. Debido a su simplicidad, existían varios errores muy básicos que podían provocar que una transferencia fallara o, peor aún, que resultara en un archivo incorrecto que el protocolo no detectaba. Esto se debía principalmente al uso de una suma de verificación simple para la corrección de errores, [ 4 ] que es susceptible a errores no detectados en los datos si dos bits están invertidos, lo cual puede ocurrir con una breve ráfaga de ruido. Además, un daño similar en el encabezado o la suma de verificación podía provocar una transferencia fallida en casos en los que los datos en sí no estuvieran dañados.

Muchos autores introdujeron extensiones a XMODEM para solucionar estos y otros problemas. Muchos solicitaron que estas extensiones se incluyeran en un nuevo estándar XMODEM. Sin embargo, Ward Christensen se negó, ya que precisamente la falta de estas características, y la codificación necesaria para soportarlas, fue lo que propició la amplia difusión de XMODEM. Como explicó:

Fue un apaño improvisado, totalmente espontáneo (como todo lo que hago), para satisfacer una necesidad personal de comunicarme con otras personas. Solo el hecho de haberlo hecho en agosto de 1977 y de haberlo publicado inmediatamente lo convirtió en el estándar que es hoy.
...Las personas que sugieren que haga cambios SIGNIFICATIVOS al protocolo, como 'dúplex completo', 'múltiples bloques pendientes', 'múltiples destinos', etc., no entienden que la increíble simplicidad del protocolo es una de las razones por las que ha sobrevivido.

Transferencias por lotes

Otro problema con XMODEM era que requería que la transferencia fuera realizada por el usuario en lugar de automatizada. [ 4 ] Normalmente, esto significaba que el usuario debía navegar en el sistema del remitente para seleccionar el archivo que deseaba y luego usar un comando para poner ese sistema en modo "listo para enviar". A continuación, iniciaba la transferencia desde su extremo mediante un comando en su emulador de terminal. Si el usuario quería transferir otro archivo, tenía que repetir este proceso.

Para las transferencias automatizadas entre dos sitios, se implementaron con el tiempo varios complementos al protocolo XMODEM. Estos generalmente asumían que el remitente continuaría enviando archivo tras archivo, mientras que el receptor intentaría iniciar la transferencia enviando un mensaje NAKcomo de costumbre. Cuando el NAKmensaje expiraba, se podía asumir que no había más archivos o que la conexión se había interrumpido.

MÓDEM7

MODEM7 , también conocido como MODEM7 batch o Batch XMODEM , fue la primera extensión conocida del protocolo XMODEM. Una transferencia de archivos XMODEM normal comienza con el receptor enviando un solo NAKcarácter al remitente, quien luego comienza a enviar otro SOHpara indicar el inicio de los datos, seguido de paquetes de datos.

MODEM7 modificó este comportamiento solo ligeramente, enviando el nombre del archivo, en formato de nombre de archivo 8.3 , antes del <SOH>. Cada carácter se enviaba individualmente y el receptor debía reenviarlo como una forma de corrección de errores. Para una implementación XMODEM no consciente, estos datos simplemente se ignorarían mientras esperaba la SOHllegada del , por lo que los caracteres no se reenviarían y la implementación podría recurrir al XMODEM convencional. Con software "consciente", el nombre del archivo podría usarse para guardar el archivo localmente. Las transferencias podrían continuar con otro <NAK>, cada archivo se guarda con el nombre que se envía al receptor.

En 1983, Jerry Pournelle describió MODEM7 como "probablemente el programa de comunicaciones para microcomputadoras más popular que existe". [ 7 ]

MODEM7 enviaba el nombre del archivo como texto normal, lo que significaba que podía corromperse por los mismos problemas que XMODEM intentaba evitar. Esto llevó a la introducción de TeLink por parte de Tom Jennings , autor de los servicios de correo originales de FidoNet .

TeLink evitó los problemas de MODEM7 estandarizando un nuevo "paquete cero" que contenía información sobre el archivo original. Esto incluía el nombre, el tamaño y la marca de tiempo del archivo , que se colocaban en un bloque XMODEM regular de 128 bytes. Mientras que una transferencia XMODEM normal comenzaba con el remitente enviando el "bloque 1" con una <SOH>cabecera, el paquete de cabecera de TeLink se etiquetaba como "bloque 0" y comenzaba con un <SYN>. El paquete contenía la fecha y hora de creación del archivo, el nombre del archivo de hasta 16 caracteres, el tamaño del archivo como un valor de 4 bytes y el nombre del programa que enviaba el archivo. [ 8 ]

Una implementación normal de XMODEM simplemente descartaría el paquete, asumiendo que el número de paquete estaba dañado. Pero esto generaba un posible retraso si el paquete se descartaba, ya que el emisor no podía saber si el receptor había respondido con un error <NAK>porque no entendía el paquete cero o porque había habido un error de transmisión. Como TeLink normalmente solo lo usaba el software de FidoNet , que lo exigía como parte de los estándares de FidoNet, esto no representaba un problema en la práctica, ya que ambos extremos siempre admitirían este estándar. [ 8 ]

El sistema básico de "bloque 0" se convirtió en un estándar en la comunidad FidoNet y fue reutilizado por varios protocolos futuros como SEAlink y YMODEM .

XMODEM-CRC

La suma de verificación utilizada en el protocolo original era extremadamente simple, y ciertos tipos de errores dentro del paquete podían pasar desapercibidos. Esto llevó a la introducción de XMODEM-CRC por John Byrns, [ 9 ] [ 10 ] que utilizaba un CRC de 16 bits en lugar de la suma de verificación de 8 bits. [ 4 ] Los CRC codifican no solo los datos en el paquete, sino también su ubicación, lo que permite detectar los errores de reemplazo de bits que una suma de verificación no detectaría. Estadísticamente, esto hacía que la probabilidad de detectar un error de menos de 16 bits fuera del 99,9969 %, e incluso mayor para cadenas de bits de error más largas. [ 11 ]

XMODEM-CRC fue diseñado para ser retrocompatible con XMODEM. Para ello, el receptor enviaba un Ccarácter (C mayúscula) en lugar de un <NAK>para iniciar la transferencia. Si el remitente respondía enviando un paquete, se asumía que el remitente "conocía" XMODEM-CRC, y el receptor continuaba enviando C. Si no llegaba ningún paquete, el receptor asumía que el remitente no conocía el protocolo y enviaba un <NAK>para iniciar una transferencia XMODEM "tradicional". [ 11 ]

Desafortunadamente, este intento de retrocompatibilidad tuvo un inconveniente. Dado que era posible que el Ccarácter inicial se perdiera o se corrompiera, no se podía asumir que el receptor no admitiera XMODEM-CRC si el primer intento de iniciar la transferencia fallaba. Por lo tanto, el receptor intentaba iniciar la transferencia tres veces con C, esperando tres segundos entre cada intento. Esto significaba que si el usuario seleccionaba XMODEM-CRC al intentar comunicarse con cualquier XMODEM, como estaba previsto, existía un posible retraso de 10 segundos antes de que comenzara la transferencia. [ 11 ]

Para evitar la demora, el remitente y el receptor generalmente listaban XMODEM-CRC por separado de XMODEM, lo que permitía al usuario seleccionar XMODEM "básico" si el remitente no lo listaba explícitamente. Para el usuario promedio, XMODEM-CRC era esencialmente un "segundo protocolo" y se trataba como tal. Sin embargo, esto no ocurría con los servidores de correo de FidoNet, donde CRC se definía como el estándar para todas las transferencias de TeLink. [ 8 ]

Mayor rendimiento

Dado que el protocolo XMODEM requería que el emisor se detuviera y esperara un <ACK>mensaje <NAK>del receptor, solía ser bastante lento. En la era de los  módems de 300 bits/s, el paquete completo de 132 bytes requería 4,4  segundos para enviarse (132 bytes * (8 bits por byte + 1 bit de inicio + 1 bit de parada) / 300 bits por segundo). Suponiendo que  el mensaje del receptor tarda 0,2 segundos <ACK>en regresar al emisor y que el siguiente paquete comience a llegar al receptor (0,1  segundos en ambas direcciones), el tiempo total para un paquete sería de 4,6  segundos, lo que representa una eficiencia del canal ligeramente superior al 92 %.

El tiempo del proceso <ACK>/ <NAK>era una función fija de la red de comunicaciones subyacente, no del rendimiento de los módems. A medida que aumentaba la velocidad de los módems, el retardo fijo crecía en proporción al tiempo necesario para enviar el paquete. Por ejemplo, a 2400  bit/s, los paquetes tardaban solo 0,55  segundos en enviarse, por lo que si el <ACK>/ <NAK>aún tardaba 0,2  segundos en regresar al equipo del usuario, la eficiencia había caído al 71%. A 9600  bit/s, es de poco menos del 40%: se invierte más tiempo esperando la respuesta que el necesario para enviar el paquete.

Se introdujeron varias versiones nuevas de XMODEM para solucionar estos problemas. Al igual que las extensiones anteriores, estas versiones tendían a ser retrocompatibles con el XMODEM original, lo que, también como ocurrió con dichas extensiones, provocó una mayor fragmentación del entorno XMODEM en el emulador de terminal del usuario. Finalmente, surgieron docenas de versiones de XMODEM.

WXModem

WXmodem , abreviatura de "Windows Xmodem", es una variante de XMODEM desarrollada por Peter Boswell en 1986 para su uso en líneas de alta latencia, específicamente sistemas públicos X.25 y PC Pursuit . Estos sistemas tienen latencias mucho mayores que el servicio telefónico convencional , lo que resulta en una eficiencia muy baja en XMODEM. Además, estas redes suelen utilizar caracteres de control para el control de flujo y otras tareas; en particular, XON/XOFF detiene el flujo de datos. Finalmente, en caso de un error que requiriera un reenvío, a veces era difícil saber si se SOHtrataba de un indicador de paquete o simplemente de ruido. WXmodem adaptó XMODEM-CRC para solucionar estos problemas. [ 11 ]

Un cambio consistió en escapar un pequeño conjunto de caracteres de control: DLE, XON, XOFFy SYN. Estos se escaparon insertando un DLEdelante de ellos y luego modificando el carácter mediante una operación XOR con 64. En teoría, esto significaba que el paquete podría tener hasta 264 bytes si originalmente consistía únicamente en caracteres que requerían escape. Estos caracteres insertados y modificados no forman parte del cálculo del CRC; se eliminan y se convierten en el extremo receptor antes de calcular el CRC. [ 11 ]

Además, todos los paquetes tenían un prefijo de SYNcarácter, lo que significaba que el inicio del paquete era SYNSOH, lo que reducía la posibilidad de que un carácter disperso SOHse confundiera con una cabecera de paquete en varios casos de error. Un carácter no escapado SYNencontrado en el cuerpo de un paquete era un error. [ 11 ]

El cambio principal en WXMODEM es el uso de una ventana deslizante para mejorar el rendimiento en enlaces de alta latencia. Para ello, los ACKmensajes iban seguidos del número de paquete que estaban ACKenviando o NAKenviando. El receptor no tiene que enviar ACKtodos los paquetes; puede enviar ACKcualquier número entre uno y cuatro paquetes. Un error ACKcon el número de secuencia del cuarto paquete implica que se envían ACKlos cuatro paquetes. Un error provoca que NAKse envíe inmediatamente un mensaje, con todos los paquetes desde ese número y después de ser reenviados. [ 11 ]

El requisito de reenviar ACKcada cuatro paquetes hace que el sistema funcione como si tuviera un tamaño de paquete de 512  bytes, pero en caso de error, normalmente solo se requieren 128  bytes para reenviar. Además, reduce la cantidad de datos que fluyen en sentido inverso en un factor de cuatro. Esto tiene poca relevancia en el funcionamiento dúplex completo típico de un módem , pero es importante en sistemas semidúplex como los modelos Telebit , que tienen una velocidad de 19  kB en una dirección y 75  bits/s en el canal de retorno .

Uno de los primeros programas de correo de terceros para el sistema FidoNet fue SEAdog , escrito por el mismo autor que el formato de compresión de datos .arc, entonces popular. SEAdog incluía una amplia variedad de mejoras, entre ellas SEAlink , un protocolo de transferencia mejorado basado en el mismo concepto de ventana deslizante que WXmodem. [ 12 ] Se diferenciaba de WXmodem principalmente en detalles.

Una diferencia es que SEAlink admitía el "paquete cero" introducido por TeLink, que es necesario para funcionar como un reemplazo directo de TeLink en sistemas FidoNet donde se esperaba el encabezado. ACKLos y NAKse extendieron a "paquetes" de tres bytes, comenzando con ACKo NAK, luego el número de paquete, luego el complemento del número de paquete, de la misma manera que el encabezado de paquete XMODEM original. El tamaño de la ventana normalmente se establecía en seis paquetes. [ 12 ]

No se esperaba que SEAlink operara sobre enlaces X.25 o similares, por lo que no realizaba el escape. Esto también era necesario para que el paquete cero funcionara correctamente, ya que este estándar utilizaba el SYNcarácter que WXmodem había reutilizado. [ 12 ] Además de estos cambios, se añadió un modo "Sobrecarga" para enlaces semidúplex. Esto suprimía los ACK para los paquetes que se transferían correctamente, lo que en la práctica hacía que la ventana fuera de tamaño infinito. Este modo se indicaba mediante un indicador en el bloque cero. [ 12 ]

Posteriormente, SEAlink incorporó varias mejoras y se convirtió en un protocolo útil de propósito general. Sin embargo, su uso siguió siendo poco común fuera del entorno FidoNet y rara vez se veía en software orientado al usuario.

XMODEM-1K

Otra forma de solucionar el problema del rendimiento es aumentar el tamaño de los paquetes. Si bien el problema fundamental de la latencia persiste, la velocidad a la que se convierte en un problema es mayor. El XMODEM-1K con paquetes de 1024 bytes [ 4 ] fue la solución más popular. En este caso, el rendimiento a 9600  bit/s es del 81%, con las mismas suposiciones que las anteriores.

XMODEM-1K era una versión ampliada de XMODEM-CRC, que indicaba un tamaño de bloque mayor en el remitente al iniciar un paquete con el <STX>carácter en lugar de <SOH>. Al igual que otras extensiones XMODEM compatibles con versiones anteriores, se pretendía que una transferencia -1K pudiera iniciarse con cualquier implementación de XMODEM en el otro extremo, desactivando las funciones según fuera necesario.

XMODEM-1K fue originalmente una de las muchas mejoras a XMODEM introducidas por Chuck Forsberg en su protocolo YMODEM . Forsberg sugirió que las diversas mejoras eran opcionales, esperando que los desarrolladores de software implementaran tantas como fuera posible. Sin embargo, generalmente implementaron lo mínimo indispensable, lo que dio lugar a una profusión de implementaciones semicompatibles y, finalmente, a la división del nombre "YMODEM" en "XMODEM-1K" y diversas variantes de YMODEM. Por lo tanto, XMODEM-1K es posterior a YMODEM, pero aun así siguió siendo bastante común.

NMODEM

NMODEM es un protocolo de transferencia de archivos desarrollado por LB Neal, quien lo publicó en 1990. NMODEM es esencialmente una versión de XMODEM-CRC que utiliza bloques más grandes de 2048 bytes, a diferencia de los bloques de 128 bytes de XMODEM. NMODEM se implementó como un programa independiente, escrito en Turbo Pascal 5.0 para la familia de computadoras compatibles con IBM PC . El tamaño del bloque se eligió para que coincidiera con el tamaño de clúster común del sistema de archivos FAT de MS-DOS en los discos duros contemporáneos , lo que simplificaba el almacenamiento en búfer de datos para la escritura. [ 13 ] [ 14 ]

Suplantación de protocolo

En conexiones fiables (sin errores), es posible eliminar la latencia mediante el pre-reconocimiento de los paquetes, una técnica conocida generalmente como " suplantación de protocolo ". Esto se suele lograr en el hardware del enlace, especialmente en los módems Telebit . Cuando se activa esta opción, los módems detectan la cabecera XMODEM y envían inmediatamente un mensaje ACK. Esto provoca que el programa XMODEM emisor envíe inmediatamente el siguiente paquete, lo que hace que la transferencia sea continua, como una ventana de tamaño infinito. Los módems también suprimen el ACKmensaje que envía el software XMODEM en el otro extremo, liberando así el canal de retorno de baja velocidad.

El sistema también puede implementarse en el propio protocolo, y algunas variantes de XMODEM ofrecían esta funcionalidad. En estos casos, el receptor enviaba el ACKpaquete en cuanto se iniciaba, al igual que los módems Telebit. Dado que esta funcionalidad solo modifica el comportamiento del receptor, no requiere cambios en el protocolo del emisor. YMODEM formalizó este sistema.

Este concepto debe contrastarse con el utilizado en SEAlink, que modifica el comportamiento en ambos extremos del enlace. En SEAlink, el receptor deja de enviar datos ACKpor completo, y el emisor cambia su comportamiento para no esperarlos.

Véase también

Referencias

Citas

  1. ↑ Telecomunicaciones: XMODEM: Nace un estándar , por Alfred Glossbrenner, PC Mag, 17 de abril de 1984, páginas 451-452, ... pero el protocolo en sí fue puesto en dominio público hace mucho tiempo por su creador, el residente de Chicago Ward Christensen. Desde su introducción en 1978, XMODEM...
  2. ↑ Enfoque: Lección de historia: El software de intercambio libre de Ward Christensen , por Michael Swaine, InfoWorld, 1 de noviembre de 1982, página 26
  3. ↑ Ward Christensen, "Recuerdos" , 25 de noviembre de 1992
  4. 1 2 3 4 5 6 7 Meeks, Brock (febrero de 1989). "Los ABC de X-, Y- y ZMODEM" . BYTE . págs. 163–166 . Recuperado el 8 de octubre de 2024 . 
  5. ↑ "La comunidad virtual" .
  6. ↑ Kline, David (julio de 1982). "Osborne—Behind Guerrilla Lines" . Microcomputing . págs. 42–50 . Recuperado el 15 de febrero de 2016 . 
  7. ↑ Pournelle, Jerry (julio de 1983). "Propulsores interestelares, accesorios Osborne, DEDICATE/32 y el Valle de la Muerte" . BYTE . pág. 334. Consultado el 28 de agosto de 2016 . 
  8. 1 2 3 Bush 1995 , pág. G.1.
  9. ↑ Christensen 1982 .
  10. ↑ Forsberg 1986 .
  11. 1 2 3 4 5 6 7 Boswell 1986 .
  12. 1 2 3 4 SEAlink 1987 .
  13. ↑ "Programa y código fuente de NMODEM 1.12" . Archivado del original el 7 de agosto de 2011. Consultado el 13 de febrero de 2020 .
  14. ↑ "Documentación de NMODEM" . Archivado del original el 9 de abril de 2016. Consultado el 13 de febrero de 2020 .

Bibliografía

  • Bush, Randy (30 de septiembre de 1995). Norma técnica FidoNet FTS-0001 (Informe técnico).
  • Christensen, Ward (1 de enero de 1982). "Descripción general del protocolo XMODEM" . Recuperado el 29 de marzo de 2026 .
  • Forsberg, Chuck (11 de septiembre de 1986). "REFERENCIA DEL PROTOCOLO XMODEM/YMODEM" . Recuperado el 29 de marzo de 2026 .
  • Boswell, Peter (20 de junio de 1986). "Protocolos de transferencia de archivos XMODEM, CRC XMODEM, WXMODEM" . CRC XMODEM.
  • Protocolo de transferencia de archivos SEALINK (Informe técnico). 24 de agosto de 1987.
  • MODEM.ASM , código fuente original, Ward Christensen, 10 de octubre de 1977.
  • 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 XMODEM / XMODEM-CRC / WXMODEM , synchro.net
  • Extensiones Adontec XMODEM/32k y XMODEM/64k , adontec.com