In questa lezione analizzeremo il funzionamento delle architetture basate sullo scambio di messaggi, un pilastro fondamentale per i moderni sistemi distribuiti e le applicazioni cloud-native.
Approfondiremo i modelli di comunicazione asincrona, il ruolo dei message broker e come queste soluzioni garantiscono scalabilità e affidabilità nelle reti complesse.
Quando uno studente apre il registro elettronico, guarda un video in streaming o manda un messaggio su un'app di chat, sta facendo qualcosa di molto piu complesso di quanto sembri: il suo dispositivo scambia una serie di messaggi con uno o piu altri dispositivi collegati in rete, e da quello scambio nasce il servizio che l'utente percepisce come "guardare un video" o "mandare un messaggio". Nessuna di queste applicazioni funzionerebbe se i computer coinvolti non seguissero delle regole precise su chi invia cosa, a chi, e in che ordine. Questo insieme di regole e di ruoli e cio che chiamiamo architettura di rete.
Capire le architetture di rete significa capire come si organizza la cooperazione tra piu dispositivi (computer, smartphone, server, sensori) per portare a termine un compito che nessuno dei due, da solo, potrebbe svolgere. In questa lezione vediamo la distinzione piu generale e piu importante fra tutte: quella tra architetture in cui i ruoli sono fissi e architetture in cui i ruoli sono paritari. Le due famiglie principali che nascono da questa distinzione, l'architettura client-server e l'architettura peer-to-peer, saranno il tema delle prossime lezioni: qui ci concentriamo sul criterio che permette di riconoscerle e distinguerle.
Un singolo computer isolato non ha bisogno di nessuna architettura di rete: esegue programmi, legge e scrive file sul proprio disco, elabora dati. Il problema nasce quando un compito richiede la collaborazione di piu dispositivi distinti, collegati fisicamente o logicamente tramite una rete (una LAN scolastica, una rete aziendale, Internet). In quel momento serve stabilire alcune cose fondamentali: chi inizia lo scambio, cosa contiene ogni messaggio, chi deve rispondere e con quali dati, e cosa succede se un messaggio va perso o arriva in ritardo.
Un nodo e un qualunque dispositivo collegato alla rete che partecipa allo scambio di messaggi: puo essere un computer desktop, un notebook, uno smartphone, un server o persino un elettrodomestico "intelligente". Un messaggio e un'unita di informazione scambiata tra due nodi, formattata secondo regole condivise che chiamiamo protocollo (i protocolli concreti, come TCP e UDP, e i socket che li implementano, sono l'argomento delle prossime lezioni di questa unita). Il concetto centrale da fissare ora e piu semplice: un'architettura di rete e la struttura organizzativa che stabilisce chi puo scambiare messaggi con chi, e con quale ruolo.
Storicamente sono emersi due modelli principali per organizzare lo scambio di messaggi tra nodi di una rete.
Nel primo modello, alcuni nodi hanno il compito di fornire un servizio (rispondere a richieste, mettere a disposizione dati o funzionalita) mentre altri nodi hanno il compito di richiederlo. Questi due ruoli, una volta assegnati, restano stabili per tutta la durata del servizio: chi fornisce il servizio non lo richiede agli stessi nodi a cui lo fornisce. Questa e la logica dell'architettura client-server, che vedremo nel dettaglio nella prossima lezione.
Nel secondo modello, ogni nodo puo assumere entrambi i ruoli a seconda del momento: nello stesso istante, o in istanti diversi, uno stesso computer puo fornire una risorsa ad altri nodi e, contemporaneamente o poco dopo, richiederne una diversa. Non esiste una gerarchia fissa tra "chi serve" e "chi e servito". Questa e la logica dell'architettura peer-to-peer (dall'inglese, "tra pari"), anch'essa oggetto di una lezione dedicata in questa unita.
Regola fondamentale: per classificare un'architettura di rete basata su scambio di messaggi non conta la tecnologia usata, ma la stabilita dei ruoli. Se il ruolo di un nodo (chi richiede, chi fornisce) resta fisso nel tempo, l'architettura e di tipo client-server. Se il ruolo puo cambiare da un momento all'altro, l'architettura e di tipo peer-to-peer.La distinzione teorica diventa piu chiara con due esempi concreti, uno quotidiano e uno scolastico.
Quando un utente apre un'app di streaming musicale sullo smartphone, l'app (il client) invia una richiesta ai server della piattaforma musicale chiedendo un determinato brano. I server rispondono inviando il flusso audio. In nessun momento lo smartphone dell'utente diventa a sua volta un server che fornisce musica ad altri utenti: il ruolo di "chi richiede" e di "chi fornisce" restano separati e stabili. Questo e un caso tipico di architettura client-server. In un laboratorio scolastico di informatica, alcuni programmi per la condivisione di file tra postazioni (per esempio durante un'esercitazione di gruppo) permettono a ogni nodo [tooltip]In questo contesto, ogni singola postazione (PC) collegata alla rete del laboratorio[/tooltip] di mettere a disposizione una propria cartella per gli altri compagni e, allo stesso tempo, di scaricare file condivisi da loro. Ogni PC del laboratorio puo quindi trovarsi, nello stesso pomeriggio, sia a fornire file (comportandosi da "server" per quel file) sia a riceverne (comportandosi da "client" per un altro file). Questo e un caso tipico di architettura peer-to-peer.Un errore frequente e pensare che "client-server" significhi necessariamente "un solo computer che fa da server per tutti gli altri". In realta un servizio puo essere distribuito su molti server che lavorano insieme (per esempio nei grandi data center), pur restando concettualmente un'architettura client-server: cio che conta, come visto sopra, e che i ruoli di richiedente e fornitore restano distinti e stabili, non il numero di macchine coinvolte da un lato o dall'altro.
Un secondo errore comune e credere che peer-to-peer significhi automaticamente "senza nessuna forma di coordinamento centrale". Molti sistemi peer-to-peer reali usano comunque un piccolo servizio centrale (per esempio per far scoprire ai nodi chi altro e collegato in quel momento), pur mantenendo paritario lo scambio vero e proprio dei dati tra i nodi. La classificazione client-server / peer-to-peer descrive quindi un criterio prevalente di organizzazione, non una regola assoluta e priva di eccezioni: esistono infatti anche architetture ibride, che verranno richiamate quando utile nelle prossime lezioni di questa unita, senza che sia necessario approfondirle gia adesso.
Un limite pratico di questa prima classificazione, infine, e che dice chi fa cosa ma non dice ancora come i messaggi vengono effettivamente scambiati a livello tecnico: quali protocolli si usano, come si apre una connessione, cosa succede in caso di errore. Sono proprio queste le domande a cui rispondono le lezioni successive di questa unita.
Ogni volta che si analizza un sistema informatico distribuito su piu dispositivi, il primo passo utile e chiedersi: i ruoli dei nodi coinvolti sono fissi o possono cambiare nel tempo? Rispondere a questa domanda permette di collocare subito il sistema in una delle due grandi famiglie di architetture basate su scambio di messaggi, prima ancora di conoscerne i dettagli tecnici. Nelle prossime lezioni di questa unita vedremo nel dettaglio le caratteristiche del server e del client nell'architettura client-server, i suoi vantaggi e svantaggi, i protocolli e i socket che la rendono possibile, e infine le caratteristiche specifiche, i vantaggi e gli svantaggi delle architetture peer-to-peer.
Domanda di autoverifica: un sistema di videoconferenza in cui tutti i partecipanti si scambiano direttamente audio e video tra loro, senza passare da un server centrale che redistribuisce i flussi, a quale architettura appartiene? Prova a motivare la risposta usando il criterio visto in questa lezione, prima di leggere la soluzione nella prossima 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