1. Introduzione
  2. Il campo location
  3. I tasti e la cache
  4. Il menù
  5. Riga di comando
  6. File di testo e file binari
  7. I buffer di ricezione
  8. UDP fallisce
  9. Diagrammi di transizione
  10. Documentazione Completa
  11. Informazioni aggiuntive
Protocollo
Analisi prestazioni
Client
Server
Download
news 


 

Introduzione
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.


INDICE

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.
INDICE

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.
INDICE

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ù:

Vediamo il significato dei campi nell'ordine:

  1. numero di righe della finestra di testo
  2. numero di colonne       "         "    "
  3. larghezza della finestra del client in pixel
  4. altezza        "        "        "      "      "   "
  5. ampiezza del buffer di ricezione TCP in byte
  6.     "           "       "      "        "      UDP "    "
  7. directory contenente la cache
  8. nome del file in cui queste (ed altre)  impostazioni vengono salvate
  9. nome del file in cui vengono salvati i dati temporanei
  10. simbolo che sostituisce il nome della risorsa nella riga di comando (vedi oltre)
i tasti:
  1. Okay: accetta le impostazioni (saranno salvate in uscita dal programma)
  2. Default: risetta tutti i valori tradizionali
  3. Cancel: annulla tutto e esce
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.
 
INDICE

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.

INDICE

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:

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)

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.

INDICE

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.
 
INDICE

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:



INDICE

Presentiamo ora dei sintetici diagrammi che illustrano il comportamento dei due client:

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.
In questa documentazione sono anche presenti quelli relativi al server.

INDICE

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

INDICE

Last modified: Sat Jan 30 10:39:43 CET 1999