|
|
|
|
|
|
|
|
Introduzione
Vediamo il significato dei campi nell'ordine:
Da qui si puo' scegliere se salvare il file su disco, nel file specificato
nel campo testuale, o se lanciare un programma che se ne occupi al volo.
In questo caso è possibile scrivere una intera linea di comando,
che GFGC interpreta: la risorsa si può sostituire con $$ (vedi menù
avanzato). Sotto Windows la cosa non è utilissima, ma ad esempio
sotto Linux un uso smodato sarebbe (chiedendo un'immagine; ad esempio prova.gif)
Nel diagramma del client UDP si può notare che il client termina
la sua vita nel momento in cui riceve il pacchetto di risposta oppure un
timeout quando è in fase di ricezione. E' chiaro che qui stiamo
parlando dell'attivazione della classe Java che implementa il client UDP.
Ogni invocazione attiva un thread il cui ciclo di vita è quello
presentato.
In questo diagramma notiamo come, a differenza del precedente, ci sia
un loop sulla ricezione dati che termina solo all'arrivo di tutti i dati
specificati nell'header del pacchetto. Il client TCP non è un thread
ma è realizzato da una funzione di una particolare classe.
GFGC è il nome (in codice) del client realizzato per il server
GFGS.
E' stato realizzato in Java, cercando di avere un programma per piu' piattaforme possibili, essendo, spesso, i client nelle situazioni pił diverse.
I test sono stati fatti in ambiente Linux e Windows.
Ecco alcuni sceen shot che ce lo mostrano in ambiente Microsoft:
In background possiamo vedere due shell DOS; su una è stato lanciato
MultiTcpServer,
sull'altra UdpServer. Da una terza shell
abbiamo lanciato CGUI3, che è il nome del file principale associato
a GFGC. In questo caso particolare stiamo utilizzando Java 1.2rc3.
Appena lanciato il client legge da un file di configurazione gli ultimi
valori impostati dall'utente, e poi mostra la schermata che vediamo sulla
sinistra. L'interfaccia mette a disposizione un minimo di strumenti utili
all'esecuzione di qualche richiesta GET, che avviene riempiendo il campo
Location
con
un indirizzo in formato standard. Il formato è una variazione di
HTTP, e consente una certa elasticità poiché tenta di completare
la richiesta nel caso manchi qualche campo (come ad esempio http://).
Il nome del protocollo viene infatti deciso in base ai bottoncini laterali
(UDP e TCP) che consentono all'utente di scegliere il protocollo
che desiderano utilizzare nella esecuzione della GET.
Nell'esempio abbiamo digitato localhost:8080/dragon : è
attivo il tasto TCP, dunque il client in realtà traduce in http-tcp://localhost:8080/dragon.
Avremmo potuto specificare indifferentemente http:// o http-tcp:// e il
risultato sarebbe stato lo stesso. Inserendo http-udp:// ma tenendo attivo
il tasto TCP il campo viene automaticamente corretto a http-tcp://. La
porta di default è la 8080, che dunque avremmo anche potuto tralasciare.
Dopo aver scritto l'indirizzo possiamo premere i tasti SEND o RELOAD
,e
così inizia la creazione del socket e la comunicazione. La differenza
fra i due tasti è di facile intepretazione: GFGC mantiene una cache
su disco delle pagine visitate, dunque ogni volta che si esegue una send
il programma cerca dapprima in cache, poi effettua il collegamento: la
pressione del tasto reload obbliga il client a trascurare la cache.
E' possibile "navigare" nella cache coi tasti back e forward
,questi
però hanno un comportamento diverso dagli analoghi di
Netscape
o simili, poiché consentono di guardare tutta la cache, andando
indietro fino alla pagina cronologicamente più vecchia, avanti fino
all'ultima richiesta. La cache si può pulire selezionando la voce
Clear
Cache dal menù Options
. E' chiaro che essa ha un numero
fisso di entry, superato il quale inizia a sovrascrivere i record più
vecchi. Il tasto List, infine, mostra tutte le URL presenti in cache.
La scelta di menù non è vastissima, ma contiene il minimo
necessario: si può salvare/caricare un file tramite schermate tipiche,
pulire lo schermo, uscire dal programma, pulire la cache, aprire un menù
di opzioni avanzate, settare un timeout in ricezione, chiamare l'aiuto.
Il Timeout stabilisce quanto al massimo il client, dopo che
è stata fatta una richiesta, resta in attesa della risposta del
server. Trascorso questo il client ignora eventuali risposte ritardatarie.
(vedi immagine successiva) La scelta di infinito, se pure possibile, non
è molto indicata.
Le opzioni avanzate consentono di stabilire vari parametri del
client. vediamo il menù:
i tasti:
Questo menù è pericoloso: consente impostazioni che potrebbero
generare eccezioni: tuttavia ciò non causa il blocco del programma
ed è sempre possibile risettare i default tornando a un funzionamento
normale.
E' possibile invocare GFGC con l'opzione -v o --verbose (>java CGUI3 -v)
per far sì che questi stampi sullo standard output una serie di
messaggi (davvero tanti, è consigliabile la redirezione su file)
che sono stati usati da noi per il debugging e che possono dare qualche
informazione in più in caso di errori. E' altresì chiaro
che tutte queste stampe rallentano molto il programma.
Le richieste possono coinvolgere sia file testuali, per i quali è
previsto il salvataggio in cache (URL compresa!) e la stampa su schermo,
sia file binari: per questi ultimi nella cache viene solo salvata la URL,
e il programma chiede come deve comportarsi:
Ne risulterebbe l'apertura del programma XV, con visualizzazione di "prova.gif"
ritagliata dalle coordinate specificate.
Nella prima immagine abbiamo chiesto "dragon". Questo è un file
JPG che il server MultiTcpServer (conforme a GFG) ha preso e passato a
GFGC. Sotto Windows abbiamo Java1.2 , e dunque GFGC, riconoscendo il file
JPG dal Mime-Type (Image/JPEG e variazioni), ha caricato una classe (sempre
realizzata da noi con gli strumenti di Java1.2) in grado di visualizzare
al volo l'immagine (come si vede dalla finestra aperta con titolo la URL).
Sebbene Java1.1 contenga delle librerie adatte alla visualizzazione,
il supporto per la loro visualizzazione è presente in GFGC solo
se si usa Java1.2, a causa della diversa organizzazione delle suddette
librerie nelle diverse versioni del linguaggio.
Nel menù avanzato è possibile settare il valore dei campi
BUFFER_RICEZIONE_TCP e BUFFER_RICEZIONE_UDP. Vediamo cosa significa.
GFGC scarica dati mettendoli temporaneamente in un buffer. Questo buffer
ha chiaramente dimensione finita, che l'utente può settare. Cosa
succede se i dati in arrivo sono superiori in quantità a questa
dimensione? GFGC mette su un meccanismo di lettura "a blocchi" ciascuno
di dimensione pari a quella del buffer e ne fa uso senza MAI riempire la
memoria con tutti i dati arrivati dalla rete: nel caso di grandi quantità
infatti ogni volta svuota il buffer e ne scrive su disco il contenuto,
lavorando successivamente col solo riferimento del file (a meno che l'utente
non ne chieda l'intero caricamento).
Nel caso di UDP non ha molto senso settare il buffer a valori superiori
alla dimensione del pacchetto più grande che può circolare
sulla rete. Vediamo di spiegare meglio la
cosa: poiché GFG manda in risposta a HTTP-UDP sempre e solo 1
unico
pacchetto, e che la dimensione di questo è fissata dalla rete (o
meglio dalle reti) sottostanti (ad esempio in Ethernet siamo sulle 1500byte),
non avrebbe senso settare 10K di buffer, poiché ne verrebbero riempite
solo una minima parte.
Il discorso cambia per TCP: in risposta alla
richiesta GFGS spedisce la risorsa segmentandola in varie parti (vedi il
server),
e dunque l'ampiezza del buffer diviene rilevante. Nelle prove svolte si
è visto che GFGC non riesce a tenere i ritmi di GFGS (e forse qualcuno
se lo aspettava anche), che spesso è costretto a fermarsi (sempre
in attesa di altre richieste) perché GFGC non riesce a svuotare
il socket in tempo. Un buffer di una certa ampiezza (almeno 5K) si rivela
benefico per le prestazioni, ma comunque tutto funziona anche con buffer
esigui.
Durante la ricezione di file di una certa grandezza
GFGC mostra una barra di "download in progress" che dà una idea
del tempo mancante.
Nel caso in cui si richieda una risorsa di dimensione troppo grande per
UDP, il server, accorgendosi di questo problema, invia un pacchetto contenente
uno speciale codice di errore ("444"). GFGC riconosce questo codice e automaticamente
reimposta la stessa richiesta con TCP, previa conferma da parte dell'utente:
Presentiamo ora dei sintetici diagrammi che illustrano il comportamento
dei due client:
In questa documentazione sono anche presenti quelli relativi al server.
GFGC è stato realizzato lavorando sia con Java1.2 sotto Windows
che con Java1.1.6-7 sotto Linux.
Per maggiori informazioni consultare il codice
di GFGC1.0
Last
modified: Sat Jan 30 10:39:43 CET 1999