ComunicazioneSD - Università degli Studi di Roma "Tor Vergata"

Transcript

Università degli Studi di Roma “Tor Vergata”
Facoltà di Ingegneria
•  Si basa sempre sullo scambio di messaggi
–  Invio e ricezione di messaggi (a basso livello)
•  Per permettere lo scambio di messaggi, le parti
devono accordarsi su diversi aspetti
–  Quanti volt per segnalare un bit 0 e quanti per un bit 1?
–  Quanti bit per un intero?
–  Come fa il destinatario a sapere quale è l’ultimo bit del
messaggio?
–  Come può capire se un messaggio è stato danneggiato e
cosa fare quando se ne accorge?
–  …
Valeria Cardellini - SD A.A. 2011/12
1
•  Soluzione (già nota): suddividere il problema in livelli
–  Ciascun livello in un sistema comunica con lo stesso livello
nell’altro sistema
–  Modello di riferimento ISO/OSI
•  Adattamento del modello di riferimento tradizionale per
le comunicazioni di rete
– 
– 
– 
– 
Protocolli di livello più basso
Protocolli di trasporto
Protocolli middleware
Protocolli applicativi
2
•  Livello middleware: fornisce servizi comuni e protocolli
general-purpose
–  di alto livello
–  indipendenti dalle specifiche applicazioni
–  che possono essere usati da altre applicazioni
•  Alcuni esempi:
– 
– 
– 
– 
– 
– 
Obiettivo di queste lezioni
Protocolli middleware di comunicazione: per invocare procedure
remote o metodi remoti, accodare messaggi, supportare
streaming e multicasting
Protocolli di naming: per permettere la condivisione di risorse tra
applicazioni
Protocolli di sicurezza: per consentire alle applicazioni di
comunicare in modo sicuro
Protocolli di commit distribuiti: per stabilire che una certa
operazione sia portata a termine da tutte le parti coinvolte o non
abbia alcun effetto
Protocolli di locking distribuiti
Protocolli di consistenza dei dati
3
•  Distinguiamo la comunicazione in base a:
–  Persistenza
•  Comunicazione persistente o transiente
–  Sincronizzazione
•  Comunicazione sincrona o asincrona
–  Dipendenza dal tempo
•  Comunicazione discreta e a stream
4
•  Comunicazione persistente
–  Il messaggio immesso viene memorizzato dal middleware di
comunicazione per tutto il tempo necessario alla consegna
–  Non occorre che il mittente continui l’esecuzione dopo l’invio
del messaggio
–  Non è necessario che il destinatario sia in esecuzione
quando il messaggio è inviato
•  Comunicazione transiente
–  Il messaggio è memorizzato dal middleware solo finché
mittente e destinatario sono in esecuzione
–  Se la consegna non è possibile, il messaggio viene
cancellato
–  E’ il caso tipico della comunicazione di rete a livello di
trasporto: i router memorizzano ed inoltrano; se non è
possibile inoltrare, cancellano
5
•  Comunicazione sincrona
–  Una volta sottomesso il messaggio, il mittente si blocca
finché l’operazione non è completata
–  L’invio e la ricezione sono operazioni bloccanti
–  Fino a quando si blocca il mittente?
•  Finché il middleware non prende il controllo della trasmissione
•  Finché il messaggio non viene consegnato al destinatario
•  Finché il messaggio non viene elaborato dal destinatario
6
•  Comunicazione asincrona
–  Una volta sottomesso il messaggio, il mittente continua
l’elaborazione: il messaggio viene memorizzato
temporaneamente dal middleware fino ad avvenuta
trasmissione
–  L’invio è un’operazione non bloccante
–  La ricezione può essere bloccante o non bloccante
7
•  Comunicazione discreta
–  Ogni messaggio costituisce un’unità di informazione
completa
•  Comunicazione a stream (streaming)
–  Comporta l’invio di molti messaggi, in relazione temporale
tra loro o in base all’ordine di invio, che servono a ricostruire
un’informazione completa
8
•  Quali sono le possibili combinazioni reali tra
persistenza e sincronizzazione?
•  Comunicazione persistente e asincrona
–  Ad es., posta elettronica
•  Comunicazione persistente e sincrona
–  Mittente bloccato fino alla copia (garantita) del messaggio
presso il destinatario
•  Comunicazione transiente e asincrona
–  Mittente non attende ma messaggio perso se destinatario non
raggiungibile (ad es. UDP)
•  Comunicazione transiente e sincrona
a) mittente bloccato fino alla copia del messaggio nel
destinatario
b) mittente bloccato fino alla copia (non garantita) del messaggio
nello spazio del destinatario (ad es. RPC asincrona)
c)  mittente bloccato fino alla ricezione di un messaggio di
risposta dal destinatario (ad es. RPC sincrona e RMI)
9
•  Il messaggio di richiesta e/o risposta può andare
perduto
–  La comunicazione su rete è sempre soggetta a fallimento
•  Il server può subire un crash
–  Prima dell’esecuzione
–  Dopo l’esecuzione
•  Il client può subire un crash
10
•  Quale è la semantica della comunicazione in presenza
di errori?
•  Dipende dalla combinazione di tre meccanismi di base
1.  Lato client: riprova (Request Retry – RR1)
–  Il client continua a provare finché ottiene risposta o è certo del
guasto del server
2.  Lato server: filtra i duplicati (Duplicate Filtering – DF)
–  Il server scarta gli eventuali duplicati di richieste provenienti
dallo stesso client
3.  Lato server: ritrasmetti le risposte (Result Retransmit –
RR2)
–  Il server conserva le risposte per poterle ritrasmettere senza
ricalcolarle
–  Meccanismo necessario se l’operazione non è idempotente
•  Operazione idempotente: molteplici esecuzioni dell’operazione
producono gli stessi effetti di una sola esecuzione dell’operazione
11
•  Semantica may-be (forse)
–  Il messaggio può arrivare o meno
–  Nessun meccanismo (RR1, DF, RR2) in uso
–  Non si fanno azioni per garantire l’affidabilità della
comunicazione
–  Ad es. best-effort in IP o UDP
Client
Invio richiesta
Server
Messaggio richiesta
Messaggio risposta
Processamento
Invio risposta
PERSO
12
•  Semantica at-least-once (almeno una volta)
–  Il messaggio, se arriva, arriva almeno una volta
•  Anche più volte, a causa della duplicazione dovuta alle
ritrasmissioni
–  In caso di insuccesso, nessuna informazione
–  Il client usa RR1, ma il server non usa né DF né RR2
•  Il server non si accorge delle ritrasmissioni
–  Adatta per operazioni idempotenti
–  All’arrivo di una risposta, il client non sa quante volte sia
stata calcolata dal server: non conosce per certo lo stato del
server
13
Client
timeout
Invio richiesta
timeout
Invio richiesta
timeout
Invio richiesta
Messaggio richiesta
Server
PERSO
Ritrasmetti messaggio richiesta
Messaggio risposta
Processamento
Invio risposta
PERSO
Messaggio risposta
Processamento
Invio risposta
14
•  Semantica at-most-once (al più una volta)
–  Il messaggio, se arriva, arriva al più una volta
•  Il client sa che la risposta è stata calcolata una sola volta
•  In caso di insuccesso, nessuna informazione; la risposta
non arriva soltanto in presenza di guasti permanenti del
server
–  Tutti e 3 i meccanismi in uso (RR1, DF, RR2)
•  Il client effettua ritrasmissioni
•  Il server mantiene uno stato per riconoscere i messaggi già
ricevuti e per non eseguire operazioni più di una volta
–  Adatta per qualunque tipo di operazione
•  Anche non idempotente
–  Semantica che non mette vincoli sulle azioni conseguenti
•  No coordinamento tra client e server: in caso di errore, il client
non sa se il server ha eseguito l’operazione, mentre il server
ignora se il client sa che ha eseguito l’operazione
•  Possibile inconsistenza sull’accordo tra client e server
15
Client
timeout
Invio richiesta
timeout
Invio richiesta
timeout
Invio richiesta
Messaggio richiesta
Server
PERSO
Messaggio risposta
PERSO
Messaggio risposta
Registrazione richiesta
Processamento
Invio risposta
Registrazione risposta
Filtraggio duplicato
Invio risposta
16
•  Semantica exactly-once (esattamente una volta)
–  Accordo completo sull’interazione
•  Il messaggio arriva una sola volta oppure o è arrivato o non è
stato considerato da entrambi: semantica tutto o niente
•  Se va tutto bene: il messaggio arriva una sola volta e viene
trattato una sola volta, riconoscendo i duplicati
•  Se qualcosa va male: client o server sanno se il messaggio è
arrivato (e considerato una sola volta - tutto) o se non è
arrivato; se non è arrivato, il tutto può essere riportato indietro
(niente)
–  Semantica con conoscenza concorde dello stato dell’altro e
senza ipotesi di durata massima del protocollo
–  Ha bisogno di ulteriori meccanismi (ad es. replicazione
trasparente, meccanismi di recovery) per tollerare guasti lato
server
17
•  Programmazione di rete esplicita
–  Chiamata diretta all’API socket e scambio esplicito di
messaggi
–  Usata nella maggior parte delle applicazioni di rete note (ad
es. Web browser, Web server)
–  La distribuzione non è trasparente
–  Gran parte del peso dello sviluppo sulle spalle del
programmatore
•  Come innalzare il livello di astrazione della
programmazione distribuita? Fornendo uno strato
intermedio (middleware) fra SO ed applicazioni che:
–  Nasconda la complessità degli strati sottostanti
–  Liberi il programmatore da compiti automatizzabili
–  Migliori la qualità del software mediante il riuso di soluzioni
consolidate, corrette ed efficienti
18
•  Programmazione di rete implicita
–  Chiamata di procedura remota (RPC)
•  L’applicazione distribuita è realizzata usando le chiamate di
procedura, ma il processo chiamante (client) ed il processo
contenente la procedura chiamata (server) possono essere su
macchine diverse
–  Invocazione di metodo remoto (Java RMI)
•  L’applicazione distribuita è realizzata invocando i metodi di un
oggetto di un’applicazione Java in esecuzione su una
macchina remota
•  Trasparenza della distribuzione
Applications, services
RMI and RPC
This
chapter
request-reply protocol
Middleware
layers
marshalling and external data representation
UDP and TCP
19
•  Il middleware scambia messaggi per consentire la
chiamata/invocazione di procedura/metodo; occorre:
–  Identificare i messaggi di chiamata/invocazione ed i
messaggi di risposta
–  Identificare univocamente procedura/metodo remota/o
•  Il middleware gestisce l’eterogeneità dei dati
scambiati
–  Marshaling/unmarshaling dei parametri per gestire diversa
rappresentazione dei dati
–  Serializzazione dei parametri (dati strutturati in flusso di
byte)
•  Il middleware gestisce alcuni errori dovuti alla
distribuzione
–  Implementazione errata
–  Errori dell’utente
• 
20
Quali sono i problemi da risolvere per realizzare la
chiamata di procedura/invocazione di metodo in modo
trasparente e senza sapere dove si trova la procedura
chiamata/il metodo invocato?
1.  Rappresentazione dei dati potenzialmente diversa su
client e server
– 
Inoltre, client e server devono coordinarsi sul protocollo di
trasporto usato per lo scambio di messaggi
2.  In presenza di malfunzionamenti, cosa può il client
considerare certo rispetto all’esecuzione di procedura
chiamata/metodo remoto?
– 
– 
Nel caso locale: semantica exactly-once
Nel caso remoto: semantica at-least-once oppure at-most-once
3.  Come effettuare il binding al server?
21
•  Client e server potrebbero usare una diversa codifica
dei dati, ad es.:
– 
– 
– 
– 
Codifica di caratteri
Rappresentazione di numeri interi e in virgola mobile
Ordinamento dei byte (little endian vs big endian)
Non solo per tipi di dato elementari ma anche strutturati
•  Quali alternative per gestire l’eterogeneità nella
rappresentazione dei dati ed interpretare il
messaggio in modo non ambiguo?
1.  La codifica è specificata nel messaggio stesso
2.  Il mittente del messaggio converte i dati nella
rappresentazione attesa dal destinatario
3.  Ogni dato è convertito in un formato comune concordato
• 
• 
Mittente: da codifica proprietaria a comune
Destinatario: da codifica comune a proprietaria
4.  Esiste un intermediario che effettua le conversioni tra
codifiche diverse
• 
• 
22
Confrontiamo le alternative 2 e 3, nell’ipotesi di N
host che comunicano tra loro
Alternativa 2: dotare ogni host di tutte le funzioni di
conversione possibili per ogni rappresentazione dei
dati
–  Alte prestazioni nella conversione
–  Alto numero di funzioni di conversione, pari a N*(N-1)
• 
Alternativa 3: concordare un formato comune di
rappresentazione dei dati ed ogni host possiede le
funzioni di conversione da/per questo formato
–  Minori prestazioni nella conversione
–  Basso numero di funzioni di conversione, pari a 2*N
23
•  Il binding stabilisce come ottenere l’aggancio corretto
tra il client ed il server che fornisce la procedura/
metodo
•  Due tipologie di binding: statico o dinamico
•  Binding statico
–  L’indirizzo del server è cablato all’interno del client
–  Semplice, costo limitato, ma mancanza di trasparenza e
flessibilità
•  Binding dinamico
–  Ritarda la decisione al momento della necessità
–  Costi maggiori, ma trasparenza e flessibilità
•  Ad es. consente di dirigere le richieste sul server più scarico
–  Il costo deve essere comunque limitato ed accettabile
24
•  Si distinguono due fasi nella relazione client/server
•  Naming: fase statica, prima dell’esecuzione
–  Il client specifica a chi vuole essere connesso, con un nome
unico identificativo del servizio
–  Si associano dei nomi unici di sistema alle operazioni o alle
interfacce astratte e si attua il binding con l’interfaccia specifica
di servizio
•  Addressing: fase dinamica, durante l’esecuzione
–  Il client deve essere realmente collegato al server che fornisce
il servizio al momento dell’invocazione
–  Si cercano gli eventuali server pronti per il servizio
–  Addressing esplicito o implicito
–  Addressing esplicito: multicast o broadcast dal parte del client
attendendo solo la prima risposta
•  Il supporto runtime di ogni macchina risponde se il servizio
richiesto è fornito da un suo server in esecuzione
25
–  Addressing implicito: uso di un name server (o binder o
directory service) che registra tutti i server e agisce su
opportune tabelle di binding, prevedendo funzioni di:
–  ricerca di nomi, registrazione, aggiornamento, eliminazione
client
stub
2, 3
4
name
server
server
stub
1
•  Frequenza del binding dinamico
–  Ogni chiamata richiede un collegamento dinamico
–  Spesso, per questioni di costo, dopo aver ottenuto il primo
binding lo si continua ad usare come se fosse statico
–  Il binding può avvenire meno frequentemente delle chiamate
stesse
•  In genere, si usa lo stesso binding per molte chiamate allo stesso
server
26
•  Remote Procedure Call (RPC)
•  Idea (proposta da Birrel e Nelson, 1984): utilizzare il
modello client server con la stessa semantica di una
chiamata di procedura
–  Un processo sulla macchina A invoca una procedura sulla
macchina B
–  Il processo chiamante su A viene sospeso
–  Viene eseguita la procedura chiamata su B
–  Input ed output sono veicolati da parametri
–  Nessuno scambio di messaggi è visibile al programmatore
27
•  Procedura p locale
•  Procedura p remota
28
•  Esempio di chiamata “locale” (convenzionale):
count = read(fd, buf, nbytes)
•  La procedura chiamante
inserisce sullo stack i
parametri e l’indirizzo di
ritorno
•  La procedura chiamata
(read) mette in un
registro il valore di
ritorno e restituisce il
controllo alla procedura
chiamante
29
•  Modello con stub (adattatore)
•  Il cliente invoca uno stub (client
stub), che si incarica di tutto:
–  Dall’identificazione del server al
trattamento dei parametri, dalla
richiesta al supporto run-time
all’invio della richiesta
•  Il server riceve la richiesta dallo
stub relativo (server stub), che si
incarica del trattamento dei
parametri dopo avere ricevuto la
richiesta pervenuta dal trasporto.
Al completamento del servizio, lo
stub rimanda il risultato al client
•  Lo sviluppo prevede la massima
trasparenza
–  Stub prodotti in modo automatico
–  Lo sviluppatore progetta e si
occupa solo delle reali parti
applicative e logiche
30
1.  La procedura chiamata, lato client, richiama il client stub
usando una normale chiamata di procedura locale
2.  Il client stub costruisce un messaggio e richiama il SO locale
•  Marshaling dei parametri: operazione di impacchettare i
parametri in un messaggio
3.  Il SO del client invia il messaggio al SO remoto
4.  Il SO remoto passa il messaggio al server stub
5.  Il server stub spacchetta il messaggio estraendo i parametri e
invoca il server
•  Unmarshaling dei parametri
6.  Il server esegue il lavoro e restituisce il risultato al server stub
7.  Il server stub lo impacchetta in un messaggio e richiama il suo
SO
8.  Il SO del server invia il messaggio al SO del client
9.  Il SO del client passa il messaggio al client stub
10. Il client stub spacchetta il messaggio e restituisce il risultato al
client
31
•  Esempio con passaggio di parametri per valore
add(i, j)
32
1.  Rappresentazione dei dati
2.  Procedura chiamante e chiamata in esecuzione su
macchine con un diverso spazio di indirizzi: come
realizzare il passaggio dei parametri per riferimento?
3.  In presenza di malfunzionamenti, cosa può la procedura
chiamante considerare certo rispetto all’esecuzione
della procedura chiamata?
4.  Come effettuare il binding alla macchina su cui viene
eseguita la procedura chiamata?
33
•  Il middleware RPC fornisce un supporto
automatizzato
–  Il codice per il marshaling/unmarshaling e la serializzazione
viene generato automaticamente dal middleware e diviene
parte degli stub
–  Tramite
•  Una rappresentazione della signature della procedura
indipendente dal linguaggio e dalla piattaforma, scritta usando
un Interface Definition Language (IDL)
•  Un formato comune di rappresentazione dei dati da usarsi per
la comunicazione
34
•  Linguaggio per la definizione delle interfacce (Interface
Definition Language - IDL)
•  Permette la descrizione di operazioni remote, la
specifica del servizio (detta signature) e la generazione
degli stub
•  Deve consentire
–  Identificazione della procedura
•  Uso di nome astratto del servizio, spesso prevedendo versioni
diverse del servizio
–  Definizione astratta dei dati da trasmettere in input ed output
•  Uso di un linguaggio astratto di definizione dei dati (operazioni e
parametri dell’interfaccia)
•  Supporta lo sviluppo dell’applicazione
–  L’interfaccia specificata dal programmatore in IDL può essere
usata per generare automaticamente gli stub
35
•  Passaggio per valore (call by value)
–  I dati sono copiati nello stack
–  Il chiamato agisce su tali dati e le modifiche non influenzano
il chiamante
•  Passaggio per riferimento (call by reference)
–  L’indirizzo (puntatore) dei dati è copiato nello stack
–  Il chiamato agisce direttamente sui dati del chiamante
•  Passaggio per copia/ripristino (call by copy/restore)
–  I dati sono copiati nello stack dal chiamante e ricopiati dopo
la chiamata, sovrascrivendo il valore originale del chiamante
–  Implementato in pochi linguaggi di programmazione (ad es.
Ada, Fortran)
36
•  Un riferimento è un indirizzo di memoria
–  E’ valido solo nel contesto in cui è usato
•  Soluzione: si simula il passaggio per riferimento
usando il passaggio per copia/ripristino
–  Il client stub copia i dati puntati nel messaggio e lo invia al
server stub
–  Il server stub effettua le operazioni con la copia, usando lo
spazio di indirizzi della macchina ricevente
–  Se occorre effettuare una modifica sulla copia, questa sarà
poi riportata dal client stub sul dato originale
•  Ottimizzazioni:
–  Se il client stub sa che il riferimento è un parametro di input,
non serve che venga ricopiato il suo valore restituito
–  Se si tratta di un parametro di output, non serve effettuare la
copia in partenza
37
•  In modalità sincrona, una
chiamata RPC provoca il
blocco del client
–  Se il server non deve restituire
nessun risultato, il blocco del
client non è necessario
•  Alcuni middleware RPC
supportano RPC asincrone
–  Il client può dedicarsi ad altri
task, una volta effettuata la
chiamata ed aver ricevuto dal
server un acknowledge che la
chiamata di procedura è stata
ricevuta ed avviata
RPC sincrona
RPC asincrona
38
•  Se la RPC produce un
risultato, si può spezzare
l’operazione in due (RPC
sincrona differita):
–  Una prima RPC asincrona
dal client al server per
avviare l’operazione
–  Una seconda RPC
asincrona dal server al
client per restituire il
risultato
RPC sincrona differita
•  Se il client riprende
l’esecuzione senza
aspettare l’acknowledge,
la RPC asincrona è detta
“a senso unico”
39
•  Analizziamo l’implementazione ed il middleware RPC
di Sun Microsystems: Open Network Computing
(ONC), anche noto come SUN RPC
•  ONC è una suite di prodotti che include:
–  eXternal Data Representation (XDR): rappresentazione e
conversione dati
–  Remote Procedure Call GENerator (RPCGEN):
generazione del client e server stub
–  Portmapper: risoluzione indirizzo del server
–  Network File System (NFS): file system distribuito di Sun
•  Molte altre implementazioni, tra cui Distributed
Computing Environment (DCE) RPC
40
•  man rpc
•  man rpcgen
•  Capitolo 16 di W.R. Stevens, “Unix Network
Programming, Volume 2: Interprocess
Communication”, 1999.
•  E. Petron, “Remote Procedure Calls”, Linux Journal,
1997.
41
42
•  Due parti descrittive in linguaggio XDR
1.  Definizioni di programmi RPC: specifiche del
protocollo RPC per le procedure (servizi) offerte,
ovvero l’identificazione delle procedure ed il tipo di
parametri
2.  Definizioni XDR: definizioni dei tipi di dati dei
parametri
–  Presenti solo se il tipo di dato non è già noto in XDR
• 
Raggruppate in un unico file con estensione .x
–  Esempio: square.x
43
struct square_in {
/* input (argument) */
long arg1;
};
struct square_out {
/* output (result) */
long res1;
};
program SQUARE_PROG {
version SQUARE_VERS {
square_out SQUAREPROC(square_in) = 1; /* procedure number = 1 */
} = 1;
/* version number */
} = 0x31230000;
/* program number */
Esempio: square.x
Definizione della procedura remota SQUAREPROC; notare che:
–  Ogni definizione di procedura ha un solo parametro d’ingresso e un solo
parametro d’uscita
– Gli identificatori (nomi) usano lettere maiuscole
– Ogni procedura è associata ad un numero di procedura unico all’interno di
un programma (nell’esempio 1)
44
•  Il programmatore deve sviluppare:
–  il programma client: implementazione del main() e della
logica necessaria per reperimento e binding del servizio/i
remoto/i (esempio: square_client.c)
–  il programma server: implementazione di tutte le procedure
(servizi) (esempio: square_server.c)
•  Attenzione: il programmatore non realizza il main()
lato server...
–  Chi invoca la procedura remota (lato server)?
45
•  Esempio: quadrato di un numero intero
•  Esaminiamo il codice della tradizionale procedura
locale
#include <stdio.h>
#include <stdlib.h>
Esempio: square_local.c
struct square_in { /* input (argument) */
long arg;
};
struct square_out { /* output (result) */
long res;
};
typedef struct square_in square_in;
typedef struct square_out square_out;
square_out *squareproc(square_in *inp) {
static square_out out;
}
out.res = inp->arg * inp->arg;
return(&out);
46
•  Procedura locale: quadrato di un numero intero
(continua)
int main(int argc, char **argv) {
square_in in;
square_out *outp;
if (argc != 2) {
printf("usage: %s <integer-value>\n", argv[0]);
exit(1);
}
in.arg = atol(argv[1]);
outp = squareproc(&in);
printf("result: %ld\n", outp->res);
exit(0);
}
Come si trasforma nel caso di procedura remota?
47
•  Il codice di servizio della procedura remota è quasi
identico alla procedura locale
#include <stdio.h>
#include <rpc/rpc.h>
#include “square.h” /* generated by rpcgen */
square_out *squareproc_1_svc(square_in *inp, struct svc_req *rqstp) {
static square_out out;
out.res1 = inp->arg1 * inp->arg1;
return(&out);
}
Esempio: server.c
•  Osservazioni:
–  I parametri di ingresso e uscita vengono passati per riferimento
–  Il parametro di uscita punta ad una variabile statica (allocazione
globale), per essere presente anche oltre la chiamata della procedura
–  Il nome della procedura cambia leggermente (si aggiunge il carattere
“_” seguito dal numero di versione, tutto in caratteri minuscoli)
48
•  Queste versioni di server.c non sono corrette: perché?
…
square_out *outp;
outp = (square_out *)malloc(sizeof(square_out));
outp->res1 = inp->arg1 * inp->arg1;
return(outp);
}
…
square_out *outp;
free(outp);
return(outp);
}
49
•  Questa versione di server.c è corretta: perché?
…
static square_out *outp;
free(outp);
return(outp);
}
50
•  Il client viene invocato col nome dell’host remoto ed il
valore intero e richiede il servizio di square remoto
#include <stdio.h>
#include "square.h“
/* generated by rpcgen */
int main(int argc, char **argv) {
CLIENT *cl;
char *server;
square_in in;
square_out *outp;
if (argc != 3) {
printf("usage: client <hostname> <integer-value>\n");
exit(1);
}
CLIENT *clnt_create(const char *host, unsigned long program,
unsigned number versnum, const char *protocol)
server = argv[1];
cl = clnt_create(server, SQUARE_PROG, SQUARE_VERS, "tcp");
Esempio: client.c
51
if (cl == NULL) {
clnt_pcreateerror(server);
exit(1);
}
in.arg1 = atol(argv[2]);
if ((outp = squareproc_1(&in, cl)) == NULL) {
printf("%s", clnt_sperror(cl, argv[1]));
exit(1);
}
printf("result: %ld\n", outp->res1);
exit(0);
}
52
•  clnt_create(): crea il gestore di trasporto client che
gestisce la comunicazione col server
–  Nell’esempio: trasporto con connessione (“tcp” tra i
parametri di input)
•  Il client deve conoscere:
–  il nome dell’host remoto su cui è in esecuzione il servizio
–  alcune informazioni per invocare il servizio stesso
(programma, versione e nome della procedura)
•  Per la chiamata della procedura remota:
–  Il nome della procedura cambia: si aggiunge il carattere “_”
seguito dal numero di versione (nome in caratteri minuscoli)
–  Due parametri di ingresso della procedura chiamata:
•  il parametro di ingresso vero e proprio
•  il gestore di trasporto del client
•  Il client gestisce gli errori che si possono presentare
durante la chiamata remota usando le funzioni di
stampa degli errori
–  clnt_pcreateerror() e clnt_perror()
53
1.  Definire servizi e tipi di dato (se necessario) ! square.x
2.  Generare in modo automatico gli stub del client e del
server e (se necessario) le funzioni di conversione XDR
! uso di RPCGEN
•  Genera square_clnt.c, square_svc.c, square_xdr.c, square.h
3.  Realizzare i programmi client e server (client.c e
server.c), compilare tutti i file sorgente (programmi
client e server, stub e file per la conversione dei dati) e
fare il linking dei file oggetto
4.  Pubblicare i servizi (lato server)
1.  Attivare il port mapper
2.  Registrare i servizi presso il port mapper (lanciando il server)
5.  Reperire (lato client) l’endpoint del server tramite il port
mapper e creare il gestore di trasporto per l’interazione
col server
A questo punto l’interazione fra client e server può procedere
54
•  Un programma tipicamente contiene più procedure
remote
–  Possibili versioni multiple di ogni procedura
–  Un unico argomento in ingresso ed in uscita per ogni
invocazione (passaggio per copia-ripristino)
•  Mutua esclusione garantita dal programma (e server):
di default no concorrenza lato server
–  Server sequenziale ed una sola invocazione eseguita per
volta
–  Per server multithreaded (non su Linux): rpcgen con
opzioni –M e –A
•  Fino al ritorno della procedura, il client è in attesa
sincrona bloccante della risposta
•  Semantica at-least-once della comunicazione
–  Ritrasmissione allo scadere di un intervallo di time-out
•  UDP come protocollo di trasporto di default
55
•  Per l’identificazione globale, un messaggio di
richiesta RPC deve contenere
–  numero di programma
–  numero di versione
–  numero di procedura
•  Numeri di programma (32 bit) appartenenti a:
[0x00000000, 0x1fffffff]: predefinito da Sun; per applicazioni
d'interesse comune
[0x20000000, 0x3fffffff]: definibile dall’utente
[0x40000000, 0x5fffffff]: transitorio, riservato alle applicazioni
[0x6fffffff, 0xffffffff]: per estensioni future
56
Applicazione distribuita basata su RPC
Utilizzo di servizi RPC standard
Definizione ed utilizzo di servizi RPC
Gestione avanzata del protocollo RPC
Interfaccia socket
Protocolli di trasporto (UDP e TCP)
Diversi livelli di
astrazione: tradeoff tra
flessibilità nel controllo
e quantità di codice da
sviluppare
57
•  Livello alto: utilizzo di servizi RPC standard
–  Esempi di procedure remote pronte per essere invocate:
rnusers(), rusers(), rstat()
–  Numeri di programmi noti
•  Livello intermedio: definizione ed utilizzo di nuovi
servizi RPC
–  Due primitive: callrpc() e registerrpc()
–  CLIENT - callrpc(): chiamata esplicita al meccanismo
RPC; provoca l’esecuzione della procedura remota
–  SERVER - registerrpc(): registrazione della procedura
remota, associandole l’identificatore
58
•  Livello basso: gestione
avanzata del protocollo
RPC
–  Chiamata remota tramite
funzioni avanzate per
ottenere la massima
capacità espressiva
59
•  Eterogeneità dei dati
gestita tramite l’uso di un
formato comune di
rappresentazione
•  Funzioni XDR di
conversione built-in,
relative a:
–  Tipi atomici predefiniti
•  Ad es. xdr_bool(),
xdr_char(), xdr_int()
–  Tipi strutturati predefiniti
•  Ad es. xdr_string(),
xdr_array()
•  Ciascuna funzione XDR creata da rpcgen può
essere usata sia per serializzare (encode) che per
deserializzare (decode)
60
•  Prima parte del file
–  Definizioni XDR delle costanti
–  Definizioni XDR dei tipi di dato dei parametri di ingresso e
uscita per tutti i tipi di dato per i quali non esiste una
corrispondente funzione XDR built-in
•  Seconda parte del file
–  Definizioni XDR delle procedure
•  Esempio in square.x: SQUAREPROC è la procedura
numero 1 della versione 1 del programma numero
0x31230000
•  Da notare che per le specifiche del protocollo RPC:
–  Il numero di procedura zero (0) è riservato a NULLPROC
–  Ogni definizione di procedura ha un solo parametro d’ingresso
e d’uscita
–  Gli identificatori di programma, versione e procedura usano
tutte lettere maiuscole ed il seguente spazio di nomi:
<NOMEPROGRAMMA>PROG per il nome del programma
<NOMEPROGRAMMA>VERS per la versione del programma
<NOMEPROCEDURA> per i nomi delle procedure
61
•  Per poter essere invocata, la procedura deve essere
registrata
–  Identificatore in base al protocollo RPC: numero di programma
(prognum), numero di versione (versnum), numero di procedura
–  Occorre definire anche il protocollo di trasporto (protocol)
–  Il client deve conoscere il numero di porta (port) su cui il server
risponde
•  Il server deve registrare il programma RPC nella tabella
dinamica dei servizi dell’host su cui è in esecuzione
•  Una riga di questa tabella (detta port map) contiene la
tripla {prognum, versnum, protocol} e port
–  Manca il numero di procedura: tutte le procedure RPC
all’interno di un programma condividono lo stesso gestore di
trasporto
•  La tabella di port map è gestita da un solo processo
(detto port mapper) per ogni host su cui sono eseguiti
server RPC
62
•  Server port mapper (portmap) in ascolto sulla porta
111 (sia UDP che TCP)
•  Quando un server RPC viene lanciato, notifica al port
mapper in esecuzione sull’host le informazioni sul
servizio offerto
–  prognum, versnum, protocol e port
•  Prima di invocare il servizio, un client contatta il port
mapper sull’host remoto per conoscere la porta
corrispondente al servizio
•  Il port mapper registra i servizi sull’host e offre le
funzionalità di:
–  Inserimento di un servizio
–  Eliminazione di un servizio
–  Corrispondenza tra servizio e porta
–  Lista dei servizi registrati
63
•  Per avere la lista di tutti i programmi RPC invocabili
su di un host usare rpcinfo -p nomehost
xxx:~/RPC/square$ rpcinfo -p
program
vers
proto
100000
2
tcp
100000
2
udp
824377344
1
udp
824377344
1
tcp
port
111
111
59528
49311
portmapper
portmapper
•  Nell’output: 824377344 (= 0x31230000) è il numero
di programma in square.x
•  /etc/rpc contiene l’elenco dei programmi RPC
disponibili
64
Data una specifica di partenza
•  file di linguaggio XDR
–  square.x
RPCGEN produce in automatico
•  header file
–  square.h
•  file stub del client
–  square_clnt.c
•  file stub del server
Analizziamoli
–  square_svc.c
•  file di routine XDR
–  square_xdr.c
Lo sviluppatore deve realizzare
•  programma client
–  client.c
•  programma server
–  server.c
65
square.x
rpcgen
#include
client.c
square.h
square_clnt.c
square_xdr.c
square_svc.c
gcc
gcc
client
server
server.c
66
67
/*
* Please do not edit this file.
* It was generated using rpcgen.
*/
#ifndef _SQUARE_H_RPCGEN
Incluso
#define _SQUARE_H_RPCGEN
#ifdef __cplusplus
extern "C" {
#endif
dai due stub
In caso di nuovi tipi di dato si devono
definire le nuove strutture dati per le
quali saranno generate in automatico
le nuove funzioni di trasformazione
struct square_in {
long arg1;
};
typedef struct square_in square_in;
struct square_out {
long res1;
};
typedef struct square_out square_out;
#define SQUARE_PROG 0x31230000
#define SQUARE_VERS 1
Esempio: square.h
68
#if defined(__STDC__) || defined(__cplusplus)
#define SQUAREPROC 1
extern square_out * squareproc_1(square_in *, CLIENT *);
extern square_out * squareproc_1_svc(square_in *, struct svc_req *);
extern int square_prog_1_freeresult (SVCXPRT *, xdrproc_t, caddr_t);
#else /* K&R C */
#define SQUAREPROC 1
extern square_out * squareproc_1();
extern square_out * squareproc_1_svc();
extern int square_prog_1_freeresult ();
#endif /* K&R C */
/* the xdr functions */
#if defined(__STDC__) || defined(__cplusplus)
extern bool_t xdr_square_in (XDR *, square_in*);
extern bool_t xdr_square_out (XDR *, square_out*);
#else /* K&R C */
extern bool_t xdr_square_in ();
extern bool_t xdr_square_out ();
#endif /* K&R C */
#ifdef __cplusplus
}
#endif
#endif /* !_SQUARE_H_RPCGEN */
Esempio: square.h
69
/*
*/
#include "square.h“
bool_t xdr_square_in (XDR *xdrs, square_in *objp)
{
register int32_t *buf;
if (!xdr_long (xdrs, &objp->arg1))
return FALSE;
return TRUE;
}
bool_t xdr_square_out (XDR *xdrs, square_out *objp)
{
register int32_t *buf;
if (!xdr_long (xdrs, &objp->res1))
return FALSE;
return TRUE;
Esempio: square_xdr.c
}
70
/*
*/
#include <memory.h> /* for memset */
#include "square.h"
/* Default timeout can be changed using clnt_control() */
static struct timeval TIMEOUT = { 25, 0 };
square_out *
squareproc_1(square_in *argp, CLIENT *clnt)
{
static square_out clnt_res;
}
Assegna timeout per la
chiamata
Reale chiamata remota
memset((char *)&clnt_res, 0, sizeof(clnt_res)); nel client stub
if (clnt_call (clnt, SQUAREPROC,
(xdrproc_t) xdr_square_in, (caddr_t) argp,
(xdrproc_t) xdr_square_out, (caddr_t) &clnt_res,
TIMEOUT) != RPC_SUCCESS) {
return (NULL);
}
Esempio: square_clnt.c
return (&clnt_res);
71
/*
*/
#include "square.h"
#include <stdio.h>
#include <stdlib.h>
#include <rpc/pmap_clnt.h>
#include <string.h>
#include <memory.h>
#include <sys/socket.h>
#include <netinet/in.h>
#ifndef SIG_PF
#define SIG_PF void(*)(int)
#endif
Funzione di dispatching
static void
square_prog_1(struct svc_req *rqstp, register SVCXPRT *transp)
{
union {
square_in squareproc_1_arg;
} argument;
char *result;
Esempio: square_svc.c
xdrproc_t _xdr_argument, _xdr_result;
char *(*local)(char *, struct svc_req *);
72
switch (rqstp->rq_proc) {
case NULLPROC:
(void) svc_sendreply (transp, (xdrproc_t) xdr_void,
(char *)NULL);
return;
case SQUAREPROC:
_xdr_argument = (xdrproc_t) xdr_square_in;
_xdr_result = (xdrproc_t) xdr_square_out;
local = (char *(*)(char *, struct svc_req *))
squareproc_1_svc;
break;
default:
svcerr_noproc (transp);
return;
}
memset ((char *)&argument, 0, sizeof (argument));
if (!svc_getargs (transp, (xdrproc_t) _xdr_argument,
(caddr_t) &argument)) {
svcerr_decode (transp);
return;
}
result = (*local)((char *)&argument, rqstp);
if (result != NULL && !svc_sendreply(transp, (xdrproc_t)
_xdr_result, result)) {
svcerr_systemerr (transp);
}
73
}
if (!svc_freeargs (transp, (xdrproc_t) _xdr_argument,
(caddr_t) &argument)) {
fprintf (stderr, "%s", "unable to free arguments");
exit (1);
}
return;
int
main (int argc, char **argv)
{
register SVCXPRT *transp;
Distrugge eventuali
registrazioni precedenti con lo
stesso numero di programma e
versione
Crea il gestore di protocollo che
pmap_unset(SQUARE_PROG, SQUARE_VERS); utilizza socket UDP
transp = svcudp_create(RPC_ANYSOCK);
if (transp == NULL) {
fprintf (stderr, "%s", "cannot create udp service.");
exit(1);
}
if (!svc_register(transp, SQUARE_PROG, SQUARE_VERS,
square_prog_1, IPPROTO_UDP)) {
fprintf (stderr, "%s", "unable to register
(SQUARE_PROG, SQUARE_VERS, udp)."); Associa la tripla {n_prog,
exit(1);
n_vers, protocollo} ad una
}
procedura di dispatching che
implementa i vari servizi
74
transp = svctcp_create(RPC_ANYSOCK, 0, 0);
if (transp == NULL) {
fprintf (stderr, "%s", "cannot create tcp service.");
exit(1);
Crea il gestore di protocollo che
}
utilizza socket TCP
if (!svc_register(transp, SQUARE_PROG, SQUARE_VERS,
square_prog_1, IPPROTO_TCP)) {
fprintf (stderr, "%s", "unable to register
(SQUARE_PROG, SQUARE_VERS, tcp).");
exit(1);
}
Entra nel ciclo infinito di attesa
e servizio della chiamata
svc_run();
fprintf (stderr, "%s", "svc_run returned");
exit (1);
/* NOTREACHED */
}
75
•  Esempi di programmi RPC disponibili sul sito
del corso
–  square: quadrato di un numero intero
•  Già esaminato
–  echo: ripetizione di una sequenza di caratteri
–  avg: valore medio di una sequenza di numeri reali
–  rls: listato di una directory remota
•  Le routine XDR in dir_xdr.c sono generate automaticamente a
partire dai tipi di dato definiti in dir.x e permettono la
conversione da formato locale a XDR e viceversa
76
•  “Trail: RMI”, http://download.oracle.com/javase/
tutorial/rmi/
77
•  Il paradigma RPC può essere facilmente esteso al
modello a oggetti distribuiti
–  Java RMI (Remote Method Invocation): RPC in Java
–  RMI fornisce la possibilità di richiedere l’esecuzione di
metodi remoti in Java, integrando il tutto con il paradigma OO
•  Java RMI è un insieme di strumenti, politiche e
meccanismi che permettono ad un’applicazione Java
in esecuzione su un host di invocare i metodi di un
oggetto di un’applicazione Java in esecuzione su un
host differente
–  Obiettivo: rendere il più possibile simili l’involcazione locale e
quella remota
78
•  Localmente viene creato solo il riferimento ad un
oggetto remoto, che è effettivamente attivo su un host
remoto
•  Il programma lato client invoca i metodi remoti
attraverso questo riferimento locale
•  Quali sono le differenza rispetto all’invocazione di un
oggetto locale?
–  Affidabilità, semantica della comunicazione, durata, …
local!
remote!
invocation!
A!
B!
C!
E!
invocation! local!
invocation!
local!
invocation!
D!
remote!
invocation!
F!
79
•  Principio base: la definizione del comportamento
(interfaccia) e l’implementazione del comportamento
(classe) sono concetti separati
•  La separazione logica tra interfaccia ed oggetto consente
anche la loro separazione fisica
–  Interfaccia remota: specifica quali metodi dell’oggetto possono
essere invocati da remoto
–  Lo stato interno di un oggetto non viene distribuito!
remote!object!
remote!
interface!
{!
Data!
m1!
m2!
m3!
implementation!
of methods!
m4!
m5!
m6!
80
•  Al binding di un client con un oggetto server
distribuito, una copia dell’interfaccia del server (stub)
viene caricata nello spazio del client
–  Ruolo del tutto analogo a quello del client stub in ambiente
RPC
•  La richiesta in arrivo all’oggetto remoto viene trattata
da un “agente” del client, locale al server (skeleton)
–  Ruolo del tutto analogo a quello del server stub in ambiente
RPC
•  Unico ambiente di lavoro come conseguenza del
linguaggio Java, ma eterogeneità dei sistemi
–  Grazie alla portabilità del codice Java
81
•  Come in RPC, anche in
RMI si usa il proxy pattern:
i due proxy (stub dal lato
client e skeleton dal lato
server) nascondono al
livello applicativo la natura
distribuita dell’applicazione
–  Stub: proxy locale sul nodo
client su cui vengono fatte le
invocazioni destinate
all’oggetto remoto
–  Skeleton: proxy remoto sul
nodo server che riceve le
invocazioni fatte sullo stub e
le realizza effettuando le
corrispondenti chiamate sul
server
82
•  Stub e skeleton rendono possibile la chiamata di un
servizio remoto come se fosse locale, agendo da
proxy
–  Sono generati automaticamente
•  (De)serializzazione supportata direttamente da Java
–  Grazie all’uso del bytecode, non c’è bisogno di
(un)marshaling come in RPC, ma i dati vengono
semplicemente (de)serializzati utilizzando le funzionalità
offerte direttamente a livello di linguaggio
–  Serializzazione: trasformazione di oggetti complessi in
sequenze di byte
•  metodo writeObject() su uno stream di output
–  Deserializzazione: decodifica di una sequenza di byte e
costruzione di una copia dell’oggetto originale
•  metodo readObject() da uno stream di input
83
•  Passi per la comunicazione
1. Il client ottiene un’istanza dello stub (come?)
2. Il client invoca i metodi sullo stub
3. Lo stub effettua la serializzazione delle informazioni
per l’invocazione (ID del metodo e argomenti) e le
invia allo skeleton in un messaggio
4. Lo skeleton riceve il messaggio ed effettua la
deserializzazione dei dati ricevuti, invoca la
chiamata sull’oggetto che implementa il server
(dispatching), effettua la serializzazione del valore di
ritorno e lo invia allo stub in un messaggio
5. Lo stub effettua la deserializzazione del valore di
ritorno e restituisce il risultato al client
84
•  RMI Registry: è il
binder per Java RMI
(per default porta
1099)
•  Servizio di naming
che consente al
server di registrare i
suoi oggetti remoti e
al client di
recuperarne i
riferimenti associati
•  Funziona come
punto di indirezione
•  Alcune limitazioni:
non è trasparente alla
locazione, non
gestisce la sicurezza
85
•  Architettura a strati
•  Solo chiamate sincrone e bloccanti
RMI
Registry
Client
Server
Stub
Skeleton
Remote Ref. Layer
Remote Ref. Layer
Transport Layer
Transport Layer
Java Virtual Machine
Java Virtual Machine
Rete
Protocollo orientato alla
connessione (TCP)
86
•  Remote Reference Layer
–  Fornisce il supporto alle chiamate inoltrate dallo stub
–  Definisce e supporta la semantica dell’invocazione e della
comunicazione
–  Scambia dati con il Transport Layer
•  Transport Layer
–  Localizza il server RMI relativo all’oggetto remoto richiesto,
gestisce le connessioni e le trasmissioni (sequenziali,
serializzate) fra i diversi spazi di indirizzi (JVM diverse)
–  Usa un protocollo proprietario: Java Remote Method
Protocol
–  Possibilità di utilizzare protocolli applicativi diversi, purché
siano orientati alla connessione
•  Ad es. HTTP per poter invocare oggetti remoti che sono in
esecuzione su macchine protette da firewall
87
• 
Realizzare i componenti remoti lato server
– 
Definizione del comportamento: interfaccia che
• 
• 
• 
– 
Implementazione del comportamento: classe che
• 
• 
• 
• 
Deve essere dichiarata public
Deve estendere java.rmi.Remote
Ogni metodo solleva l’eccezione java.rmi.RemoteException
per proteggere l’applicazione da anomalie derivanti dall’utilizzo di
risorse remote
Implementa l’interfaccia definita
Estende java.rmi.UnicastRemoteObject
Occorre anche registrare il servizio, invocando il metodo bind/
rebind sul registry (nella classe java.rmi.Naming)
Realizzare i componenti locali lato client
!
Bisogna ottenere il riferimento all’oggetto remoto, invocando il
metodo lookup sul registry
• 
88
Dopo aver sviluppato il codice, è necessario:
1.  Compilare le classi sviluppate
2.  A partire da Java SE 5, le classi per stub e skeleton sono
generate dinamicamente
• 
Per versioni precedenti, occorre usare il compilatore RMI rmic
per pre-generare le classi stub e skeleton; inoltre, la classe stub
deve essere localmente disponibile sul lato client
3.  Attivare l’RMI registry manualmente (comando rmiregistry),
che viene lanciato in un processo separato (rispetto a quello in
cui è eseguito il server RMI) ed ha struttura e comportamento
standard
• 
In alternativa, si può creare all’interno del codice server un proprio
registry locale tramite il metodo createRegistry (in
java.rmi.registry)
4.  Avviare il server
5.  Avviare il client
A questo punto l’interazione tra client e server può procedere
89
•  L’interfaccia estende
l’interfaccia Remote
•  Ciascun metodo remoto
–  Deve lanciare una
RemoteException
public interface EchoInterface
extends java.rmi.Remote{
String getEcho(String echo)
throws java.rmi.RemoteException;
}
•  L’invocazione dei metodi
remoti non è
completamente trasparente
–  Ha un solo parametro di uscita; nessuno, uno o più parametri di
ingresso
–  I parametri di ingresso del metodo remoto possono essere
•  passati per valore, se sono tipi primitivi o oggetti che
implementano l’interfaccia Serializable: serializzazione/
deserializzazione ad opera di stub/skeleton
•  oppure per riferimento, se sono oggetti Remote
• 
90
public class EchoRMIServer
extends UnicastRemoteObject
La classe che implementa il
implements EchoInterface{
server
//Costruttore
–  Estende la classe
public EchoRMIServer()
UnicastRemoteObject
throws RemoteException
–  Implementa tutti i metodi definiti { super(); }
nell’interfaccia
//Implementazione del metodo remoto
–  Il metodo super()chiama il
dichiarato nell’interfaccia
costruttore della classe
public String getEcho(String echo)
UnicastRemoteObject che
esegue le inizializzazioni
{ return echo; }
necessarie per consentire di
public static void main(String[] args) {
rimanere in attesa di richieste
// Registrazione del servizio
remote su una porta e poterle
try
gestire
{ EchoRMIServer serverRMI =
new EchoRMIServer();
Naming.rebind(“EchoService”, serverRMI); }
catch (Exception e)
{e.printStackTrace(); System.exit(1); }
}
}
91
• 
• 
• 
public class EchoRMIServer
extends UnicastRemoteObject
Nel metodo main si crea
l’istanza dell’oggetto server; una implements EchoInterface{
volta creato, l’oggetto è pronto //Costruttore
public EchoRMIServer()
per accettare richieste remote
L’RMI registry locale al server
{ super(); }
registra tutti i servizi
//Implementazione del metodo remoto
dichiarato nell’interfaccia
–  Metodi bind/rebind della
public String getEcho(String echo)
classe Naming (rebind
rimpiazza un binding già
esistente)
{ return echo; }
public static void main(String[] args) {
–  Tante bind/rebind quanti
// Registrazione del servizio
sono gli oggetti server da
try
registrare, ognuno con un
{ EchoRMIServer serverRMI =
proprio nome logico
new EchoRMIServer();
Registrazione nel servizio di
Naming.rebind(“EchoService”, serverRMI); }
naming offerto dall’RMI registry
catch (Exception e)
–  bind/rebind solo su RMI
registry locale
}
}
92
•  Servizi acceduti tramite
l’interfaccia, ottenuta con una
lookup all’RMI registry
• 
• 
public class EchoRMIClient
{
//Avvio del client RMI
public static void main(String[] args)
{
Reperimento di un riferimento
bufferedReader stdIn =
remoto
new BufferedReader(
new InputStreamReader(System.in));
–  Ossia un’istanza di stub
try
dell’oggetto remoto (non della {
classe dello stub, che di solito si //Connessione al servizio RMI remoto
assume già presente sul client)
EchoInterface serverRMI = (EchoInterface)
Naming.lookup(“EchoService”);
Invocazione del metodo remoto
//Interazione con l’utente
String message, echo;
–  Chiamata sincrona bloccante
System.out.print(“Messaggio? “);
con i parametri specificati
message = stdIn.readLine();
nell’interfaccia
//Richiesta del servizio remoto
echo = serverRMI.getEcho(message);
System.out.println(“Echo: “+echo+”\n”);
}
catch (Exception e)
Vedi esempio completo
sul sito del corso
}
}
93
• 
Lato server
1.  Compilazione
javac EchoInterface.java
javac EchoRMIServer.java
2.  Generazione stub e skeleton (necessaria solo prima di Java SE 5)
rmic EchoRMIServer
EchoRMIServer_Stub.class
3.  Esecuzione lato server
Avvio in background del registry:
rmiregistry &
Avvio del server: java EchoRMIServer
• 
Lato client
1.  Compilazione
javac EchoRMIClient.java
2.  Esecuzione lato client
java EchoRMIClient
94
•  I metodi di un oggetto remoto possono essere
invocati in modo concorrente da molteplici client
–  Dalla specifica: “Since remote method invocation on the
same remote object may execute concurrently, a remote
object implementation needs to make sure its
implementation is thread-safe”
•  Per proteggere metodi remoti da accessi concorrenti
“pericolosi” garantendo la thread safety occorre
definire il metodo come synchronized
•  Esempio: metodo remoto che incrementa un valore
95
•  Usando Java RMI sviluppare il codice per l’interfaccia
MathServices con i seguenti metodi remoti:
public double sqroot (double value);
public double square(double value);
e sviluppare il client che invoca tali metodi remoti
96
•  SUN RPC: visione a processi; trasparenza all’accesso
incompleta e no trasparenza all’ubicazione
•  Entità che si possono richiedere: solo operazioni o
funzioni
•  Semantica di comunicazione (default): at-least-once
•  Modi di comunicazione: sincroni e asincroni
•  Durata massima ed eccezioni: timeout per
ritrasmissione e casi di errore
•  Ricerca del server: port mapper sul server
•  Presentazione dei dati: IDL specifico (XDR) e
generazione stub
•  Passaggio dei parametri: per copia-ripristino
•  Varie estensioni, tra cui broadcast (più risposte da
molteplici server anziché una sola) e sicurezza
97
•  Java RMI: visione per sistemi ad oggetti; trasparenza
all’accesso, no trasparenza all’ubicazione e non
maschera totalmente la distribuzione (semantica
passaggio parametri, interfacce ed eccezioni remote)
•  Entità che si possono richiedere: metodi di oggetti via
interfacce
•  Semantica di comunicazione: at-most-once
•  Modi di comunicazione: solo sincroni
•  Durata massima ed eccezioni: trattamento di casi di
errore
•  Ricerca del server: uso di registry
•  Presentazione dei dati: generazione stub e skeleton
•  Passaggio dei parametri: di default per valore (tipi di
dato primitivi e oggetti serializable), nel caso di
oggetti con interfacce remotizzabili per riferimento
(oggetti remote)
98
•  RPC e RMI migliorano la trasparenza all’accesso
•  Ma non sono sempre meccanismi adatti a supportare
la comunicazione in un SD
–  Ad es. quando non si può essere certi che il destinatario sia
in esecuzione
–  La natura essenzialmente sincrona delle RPC comporta una
perdita di efficacia nella comunicazione
•  Alternativa: comunicazione orientata ai messaggi
–  Di tipo transiente
•  Berkeley socket: già esaminata in altri corsi
•  Message Passing Interface (MPI)
–  Di tipo persistente
•  Sistemi a code di messaggi o Message Oriented
Middleware (MOM)
99
•  Libreria per lo scambio di messaggi tra processi in
esecuzione su nodi diversi
–  Specifica della sola interfaccia (http://www.mpi-forum.org/)
–  Diverse implementazioni, tra cui Open MPI (http://
www.open-mpi.org/) e MPICH (http://www.mcs.anl.gov/
research/projects/mpich2/)
–  Standard de facto per la comunicazione tra i nodi di un
sistema che esegue un programma parallelo sviluppato per
un’architettura a memoria distribuita
•  MPI definisce una serie di primitive per la
comunicazione tra processi; in particolare:
–  Primitive per la comunicazione punto-punto: per l’invio e la
ricezione di un messaggio tra due processi diversi
–  Primitive per la comunicazione collettiva
100
•  Principali primitive per la comunicazione punto-punto:
–  MPI_Send e MPI_Recv: comunicazione bloccante
•  MPI_Send con modalità sincrona o bufferizzata a seconda
dell’implementazione
–  MPI_Bsend: invio bloccante bufferizzato
–  MPI_Ssend: invio sincrono bloccante
–  MPI_Isend e MPI_Irecv: comunicazione non bloccante
Primitive MPI
Significato
MPI_Bsend
Aggiunge un messaggio in uscita ad un buffer per l’invio
MPI_Send
Invia un messaggio e aspetta finché non viene copiato in un
buffer locale o remoto
MPI_Ssend
Invia un messaggio e aspetta finché non inizia la ricezione
MPI_Isend
Invia il riferimento ad un messaggio in uscita e continua
MPI_Recv
Riceve un messaggio; si blocca se non ce ne sono
101
#include <stdio.h>
#include <string.h>
#include <mpi.h>
int main (int argc, char **argv) {
int myrank;
char message[20];
MPI_Status status;
MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &myrank);
printf("Il mio rank e' : %d\n", myrank);
if (myrank == 0) {
MPI_Send(buf, count, datatype,
//Invia un messaggio al processo 1
dest, tag, comm)
strcpy(message, "PROVA");
MPI_Send(message, strlen(message)+1, MPI_CHAR, 1, 99, MPI_COMM_WORLD);
printf("%d) Ho inviato: '%s'\n", myrank, message);
} else if (myrank==1) {
//Riceve il messaggio dal processo 0
MPI_Recv(message, 20, MPI_CHAR, 0, 99, MPI_COMM_WORLD, &status);
printf("%d) Ho ricevuto: '%s'\n", myrank, message);
}
MPI_Finalize();
MPI_Recv(buf, count, datatype,
return 0;
source, tag, comm, status)
}
102
•  Idea base di un MOM (o sistema a code di
messaggi): le applicazioni distribuite comunicano
inserendo messaggi in apposite code
–  Di solito ogni applicazione ha la sua coda privata (esistono
anche code condivise da più applicazioni)
–  Eccellente supporto per comunicazioni persistenti e
asincrone
•  Il mittente ha soltanto la garanzia che il suo
messaggio venga inserito nella coda del destinatario
–  Nessuna garanzia che il destinatario prelevi il messaggio
dalla sua coda
–  Disaccoppiamento temporale tra mittente e destinatario (già
esaminato per publish/subscribe)
•  Un messaggio può contenere
qualunque dato e deve
essere indirizzato
opportunamente
–  Nome univoco a livello del
sistema
103
•  Principali primitive offerte dall’API di un MOM:
–  put: invio non bloccante di un messaggio
•  Il messaggio viene aggiunto ad una coda
•  Operazione asincrona ! come trattare il caso di coda piena?
–  get: ricezione bloccante di un messaggio
•  Si blocca finché la coda non è più vuota e preleva il primo
messaggio (oppure si blocca in attesa di un messaggio specifico)
•  Operazione sincrona rispetto alla presenza di messaggi in coda
–  poll: ricezione non bloccante di un messaggio
•  Controlla se ci sono messaggi in una coda e rimuove il primo
(oppure un messaggio specifico), senza bloccarsi
–  notify: ricezione non bloccante di un messaggio
•  Installa un handler (funzione di callback) che avvisa il
destinatario quando viene inserito un messaggio in una coda
•  Il meccanismo di callback separa la coda dall’attivazione del
destinatario
104
•  I messaggi possono essere inseriti/letti solo in/da
code locali al mittente/destinatario
–  Inserimento in coda sorgente (o di invio)
–  Lettura da coda di destinazione (o di ricezione)
–  La coda appare locale sia al mittente che al destinatario
(trasparenza della distribuzione)
–  E’ il sistema ad occuparsi del trasferimento dei messaggi
•  Il MOM deve mantenere la corrispondenza tra ogni
coda e la sua posizione sulla rete (servizio di naming)
105
•  L’architettura generale di un
•  Il MOM realizza un overlay
MOM scalabile richiede un
network con topologia
insieme di gestori (router o relay)
propria e distinta
specializzati nel servizio di
routing dei messaggi da un
–  Occorre un servizio di routing
gestore all’altro
•  Una sottorete connessa di
router conosce la topologia
della rete logica (statica) e si
occupa di far pervenire il
messaggio dalla coda del
mittente a quella del
destinatario
•  Topologie di rete complesse
e variabili (scalabili)
richiedono la gestione
dinamica delle
corrispondenze codaposizione di rete (analogia
con routing in reti IP)
106
•  L’area di applicazione più importante dei MOM è
l’integrazione di applicazioni in ambito aziendale
(Enterprise Application Integration, EAI)
–  Le applicazioni devono essere in grado di interpretare il
formato dei messaggi (struttura e rappresentazione dei dati)
•  Soluzioni possibili per gestire l’eterogeneità dei
messaggi (3 su 4 già esaminate):
– 
– 
– 
– 
Codifica del formato contenuta nel messaggio
Ogni destinatario è in grado di comprendere ogni formato
Formato comune dei messaggi
Gateway di livello applicativo (broker) in grado di effettuare le
conversioni tra formati diversi
•  La soluzione generalmente adottata nei MOM si basa
sulla presenza di message broker
107
•  Gestisce l’eterogeneità delle applicazioni
–  Trasforma i messaggi in ingresso nel formato adatto
all’applicazione destinataria, fornendo trasparenza di
accesso ai messaggi
–  Gestisce un repository delle regole e dei programmi che
consentono la conversione dei messaggi
–  Per ragioni di scalabilità la sua implementazione può essere
distribuita
broker
Anche detta architettura Hub-and-Spoke
•  Esempi di MOM con broker
–  IBM WebSphere MQ
–  Microsoft Message Queueing (MSMQ)
–  Java Message Service (JMS): un’API MOM per Java
108
•  MOM molto diffuso (~40% del mercato) e supportato
•  I messaggi sono gestiti dai queue manager (QM)
–  Le applicazioni possono inserire/estrarre messaggi solo
nelle/dalle code locali o attraverso un meccanismo RPC
•  Il trasferimento dei messaggi da una coda all’altra di
QM diversi avviene tramite canali di comunicazione
unidirezionali ed affidabili gestiti da message channel
agent (MCA) che si occupano di tutti i i dettagli
–  Stabilire canali usando gli strumenti messi a disposizione dai
protocolli di rete
–  Tipo di messaggi
–  Invio/ricezione dei pacchetti
•  Ogni canale ha una coda di
invio
109
•  Il trasferimento sul canale può avvenire solo se
entrambi gli MCA sono attivi
–  Il sistema MQ fornisce meccanismi per avviare
automaticamente un MCA
•  Il routing è sotto il controllo di una gestione di sistema
statica e non flessibile
–  L’amministratore stabilisce in fase di configurazione le
opportune interconnessioni tra QM in tabelle di routing
110
•  Indirizzo di destinazione: nome del gestore di
destinazione + nome della coda di destinazione
•  Elemento della tabella di routing: <destQM, sendQ>
–  destQM: nome del gestore di destinazione
–  sendQ: nome della coda d’invio locale
•  Quali sono i problemi del routing nel sistema MQ?
111
•  Per favorire l’integrazione di applicazioni, MQ Broker
può intervenire sui messaggi
–  Trasformando formati
–  Attuando il content-based routing dei messaggi
–  Lavorando su informazioni di applicazione, per specificare
sequenze di azioni
112
•  I tipi di comunicazione analizzati finora sono basati su
uno scambio di unità di informazioni discreto, ovvero
indipendente dal tempo
–  Le relazioni temporali tra i dati non sono fondamentali per
l’interpretazione dei dati
•  Nei media continui i valori sono dipendenti dal tempo
–  Audio, video, animazioni, dati di sensori (temperatura,
pressione, …)
•  Data stream: una sequenza (flusso) di unità di dati
dipendenti dal tempo
–  Ad es. stream audio, stream video
–  Requisiti temporali espressi come requisiti di qualità del
servizio (Quality of Service, QoS)
113
•  Vincoli temporali sulla modalità trasmissiva dei dati
–  Trasmissione asincrona
•  Preserva l’ordinamento, ma non la distanza temporale tra unità
dati dello stream
•  Non ci sono quindi restrizioni temporali
–  Trasmissione sincrona
•  Preserva l’ordinamento e garantisce un tempo massimo di
trasmissione per ogni unità dati dello stream
–  Trasmissione isocrona
•  Aggiunge rispetto alla modalità sincrona la garanzia di un
tempo minimo di trasmissione ! bounded (delay) jitter
114
•  Definizione: consideriamo solo stream di dati continui
con trasmissione isocrona
•  Alcune caratteristiche comuni
–  Gli stream sono unidirezionali
–  Generalmente c’è un’unica sorgente ed una o più
destinazioni
•  Gli stream possono essere semplici o compositi
•  Stream semplici
–  Una semplice sequenza di dati
•  Stream compositi
–  Internamente strutturati e composti da stream semplici
(substream), con requisiti temporali tra i substream che li
compongono
–  Ad es. film con 1 substream video e 2 substream audio per
effetto stereo
–  Problema di sincronizzazione
115
•  In uno stream è essenziale che siano preservate le
relazioni temporali tra le unità dati
•  Il termine QoS (Quality of Service) è usato per
descrivere i requisiti di un’applicazione verso una
certa risorsa
–  Alcune applicazioni richiedono livelli minimi garantiti, altre
richiedono qualità in termini statistici (es. elaborazione
remota di immagini mediche vs. video entertainment)
•  Metriche per specificare la QoS a livello applicativo
–  Il bit rate a cui devono essere trasportati i dati
–  Il tempo massimo di set up di una sessione (quando
un’applicazione può iniziare ad inviare dati)
–  Il tempo massimo di trasporto (quanto impiega un’unità di
dati ad arrivare al destinatario)
–  La varianza massima del tempo di trasmissione (jitter)
–  Il tempo massimo di round-trip
116
•  Come garantire la QoS considerando che lo stack
di protocolli Internet si basa su un servizio a
datagram e di tipo best-effort?
–  A livello di rete
–  A livello applicativo
•  Esistono vari meccanismi a livello di rete
–  Ad es. DiffServ (Differentiated Services), un modello di
servizio e relativa architettura con l’obiettivo di
differenziare i servizi in Internet
•  Supportando meccanismi di classificazione del traffico
•  I pacchetti possono essere trattati con diversa priorità, ad
es. classi di inoltro rapido ed inoltro assicurato
•  Non necessariamente supportato dai router
117
•  Uso di buffer per ridurre lo jitter
•  Uso del frame interleaving per ridurre gli effetti della
perdita dei pacchetti (quando più frame sono nello
stesso pacchetto)
Trasmissione noninterleaved
Trasmissione interleaved
118
•  Problema: dato uno stream composito, come
mantenere la sincronizzazione tra i diversi stream
semplici componenti?
–  Ad es. effetto stereo con due canali audio: la differenza di
sincronizzazione tra i due substream deve essere inferiore a
20-30 µsec!
•  Soluzione possibile: sincronizzazione esplicita
–  Applicazione del principio dell’algoritmo token bucket usato
per il filtraggio del traffico
119
•  Comunicazione multicast: schema di comunicazione
in cui i dati sono inviati a molteplici destinatari
–  Comunicazione broadcast: caso particolare della multicast,
in cui i dati sono spediti a tutti i destinatari connessi in rete
–  Esempi di applicazioni multicast one-to-many: distribuzione
di risorse audio/video, distribuzione di file
–  Esempi di applicazioni multicast many-to-many: servizi di
conferenza, giochi multiplayer, simulazioni distribuite
interattive
Unicast di un video a 1000 utenti
Multicast di un video a 1000 utenti
120
•  Multicast a livello di protocolli di rete
–  Multicast a livello IP basato sui gruppi
•  Gruppo: host interessati alla stessa applicazione multicast
•  Indirizzo IP di classe D assegnato al gruppo
–  La replicazione dei pacchetti e il routing sono gestiti dai
router
–  Uso limitato nelle applicazioni per:
•  mancanza di uno sviluppo su larga scala (solo circa 5% degli
AS supporta il multicast)
•  problema di tener traccia dell’appartenenza ad un gruppo
•  Multicast a livello applicativo
–  La replicazione dei pacchetti e il routing sono gestiti dagli
end host
–  Strutturato: creazione di percorsi di comunicazione espliciti
–  Non strutturato: basato su gossip
121
•  Idea di base del multicasting applicativo
–  Organizzare i nodi in una rete overlay
–  Usare tale rete overlay per diffondere le informazioni
•  Come costruire la rete overlay?
–  Nodi organizzati in un albero
•  Unico percorso tra ogni coppia di nodi
–  Nodi organizzati in una mesh (rete a maglia)
•  Molti percorsi tra ogni coppia di nodi
122
•  Esempio: costruzione di un albero per il multicasting
applicativo in Scribe
–  Scribe: sistema publish/subscribe decentralizzato basato su Pastry
–  Pastry: rete P2P strutturata basata su DHT
1.  Il nodo che inizia la sessione multicast genera l’identificatore, detto
groupId, del gruppo di multicast
2.  Cerca (tramite Pastry) il nodo responsabile per groupId
3.  Tale nodo diventa la radice dell’albero di multicast
4.  Se il nodo P vuole unirsi all’albero di multicast identificato da
groupId invia una richiesta di JOIN
5.  Quando la richiesta di JOIN arriva al nodo Q
•  Q non ha mai ricevuto una richiesta di JOIN per groupId Q diventa
forwarder, P diventa figlio di Q e Q inoltra la richiesta di JOIN verso la
radice
•  oppure Q è già un forwarder per groupId P diventa figlio di Q; non
occorre inoltrare la richiesta di JOIN alla radice
Riferimento: M. Castro et al., “SCRIBE: A large-scale and decentralised
application-level multicast infrastructure”, IEEE JSAC, Oct. 2002.
123
forwarder
radice
forwarder
join()
join()
forwarder
radice
forwarder
forwarder
radice
forwarder
forwarder
join()
124
•  Stress sui collegamenti: quante volte un messaggio di
multicasting applicativo attraversa lo stesso
collegamento fisico?
–  Esempio: il messaggio da A a D attraversa <Ra,Rb> due volte
•  Stretch: rapporto tra il tempo di trasferimento
nell’overlay network e quello nella rete sottostante
–  Esempio: i messaggi da B a C seguono un percorso con costo
71 a livello applicativo, ma 47 a livello di rete stretch=71/47
125
•  Protocolli di tipo probabilistico, detti anche epidemici o
di gossiping
–  Essendo basati sulla teoria della diffusione delle epidemie o del
gossip nelle reti sociali
•  Permettono la rapida diffusione delle informazioni in reti
a larghissima scala attraverso la scelta casuale dei
destinatari successivi tra quelli noti al mittente
–  Ogni nodo, per inviare un messaggio, recapita il messaggio ad
un sottoinsieme, scelto casualmente, dei nodi nella rete
–  Ogni nodo che lo riceve ne rinvierà una copia ad un altro
sottoinsieme, anch’esso scelto casualmente, e così via
•  Caratteristiche della diffusione delle informazioni basata
su gossip
–  Scalabilità: ogni nodo invia soltanto un numero limitato di
messaggi, indipendentemente dalla dimensione complessiva
della rete
–  Affidabilità e robustezza: grazie alla ridondanza dei messaggi
126
•  Definiti nel 1987 di Demers et al. in un lavoro sulla
garanzia di consistenza nei database replicati
•  Idea di base: assumendo che non vi siano conflitti di
scrittura
–  Le operazioni di aggiornamento sono eseguite inizialmente su
una o alcune repliche
–  Una replica comunica il suo stato aggiornato ad un numero
limitato di vicini
–  La propagazione dell’aggiornamento è lazy (non immediata)
–  Al termine, ogni aggiornamento dovrebbe raggiungere tutte le
repliche
Riferimento: A. Demers et al., “Epidemic Algorithms for Replicated Database
Maintenance”, Proc. 6th Symp. on Principles of Distributed Computing, pp.
1-12, Aug. 1987. ACM.
127
•  Principi di funzionamento: anti-entropia e gossiping
•  Anti-entropia: modello di propagazione in cui ciascuna
replica sceglie a caso un’altra replica e si scambiano gli
aggiornamenti, giungendo al termine ad uno stato
identico su entrambe
•  Gossiping: una replica che è stata appena aggiornata
(ossia infettata) contatta un certo numero di repliche
scelte casualmente inviandogli il proprio aggiornamento
(infettandole a loro volta)
128
•  Un nodo P sceglie casualmente un altro nodo Q nel
sistema
scelta
•  Tre strategie di aggiornamento:
–  push: P invia soltanto i suoi aggiornamenti a Q
–  pull: P si prende soltanto i nuovi aggiornamenti da Q
–  push-pull: P e Q si scambiano reciprocamente gli
aggiornamenti (dopodiché possiedono le stesse
informazioni)
dati
scelta
dati
scelta
dati
•  Osservazione: la strategia push-pull impiega solo
O(log(N)) round per propagare un singolo
aggiornamento a tutti gli N nodi del sistema
–  Round: intervallo di tempo in cui ogni nodo ha preso almeno
una volta l’iniziativa di scambiare aggiornamenti
129
•  Modello di base: un nodo P che è stato appena
aggiornato, contatta un nodo Q scelto a caso; se Q ha
già ricevuto l’aggiornamento (è già infetto), P smette
con probabilità 1/k di contattare altri nodi
•  Se s è la frazione di nodi non ancora aggiornati, si
dimostra che
s = e!(k+1)(1!s)
•  Per garantire che tutti i nodi siano aggiornati, occorre
combinare il gossiping puro con l’anti-entropia
130
•  Due peer P e Q, con P che ha scelto Q per lo scambio
di dati
Active thread (peer P):
(1) selectPeer(&Q);
(2) selectToSend(&bufs);
(3) sendTo(Q, bufs);
(4)
(5) receiveFrom(Q, &bufr);
(6) selectToKeep(cache, bufr);
(7) processData(cache);
----->
<-----
Passive thread (peer Q):
(1)
(2)
(3) receiveFromAny(&P, &bufr);
(4) selectToSend(&bufs);
(5) sendTo(P, bufs);
(6) selectToKeep(cache, bufr);
(7) processData(cache)
•  Quali sono gli aspetti cruciali?
–  La selezione dei peer
–  La selezione dei dati scambiati
–  Il processamento dei dati ricevuti
Riferimento: A.-M. Kermarrec, M. van Steen, “Gossiping in Distributed Systems”,
ACM Operating System Review 41(5), Oct. 2007.
131
•  La diffusione dell’informazione è l’applicazione
classica e più popolare del gossiping nei SD
–  Valida alternativa rispetto al flooding
•  Nel caso di flooding
–  Ogni nodo che riceve il messaggio lo invia a tutti i suoi vicini
–  Il messaggio viene scartato quando il suo TTL diviene nullo
Round 2
Round 1
Round 3
Messaggi inviati: 18
Nodi raggiunti: 8 su 9
132
•  Nel caso di gossiping semplice
–  Il messaggio viene inviato con una probabilità di gossiping p
for each messaggio m
if random(0,1) < p then invia m
Round 1
p
p
Round 2
p
Round 3
p
p
p
p
p
p
p
p
Messaggi inviati: 11
Nodi raggiunti: 6 su 9
133
•  Oltre alla diffusione dell’informazione…
•  Peer sampling
–  Per fornire a ciascun peer una lista di peer da contattare
•  Monitoring di nodi e risorse in sistemi distribuiti a
larga scala
•  Computazioni distribuite per l’aggregazione di dati, in
particolare in reti di sensori
–  Computazione di valori aggregati (ad es. somma, media,
massimo, quantili)
–  Ad es. nel caso di calcolo della media
•  Siano x0,i e x0,j i valori al tempo t=0 posseduti dai nodi i e j
•  Dopo il gossiping tra i e j: x1,i,x1,j "(x0,i + x0,j)/2
134

ComunicazioneSD - Università degli Studi di Roma "Tor Vergata"

Transcript

Documenti analoghi

Sistemi Distribuiti e Cloud Computing

Sistemi Distribuiti e Cloud Computing

Scheva-Pazik, è finita? - Marco Tilli, ex di Valeria Marini

Demetrio Stratos Nanni Balestrini Le milleuna

4pp

Sistemi peer-to-peer Sistemi peer-to-peer (P2P)

Networking Computing power Storage Memory Protocols

Graduatoria alunni sezione Bilinguismo

Anteprima di “TaorminaFilmFest

Il green carpet della Mostra del Cinema di Venezia