Copyright © 1986 Universita' di Firenze. All rights reserved.
Free license available.
Accesso e Trasferimento di File
Molti sistemi di rete forniscono ai computers la possibilità di accedere
a files su macchine remote. Esistono vari tipi di accesso remoto, ognuno dei quali ottimizza
finalità diverse, quali ad esempio la riduzione dei costi globali.
In queste architetture, un file server centralizzato fornisce la possibilità di
archiviare dati su una memoria remota ad un set di computers che non hanno un disco di memoria
locale. Periodicamente i computers spediscono copie di files (o copie di interi dischi)
attraverso una rete su un archivio, dove sono registrati in caso di perdita accidentale.
Infine sarà possibile condividere dati tra utenti, programmi o siti multipli.
La condivisione dei files (files sharing) ha due forme distinte:
"on-line access" e "whole-file copying". Come con l'on-line access, il whole-file copyng tra macchine eterogenee
può essere difficoltoso. Il client ed il server devono accordarsi sull'autorizzazione,
sul diritto di proprietà del file e sul formato dei dati; quest'ultimo è di
fondamentale importanza perchè potrebbe rendere impossibile la traslazione inversa;
tenendo anche in condiderazione che non tutte le differenze rappresentative possono essere
accomodate.
FTP (File Transfer Protocol) [standard09]
Il Trasferimento di File è tra gli applicativi TCP/IP più
frequentemente usati, ed esso influisce notevolmente traffico di rete.
L'FTP non si limita alle funzioni di trasferimento, ma offre molti altri servizi:.
Come per altri servers, la maggior parte delle implementazioni server FTP permette un accesso
simultaneo a più clients, i quali usano il TCP per connettersi ad esso.
Un singolo processo master server aspetta una richiesta di connessione e quando questa è
instaurata, crea un processo slave per gestirla che viene dirottato su un diverso numero di porta.
Il processo slave accetta e gestisce la control connection dal client, che reca i
comandi che dicono al server quale file trasferire, ma usa una connessione addizionale per la data
transfer connection, cioè per il trasferimento dei dati stessi.
La figura seguente illustra quanto detto:
Come mostra la figura, il processo di controllo client connette il processo di controllo server
usando una connessione TCP, mentre l'associato processo di trasferimento dati usa la propria
connessione TCP. In ogni caso l'FTP stabilisce una nuova connessione per il trasferimento
dati per ciascun file da trasferire.
In definitiva, le connessioni ed i processi di trasferimento dati possono essere creati
dinamicamente quando necessari, ma la connessione di controllo persiste durante tutta la
sessione. Una volta che questa scompare, la sessione è terminata ed il software di
entrambe le parti termina tutti i processi di trasferimento dati.
Assegnazione del numero di Porta TCP
Quando un client forma una connessione iniziale con un server, usa localmente un
numero di porta di protocollo random , ma contatta il server ad una ben
nota porta (21) [standard09]. Un server, che usa solo una porta di protocollo può accettare connessioni
da molti clients; quando i processi di controllo creano una nuova connessione TCP per un
trasferimento di dati, essi non possono usare la stessa coppia di numeri di porta usati nella
connessione di controllo.
Il client ottiene una porta libera sulla sua macchina, ed la usa per contattare il processo di
trasferimento dati sulla macchina del server, il quale può usare una porta riservata per
il trasferimento dati FTP (20) [standard09].
Per assicurarsi che il processo di trasferimento dati sul server connetta il corretto
processo sulla macchina del client, il server non deve accettare connessioni da un processo
arbitrario, ma deve specificare la porta che sarà usata sulla macchina del client e
la porta locale.
In definitiva il processo di controllo client può ottenere una porta locale random da
usare nel trasferimento di file, comunicare il numero di porta al server sulla connessione di
controllo ed aspettare che il server stabilisca un processo di trasferimento dati
accettando una connessione da quella porta; dopo parte il processo di
trasferimento sulla macchina del client per realizzare la connessione.
Il formato usato dal TCP affinchè i dati passino attraverso la connessione di controllo
è il Network Virtual Terminal (NVT), ma diversamente dal protocollo TELNET, l'FTP
non permette opzioni di negoziazione ed usa solo la definizione di base NTV.
FTP dal punto di vista dell'utente TFTP (Trivial File Transfer Protocol)
NFS (Network File System)
RPC (Remote Procedure Call)
Gli utenti vedono FTP come un sistema interattivo. Una volta invocato,
il client esegue le seguenti operazioni in modo ricorsivo: leggere una linea di input,
scandire la linea per estrarre un comando ed i suoi argomenti, ed eseguire il comando
con gli specificati argomenti. Per esempio, per originare la versione di FTP disponibile
sotto BSD UNIX, l'utente invoca il comando ftp:
% ftp
Il programma del client FTP locale viene attivato e presenta all'utente un prompt.
Seguendo il prompt, l'utente può originare comandi come help.
ftp> help
I comandi possono essere abbreviati. I comandi sono:
! cr macdef proxy send
$ delete mdelete sendport status
account debug mdir put struct
append dir mget pwd sunique
ascii disconnect mkdir quit tenex
bell form mls quote trace
binary get mode recv type
bye glob mput remotehelp user
case hash nmap rename verbose
cd help ntrans reset ?
cdup lcd open rmdir
close ls prompt runique
Per ottenere più informazioni riguardo un dato comando, l'utente può
digitare help command come nel seguente esempio (l'output è mostrato
nel formato prodotto dall'FTP):
ftp> help ls
ls list contents of remote directory
Per eseguire un comando, l'utente deve digitare il nome del comando stesso:
ftp> bell
bell mode on.
Nonostante FTP sia il principale dei protocolli di trasferimento di files
nel complesso TCP/IP, è anche il più complesso e difficile da implementare.
Molte applicazioni non necessitano della piena funzionalità che l'FTP offre, nè
si possono permettere la sua complessità.
Il complesso TCP/IP contiene un secondo protocollo di trasferimento dei files che fornisce
servizi non costosi e poco sofisticati usato generalmente per connessioni locali. Noto come Trivial File Transfer Protocol, o
TFTP, esso è mirato a quelle applicazioni che non necessitano interazioni complesse
tra client e server. TFTP riduce le operazioni a semplici trasferimenti di files e non
fornisce certezze perchè usa il protocollo UDP che non è sicuro.
Il software del TFTP è di dimensioni minori di quello dell'FTP, e ciò
è importante in molte applicazioni. Per esempio, i costruttori di
dispositivi senza disco possono collocare TFTP in memorie di tipo ROM e usarlo per ottenere
una image iniziale della memoria quando la macchina è avviata; il programma
nella ROM è detto system bootstrap.
Diversamente dall'FTP, il TFTP necessita di un servizio di trasporto di flusso affidabile ma non lo usa.
Esso si appoggia sull'UDP o su qualsiasi altro sistema di recapito dei pacchetti inaffidabile,
usando il timeout e la ritrasmissione per assicurarsi che i dati arrivino. Il mittente
trasmette un file in blocchi di dimensione fissa (512 byte) ed aspetta un acknowledgement
per ogni blocco prima di inviare il successivo. Il ricevente deve inviare un messaggio
di acknowledgement per ogni blocco ricevuto.
Le regole per il TFTP sono semplici. Il primo pacchetto inviato richiede un trasferimento
di file e instaura una interazione tra client e server - il pacchetto specifica un nome di
un file e se il file sarà letto (trasferito al client) oppure scritto (trasferimento
al server). I blocchi del file sono numerati in modo consecutivo a partire da 1.
Ogni pacchetto dati contiene un header che specifica il numero assegnato al blocco, ed
ogni acknowledgement contiene il numero del blocco che ha ricevuto riscontro. Un blocco
di dimensione inferiore a 512 bytes segnala la fine del file. E' possibile inviare un
messaggio d'errore sia al posto dei dati che a quello di un acknowledgement; gli errori
fanno terminare il trasferimento.
La figura mostra il formato dei cinque tipi di pacchetti TFTP. Il pacchetto iniziale deve
usare i codici delle operazioni 1 o 2, specificando se sia una read request
(richiesta di lettura) o una write request (richiesta di scrittura). Il pacchetto iniziale
contiene sia il nome del file che il modo d'accesso che il client richiede (read access o
write access).
Una volta fatta la richiesta di lettura o di scrittura, il server adopera l'indirizzo IP ed
il numero di porta del client per identificare le operazioni seguenti.
Inoltre, nè i messaggi data (che recano blocchi del file) nè i messaggi
ack (che recano il riscontro dei blocchi dati) necessitano la specifica del nome
del file. Il tipo di messaggio finale illustato in figura è usato per gli errori.
Molti messaggi possono essere ritrasmessi dopo un timeout, ma la maggiorparte degli altri errori
causa semplicemente la fine della interazione.
La ritrasmissione TFTP è simmetrica. Ambo le parti implementano un
timeout ed una ritrasmissione. Se il mittente va fuori tempo massimo, ritrasmette l'ultimo
blocco di dati. Se invece la parte responsabile per gli acknowledgements va fuori tempo massimo,
ritrasmette l'ultimo acknowledgement. Dato che entrambe le parti partecipano alla ritrasmissione,
assicura che il trasferimento non fallisce a causa della perdita di un singolo pacchetto.
Anche se la ritrasmissione simmetrica garantisce una certa robustezza, può però
portare ad una eccessiva ritrasmissione. Il problema, noto come Sorcerer's Apprentice
Bug (disturbo dell'apprendista stregone), sorge quando un acknowledgement per un pacchetto
dati k è in ritardo, ma non è andato perso. Il mittente ritrasmette il
pacchetto dati che il ricevente riscontra. Entrambi gli acknowledgements arrivano, ed ognuno
causa la trasmissione del pacchetto dati k+1. Il ricevente invierà il riscontro
per entrambi i pacchetti k+1, e tali acknowledgements causeranno la trasmissione dei
due pacchetti k+2. Il Sorcerer's Apprentice Bug può anche originarsi se la rete
duplica i pacchetti. Una volta iniziato, il ciclo continua in modo indefinito ed ogni pacchetto
sarà trasmesso esattamente due volte.
Inizialmente sviluppato dalla Sun Microsystem Incorporated, il
Network File System (NFS) fornisce un accesso on-line a file condivisi che risulta
trasparente ed integrato: molti siti TCP/IP usano NFS per interconnettere i file system
dei propri computers. Un utente può eseguire un programma applicativo arbitrario ed usare
files arbitrari per l'input e l'output. Gli stessi nomi dei files non mostrano se i files sono
remoti o locali.
La figura illustra come NFS sia legato al sistema operativo. Quando si esegue un programma
applicativo, esso chiama il sistema operativo per aprire (open) un file, o per
memorizzare (store) e richiamare (retrieve) dati nei files.
Il meccanismo di accesso ai files accetta la richiesta ed automaticamente la passa o al
software del file system locale o al client dell'NFS, a seconda se il file è su un disco
locale o su una macchina remota. Quando riceve una chiamata, il software del client usa il
protocollo NFS per contattare il server appropriato su una macchina remota ed eseguire
l'operazione richiesta. Quando il server remoto risponde, il software del client riporta i
risultati al programma applicativo.
Invece di definire il protocollo NFS nel suo insieme, i progettisti
decisero di costruire tre parti indipendenti: il protocollo NFS stesso, un meccanismo
general-purpose Remote Procedure Call (RPC) ed un general-purpose eXternal
Data Representation (XDR). L'intento era quello di separare le tre parti per rendere
possibile l'uso di RPC e XDR da parte di altri software, includendo programmi applicativi
ed altri protocolli. Una volta configurato l'NFS, i programmi accedono ai files remoti usando
esattamente le stesse operazioni che usano per files locali.
Comunque, sia l'RPC che l'XDR forniscono meccanismi che i programmatori possono usare per
costruire programmi distribuiti.
Per esempio, un programmatore può dividere un programma in una parte client ed in
una server che usa RPC come meccanismo di comunicazione principale. Dalla parte del client,
il programmatore imposta alcune procedure come remote, costringendo il compilatore
ad incorporare il codice RPC in quelle procedure. Dalla parte del server, il programmatore
implementa le procedure desiderate ed usa altri strumenti dell'RPC per renderle parte del
server. Quando il programma esecutivo del client chiama una delle procedure remote, l'RPC
raccoglie automaticamente i valori degli argomenti, forma un messaggio, invia il messaggio
al server remoto, aspetta una risposta, e registra i valori restituitigli negli argomenti
designati. In breve, la comunicazione col server remoto avviene automaticamente come un
effetto collaterale della procedura di chiamata remota. Il meccanismo RPC nasconde tutti
i dettagli del protocollo, rendendo possibile al programmatore che conosce poco dei
protocolli di comunicazione sottostanti di scrivere programmi distribuiti.
Uno strumento correlato, l'XDR, fornisce un modo ai programmatori di far passare dati tra
macchine eterogenee senza scrivere procedure per convertire le rappresentazioni hardware
dei dati. L'XDR risolve il problema definendo una rappresentazione indipendente dalla macchina.
Ad un capo del canale di comunicazione, un programma invoca procedure XDR per convertire
dalla rappresentazione hardware locale in quella indipendente dalla macchina. Una volta che
il dato è stato trasferito ad un'altra macchina, il programma ricevente invoca le
routines XDR per convertire dalla rappresentazione indipendente dalla macchina in quella
della macchina locale.
Il maggior vantaggio dell'XDR è che esso automatizza la maggiorparte del compito
di conversione dei dati. I programmatori non hanno bisogno di digitare manualmente le
chiamate alle procedure XDR, ma essi forniscono al compilatore XDR le dichiarazioni
dal programma per cui i dati devono essere trasformati, ed il compilatore genera automaticamente
un programma con le necessarie chiamate alle librerie XDR.
