YMODEM – Wikipedia

YMODEM ist ein Dateiübertragungsprotokoll, das zwischen Mikrocomputern verwendet wird, die über Modems miteinander verbunden sind. Es wurde hauptsächlich zum Übertragen von Dateien zu und von Bulletin-Board-Systemen verwendet. YMODEM wurde von Chuck Forsberg als Erweiterung von XMODEM entwickelt und erstmals in seinem CP / M implementiert SÜSSKARTOFFEL Programm. Ursprünglich auch als YAM bekannt, wurde es 1985 von Ward Christensen, Autor des ursprünglichen XMODEM, offiziell als “YMODEM” bezeichnet.

YMODEM hat XMODEM auf drei Arten erweitert und Funktionen anderer erweiterter XMODEM-Varianten kombiniert. Wie XMODEM-CRC ersetzte YMODEM die 8-Bit-Prüfsumme durch eine 16-Bit-CRC (Cyclic Redundancy Check), machte sie jedoch zur Standardform der Korrektur anstelle der optionalen. Von TeLink wurde der Header “Block 0” hinzugefügt, der den Dateinamen und die Größe gesendet hat. Dies ermöglichte Stapelübertragungen (mehrere Dateien in einer einzigen Sitzung) und machte das Auffüllen am Ende der Datei überflüssig. Schließlich ermöglichte YMODEM, die Blockgröße von den ursprünglichen 128 Datenbytes auf 1024 zu erhöhen, wie in XMODEM-1k, wodurch der Durchsatz bei schnelleren Modems erheblich verbessert wurde.

Forsberg baute den Standard mit all diesen Funktionen als Laufzeitoptionen auf, sodass ein einzelner Protokolltreiber bei der Verbindung mit Nicht-YAM-Systemen auf XMODEM-CRC oder sogar XMODEM zurückgreifen kann. Er glaubte, dass Programmierer so viele dieser Funktionen wie möglich auf einer bestimmten Plattform implementieren möchten. Er war bestürzt, als er feststellte, dass die meisten Implementierungen mit CRC-16 tatsächlich nur eine Blockgröße von 1 KB bereitstellten und den “Block 0” nicht implementierten, während der Name YMODEM weiterhin verwendet wurde. Das Ergebnis war die Veröffentlichung vieler nicht miteinander kompatibler YMODEM-Implementierungen und die Verwendung des Namens YMODEM-Charge um klar anzugeben, welche Versionen den vollständigen Standard unterstützt haben.

Eigenschaften[edit]

XMODEM[edit]

Das ursprüngliche XMODEM war ein sehr einfaches Protokoll, und das ist der Grund für seinen Erfolg. Es kann auf praktisch jeder Maschine der Ära implementiert werden, auch auf solchen mit sehr begrenzten Prozessoren und Speicher. Dabei wurden die zu sendenden Daten in 128-Byte-Pakete aufgeteilt, ein 3-Byte-Header und eine 1-Byte-Prüfsummenfußzeile hinzugefügt und die resultierenden 132-Byte-Pakete der Reihe nach gesendet. Der empfangende Computer hat die Prüfsumme aus den 128 Datenbytes neu berechnet. Wenn sie mit der in der Fußzeile gesendeten Prüfsumme übereinstimmt, hat er eine zurückgesendet ACKund wenn es nicht übereinstimmte, a NAK. Als der Absender eine erhielt ACK es schickte das nächste Paket, während a NAK veranlasste es, den letzten erneut zu senden.

Es gab eine Reihe von Problemen mit dem Protokoll. Durch die Verwendung einer einfachen Prüfsumme konnten einige häufige Fehler unbemerkt bleiben. Die kleine Paketgröße und die Anforderung, auf die zu warten ACK oder NAK führte zu einer langsamen Leistung bei Verbindungen mit höherer Geschwindigkeit oder solchen mit erheblicher Latenz. Da die Übertragung keine Details der Datei enthielt, musste schließlich jede Datei manuell gestartet werden, was bei der Übertragung vieler kleiner Dateien mühsam sein kann.

Lösungen für diese Probleme wurden in den frühen 1980er Jahren entwickelt. XMODEM-CRC ersetzte die Prüfsumme durch eine 16-Bit-CRC (Cyclic Redundancy Check), die gegenüber häufigen Fehlern wesentlich widerstandsfähiger war. XMODEM-1k erweiterte die Paketgröße von 128 Byte auf 1024 und verbesserte die Leistung bei Verbindungen mit höherer Geschwindigkeit, während andere, wie WXMODEM und SEAlink, stattdessen Schiebefenstersysteme einführten, um sowohl die Leistung als auch die Latenz zu bekämpfen, was auf Kosten einer gewissen Komplexität führte. Wieder andere, wie TeLink und MODEM7, fügten Dateiinformationen hinzu, sodass eine einzelne Übertragung mehrere Dateien enthalten konnte, sodass Stapel von Dateien mit einem einzigen Befehl gesendet werden konnten.

YMODEM[edit]

Leider ist keine dieser erweiterten Versionen enthalten alle dieser Funktionen. Chuck Forsberg, Autor des CP / M-Programms “Yet Another Modem” (YAM), hat beschlossen, einen einzigen Protokolltreiber zu schreiben, der alle diese Optionen unterstützt. Wenn die Benutzer eine Übertragung starten, können sie in der Befehlszeile angeben, welche Optionen sie möchten, und beispielsweise angeben, dass sie CRC verwenden möchten. Das Protokoll wurde so geschrieben, dass es diesen Stil versucht, aber ordnungsgemäß zurückgreift, um den von der Remote-Software implementierten Funktionen zu entsprechen.

Abbrechen[edit]

Ein Problem mit dem ursprünglichen XMODEM war, dass es keine definierte Möglichkeit gab, die Übertragung nach dem Start abzubrechen. Die normale Lösung war zu senden NAKs zu jedem nachfolgenden Paket, wenn der Benutzer es angefordert hat. Da das XMODEM-Protokoll ein Limit von zehn definiert hat NAKWenn ein Sendevorgang abgebrochen werden soll und das Senden eines Pakets eine Sekunde dauern kann, bedeutet dies, dass es eine Verzögerung von zehn Sekunden gab, bei der der Absender kontinuierlich Daten sendete, die einfach ignoriert wurden.

Einige Implementierungen hatten die Möglichkeit hinzugefügt, a zu senden KÖNNEN Anstatt von ACK oder NAK am Ende eines empfangenen Pakets, um einen Abbruch anzuzeigen. Leider bestand die Möglichkeit, dass a KÖNNEN könnte durch Leitungsrauschen erzeugt werden und einen Abbruch auslösen. YAM hat dies daher leicht modifiziert, um zwei zu erfordern KÖNNENs Rücken an Rücken, die sofort einen “anmutigen Abbruch” am Absenderseite durchführen würden.

CRC[edit]

Die CRC-Unterstützung wurde in XMODEM-CRC eingeführt. Dies war eine sehr einfache Änderung des ursprünglichen Protokolls; Auf Anfrage würde der Empfänger versuchen, die Übertragung durch Senden einer Initiale auszulösen C. anstelle einer NAK. Wenn der Remote-Absender die CRC-Option unterstützt, beginnt er wie gewohnt mit dem Senden von Paketen, jedoch mit einer 16-Bit-CRC in der Fußzeile anstelle der 1-Byte-Prüfsumme. YAM unterstützte diese Option ohne Änderungen.

1k[edit]

In XMODEM-1k wurden 1024-Byte-Pakete eingeführt. Diese Version hat das Triggerzeichen des Empfängers nicht geändert, sodass der Absender nicht wissen konnte, ob der Empfänger größere Pakete unterstützt. Stattdessen wurde XMODEM-1k an beiden Enden der Verbindung als separates Protokoll dargestellt. Wenn eine solche Verbindung gestartet wurde, konnte der Absender wählen, ob er entweder 1024 Bytes in einem Paket oder 128 Bytes senden möchte, wobei das größere mit einem angegeben wird STX Zeichen in der Kopfzeile statt der normalen SOH. Normalerweise würden nur die letzten Pakete die kleineren Pakete verwenden, um zu vermeiden, dass große Mengen an Auffüllung gesendet werden. 1k nahm auch CRC für alle Verbindungen an. YAM unterstützte 1k ohne Änderungen.

Nullpaket[edit]

Um die automatisierte Übertragung von FidoNet-E-Mails zu unterstützen, hat MODEM7 die Möglichkeit eingeführt, den Dateinamen vor dem Senden des ersten Datenblocks als Klartext zu senden. Dies war nicht zuverlässig, und TeLink verbesserte dies, indem der Dateiname und optional andere Daten wie das Erstellungsdatum und die Dateilänge in einem vollständigen 128-Byte-Paket abgelegt wurden. XMODEM hat die Übertragung mit Paket Nummer eins gestartet, daher hat TeLink dieses Paket als Nummer Null gesendet. Dieses “Nullpaket” oder “Blocknull” wurde in anderen FidoNet-Systemen wie SEAlink und anderen üblich.

YAM unterstützte das Nullpaketformat, wurde jedoch von vielen Implementierungen von YMODEM von Drittanbietern ignoriert. Wenn eine Implementierung versuchte, das Nullpaket an eine nicht bekannte Version zu senden, würde der Empfänger dies natürlich tun NAK das Paket, als Paket Null ist illegal. Der Absender würde dann das sehen NAK Versuchen Sie als Übertragungsfehler, das Paket erneut zu senden, und versuchen Sie dies zehnmal, bevor Sie fehlschlagen.

Aus Gründen, die nicht ganz klar sind, haben viele Implementierungen von YMODEM diese Funktion nicht implementiert. Weil sie sich dessen nicht bewusst waren, schickten sie eine NAKund löst eine Reihe von Wiederholungsversuchen aus, bevor ein Fehler auftritt. Dies bedeutete, dass die Übertragungen fehlschlagen würden, wenn der Benutzer ein kompatibles YMODEM mit einer nicht kompatiblen Version verwenden würde. Trotzdem waren solche nicht konformen Versionen üblich.

Infolgedessen war es üblich, dass sowohl YMODEM als auch YMODEM Batch als zwei separate Protokolle aufgeführt wurden. Weitere Verwirrung wurde durch die Ähnlichkeit zwischen XMODEM-1k und diesen nicht konformen YMODEMs verursacht, die dem Punkt ähnlich waren, dass sie häufig fälschlicherweise als gleich aufgeführt wurden.

Streaming-Unterstützung[edit]

YMODEM-g ist eine Streaming-Variante für fehlerfreie Verbindungen. Es wartet nicht auf den Empfang einer Bestätigung, bevor das nächste Paket gesendet wird. Das Protokoll ist schneller als YMODEM, da keine Latenz zwischen Paketen eingeführt wird, jedoch keine Fehler korrigiert werden kann. Es hängt davon ab, dass die zugrunde liegende Verbindung fehlerfrei ist, was beispielsweise bei Modems der Fall ist, die MNP unterstützen.

Normalerweise wird eine YMODEM-Übertragung vom Empfänger gestartet, der a sendet C. um anzuzeigen, dass das 128-Byte-Format mit CRC verwendet werden soll, oder NAK wenn es das ursprüngliche Prüfsummensystem verwenden möchte. Wenn das g-Protokoll gewünscht wird, wird die Übertragung stattdessen durch Senden von a ausgelöst G. Wenn der Absender das g-Protokoll nicht unterstützt, betrachtet er dies als Fehler und ignoriert es. Wenn er jedoch g unterstützt, beginnt er, Pakete in einem kontinuierlichen Stream zu senden. Es wird nur eine einzige erwartet ACK nachdem das endgültige Paket empfangen wurde, was durch das Vorhandensein eines angezeigt wird EOT Zeichen in den Daten. YMODEM-g geht davon aus, dass 1k Pakete verfügbar sind.

Obwohl dieses Protokoll möglicherweise schneller als ZMODEM ist, wurde es immer noch selten verwendet. Dies war teilweise auf den Mangel an anderen Funktionen zurückzuführen, aber auch auf ein schwerwiegenderes Problem. Vor dem Aufkommen des 16550 UART bestand ein erhebliches Risiko eines Pufferüberlaufs an der seriellen Schnittstelle. Obwohl dies von YMODEM-g erkannt würde, konnte es nicht korrigiert werden, da keine erneute Blockübertragung möglich ist. Der Empfänger müsste die gesamte Übertragung von Anfang an abbrechen und neu starten. ZMODEM hingegen verfügt über eine Übertragungswiederaufnahmefunktion, die es attraktiver macht.

Verweise[edit]