Sei sulla pagina 1di 8

SISTEMI DISTRIBUITI

1. Definizioni
Un sistema distribuito è un insieme di componenti hw e sw interconnessi tra loro in cui le comunicazioni
avvengono esclusivamente tramite message passing. Nel disegno sottostante i diversi sistemi operativi
offrono dei servizi (API) in
modo da fornire alle diverse
macchine ed applicazioni un
ambiente unico
(middleware) con cui
interfacciarsi. In questo
modo il middleware
“nasconde” alle applicazioni
A, B e C i diversi protocolli e
sistemi operativi. Il
middleware è uno strato
software che sta sopra i
sistemi operativi di rete e fornisce servizi alle applicazioni soprastanti. Nei SD è importante il concetto di
trasparenza: NON è necessario conoscere i dettagli con cui vengono realizzate le funzionalità utilizzate. In
un sistema distribuito che si possa definire tale i nodi devono collaborare, poiché indipendenti tra loro:
ognuno conosce il proprio stato, NON c’è un clock globale. Questa caratteristica porta a problemi di
coordinazione e sincronizzazione. L’indipendenza dei nodi permette di avere fallimenti parziali (non
globale! Anche detti partial failures). Il termine failure transparency indica che il sistema è in grado di
portare a termine un compito anche in presenza di fallimenti parziali.

Caratteristiche fondamentali di tutti i sistemi distribuiti

▪ NON c’è memoria condivisa,


▪ Comunicazione e coordinamento via scambio di messaggi (message passing),
▪ Ogni componente è autonomo (concorrenza),
▪ NON c’è un clock globale,
▪ Fallimenti indipendenti dei singoli nodi (NO fallimento globale).

I sistemi distribuiti possono essere organizzati secondo diversi stili architetturali:

1. A strati (layered);
2. A livelli (tier es. applicazioni Client-Server);
3. Basata su oggetti (es. RMI)
4. Centrata sui dati;
5. Basata su eventi (es. AJAX).

4 problemi che deve affrontare ogni sistema distribuito [IMPORTANTE]

1. Identificare la controparte (naming);


2. Accedere alla controparte (access point); //come “raggiungo” un processo remoto /risorsa?
3. Comunicazione 1 (protocol); //come i partecipanti si scambiano messaggi?
4. Comunicazione 2 (syntax & semantics) //come “comprendo” il significato del messaggio?

Per poter capire le richieste e formulare le risposte i due processi devono concordare un protocollo. I
protocolli definiscono il formato, l’ordine di invio e di ricezione dei messaggi tra dispositivi, il tipo dei dati e
le azioni da eseguire quando si riceve un messaggio (es. http). Gli “attori” della comunicazione devono
definire e condividere tale protocollo.

2. Le socket
Le socket sono particolari canali per la comunicazione tra processi che NON condividono memoria. Una
socket è una quadrupla (IP mittente, IP destinatario, porta mittente, porta destinatario) che identifica in
modo univoco un canale virtuale all’interno del quale è possibile comunicare. Le well-known ports sono le
porte TCP e UDP nell’intervallo 0-1023 e sono assegnate a specifici servizi. Analizziamo i 4 problemi dei SD
per il protocollo TCP/IP:

▪ Naming: è necessario conoscere nome dell’host e porta;


▪ Access point: si utilizza l’indirizzo IP (host:port) per accedere ai processi;
▪ Protocol: byte stream (!);
▪ Syntax & semantics: protocolli applicativi con semantica predefinita (http, smtp).

La trasparenza è molto bassa perché le informazioni le deve conoscere l’utente (nome host, porta, etc.) ed
è un protocollo “base”.

Il server crea una socket collegata alla well-known port (che identifica il servizio fornito) dedicata a ricevere
richieste di connessione. Attraverso la accept il server crea una nuova socket dedicato alla comunicazione
con il client (quindi le socket sono 2). Le socket trasportano stream di bytes, quindi non c’è il concetto di
“messaggio” (flusso continuo) e la read/write avviene per un numero arbitrario di byte (es. il sender manda
100 bytes ma io li leggo 10 alla volta). Quindi ci sono dei cicli di lettura che termineranno in base alla
dimensione dei “messaggi” come stabilito dal formato del protocollo applicativo in uso.

In java si utilizzano le classi java.net.Socket e java.net.ServerSocket .

Il server crea una socket con una porta nota per accettare le richieste di connessione ed entra in un ciclo
infinito in cui alterna

o Attesa / accettazione di una richiesta di connessione da un client,


o Ciclo lettura-esecuzione, invio risposta fino al termine della conversazione (spesso stabilita dal
client),
o Chiusura connessione.

I server possono essere:

▪ Iterativi (soddisfano una richiesta alla volta): quando riceve una richiesta di connessione il server
crea una socket temporanea per stabilire una connessione diretta con il client. Le eventuali ulteriori
richieste per il server verranno messe in coda sulla well-known port.
▪ Concorrenti mono-processo (simulano la presenza di un server dedicato);
▪ Concorrenti multi-processo (creano server
dedicati);
▪ Concorrenti multi-thread (creano thread
dedicati).

Come possiamo realizzare un server concorrente?

o In C usando il Selector (A) hai un unico processo che può gestire più client
contemporaneamente;
o In Java assegni un Thread(B) per ogni richiesta;
o In C utilizzando la fork (C) assegni un processo slave per ciascuna richiesta.
La fork crea un processo clone del padre che eredita i canali di comunicazione ed esegue lo stesso codice.

Confronto tra i modelli

▪ Mono-processo (iterativo e concorrente): gli utenti condividono lo stesso spazio di lavoro ed è


adatto ad applicazioni cooperative che prevedono la modifica dello stato (read e write).
▪ Multi-processo: ogni utente ha uno spazio di lavoro autonomo ed è adatto ad applicazioni
cooperative che non modificano lo stato del server (only write), oppure applicazioni autonome che
modificano uno spazio di lavoro proprio (lettura e scrittura).

In conclusione con le socket:

▪ il protocollo è di basso livello,


▪ la trasparenza è bassa,
▪ non c’è un servizio di naming,
▪ indirizzo fisico (host:port) per accedere

3. HTML5 (+DOM) + CSS


Linguaggio di markup: utilizzato per annotare un documento in modo che l’annotazione sia sintatticamente
distinguibile dal testo. HTML ne è un esempio ed è utilizzato per dare struttura ai componenti web.

CSS è un linguaggio utilizzato per dare uno stile ai contenuti web.

DOM è un’interfaccia neutrale rispetto al linguaggio di programmazione e alla piattaforma utilizzata per
consentire ai programmi l’accesso e la modifica dinamica di un contenuto, struttura e stile di un documento
web. DOM è una API per l’accesso e la gestione dinamica di documenti XML e HTML.

Le media query sono dei particolari selettori capaci di valutare la capacità del device di accesso alla pagina.
Una media query in un CSS permette di specificare regole di adattività dei contenuti (tanto in termini di stile
che di struttura del documento HTML) sulla base delle caratteristiche del device usato per visualizzare la
pagina.

JavaScript è un linguaggio di scripting interpretato, dinamico e debolmente tipizzato, inizialmente pensato


per l’esecuzione di semplici script all’interno del browser web. È utilizzato per il tier di presentazione ma può
anche realizzare almeno parte della logica applicativa.

4. Message oriented communication


Una risorsa è un file, cioè una sequenza di dati residente in un computer, ed è identificato da un URL
(indirizzo univoco per la risorsa).

Un web server è un’applicazione che si occupa di gestire le risorse (file) su un computer e di renderle
disponibili ai client.
L’URL identifica un oggetto nella rete e specifica come interpretare i dati ricevuti attraverso il protocollo. Ha
cinque componenti principali:

1. Nome del protocollo,


2. Indirizzo dell’host,
3. Porta del processo, //opzionale
4. Percorso dell’host, se il servizio usa una well-known port.
5. Identificatore della risorsa

I dati testuali sono espressi nei linguaggi standard HTML, XML e JSON. I dati NON testuali vengono trattati
con la codifica MIME. La dinamicità delle pagine è data da JavaScript e simili.

I protocolli definiscono il formato, l’ordine di invio e di ricezione dei messaggi tra i dispositivi, il tipo dei dati
e le azioni da eseguire quando si riceve un messaggio.

http usa TCP aprendo una socket verso il server (porta 80). Il server accetta la connessione TCP e vengono
scambiati messaggi http tra client (browser) e il server (web server). http è stateless, infatti il server non
mantiene informazioni sulle richieste precedenti del client: ogni richiesta deve contenere tutte le
informazioni necessarie per la sua esecuzione.

formato dei messaggi http (request e


response hanno la STESSA struttura).

▪ Request line: metodo, URL e


versione. metodo indica qual è
l'operazione che devo svolgere. sp
è lo spazio e viene usato come
separatore. URL: risorsa a cui sto
puntando. versione: versione di
HTTP che sto utilizzando.
▪ Header lines: numero arbitrario di
coppie nome:valore che servono a
qualificare il messaggio
▪ Riga vuota (cr|lf) per indicare la fine dell’header.
▪ Entity body (payload): dati veri e propri.

Response: codici di stato http:


o 1XX (informazione)
o 2XX (successo)
o 3XX (reindirizzamento)
o 4XX (errore del client)
o 5XX (errore del server)

Comunicazione transiente: se il destinatario non è connesso, i dati vengono scartati.

Comunicazione persistente: il middleware memorizza i dati fino alla consegna del messaggio al destinatario.

Cosa significa metodi idempotenti e safe?

Safe = operazioni che non modificano lo stato dei dati. //solo lettura

Idempotente = la stessa operazione, eseguita più volte, porta allo stesso risultato.

Se sender e receiver usano protocolli diversi si può usare un message broker in grado di gestire diversi
protocolli.

5. Servlet-MVC
Applicazione web = adozione protocollo http.

Una Servlet è un componente gestito in modo automatico da un engine. Ogni Servlet implementa
l’interfaccia javax.servlet.Servlet, con 5 metodi:

JSP è una tecnologia utile per lo sviluppo di applicazioni web. Rispetto ai Servlet, facilita la separazione tra
logica di presentazione e logica applicativa.

Un bean è una classe che segue regole precise:

o Deve avere costruttori senza parametri,


o Dovrebbe avere campi private,
o I metodi di accesso ai campi sono set/get setXXX e getXXX (xxx = campi)
Ds06- RPC-RMI

Il modello RPC maschera il modello Client-Server, con la


differenza che in questo caso è il middleware a inviare
richieste e recuperare le risposte (non direttamente il
client).

Si utilizzano gli stub per realizzare la comunicazione tra


processi remoti e simulare comportamenti locali per
chiamante e chiamato.

client stub simula a P1 di essere la procedura B, mentre


server stub simula a P2 di essere la procedura A (i due stub
comunicano tra di loro).

Marshalling= fare una copia di tutti i dati locali su una


macchina remota.

Un puntatore è una variabile che contiene un indirizzo di memoria. Può essere modificato in ogni momento
e non è tipizzato. Un riferimento è una variabile che contiene informazioni logiche (alias) per accedere ad
un oggetto. È immutabile (può essere inizializzato solo all’atto della creazione di un oggetto) ed è
fortemente tipizzato.
gli oggetti locali sono passati per copia, quelli remoti per reference (viene copiata la reference, non
l’oggetto).

Gli oggetti non


remoti vengono passati per valore, se serializzabili. I tipi base sono serializzabili in modo nativo. È possibile
creare classi serializzabili implementando l’interfaccia Serializable.

RMI per l’identificazione degli oggetti definisce un rmiregistry, che ha le seguenti caratteristiche:

▪ Sta su ogni macchina che ospita oggetti remoti,


▪ Solitamente sulla porta 1099,
▪ RMI attiva un servizio di ascolto per quel servizio.
Bibliografia & risorse utili
https://www.youtube.com/watch?v=LEftMG6Lduw&ab_channel=AndreaCapiluppi (socket)