Passa al contenuto principale

5. Pacchetti TFTP (TFTP Packets)

TFTP supporta cinque tipi di pacchetti, tutti menzionati sopra:

OpcodeOperazione
1Richiesta di lettura (Read request, RRQ)
2Richiesta di scrittura (Write request, WRQ)
3Dati (Data, DATA)
4Riconoscimento (Acknowledgment, ACK)
5Errore (Error, ERROR)

L'intestazione TFTP di un pacchetto contiene l'opcode associato a quel pacchetto.

Pacchetto RRQ/WRQ​

  2 byte     stringa    1 byte     stringa   1 byte
  ------------------------------------------------
 | Opcode |  Filename  |   0  |    Mode    |   0  |
  ------------------------------------------------

           Figura 5-1: Pacchetto RRQ/WRQ

I pacchetti RRQ e WRQ (opcode 1 e 2 rispettivamente) hanno il formato mostrato nella Figura 5-1. Il nome del file è una sequenza di byte in netascii terminata da un byte zero. Il campo modalità contiene la stringa "netascii", "octet" o "mail" (o qualsiasi combinazione di maiuscole e minuscole, come "NETASCII", "NetAscii", ecc.) in netascii che indica le tre modalità definite nel protocollo. Un host che riceve dati in modalità netascii deve tradurre i dati nel proprio formato. La modalità octet viene utilizzata per trasferire un file che è nel formato a 8 bit della macchina da cui viene trasferito il file. Si presume che ogni tipo di macchina abbia un singolo formato a 8 bit che è più comune e che quel formato sia scelto. Ad esempio, su un DEC-20, una macchina a 36 bit, questo sono quattro byte a 8 bit per parola con quattro bit di interruzione. Se un host riceve un file octet e poi lo restituisce, il file restituito deve essere identico all'originale. La modalità mail utilizza il nome di un destinatario di posta al posto di un file e deve iniziare con un WRQ. Altrimenti è identica alla modalità netascii. La stringa del destinatario di posta dovrebbe essere della forma "username" o "username@hostname". Se viene utilizzata la seconda forma, consente l'opzione di inoltro della posta da parte di un computer relay.

La discussione sopra presume che sia il mittente che il destinatario operino nella stessa modalità, ma non c'è motivo per cui questo debba essere il caso. Ad esempio, si potrebbe costruire un server di archiviazione. Non c'è motivo per cui tale macchina debba tradurre netascii nella propria forma di testo. Piuttosto, il mittente potrebbe inviare file in netascii, ma il server di archiviazione potrebbe semplicemente archiviarli senza traduzione in formato a 8 bit. Un'altra situazione del genere è un problema che attualmente esiste sui sistemi DEC-20. Né netascii né octet accedono a tutti i bit in una parola. Si potrebbe creare una modalità speciale per una tale macchina che legge tutti i bit in una parola, ma in cui il ricevitore memorizza le informazioni in formato a 8 bit. Quando tale file viene recuperato dal sito di archiviazione, deve essere ripristinato nella sua forma originale per essere utile, quindi anche la modalità inversa deve essere implementata. Il sito utente dovrà ricordare alcune informazioni per raggiungere questo obiettivo. In entrambi questi esempi, i pacchetti di richiesta specificherebbero la modalità octet all'host esterno, ma l'host locale sarebbe in qualche altra modalità. Nessuna modalità specifica per macchina o applicazione è stata specificata in TFTP, ma una sarebbe compatibile con questa specifica.

È anche possibile definire altre modalità per coppie di host cooperanti, sebbene questo debba essere fatto con attenzione. Non c'è requisito che altri host le implementino. Non c'è autorità centrale che definirà queste modalità o assegnerà loro nomi.

Pacchetto DATA​

         2 byte     2 byte      n byte
         ----------------------------------
        | Opcode |   Block #  |   Data     |
         ----------------------------------

              Figura 5-2: Pacchetto DATA

I dati vengono effettivamente trasferiti in pacchetti DATA rappresentati nella Figura 5-2. I pacchetti DATA (opcode = 3) hanno un numero di blocco e un campo dati. I numeri di blocco sui pacchetti di dati iniziano con uno e aumentano di uno per ogni nuovo blocco di dati. Questa restrizione consente al programma di utilizzare un singolo numero per discriminare tra pacchetti nuovi e duplicati.

Il campo dati ha una lunghezza da zero a 512 byte. Se ha una lunghezza di 512 byte, il blocco non è l'ultimo blocco di dati; se ha una lunghezza da zero a 511 byte, segnala la fine del trasferimento. (Vedere la sezione sulla terminazione normale per i dettagli.)

Tutti i pacchetti diversi dagli ACK duplicati e quelli utilizzati per la terminazione vengono riconosciuti a meno che non si verifichi un timeout [4]. L'invio di un pacchetto DATA è un riconoscimento per il primo pacchetto ACK del pacchetto DATA precedente. I pacchetti WRQ e DATA vengono riconosciuti da pacchetti ACK o ERROR, mentre i pacchetti RRQ e ACK vengono riconosciuti da pacchetti DATA o ERROR.

Pacchetto ACK​

               2 byte     2 byte
               ---------------------
              | Opcode |   Block #  |
               ---------------------

               Figura 5-3: Pacchetto ACK

La Figura 5-3 rappresenta un pacchetto ACK; l'opcode è 4. Il numero di blocco in un ACK ripete il numero di blocco del pacchetto DATA riconosciuto. Un WRQ viene riconosciuto con un pacchetto ACK con numero di blocco zero.

Pacchetto ERROR​

     2 byte     2 byte      stringa    1 byte
     -----------------------------------------
    | Opcode |  ErrorCode |   ErrMsg   |   0  |
     -----------------------------------------

              Figura 5-4: Pacchetto ERROR

Un pacchetto ERROR (opcode 5) assume la forma rappresentata nella Figura 5-4. Un pacchetto ERROR può essere il riconoscimento di qualsiasi altro tipo di pacchetto. Il codice di errore è un intero che indica la natura dell'errore. Una tabella di valori e significati è fornita nell'appendice. (Notare che diversi codici di errore sono stati aggiunti a questa versione di questo documento.) Il messaggio di errore è destinato al consumo umano e dovrebbe essere in netascii. Come tutte le altre stringhe, è terminato con un byte zero.

Ultimo aggiornamento il