In questa lezione esploriamo il ruolo fondamentale del client all'interno delle moderne architetture di rete, analizzandone le caratteristiche tecniche e le funzionalità nei contesti Cloud e Web Services.
Comprendere il comportamento e le responsabilità del client è essenziale per padroneggiare il funzionamento dei sistemi distribuiti previsti dal programma TPSIT 5.
Uno studente controlla le previsioni del tempo dal proprio smartphone mentre e sull'autobus, con la connessione che va e viene; poco dopo, a casa, apre lo stesso servizio dal computer portatile con Wi-Fi stabile. In entrambi i casi il client cambia dispositivo, sistema operativo e tipo di connessione, eppure il servizio continua a funzionare. Questo esempio mostra bene che il client, pur essendo il "lato piu semplice" della coppia client-server, deve rispondere a esigenze molto diverse da quelle viste per il server nella lezione precedente. In questa lezione vediamo quali sono le caratteristiche tipiche di un buon client.
Come visto nella lezione sulla definizione generale di client-server, il client e chi avvia la comunicazione: decide lui quando collegarsi e cosa richiedere. Da questo deriva una prima caratteristica importante: a differenza del server, il client non ha bisogno di un indirizzo di rete fisso e conosciuto. Nessuno deve "trovare" un client per contattarlo, perche e sempre il client a contattare per primo il server. Questo permette al client di cambiare rete liberamente (passare dal Wi-Fi di casa alla rete dati del telefono, spostarsi da una rete all'altra) senza che il servizio smetta di funzionare, mentre per un server, come visto in precedenza, questo tipo di cambiamento continuo sarebbe un problema.
Questa liberta ha pero un rovescio della medaglia: siccome e il client a decidere quando collegarsi, deve anche essere lui a gestire i momenti in cui la connessione manca del tutto o e instabile, cosa che vedremo tra poco.
Un server, in genere, gira su un numero limitato di macchine gestite direttamente da chi eroga il servizio. Un client, al contrario, deve poter funzionare su una grandissima varieta di dispositivi: computer con sistemi operativi diversi (Windows, macOS, Linux), smartphone e tablet con sistemi diversi (Android, iOS), schermi di dimensioni molto diverse tra loro. Questa varieta si chiama eterogeneita, ed e una caratteristica strutturale del lato client che non ha un vero equivalente dal lato server.
Per gestire l'eterogeneita, i client devono rispettare standard e protocolli comuni e ben documentati: e proprio perche client molto diversi tra loro sanno "parlare" lo stesso linguaggio verso il server che un sito web, per esempio, funziona allo stesso modo su un computer Windows e su uno smartphone Android. I dettagli tecnici di questi protocolli di comunicazione saranno oggetto delle prossime lezioni di questa unita.
Regola fondamentale: mentre il server e tipicamente un ambiente omogeneo e controllato da chi offre il servizio, il client deve funzionare correttamente in un ambiente eterogeneo e non controllato, fatto di dispositivi, sistemi operativi e condizioni di rete molto diversi tra loro.Un'altra caratteristica distintiva del client e che, molto spesso, e lui il punto di contatto diretto con una persona: deve quindi occuparsi di presentare le informazioni ricevute dal server in un modo comprensibile (testo leggibile, immagini, pulsanti) e di raccogliere correttamente cio che l'utente vuole richiedere. Il server, invece, normalmente non ha nessuna interfaccia pensata per un utente umano: riceve e restituisce dati in un formato pensato per essere letto da un altro programma.
Proprio perche e il client a poter perdere la connessione in qualunque momento (spostandosi, entrando in una zona senza copertura, e cosi via), un client ben progettato deve saper gestire gli errori di rete in modo chiaro: riconoscere quando una richiesta non ha ricevuto risposta entro un tempo ragionevole (timeout), eventualmente riprovare automaticamente, e soprattutto informare l'utente in modo comprensibile ("connessione assente" e molto piu utile di un messaggio tecnico incomprensibile). Alcuni client vanno oltre e conservano localmente gli ultimi dati ricevuti, in modo da poter mostrare qualcosa (per esempio l'ultima previsione del tempo scaricata) anche quando la connessione al server non e momentaneamente disponibile.
Un'app di previsioni meteo su smartphone, se non trova connessione, mostra spesso l'ultimo dato aggiornato scaricato in precedenza insieme a un avviso ("dati non aggiornati, ultima sincronizzazione alle..."), invece di lasciare la schermata vuota o mostrare un errore incomprensibile. Questo e un esempio di gestione corretta dell'assenza di rete lato client. In un laboratorio scolastico di informatica, alcuni computer possono avere Windows installato e altri Linux, eppure tutti riescono a collegarsi allo stesso server didattico della scuola per consultare gli stessi materiali. Questo funziona perche il client (per esempio il browser) su entrambi i sistemi operativi rispetta gli stessi standard di comunicazione verso il server, nonostante l'eterogeneita dei dispositivi.A differenza del server, che di norma dispone di risorse hardware dimensionate per gestire moltissimi utenti insieme, il client gira sul dispositivo personale dell'utente, che puo avere risorse limitate (si pensi a uno smartphone di fascia economica). Un client ben progettato deve quindi essere leggero: non deve occupare piu risorse di calcolo, memoria o batteria di quanto sia necessario per il servizio che offre.
Il client, inoltre, spesso salva localmente dati sensibili (credenziali di accesso salvate, cronologia, file scaricati temporaneamente): anche se le misure di sicurezza piu approfondite (crittografia, autenticazione) sono argomento di un modulo successivo del corso, e importante fissare fin da ora che la sicurezza non riguarda solo il server. Un client che conserva password in chiaro sul dispositivo, per esempio, rappresenta un rischio anche se il server a cui si collega e sicurissimo.
Un errore diffuso e pensare che, siccome il server e "quello importante" (custodisce i dati, elabora le richieste), il client non richieda particolare attenzione in fase di progettazione. In realta un client mal progettato puo rendere inutilizzabile un servizio anche quando il server dietro di esso funziona perfettamente: basta un'interfaccia poco chiara o una cattiva gestione degli errori di rete per far percepire il servizio come "rotto", anche se il problema non e mai stato del server.
Un secondo errore e credere che un client debba sempre essere collegato al server per essere utile. Molte applicazioni moderne (documenti che si possono modificare offline e sincronizzare piu tardi, mappe che restano consultabili anche senza rete) sono progettate apposta per funzionare, almeno in parte, anche in assenza di connessione, sincronizzando i dati con il server non appena la rete torna disponibile.
Confrontando questa lezione con la precedente, si nota che molte caratteristiche del client sono l'esatto opposto di quelle richieste al server: dove il server ha bisogno di un indirizzo stabile, il client puo cambiarlo liberamente; dove il server opera in un ambiente omogeneo e controllato, il client deve adattarsi a dispositivi molto diversi tra loro; dove il server deve restare sempre raggiungibile, il client puo funzionare anche a intermittenza, purche gestisca bene le interruzioni. Questa complementarita tra i due ruoli e uno dei motivi per cui, nella prossima lezione di questa unita, vedremo insieme i vantaggi e gli svantaggi complessivi dell'architettura client-server.
Domanda di autoverifica: un'applicazione per prendere appunti che permette di scrivere anche senza connessione e poi sincronizza tutto quando la rete torna disponibile sta sfruttando quale caratteristica del client vista in questa lezione?
Contatti Supportaci Chi siamo Cookies
La possibilità di poter ascoltare l'audio è offerto da ResponsiveVoice-NonCommercial
licensed under
Questo sito è un'idea di Francesco
Statistics