Prova di collegamento
Prova di collegamento
Per collaudare il server realizzato a pagina precedente procediamo nel seguente modo. Innanzitutto eseguiamo il server, lanciando il comando node server.js. Dopodiché, per simulare la connessione del client apriamo un’altra shell (ad esempio un altro prompt dei comandi) che svolgerà il ruolo di client. Per connettere il client al server basterà digitare il comando telnet localhost 5010. Se lavoriamo con Windows dovremmo trovarci in una situazione come quella di figura 1.
Figura 1 – Finestra del server e finestra del client
Dopo esserci connessi possiamo provare a digitare il comando status() su una qualsiasi delle due finestre. In ogni caso il risultato dovrebbe essere il seguente
1 | Server is up and running |
Se infatti guardiamo al codice di pagina precedente vedremo che abbiamo aggiunto la funzione status alla shell, usando l’istruzione
1 | remote.context.status =status ; |
a questo punto dovremo notare che in realtà abbiamo eseguito un’istruzione di questo tipo due volte, perché abbiamo anche scritto
1 | local.context.status =status ; |
Questo perché lo snippet di pagina precedente crea due console, ovvero inizializza due shell: una locale e una remota. Quella remota è disponibile solo quando ci colleghiamo da un’altra finestra, usando il protocollo telnet. Quella locale invece è disponibile direttamente sul server, quando eseguiamo lo snippet Node.js. Quest’ultima shell non è strettamente necessaria se vogliamo usare lo snippet per monitorare il server da remoto: l’abbiamo inserita a scopo didattico, per mostrare come cambia il comportamento del modulo REPL quando precisiamo un flusso d’ingresso diverso. Nel nostro caso le due shell si distinguono proprio dal flusso d’ingresso: la shell remota accetta in ingresso la connessione telnet, mentre quella locale accetta in ingresso i dati provenienti dalla tastiera.
Con questo abbiamo finito. Come accennato, la funzione status andrebbe arricchita aggiungendo il codice che vogliamo monitorare. In questo modo possiamo eseguire la funzione status da una qualsiasi macchina remota, esattamente come se fossimo sul server. Come già detto, ai fini della sicurezza, questo è possibile solamente se il server remoto accetta in ingresso connessioni di tipo telnet. Questo aspetto solitamente dipende dalla configurazione del provider: se non abbiamo accesso a tale configurazione la connessione telnet potrebbe essere disabilitata. In altre parole: se non possiamo configurare accessi di tipo telnet, lo snippet di pagina precedente dovrebbe essere del tutto innocuo. Conclusioni
Lo snippet di pagina precedente usa due volte l’oggetto shell ritornato dal modulo “repl”. Ciò significa che l’istruzione di import del modulo, oltre a rendere accessibile il modulo “repl”, si occupa anche di creare l’oggetto che rappresenta la shell, tramite l’istruzione
1 | var shell = require("repl") ; |
se guardiamo al codice, vedremo che eseguiamo il metodo start su quest’oggetto due volte: la prima volta per la variabile local, la seconda volta per la variabile remote. Queste due variabili sono quindi “imparentate” perché create eseguendo lo stesso metodo start sullo stesso oggetto shell. Ciò suggerisce che le due shell (locale e remota) non siano indipendenti: possiamo verificarlo creando una variabile da una parte (scrivendo ad esempio “a=12”) e poi visualizzando la stessa variabile dall’altra parte (scrivendo ad esempio “a+2”).
La conclusione è che le due shell sono connesse e quindi permettono di condividere dati e funzioni. È proprio in virtù di questo meccanismo che possiamo monitorare, da una macchina remota, qualsiasi variabile esistente nell’ambiente Node.js. Le potenzialità sono moltissime e vale la pena fare qualche prova: anche se non useremo mai telnet come protocollo per monitorare la macchina remota, è sempre utile essere in grado di verificarne il funzionamento.
