Copyright © 1997 Università di Firenze. All rights reserved.

license available.

Il trasferimento di file è tra le applicazioni più comuni del TCP/IP e rende conto di gran parte del traffico nella rete. Protocolli standard di trasferimento dei file esistevano per l'ARPANET prima ancora che il TCP/IP diventasse operativo.
Ci sono due diversi tipi di condivisione di file: in una il file sta nell'HOST, ne faccio una copia locale, opero su quella, eventualmente la modifico e la rimetto sull'HOST (perchè il file potrebbe essere necessario a più di una persona); nell'altra invece vado ad interagire direttamente con l'HOST e uso la copia dell'HOST per leggere, scrivere e modificare il file. Sono due modi completamente diversi di operare: il primo è esemplificato dall'FTP (File Transfer Protocol) mentre il secondo è implementato dal protocollo NFS (Network File System).
Il problema principale dell'FTP è che se due utenti utilizzano contemporaneamente lo stesso file e lo modificano, rimarrano nell'HOST soltanto le modifiche di colui che ha riscritto il file per ultimo e si perderanno le modifiche apportate dall'altro utente. Questo è un limite che non ha, invece, il protocollo NFS perchè non viene fatta nessuna copia locale, ma si ha una condivisione dei file.
L'FTP svolge altre funzioni, sempre collegate a quella del trasferimento di file, che sono: accesso interattivo, specificazione del formato e controllo del autenticazione. Con quest'ultima caratteristica l'FTP richiede ai client di autorizzare sè stessi trasmettendo al server un nome ed una password di login prima di richiedere trasferimenti di file.
I problemi che si possono incontrare nel trasferimento di file è che i file system non sono uniformi (lunghezza dei nomi di file, riconoscimento caratteri maiuscoli e minuscoli, dati memorizzati a 7 bit o a 8 bit ecc.) e vengono risolti dall'FTP tramite il mascheramento dei file system.

L' FTP segue un modello client-server. Come altri server, la maggior parte delle implementazioni dell' FTP consentono l'accesso simultaneo da parte di più client. I client usano il TCP per connettersi al server in quanto hanno bisogno di un servizio affidabile. Un singolo processo server master attende le connessioni e crea un processo slave per gestire ciascuna conessione. Tuttavia a differenza della maggior parte dei server, il processo slave non esegue tutti i calcoli necessari. Invece lo slave accetta e gestisce la connesione di controllo dal client, ma impiega uno o più processi per gestire una connessione di trasferimento dei dati.
Di solito sia il client che il server creano un processo separato per gestire il trasferimento dei dati.
Le connessioni di trasferimento dei dati ed i relativi processi che ne fanno uso possono essere creati dinamicamente all' occorrenza, ma la connessione di controllo permane durante un' intera sessione. Una volta che la connessione di controllo scompare, la sessione viene terminata ed il software ad entrambe le estremità termina tutti i processi di trasferimento dei dati.

La porta n° 20 e la porta n° 21 sono riservate all' FTP (sono porte TCP).
Il processo di controllo va a richiedere una connessione TCP alla porta n° 21 col corrispondente processo di controllo del server; si instaura una connessione bidirezionale attraverso la quale vengono dati i comandi standard dell' FTP che si trovano negli RFC (Request For Comment).
La porta n° 20 è riservata, invece, al trasferimento dei dati.
Al di sotto dei processi di controllo ci sono i processi di trasferimento dati che si interfacciano con i rispettivi file system mascherati.

Quando vogliamo effettuare una connessione FTP questo ci chiede sempre un nome ed una password di login, che non viene mai visualizzata. Soltanto in un caso non ci viene chiesta la password: negli anonymous FTP.
Molti server FTP seguono la convenzione di consentire l'FTP anonimo, in cui l' utente non ha bisogno di un' account o di una password per ottenere l' accesso, ma specifica un nome di login anonymous (anonimo) ed una password guest (ospite). Il server ammette i login anonimi, ma restringe l'accesso soltanto ai file disponibili pubblicamente.

La suite TCP/IP contiene un secondo protocollo di trasferimento di file, che fornisce un servizio poco costoso e meno sofisticato dell' FTP. Noto come "protocollo di trasferimento di file banale" (Trivial File Transfert Protocol: TFTP), esso è destinato ad applicazioni che non necessitano di complesse interazioni tra il client ed il server. Essendo più restrittivo dell'FTP, il software del TFTP è molto più piccolo. La piccola dimensione è importante soprattutto nelle workstation senza dischi, che codificano il TFTP nelle ROM.
Il TFTP, all'avvio, carica nella memoria RAM il sistema operativo, o parte di esso, direttamente dal server.
Il TFTP generalmente non usa per il trasferimento il TCP, ma l' UDP; trasferisce un pacchetto alla volta ed utilizza un sistema "stop and wait" per il riscontro dei pacchetti.
Il TFTP che utilizza per il trasferimento il protocollo UDP viene sempre utilizzato in reti locali e ciò permette di ridurre ritardi ed errori sui pacchetti.

Sviluppato dalla Sun Microsystem Incorporated, il Network File System (NFS) fornisce un accesso in linea, trasparente ed integrato, al file condiviso; molte postazioni TCP/IP usano l'NFS per interconnettere i file system dei loro computer.
Dal punto di vista dell'utente l'NFS è quasi invisibile. L'utente può eseguire un arbitrario programma applicativo ed utilizzare file arbitrari per l'input/output. I nomi dei file stessi non indicano se essi sono locali o remoti.

Quando un programma applicativo viene eseguito, esso chiama il sistema operativo per aprire un file, o per registrare e reperire i dati in un file. Il meccanismo di accesso al file accetta la richiesta e la passa automaticamente al software del file system locale o al client NFS, a seconda che il file risieda sul disco locale o in una macchina remota. Quando riceve una richiesta, il software del client impiega il protocollo NFS per contattare il server appropiato in una macchina remota ed eseguire l'operazione richiesta.
Quando il server remoto risponde, il software del client restituisce i risultati al programma applicativo.

Anzichè definire il protocollo NFS dall'inizio, i progettisti hanno scelto di realizzare tre pezzi indipendenti: il protocollo NFS stesso, un meccanismo di chiamata di procedura remota (Remote Procedure Call: RPC) di applicabilità generale ed una rappresentazione esterna dei dati (eXternal Data Rappresentation: XDR).
Il loro intento era quello di separare i tre processi per rendere possibile l'uso della RPC e della XDR in altro software (inclusi i programmi applicativi, come pure altri protocolli).