• Non ci sono risultati.

Capitolo 5

N/A
N/A
Protected

Academic year: 2021

Condividi "Capitolo 5"

Copied!
24
0
0

Testo completo

(1)

Capitolo 5 – Descrizione del codice lato Client

61

Capitolo 5

Descrizione del diagramma a blocchi dell’applicativo lato client

Descriveremo in questa sezione il codice contenuto nel diagramma a blocchi dell’applicativo lato client .

Il pannello frontale dell’applicativo è mostrato in figura 5.1

Fig. 5.1 : Pannello frontale del client

5.1 Struttura del programma

La struttura del codice è composta da quattro cicli while che agiscono in parallelo.

E’ stata scelta questa strada per poter eseguire più istruzioni contemporaneamente e con diversi livelli di priorità .

(2)

Capitolo 5 – Descrizione del codice lato Client

62

Passiamo alla descrizione del ciclo while principale che racchiude la gestione delle funzionalità principali del sistema.

Tutte queste istruzioni sono a loro volta contenute in una struttura sequence che consente la corretta sequenzializzazione delle operazioni .

Il primo frame della sequence è illustrato nella figura seguente e permette la creazione del modulo per l’inserimento dei dati di accesso al sistema : username e password.

Fig. 5.2 : Prima parte del codice dell’applicativo lato client

Consente inoltre di visualizzare l’indirizzo IP del server che viene recuperato da un file di testo denominato indirizzo ip del server.txt , contenuto nella cartella Client Teledidattica

eseguibile.

Tale indirizzo può essere modificato attraverso un subVI che verrà descritto in seguito. Le istruzioni del primo frame sono tutte contenute in un ciclo while ; grazie a questo ciclo , se l’utente preme inavvertitamente il tasto ok prima dell’inserimento dei dati , viene invitato a inserirli tramite un messaggio di errore.

All’interno del while citato avviene anche l’inizializzazione dei dati visualizzati nel pannello frontale : il led status e l’indicatore di stringa risposta del server .

Inseriti i dati , alla pressione del tasto ok , le due stringhe vengono composte in un’unica stringa e passate al frame successivo.

(3)

Capitolo 5 – Descrizione del codice lato Client

63

Fig. 5.3 : Apertura connessione con il server

In tale frame avviene l’apertura della connessione con il server utilizzando la porta 2000 e l’indirizzo IP specificato in precedenza.

Nel caso si generino errori all’apertura della connessione , si recupera il codice dell’errore stesso , che , pilotando una struttura case permette la visualizzazione di un messaggio che avverte l’utente sulla natura del problema .

Questo ,causa inoltre l’uscita dall’applicazione.

Attraverso una funzione TCP write viene inviata al server la stringa contenente i dati di autenticazione.

(4)

Capitolo 5 – Descrizione del codice lato Client

64

Fig. 5.4 : Ricezione informazioni dal server

Si utilizza poi una funzione TCP read che, utilizzando lo stesso identificativo di connessione, riceve la risposta del server.

La stringa ricevuta va a pilotare una struttura case che permette la gestione dei casi : autenticazione fallita , server occupato e corretta autenticazione .

Nel caso di autenticazione fallita il server invia il carattere F che corrisponde ad un omonimo caso nella struttura case .

Il codice è mostrato in figura 5.5

Fig. 5.5 : Caso di autenticazione fallita

Viene mostrato un messaggio attraverso il quale si invita l’utente a reinserire i dati oppure a terminare la sessione.

Nel caso in cui il server risulti occupato , invia al client il carattere “o” che attiva l’omonimo frame della struttura case .

In questo caso si genera un messaggio che avverte l’utente dello stato del server e lo invita a riprovare la connessione in un secondo momento.

Come si vede dalla figura 5.6 , dopo la comparsa del messaggio , la sessione viene interrotta.

Si è scelto di non prevedere un meccanismo di gestione di una eventuale coda perché abbiamo ritenuto che sia poco probabile che l’utente a casa decida di rimanere in attesa della conclusione della sessione di lavoro in corso per un tempo che può arrivare fino a trenta minuti.

(5)

Capitolo 5 – Descrizione del codice lato Client

65

Fig. 5.6 : Caso di server occupato

Dopo l’autenticazione del client , Il server invia la lista degli strumenti disponibili per il contro remoto.

Questo comporta l’esecuzione della parte di codice corrispondente al caso True della struttura case ( caso di default ) .

Queste istruzioni gestiscono il controllo e il rilascio degli strumenti disponibili sul server. Il codice corrispondente a questo caso è contenuto all’interno di una struttura sequence che consente una corretta sequenzializzazione delle istruzioni.

(6)

Capitolo 5 – Descrizione del codice lato Client

66

Fig. 5.7 : Codice corrispondente al caso di server libero

Per evitare che il caso di default venga attivato anche alla ricezione di un qualsiasi altro carattere diverso da “F” ed “O” , viene eseguita una ricerca nella stringa ricevuta per controllare la presenza del carattere speciale CR+LF .

Questo carattere compare all’inizio della stringa, dato che questa viene preliminarmente ribaltata.

La stringa ricevuta , mostrata in figura 4.8 , contiene anche il tempo in minuti a disposizione per completare la sessione.

Fig. 5.8 : Formato della stringa ricevuta

La stringa tempo viene convertita in un numero e moltiplicata per 600 per ottenere i decimi di secondo che andranno a pilotare il subVI conto alla rovescia.vi che descriveremo in seguito.

La parte restante della stringa viene inviata al subVI scelta vi.vi la cui icona è mostrata in figura 4.9.

(7)

Capitolo 5 – Descrizione del codice lato Client

67

Fig. 5.9 : Icona del subVI scelta vi.vi

Descriviamo brevemente il codice di questo subVI .

Le istruzioni sono contenute all’interno di una struttura sequence , i primi due frame sono mostrati in figura 5.10.

Fig. 5.10 : Prima parte del codice del subVI scelta vi.vi

Nel primo frame viene creato il vettore contenente i nomi dei VI disponibili ; questi vengono separati l’uno dall’altro tramite la ricerca del carattere speciale CR+LF .

Nel successivo frame , grazie al vettore ricavato in precedenza , viene generato un menù di scelta costituito da un controllo di tipo ring programmabile mediante un property node . L’ultima parte del codice è mostrata in figura 5.11.

(8)

Capitolo 5 – Descrizione del codice lato Client

68

Fig. 5.11 : Ultima parte del codice del subVI “ scelta vi.vi”

Grazie all’ inizializzazione dell’uscita del ring a zero , il sistema consente all’utente la scelta dello strumento da controllare.

Il dato , infatti , giunge alla parte successiva del codice solo quando la scelta pone l’uscita del ring ad uno stato diverso da zero.

Nel vettore creato ogni numero corrisponde a un particolare VI , grazie alla scelta fatta dall’utente siamo in grado di selezionare un particolare elemento del vettore stesso.

Utilizzando il nome associato al VI e l’indirizzo IP del server , il subVI build url.vi , la cui icona è mostrata in figura 5.12 , compone gli URL necessari per connettersi alla home page del sito internet del laboratorio di teledidattica e alla pagina che contiene il pannello frontale dello strumento da controllare.

(9)

Capitolo 5 – Descrizione del codice lato Client

69

Fig 5.12 : Icona del subVI build url.vi

Il numero corrispondente al VI selezionato dall’utente viene convertito in stringa e composto con il carattere speciale CR+LF .

Tale stringa viene inviata al server nel frame successivo , mostrato in figura 5.13 , dove viene aperta una nuova connessione .

Da notare che non esiste limite al numero di connessioni che il client può aprire verso il server non essendoci in questa direzione problemi di corretto indirizzamento dei dati , come visto nel capitolo dedicato alla descrizione del server.

Successivamente viene visualizzato un messaggio che informa l’utente del tempo disponibile per completare la sessione di lavoro.

Le istruzioni contenute nell’ultimo frame della struttura sequence che stiamo trattando sono inserite in un ciclo while per permettere l’iterazione ciclica delle istruzioni che andiamo a descrivere.

(10)

Capitolo 5 – Descrizione del codice lato Client

70

Vengono eseguiti in parallelo due subVI : conto alla rovescia modificato.vi e Punta URL.vi , le cui icone sono mostrate in figura 5.14 .

Fig. 5.14 : Icone dei subVI tempo disponibile e Punta URL

Partiamo dalla descrizione del subVI tempo disponibile.vi .

Esso ha un ingresso booleano che permette di avviare il subVI alla pressione del tasto OK sul messaggio visualizzato all’utente.

Al suo avvio fa comparire nello schermo del client un pannello frontale che visualizza lo scorrere del tempo a disposizione per completare la sessione e un led che indica lo stato della sessione.

Sono presenti inoltre tre tasti : help , cambia e stop .

Parte del codice contenuto nel diagramma a blocchi del subVI è mostrato in figura 5.15.

(11)

Capitolo 5 – Descrizione del codice lato Client

71

Tutte le istruzioni sono contenute in un ciclo while che permette sia il continuo aggiornamento del tempo visualizzato che il controllo dello stato dei tasti sopraccitati .

Tale ciclo viene ripetuto un numero di volte pari a quello dei decimi di secondo che portano al completamento del tempo utile totale.

E’ presente uno shift register che permette il recupero del tempo residuo e il riavvio del ciclo a partire da questo dato.

In uscita, oltre al numero citato in precedenza , sono presenti una stringa e un riferimento alla pagina web a cui l’utente può connettersi premendo il tasto help.

Questo riferimento viene utilizzato alla fine della sessione di lavoro per chiudere la finestra del browser che contiene la pagina web.

Tale pagina , contenuta all’interno della root directory del web server ( cartella www ) , è raggiungibile all’indirizzo http://IP del server / prima.htm e contiene informazioni relative all’utilizzo del sistema .

Alla pressione del tasto help si commuta a true lo stato del controllo che pilota la struttura

case che avvia la parte di codice mostrata nella figura 5.16.

Fig. 5.16 : parte del codice del subVI “conto alla rovescia modificato.vi”

Queste istruzioni permettono di costruire l’indirizzo URL della home del sito a partire dell’indirizzo IP del server, ricevuto in ingresso dal subVI , e di aprire il browser che punta a tale indirizzo mediante il subVI Punta URL.vi che sarà descritto in seguito.

L’uscita string pilota la struttura case che gestisce le operazioni di fine sessione di lavoro e cambio dello strumento.

(12)

Capitolo 5 – Descrizione del codice lato Client

72

Il controllo cambia ferma l’esecuzione del ciclo e produce in uscita la stringa cambia , mentre il controllo Boolean rappresenta il tasto stop e permette di uscire dal ciclo in qualsiasi momento , terminando cosi’ la sessione di lavoro .

In questo caso si produce in uscita il comando fine .

Come si vede dalla figura 5.17 lo stato del controllo cambia pilota il case che stabilisce la stringa in uscita.

Fig. 5.17 : Gestione della stringa in uscita

Nel caso in cui l’utente prema il tasto cambia , il risultato dell’uscita Numeric verrà utilizzato nel ciclo successivo come ingresso per permettere di far ripartire il ciclo tenendo conto del tempo già trascorso .

In uscita si produce la stringa fine anche quando scade il tempo disponibile per il completamento della sessione.

Passiamo ora alla descrizione del codice del subVI Punta URL.vi mostrato in figura 5.18.

Fig. 5.18 : Codice associato al subVI “Punta URL.vi”

Si apre un riferimento al browser impostato come predefinito ,poi mediante il primo property

node si rende visibile la finestra , mentre il secondo property node consente di puntare

all’indirizzo URL specificato in ingresso sotto forma stringa.

L’indirizzo specificato in ingresso è associato alla pagina che contiene il pannello dello strumento scelto .

(13)

Capitolo 5 – Descrizione del codice lato Client

73

Tale pagina è stata creata tramite il web publishing tool di labVIEW ( vedi appendice B) . I comandi e le informazioni scambiati tra client e web server viaggiano attraverso protocollo TCP-IP .

Infatti il web server di labVIEW gestisce la comunicazione con il client e con il VI dello strumento che si controlla.

Il client invia i comandi e riceve le risposte tramite il suo browser , il web server mette in comunicazione client e VI dello strumento.

La comunicazione tra server e strumento, invece, avviane tramite protocollo GPIB.

Come già detto in precedenza è presente in uscita un riferimento alla pagina aperta che consente la chiusura della stessa al termine delle operazioni.

Fig. 5.19 : Parte del codice che gestisce il cambio dello strumento

La struttura case mostrata in figura 5.19 permette la gestione delle operazioni di cambio strumento e fine sessione di lavoro.

E’ pilotata dalla stringa in uscita dal subVI conto alla rovescia.vi .

Nel caso in cui la stringa in uscita sia camb la prima operazione effettuata è quella di chiusura della pagina web che contiene il pannello dello strumento controllato in precedenza.

La chiusura della pagina avviene grazie al subVI chiudi url.vi la cui icona e è mostrata nella figura 5.20.

(14)

Capitolo 5 – Descrizione del codice lato Client

74

Questo subVI tramite l’ invoke node Quit e il riferimento alla pagina, ricevuto in ingresso, consente di chiudere la pagina stessa.

Nel caso in cui il client abbia chiuso manualmente la pagina si genera un errore che viene cancellato per evitare malfunzionamenti.

A questo punto si apre una nuova connessione con il server per l’invio della stringa camb che il server gestisce chiudendo il pannello dello strumento precedentemente controllato e mettendosi in attesa della stringa che identifica il nuovo strumento da controllare.

Sul client ricompare il pannello che contiene il menù di scelta degli strumenti .

Come descritto in precedenza il client invia un numero che corrisponde allo strumento scelto.

Fig 5.21 : Seconda parte del codice che gestisce il cambio dello strumento

Da notare che , per l’invio di tale numero, si utilizza il riferimento alla connessione aperta in precedenza.

Se non si verificano errori , e quindi lo status del cluster di errore è su false , il ciclo while non viene bloccato.

Questo permette di ritornare all’inizio del ciclo mostrato in figura 5.13 , in cui si ha l’apertura della pagina web contenente il pannello frontale del nuovo strumento e del pannello frontale del subVI che mostra il tempo residuo a disposizione.

Passiamo ora alla descrizione del codice che gestisce la situazione in cui l’utente decide di terminare la sessione , che corrisponde al caso “fine” della struttura case .

(15)

Capitolo 5 – Descrizione del codice lato Client

75

Le istruzioni che andremo ora a descrivere vengono eseguite anche nel caso in cui scada il tempo disponibile per completare la sessione.

Fig. 5.22 : Parte iniziale del codice che gestisce il caso di fine della sessione

La prima operazione consiste ,come nel caso già esaminato, nella chiusura della pagina web che contiene il pannello frontale dell’ultimo strumento controllato.

Successivamente viene aperta una nuova connessione e inviata la stringa fine.

Il Server chiuderà allora il pannello frontale dell’ultimo strumento controllato e invierà al client un messaggio per specificare tipologia e numero dei files da ricevere .

Tale messaggio viene letto mediante la funzione TCP Read che utilizza lo stesso identificativo di connessione usato per inviare il messaggio di fine sessione , come si vede dalla figura 5.23 .

(16)

Capitolo 5 – Descrizione del codice lato Client

76

La connessione viene chiusa e alla pressione del tasto OK da parte del client , viene eseguito il codice corrispondente al subVI file receivermultiplo.vi la cui icona è mostrata in figura 5.24 .

Fig 5.24 : Icona relativa al subVI file receivermultiplo.vi

In questa fase, il server è in ascolto della rete, in attesa delle richieste provenienti dal client riguardanti il tipo di file da ricevere.

Tutto il codice relativo al subVI file receivermultiplo.vi è contenuto in un ciclo for che viene eseguito due volte , una volta per i files di testo e una volta per i files immagine.

La prima parte del codice del subVI è mostrata in figura 5.25 .

Fig. 5.25 : Prima parte del codice del subVI file receivermultiplo.vi

La prima istruzione consiste nell’apertura di una nuova connessione per l’invio della parola che codifica il tipo di file richiesto ( “testo” e “ immag” ).

Tale parola è selezionata mediante l’indice i del ciclo for.

Viene poi letta la stringa inviata dal server che contiene il numero di files dello stesso tipo da ricevere.

(17)

Capitolo 5 – Descrizione del codice lato Client

77

La stringa , convertita in numero , pilota il ciclo for mostrato in figura 5.26 , che contiene tutte le istruzioni da ripetere per ciascuno dei files da ricevere.

Fig. 5.26 : Seconda parte del codice del subVI file receivermultiplo.vi

Queste istruzioni sono contenute in una struttura sequence in cui il primo frame gestisce l’apertura di una finestra di dialogo che consente all’utente di scegliere il percorso di salvataggio del file in arrivo.

L’estensione del file viene attribuita automaticamente e al client resta solo il compito di scegliere il nome del file e la collocazione.

Il sistema verifica se un file con lo stesso nome esiste già nella posizione scelta e in questo caso chiede al client se desidera sovrascrivere o rinominare il file.

Nel frame successivo , mostrato nella figura 5.27 , sono presenti le istruzioni per la creazione e la ricezione del nuovo file.

Viene creato un nuovo file avente nome e percorso specificati dal client .

Sfruttando lo stesso riferimento alla connessione viene ricevuto il numero di pacchetti in cui è stato suddiviso il singolo file.

Tale dato determina il numero di volte in cui viene eseguito un ulteriore ciclo for contenente le istruzioni per la ricezione del singolo pacchetto .

(18)

Capitolo 5 – Descrizione del codice lato Client

78

Fig. 5.27 : Terza parte del codice del subVI file receivermultiplo.vi

In questo ciclo , dapprima si legge la dimensione del pacchetto, che verrà utilizzata per specificare il numero di bytes letti dalla successiva funzione TCP Read .

Il singolo pacchetto viene ricevuto sotto forma di stringa e oltre a includere i dati componenti il file in forma binaria contiene anche il checksum ricavato come specificato nel capitolo precedente.

Questa stringa viene inviata al subVI decodifica pacchetto.vi la cui icona è mostrata nella figura 5.28.

Fig 5.28 : Icona del subVI decodifica pacchetto.vi

Viene calcolata la dimensione della stringa che rappresenta il pacchetto ricevuto , a questo numero si sottrae la dimensione del checksum (4 byte ) per separarlo dai dati utili.

Come si vede dalla figura 5.29 , la stringa dei dati utili viene convertita in un vettore numerico di dati binari .

(19)

Capitolo 5 – Descrizione del codice lato Client

79

A partire da questo vettore si calcola il nuovo checksum che viene confrontato con quello ricevuto.

Se i valori coincidono la trasmissione è andata a buon fine , in caso contrario si avverte l’utente che si è verificato un errore di rete.

Fig. 5.29 : Codice del subVI decodifica pacchetto.vi

Il vettore di dati binari in uscita dal subVI viene memorizzato utilizzando la funzione Write to

Binary File .

Le ultime operazioni descritte vengono ripetute per il numero di pacchetti che compongono il file inviato dal server.

Da notare come sia il riferimento alla connessione che quello al file vengono riutilizzati ciclicamente grazie all’uso di shift register.

Terminato tale ciclo si chiude il riferimento al file ma non quello alla connessione che viene sfruttato per ricevere i restanti files dello stesso tipo.

Infatti si torna al primo frame della struttura sequence appena descritta e vengono rieseguite le operazioni già illustrate per i files restanti.

Alla ricezione dell’ultimo file di uno stesso tipo si chiude la connessione, per evitare conflitti nella ricezione di files di tipo diverso.

Viene, a questo punto ,eseguito per la seconda volta il ciclo for e si ripetono le stesse istruzioni già illustrate per il secondo tipo di file da ricevere.

Terminata la ricezione dei files vengono chiuse le finestre del browser rimaste eventualmente aperte.

(20)

Capitolo 5 – Descrizione del codice lato Client

80

Infine , sfruttando lo status del cluster di errore , che si troverà sicuramente al valore false data la cancellazione di eventuali errori , e l’utilizzo della funzione Quit già descritta, si esce dall’applicazione.

E’ stata utilizzata una funzione AND per garantire l’uscita dall’applicazione solo dopo la completa ricezione dei files.

Le istruzioni appena descritte sono mostrate nella figura seguente.

Fig. 5.30 : Parte finale del codice dell’applicativo lato client

5.2 Cicli while paralleli

Passiamo a questo punto alla descrizione dei restanti cicli while che compongono il diagramma a blocchi dell’applicativo lato client.

Il primo ciclo permette di controllare lo stato del pulsante CAMBIA IP .

Si è scelto di memorizzare l’indirizzo IP del server in un file di testo denominato Indirizzo ip

del server.txt contenuto nella stessa cartella che contiene l’eseguibile lato client per fare in

(21)

Capitolo 5 – Descrizione del codice lato Client

81

Nel caso in cui l’utente abbia la necessità di modificare tale indirizzo, premendo il tasto

CAMBIA IP avvia il subVI nuovo_indirizzo_ip.vi come mostrato in figura 5.31.

Fig. 5.31 : Codice che permette il cambio dell’indirizzo IP del server

Tutto il codice di questo subVI è contenuto in un ciclo while che a sua volta contiene una

struttura sequence composta da tre frame ; i primi due sono mostrati nella figura 5.32.

Fig. 5.32 : Prima parte del codice del subVI nuovo_indirizzo_ip.vi

(22)

Capitolo 5 – Descrizione del codice lato Client

82

Da notare che vengono utilizzati la funzione Current VI’s Path e il subVI Folder _path.vi ,già descritti nel capitolo 4 , per far si che l’applicativo funzioni correttamente qualsiasi sia il percorso in cui sceglie di collocarlo l’utente .

Nel secondo frame si crea il modulo per la visualizzazione del valore attuale dell’IP e per l’inserimento dell’eventuale nuovo valore.

E’ presente un ciclo while che consente di controllare lo stato dei tasti Annulla e Inserisci . Nell’ultimo frame , mostrato in figura 5.33 , viene memorizzato il nuovo indirizzo IP inserito dall’utente nel file di testo citato in precedenza.

Le istruzioni sono contenute in una struttura case che permette di scegliere se cambiare o meno l’indirizzo IP .

Fig. 5.33: Seconda parte del codice del subVI nuovo_indirizzo_ip.vi

Da notare che, per via dell’azione meccanica utilizzata per i tasti ( Switch When Released ), è stato necessario reinizzializzare allo stato false i tasti dopo il loro utilizzo.

Infatti , tale meccanica, è stata scelta per fare in modo che ad ogni azione sul tasto corrispondesse una reazione immediata .

Questo meccanismo è stato realizzato mediante una struttura sequence formata da due frame ; il primo contiene le istruzioni da eseguire alla pressione del tasto mentre il secondo , mediante una variabile locale , compie l’ inizializzazione .

(23)

Capitolo 5 – Descrizione del codice lato Client

83

Fig. 5.34 : Meccanismo di inizializzazione dei tasti

Il terzo ciclo while presente nel diagramma a blocchi dell’applicativo lato client permette il controllo dello stato del tasto Help .

Alla pressione del tasto si apre una finestra del browser predefinito che punta alla pagina di Help già descritta in precedenza.

I subVI presenti nel codice sono già stati descritti in questo capitolo.

Fig. 5.35 : Controllo dello stato del tasto Help

L’ultimo ciclo while , mostrato in figura 5.36 , consente di controllare lo stato del tasto STOP che permette di uscire dall’applicazione .

(24)

Capitolo 5 – Descrizione del codice lato Client

Figura

Fig. 5.1 : Pannello frontale del client
Fig. 5.2 : Prima parte del codice dell’applicativo lato client
Fig. 5.5 : Caso di autenticazione fallita
Fig. 5.8 : Formato della stringa ricevuta
+7

Riferimenti

Documenti correlati

Entra in scena un personaggio cattivo = antagonista che crea un problema.. Il protagonista deve lottare con l’antagonista per risolvere

Come punto di partenza dell’analisi del testo e della rappresentazione teatrale mi sono posto una domanda: vista la peculiarità e la qualità del testo di Chlebnikov, vista

Essi sono essenzialmente funzione dell area A, del perimetro P e della lunghezza dell asta principale L..

L’ escoriosi della vite, causa- ta da Phomopsis viticola Sacc., nota anche come necrosi corticale, è una malattia fun- gina conosciuta sin dagli anni 50 che ha assunto, in

[r]

Su istanza del Responsabile del Progetto, considerata la necessità di garantire il corretto svolgimento delle attività di ricerca, si rende necessario modificare

Il capitolo 113.1928 “Incarichi libero professionali di studi, ricerca e consulenza”, viene diminuito di € 19.001,02;. Il capitolo 113.1930 “Collaborazioni coordinate e

Considerata la necessità di garantire il corretto compimento delle attività di ricerca afferenti alla Struttura di Ricerca 4 - Strumenti e Metodi per la