Bestzeit

Inhaltsverzeichnis

Einer der entscheidenden Vorzüge der Datenübertragung ist die Möglichkeit, Dateien in den unterschiedlichsten Formaten über die analoge oder digitale Leitung zu übertragen - kostensparend über weite Entfernungen in kurzer Zeit. Eine der wesentlichen Voraussetzungen hierfür war die Entwicklung sogenannter File-Transfer-Protokolle. X-Modem ist die älteste Implementation und stammt von Ward Christensen.

X-Modem

Es verwendet 128 Byte lange Blöcke mit folgendem Aufbau: <128 byte datenblock>. Dabei ist SOH ein Startzeichen (Start of Header), n ein Blocknummernbyte (ab 01 aufwärts gezählt), !n die invertierte Blocknummer und s die auf 8 Bit begrenzte arithmetische Prüfsumme über die 128 Bytes des Datenblocks. Ist die Dateilänge nicht durch 128 teilbar, wird der letzte Datenblock mit EOF (End of File) auf 128 Byte aufgefüllt; die empfangene Datei ist im Extremfall also bis zu 127 Byte länger als die ursprüngliche.

Handelt es sich in einem solchen Fall um eine binäre Datei, treten eventuell Fehler bei der Ausführung auf - zumindest, wenn das dazugehörige Programm die Datei auf ihre Länge hin prüft. Utilities, beispielsweise HunkPad für Amiga, reduzieren die via X-Modem 'aufgeblähte' Datei auf ihre tatsächliche Größe - sie ist dann wieder lauffähig.

Die X-Modem-Übertragung initiiert der Empfänger, indem er den Sender mit einem NAK-Zeichen (Negative Acknowledgement) anstößt. Der Empfänger bestätigt jeden einzelnen fehlerfrei erhaltenen Block mit einem ACK-Steuerzeichen (Acknowledgement); wenn die Prüfsumme nicht stimmt, sendet er ein NAK, ebenso dann, wenn er nach einer gewissen Zeit nicht genügend Bytes je Block erhält.

Der Sender wiederholt bei NAK den zuletzt übermittelten Block oder sendet nach ACK den nächsten. Zum gezielten Abbruch der Übertragung dient das mehrfache Senden des Steuerzeichens CAN (Cancel). Ein einzelnes CAN sollte ignoriert werden, da bei einer fehlerhaften Übertragung eventuell 'Schmierzeichen' auftreten, die ein CAN enthalten und so einen Abbruch bewirken könnten. Wurde der letzte Block mit ACK quittiert, erzeugt der Sender ein EOT-Zeichen, um das Dateiende zu markieren. Auch dieses EOT benötigt ein ACK zur Bestätigung.

Das ursprüngliche X-Modem findet kaum noch Verwendung, da es zwei entscheidende Nachteile aufweist: Erstens die unzuverlässige Fehlererkennung, für die das Prüfsummenbyte verantwortlich ist. Wenn in zwei Bytes eines Datenblocks jeweils dasselbe Bit verfälscht wird, bleibt der Fehler unerkannt.

Zweitens führt die geringe Blocklänge (128 Byte Nutzdaten) im Vergleich zur Laufzeit zwischen Sender und Empfänger zu einer unnötig langsamen Übertragung. Der Effekt zeigt sich besonders deutlich bei puffernden MNP/V.42-Modems, wobei sich die Zeit bis zum Erhalt der ACK-Antwort drastisch erhöht. Dadurch entstehen Pausen beim Senden, die bewirken, daß man oft weniger als die Hälfte der möglichen Geschwindigkeit erzielt.

Zuverlässiger: X-Modem-CRC

Um die Zuverlässigkeit der Fehlererkennung zu verbessern, schlug Ward Christensen später eine X-Modem-Variante vor: Statt des einfachen Prüfsummenbytes sendet man ein 16-Bit-CRC- Wort (Cyclic Redundancy Check), eine gebräuchliche und sichere Fehlererkennungsmethode, die auch vertauschte Bits erkennt. Um mit der Prüfsummenvariante kompatibel zu bleiben, überträgt der Empfänger zum Anstoßen der Übertragung ein 'C' - je nach Implementation auch ein anderes Zeichen - statt des NAK. Der Sender erfährt dadurch, ob das 'alte' X-Modem oder X-Modem-CRC zum Einsatz kommt. Erhält der Empfänger auf 'C' keine Antwort, versucht er es mit NAK und greift dadurch gegebenenfalls auf die alte Prüfsummenmethode zurück.

Schneller: X-Modem-1K

X-Modem-CRC war hinsichtlich der Fehlersicherheit ein großer Fortschritt, litt aber an den gleichen Geschwindigkeitsbeschränkungen wie das Uralt-X-Modem. Mit dem Aufkommen schnellerer Modems wurde die Verzögerung durch ACK- Wartezeiten zunehmend lästiger, so daß eine Variante mit 1 KByte Blocklänge aufkam.

Zur Unterscheidung von den alten 128-Byte-Paketen verwendet man am Blockanfang ein STX- statt eines SOH-Zeichens. Im Prinzip ist zwar ausdrücklich auch die Prüfsummenmethode statt der CRC-'Prüfsumme' erlaubt, findet aber de facto kaum Anwendung. Die folgende Beispielrechnung - die jeglichen MNP/ V.42-Protokoll-Overhead außer acht läßt - macht den Fortschritt anhand einer theoretischen Durchsatzrate deutlich: Überträgt man eine komprimierte Datei mit einem 9600er Modem, MNP 5 und einer internen MNP-Blocklänge von 128 Byte, erreicht man unter Berücksichtigung des internen Protokolls etwas mehr als ein KByte pro Sekunde: 9600 Bit : 8 Byte = 1200 Byte/s. Damit wäre ein X-Modem-1K-Block also in ziemlich genau einer Sekunde übertragen. Der PC steuert das Modem mit 19 200 Bit/s an und benötigt für die Übertragung eines 128-Byte-Blocks zum lokalen Modem etwa 67 ms. Da das Modem einen MNP-Block erst sendet, wenn es ihn vom PC vollständig erhält, schickt es den MNP- Block erst nach 67 ms über die Telefonleitung. Bei 9600 Bit/s benötigt das Modem dafür weitere 110 ms. Das Empfängermodem übergibt den MNP-Block nun dem dortigen PC, was wiederum 67 ms dauert. Insgesamt kommt der 128-Byte-Teilblock bei einer optimalen Leitung also nach rund 0,25 s vom einen zum anderen PC, und frühestens dann kann das X-Modem-Protokoll des Empfängers mit einem ACK-Zeichen antworten.

Beim alten X-Modem dauert die Übertragung der 128 Byte Nutz- und 5 Byte Protokolldaten von Modem zu Modem bei 9600 Bit/s etwa 0,11 s: 133 Byte/s : 1200 Byte/s. Man erreicht also nicht einmal die Hälfte der theoretischen Durchsatzrate. Bei X-Modem-1K mit 1-KByte Blocklänge, bestehend aus 1024 Byte Nutzdaten und 5 Byte Protokolldaten, dauert die Übertragung 86 ms. Damit einer Antwortzeitverzögerung von 0,25 Sekunden zu rechnen ist, beträgt die Bandbreitennutzung 77 Prozent: 86 ms : (86 ms + 25 ms). Hierbei handelt es sich um einen theoretischen Wert bei optimalen Leitungsbedingungen. In der Praxis dürfte das Ergebnis wohl etwas niedriger, bei 75 Prozent liegen. Die Übertragungsdauer für Nutzdaten ist im Verhältnis zu 128-Byte- Blöcken gestiegen, die Pausenzeit zwischen zwei Datenblöcken gesunken.

Bei Satellitenverbindungen sieht das Zeitverhalten noch ungünstiger aus. Die Funkwellen breiten sich mit 300 000 km/s aus. Geostationäre Satelliten stehen in 36 000 km Höhe über dem Äquator. Nehmen wir den günstigen Fall an, daß die beiden DFÜler in Äquatornähe sind, dann beträgt die Laufzeit eines Datenpakets zum Empfänger 0,24 Sekunden: 72 000 km : 300 000 km. Weitere 0,24 Sekunden vergehen, bis ein ACK den umgekehrten Weg zurückgelegt hat. Zwischen den Datenblöcken tritt also allein wegen der Satellitenentfernung bereits eine zusätzliche Verzögerung von rund einer halben Sekunde auf, was den Datendurchsatz um 15 Prozent reduziert, legt man den vorherigen Wert von 0,11 Sekunden eines 9600er Modems zugrunde: 0,11 s : (0,25 s + 0,48 s).

Größere Blocklänge = schneller?

Es ist ein Trugschluß zu glauben, man müsse nur die Blocklänge ständig vergrößern, um immer näher an die theoretische Grenze zu kommen. Wenn beispielsweise, bedingt durch eine schlechte Leitung, jedes fünftausendste Zeichen falsch ankommt, muß man bei 1-KByte-Blöcken jedes fünfte Datenpaket wiederholen. Das reduziert den Datendurchsatz um 20 %. Bei X-Modem mit 128-Byte-Blöcken sind bei gleicher Fehlerfrequenz jedoch nur die 'letzten' 128 Bytes betroffen. Der Datendurchsatz sinkt dann lediglich um 2,5 %. Bei 10- KByte-Blöcken minimiert sich zwar der Laufzeiteffekt, aber bei der angeführten Fehlerrate käme so gut wie überhaupt kein Block mehr fehlerfrei an.

Y-Modem: Dateiname inklusive

Trotz der flotteren Übertragung besitzt auch X-Modem-1K einen Nachteil: Man muß den Dateinamen meist zweimal eingeben - als Dateiauswahl in der Mailbox und als lokalen Namen, wie er auf der eigenen Festplatte erscheint. Chuck Forsberg legte deshalb eine Art Schale um X-Modem-1K herum: Während die Blockzählung bei X-Modem immer mit 01 beginnt, sendete er einen Block 00 vorneweg, der den Dateinamen und die Dateilänge enthielt - Y-Modem war entstanden. Jetzt ersparte man sich das Abtippen des Namens und vermied gleichzeitig, daß die empfangene Datei bis zu ein KByte länger als die gesendete war; das Empfangsprogramm konnte den letzten Datenblock auf die richtige Länge abschneiden.

Später entstand noch die Variante Y-Modem-G, die auf die Bestätigung eines Blocks verzichtet und sich deshalb primär für fehlerfreie Übertragungen eignet. Da diese aber im richtigen Leben praktisch nie vorkommen (selbst bei V.42- oder MNP-Modems können Fehler noch im Empfangs-PC durch verlorene Interrupts auftreten), blieb Y-Modem-G trotz des geringen Anteils an Steuerinformationen und der damit verbundenen Effizienz ohne größere Bedeutung.

Der Quasi-Standard

Es ließ Chuck Forsberg keine Ruhe, daß auch Y-Modem die Übertragungsleitung nicht voll ausnutzt, wenn man auf die Fehlerkorrektur nicht verzichten will. Von einigen Anwendern kam der Vorschlag, 'kritische' Steuerzeichen mit einem vorangestellten Kennzeichen umzukodieren, was Chuck Forsberg als Data Link Escaping (DLE) implementierte. Daraus entstand Ende 1986 das zur Zeit meistgenutzte Z-Modem- Protokoll. So war es möglich, Leitungen zu nutzen, die bestimmte Steuerzeichen ausfiltern, wie beispielsweise das Datex-P-Netz. Auch die Übertragung mit dem XON/XOFF-Handshake- Softwareprotokoll - das den Datenfluß zwischen Modem und Computer steuert und hierfür zusätzliche Bytes übermittelt - verursachte keine Probleme. Der Sender wartet jetzt nicht mehr nach jedem einzelnen Block auf eine Bestätigung, bevor er den nächsten abschickt. Statt dessen übermittelt er einfach solange drauflos, bis er ein NAK erhält (in diesem Fall kein einzelnes Zeichen, sondern einen kleinen Block, da Z-Modem außer dem NAK-Zeichen auch eine fortlaufende Nummer der Blöcke transportiert). Die Übertragungsleitung steht also dauernd unter 'Strom'. Intern verwendet man wie bei Y-Modem 1-KByte- Blöcke. Bei einem NAK folgt die Wiederholung der Blöcke ab dem fehlerhaft übertragenden.

Freundlicherweise veröffentlichte Forsberg auch einige C-Routinen, die die Implementation veranschaulichten (c't- Mailbox, Forsberg.zip). Optional sah er für besonders fehlerträchtige Verbindungen auch eine 32-Bit-CRC vor. Viele Terminal- und Mailbox-Programme unterstützten daraufhin neben den verschiedenen X- und Y-Modem-Varianten wenig später auch Z-Modem. Dennoch darf man nicht übersehen, daß auch Z-Modem einige Kompromisse macht: Treten Übertragungsfehler in einem Netz auf, das Kosten nach Datenmengen berechnet, erweist sich Z- Modem als besonders teuer, da es noch Daten sendet, solange die Gegenseite kein NAK empfängt. Ferner ist DLE bei den meisten heutigen Übertragungsstrecken unnötig, da praktisch jedes Modem neben dem XON-/XOFF-Softwareprotokoll auch das hardwaremäßige RTS-/CTS-Handshake unterstützt.

Back to the roots

Würde man die durch das Warten auf eine Bestätigung auftretenden Sendepausen beseitigen, könnten die X- und Y- Modem-Protokolle schneller als Z-Modem sein, da sie kein DLE nutzen. Aber wie?

Ich stelle mir einen Weg vor, der lediglich auf der Sendeseite Änderungen benötigt, zum Beispiel in einer Mailbox-Software. Auf Seiten des Benutzers dürfte die Software keinerlei Anpassung erfordern, zumindest, wenn das Programm mit eingestelltem Y-Protokoll sich halbwegs an Christensens und Forsbergs Implementierungsrichtlinien hält. Z-Modem sendet so lange die Blöcke 'blind', wie es keine 'Reklamation' für einen vorhergehenden Block erhält. Bei X- oder Y-Modem macht dies keinen Sinn, da man mit dem ACK nicht die Nummer des bestätigten Blocks mitsendet und ein empfangenes ACK sich deshalb auf den nächsten Block bezieht: verlorengegangene Blöcke würden nicht erkannt.

Abhilfe wäre einfach. Y-Modem sendet den jeweils nächsten Block nicht vollständig, sondern ohne die Prüfsumme am Ende. Somit erfolgt auch keine Bestätigung. Die Prüfsumme übermittelt man versetzt, sobald das ACK für den vorhergehenden Block kommt, während der nächste vorbereitet wird. Bekommt der Sender ein NAK gesandt, müßte er den vorhergehenden und den aktuellen Block - diesen zunächst ohne Prüfsumme - wiederholen.

Umgesetzt

Dieses im folgenden 'Enhanced X-/Y-Modem' genannte Verfahren habe ich bei der Mailboxsoftware EMAIL implementiert. Das Verfahren scheint simpel, wirkt aber Wunder. Das im Vergleich zu Z-Modem ohne DLE werkelnde Enhanced X-/Y-Modem liefert um zwei bis drei Prozent höhere Nettodatenraten. Z-Modem kommt mit einem 14 400er Modem auf eine Durchsatzrate von etwa 1650 Byte pro Sekunde. Enhanced Y-Modem hingegen auf einen Nettodurchsatz von bis zu 1690 Byte/s. Über einen ISDN-Kanal und INT-14h-Treiber unter DOS beträgt der Durchsatz gar 7800 Byte/s.

Die ersten Testläufe mit herkömmlichen Terminalprogrammen, die eine saubere X- oder Y- Modem-Implementation haben, verliefen ohne Probleme. Das für Fernwartungen von Symantec entwickelte 'Norton pcAnywhere' macht sowohl in der DOS- als auch in der Windows-Version das neue X-/Y-Modem-Verfahren klaglos mit. Auch das Windows-3.1- Terminalprogramm und die Public-Domain-Software Shamcom-Lite laufen fehlerfrei. Mit dem Programm Norton-TERM95 von Symantec ist eine Enhanced-Y-Modemübertragung nicht möglich; es behandelt die Daten, die dem gerade erwarteten Datenblock unmittelbar folgen, als 'unerwarteten Block' und verweigert den Transfer. Das Shareware-Programm Terminate funktioniert nur teilweise: Es hat offenbar beim Wiederaufsetzen nach Fehlern größere Probleme.

Generell hakt es jedoch bei Shareware-Programmen - vermutlich, weil für das X- oder Y-Modem-Protokoll keine Quellcodebeispiele im Umlauf sind. So führt ein einzelnes zu CAN verfälschtes Zeichen entgegen Christensens Empfehlung zum Abbruch.

Abschließend ein Vorschlag: Um eventuellen Inkompatibilitäten mit bestimmter Terminalsoftware aus dem Weg zu gehen, sollte der Anwender bei künftigen Mailboxprogrammen das Voraus-Senden des nächsten Datenblocks abschalten können. (br)/(dz) (ole)