RDT ist eine Abkürzung für "Reliable Data Transfer", also "Zuverlässige-Datenübertragung". RDT definiert, wie über zuverlässige und unzuverlässige Leitungen Daten geschickt werden. Im folgenden wird derjenige Computer, der die angeforderten Daten versenden soll, stets Sender genannt, und derjenige, der diese angefordert hatte, Empfänger (Selbstverständlich senden und empfangen jedoch beide). RDT teilt sich in verschiedene Versionen auf:

RDT 1.0

Diese Version von RDT definiert den Datentransfer über eine fehlerfreie Leitung (keine Bitfehler, kein Datenverlust). Diese Version ist sehr einfach: Der Sender sendet, der Empfänger empfängt, und das wars dann auch schon.

RDT 2.0

Dieses Protokoll definiert den Grundgedanken bei Übertragungskanälen, bei denen zwar Bitfehler auftreten können, jedoch keine Pakete verloren gehen.

Damit auch jedes Paket garantiert fehlerfrei beim Empfänger ankommt, muss dieser Überprüfen, ob der Inhalt korrekt ist. Diese Korrektheitsprüfung wird anhand der Checksumme gemacht. Falls das Ergebnis korrekt ist, sendet der Empfänger an den Sender ein ACK zurück, wodurch dieser dann weiss, dass das Paket korrekt angekommen ist. Falls das Paket Fehler enthielt, sendet der Empfänger ein NAK zurück, worauf der Sender das Paket einfach nochmals sendet. Dies geht solange, bis alle Pakete mit einem ACK bestätigt wurden.

Leider enthält diese Überlegung, obschon einleuchtend und klar definiert, einen Fehler: Auch die ACKs oder NAKs sind Pakete, die eventuell Fehler enthalten können. Leider ist es nicht sehr ratsam, wenn der Sender einfach bei einer fehlerhaften ACK/NAK-Nachricht oder nach einer Zeitüberschreitung das Paket nochmals sendet, denn eventuell kam das Paket ja richtig an, und so wären dann zwei identische Pakete beim Empfänger. Eine einfache Lösung dieses Problems wäre, wenn zu jedem Paket eine Nummer mitgesendet werden würde, so kann der Empfänger entscheiden, ob das Paket nun gebraucht wird oder nicht.

Es gibt nun zwei RDT-Versionen, die für solche Fehler definiert sind:

RDT 2.1

Bei dieser Version wird bei jedem Paket abwechselnd eine 0 oder eine 1 mitgegeben. Falls der Sender ein NAK oder eine ACK/NAK-Nachricht, die nicht korrekt ist, erhalten, so versendet er das gleiche Paket mit der gleichen Nummer 0 oder 1 nochmals. Der Empfänger kann dadurch sehen, ob das angekommene Paket nochmals das Gleiche wie beim vorherigen Versuch (nämlich wenn die Nummer immer noch die Gleiche ist), oder aber ein neues Paket ist.

RDT 2.2

Die Nummerierung der Pakete funktioniert gleich wie bei Version 2.1, nur werden hier keine NAKs mehr gesendet. Der Empfänger sendet nach jedem Empfang ein ACK mit der Nummer des letzten korrekt empfangenen Paketes zurück. Dadurch weiss der Sender, ob der Empfänger das soeben geschickte Paket korrekt erhalten hat, oder eben nicht.

RDT 3.0

Diese Version beinhaltet die Lösung für Kanäle, bei denen Pakete zusätzlich noch verloren gehen können. Die Grundidee ist hier, dass die Pakete wiederum mit 1 oder 0 nummeriert werden. Dadurch kann bei jedem ACK mit angegeben werden, welches Paket denn nun richtig empfangen wurde.

Der Knackpunkt liegt nun bei ACK: Falls ein Paket verloren geht, wird der Empfänger kein ACK zurückschicken. Wenn das Paket ankam, das ACK jedoch verlorengeht, wird auch kein ACK beim Sender ankommen. In diesen beiden Fällen muss der Sender einen timeout definieren, welcher besagt, dass bei Nicht-Erhalt des ACKs innerhalb der gesetzten Zeit das Paket nochmals übermittelt werden muss. Nun kann es passieren, dass ein ACK nach dem timeout doch noch ankommt, und somit wurde das Paket versehentlich doppelt verschickt. Dies ist jedoch kein Problem, da man ja immer noch die Nummern mitschickt.

Leider hat diese Version noch einen kleinen Fehler: Es kann passieren, dass verspätete ACKs-0 so spät beim Sender ankommen, dass dieser bereits das übernächsten Paket (ebenfalls mit der Nummer 0) gesendet hat. Dadurch würde der Sender fälschlicherweise meinen, dieses Paket sei gemeint. Falls nun aber der Empfänger das momentane 0-Paket falsch empfangen hat, so kann dies nicht mehr rückgängig gemacht werden, denn der Sender denkt sich ja, es sei korrekt angekommen.

Nun, dieses RDT scheint zwar für bestimmte Fälle ganz gut zu sein, es ist jedoch ziemlich unbrauchbar, da es sehr! ineffizient ist: Man stelle sich vor, man müsste ein Paket von der Grösse 1 KiloByte über eine Leitung von 1 Gigabit pro Sekunde versenden. Um die Daten zu senden, bräuchte man also nur 8 Microsekunden, aber bis dass eine Antwort wieder da ist, kann es länger dauern. Wenn man nun annimmt, dass die gesamte Zeit, bis dass eine Antwort kommt, 30 Millisekunden dauert, so hat man nur rund 0.027% der Verbindung genutzt. Um dies zu erklären, stelle man sich vor, man habe 1000 solche Pakete zu versenden. Man wartet also insgesamt 30 Sekunden. 1000 mal ein KiloByte sind aber 1 Megabyte, also 8 Megabit. Um 8 Megabit über eine 1-Gigabit verbindung zu jagen, bräuchte man nur 80 Millisekunden. Dies sind genau die 0.027% von 30 Sekunden.

Dieser Verlust entsteht natürlich dadurch, dass bei jedem Paket erst die Antwort abgewartet werden muss. Eine Lösung dieses Problems ist das Pipelining, also das versenden von Daten, während die alten noch unterwegs sind. Beispiele für solche Protokolle sind GBN, Selective Repeat und TCP.