Comunicazione: Socket, RPC ed RMI

Comunicazione: Socket,
Socket, RPC ed RMI - Socket (1/3)
Comunicazione: Socket,
Socket, RPC ed RMI - Socket (2/3)
 Creare un’applicazione distribuita
 Socket:
 Canali di comunicazione tra processi residenti su host diversi
 Per ogni applicazione occorre stabilire un protocollo di trasmissione per
la codifica e la decodifica dei dati
 Spostano la programmazione delle applicazioni ad un livello troppo
basso macchina remota
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.1
Comunicazione: Socket,
Socket, RPC ed RMI - Socket (3/3)
 Remote Procedure Call (RPC):
 Astrazione della comunicazione fra i processi al livello di una chiamata
di procedura
 I parametri vengono impacchettati e spediti a destinazione dopo essere
stati codificati. Ad una operazione analoga vengono sottoposti i valori
restituiti
 Consente l’invio di solo di tipi di dato primitivi
 La conversione dei dati tra piattaforme diverse introduce un overhead
molto elevato
 E’ legata al concetto di processo e non si integra nel codice Object
Oriented
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.2
 Remote Methode Invocation (RMI)
 Meccanismo che permette ad un’applicazione in esecuzione su una
macchina locale di invocare i metodi di un'altra applicazione in
esecuzione su una macchina remota
 Viene creato localmente solo il riferimento ad un oggetto remoto, che è
effettivamente attivo su un host distinto. Un programma invoca i metodi
attraverso questo riferimento locale
 La struttura che si occupa di intercettare le invocazioni dei metodi per
trasmetterli (con i relativi argomenti) all'oggetto sul server è denominata
Object Request Broker (ORB)
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Middleware e rete
Middleware e rete
Message passing
comunicazione sincrona
TCP
interfaccia verso TCP si basa su flusso bidirezionale e abilita l’invio di
un flusso (stream) di dati fra mittente e destinatario
Comunicazione produttore-consumatore
asincrona
Receive bloccante con timeout - fissa un intervallo oltre il quale non attendere
(affidabilità)
porta
Destinatario
Mittente
SD.5b.3
Message passing
Interfaccia fra middleware e strato trasporto (TCP o UDP)
UDP
interfaccia verso UDP si basa su message passing e abilita l’invio di
un singolo messaggio fra mittente e destinatario
Comunicazione datagramma
Es: socket per specificare il destinatario (porta) in Unix
17:04
send
receive
bloccante
bloccante
Denominazione del destinatario
- processo
- porta
- gruppi di processi
- gruppi di porte
non bloccante
bloccante
non bloccante non bloccante
in TCP destinatario è
(IP address, numero porta )
processo
una porta ha un destinatario ma può avere più mittenti
un processo può ricevere su più porte
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.4
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.5
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.6
1
Sockets e porte
Message passing
in TCP destinatario è
(IP address, numero porta )
Comunicazione UDP
Nota:
Porta concordata
socket
porta
InetAddress
classe JAVA che rappresenta indirizzi IP
gli utenti della classe usano i nomi DNS - metodi che usano nomi DNS (es: creazione)
qualsiasi porta
Comunicazione UDP
datagramma, comunicazione non affidabile
socket
message
server
client
cliente: mittente/destinatario
- crea socket
- lo collega a IP address e porta
altre porte
il server rende noto il numero di porta ai clienti
il server deve essere eseguito (servizio) sempre su quell’host
-> manca di trasparenza di locazione
IP address
Processo -> molte porte per ricevere
Porta: uso esclusivo di un processo (eccezione: IP multicast)
UDP usa send non bloccante e receive bloccante eventualmente con timeout
Possibile concorrenza con thread
Perdita di messaggi se non esiste un socket collegato alla porta destinazione
Socket ---> protocollo TCP/UDP
17:04
SD.5b.7
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
SD.5b.8
17:04
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Comunicazione in UDP
Guasti in UDP
integrità, validità
Controllo della correttezza (checksum)
Array di bit con msg
lungh. msg
IP address
numero porta
DatagramSocket: fornisce il # di porta ad un processo che lo chiede, permette
al sistema di scegliere una porta libera
UDP usato per applicazioni che non richiedono forte affidabilità
SocketException se la porta è già in uso o riservata
Metodi:
send
receive
per trasmettere pacchetti tra socket
setSoTimeout
connect
per connettersi ad una porta e indirizzo
es: DNS
17:04
SD.5b.10
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
SD.5b.9
Cliente UDP invia un messaggo al servente e riceve la risposta
per invio e ricezione
metodi per estrarre le informazioni dal DatagramPacket
getPort
getData
getAddress
Tipi di guasto
omissioni -> perdita di messaggi (errore canale, checksum,
spazio limitato,…)
arbitrari -> disordine di consegna
17:04
import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
// args give message contents and server hostname
try {
DatagramSocket aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m,
args[0].length(), aHost, serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = new DatagramPacket(buffer,
buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new String(reply.getData()));
Classi di JAVA API per comunicazione datagramma
DatagramPacket
DatagramSocket
Modello di guasti
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
- quando si esegue una receive si ottiene oltre al messaggio anche
- IP address e porta del mittente
- possono essere usate per l’invio di risposta
Processo -> Socket -> IP address, numero porta
Soluzione:
- riferimento al servizio per nome e uso del name server ->
trasparenza di locazione
- il SO fornisce nomi per cui si ha indipendenza dalla locazione ->
trasparenza di locazione e di migrazione
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
IP address
processo
servente
- crea socket
- lo collega una porta
- rende nota la porta ai clienti
17:04
SD.5b.11
aSocket.close();
}catch (SocketException e){System.out.println("Socket: " +
e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}
}
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.12
2
Comunicazione TCP
Servente UDP riceve richieste ripetute dal cliente e le rispedisce al cliente
import java.net.*;
import java.io.*;
public class UDPServer{
public static void main(String args[]){
try{
DatagramSocket aSocket = new DatagramSocket(6789);
byte[] buffer = new byte[1000];
while(true){
DatagramPacket request = new DatagramPacket(buffer,
buffer.length);
aSocket.receive(request);
DatagramPacket reply = new
DatagramPacket(request.getData(),
request.getLength(), request.getAddress(),
request.getPort());
aSocket.send(reply);
}
}catch (SocketException e){System.out.println("Socket: " +
e.getMessage());
}catch (IOException e) {System.out.println("IO: " +
e.getMessage());}
}
}
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
Flusso di dati, comunicazione con connessione e affidabile
- senza duplicazione, garanzia dell’ordine
- scelta della lunghezza (segmentazione)
- uso di connect e accept per attivare una connessione, poi la comunicazione
è fra entità pari
servente
- crea socket di ascolto
cliente
- lo collega una porta
- crea stream socket
- aspetta la richiesta di connessione
- lo collega a qualsiasi porta
(coda)
- esegue una connect
- esegue una accept creando un stream socket
per quel cliente e mantiene l’altra porta libera per
l’ascolto di altre connect
SD.5b.13
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.14
Cliente TCP si connette al server, invia un messaggo e riceve la risposta
Socket
usato da due processi
connessi
metodi
accept che restituisce un’istanza Socket il cliente tramite un
costruttore crea
il socket per la
connessione ed
esegue connect
metodi
getInputStream
get Output Stream,
17:04
Possibile uso di thread diversi per comunicazioni diverse con clienti
Modello di guasti
Controllo della correttezza, duplicazioni e ordinamento
(checksum, numeri di sequenza)
controllo della perdita di messaggi (timeout e ritrasmissione)
Casi estremi: fallimento e caduta della connessione
- notifica al processo
- impossibile distinguere fra guasto di rete e guasto di processo destinazione
- impossibile garantire la consegna di messaggi recenti
SD.5b.16
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.15
Servente TCP crea una connessione per ogni cliente e ripete le richieste
import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
// arguments supply message and hostname of destination
try{
int serverPort = 7896;
Socket s = new Socket(args[1], serverPort);
DataInputStream in = new DataInputStream(
s.getInputStream());
DataOutputStream out =
new DataOutputStream( s.getOutputStream());
out.writeUTF(args[0]);
// UTF è una stringa codificata
String data = in.readUTF();
System.out.println("Received: "+ data) ;
s.close();
}catch (UnknownHostException e){
System.out.println("Sock:"+e.getMessage());
}catch (EOFException
e){System.out.println("EOF:"+e.getMessage());
}catch (IOException
e){System.out.println("IO:"+e.getMessage());}
}
}
Classi di JAVA API per comunicazione TCP
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Blocco possibile dovuto al buffer di socket destinazione, o a meccanismi di controllo
del flusso
- ogni socket (cliente e servente) ha un input e output stream
- alla chiusura i dati nei buffer vengono consegnati e
- la connessione viene interrotta
Comunicazione in TCP
Server Socket
usato dal server per creare socket per ascolto
Guasti in TCP
import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
int serverPort = 7896;
ServerSocket listenSocket = new ServerSocket(serverPort);
while(true) {
Socket clientSocket = listenSocket.accept();
Connection c = new Connection(clientSocket);
}
} catch(IOException e) {System.out.println("Listen :"+e.getMessage());}
}
}
// continua
SD.5b.17
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.18
3
Esempio - continua
Esempio: IPC in Unix
class Connection extends Thread {
DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public Connection (Socket aClientSocket) {
try {
clientSocket = aClientSocket;
in = new DataInputStream( clientSocket.getInputStream());
out =new DataOutputStream( clientSocket.getOutputStream());
this.start();
} catch(IOException e)
{System.out.println("Connection:"+e.getMessage());}
}
public void run(){
try {
// an echo server
String data = in.readUTF();
out.writeUTF(data);
clientSocket.close();
} catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
} catch(IOException e) {System.out.println("IO:"+e.getMessage());}
}
}
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
Unix BSD 4.x : primitive di interprocess communication tramite chiamate di sistema
implementate sullo strato (4) TCP/UDP
Mittente/Destinatario: indirizzo socket -> IP address, numero porta
connect(s, ServerAddress)
Protocollo di rete
chiamata send
Creazione del socket
chiamata di sistema socket - specifica di dominio di comunicazione (Internet), tipo
(con/senza conn.), protocollo ---> restituisce un descrittore
amount = recvfrom(s, buffer, from)
17:04
SD.5b.20
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Comunicazione solitamente sincrona, talvolta asincrona, affidabile
Client
s = socket(AF_INET, SOCK_STREAM,0)
bind(s, ServerAddress);
listen(s,5);
doOperation
Request
message
getRequest
public byte[] getRequest ();
Riceve una richiesta di cliente da una porta del servente
select object
(continue)
execute method
Reply
message
SD.5b.21
public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)
manda una richiesta all’oggetto remoto e restituisce la risposta
L’argomento specifica
l’oggetto remoto
il metodo da invocare
gli argomenti del metodo
Server
n = read(sNew, buffer, amount)
17:04
Operazioni del protocollo
request-reply
Comunicazione cliente-servente: request-reply
ServerAddress e ClientAddress sono indirizzi socket
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
bind(s, ServerAddress)
sendto(s, "message", ServerAddress)
Alternativa - una sola chiamata per creazione e bind (es JAVA API)
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
(wait)
connect fa automaticamente il bind del nome al
socket
s = socket(AF_INET, SOCK_DGRAM, 0)
bind(s, ClientAddress)
ServerAddress e ClientAddress sono indirizzi socket
Binding collegamento fra descrittore del socket e indirizzo
bind - chiamata di sistema - prima della comunicazione
SD.5b.19
Ricezione di un messaggio
s = socket(AF_INET, SOCK_DGRAM, 0)
chiamata receive
destinatario
mittente
sNew = accept(s, ClientAddress);
write(s, "message", length)
Indirizzi socket sono pubblici
socket
socket
Ascolto e accettazione di connessione
s = socket(AF_INET, SOCK_STREAM,0)
Bind - collegamento statico
Invio di un messaggio
Esempio: Unix - sockets usati per streams
Richiesta di connessione
Esempio: Unix - sockets usati per datagrammi
sendReply
public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);
Invia un messaggio di risposta al cliente all’IP address e porta specificata
Max numero di richieste
accodabili
17:04
SD.5b.22
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.23
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.24
4
Struttura del messaggio
request-reply
Guasti in request-reply
messageType
int (0=Request, 1= Reply)
requestId
int
objectReference
RemoteObjectRef
Guasti in request-reply
- possibile perdita di messaggi
mittente
destinatario
nodi intermedi
- doOperation ha un timeout per la risposta
poi ritrasmette
o notifica l’errore al cliente
- possibile partizionamento della rete a causa di cadute di linea
- se si perde l’ack e il servente riceve un duplicato di richiesta si riesegue l’operazione
->> ok solo per operazioni idempotenti, non cambia il risultato ripetendo l’operazione
methodId
int or Method
- possibile guasto di processi
problema della identificazione dei guasti
uso di timeout
arguments
array of bytes
- se un messaggio arriva, è corretto
- possibile uso della storia dei messaggi ricevuti per evitare riesecuzioni inutili
svuotando periodicamente l’elenco
semplificazione con un solo messaggio per cliente (ultimo reply inviato)
se doOperation , getRequest e sendReply sono implementate su UDP si possono
avere i problemi dovuti a connessione datagram
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.25
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Protocolli di scambio RPC
17:04
SD.5b.26
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Messaggio di richiesta HTTP
17:04
SD.5b.27
Messaggio di risposta HTTP
Protocolli con diverse semantiche in presenza di guasti di comunicazione
Implementazione di diversi tipi di RPC
Nome
Messagio inviato da
Cliente
Servente
method
Cliente
GET
R
Request
R
Request
Reply
R
Request
Reply
URL or pathname
//www.dsi.unive.it/laurea/index.html
HTTP version
headers message body
HTTP version
HTTP/1.1
HTTP/ 1.1
status code
200
reason
OK
headers
message body
resource data
Acknowledge reply
Request
Mittente
Destinatario
Reply(..Id..)
Ack Reply(..Id…)
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.28
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.29
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.30
5
RPC: meccanismo di invocazione remota
RPC: esempio
Comunicazione fra oggetti distribuiti - RPC
Strumenti specifici del linguaggio (compilatore STUB) per nascondere i
dettagli dei passaggi dei parametri
Routine precompilata
S routine
(procedura)
Compilatore
P
Compilatore
programma
utente
SO
codice oggetto
Linker/loader
UO
codice oggetto
1. Il Cliente chiama la STUB in modo normale
2. La STUB Cliente costruisce il msg di richiesta, marshalling dei parametri, chiama il SO per
effettuare la chiamata
3. SO manda il msg al servente
4. Il nodo servente lo riceve e lo passa allo STUB Servente
5. La STUB Servente unmarshall parametri, chiama la routine corrispondente
6. La chiamata viene eseguita e i risultati sono restituiti alla STUB Servente
7. La STUB Servente marshall parametri, costruisce il msg risposta e lo passa al SO per la
risposta
8. Il msg viene inviato al cliente
9. La STUB Cliente riceve il msg
10. La STUB Cliente unmarshall, passa il risultato al cliente.
Cliente
STUB
Servente
message
n = sum(4,7)
Sum
4
7
Sum
4
7
sum(i,j)
int i,j;
{
return (i+1)
}
Invocazione remota
UO
codice oggetto
Client STUB
Server STUB
Compilatore
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Call
Return
SO
codice oggetto
31
pack parametri
unpack risultati
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
RPC: progetto - parametri
Aspetti di progetto
call
risultati
17:04
SD.5b.32
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
RPC: progetto - binding
l’indirizzo di una macchina non ha significato su un’altra
-> usare oggetti reali
-> usare call by value-result invece di call by reference
17:04
SD.5b.34
- dinamico
localizzare il servente a tempo di esecuzione
• la specifica del servizio e memorizzata (registrata) da un binder (name server)
il binder è un servente ad un indirizzo noto
la specifica include: nome del servizio
specifica della routine di servizio (def. interfaccia o def. della classe)
indirizzo (nome host, nome porta) del servente che esegue il servizio
l’atto di registrazione è detto exporting
• il servente (service provider) usa la specifica del servizio per generare la
stub del servente e collegarla alla routine di servizio (servente pronto a ricevere)
• il costruttore di applicazioni può
- esaminare la specifica del servizio registrata nel binder (tramite un browser) per
il servizio cercato e selezionare una specifica di servizio
- passarla al generatore di Stub per creare la Stub Cliente
la Stub Cliente ha il codice per contattare il binder a run time ed ottenere l’indirizzo
del server indicando il nome del servizio => il cliente non deve essere ricompilato
(trasparenza)
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.33
RPC: progetto - IDL
BINDING
- statico scrivere il programma cliente (generare la STUB) per un servente specifico su
una macchina specifica -> semplice, non flessibile, non trasparente
- passaggio dei parametri
- binding
- trattamento dei guasti
PARAMETRI varie tecniche usate dai linguaggi (es. C usa call by value e by reference)
- call by value
il valore del parametro è copiato nella pila; una
variabile locale alla procedura chiamata è inizializzata a tale valore. Se questa viene
modificata, ciò non ha effetto sulla variabile originaria
- call by reference
il riferimento alla variabile (puntatore, indirizzo) è
copiato nella pila; la procedura chiamata HA accesso alla variabile e le modifiche si
riflettono direttamente sul programma chiamante
- call by value-result
il valore della variabile è copiato nella pila come nella
chiamata per valore, poi è ricopiato sulla pila dopo la chiamata, riscrivendo il risultato
originale
PROBLEMA: come trattare la call by reference in REMOTO (RPC)?
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
unpack parametri
pack risultati
17:04
SD.5b.35
Occorre un linguaggio di specifica per descrivere le routine di servizio
-> in programmi C++ si possono definire le classi, ma è una scelta dipendente dal
linguaggio
-> IDL Interface Defintion Language
permettono la programmazione con diversi linguaggi
un IDL per il compilatore stub
-> clienti e serventi possono essere scritti in diversi linguaggi
Esempio:
read (in char name(maxpath), out char buf(bufsize),
in int nbytes, in int position)
- in/out rispetto al servente specifica la direzione del flusso di informazione
- il server aspetta un path name (nome di file), numero di bytes da leggere dalla
position e il risultato viene posto in buf
- il cliente manda parametri in al servente nella richiesta, il servente invia il
messaggio che contiene i parametri out
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.36
6
RPC: progetto - trattamento dei guasti e semantica
RPC: guasti e semantica
Modelli di guasto
- di comunicazione: i processi funzionanti possono non poter comunicare
temporaneamente
- crash dei nodi: eventualmente recuperabile
semantica della RPC
- terminazione normale il cliente riceve il messaggio dal servente
- terminazione anormale (eccezionale)
il cliente NON riceve la risposta
=>
o non ha ricevuto alcun messaggio
o ha ricevuto un messaggio di indirizzo sconosciuto (AU)
semantica
exactly once
at most once
at least once
NOTA: exactly once
at most once
SD.5b.37
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
semantica RPC e guasti di comunciazione
server non mantiene
i risultati
at least once
REQ
retry fino alla risposta
risposta=reply
May be
server mantiene
i risultati
17:04
SD.5b.38
semantica RPC e crash del server
Crash durante o dopo l’esecuzione
Cliente - time out
no retry
risposta=AU
receive(…)
<esecuzione>
REQ
receive(…)
crash
crash
no reply
exactly once
il cliente invia la richiesta e riceve una AU
-> semantica RPC è ….
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
SD.5b.40
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
SD.5b.39
-> occorre coordinare cliente e servente
es.
at most once
17:04
Semantica exactly once
comportamento tutto o niente
terminazione normale: una esecuzione
terminazione anormale: nessuna esecuzione
difficile (impossibile) da ottenere in presenza di crash del servente
possibili azioni del servente non annullabili o reversibili
se le azioni del servente sono annullabili (es. cambiamento di dati), il guasto di
tipo server crash si può annullare con ‘undo’ delle esecuzioni parziali,
per simulare la mancata esecuzione
no reply
• il cliente non può sapere cosa è accaduto
• al cliente scatta il timeout in attesa di risposta
• il cliente reagisce al timeout con
17:04
•
semantica RPC in presenza di guasti di comunicazione e crash del servente
Crash prima dell’esecuzione
server invia il risultato al cliente e poi servente crash
il ripristino del server riporta uno stato pre-crash
MA il cliente HA ricevuto il risultato => situazione cliente servente incoerente
approccio generale => transazioni atomiche (azioni atomiche)
- ritenta (rinvia la richiesta): alla fine una risposta può essere ricevuta (se il
guasto è stato riparato)
la risposta sarà reply o address unknown: RPC con semantica at least once
- termina la RPC con semantica at most once
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
-> il cliente non riprova: semantica RPC è ….
-> il cliente riprova finché non ottiene una risposta
- la risposta è AU, la chiamata termina in modo anormale
semantica RPC è ….
- la risposta è la reply -> due casi
caso 1 il servente non mantiene lo stato di esecuzioni precedenti, per
cui il servente può rieseguire richieste ripetute
semantica RPC è ….
caso 2 il servente mantiene il risultato dell’ultima esecuzione in un
buffer, in caso di duplicati li riconosce e rinvia il risultato
semantica RPC è ….
-assumiamo che il protocollo RPC:
- per gli eventi 2,3,4: il cliente attiva un timer dopo l’invio del messaggio richiesta
in modo da non bloccarsi mai
allo scattare del timeout il cliente può
- terminare la chiamata in modo anormale
- ritentare la chiamata e rinviare la richiesta
- ripetere il tentativo un numero finito di volte per terminare
poi in modo anormale
difficile da implementare
relativamente facile da implementare, compromesso
17:04
• il cliente invia la richiesta e poi scatta il timeout mentre aspetta la risposta
- per l’evento 1: riceve un messaggio AU (address unknown) dal nodo chiamato
la chiamata termina in modo anormale
term. normale: la chiamata è stata eseguita una volta
term. anormale: la chiamata non è stata eseguita
term. normale: la chiamata è stata eseguita una volta
term. anormale: la chiamata non è stata eseguita,
o è stata eseguita parzialmente o eseguita più volte
term. normale: la chiamata è stata eseguita una o più volte
term. anormale: la chiamata non è stata eseguita ,
o è stata eseguita parzialmente
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
semantica RPC e guasti di comunicazione
- possibili eventi di guasti durante una RPC
1. Il cliente non riesce a localizzare il processo servente
2. Il messaggio di richiesta del cliente è perso
3. La risposta del servente è perso
4. Crash del servente durante la chiamata
5. Crash del cliente durante la chiamata
17:04
SD.5b.41
protocollo di coordinazione che garantisce la proprietà
‘tutto o niente’
approccio pratico RPC => implementare la semantica RPC at most once
e usare le transazioni atomiche a livello applicazione per assicurare la consistenza delle
applicazioni anche in presenza di guasti e di crash del server
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.42
7
semantica RPC in presenza di guasti di comunicazione e crash del servente
Protocolli RPC che forniscono una specifica semantica in presenza di
- messaggi persi
- server crash
at least once RPC
cliente
fa la chiamata con timeout
servente
at most once RPC
cliente
servente
RPC e crash del cliente
Crash del cliente e orfani
Se un cliente è soggetto a crash dopo aver inviato una richiesta che è eseguita da un
servente, l’esecuzione è detta orfano
gli orfani consumano risorse (elaborazione, memoria,…)
se scatta il timeout (la risposta non è arrivata) ritenta
ripete i tentativi un numero finito di volte
se il cliente ha eseguito lock su risorse queste rimangono bloccate
esegue le chiamate ricevute e invia le risposte
NON mantiene lo stato di chiamate precedenti (stateless server)
gli orfani creano problemi di consistenza e interferiscono con la esecuzione normale
ripete come sopra
i messaggi contengono un numero di sequenza di chiamata
le rispedizioni di richieste hanno lo stesso numero della prima
nuove richieste hanno un numero in ordine crescente
orfano
crash
- controllo duplicati
il servente al ricevimento di una nuova richiesta controlla che non sia già in
esecuzione sullo stesso nodo una precedente richiesta dallo stesso cliente.
In tal caso dovrebbe terminare o abortire la precedente chiamata prima di eseguire
quella corrente.
- controllo della vitalità dei clienti
un nodo servente dovrebbe periodicamente controllare se i clienti sono ‘vivi’.
Se si sospetta un guasto del cliente, allora si dovrebbero terminare o abortire gli
orfani.
Servente
richiesta
Cliente
Trattamento degli orfani
per ogni cliente il servente mantiene i risultati dell’ultima
chiamata eseguita con il numero di sequenza
per ogni richiesta si controlla se è nuova e solo in tal caso
riesegue, altrimenti invia solo il risultato già calcolato
-> informazione di stato
un crash del servente fa perdere tale stato
-> come assicurare la permanenza dello stato per gestione dei duplicati?
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:04
SD.5b.43
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Comunicazione a gruppi
17:04
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Come si trattano le risposte?
senza attesa
attesa di una sola risposta
attesa di alcune risposte - quante?
attesa di tutte le risposte
messaggio multicast inviato da uno ad un gruppo
utile per tolleranza ai guasti in applicazioni distribuite
Destinatario 1
Multicast
richiesta
multicast
Motivazioni per il multicast
• Tolleranza ai guasti - replicazione servizi - stessa richiesta a più
serventi in parallelo; tollera guasti dei serventi
• ricerca e localizzazione di oggetti distribuiti - es. File system
distribuito: il server appropriato risponde
• replicazione dei dati - migliori prestazioni - ad una modifica il
gestore delle copie invia messaggio multicast
• aggiornamento multiplo
17:04
17:04
SD.5b.45
Protocolli multicast
Protocolli multicast
Comunicazione uno - a - tutti: broadcast
Comunicazione uno - a - molti: multicast
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
SD.5b.44
Sollecito
selettivo
globale
Conferma
positiva (ack)
negativa (nack)
Numero di conferme attese
risposta 1
Semantica del multicast
Destinatario 2
Implementazione del multicast
indirizzi di gruppo
supporto di broadcast
supporto punto-a-punto
risposta 2
Mittente
richiesta ripetuta per 3
Destinatario 3
risposta 3
SD.5b.46
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
classe D nel protocollo IP (livello 3)
es. Ethernet
lista con uso di attributi: invio di messaggi con predicato
il destinatario che soddisfa il predicato può ricevere il messaggio
17:04
SD.5b.47
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.48
8
Multicast: atomicità e affidabilità
Protocolli multicast
Protocolli multicast: ordinamento
A
Multicast atomico
garanzia di consegna a tutti i componenti del gruppo
Multicast FIFO
ordinamento solo dallo stesso mittente allo stesso destinatario
mitt 1
ricevuto da tutti o da nessuno
Multicast affidabile
garanzia di consegna
Multicast non affidabile
spedisce una sola volta
mitt 2
AB
mitt 3
BA
Multicast causale
ordinamento logico (causale)
consegna in un ordine che rispetta una regola di causalità
se un evento A precede un evento B
allora i messaggi sono consegnati rispettando tale ordine
algoritmi di ordinamento (Lamport)
mitt 4
B
Multicast totalmente ordinato
se atomico, consegna ad ogni membro del gruppo nello stesso
ordine
Ordinamento dei messaggi ai destinatari?
Multicast totalmente ordinato
Singoli multicast atomici mantengono l’ordine FIFO dei messaggi per un mittente e un destinatario
ma per più mittenti di multicast si può avere disordine
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.49
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Protocollo multicast: implementazione
*
semplice ma non efficiente: tramite send potenzialmente inaffidabile
procedure multicast (dest: array of PortId; m: messaggio);
var i: cardinal;
begin
for i:=0 to Max (dest) do Send (dest(i),m);
end;
*
17:05
SD.5b.50
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
attesa della risposta
time-out e ritrasmissione
17:05
SD.5b.51
Protocollo multicast atomico e affidabile
gestione dei guasti
- omissione di messaggi
- failure del mittente
Quando un processo aspetta la risposta da un altro processo del gruppo, lo
monitorizza (mittente) per identificare possibili eventuali guasti
(richiede la trasmissione della risposta)
occorre effettuare un monitoraggio
- controllo della trasmissione corrente
- eventuale ritrasmissione
- rimozione dei processi falliti
- gestione del gruppo
Possibile esclusione da un gruppo.
Muticast atomico e affidabile - costoso
implementazione:
- invio del messaggio a tutto il gruppo
- attesa della risposta
- time-out e ritrasmissione
per multicast affidabile:
- controllo di perdita di messaggi
- crash del mittente
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Differenza fra multicast causale ed atomico
Protocollo multicast affidabile: implementazione
Diverse implementazioni del multicast
*
per trasmettere da più clienti
I messaggi trasmessi ad un gruppo in multicast arrivano
ad ogni membro del gruppo in ordine
1 mittente
invia un messaggio al gruppo e aspetta ack da ognuno
2
se arrivano tutti gli ack OK
altrimenti se non arrivano entro un timeout: ritrasmissione
ripetendo l’attesa un dato numero di volte, oltre le quali si
elimina dal gruppo chi non risponde
problema: guasto del monitor
- attesa, quanto?
17:05
SD.5b.52
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.53
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.54
9
Hold-back queue
Protocollo multicast atomico e affidabile
Negative ack
Altre soluzioni al multicast atomico e affidabile
Problema: guasto mittente
Altre soluzioni al multicast atomico e affidabile
Hold-back queue
Negative ack
Il messaggio a destinazione viene tenuto in sospeso prima di essere
consegnato, fino all’arrivo del messaggio di consegna
Per atomicità
ogni destinatario invia un ack e monitorizza il mittente per attesa di conferma
I messaggi sono numerati ordinatamente dal mittente
Per garantire l’ordinamento e l’atomicità i messaggi sono numerati e ogni
messaggio è ritardato finché non arrivano i precedenti
il mittente completato il multicast, manda conferma a tutti (in m. atomico)
Il destinatario invia un segnale di NACK se il numero di
messaggio arrivato non è in sequenza
Il destinatario non invia ACK
Il mittente ha copia (storia) dei messaggi inviati
Atomicità e ordine
Con un multicast per volta il successivo è la conferma dal mittente del m. precedente
- soluzioni inefficienti -
Gestione possibili guasti del mittente recuperabili dal destinatario
Anche i destinatari devono avere la storia dei messaggi
Mittente
Hold back queue
Problema della lunghezza della storia
Destinatario
Possibili occasionali ack positivi (con # messaggio ricevuto) in piggyback
Coda di destinazione
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Multicast atomico e totalmente ordinato
17:05
SD.5b.55
Multicast atomico e totalmente ordinato
(1/3)
Si associa ad ogni messaggio un identificatore unico totalmente ordinato
Si passano ai livelli superiori (applicazione) solo i messaggi stabili
Semplice da realizzare se ogni mittente usa il # in sequenza con riferimento ad un
ordinamento totale
Ogni destinatario è sicuro del messaggio solo se non esiste un gap con il
successivo
Sequenza condivisa di identificatori
17:05
17:05
SD.5b.56
17:05
(3/3)
b) usare un processo sequenziatore
- centralizzata
unico gestore che ordina
collo di bottiglia
c) usare un protocollo fra i membri del gruppo per la generazione di
un identificatore
- distribuita
coordinamento fra i riceventi che concordano l’ordine
a) usare una marca temporale (timestamp) da orologi logici o fisici
diverse implementazioni
es. un gestore per ogni richiesta
soluzione inefficiente e poco scalabile
es. uso di broadcast
solo per casi particolari
algoritmi distribuiti per sistemi distribuiti
Soluzioni b e c integrano il calcolo dell’identificatore con il multicast
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
SD.5b.57
Implementazione:
Problemi aperti
SD.5b.58
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Multicast atomico e totalmente ordinato
(2/3)
Soluzioni:
Un messaggio è stabile a destinazione se non possono arrivare altri messaggi con
id. più basso.
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.59
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.60
10
IP multicast - indirizzi
IP multicast: comunicazione a gruppi
Implementazione: IP multicast - comunicazione a gruppi
Esempio - implementazione di comunicazione a gruppi
socket
socket
Messaggio multicast
mittente
Applicazione
Ogni host può appartenere a vari gruppi,
quando un insieme di processi hanno socket
nel gruppo
IP multicast
TTL - Time To Live - limite al numero di passi tramite rourter nel cammino
permanenti
Indirizzi
anche vuoti - in [ 224.0.0.1 , 224.0.0.225]
UDP
destinatario
temporanei
esistono solo se creati, eliminati se vuoti
richiesta di indirizzo - problema di unicità
non è garantito che si eviti di partecipare ad un altro gruppo
IP
Guasti <- ereditati da UDP
di omissione: consegna non garantita - non totale
Invio al gruppo anche senza appartenervi
socket
destinatario
Multicast locale e/o remoto, se la rete offre il servizio
socket
Router multicast - collegati fra loro
destinatario
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Gruppo dinamico
17:05
SD.5b.61
Implementazione: multicast in Java
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.62
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Un processo peer si unisce al gruppo in multicast e invia/riceve datagrams
17:05
SD.5b.63
continua
Implementazione in Java
Java fornisce un insieme di classi primitive per il multicast
JAVA API interfaccia datagram al multicast IP
classe MulticastSocket
sottoclasse di
DatagramSocket
costruttori per socket per uso su un porta specificata o una qualsiasi libera
metodi
joinGroup
leaveGroup
setTimeToLive (1 per default)
Invio di messaggi in multicast è simile all’invio su un socket UDP
- creare un datagram
- specificare il TTL (numero di hop)
Operazioni:
- creazione un socket multicast
- iscrizione ad un gruppo multicast
- invio dati al gruppo
- ricezione dal gruppo
- abbandono del gruppo
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
// get messages from others in group
byte[] buffer = new byte[1000];
for(int i=0; i< 3; i++) {
DatagramPacket messageIn =
new DatagramPacket(buffer, buffer.length);
s.receive(messageIn);
System.out.println("Received:" + new
String(messageIn.getData()));
}
s.leaveGroup(group);
}catch (SocketException e){System.out.println("Socket: " +
e.getMessage());
}catch (IOException e){System.out.println("IO: " +
e.getMessage());}
import java.net.*;
import java.io.*;
public class MulticastPeer{
public static void main(String args[]){
// args give message contents & destination multicast group (e.g.
"228.5.6.7")
try {
InetAddress group = InetAddress.getByName(args[1]);
MulticastSocket s = new MulticastSocket(6789);
s.joinGroup(group);
byte [] m = args[0].getBytes();
DatagramPacket messageOut =
new DatagramPacket(m, m.length, group, 6789);
s.send(messageOut);
}
}
// continua
17:05
SD.5b.64
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.65
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.66
11
Tipologie di sistemi RMI
Common Object Broker Architecture (CORBA):
 Permette la comunicazione fra applicazioni scritte in linguaggi differenti
mediante un modello di oggetto neutro.
 Permette la comunicazione di applicazioni preesistenti sviluppate in ambienti
eterogenei e per le quali non sia possibile effettuare una conversione in un
linguaggio comune.
L’eterogeneità di ambienti e di linguaggi comporta una elevata complessità del
codice.


Java RMI
Tipologie di sistemi RMI

Java RMI:

E’ un API che permette ad un’applicazione Java in esecuzione su una macchina
locale (client) di invocare i metodi di un’altra applicazione Java (server) in esecuzione
su una macchina remota

Modello a oggetti distribuito:
 Permette la comunicazione fra applicazioni scritte in Java
 L’eterogeneità di ambienti come conseguenza della portabilità del linguaggio
Java, porta ad un codice più semplice

Con Java RMI si utilizzano oggetti remoti che seguono per quanto possibile il
modello ad oggetti di Java
 Nel modello ad oggetti distribuito di Java un oggetto remoto consiste in:
 Un oggetto i cui metodi sono invocati da un’altra JVM presente su un host differente.
 Un oggetto descritto tramite interfacce remote che dichiarano i metodi accessibili da
remoto
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.67
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Caratteristiche del modello ad oggetti distribuito
17:05
SD.5b.68
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Caratteristiche del modello ad oggetti distribuito

I client di oggetti remoti interagiscono con le interfacce remote e devono gestire delle
eccezioni per eventuali fallimenti di una RMI

Gli argomenti ed i risultati dei metodi remoti sono passati per valore e non per
riferimento, sfruttando il concetto di serializzazione

Un oggetto remoto è sempre passato per riferimento

La semantica di alcuni dei metodi definiti dalla classe Object è specificata per gli
oggetti remoti

Sono stati introdotti meccanismi di sicurezza per il controllo del comportamento delle
classi e dei riferimenti

17:05
SD.5b.69
Architettura di RMI
I modelli coincidono per i seguenti aspetti:
 Un riferimento ad un oggetto remoto può essere un argomento o un valore di
ritorno indistintamente dal tipo di invocazione (locale o remota)
 Su un oggetto remoto si può effettuare il cast ad una qualsiasi delle interfacce
remote che implementa

S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.70
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.71
Stub: Reference all’oggetto remoto, proxy locale su cui vengono fatte le invocazioni
destinate all’oggetto remoto
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.72
12
Architettura di RMI
Architettura di RMI


RRL: Instaura un collegamento logico tra i due lati e gestisce la semantica
dell’invocazione:

Sul client riceve dallo stub le richieste da inviare al server e le codifica

Sul server decodifica le richieste e le inoltra allo skeleton
Garbage collection di oggetti remoti
Gli appropriati stub e skeleton vengono determinati a tempo di esecuzione.
Livello Applicazione
Livello Presentazione
Stub
Skeleton

Skeleton: Elemento che riceve le invocazioni all’oggetto remoto e le realizza
comunicando col server
Livello Sessione
Remote Reference
Layer

TL: Localizza il server RMI relativo all’oggetto remoto richiesto, gestisce le
connessioni (coi timeout) e le trasmissioni (sequenziali, serializzate)
Livelllo Trasporto
TCP
Livello Rete
Livello Data Link
Livello Fisico
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.73



Serializzazione
Ogni volta che viene creato un riferimento ad un oggetto remoto il relativo contatore
viene incrementato. Per la prima occorrenza viene inviato un messaggio che avverte
il server
Il sistema RMI utilizza un algoritmo di garbage collection basato sul conteggio dei
riferimenti

Ogni JVM aggiorna una serie di contatori ciascuno associato ad un determinato
oggetto

Ogni contatore rappresenta il numero dei riferimenti ad un certo oggetto che in quel
momento sono attivi su una JVM
IP
Interfaccia hw
Rete Fisica
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Garbage collection di oggetti remoti

Applicazione
17:05
SD.5b.74
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
1/4
17:05
Serializzazione

Meccanismo alla base delle trasmissioni di dati fra client e server in RMI

E’ la trasformazione automatica di oggetti e strutture di oggetti in semplici sequenze
di byte, da immettere in uno stream (StreamObject)

Quando nessun client ha più riferimenti ad un oggetto, il runtime di RMI utilizza un
“weak reference” per indirizzarlo
Il weak reference è usato nel garbage collector per eliminare l’oggetto nel momento
in cui anche dei riferimenti locali non sono più presenti
SD.5b.75
2/4
Esempio di serializzazione:
Record record = new Record();
FileOutputStream fos = new FileOutputStream(“data.ser”);
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(record);

Esempio di de-serializzazione:
FileOutputStream fis = new FileOutputStream(“data.ser”);
ObjectOutputStream ois = new ObjectOutputStream(fis);
record = (record)ois.readObject();
ois.close();
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.76
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.77
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.78
13
Serializzazione

3/4
Serializzazione
Si possono serializzare soltanto istanze di oggetti serializzabili, ovvero che:

 Implementano l’interfaccia Serializable
 Contengono esclusivamente oggetti serializzabili

4/4
RMI in pratica
Non viene trasferito l’oggetto vero e proprio ma solo le informazioni che ne
caratterizzano l’istanza (non metodi, nè costanti, nè variabili static, nè variabili
transient)

 estenda la java.rmi.Remote

private String firstName;
private String lastName;
 Estendere java.rmi.UnicastRemoteObject


S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
RMI in pratica
 propaghi la java.rmi.RemoteException
Al momento della deserializzazione sarà ricreata una copia dell’istanza “trasmessa”
usando il .class (che deve quindi essere accessibile) dell’oggetto e le informazioni
ricevute
private in phone;
... };
SD.5b.79
Download del codice da remoto
 Creando un’associazione nome logico-oggetto remoto e memorizzandola nel registro
rmiregistry
(con java.rmi.Naming.bind)
 Attivando l’applicazione che gestisce tale archivio (rmiregistry)



Compilare le classi (con javac) e generare stub e skeleton (con rmic)
Con l’interfaccia Externalizable la trasformazione deve essere implementata
direttamente dal programmatore riferendo i metodi readExternal e writeExternal
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
2/2
Rendere le classi accessibili in remoto:
 Il server deve rendere noto il possesso di un oggetto abilitato all’invocazione
remota
17:05
SD.5b.80
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
1/2
Download del codice da remoto
Per deserializzare un oggetto ed instanziarlo è necessario accedere al suo codice
=> il client che riceve lo stub deve poter accedere anche ai .class
problemi
 localizzare il server da cui scaricare il codice
 effettuare il download
 eseguire in modo sicuro il codice scaricato
 Il client deve ottenere il reference all’oggetto remoto
(con java.rmi.Naming.lookup(String url))
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Definire e realizzare i componenti utilizzabili in remoto devono necessariamente:
 Implementare un’interfaccia che
Esempio:
public class Record implements Serializable {

1/2

17:05
SD.5b.81
2/2
Soluzioni
 Informazioni relative a dove reperire il codice memorizzate sul server e passate
al client by need
 Esempio: java -Djava.rmi.server.codebase
= http://nome_host:port/rmi/NomeApplicaz
 Utilizzo di RMIClassLoader
 Utilizzo di RMISecurityManager
17:05
SD.5b.82
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.83
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.84
14
Marshalling
Rappresentazione dei dati
Problema della rappresentazione esterna dei dati
Mapping delle strutture dati nei messaggi
Destinatario
Messaggi
informazione
sequenziale
Strutture dati
valori
strutture dati
es. serializzazione oggetti JAVA
dati
esterni
trasformazione
dati
locali
17:05
SD.5b.85
16–19
20-23
24–27
5
"Smit"
"h___"
6
"Lond"
"on__"
1934
rappresentazione dati comuni in CORBA
utilizzabile da vari linguaggi
17:05
Rappresentazione
length (unsigned long) fo ll owed by elements in order
length (unsigned long) fo ll owed by characters in order (can also
can have wide characters)
array elements in order (no length specified because it is fi xed)
in the order of declaration of the components
unsigned l ong (the val ues are specified by the order declared)
type tag followed by the selected member
arra y
stru ct
enumerated
union
SD.5b.86
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
JAVA RMI
CORBA - messaggi CDR
Es. struct con tre campi {‘Smith’, ‘London’, 1934}
0–3
4–7
8–11
12–15
Tipo
sequence
stri ng
Usare il formato ‘dati esterni’
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
Esempi
4 bytes
e composti
Rappresentazione di
dati
esterni
Si può operare - direttamente al mittente e destinatario
- automaticamente alla specifica dei tipi di dati da trasmettere
(tramite una notazione ad hoc)
Trasformazione - in forma binaria, testuale,...
Due approcci - si usa una codifica comune (formato dati esterni) concordato
- si invia il formato insieme ai dati
index in
sequence of bytes
15 tipi primitivi: short, long, unsigned short, unsigned long, float, double, char,
boolean, octect,…
compito del middleware
Diversi tipi - diverse codifiche
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
marshalling
unmarshalling
Appiattire le strutture dati
trasformazione
Common Data Representation, rappresentazione di dati esterni in CORBA
Marshalling - assemblare un insieme di dati in forma utile per la trasmissione in un
messaggio
Unmarshalling - disassemblare
Mittente
strutture dati
CORBA - CDR
Rappresentazione dei dati esterni
17:05
SD.5b.87
Esempio: serializzazione di formati Java
Java Remote Method Invocation
notes
on representation
length of string
dati e primitive passati come argomenti e risultati di una invocazione di un metodo
Person
8-byte version number
Formato di serializzazione con le informazioni utili per la classe
I riferimenti ad altri oggetti contenuti in un oggetto sono serializzati in handles
h0
class name, version number
3
int year
java.lang.String
name:
java.lang.String
place:
number, type and name of
instance variables
1934
5 Smith
6 London
h1
values of instance variables
Deserializzazione per ristrutturare gli oggetti (senza ulteriori informazioni)
length of string
‘London’
Explanation
Serialized values
classi -> istanze (oggetti)
Una classe che implementa l’nterfaccia
Serializable
permette la serializzazione degli oggetti (appiattimento delle strutture)
‘Smith’
I formati serializzati contengono anche altre marche addizionali di tipi
h0 e h1 sono handles
unsigned long
ES. Standard XDR SUN sviluppato per Sun NFS
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.88
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.89
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.90
15
Rappresentazione di un riferimento ad oggetto remoto
Invocazione ad oggetti remoti
Comunicazione cliente-servente
Identificare l’oggetto remoto -> remote object reference
identificatore unico di un oggetto remoto
unicità spazio-temporale
32 bits
Internet address
32 bits
port number
32 bits
time
32 bits
object number
interface of
remote object
Problemi di rilocazione di oggetti
S. Balsamo - 2008 - U niversità C a’ Foscari di Venezia
17:05
SD.5b.91
16