Sebbene la rete internet sia costruita sulla coppia di protocolli TCP/IP, il primo dei quali assicura un flusso bidirezionale di dati, senza perdita di pacchetti e duplicazioni, realizzato attraverso un meccanismo di connessione, per cui si parla anche di protocollo connesso di trasporto, è possibile realizzare una trasmissione sicura di dati a partire dalla coppia di protocolli UDP/IP.
Come è noto non si tratta esattamente di una rete internet anche se molti autori tendono ad assimilarla ad essa, poichè il sottostante protocollo IP di rete è lo stesso utilizzato per internet. Tuttavia, un semplice protocollo di trasporto non connesso, com'è per l'appunto UDP, permette di realizzare una tramissione di file fra nodi, analogamente a quanto accade per FTP, uno dei protocolli di utilità più utilizzati su internet.
La realizzazione di un semplice protocollo di trasferimento di file, a partire da UDP, ha suggerito per esso il nome di Trivial File Transfer Protocol, brevemente TFTP. Ciascun pacchetto trasferito durante una connessione viene notificato separatamente ed, inoltre, è trasferire file fra elaboratori su reti diverse, purchè implementino UDP
La sua realizzazione è semplice e diretta prorpio perchè mancano molte delle caratteristiche del protcollo FTP. Le uniche operazioni permese sono quelle di leggere o scrivere file (o, mail) da/verso un server remoto. Non può listare il contenuto di un direttorio ed, inoltre, non è provvisto di ulcun sistema di autenticazione dell'utente. Analogamente ad altri protocolli su internet trasmette dati in formato ad 8-bit.
Le modalità di trasferimento disponobili sono
Naturalmente possono essere definite ulteriori modalità di trasmissione fra coppie di nodi, ma queste devono essere sufficientemente standardizzate da renderle operative praticamente.
Poichè il protocollo TFTP è stato progettato per essere implementato mediante datagrammi, ciascun pacchetto è identificato da tre intestazioni che sono, nell'ordine, dall'esterno verso l'interno IP/UDP/TFTP. Inoltre, come è noto, ai livelli più bassi i pacchetti vengono spezzati in frame, ciascuno prefissato con i rispettivi MAC/LLC, che vengono immessi nel mezzo trasmissivo secondo le specifiche dell'hardware di rete a disposizione.
Il protocollo TFTP, come si è già detto, si basa su un protocollo di trasporto non connesso, cosicchè il trasferimento di un file inizia sempre con una richiesta di lettura o scrittura che funge anche da richiesta di connessione.
Se il server garantisce la richiesta, allora viene aperta una connessione in seguito alla quale inizia la trasmissione del file in blocchi di lunghezza fissa di 512 byte. Ciascun pacchetto contiene un singolo blocco di dati e deve essere notificato da un pacchetto di notifica prima che il prossimo pacchetto venga spedito. Un pacchetto con una lunghezza minore di 512 byte segnala la terminazione del trasferimento.
Se un pacchetto si perde nella rete, allora il ricevente in attesa del pacchetto supererà il tempo limite (timeout) di attesa, ritrasmettendo l'ultimo pacchetto che può essere un pacchetto di dati o di notifica. In questo modo il mittente, ricevendolo, cercherà di ritrasmettere il pacchetto perduto. Il mittente deve tenere soltanto un pacchetto per la ritrasmissione, poichè la trasmissione un pacchetto per volta, fino alla ricevuta notifica di avvenuta trasmissione, garantisce che tutti i pacchetti precedenti sono già stati ricevuti.
Vale la pena osservare che entrambi i nodi coinvolti nel trasferimento fungono da mittente e ricevente. Il primo spedisce dati e riceve notifiche mentre il secondo riceve dati e spedisce notifiche.
Per semplicità di implementazione il protocollo TFTP è realizzato con una minima gestione degli errori, cosicchè la maggior parte di essi provocano la terminazione della connessione. Gli errori vengono segnalati spedendo un pacchetto errore che non deve essere nè notificato nè ritrasmesso. Questo significa che il server oppure il cliente possono terminare normalmente dopo aver segnalato il verificarsi di un errore, mediante trasmissione dell'apposito pacchetto per cui non si è garantiti che il pacchetto raggiunga l'altro capo della connessione. In questo caso si utilizzano meccanismi di timeout per riconoscere la terminazione di connessione quando il pacchetto che segnala l'errore va perduto.
Gli errori possono essere causati da tre tipi di eventi:
Il protocollo TFTP riconosce una sola condizione di errore che non provoca la terminazione della connessione: il pacchetto ricevuto proviene da una porta mittente che non è quella corretta. In questo caso viene spedito un pacchetto di errore al nodo che ha generato quel pacchetto.
Come si è accennato il protocollo TFTP è molto restrittivo, per ragioni implementative. Ad esempio, i blocchi di lunghezza fissa permettono un'allocazione semplice e diretta ed, inoltre, l'attesa di notifica pacchetto per pacchetto fornisce un corretto controllo di flusso dei dati, eliminando la necessità di riordinare i pacchetti di dati in arrivo.
Lo stabilirsi del trasferimento fra due entità TFTP è determinato dall'invio di una richiesta WRQ, per scrivere su un file remoto, o RRQ, per leggere da un file remoto e dalla successiva ricezione di una risposta positiva che rappresenta la notifica a scrivere nel primo caso e il primo pacchetto letto, nel secondo.
In generale, un pacchetto di notifica contiene il numero di blocco del pacchetto di dato che è stato notificato, essendo ogni pacchetto identificato col rispettivo numero d'ordine del blocco da trasferire. I numeri dei blocchi sono consecutivi ed iniziano a partire da uno. Poichè la risposta positiva ad una richiesta di scrittura è un pacchetto di notifica, in questo caso speciale il numero di blocco sarà zero. Se la risposta è un pacchetto di errore, allora la richiesta è stata respinta.
Normalmente, poichè lo scopo di un pacchetto di notifica è quello di confermare l'avvenuta ricezione di un pacchetto, il pacchetto di notifica conterrà il numero di blocco del pacchetto di cui si sta attendendo una positiva ricezione.
Per creare la connessione, ciascuna delle parti sceglie un proprio identificatore di Trasmissione TID che verrà usato per tutta la durata della connessione. La scelta è fatta in modo casuale cosicchè è praticamente impossibile che venga selezionato lo stesso numero due volte per due connessioni in immediata successione.
Ciascun pacchetto del medesimo trasferimento di file è associato con una coppia di TID, uno relativo al mittente e l'altro al ricevente della connessione, i quali sono gestiti per protocolli di tipo datagramma, com'è il protocollo UDP, ossia, come porte di trasmissione e destinazione.
Un elaboratore, che richiede una connessione, sceglie un TID mittente nella maniera appena descritta ed invia la propria richiesta iniziale al TID 69, così come è specificato dal protocollo TFTP, relativamente al nodo server. La risposta a tale richiesta, in condizioni normali, usa il TID scelto dal server come TID mittente e il TID del messaggio di richiesta appena ricevuto come TID ricevente. La coppia di TID così selezionata verrà utilizzata per il resto della trasmissione.
A scopo illustrativo si consideri l'esempio descritto nella figura riportata di seguito
che mostra i passi iniziali impiegati per stabilire la connessione che permette di trasferire un file verso un nodo remoto. Si noti che WRQ e ACK sono i nomi che identificano i pacchetti di richiesta di scrittura e notifica, rispettivamente.
L'inizio di una connessione relativa ad una richiesta di scrittura può essere così descritta.
A questo punto si stabilisce la connessione e il primo pacchetto di dati inviato dal cliente ClientIP sarà identificato dal numero 1. Al passo seguente, e in tutti i passi successivi, la coppia ClientIP e ServerIP dovrà assicurarsi che CliTID sia lo stesso valore su cui si sono accordati nei primi due passi della connessione. Se il TID del mittente non corrisponde a quello previsto il pacchetto viene scartato come se fosse stato spedito erroneamente da qualcunaltro.
In questo caso viene inoltrato un pacchetto d'errore al mittente del pacchetto sbagliato, senza disturbare il trasferimento in corso. Ciò accade solamente se il modulo TFTP riceve un pacchetto con un TID non corretto. Se i protocolli sottostanti non lo permettono, questa particolare condizione di errore non potrà verificarsi.
L'esempio seguente illustra il funzionamento del protocollo TFTP nella situazione appena discussa. Si consideri un nodo A che manda una richiesta ad un nodo B. Da qualche parte, nella rete, la richiesta viene duplicata per cui ne risultano due differenti notifiche, che giungono ad A, con TID differenti scelti da B in risposta alle due richieste.
La prima risposta ad arrivare è anche quella che permette ad A di continuare normalmente la connessione. Quando anche la seconda sarà arrivata, il nodo A la rifiuterà senza, per questo, terminare la prima connessione. Perciò, se vengono scelti due TID differenti per due diverse connessioni con il nodo B, e il nodo A controlla il TID del mittente dei messaggi che riceve, allora la prima connessione può essere mantenuta mentre la seconda verrà rifiutata restituendo un pacchetto d'errore.
Come è già stato accennato, il protocollo TFTP manipola diversi tipi di pacchetti secondo lo schema riportato in tabella
| Codice | Operazione | Mnemonico |
|---|---|---|
| 1 | Richiesta di Lettura | RRQ |
| 2 | Richiesta di Scrittura | WRQ |
| 3 | Invio di un Blocco | DATA |
| 4 | Notifica | ACK |
| 5 | Errore | ERROR |
Come si può notare l'intestazione di ciascun pacchetto contiene all'inizio un codice operativo, che occupa 2 byte, il cui scopo è quello di marcare il tipo di pacchetto. I codici operativi ed il formato di ciscun tipo di pacchetto sono discussi nel seguito.
I pacchetti RRQ e WRQ, corrispondenti ai codici operativi 1 e 2 rispettivamente, hanno il formato rappresentato in figura
dove
Un nodo che riceve dati in modalità netascii deve tradurre quei dati nel proprio formato nativo. La modalità octet, invece, è utilizzata per trasferire file nel formato 8-bit del nodo da cui il file proviene. In questo caso si suppone che ciascun tipo di elaboratore abbia un unico formato a 8-bit più comune, cosicchè è proprio quel formato ad essere scelto. Se un nodo riceve un file octet e poi lo restituisce, allora quest'ultimo deve essere identico all'originale.
La modalità mail è del tutto identica alla modalità netascii a parte il fatto che viene utilizzato il nome del destinatario della "mail", invece del nome del file, ed inoltre la connessione deve iniziare con una richiesta di scrittura (WRQ).
Nella discussione precedente si è assunto che entrambi, mittente e ricevente, operino nella stessa modalità ma non c'è nessuna specifica che questo sia sempre il caso. Si consideri, ad esempio, il caso di un server, utilizzato per immagazzinare dati. Appare evidente che non c'è alcuna necessità, da parte del server, a tradurre la modalità netascii nel proprio formato testuale perchè l'immagazzinamento potrebbe avvenire esattamente nel modo con cui è stato ricevuto, utilizzando un fomato ad 8-bit.
Naturalmente è possibile definire altre modalità fra coppie di nodi cooperanti nel protocollo TFTP, ma questo va fatto con molta attenzione perchè non c'Egrave alcuna obbligatorietà che tali modalità vengano definite anche su altri nodi, proprio perchè non esiste alcuna autorità centrale che definisca nuove modalità ed assegni ad esse dei nomi.
I dati vengono effettivamente trasferiti secondo il formato di pacchetti DATA secondo quanto rappresentato nella figura seguente
I pacchetti DATA, con codice operativo 3, hanno un numero di blocco ed un campo dati. I numeri che identificano la progressione dei blocchi iniziano con uno e sono incrementati di una unità per ogni nuovo blocco di dati. Questa restrizioneconsente l'uso di un solo numero per discriminare i nuovi pacchetti e le possibili duplicazioni.
Il campo dati può essere lungo fino a 512 byte: se il blocco non è l'ultimo sarà esattamente 512 mentre avrà un valore inferiore in caso opposto, segnalando la terminazione del trasferimento.
Tutti i pacchetti, a parte quelli usati per la terminazione, sono notificati individualmente a meno che non si verifichi un timeout. L'invio di un pacchetto DATA va considerato anche come la notifica di ricezione per un pacchetto ACK, relativo al pacchetto DATA mandato in precedenza. I pacchetti WRQ e DATA sono notificati da pacchetti ACK oppure ERROR, mentre i pacchetti RRQ e i pacchetti ACK sono notificati sia dai pacchetti DAT che da quelli ERROR. La figura seguente rappresenta un pacchetto ACK, con codice operativo 4.
Il numero di blocco che compare nel pacchetto è esattamente il corrispondente numero che compare nel pacchetto DATA, di cui si sta inviando notifica. Un pacchetto WRQ è notificato da un pacchetto ACK avente numero di blocco zero.
I pacchetti ERROR, identificati dal codice operativo 5, hanno la forma rappresentata nella figura seguente.
I paccehtti ERROR possono essere notificati da ogni altro tipo di pacchetto. Il codice di errore è un intero che indica la natura dell'errore. Normalmente viene assegnata una tabella dei tipi di errori e il loro significato.
Il messaggio d'errore non è strettamente necessario ma viene aggiunto per ragioni di comprensibilit&abreve per l'utente umano. Naturalmente è codificato in modalità netascii e terminato, come tutte le stringhe, con un byte nullo.
La fine della trasmissione è marcata da un pacchetto DATA che contiene dati fra 0 e 511 byte, ossia il datagramma ha una lunghezza minore di 515 byte. Questo pacchetto è notificato da un pacchetto ACK, come tutti gli altri pacchetti DATA. Dopo quest'ultima notifica il server può terminare la connessione.
Si tenga presente, però, che il server che inoltra l'ultimo pacchetto di notifica dovrebbe attendere un certo intervallo di tempo ancora, prima di chiudere la connessione, per ritrasmettere eventualmente l'ultimo pacchetto ACK, nel caso che questo fosse andato perso.
Quest'ultima situazione è determinata dal fatto che il server riceve nuovamente il pacchetto finale di dati perchè il mittente continuerà a trasmettere questo pacchetto fino a quando non ottine una notifica di avvenuta ricezione oppure il tempo a disposizione è terminato. Se la risposta è un pacchetto ACK vuol dire che la trasmissione dei dati è stata completata con successo.
Nel caso, invece, che si sia verificato un timeout ed il cliente non deve ritrasmettere più nulla, il trasferimento può considerarsi essere avvenuto con successo. Comunque, si può anche concludere con un trasferimento senza successo ma, in entrambi i casi, si chiude la connessione.
Nel caso che la richiesta di lettura o scrittura, inoltrata con i pacchetti iniziali RRQ o WRQ, non possa essere garantita oppure si è verificato qualche errore durante la trasmissione, viene inviato un pacchetto d'errore, con codice operativo 5. Questo viene inoltrato solamente per cortesia perchè non potrà essere nè ritrasmesso nè notificato. Le condizioni di errore possono essere rilevate anche per mezzo dei timeout.