Nessun titolo diapositiva
Download
Report
Transcript Nessun titolo diapositiva
Sistemi Distribuiti
Massimo Ancona
SD 1:
Processi e Thread
Un processo (task/job) e’ un’istanza di un
programma attivo su un processore.
Su un sistema multiprocessore o su un computer
network si hanno più processi attivi
simultaneamente: in questo caso si dice che si ha
multiprocessing o parallel processing.
Su un sistema monorocessore solo un processo può
essere in esecuzione (attivo) in ogni istante.
Tuttavia il sistema operativo può mantenere più
processi “attivi” simultaneamente passando il
controllo a turno a ciascuno di essi: in questo caso
si parla di multitasking.
SD 2:
Processi e Thread (cont.)
Si parla inoltre di single-user multitasking
quando più processi collaborano all’esecuzione
di un singolo programma.
Vi sono versioni di Unix che non possono eseguire
I/O asincroni: in questo caso, per sovrapporre
operazioni di I/O con l’elaborazione si costruisce un
programma formato da più processi in esecuzione
simultanea - quando un processo si blocca su una
read gli altri possono proseguire l’elaborazione.
SD 3:
Processi e Thread (cont.)
Questo metodo ha i seguenti difetti:
su piccoli sistemi si penalizza l’occupazione
di memoria.
Il costo del context-switching è elevato.
Lo scambio di dati tra processi è costoso
SD 4:
Processi e Thread (cont.)
Per questo si sono introdotti i thread detti
anche processi lightweight che:
Sono schedulati in modo indipendente come i
processi.
Condividono lo stesso spazio virtuale.
Il context-switching è più efficiente.
ogni thread ha un program counter, registri e stack
propri, ogni altro dato è condiviso
SD 5:
Process Scheduling
Non-preemptive: il processo continua
l’esecuzione finché non lascia spontaneamente
l’uso del processore
preemptive: il processo può essere interrotto al
completamento di una singola istruzione
macchina
Nei thread il problema è più critico: se un thread
viene interrotto durante l’aggiornamento di una
struttura condivisa può lasciarla in uno stato
inconsistente
SD 6:
Processi e thread (cont.)
Più precisamente un processo è composto da
un programma eseguibile
un address space privato (insieme di pagine
virtuali)
risorse di sistema: semafori, porte di
comunicazione, file.. che gli vengono
allocate dal sistema operativo
almeno un thread di esecuzione
SD 7:
Processi e thread (cont.)
Mentre un thread è composto da
un unico ID (client ID)
un insieme di registri macchina
una o più stack (in Windows NT ad esempio una per
eseguire in kernel mode e una in user mode)
un’eventuale memoria privata in uso a sottosistemi
quali run-time library e dynamic-link library (DLL)
SD 8:
Processi e thread (cont.)
Spazio di indirizzamento di un processo
con meccanismi di virtual memory i processi hanno
una visione logica della memoria che non risponde
al layout fisico
ogni accesso viene tradotto in un indirizzo fisico
inibendo l’accesso alla memoria virtuale di altri
processi
per eseguire codice del sistema operativo o
accedere alla sua memoria un thread deve eseguire
in kernel mode. La maggior parte dei processi
esegue in modo ristretto (user mode)
SD 9:
Processi e thread (cont.)
SD 10:
Concorrenza e distribuzione
11
Il termine Concorrenza denota la proprieta’ di un
sistema di svolgere piu’ attivita’ simultaneamente
(almeno in apparenza).
Vi sono tre tipi di concorrenza:
concorrenza apparente, tipica di un ambiente multiprogrammato (OS). L’utilizzo di un solo processore
impedisce un’esecuzione realmente concorrente
Concorrenza reale (o effettiva) in sistemi multiprocessore fortemente accoppiati (sistemi paralleli).
Concorrenza reale (o effettiva) in sistemi distribuiti
debolmente accoppiati - argomento principale di
questo corso.
SD 11:
20 luglio 2015
SD
Sistemi Software Concorrenti
12
Vi sono tre dimensioni della concorrenza:
Scheduling - riguarda come e quando i tasks
concorrenti possono fare uso di risorse di sistema
condivise, es. CPU, I/O e memoria.
Sinchronizzazione - gestisce l’ordinamento relativo
degli eventi tra i threads di controllo del sistema. In
generale, quando una risorsa o oggetto e’ condiviso, l’
alternarsi (interleaving) di accesso ad essa puo’
portare a risultati imprevedibili (non determinismo).
Communication - i processi (thread) si sincronizzano
per scambiare informazioni tramite tecniche quali:
shared memory, message passing, remote procedure
call, rendezvous.
20 luglio 2015
SD 12:
SD
13
Systemi Distribuiti versus Sistemi Paralleli
La comunicazione e’ piu’ costosa tra processi
distribuiti che tra processi paralleli al punto da far
escludere meccanismi di memoria condivisa simulata.
L’ hardware nei sistemi distribuiti e’ in generale fault
tolerant. La rete puo’ partizionarsi, alcuni nodi di
elaborazione possono fallire, ma un algoritmo
distribuito puo’ ancora terminare con successo. Si noti
che questa possibilita’ di grande affidabilita’ e’ solo
potenziale: motivi di costo e di difficolta’ di
coordinamento tra i processi possono vanificare
queste potenzialita’.
SD 13:
20 luglio 2015
SD
Determinismo non determinismo
14
Determinismo: produrre un’output predicibile.
I programmi deterministici si diramano su condizioni
assolute. Il determinismo applica istruzioni logiche per
confrontare variabili e condizioni onde controllare il
flusso di un programma e produrre i risultati richiesti.
Ogni esecuzione a partire dalle stesse condizioni iniziali
produce sempre gli stessi risultati.
Non determinismo: i risultati non sono predicibili, diverse
esecuzioni con gli stessi input possono produrre
risultati diversi.
Piu’ un programma e’ data driven meno i sui risultati sono
predicibili (prevedibili). Questo comportamento viene
detto non deterministico.
SD 14:
20 luglio 2015
SD
Determinismo non determinismo
15
process IncDecN is
N : INTEGER := 0;
thread INCREMENT;
begin
N := N + 1;
end INCREMENT;
thread DECREMENT;
begin
N := N - 1;
end DECREMENT;
begin
null;
end SHARED_DATA;
SD 15:
20 luglio 2015
SD
Determinismo non determinismo
16
Questo codice esegue i task increment e
decrement concorrentemente. Le operazioni di
addizione e sottrazione sono di solito
implementate da tre istruzioni in codice
macchina una load, una inc o dec per sommare
o sottrarre 1, e una store. Una
implementazione su un singolo processore
puo’ “interleave” queste operazioni in diversi
modi concorrenti :
N vale, al termine delle tre possibili esecuzioni
riportate nella tavola, -1, 0 ed 1; risultati
chiaramente inaccettabili.
SD 16:
20 luglio 2015
SD
Determinismo non determinismo
lod n
lod n
lod n
inc
17
lod n
inc
lod n
sto n
dec
dec
lod n
sto n
dec
sto n
sto n
inc
Diverse sequenze di esecuzioni diversi risultati
sto n
20 luglio 2015
SD
sto n
SD 17:
Systemi Software Concorrenti
18
I sistemi software sono costituiti da Componenti
che reagiscono a richieste esterne di servizio
Teoricamante ogni componente è in grado di
servire più richieste concorrentemente
La concorrenza può essere vista in modi diversi
Competitive: le richieste concorrenti
competono su una risorsa per la propria
esecuzione
Cooperative: esse collaborano per soddisfare
una singola richiesta di livello più alto
SD 18:
20 luglio 2015
SD
19
Sistemi Software Concorrenti
Competitive concurrency: mantiene l’illusione
del time sharing permettendo che una singola
richiesta di servizio resti invisibile ad altre
richieste non correlate e simultaneamente
attive. Si verifica quando una componente può
eseguire due o più servizi indipendenti e
generati all’esterno della componente stessa
SD 19:
20 luglio 2015
SD
20
Systemi Software Concorrenti
Cooperative concurrency: aumenta le
performance nel soddisfare una richiesta
o semplifica il coordinamento di più
eventi che concorrono al completamento
della stessa. Opera all’interno di una
stessa componente e riduce la latenza
della richiesta stessa
SD 20:
20 luglio 2015
SD
21
Systemi Software Concorrenti
Internal concurrency: la concorrenza
controllata esplicitamente da una
singola componente
External concurrency: ogni altro tipo di
concorrenza
SD 21:
20 luglio 2015
SD
22
Software Architecture
“The structure of the components of a program/
system, their interrelationships, and principles
and guidelines governing their design and
evolution over time [D. Garlan D. E. Perry]”
E’ composta da
“a shared repertory of methods, techniques,
patterns and idioms for structuring complex
software systems”
SD 22:
20 luglio 2015
SD
Struttura dei sistemi distribuiti
Un sistema distribuito (SD) è un insieme integrato di
Hardware, composto da
processori
una struttura di rete
Software, costituito da
componenti operanti sui processori e comunicanti
tramite la rete
SD 23:
Categorie di Sistemi Distribuiti
Client-server
Cooperative processing
Peer-to-peer
Messaging model
Distributed database
Object-based
Object-oriented
Group communication
SD 24:
Modello Client-Server
Interazione asimmetrica tra due processi
Il processo client invia una richiesta di servizio al server che
esegue il servizio e restituisce un risultato
Il flusso di controllo è usualmente sincrono
La logica di comunicazione è half-duplex: dal client al server e
viceversa
Non è escluso che client e server possano scambiarsi i ruoli
Variante: function shipping i processi si scambiano anche
codice
SD 25:
Modello Client-Server
20 luglio 2015
SD
26
Modelli Client-Server Complessi
20 luglio 2015
SD
27
Modelli Client-Server Complessi
20 luglio 2015
SD
28
Cooperative processing
E’ un tipo particolare di client-server
Il client implementa un’interfaccia verso un
utente. Esempio tipico una Graphical User
Interface (GUI) quali Xwindow (X11) di
Unix
SD 29:
Modello Peer-to-peer
Concetto in uso da molti anni con diversi
significati. Noi lo usiamo come alternativa
a client-server
Interazione piu’ o meno simmetrica tra due
processi che non svolgono ruoli fissi
SD 30:
Modello Peer-to-peer
20 luglio 2015
SD
31
Messaging model
I processi si scambiano messaggi tramite
code di tipo FIFO (first-in-first-out).
Il numero dei processi che possono accedere alla
stessa coda non è fissato
Si considerano code infinite: la scrittura ha sempre
successo, la lettura è bloccante
E’ difficile correlare le richieste con le risposte
Esempio tipico: produttore(i)-consumatore(i)
SD
SD32:
32:
Distributed Database
Diverse parti di insiemi di dati risiedono
su processori diversi.
La gestione avviene in modo completamente
trasparente per l’utente come se il database
risiedesse su un singolo nodo.
Ha i seguenti problemi:
Integrità dei dati
sincronizzazione degli accessi
transazioni e query generalizzate
SD 33:
Modello Object-based
Ogni risorsa condivisa è vista come un
oggetto.
Gli oggetti sono identificati in modo unico (object
ID).
Gli oggetti possono essere spostati nella rete senza
cambiarne l’object ID.
SD 34:
Modello Object-oriented
Ogni entità in esecuzione è un oggetto.
Gli oggetti sono dotati di un’interfaccia messagehandling.
L’accesso alle operazioni fornite dall’oggetto è
filtrata dalla sua interfaccia.
SD 35:
Modello Group-communication
I processi interagiscono con scambio di messaggi ma il
ricevitore non è un processo ma un gruppo di processi.
Ogni operazione send al gruppo si mutua in una receive
per ogni processo del gruppo.
L’invio di un messaggio ai membri di un gruppo è detto
multicasting. Applicazioni:
fault-tolerance: server identici (gruppo) eseguono la
stessa operazione
aggiornamento multiplo: esempio sincronizzazione di
clock
SD 36:
Modello client-server cont.
La limitazione principale di questo modello è l’intrinseca
focalizzazione su “clienti che richiedono singoli servizi”.
Piccole applicazioni client/server sono utili per gestire
semplici servizi distinti - esempi: file print o accesso a
database centralizzato.
Per questo si estende il modello ad interazioni
supportate da server multipli in un’interazione unomolti:
come richiedere servizi multipli
come gestire tali servizi
come smistare le risposte ai clienti
SD 37:
Modello client-server cont.
Le richieste per servizi multipli sono gestibili o
esplicitamente o implicitamente.
nel primo caso il client emette una richiesta per ogni servizio
nel secondo caso il cliente emette una singola richiesta: il server
è complesso ed interagisce con altri server per eseguire la
richiesta del client. Ad esempio un database eterogeneo può:
mappare una richiesta ad alto livello in subqueries a
database distinti sul network
applicare un join relazionale per immergere le risposte
restituire al client il data set costruito
SD 38:
Modello client-server (cont.)
Il comportamento del client o di un server complesso nel ricevere
risposte dipende dal modello di comunicazione sottostante
Le comunicazioni possono essere bloccanti, non bloccanti
nel secondo caso il guadagno in velocità è compromesso dalla
complessità della gestione per richiedere servizi multipli
Strumenti di supporto all’implementazione di modelli client/server
complessi sono:
i meccanismi RPC (Remote Procedure Call) e LPC (local PC)
API di messaging systems per posting di messaggi a bounded queues
SD 39:
Modello client-server (cont.)
I sistemi di messaging aumentano il numero di istruzioni di controllo
all’interno delle applicazioni. Il problema è controllabile con l’ uso
di oggetti attivi detti agenti con lo scopo di
mediare le interazioni tra le applicazioni ed il communication
kernel
eseguire task di controllo distribuito specifici dell’ applicazione
In questo senso gli agenti svolgono un ruolo analogo agli stub RPC
le API di messaging implementano primitive per comunicazioni
blocking o non-blocking
vengono supportati entrambi i meccanismi di polling e di callback
SD 40:
Ancora sul modello client-server
Gli agenti si interfacciano sia con l’applicazione che
con il system layer di messaging, ma ne restano
distinti.
Ne segue che gli agenti possono supportare
svariati modelli di coordinamento distribuito
restando indipendenti dalle applicazioni
possono assumere i ruoli sia del client che del
server.
SD 41:
Service Request Manager
Un broker (o request broker) è un meccanismo di
controllo dedicato che media le interazioni tra le
applicazioni client e i server in grado di fornirle.
I broker liberano le applicazioni dalla necessità di mantenere
informazioni su dove o come ottenere certi servizi. Essi sono
realizzabili con tre modelli
Forwarding Broker smista una richiesta all’opportuna applicazione
server, ottiene la risposta e la gira al client (es. CORBA)
Handle-driven broker restituisce al client un service handle che
contiene le informazioni che il client usa per interagire con il server
Hybrid broker che supporta entrambi i modelli dinamicamente
SD 42:
Terminologia
Naming: un processo usa un nome per accedere ad una
risorsa non sua. Il termine identificatore viene usato
esclusivamente per programmi il termine nome anche
per utenti
Reliability: misura della possibilità di deviare dal
comportamento voluto
Fault-tolerance: la capacità di un sistema di fallire in modo
indolore o mascherare il guasto in modo trasparente all’utente
Marshalling: il meccanismo di conversione di un insieme di
dati in forma di messaggio da trasmettere.
SD 43:
Terminologia
Unreliable message: un invio di un messaggio senza
richiesta di acknowledgment (ack) o retry.
Delivery failure: “mancanza di recapito” - si fanno le
seguenti assunzioni:
I messaggi vengono eliminati dai server o dai gateway di rete
La rete può disconnettersi (partizionarsi)
Delivery sicuro: i messaggi vengono filtrati da metodi di
correzione dell’errore e/o ritrasmissione.
SD 44:
Mobile Communication Networks
Una rete (network) è formata da nodi e connessioni
(link). I nodi sono di due tipi:
endpoints o (hosts/ terminals) che operano come sorgente/
destinazione di traffico
switch (router/ access point/ base station) che hanno la funzione di
smistare il traffico
Un network è detto mobile se cui alcuni nodi (endpoint
e switch) cambiano ubicazione relativa nel tempo
durante il funzionamento
SD 45:
Mobile Communication Networks
Un routing system è un insieme di componenti atte a
monitorare la topologia della rete (network) e i servizi
distribuire l’informazione necessaria per costruire i percorsi (route)
locazzare gli end-point di una sessione
smistare il traffico in base ai percorsi (route) stabiliti
SD 46:
Mobile Communication Networks
In funzione del grado di mobilità dei suoi componenti
una rete si divide in
Cablata (Wireline) - tutte le componenti sono fisse (rete wired
tradizionale) Es. la LAN del DISI
Cellulare - solo gli end point sono mobili, mentre le switch sono fisse
Satellitare (Satellite network) quando le switch sono satelliti
orbitanti intorno alla terra
Pocket radio (ad hoc) - Sia gli end point che le switch sono mobili
SD 47:
Mobile Communication Networks
Network cellulari
Le switch sono fisse e chiamate anche base station alcune
sono collegate alla rete in modo wired altre in modo wireless
Gli end point sono mobili - solo ripartiti in celle ciascuna associata
ad una base station (una base station può gestire una o più celle).
Questa organizzazione favorisce il riuso delle frequenze di trasmissione
in celle geograficamente distanti
Appartengono a questa categoria le reti telefoniche cellulari
(AMPS, PCS, GSM ) gli standard di telefonia cordless, le WLAN IEEE
802.11
SD 48:
Mobile Communication Networks
Network cellulari - problemi
Le dimensione delle celle i sistemi microcellulari hanno celle con raggio da 50m a 500m e
costituiscono sistemi di massima capacità ma con maggior costo di
handoff
handoff ( o handover) - l’operazione di aggiornamento della
configurazione dovuta al cambiamento di posizione (cella) di un
endpoint. Il cambio di cella è provocato dal cambio posizione,
l’appartenenza a una cella, detto affiliazione, viene formalizzato
mediante un processo di registrazione.
Assegnamento delle celle ai Mobile Switching Centers (MSCs) un MCS è un’entità associata ad una porzione fissata del network
SD 49:
Mobile Communication Networks
Satellite Network
Le switch units sono imbarcate su satelliti orbitanti. I link sono
terra-satellite o inter-satellitari. Hanno problemi simili ai
sistemi cellulari. Sono di due tipi:
un piccolo numero di satelliti in orbita geostazionaria offre una
buona copertura del terreno tali da raggiungere quasi ogni utente
con un singolo hop. Utenti non coperti dallo stesso satellite
iteragiscono su più hop terra-cielo o usando link intersatellitari
Low hearth Orbit (LEO) network composti da molti satelliti (molto
costosi es. Iridium) Benché dotati di topologia dinamica non
richiedono meccanismi di traking a topologia adattativa.
SD 50:
Mobile Communication Networks
Pocket Radio Network
I sistemi di comunicazione militari richiedono tecniche di
networking di tipo adattivo in modo da sopravvivere in
ambienti ostili. Esempi: DARPA PRNET SURAN.
Solo di recente si è visto un interesse per l’uso anche in
applicazioni civili. Questi network vengono chiamati ad hoc
dal comitato dello standard IEEE 802.11 - si chiamano anche i
packet radio network.
La mobilità delle switch porta alcuni problemi di
organizzazione diversi da quelli dei network cellulari
SD 51:
Mobile Communication Networks
Pocket Radio Network cnt.
La necessità di risposte rapide al movimento degli switch
richiede meccanismi organizzativi automatici operanti con
interventi manuali minimi.
Il problema di progetto principale consiste nell’organizzare le
switch in gruppi: problema motivato da
esigenza di controllare il riuso spaziale dei canali (in termini di
frequenza, tempo, spreading code...)
ridurre il tempo di overhead del routing
SD 52:
Mobile Communication Networks
Pocket Radio Network - Tecniche di clustering delle
switch per realizzare il controllo dei canali di
comunicazione
Algoritmi principali
Un primo algoritmo, di tipo distribuito,fa usa clusterheads. Ogni
nodo ha un proprio ID numerico. Il nodo con ID minimo in un certo
intorno viene scelto come clusterhead locale e delegato a
controllare l’accesso al canale
Un secondo algoritmo costruisce cluster senza scegliere un
clusterhead: ogni cluster ha un diametro di al più due hop. I cluster
vengono costruiti iterativamente partendo dal nodo di massimo
grado per formare il primo cluster e iterando il metodo nel parte
restante del network
SD 53:
Mobile Communication Networks
Pocket Radio Network - Tecniche di clustering
gerarchico
Si applica a grandi network (DARPA) per ridurre lo spazio
occupato - infatti la quantità di informazione richiesta è
dell’ordine O(n^2) mentre la capacità del network cresce solo
linearmente con n.
SD 54:
Mobile Communication Networks
Location tracking
Ogni network deve avere informazioni sulla posizione corrente
di ogni endpoint. Lo scopo è quello di smistare il traffico di
comunicazione ai destinatari interessati: il problema è detto
location tracking o mobility tracking o mobility management
Di solito si mantengono due informazioni distinte l’ID di un
endpoint e il suo indirizzo (che specifica dove è situato).
Molti meccanismi per il tracking della locazione si basano su
un mapping, dipendente dal tempo, dell’ID sull’indirizzo
attuale di ogni endpoint
SD 55:
Mobile Communication Networks
Location tracking cont.
Molti metodi sono simili ad aggiornamenti/ interrogazioni
applicate a un database distribuito (detto location database).
Il problema si divide in due sotto-problemi:
stabilire quando e come cambiare una entry nel database
organizzare e mantenere il database stesso
SD 56:
Mobile Communication Networks
Updating the location database
Essendo la mobilità all’interno di di una cella trasparente al
network - l’operazione è necessaria solo quando un endpoint
cambia cella. Si effettuano due operazioni
updating (detta registration) l’azione con cui un endpoint mobile
inizia un cambio di locazione;
finding (detta paging) l’azione di attivazione di una ricerca di un
endpoint
molti metodi usano una combinazione di entrambi - ad esempio gli
update non vengono attivati ad ogni cambio di cella ma secondo
una strategia predefinita
SD 57:
Mobile Communication Networks
Updating the location database: static strategies
In questo caso vi è un insieme di celle predefinito in cui
avviene l’aggiornamento. Quando un endpoint entra in una di
queste celle si può attivare un aggiornamento (non necessariamente ogni volta). Vi sono due metodi:
Location areas (o paging o registration areas) L’area di servizio è
ripartita in gruppi di celle, ciascuno gruppo forma una a location
area: la posizione di un endpoint è aggiornata solo quando esso
cambia location area; usato da sistemi cellulari di seconda
generazione (GSM, IS-41);
Reporting cells (o reporting centers); in questo metodo un sottoinsieme di celle da cui poter aggiornare la posizione di un endpoint
viene definito staticamente. La ricerca di un endpoint si effettua
nelle vicinanze dalla reporting cell da cui è stato attivato
l’aggiornamento più recente (ultimo indirizzo conosciuto)
SD 58:
Mobile Communication Networks
Updating the location database: dynamic strategies
In questo caso è un endpoint a decidere quando aggiornare il
database in base al proprio stato di movimento
tale aggiornamento è eseguibile da una cella arbitraria.
In prima approssimazione si tende ad estendere le strategie
statiche aggiungendo informazioni “che rappresentano il
movimento”.
SD 59:
Mobile Communication Networks
Organizzazione del location database
Si vogliono ottimizzare:
la quantità di memoria usata
il numero di messaggi necessari.
Sono due criteri contrastanti per cui si segue un compromesso
tra essi e si tiene conto anche della semplicità di
implementazione
SD 60:
Mobile Communication Networks
Organizzazione del location database cont.
Il sistema più pratico usa un approccio centralizzato
memorizzando tutti gli abbinamenti ID-to-address in un unico
nodo centrale:
Il metodo diviene rapidamente inutilizzabile al crescere del
numero di endpoint. Il metodo non è fault-tolerant per la
mancanza di replicazione
Si preferisce quindi distribuire il database nel network
SD 61:
Mobile Communication Networks
Organizzazione del location database cont.
Il metodo consiste nel partizionare il network e allocare una
parte del database in ciascuna partizione
Il metodo è particolarmente adatto ai casi in cui ogni utente è
registrato in un’area specifica detta home. Quando un
endpoint si sposta si aggiorna il relativo home database per
riflettere il cambiamento
SD 62:
Mobile Communication Networks
Organizzazione del location database - esempi
Nei network PCS si usano due registri:
Home Location Register (HLR)
Visitor Location Register (VLR)
Un metodo analogo viene usato nel Mobile IP scheme e nel
Cellular Digital Packet Data (CDPD)
I Metodi gerarchici adatti a problemi di grande dimensione
hanno successo anche in questo caso
SD 63:
Mobile Communication Networks
Location tracking nei PCS
Nei network PCS si hanno due standard:
Nord-americano IS-41
Europeo standard GSM
Entrambi usano partizionare l’area di servizio in location
area e si basano su una gerachia a due livelli
ogni utente ha una entry nel HLR
quando si muove ottiene un record temporaneo nel VLR
che invia un messaggio di registrazione al HLR
SD 64:
Mobile Communication Networks
Location tracking in Internet
E’ stato introdotto lo standard Mobile IP
Ogni endpoint mobile ha un indirizzo IP permanente su un
home network su cui ha anche un home agent che opera
come gestore di mobilità e che gestisce l’indirizzo corrente
(care-of address) del nodo mobile
Quando l’ endpoint si muove usa un un indirizzo
temporaneo di smistamento (care-of address) nel network
“straniero” abbinato ad un foreign agent nel network
visitato presso cui l’ endpoint si registra. Il care-of address
non è altro che l’ IP del foreign agent.
SD 65:
Mobile Communication Networks
Location tracking nei Pocket Radio Network
Se il network è flat tutti i nodi sono visibili tra loro e non
occorrono meccanismi di location tracking. Essendo non
scalabili essi richiedono forme di clusterizzazione
ogni nodo ha un indirizzo gerarchico formato dagli ID dei
cluster incapsulati che lo contengono
Vi sono Address Server (AS) in ogni cluster di livello zero
che gestiscono gli indirizzi gerachici usati per il routing.
Quando un nodo vuole comm. con un altro nodo interroga
AS del priprio cluster che può a sua volta rivolgersi ad altri
AS
SD 66:
Mobile Communication Networks
Route selection and forwarding
Sono tecniche che richiedono informazioni dettagliate su
Stato corrente del network (interconnettività dei nodi e
qualità dei link)
la sessione (cioè rate di traffico, locazione degli endpoint..)
Questo allo scopo di di dirigere il traffico lungo cammini
consistenti con il servizio richiesto e le restrizioni
imposte dal network
si possono avere rerouting di traffico molto frequenti
SD 67:
Mobile Communication Networks
Route selection and forwarding cont.
Come nei network wired, il tipo di route selection e le
procedure di smistamento dipendono dalla tecnologia di
switching sottostante
Circuit-based
Packet based
In parte dipende anche dalla mobilità delle switch
SD 68:
Mobile Communication Networks
Route selection and forwarding cont.
In molti network cellulari le route vengono calcolate off-line e
le chiamate vengono smistate tramite circuiti impostati lungo
tali route
le procedure di handoff permettono ad una call di continuare
anche quando un endpoint si sposta da una cella all’altra
In molti packet radio network le route vengono calcolate dalle
switch stesse e il traffico viene smistato hop-by-hop ad ogni
switch lungo una route. Le switch modificano le route in base
a mutamenti percepiti nel network
SD 69:
Mobile Communication Networks
Route selection: infrastruttura stazionaria
Il network può essere wireline o wireless - esso connette un
insieme di base station con interfacce radio tramite le quali gli
endpoint accedono al network
network cellulari i telecomunicazione
network ATM
inter-network con endpoint mobili
Il moto degli endpoint attiva modifiche nel routing, ma le
modifiche vengono calcolate nella infrastruttura statica
SD 70:
Mobile Communication Networks
Route selection: network cellulari (CTN)
IS-41 e GSM hanno un comportamento simili: quando un
endpoint migra (roams) in un’area di servizio esterna alla
propria home, la sua posizione corrente nell’ HLR deve essere
aggiornata affinché esso continui a ricevere chiamate
Un MSC viene informato di ciò mediante una richiesta di
registrazione
lo MSC notifica il VLR che a sua volta notifica l’ HLR della
nuova locazione dell’ endpoint
SD 71:
Mobile Communication Networks
Route selection: network cellulari (CTN)
quando un endpoint x vuole comunicare con un endpoint
y la call e’ smistata tramite il network fisso a un MSC
nell’area home di y. L’ MSC consulta l’ HLR di y e scopre
la locazione del VLR di y estendendo quindi la call setup
ad esso
nel caso che la base station corrente di y sia sconosciuta
il VLR inizia l’operazione di paging tramite un MSC locale
che effettua un broadcast della pagina a tutte la base
station dell’area. La base station interessata risponde e
l’MSC può completare l’instaurazione della call
SD 72:
Mobile Communication Networks
Route selection: network cellulari - handoff
quando y si muove cambiando base station deve
affiliarsi rapidamente con una nuova base station
(handoff). Vi sono 4 tipi di handoff
Mobile-controlled
Network-controlled
Mobile-assisted
Soft
SD 73:
Mobile Communication Networks
Mobile-controlled handoff
Gli endpoint mobili monitorizzano costantemente la
qualità del segnale della base station e di quelle vicine e
scegliendo come nuova base station quella che offre il
segnale migliore (usando isteresi)
Network-controlled handoff
è la base station a controllare la qualità del segnale degli
endpoint. Quando esso scende sotto una certa soglia la
base station invia una richiesta di handoff al MSC che
chiede alle base station vicine di monitorare il segnale
dell’endpoint e scegliendone una nuova tra quelle con
buon livello di segnale
SD 74:
Mobile Communication Networks
Mobile-assisted handoff (GSM, IS-41)
Sono la base station a chiedere agli endpoint mobili di
monitorare costantemente la qualità del segnale
ricevuto da un insieme specifico di base station vicine.
Le misure sono inviate alla base station che le smista al
MSC. L’MSC stabilisce quando iniziare un handoff e
quale base station diventerà la nuova base station di un
endpoint.
SD 75:
Mobile Communication Networks
Soft handoff (IS-95 digital CDMA)
Gli endpoint mobili possono affiliarsi simultaneamente a
più base station dotate segnale di equivalente qualità.
In ricezione gli endpoint possono combinare i segnali
ricevuti aumentando la probabilità di una decodifica
positiva.
In trasmissione sono le base station che gestiscono una
call di un endpoint che smistano il traffico da esso
ricevuto estesa con un’informazione di qualità al MSC
che seleziona lo stream di informazione di qualità
migliore.
SD 76:
Implicazioni della Mobilità
Riguardano aspetti generali e nuove prospettive di
utulizzo di cui tener conto nello sviluppo di software.
Tra essi
Ubiquitous Computing
Location Awareness
Application Awareness
Doze mode management e no-connection events
Radio Awareness
SD 77:
Ubiquitous Computing
Prospettato come “terzo paradigma” dopo i mainframe
ed i personal computers.
Può essere visto come l’opposto della realtà virtuale che mette
l’utente a contatto con un mondo virtuale generato a computer
L’ Ubiquitous Computing mette il computer in grado di
operare nel mondo reale, in ogni situazione, all’aperto, in
macchina, in fabbrica ecc.
SD 78:
Location Awareness
Un sistema location-aware è un sistema che
conosce la locazione di ogni unità mobile e che usa
questa informazione per migliorare il proprio
comportamento
Livelli di astrazione
Location Transparent: l’impatto che la mobilità ha sulle
applicazioni è completamente nascosto
Location-Tolerant: astrazione intermedia, che permette
alle applicazioni di reagire a conseguenze della mobilità
che non possono essere filtrate
Location Aware: il livello applicativo stesso conosce la
propria ubicazione ed usa direttamente questa
informazione
SD 79:
Radio Awareness
Si basa sul fatto che il Broadcasting non ha costi
extra in una WLAN ridotta, o ha costi ridotti in
network radio di maggiori dimensioni. Questo fatto
offre la possibilità ad ogni utente di essere sempre
informato su eventi rilevanti del network,
indipendentemente dal posto in cui sta opera
SD 80:
Client-server in Mobile Environments
Mobile Client-server Computing: Paradigmi
Mobile-aware adaptation
Modello client-server esteso
Accesso ai dati in ambiente mobile
SD 81:
Client-server in Mobile Environments
Mobile-aware adaptation
il sistema client-server mobile deve essere in grado di
reagire a cambiamenti rapidi nel network e nelle risorse
locali durante l’ accesso a dati remoti, onde permettere
all’applicazione un funzionamento corretto
Il rango di adattabilità adottabili va da
laisse-faire adaptation : responsabilità dell’applicazione
application-transparent adaptation (del sistema)
application-aware adaptation (intermedia)
SD 82:
Client-server in Mobile Environments
Application transparent adaptation
Usata da molte applicazioni client-server che sono
state sviluppate assumendo che l’ambiente di una
applicazione non cambi (mobility unaware)
Il metodo permette a queste applicazioni di operare
anche in ambienti mobili. Il sistema nasconde le
differenze tra ambiente stazionario ed ambiente
mobile
SD 83:
Application Transparent Adaptation
File system Proxy il fle system proxy nasconde
la mobilità ed emula sui computer mobili i
servizi del file server.
CODA file system: il proxy gestisce il
funzionamento in modo disconnesso mediante
logging delle operazioni eseguite durante la
disconnessione.
SD 84:
Application Transparent Adaptation
File system Proxy (cnt)
Disconnected Operations:
il proxy gestisce il funzionamento in modo
disconnesso operando un logging delle operazioni
effettuate durante la disconnessione
Esse verranno rieseguite al momento della
riconnessione.
Weakly Connected Operations:
il proxy pre-carica (pre-fetches) i dati dal server nella
cache del client ed usa object or volume call-back per
validarne il contenuto. Volume call-back è
pessimistico
SD 85:
Application Transparent Adaptation
File system Proxy (cnt)
Isolation-only Transaction:
Le operazioni eseguite in modo disconnesso possono
portare ad inconsistenze sui dati dovute ad azioni di
più computer operanti sugli stessi dati in modo
disconnesso
la loro esecuzione è realizzata dal file system proxy
che gestisce la consistenza in dipendenza dalle
condizioni di connessione.
Al contrario delle transazioni tradizionali la failure
atomicity non è garantita.
SD 86:
Application Transparent Adaptation
Web Proxy (WebExpress) Vi sono due
componenti tra un Web client e un Web server
The Client Side Intercepr (CSI)
The Server Side Intercepr (SSI)
Insieme eseguono ottimizzazioni per ridurre l’uso di
banda e tempi di latenza
Caching:
sia CSI che SSI operano caching di grafica e oggetti
HTML. Se una URL si riferisce ad un oggetto in cache
esso viene smistato all’istante
la cache di SSI contiene risposte da web server usato.
SD 87:
Application Transparent Adaptation
Web Proxy (cnt)
Differencing:
Il concetto consiste nel caching di oggetti base
comuni sia sul CSI che sul SSI. Al ricevimento di una
risposta il SSI calcola le differenze tra l’oggetto base e
la risposta e manda le differenze al CSI che
ricostruisce per immersione il risultato
Protocol Reduction:
ogni CSI si connette al rispettivo SSI con una singola
connessione TCP/IP eliminando costi di riconnessione
e “multiplexando” richieste/risposte
Header Reduction:
HTTP è stateless: quindi ogni richiesta deve
specificare le capability del browser.
SD 88:
Application Aware Adaptation
permette alle applicazioni di reagire a cambiamenti di
risorse mobili. Si realizza tramite collaborazione tra il
sistema ed ogni applicazione
Si divide in
Client-based Application Adaptation
Client-Server Application Adaptation
Proxy-based Application Adaptation
SD 89:
Application Aware Adaptation
Client-based Application Adaptation
Solo le applicazioni in esecuzione sui clienti mobili
reagiscono a cambiamenti nell’ambiente
Client-Server Application Adaptation
sia le applicazioni sui clienti mobili che quelle sui
server reagiscono a cambiamenti nell’ambiente
Proxy-based Application Adaptation
Supporta adattamenti application-specific che
avvengono solo sul server proxy del network fisso
SD 90:
Extended Client Server Model
Si base sull’esame dell’impatto che la mobilità ha
sul modello client-server (modello client-server
esteso)
La limitazione di risorse computazionali del client può
richiedere di eseguire sul server operazioni
usualmente eseguite sul client
Alternativamente, problemi di connessione possono
richiedere al client di eseguire operazioni usualmente
eseguite dal server
Un caso estremo viene chiamato thin client architecture
l’altro estremo full client architecture
Flexible client architecture
SD 91:
Thin Client Architecture
Il sistema della Citrix corporation
Permette a diverse piattaforme remote di connettersi
ad un terminal server Windows NT.
Un server chiamato Metaframe gira sotto WNT su un
desktop e comunica con i thin client mediante un
protocollo proprietario detto Independent Computing
Architecture protocol (ICA)
Metaframe esegue tutte le operazioni in modo remoto
i client hanno solo la funzione di user interface
SD 92:
Thin Client Architecture
Il sistema della Citrix corporation è stato
sperimentato in ambiente wireless dalla Motorola
Il risultato di questa ricerca ha mostrato che i limiti
di banda non riducono le performance
dell’architettura poiché i clienti fanno un uso
limitato della banda
SD 93:
Full Client Architecture
l clienti mobili spesso si trovano in stato di “weak
connectivity “ a causa di
bassa bandwidth
intermittenza delle comunicazioni e alta latenza
nei casi estremi i clienti devono operare in
disconnected mode
La capacità di operare in modo disconnesso offre
vantaggi anche quando la connessione è disponibile
SD 94:
Full Client Architecture
Il modo disconnesso ha i seguenti vantaggi
risparmio della carica delle batterie
riduzione del carico sulla rete
in applicazioni militari permette il silenzio readio
L’ architettura full client permette di lavorare in
modo disconnesso o debolmente connesso
L’emulazione è eseguibile tramite un lightweight
server risiedente sul client
SD 95:
Flexible Client Architecture
Generalizza entrambe le architetture thin e full
client rilocando dinamicamente i ruoli di client e
server eseguendo l’applicazione su uno o sull’altro
Mobile objects (o mibile agents) sono codice che
viaggia liberamente sul network . Essi permettono di
eseguire le funzionalità richieste sia su host mobili
che stazionari.
Collaborative Groups: formati da un gruppo di user
disconnessi dal resto del network
SD 96:
Flexible Client Architecture
Application specific proxy: intermediario tra tra
clienti e server per eseguire operazioni compute
intensive.
Virtual mobility of servers: si replicano servizi sul
network per migliorare l’ handoff di clienti mobili
SD 97:
Mobile Data Access
Supporta lo smistamento di dati dal server e il
mantenimento della consistenza dei dati in ambienti
mobili e wireless.
L’accesso ai dati mobili è caratterizzabile dal data
delivery mode che può essere di tre tipi:
Server-push delivery
Client-pull delivery
Hybrid delivery
SD 98:
Mobile Data Access
Server data dissemination:
Broadcast disks
Indexing on Air
Client Cache management
Automated hoarding
varied granularity of cache coerence
SD 99:
Mobile Data Access
Server data dissemination (Broadcast disk)
In molte applicazioni (as. Web) il volume di scambio
dati dal server al client è molto maggiore del flusso
contrario.
Inoltre il numero di clienti è molto elevato
La soluzione consiste nell’ uso di broadcasting
Broadcast disk: quando il server smista i dati in
continuazione ai clienti, il canale di broadcast viene
assimilato ad un disco da cui i clienti ottendono i dati.
SD 100:
Mobile Data Access
Server data dissemination (Indexing on Air)
Nel metodo push-based i server periodicamente
smistano i dati più richiesti, in broadcast ai clienti.
Il server può modificare dinamicamente il contenuto
dello hot spot.
Il cliente è lazy (trasmette solo quando necessario).
Gli indici sono strutturati per minimizzare:
Il query time: tempo tra issue-of-a-query e
ricevimento della risposta
Listening time: tempo di ascolto del canale
SD 101:
Mobile Data Access
Client cache management: si basa sul caching di
dati acceduti frequentemente. Permette di gestire
disconnected mode e
intermitted connected mode
la connettività debole rende costoso il
mantenimeno coerente del contenuto della cache
Il termine Hoarding indica tecniche di pre-fetching
dei dati prima della disconnessione.
SD 102:
Mobile Data Access
Automated Hoarding.
Caching sul client prima di disconnessione
Varied granularity of Cache coerence
estensione di metodi client/server tradizionali ad
ambienti mobile
Cache invalidation reports
approccio all’invalidazione della cache basato sulla
dissemination (Barbara & Imielinski). Periodicamente
il server invia un report di invalidazione
SD 103:
Mobile Data Access
Automated Hoarding. I files non locali vengono
‘cached’ sulla cache del client prima della
disconnessione. Vi sono tre tecniche basate sulla
misura della distanza semantica tra i files.
Varied granularity of Cache coerence: estensione di
metodi di consistenza in applicazioni client-server
tradizionali:
callback approach: i server inviano messagi di
invalidation
detection approach: i clent inviano query di validazione
SD 104:
Mobile Data Access
Cache invalidation reports:
Invece di richiedere al server la validazione di copie
cached i clienti si pongono in ascolto di report di
invalidazione in arrivo dai server. Tre metodi
TS - broadcasting Time Stamps
AT - Amnesic Terminals
SIG - SIGnatures
SD 105:
Wireless LAN
Vi sono diverse proposte Standard. Le principali
sono
IEEE-802.11
Bluetooth
Home RF
PAN
SD 106:
Wireless LAN
SD 107:
Lo Standard IEEE 802.11
Lo Spettro Radio
Lo spettro delle radio-frequenze (RF) e` deviso in
due tipi di bande: assegnate e libere.
le prime sone dedicate a grandi organizzazioni,
- le seconde sono sogette a regole ma prive di
restrizioni e tasse
SD 108:
Lo Standard IEEE 802.11
Basato su un metodo che permette un
buon impiego di ampiezze di banda
limitata detto Spread Spectrum (SS) esso garantisce comunicazioni affidabili
anche in ambienti a rumore elevato
SD 109:
Lo Standard IEEE 802.11
Molti network wireless attuali seguono le
specifiche dello standard IEEE 802.11 per reti
WLAN multi-hopping operanti nella banda di
2.4GHz. Lo standard europeo più vicino è lo ETSI
(European Telecomm. Standard Institute)
I metodi di uso uniforme del canale classici:
Time Division Multiple Access (TDMA)
Frequency division Multiple Access (FDMA)
Code Division Multiple Access (CDMA)
non fanno un uso efficiente della bandwidth di
canale poiché richiedono allocazioni on demand
SD 110:
Lo Standard IEEE 802.11
la tecnologia SS permette la massima
data rate su un canale a banda limitata.
Vi sono due tecniche implementative
Frequency Hopping Spread Spectrum (FHSS)
Direct Sequence Spread Spectrum (DSSS)
(chiamata anche Direct-Sequence Modulation DSM)
SD 111:
IEEE 802.11 - FHSS
Il metodo FHSS usa diversi canali di
frequenza
Il trasmettitore invia un segnale su un canale
per un breve periodo, saltando (hopping) poi in
modo pseudo-random, su un altro canale di
frequenza.
Il ricevitore deve seguire la stessa sequenza
pseudo-random ripetendogli stessi salti del
trasmettitore.
SD 112:
IEEE 802.11 - FHSS
Vantaggi:
- non richiede una banda contigua
- semplice ed economico da realizzare
Svantaggi:
- rende l' handower tra celle contigue difficile da
coordinare
SD 113:
IEEE 802.11 - DSSS
Nel metodo DSSS, il trasmettitore sostituisce gli
zeri e gli uno di un segnale digitale in banda base
da trasmettere, con codici di lunghezza fissa,
producendo un allargamento (spread) di banda di
un’opportuna quantita'
Il ricevitore usa lo stesso codice del trasmettitore
e mediante correlazione ricostruisce il segnale
trasmesso.
SD 114:
IEEE 802.11 - DSSS
Vantaggi :
miglior copertura a parita` di potenza irradiata
( piu' del 50% di FHSS)
miglior qualita` del segnale
handower piu' facile
Svantaggi:
richiede una banda contigua
SD 115:
IEEE 802.11 - DSSS
Network Multihop
La configurazione più semplice di un network
wirless è composta da una unità mobile connessa
ad una stazione di supporto a sua volta connessa
ad una rete wired. Questa semplice configurazione
è detta single hop.
La tecnologia multi-hop permette ad una radio di
smistare pacchetti ad altre radio situate sul
percorso verso la loro destinazione.
La tecnologia multi-hopping permette di limitare la
potenza di emissione delle radio limitando il
consumo delle batterie.
SD 116:
IEEE 802.11 - DSSS
Architettura di un Wireless LAN multi hop
Le componenti generiche di una LAN radio sono:
Radio Modules
Access Points
Bridges
Network Adapters
Un network tipico è composto da
access point / repeater
radio node / radio end node
SD 117:
IEEE 802.11 - DSSS
SD 118:
Meccanismi per lo Scambio dei Messaggi
Si usano due pimitive Send e Receive
e una classe message con una struttura del tipo
typedef enum{NONE,TIMEOUT} Errortype;
class Message {
private:
errorType ErrorReport;
public:
class portId{...};
class messagetype {...};
void send(OUT PortId p, OUT Message m);
void Receive(OUT PortId p. IN Message m);
};
SD 119:
Meccanismi per lo Scambio dei Messaggi
Send e Receive possono essere sincrone o
asincrone, nel primo caso sono entrambe
bloccanti, nel secondo Send è non
bloccante, mentre receive può esserlo o
no a seconda delle implementazioni.
Tipo
Send blocc. Receive blocc. Esempio
Sincrono
SI
SI
Occam
Asincrono
NO
SI
Mach
Asincrono
NO
NO
Charlotte
SD 120:
Send e Receive
Una Receive bloccante non ha problemi in
processi multi-thread.
Essa puo’ attewndere all’infinito un
messaggio destinato a non arrivare. Si
ovvia a questi inconvenienti con timeout,
dopo un certo tempo l’operazione subisce
una terminazione forzata.
Delivery failure - del tipo seguente:
SD 121:
Tipi di Delivery Failure
si perdono i messaggi (nei sender,receiver o
gataway)
in network WAN si hanno duplicazioni o
smistamenti fuori ordine e forti ritardi
in network LAN si hanno solo perdite (rare)
la rete si partiziona in sottoreti disconnessesi
un processore puo’ avere un guasto (fail).
Si suppone comunque di non avere data
corruption (correzione di errore).
SD 122:
Azioni in caso di delivery failure
i processi devono fornire meccanismi per
ottenere un grado di affidabilita’
adeguato: ad esempio usare acknowledge
positivi (messaggio ricevuto)
Request-reply protocol: tipico del client-server.
La comunicazione e’ di solito sincrona e il cliente si
blocca fino all’arrivo della risposta.
Un altro metodo si basa su tre primitive (Amoeba,
Chorus, Mach..): DoOperation, GetRequest,
SendReply
SD 123:
OSF/DCE Distributed Computing
Environment
Un insieme di tool software e servizi che
semplificano la programmazione
distribuita
DCE RPC: cuore del sistema facilita lo sviluppo
delle applicazioni per l’alto livello di astrazione.
DCE Directory Service nmeccanismo reliable
per associare nomi alle applicazioni.
DCE Security Service
DCE Distributed time service
DCE Threads
SD 124:
DCE Distributed File Service
RELIABILITY
Il termine unreliable message significa
letteralmente:
“trasmettere un singolo messaggio senza
richiesta di acknowledgement e/o
meccanismi di retry”.
Message Identifier: identificativo unico di un
messaggio. E’ formato da due parti:
requestId generato sequezialmente in modo
crescente
senderId identificativo del processo sender (es.
SD 125:
una porta)
COMUNICAZIONI CLIENT-SERVER
Il protocollo RPC:
Si presenta in tre forme:
request protocol (R) - isi usa quando non e’
richiesto un valore di ritorno (tipo void).
Request-reply protocol (RR) - si richiede un
risultato di ritorno, la risposta del server funge
anche da ack.
request-reply-acknowledge reply (RRA)
protocol - basato su tre messaggi: request reply
ack. Quest’ultimo contiene il reqestId del reply
message da validare
SD 126:
GROUP COMMUNICATION
Si basa sul concetto di Multicast - un messaggio
inviato da un processo ai processi membri di un
gruppo. Utile per:
Fault tolerance basata su servizi replicati: un
gruppo di server che eseguono lo stesso servizio.
Localizzazione di oggetti in servizi distribuiti
Servizi piu’ efficienti
Aggiornamenti multipli
Importante nei sistemi wireless
SD 127:
GROUP COMMUNICATION
Atomicità
Tutti i membri di un gruppo devono ricevere tutti
i request message a loro inviati.
Atomic Multicast: invio di un messaggio che è
ricevuto da tutti i membri del gruppo o da
nessuno.
Reliability
Reliable Multicast: metodo di trasmissione che
cerca di raggiungere tutti i membri del gruppo
senza garanzia di successo.
SD 128:
GROUP COMMUNICATION
Ordering
Riguarda l’ordine di ricevimento dei messaggi da
parte dei membri di un gruppo. Nei multicast
atomico e reliable si usano code FIFO di
ordinamento dei messaggi.
Multicast totalmente ordinato: una serie di
messaggi inviati a un gruppo e che devono
raggiungere i membri del gruppo tutti nello stesso
ordine.
SD 129:
CORBA
Common Object Broker
Architecture
SD 130:
Common Object Request Broker
Architecture (CORBA)
Cos’è CORBA
La specifica di un’architettura Object-Oriented per
applicazioni distribuite
A cosa serve
ad accedere a informazioni distribuite in ambito di
applicazioni desktop
a trasformare programmi e sistemi esistenti in
risorse di rete
SD 131:
Common Object Request Broker
Architecture (CORBA)
CORBA si basa su distributed object
computing.
CORBA rende possibile il riuso di software
tramite elaborazioni ad oggetti distribuite
I due ingredienti essenziali di CORBA
sono quindi
integrazione di un objct-model con distributed
computing
l’uso di un broker - intermediario che smista
messaggi tra client e server
SD 132:
Common Object Request Broker
Architecture (CORBA)
Il broker ha la capacità di
scegliere i server più adatti a soddisfare una
richiesta
separare l’interfaccia (vista dal cliente)
dall’implementazione del server
I principali meccanismi per elaborazioni
distribuite in uso sono
Remote Procedure Call (RPC)
API specifiche di comunicazione per applicazioni in
rete
SD 133:
CORBA (struttura di un’applic.)
SD 134:
CORBA (architettura)
SD 135:
OGGETTI CORBA
Un oggetto Corba ha un’interfaccia scritta in IDL
e ha differenti rappresentazioni sul client e sul
server.
Un server implementa un oggetto in un linguaggio
di programmazione concreto, es. C++ o Java, come
istanza di un’ implementation class:
l’implementazione e’ detta un servant.
Un client intenzionato ad usare un oggetto
implementato da un server crea un oggetto che
delega tutte le operation call al servant tramite l’
ORB. Questo oggetto e’ detto proxy.
SD 136:
OGGETTI CORBA
Quando un client chiama un metodo sul local
proxy object, l’ORB impacchetta i parametri e li
invia al server che spacchetta i parametri e
invoca il metodo sul servant. I parametri di
ritorno e il risultato seguono il cammino a
ritroso.
Un servant e’ connesso all’ORB in modo da
permettergli di invocare il metodo del servant.
La connessione e’ gestita dal POA (Portable
Object Adapter).
SD 137:
OGGETTI CORBA
SD 138:
CORBA Implementazione dei Servant
Ci riferiamo all’esempio IDL seguente
// IDL
interface A
{
void op_a(); };
interface B
{
void op_b(); };
interface I: A, B
{ void op_I(); };
SD 139:
CORBA Implementazione dei Servant
Implementazione mediante inheritance in C++
// C++
2 class A_impl: virtual public POA_A
3 { public: virtual void op_a() throw(CORBA::SystemException); };
4 class B_impl: virtual public POA_B
5 {public: virtual void op_b() throw(CORBA::SystemException); };
6 class I_impl: virtual public POA_I, virtual public A_impl, virtual
public B_impl
7 {public: virtual void op_i() throw(CORBA::SystemException); };
SD 140:
CORBA Implementazione dei Servant
Commenti sull’ implementazione in C++
2-3 definizione della classe A_impl. Essa eredita dalla class
skeleton POA_A. Nel caso in cui a_impl avesse parametri questi
verrebbero mappati secondo le regole di mapping IDL-to-C++;
4-5 idem per B_impl;
6-7 la class I_impl e’ derivata sia da POA_I che da A_impl e
B_impl
E’ obbligatorio l’uso di ereditarieta’ “public virtual”; la keyword
public e’ evitabile solo se I non eredita da altre interfacce, cioe’
se eredita solo da POA_I e nessuna classe implementazione
eredita da I_impl. Infine non e’ necessario avere una classe
implementazione per ogni interfaccia.
SD 141:
CORBA Implementazione dei Servant
Implementazione mediante inheritance in Java
// Java
2 public class I_impl extends IPOA
3{
4 public void op_a() { };
5 public void op_b() { };
6 {public void op_i() { }
};
SD 142:
CORBA Implementazione dei Servant
Il compilatore IDL-to-Java genera parecchi file
tra cui:
I.java, che definisce una interfaccia Java I contenente i metodi
pubblici e gli attributi di I
IPOA.java, scheletro astratto di una classe da usare come base
delle classi del servant
Diversamente dal C++, Java non ha ereditarieta’ multipla il che
impedisce a una servant class di ereditare implementazioni di
operazioni da altre servant class, escluso il caso di usare un’
implementazione basata sulla delegazione. Per questo e’
necessario implementare tutte le operazioni in una sola servant
class I_impl, senza riferimenti al fatto che esse siano definite in
I o in un’interfaccia da cui I e’ derivata.
SD 143:
CORBA Creazione dei Servant
Il metodo e’ identico sia in C++ che in Java:
Creazione dei Servant in C++
//C++
I_impl* servant_pointer = new I_impl;
I_impl* another_servant_pointer = new I_impl;
In C++ i servant vengono creati come oggetti C++ tramite new
Questo non informa Orb della loro esistenza, questo avviene solo
al momento della loro attivazione
Icreazione di servant in Java
//Java
I_impl impl = new I_impl();
I_impl another_impl = new I_impl();
SD 144:
CORBA Attivazione dei Servant
Il metodo e’ identico sia in C++ che in Java:
I servant devono essere attivati prima di ricevere richieste. La
loro attivazione segnala al run-time di ORB tutti i servant che
rappresentano specifici oggetti Corba. Ogni attivazione di
servant gli assegna uno specifico object identifier OID.
Gli OID possono essere assegnati da POA o dal codice della
applicazione server.
I servant possono essere attivati implicitamente o
esplicitamente. L’attivazione implicita avviene quando viene
creata la prima object reference di un servant. L’attivazione
esplicita richiede una call a una API specifica.
SD 145:
CORBA Attivazione dei Servant in C++
Attivazione implicita in C++
//C++
I_impl impl;
I_var iv = impl -> _this();
// creazione
//attivazione chiamando _this
Attivazione esplicita in C++
//C++
I_impl impl;
// istanziazione
PortableServer::POA_var poa = impl._default_POA();
poa -> activate_object;
// crea ID unico
SD 146:
CORBA (Un Esempio)
Hello World
Classico esempio introduttivo qui realizzato in
forma client-server.
Versione C++:
#include <iostream.h>
int main(int, char*[])
cout<< “Hello World!” << endl;
return 0
SD 147:
CORBA (Hello World)
Hello World, versione Java:
public class Greeter
public static void main (String args[])
System.out.println(“Hello World!”);
SD 148:
CORBA (Hello World)
Hello World in Corba
Codice IDL:
interface Hello;
void say_hello();
Un’interfaccia IDL equivale ad una classe astratta in
C++ o ad un’interfaccia Java
SD 149:
CORBA (Hello World)
Hello World in Corba (linguaggio C++)
Si deve prima tradurre il codice IDL in C++ con
il compilatore IDL
idl Hello.idl (comando di attivazione)
questo comando crea quattro files
Hello.h,
Hello.cpp,
Hello_skel.h,
Hello_skel.cpp
Quindi si implementano server e client
SD 150:
CORBA (Hello World)
Hello World in Corba (C++)
Implementazione del server: si crea una classe
implementazione Hello_impl
#include <Hello_skel.h>
class Hello_impl: public POA_Hello;
public PortableServer::RefCountServantBase
public:
virtual void say_hello()
throw(CORBA::SystemException);
;
SD 151:
CORBA (Hello World)
Questa classe eredita dallo skeleton POA_Hello,
quindi si include Hello_skel.h
Hello_impl e’ classe derivata da POA_Hello
Inoltre si devono implementare tutte le
operazioni della interfaccia in IDL (qui solo
say_hello). Hello_impl.cpp e’ quindi:
#include <iostream.h>
#include <OB/CORBA.h>
#include <Hello_impl.h>
void Hello_impl::say_hello()
throw(CORBA::SystemException)
cout<< “Hello World!” << endl;
SD 152:
CORBA (Hello World)
Includiamo OB/CORBA.h che contiene le
definizioni delle classi standard CORBA
Infine includiamo la definizione della classe
Hello_impl
#include <iostream.h>
#include <OB/CORBA.h>
#include <Hello_impl.h>
void Hello_impl::say_hello()
throw(CORBA::SystemException)
cout<< “Hello World!” << endl;
SD 153:
CORBA (Hello World)
Si salvano quindi la class definition in
Hello_impl.h e l’implementazione in
Hello_impl.cpp
Infine si scrive il programma server. Il
trattamento delle eccezioni e’ semplificato e
sdoppiato in due funzioni main() e run().
main() crea l’ ORB e chiama run()
SD 154:
CORBA (Hello World)
#include <OB/CORBA.h>
#include <Hello_impl.h>
#include <fostream.h>
int run(CORBA::ORB_ptr);
int main(int argc,char* argv[])
int status = EXIT_SUCCESS;
CORBA::ORB_init(argc, argv);
status = run(orb);
try
orb -> destroy();
SD 155:
CORBA (Hello World)
La funzione run() (commenti):
un servant di tipo Hello_impl viene creato ed assegnato a
ServantBase_var:
int run(CORBA::ORB_ptr orb)
CORBA::Object_var poaObj=
orb ->resolve_initial_references(“RootPOA”);
PortableServer::POA::_var rootPoa =
PortableServer::POA::_narrow(poaObj);
PortableServer::POAManager_var manager =
rootPoa -> the_POA Manager();
Hello_impl* helloImpl = new Hello_impl();
PortableServer::POA::ServantBase_var servant =
SD 156:
CORBA 3.0
SD 157:
Evoluzione di CORBA
Introdotto nel 1991 come astrazione
per la programmazione di oggetti
distribuiti permette di integrare
applicazioni distinte in un sistema
distribuito ed omogeneo
il cuore di ogni sistema basato su
CORBA è l’ORB (Object Request
Broker).
SD 158:
Da CORBA 1 a CORBA 3
EVOLUZIONE di CORBA
CORBA 2 aggiunge (1995)
lo Standard General Inter-ORB Protocol (GIOP) e
relativa specifica di implementazione sul TCP/IP
L’ Internet Inter-ORB Protocol (IIOP)
CORBA 3 aggiunge (1998)
Il Portable Object Adapter (POA)
CORBA Messaging
Objects By Value
SD 159:
Portable Object Adapter POA
RUOLO di POA
Mediare tra gli Oggetti CORBA (CO) e il mondo
delle implementazioni, nei vari linguaggi di
progr. dette Servants. In particolare
Creare Oggetti CORBA (CO)
Smistare le richieste fatte ai singoli CO
Dispatching delle richieste ai servant che
incarnano o implementano CO target
Attivare disattivare CO
SD 160:
POA - Motivazioni
Fino a CORBA 2.1 il solo standard Object
Adapter definito dall’OMG è stato BOA
BOA fornisce solo servizi di base che
permettono la creazione e
l’implementazione di CO
Molte feature mancavano o erano
definite in modo ambiguo con
conseguente proliferazione di versioni
proprietarie tra loro incompatibili
SD 161:
POA - Basics
POA media tra l’ORB e e le applicazioni
server
SD 162:
POA - Basics 1
Il cliente invia la richiesta (invokes the
request) mediante una Object Reference
(OR) che specifica l’oggetto target
La richiesta è ricevuta dall’ORB del
server
parte di essa contiene un ID detto Object Key
(OK) che identifica univocamente il CO
nell’ambito dell’applicazione server
Essendovi più POA la OK aiuta ORB nel
dispatching verso il POA opportuno.
SD 163:
POA - Basics 2
Il POA usa una parte della OK detta Object ID
(OID) per associare il Target Object e il
servant (livello di linguaggio programmativo)
le associazioni possono essere memorizzate in
una map oppure:
POA può chiamare l’applicazione per provvedere
ad un servant relativo al target object ID, o usarne
uno di default stabilito dall’applicazione stessa
in ogni caso POA smista la richiesta all’appl.
SD 164:
POA - Basics 3
Il POA interagisce principalmente con
tre entità:
Due l’ Object Reference - e l’ Object ID usate
per identificare
La terza il Servant che implementa i CO
Una server Application prima chiede a
POA di creare un nuovo CO - il POA
restitusce una Object Reference che
identifica univoc. Il CO nell’ambito di
tutte le applicazioni server.
SD 165:
POA - Basics 4
All’ atto della creazione di un CO l’ OID
viene fornito dal’applicazione stessa o dal
POA che identifica in modo unico il CO nel
proprio scope
Un Servant è detto Incarnare (o to
provide a body) di un CO. In definitiva la
richiesta per un CO viene eseguita dal suo
Servant . Nel caso di uso di C++ e Java i
Servant sono istanze di classi del
linguaggio.
SD 166:
Oggetti Persistenti e Transienti
Una delle caratteristiche migliori di CORBA
è il meccanismo di attivazione
automatica e trasparente di oggetti. Se
un’ applicazione Client emette una
richiesta ad un Target Object non in
esecuzione o non attivato, CORBA chiede
alle implementazioni di ORB di attivare
un processo server per tale oggetto (se
necessario) e quindi di attivare l’oggetto
stesso.
SD 167:
Oggetti Persistenti e Transienti 2
Ogni attivazione di processo server e di
target object è trasparente ai rispettivi
clienti
Gli Oggetti CORBA che hanno un ciclo di
vita che trascende quello del processo
specifico che li crea o attiva sono detti
persistenti.
E’ anche utile avere oggetti il cui ciclo di
vita è limitato da quello del processo o
dell’ Object Adapter che li crea.
SD 168:
Oggetti Persistenti e Transienti 3
POA supporta due tipi di CO
Persistent objects (nella versione originale)
Transient objects (TCO) il cui ciclo di vita è
limitato da quello del POA in cui viene creato
Gli Oggetti transient richiedono meno
bookkeeoing da parte dell’ORB. Una
volta distrutto il POA che ha creato un
TCO non può più essere riattivato
sempificando le operazioni dell’ORB.SD 169:
POA aspetti ulteriori
POA supporta anche i seguenti
meccanismi
Explicit and on-demand activation
Separation of servant and CORBA object life
cycles
Different policies of multithreading
CORBA multithreading
permette ad un’applicazione server di usare più
thread per servire più richieste
SD 170:
concorrentemente
CORBA & OMA in ETERPRISE COMPUTING
Dopo Corba 2.0 l’OMG si è mosso in
diverse direzioni:
Multiple interfaces per object,
Object passed by value,
Beans-like component model,
Real-time support
Fault-tolerance
Embedded CORBA
SD 171:
USO di IDL
Le imprese operanti nel mercati verticali hanno
iniziato ad usare IDL per descrivere le
specifiche di oggetti standard da usare in
modo pubblico e condiviso. OMG ha ampliato il
proprio scopo con un allargamento di orizzonti
a:
Finanza /Asicurazioni
Commercio Elettronico,
Healthcare,
Manufactoring,
Telecomunicazioni
Trasporti
Life Science & Research
Business Objects
SD 172:
OMG Specification Suite
Come risultato si è avuta un’ampia gamma di
specifiche OMG
SD 173:
ARCHITECTURAL OVERVIEW
L’ architettura OMG offre:
Supporto per analisi e design: UML e MOF
Basic o-o computing model: ORB; OMG/ISO IDL e suo
mapping verso C,C++,Java,Smalltalk,Cobol e Ada
Distribuzione: il protocollo GIOP e il suo mapping
verso TCP/IP e varie forme alternative di messaging e
asynchronous invocation
Component Model: CORBA Components and Scripting;
multiple interfaces; oggetti passati per valore
Modi specializzati: real-time, fault-tolerance,
embedded CORBA
SD 174:
ARCHITECTURAL OVERVIEW (cont)
CORBAservices. Basic services for distributed
object applications: naming and trader
services, event & notification, Object
Transaction Serv. (OTS), Security serv.
Horizontal CORBAfacilities: System
Management, print spooling, etc..
Vertical Market (Domain) CORBAfacilities:
Supporto per l’impresa, oggetti standard per
funzioni standard, condivisibilità ecc.
SD 175:
UML e MOF: Supporting Analysis and Design
Il modeling è il primo passo chiave per costruire
sistemi software di impresa con requisiti
industrial-strength. Questo ha portato l’OMG a
promuovere l’ Unified Modeling Language
(UML)
un linguaggio visuale per lo scambio di modelli
di sviluppo software ben definiti
UML è definito nella guida UML Notation Guide
www.corba.org
SD 176:
CORBA Computing Model
Passaggio di una richiesta da un client ad un object
implementation (vrdi figura):
entrambi client e implementation sono isolati dall’ORB
tramite una OMG/ISO IDL interface.
La richiesta non passa direttamente dal cliente
all’implementazione ma è sempre gestita da ORB
ogni richiesta sia locale che remota ha sempre la stessa
forma
I dettagli per la distribuzione risedono in ORB
SD 177:
CORBA Distribution Model
Il passaggio di una richiesta èda un client ad un object
implementation nel caso distribuito (figura) si basa sulla
comunicazione ORB-to-ORB. IDL supporta la distribuzione in
vari modi. In particolare GIOP (lo Standard general Inter ORB
Protocol) specifica tutti gli aspetti di interoperabilità.
SD 178:
COMPONENT PROGRAMMING
Si basa sullo sviluppo di componenti che
implementano un’interfaccia ben definita
(esempio: interfacce CORBA implementate in
IDL). La base è costituita dalle interfacce che
una componente esporta verso il mondo
esterno. Ciascuna di queste è un socket su
cui altre componenti ed applicazioni si
agganciano (plug-in).
La programmazione basata su componenti
separa la costruzione di unità computazionali
dalla loro configurazione tramite connettori in
un sistema computazionalmente complesso
SD 179:
CORBA Component Model (CORBAbeans)
Rappresenta un’estensione naturale del modello CORBA object.
Un container environment che incapsula
transactionality
security
persistence
provvede un’ interfaccia ed event resolution
Integrazione con Entreprise JavaBeans
Software distribution format che facilita il marketing di
software CORBAcomponent
L’ambiente CORBAcomponents è sicuro, persistente e
transactional.
SD 180:
EVENT DRIVEN
PROGRAMMING
Event-Driven programming
Molti task di programmazione richiedono
l’integrazione di fatti (eventi) che avvengono
in modo asincrono: essi non avvengono a
tempi fissi e controllati ed il sistema deve
essere pronto a trattarli in ogni momento essi
avvengano.
Ad esempio una GUI non può obbligare un
utente a premere un tasto del mause dopo
ogni spostamento.
SD 182:
Event-Driven programming
The most commonly used technique for doing this is called event-based
programming, and it is such a good coding idiom that it is used in
nearly every practical programming language in use today. Of course,
some languages offer better support for it than others...
The basic idea is that you have a queue of possible events, and as the
environment (i.e. the world outside the program) does things, so events
are generated and added to the queue. Meanwhile, the program sits
there, grabbing events off the queue and doing whatever it takes to deal
with them, usually by way of a gigantic [switch] statement (or whatever
that language's equivalent is.)
SD 183:
Event-Driven programming
Event-driven programming è quindi uno stile
di programmazione in cui il programma è
driven da eventi esterni. I programmi Eventdriven sono composti da piccole porzioni di
codice dette:
event handlers, attivati in risposta a eventi
esterni
un dispatcher, che attiva gli event handlers,
sulla base di eventuali event queue che
memorizzano gli eventi non ancore processati.
SD 184:
Event-Driven programming cont.
Event: - Unlike traditional programs,
which follow their own control flow
pattern, onlysometimes changing
course at branch points, the control
flow of event-driven programs is largely
driven by external events.
event handler: an event handler is the
code that is executed when an event
occurs. See also event.
SD 185:
Event-Driven programming cont.
In molti casi gli event handlers possono attivare
(to trigger) a loro volta nuovi eventi,
provocando una cascata di eventi.
Event-driven programming rinforza
flessibilità e asincronia e tende ad essere
praticamente modeless. Le graphical user
interface sono solitamente programmate in
stile event-driven.
Gli Operating Systems costituiscono un altro
esempio di programmi event-driven.
SD 186:
Interrupt-Driven programming
The style of programming where the
program is not in control all the time
but rather responds to interrupts or
signals in order to get started.
At the lowest level, interrupt handlers
act as direct event handlers for
hardware events, with the CPU
hardware performing the role of the
dispatcher.
SD 187:
Event-Driven programming
Evento
come un’eccezione un evento è una condizione
(hardware) “segnalata” (espressa tramite segnale)
al contrario di un eccezione (meccanismo simile) un
evento rappresenta una condizione normale
La tecnica usata per per gestire eventi è detta eventbased o event-driven programming,
Nella programmazione event-driven (ad eventi) non si
ha un flusso di controllo normale ma sostanzialmente
solo event handlers
SD 188:
Event-Driven programming
L’idea base è quella di gestire una coda di eventi
in modo tale che quando l’ambiente (mondo
esterno al programma) è operativo genera
eventi che vengono inseriti nella coda (in
attesa di essere serviti)
Il programma cicla all’interno di un outermost
(switch) statement (o usa tecniche
equivalenti) in cui si chiede se vi sono eventi
in attesa nella coda, in caso affermativo li
preleva e li gestisce (li serve).
SD 189:
Event-Driven programming
Event-driven programming è quindi uno stile
di programmazione in cui il programma è
pilotato (driven) da eventi esterni. I
programmi Event-driven sono composti da
piccole porzioni di codice dette:
event handlers, attivati in risposta a eventi
esterni e da un
event dispatcher, che attiva gli event handlers,
tramite l’uso di event queue che memorizzano
gli eventi non ancora processati.
SD 190:
Event-Driven programming cont.
Ne consegue che, al contrario dei programmi
tradizionali che seguono un proprio flusso di
controllo (own control flow pattern) e solo
raramente cambiano direzione ai punti di salto
( detti “branch points”), il flusso di controllo dei
programmi a eventi (event-driven) è
sostanzialmente pilotato dagli eventi esterni.
Un event handler è una porzione di codice
eseguita quando si verifica un evento.
SD 191:
Event-Driven programming cont.
In molti casi gli event handlers possono attivare
(to trigger) a loro volta nuovi eventi,
provocando una cascata di eventi.
Event-driven programming potenzia
flessibilità e asincronia e tende ad essere
praticamente modeless. Le graphical user
interface sono solitamente programmate in
stile event-driven.
Gli Operating Systems costituiscono un altro
esempio di event-driven programs.
SD 192:
Interrupt-Driven programming
The style of programming where the program
is not in control all the time but rather
responds to interrupts or signals in order to get
started.
At the lowest level, interrupt handlers act as
direct event handlers for hardware events,
with the CPU hardware performing the role of
the dispatcher.
SD 193:
Interrupt-Driven programming
Lo stile di programmazione in cui il programma
non ha il controllo in modo continuo ma
responde ad interrupts, cioè a segnali che ne
risvegliano l’esecuzione.
Al livello più basso, gli interrupt handlers
operano come gestori diretti di eventi
hardware, mentre la CPU gioca il ruolo del
dispatcher.
SD 194:
Computer Science Department
Genova University
SYNCHRONOUS/
REACTIVE
PROGRAMMING
In Sistemi Software Concorrenti
SistemiDistribuiti
January 24, 2000
Sistemi Reattivi (Reactive Systems)
196
Un sistema reattivo è un sistema event-driven
che interagisce continuamente con l’ ambiente
(environment) reagendo agli stimoli che da
esso gli pervengono. Si assume che i sistemi
reattivi:
eseguano con una velocità mai sopraffatta da
quella dell’ambiente.
usualmente non terminino mai e quindi non
siano facilmente caratterizzabili da semplici
funzioni che partendo da uno stato iniziale li
portino ad uno stato finale.
SD 196:
20 luglio 2015
SD
Sistemi Reattivi real-time
197
Un sistema real-time è un sistema reattivo che
deve rispettare vincoli temporali (timing
constraints).
Il termine reactive è più specifico di eventdriven (piuttosto overloaded in letteratura)
ma è più generale di soft real-time e near realtime: poiché esso non si riferisce a vincoli
temporali da rispettare in real-time.
I sistemi reattivi più semplici vengono spesso
programmati come macchine a stati finiti
(automi).
SD 197:
20 luglio 2015
SD
Event-Driven programming cont.
198
a reactive system is an event-driven
systeminterrupt-driven is event-driven thus
reactive systems
|
|
interrupt-driven systems | ==> event-driven
systems
|
|
signal-driven systems
|
SD 198:
20 luglio 2015
SD
199
Sistemi Reattivi (Cont.)
I linguaggi sincroni (synchronous languages)
sistema real-time è un sistema reattivo che
deve rispettare vincoli temporali (timing
constraints).
Il termine reactive è più specifico di eventdriven (piuttosto overloaded in letteratura)
ma è più generale di soft real-time e near realtime: poiché esso non si riferisce a vincoli
temporali da rispettare in real-time.
I sistemi reattivi più semplici vengono spesso
programmati come macchine a stati finiti
(automi).
SD 199:
20 luglio 2015
SD
Architetture Software Sincrone
Le architetture software sincrone sono state
esplicitamente introdotte per la
programmazione dei sistemi reattivi. I sistemi
risultanti includono architetture data-flow e
dichiarative ed anche quelle derivate dai
tradizionali linguaggi imperativi.
SD 200:
Architetture Software Sincrone (Cont.)
L’ ipotesi di sincronia (synchrony hypothesis) assume
che tutte le computazioni avvengano in passi atomici
discreti durante i quali il tempo viene ignorato (come
se venissero eseguite in tempo nullo), inoltre si
ipotizza che:
Il tempo avanzi solo quando non vi è codice eligible
for execution.
Durante un singolo step tutti gli output ed input
avvengano allo stesso istante: cioè output e input
sono mutuamente sincroni
il concetto di tempo continuo è sostituito da una serie
ordinata di passi (step) discreti tra i quali avvengono
cambi discreti nello stato globale.
Il codice eseguito in ogni passo è detto una reazione
(reaction)
SD 201:
Ipotesi di sincronia (Cont.)
L’ ipotesi di sincronia permette di gestire la
concorrenza interna di tipo cooperativo in
modo deterministico.
Gli eventi concorrenti asincroni si manifestano
solo nell’ambito di global state ‘shapshots’
Nessuna sezione critica esplicita occorre nel
codice sorgente né in forma di monitor o di
oggetti concorrenti
tutto il codice può essere pensatocome interno
a sezioni critiche implicite eseguite con lo
stile di programmazione dei guarded
command
SD 202:
Linguaggi sincroni
I linguaggi syncroni/reattivi si focalizzano sulla
concorrenza interna di tipo cooperativo
comunemente presente in driver e controller
di sistema
essi incapsulano nella compilazione tutta la
concorrenza interna cooperativa producendo
una singola macchina a stati finiti che gestisce
tutte le attività
I principali sono Meta/NPL di ISIS [Marzullo &
Wood] Estrel e Reactive C
SD 203:
CORBA (Hello World)
catch(const CORBA::Exception&)
status = EXIT_FAILURE;
return status;
la prima cosa che fa e’ inizializare ORB. Questa operazione
richiede i parametri con cui il programma e’ stato attivato
la funzione run() viene poi attivata
il codice cattura e stampa tutte le eccezioni sollevate da
ORB_init() o run()
Se ORB e’ stato creato con successo viene anche distrutto
viene restituito lo stato di ritorno
SD 204:
CORBA (Hello World)
La funzione run() e’:
int run(CORBA::ORB_ptr orb)
CORBA::Object_var poaObj=
orb ->resolve_initial_references(“RootPOA”);
PortableServer::POA::_var rootPoa =
PortableServer::POA::_narrow(poaObj);
PortableServer::POAManager_var manager =
rootPoa -> the_POA Manager();
Hello_impl* helloImpl = new Hello_impl();
PortableServer::POA::ServantBase_var servant =
helloImpl;
SD 205:
CORBA (Hello World)
La funzione run() (continuazione):
Hello_var hello = helloImpl ->_this();
CORBA::String_var s = orb -> object_to_string(hello);
const char* refFilw = “Hello.ref”;
ofstream out(refFile);
out << s << endl;
out.close();
manager ->activate();
orb -> run();
return EXIT_SUCCESS;
SD 206:
CORBA (Hello World)
La funzione run() (commenti):
Il client accedera’ all’oggetto implementazione tramite
una “stringfied” object reference salvata su un file, che
sara’ in seguito letto dal client e riconvertito in un
object reference
Hello_var hello = helloImpl ->_this();
CORBA::String_var s = orb -> object_to_string(hello);
const char* refFilw = “Hello.ref”;
ofstream out(refFile);
out << s << endl;
out.close();
SD 207:
CORBA (Hello World)
Implementazione del client:
#include <OB/CORBA.h>
#include < Hello.h>
#include <fstream.h>
int run(CORBA::ORB_ptr);
int main(int argc, char* argv[])
…// come il server
SD 208:
CORBA (Hello World)
Implementazione del client (commenti):
se l’applicazione usa piu’ di un oggetto non e’
necessario salvarne il riferimento per
ciascuno: solitamente ne basta uno che
restituisce riferimenti agli altri
Diversamente dal server il client non include
Hello_impl.h
SD 209:
CORBA (Hello World)
Implementazione del client (continuazione):
int run(CORBA::ORB_ptr orb);
const char* refFile = “Hello.ref”;
ifstream in(refFile);
char s[2048];
in >> s;
CORBA::Object_var obj = orb -> string_to_object(s);
Hello_var hello = Hello::_narrow(obj);
hello -> say_hello();
return 0
SD 210:
CORBA (Hello World)
Implementazione del client (commenti):
l’object reference “stringfield” scritto dal
server viene letto dal client e convertito in
CORBA::Object object reference. E non e’
richiesto un riferimento alla root di POA (o POA
Manager)
l’op. _narrow genera un riferimento ad un
oggetto Hello (effetto simile a un cast
dinamico)
SD 211:
CORBA (Hello World)
Implementazione del client (continuazione):
int run(CORBA::ORB_ptr orb);
const char* refFile = “Hello.ref”;
ifstream in(refFile);
char s[2048];
in >> s;
CORBA::Object_var obj = orb -> string_to_object(s);
Hello_var hello = Hello::_narrow(obj);
hello -> say_hello();
return 0
SD 212:
CORBA (Hello World)
Implementazione del client (continuazione):
int run(CORBA::ORB_ptr orb);
const char* refFile = “Hello.ref”;
ifstream in(refFile);
char s[2048];
in >> s;
CORBA::Object_var obj = orb -> string_to_object(s);
Hello_var hello = Hello::_narrow(obj);
hello -> say_hello();
return 0
SD 213: