5. TFTP-Pakete (TFTP Packets)
TFTP unterstützt fünf Pakettypen, die alle oben erwähnt wurden:
| Opcode | Operation |
|---|---|
| 1 | Leseanfrage (Read request, RRQ) |
| 2 | Schreibanfrage (Write request, WRQ) |
| 3 | Daten (Data, DATA) |
| 4 | Bestätigung (Acknowledgment, ACK) |
| 5 | Fehler (Error, ERROR) |
Der TFTP-Header eines Pakets enthält den mit diesem Paket assoziierten Opcode.
RRQ/WRQ-Paket
2 Bytes String 1 Byte String 1 Byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------
Abbildung 5-1: RRQ/WRQ-Paket
RRQ- und WRQ-Pakete (Opcodes 1 bzw. 2) haben das in Abbildung 5-1 gezeigte Format. Der Dateiname ist eine Sequenz von Bytes in netascii, die mit einem Null-Byte endet. Das Modusfeld enthält die Zeichenfolge "netascii", "octet" oder "mail" (oder eine beliebige Kombination aus Groß- und Kleinbuchstaben, wie "NETASCII", "NetAscii" usw.) in netascii, die die drei im Protokoll definierten Modi angibt. Ein Host, der netascii-Modus-Daten empfängt, muss (MUST) die Daten in sein eigenes Format übersetzen. Der Octet-Modus wird verwendet, um eine Datei zu übertragen, die im 8-Bit-Format der Maschine vorliegt, von der die Datei übertragen wird. Es wird angenommen, dass jeder Maschinentyp ein einzelnes 8-Bit-Format hat, das am gebräuchlichsten ist, und dass dieses Format gewählt wird. Zum Beispiel ist dies auf einem DEC-20, einer 36-Bit-Maschine, vier 8-Bit-Bytes pro Wort mit vier Bits Bruch. Wenn ein Host eine Octet-Datei empfängt und sie dann zurückgibt, muss (MUST) die zurückgegebene Datei mit dem Original identisch sein. Der Mail-Modus verwendet den Namen eines Mail-Empfängers anstelle einer Datei und muss (MUST) mit einem WRQ beginnen. Ansonsten ist er identisch mit dem netascii-Modus. Die Mail-Empfänger-Zeichenfolge sollte (SHOULD) die Form "username" oder "username@hostname" haben. Wenn die zweite Form verwendet wird, erlaubt sie die Option der Mail-Weiterleitung durch einen Relay-Computer.
Die obige Diskussion geht davon aus, dass sowohl Sender als auch Empfänger im selben Modus arbeiten, aber es gibt keinen Grund, warum dies der Fall sein muss. Zum Beispiel könnte man einen Speicher-Server bauen. Es gibt keinen Grund, warum eine solche Maschine netascii in ihre eigene Textform übersetzen müsste. Vielmehr könnte der Sender Dateien in netascii senden, aber der Speicher-Server könnte sie einfach ohne Übersetzung im 8-Bit-Format speichern. Eine andere solche Situation ist ein Problem, das derzeit auf DEC-20-Systemen besteht. Weder netascii noch octet greifen auf alle Bits in einem Wort zu. Man könnte einen speziellen Modus für eine solche Maschine erstellen, der alle Bits in einem Wort liest, aber in dem der Empfänger die Informationen im 8-Bit-Format speichert. Wenn eine solche Datei vom Speicherort abgerufen wird, muss (MUST) sie in ihre ursprüngliche Form wiederhergestellt werden, um nützlich zu sein, daher muss (MUST) auch der umgekehrte Modus implementiert werden. Die Benutzer-Site muss (MUST) sich einige Informationen merken, um dies zu erreichen. In beiden Beispielen würden die Anforderungspakete den Octet-Modus dem fremden Host spezifizieren, aber der lokale Host wäre in einem anderen Modus. Keine solchen maschinen- oder anwendungsspezifischen Modi wurden in TFTP spezifiziert, aber einer wäre mit dieser Spezifikation kompatibel.
Es ist auch möglich, andere Modi für kooperierende Host-Paare zu definieren, obwohl dies mit Vorsicht erfolgen muss (MUST). Es gibt keine Anforderung, dass andere Hosts diese implementieren. Es gibt keine zentrale Autorität, die diese Modi definiert oder ihnen Namen zuweist.
DATA-Paket
2 Bytes 2 Bytes n Bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------
Abbildung 5-2: DATA-Paket
Daten werden tatsächlich in DATA-Paketen übertragen, die in Abbildung 5-2 dargestellt sind. DATA-Pakete (Opcode = 3) haben eine Blocknummer und ein Datenfeld. Die Blocknummern auf Datenpaketen beginnen mit eins und erhöhen sich um eins für jeden neuen Datenblock. Diese Einschränkung ermöglicht es dem Programm, eine einzelne Nummer zu verwenden, um zwischen neuen Paketen und Duplikaten zu unterscheiden.
Das Datenfeld ist zwischen Null und 512 Bytes lang. Wenn es 512 Bytes lang ist, ist der Block nicht der letzte Datenblock; wenn es zwischen Null und 511 Bytes lang ist, signalisiert es das Ende der Übertragung. (Siehe den Abschnitt über normale Beendigung für Details.)
Alle Pakete außer doppelten ACKs und solchen, die für die Beendigung verwendet werden, werden bestätigt, es sei denn, es tritt ein Timeout auf [4]. Das Senden eines DATA-Pakets ist eine Bestätigung für das erste ACK-Paket des vorherigen DATA-Pakets. Die WRQ- und DATA-Pakete werden durch ACK- oder ERROR-Pakete bestätigt, während RRQ- und ACK-Pakete durch DATA- oder ERROR-Pakete bestätigt werden.
ACK-Paket
2 Bytes 2 Bytes
---------------------
| Opcode | Block # |
---------------------
Abbildung 5-3: ACK-Paket
Abbildung 5-3 zeigt ein ACK-Paket; der Opcode ist 4. Die Blocknummer in einem ACK wiederholt die Blocknummer des bestätigten DATA-Pakets. Ein WRQ wird mit einem ACK-Paket mit Blocknummer Null bestätigt.
ERROR-Paket
2 Bytes 2 Bytes String 1 Byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------
Abbildung 5-4: ERROR-Paket
Ein ERROR-Paket (Opcode 5) hat die in Abbildung 5-4 dargestellte Form. Ein ERROR-Paket kann die Bestätigung jedes anderen Pakettyps sein. Der Fehlercode ist eine Ganzzahl, die die Art des Fehlers angibt. Eine Tabelle mit Werten und Bedeutungen ist im Anhang angegeben. (Beachten Sie, dass dieser Version dieses Dokuments mehrere Fehlercodes hinzugefügt wurden.) Die Fehlermeldung ist für den menschlichen Verbrauch bestimmt und sollte (SHOULD) in netascii sein. Wie alle anderen Zeichenfolgen wird sie mit einem Null-Byte beendet.