Sistemi Distribuiti Introduzione al corso

Transcript

1 Sistemi Distribuiti Introduzione al corso Contenuti Concetti fondamentali e principi di progetto dei sistemi di elaborazione distribuiti (SD) Caratteristiche, architettura hw e sw, classificazione e progetto dei SD Altri testi di consultazione Crediti: 6+3 Docenti: Simonetta Balsamo, Andrea Marin Testo di riferimento sito: G.Coulouris, J.Dollimore and T.Kindberg Distributed Systems: Concepts and Design IV Ed., Addison-Wesley 2005 A. Tanenbaum Distributed Systems, 2a Ed. Prentice-Hall 2007 (ed. Italiana Pearson) S. Mullender Distributed Systems, Addison-Wesley 1993 A. Tanenbaum Computer Networks, Prentice-Hall (Reti di Calcolatori, Jackson Ed.) Richiami di reti di calcolatori: struttura, architettura e protocolli e Interconnessione Comunicazione: chiamata e invocazione remota in ambito distribuito Middleware Name service Algoritmi distribuiti (tempo, consenso, coordinamento) Coordinamento in SD (tempo, orologi, mutua esclusione, elezione, stallo) Condivisione di dati e coerenza (replicazione, transazioni) Sistemi operativi distribuiti (thread, mutua esclusione, migrazione) Tolleranza ai guasti in SD File system distribuito Casi di studio: oggetti distribuiti, documenti distribuiti, coordinamento Nuove tecnologie: mobilità (codice e agenti), sistemi peer-to-peer, ubiquitous networks SD1.2 Organizzazione del corso Organizzazione del corso Fondamenti 1 Caratteristiche dei S.D. 2 Modelli di Sistemi 3 Reti ed interconnesione (richiami) 4 Interprocess Communication Middleware 5 Oggetti Distribuiti e RMI 7 Sicurezza 9 Name Services 17 Web Services Infrastruttura del sistema Algoritmi distribuiti 11 Tempo e stato globale 12 Coordinamento e cooperazione M2 Affidabilità Dati condivisi 13 Transazioni e Controllo della Concorrenza 14 Transazioni distribuite 15 Replicazione Nuovi paradigmi Modulo 1 (6 CFU) - Docente: S. Balsamo Fondamenti: modelli e IPC Middleware: RMI, RPC, eventi, name e web services Infrastruttura di sistema: sistemi operativi, file system distribuito Tempo e stato globale Coordinamento e cooperazione Transazioni Replicazione Nuovi paradigmi: mobilità Modulo 2 (3 CFU) - Docente: A. Marin Tolleranza ai guasti. Algoritmi distribuiti per sistemi tolleranti ai guast Sistemi peer-to-peer. Casi di studio: Napster, Gnutella, Pastry Sistemi multimediali distribuiti. Casi di studio: Tiger video server 6 Supporto al sistema operativo 8 File Systems Distribuiti 18 Memoria condivisa distribuita 10 Sistemi Peer to Peer M2 Algoritmi e casi di studio 16 Mobile and Ubiquitous computation SD1.3 SD1.4

2 Sistemi distribuiti - motivazioni Cosa è un Sistema distribuito? Sviluppo dei sistemi di comunicazione Riduzione dei costi e progressi tecnologici Reti di calcolatori e sistemi interconnessi: soluzione adeguata a molti problemi ed ambienti Sviluppo di applicazioni Caratteristiche richieste, possibili vantaggi: condivisione di risorse eterogeneità affidabilità estendibilità/scalabilità prestazioni elevate trasparenza Per esempio Client-Server Il Web Internet reti ad-hoc Reti di sensori DNS Kazaa (sistemi peer to peer) (il sistema solare?) (un sistema sociale?) (la catena alimentare?) SD1.5 SD1.6 Sistemi distribuiti - definizioni 1/3 Sistemi distribuiti - definizioni 2/3 hardware Sistema di elaborazione: software di sistema (dati e controllo) software applicativo (dati e controllo) Difficile demarcazione (e.g. sistemi real-time, elab. dati) hardware distribuito Sistema distribuito e/o controllo distribuito e/o dati distribuiti hardware: unità di elaborazione (!2) interconnessione! rete di comunicazione distribuzione fisica dell'applicazione distribuzione funzionale del sistema controllo: gestione delle risorse fisiche e logiche coordinamento delle attività dell U.E. strategie centralizzate, gerarchiche, distribuite dati: risorsa da gestire distribuzione: replicazione, partizione (copie multiple a diverse locazioni, porzioni dei dati a diverse locazioni) tolleranza ai guasti prestazioni Hardware Controllo Dati Omogeneo Eterogeneo master-slave completa replicazione Special-purpose Omogeneo autonomo directory non General-purpose su transazioni compl. replicate Eterogeneo autonomo dati e directory General-purpose compl. cooperativo locali SD1.7 SD1.8

3 Sistemi distribuiti - definizioni 3/3 Alcuni esempi di problemi nella progettazione dei sistemi distribuiti sistemi distribuiti sistemi paralleli singola applicazione sistema distribuito un sistema costituito da più unità di elaborazione autonome che supportano un insieme di processi e/o di basi di dati e che interagiscono cooperando per raggiungere un dato obbiettivo. I processi si coordinano e si scambiano informazione tramite una rete di comunicazione Algoritmi basilari, e.g. gestione asincronia, ricerca del consenso Routing, e.g., IP,BGP Sistemi su larga scala, es. Grid,Gnutella,Kazaa Distributed File Systems, es. NFS, AFS, CODA Protocolli, e.g., multicast, IP multicast, Coordinamento, es. giochi on line memorie e Databases Sicurezza appare all utente come un singolo sistema - trasparenza SD1.9 SD1.10 Sistemi distribuiti - caratteristiche Esempio Concorrenza Unità autonome e asincrone Condivisione di risorse - coordinamento - accessibilità Mancanza di tempo globale Guasti indipendenti delle u.e. Visualizzazione di alcuni cammini in una porzione di Internet SD1.11 Da: " 2002, M. T. Harandi and J. Hou (I. Gupta)) SD1.12

4 Sistemi distribuiti - obbiettivi Esempio: Tipica parte di Internet economia condivisione di risorse: riduzione dei costi - maggior elaborazione locale, distribuita tecniche di compressione - protocolli efficienti di comunicazione software modularità - progetto, verifica, modifica, mantenimento, riuso flessibilità ed estendibilità, gestione dell eterogeneità chiare e semplici interfacce software, hardware - middleware protocolli standard di comunicazione interoperabilità disponibilità ed integrità gestione dei guasti hardware e software - risorse critiche, replicazione tecniche di riconoscimento dei guasti e recupero degradazione controllata delle prestazioni prestazioni tempo di risposta - throughput riduzione dei colli di bottiglia - parallelismo località e distribuzione del controllo sicurezza - efficienza trasparenza SD1.13 intranet!!! ISP! satellite link desktop computer: server: network link: ISP: Internet Service Provider backbone SD1.14 Esemio: Tipica intranet Esempio: sistema distribuito a componenti mobili Server di stampa e altri servers server Desktop computers Internet Web server server Local area network Host intranet Wireless LAN WAP gateway Home intranet il resto di Internet File server router/firewall stampante altri servers Stampante Mobile phone Laptop Macchina fotografica Host site PDA: personal digital assistant WAP: wireless application protocol SD1.15 SD1.16

5 Sistemi distribuiti - problemi aperti Sistemi distribuiti - problemi aperti condivisione di risorse gestione della eterogeneità gestione della concorrenza openess sicurezza scalabilità gestione dei guasti trasparenza SD1.17 eterogeneità reti: protocolli e servizi unità di elaborazione sistemi operativi linguaggi - applicazioni middleware strato intermedio per rendere trasparente l eterogeneità e fornire un unico modello di calcolo (protocolli, SO, hw, linguaggi), es. CORBA, RMI (Remote Method Invocation) mobilità: codice mobile es. Java applets - macchine virtuali per esportabilità openess estendibilità - uniformità - gestione eterogeneità documentazione e specifica - es. RFC (Request For Comments) QoS: Quality of Service: prestazioni, affidabilità, sicurezza gestione dei guasti identificazione - mascheramento - recovery tolleranza ai guasti - disponiblità ridondanza SD1.18 Esempio - World Wide Web Web servers e web browsers sistema di pubblicazione ipertestuale e accesso a risorse e servizi, basato su Internet applicazioni sw : browser sistema aperto, estendibile (applicazioni, risorse, funzionalità ) standard per la comunicazione, per i documenti ulitizza: Architettura client-server HyperText Markup Language (HTML) - linguaggio di specifica HyperText Transfer Protocol (HTTP) - protocollo Uniform Resource Locator (URL ) - identificatori di risorse o documenti protocollo:identificatore-specifico dello schema esempio più recentemente: Extensible Markup Language (XML) - formato universale per documenti e dati strutturati Web servers File system of Activity.html Protocols Browsers Internet SD1.19 SD1.20

6 Computers vs. Web servers in Internet Data Computers Web servers 1979, Dec , July 130, , July 56,218,000 5,560, , Jan. 171,638,297 35,424,956 Data Computers Web servers Percentuale 1993, July 1,776, , July 6,642,000 23, , July 19,540,000 1,203, , July 56,218,000 6,598, , July 125,888,197 31,299, , July 42,298,371 crescita del numero di Hosts collegati ad Internet SD1.21 Numero di Hosts collegati ad Internet 1977: 111 hosts su Internet 1981: 213 hosts 1983: 562 hosts 1984: 1,000 hosts 1986: 5,000 hosts 1987: 10,000 hosts 1989: 100,000 hosts 1992: 1,000,000 hosts 2001: milioni di hosts 2002: oltre 200 milioni di hosts 2005: oltre 350 milioni di hosts 2006: oltre 440 milioni di hosts Fonte: Internet Society crescita logaritmica del numero di siti Web

7 1990: 1 sito 1991: 10 siti 1992: 50 siti 1993: 623 siti 1994: 10,022 siti 1995: oltre 23,000 siti 1996: oltre 250,000 siti 1998: oltre 3,500,000 siti 2000: oltre 25 milioni siti 2001: oltre 36 milioni siti 2003: oltre 45 milioni siti 2005: oltre 70 milioni di siti 2006: oltre 100 milioni di siti Numero di siti web collegati ad Internet Fonte: Internet Society Trasparenze Trasparenza di accesso: permette di accedere risorse locali e remote con le stesse operazioni. di rete Trasparenza di locazione: permette di accedere alle risorse senza conoscere la locazione. Trasparenza di concorrenza: permette ad un insieme di processi di operare concorrentemente condividendo risorse e senza interferire fra loro. Trasparenza di replicazione:permette l uso di copie multiple di risorse per aumentare l affidabilità e le prestazioni, senza che gli utenti ne abbiano conoscenza. Trasparenza ai guasti : permette il mascheramento dei guasti in modo che gli utenti possano completare le operazioni richieste anche in presenza di guasti di componenti hardware o software. Trasparenza alla mobilità permette di spostare le risorse e i clienti in un sistema senza influenzare le operazioni di utente. Trasparenza alle prestazioni: permette di riconfigurare il sistema al variare del carico per migliorare le prestazioni. Trasparenza di scalabilità: permette al sistema e alle applicazioni di espandersi in modo scalabile senza modificare la struttura del sistema o gli algoritmi applicativi. SD1.26 Esempi di applicazioni Sistemi Distribuiti comunicazione di dati fra terminali di un sistema di elaborazione - fra sistemi di elaborazione sistemi distribuiti o centralizzati es. packed-switched networks (Arpanet, Datapac, Transpac, Telnet) comunicazione con vincoli (magazzini, carte di credito) condivisione di risorse es.: office automation identificazione - protezione - gestione della intercomunicazione controllo di processi microprocessori per controllo e monitor basi di dati distribuite partizionamento o replicazione - località - integrità controllo degli accessi -affidabilità - sicurezza Organizzazione hw Obbiettivo di progetto: migliorare le prestazioni del sistema mantenendo contenuti i costi Sistema centralizzato: aumentare la velocità (ciclo) della CPU - limite fisico: velocità della luce - segnale elettrico può percorrere 30 cm/ns nel vuoto 20 cm/ns su rame => dato il ciclo di CPU se un elaboratore esegue 1 istruzione in 1 ns, la massima distanza che un segnale può coprire da CPU a memoria è 20cm Sistema distribuito: diverso modello di esecuzione diversi modelli SD2.2

8 Sistemi distribuiti - architetture SISD varie classificazioni classificazione di Flynn (1972) Modello von Neuman - singolo flusso di istruzioni (programma) eseguito da una CPU e con una memoria contenente i dati - FETCH, DECODE, EXECUTE ogni singola istruzione nella sequenza Flusso di istruzioni singolo multiplo Flusso dei dati singolo SISD MISD multiplo SIMD MIMD Strategie di accelerazione del ciclo - parallelismo (limitato) : uso di molte ALU specializzate che eseguono ogni singola operazione ad alta velocità (es. +, x, ) - pipelining : DECODE di istruzione y contemporaneo a FETCH di istruzione y+1, EXEC di y - uso di gerarchie di memoria (livelli di cache) - uso di hw specializzato SIMD array processor stesso calcolo su molti dati MIMD sistemi distribuiti SD2.3 SD2.4 SIMD MIMD Esecuzione in parallelo su un insieme di dati Architettura vettoriale anziché una singola ALU che opera su una singola variabile per ogni input, si ha un vettore di ALU che opera su un vettore di valori di input produce un vettore di output (esegue operazioni su vettori) Array processor - matrice di elementi processore/memoria - singola unità di controllo che esegue il broadcast di una singola istruzione a tutti i processori - ogni processore esegue l istruzione sui dati disponibili in memoria locale (esegue operazioni su matrici) NOTA: in entrambi i casi utilizza un singolo PC (program counter) e Nota CPU distinte eseguono differenti programmi (multiple instruction stream) su flussi di dati distinti (multiple data stream) CPU dotate di proprio Program Counter, memoria, dati, programmi, cooperano per svolgere e fornire un servizio comune => macchina MIMD = sistema distribuito - in alcune configurazioni le CPU possono condividere dati collocati in memoria comune accessibile via bus di sistema (multiprocessor) - gli accessi concorrenti alla memoria comune possono creare conflitti nell accesso al bus => uso di memoria locale privata (cache) per ogni CPU, contenente codice e dati da non condividere, minimizzando gli accessi alla memoria comune Esempio: sistema di prenotazione aerea: richieste multiple di prenotazione (multiple data stream) che possono essere servite concorrentemente (multiple instruction stream) da un insieme di CPU che condividono la pianta dell aereo e ne tengono aggiornato lo stato. SD2.5 SD2.6

9 Sistemi distribuiti - architetture Multiprocessori a bus Multiprocessore Multicalcolatore memoria condivisa accoppiamento stretto ritardo di trasmissione breve velocità di trasmissione alta memoria locale privata U.E. elaborazione, memorizzazione Rete di comunicazione! accoppiamento lasco maggiore ritardo di trasmissione minore velocità di trasmissione insieme di U.E. interconnesse da una rete di interconnessione Architettura: a bus -a commutazione SD2.7 CPU BUS Bus dati, indirizzo, controllo 32 o 64 linee indirizzi, 32 o 64 linee dati, almeno 32 linee controllo parallele banda 300 Mbps limite tipico per le prestazioni:4/5 CPU Lettura da memoria: CPU scrive l indirizzo di parola richiesta sul bus indirizzi conferma il comando di lettura via CNTRL memoria scrive il dato su linee dati CPU MEMORIA SD2.8 Multiprocessori a bus: coerenza della memoria Multiprocessori a bus CPU Cache CPU Cache MEMORIA CPU Cache CPU Cache MEMORIA Condivisione della memoria Problema: coerenza al tempo t la CPU A scrive il valore x all indirizzo di memoria y al tempo t >t la CPU B legge il valore x dall indirizzo di memoria y Coerenza costosa da implementare => sovraccarico del bus Soluzione basata sulla memoria cache mantenere parole accedute più recentemente hit rate: probabilità di successo, se la parola cercata è nella m. cache (es.:90%) BUS SD2.9 coerenza: possibile soluzione scrittura attraverso la cache, ogni scrittura nella m.c. è riportara in memoria (write-through cache) tutte le CPU controllano eventuali scritture e nel caso eliminano o aggiornano la parola (snoopy cache) meccanismo trasparente all'utente - limite tipico per le prestazioni:32/64 CPU BUS SD2.10

10 Multiprocessori a commutazione Multiprocessori a commutazione: Omega network MEMORIA CPU MEMORIA CPU Memoria multimodulare Connessione a crossbar Crosspoint interruttore (switch) Svantaggio:costo n memorie ed n CPU richiedono n 2 switches Altre architetture commutatore di crosspoint (es. n=64, 4096 switch) SD2.11 n memorie ed n CPU richiedono (n/2 log n) switches Vantaggio: accesso diretto di ogni CPU ad ogni modulo Svantaggio: maggior ritardo di comunicazione: log n stati di switching ogni stadio ha n/2 switch Esempio: n=1024, 10 stadi di switch per trasmettere da CPU a memoria e 10 stadi per la trasmissione inversa; se la CPU è una RISC con tempo di esecuzione di 10 ns i 20 switch devono essere attraversati da meno di 10 ns => ogni switch 10ns/2=0.5 ns= 500 picosec=> occorrono 1024x10=5120 CS da 500 picosec => costo elevato SD2.12 Multiprocessori a commutazione: Omega network Multiprocessori a commutazione: Omega network CPU Memoria CPU Memoria Esempio: n=8, 3=log 8 livelli di switch per trasmettere da CPU a memoria SD2.13 Esempio: n=16, 4 livelli di switch per trasmettere da CPU a memoria SD2.14

11 Multiprocessori a commutazione: NUMA Multicalcolatore a bus Workstation Workstation NUMA Not Uniform Memory Access Ogni CPU ha una memoria locale: - accesso veloce alla memoria locale - più efficienti - problemi di allocazione ottima di dati e programmi ML CPU ML CPU File Server Multiprocessor Snoopy cache Limitati dalla capacità del bus (max 64 CPU) Crossbar switch Costoso Omega Network Costoso NUMA Complessità degli algoritmi di allocazione di+ programmi e dati Senza memoria condivisa Traffico limitato Espandibilità Protocolli di rete Rete ML Memoria locale Printer SD2.15 SD2.16 Multicalcolatore a commutazione Multicalcolatore a commutazione Diverse topologie Es. Griglia (struttura bidimensionale) Es. Ipercubo:cubo ad 4 dimensioni Ogni CPU ha 4 link Ipercubo commerciale Es. Ipercubo:cubo ad n dimensioni Ogni U.E. è un vertice, gli spigoli sono connessioni Ogni U.E. ha n connessioni Crescita logaritmica delle connessioni Trasmissione anche in più passi Limite logaritmico al numero di passi con "n SD2.17 SD2.18

12 Multicalcolatore a commutazione Multiprocessori e multicalcolatori a commutazione: altre soluzioni Es. Ipercubo: cubo ad 6 dimensioni Ogni CPU ha 6 link Sistemi a parallelismo massiccio supercomputer con migliaia di CPU bassa latenza e alta banda buona affidabilità Sistemi a cluster di workstations (COW) U.E. connesse con componenti disponibili ( off the shelf ) nessun accorgimento specifico per ottimizzare prestazioni e affidabilità SD2.19 SD2.20 Sistemi distribuiti - Architetture software Sistemi distribuiti - Architetture software Sistemi Operativi (OS) OS per un sistema uniprocessore OS per un sistema multiprocessore: MOS OS per un sistema distribuito: DOS OS per la gestione della rete in un sistema distribuito: NOS SO per un sistema di elaborazione uniprocessore gestione delle risorse condivisione delle risorse insieme di utenti (processi) sistema con memoria condivisa globale singola coda di processi pronti ed eseguibili possibile attesa attiva stato o modo di operazione nucleo vs utente modello di macchina virtuale modelli di OS microkernel monolitico modelli di OS microkernel SD2.21 SD2.22

13 Sistemi distribuiti - Architetture software Classificazione Accoppiamento lasco: S.O. di rete, interazione lasca Accoppiamento stretto: S.O. per multiprocessori e multicalcolatori Accoppiamento lasco (loosely-coupled DOS) macchine, utenti, programmi indipendenti fra loro condividono uso di risorse costose ogni U.E. è identificabile ed è in grado di operare indipendentemente dagli altri (e.g, un guasto di rete non blocca l operatività della singola U.E.) Accoppiamento stretto (tightly-coupled DOS) macchine indipendenti coordinate da un controllore Sistemi distribuiti - Architetture software Classificazioni Accoppiamento stretto/lasco Multicalcolatore/multiprocessore A bus/a commutazione Multicalcolatore Multicalcolatore Multiprocessore sw ad accoppiamento lasco sw ad accoppiamento stretto (es su LAN con DOS) sw ad accoppiamento stretto (es MPC con OS) Es. SO distribuito: sw ad accoppiamento stretto su hw ad accoppiamento lasco s.d. senza memoria condivisa gli utenti vedono il sistema come un solo ambiente (uniprocessore virtuale) meccanismi globali per comunicazione - protezione - file system - gestione di memoria locale Es. SO a multiprocessori: sw ad accoppiamento stretto su hw ad accoppiamento stretto sistema con memoria condivisa globale singola coda di processi pronti ed eseguibili possibile attesa attiva SD2.23 SD2.24 Sistemi distribuiti - Architetture software NOS - sw ad accoppiamento lasco su hw ad accoppiamento lasco Es. SO di rete su multicalcolatori: sw ad accoppiamento lasco su hw ad accoppiamento lasco sistema operativo di rete (NOS - Network Operating System) rete di UE ognuna dotata di memoria, CPU, OS, periferiche tutti i comandi sono eseguiti localmente l esecuzione di comandi in remoto richiede la visibilità all utente della locazione di risorse Esempio: rlogin ihoh UE usata come terminale remoto di ihoh i comandi inviati dalla UE sono eseguiti sulla macchina remota ad ogni istante una sola macchina è in esecuzione la selezione delle macchine è manuale => l utente deve conoscere l esistenza e disponibilità delle macchine Esempio: rcp ihoh:file1 squit:file2 copia file1 da ihoh a squit l utente deve sapere che file1 è nel FS di ihoh e che squit ha un FS in cui deposita file1 con nome file2 SD2.25 SD2.26

14 NOS - sw ad accoppiamento lasco su hw ad accoppiamento lasco NOS - sw ad accoppiamento lasco su hw ad accoppiamento lasco Due clienti e un servente in un NOS Diversi clienti possono montare i serventi in diverse parti Esempio da A. Tanenbaum Sistemi Distriibuiti SD2.27 Esempio da A. Tanenbaum Sistemi Distriibuiti SD2.28 NOS - sw ad accoppiamento lasco su hw ad accoppiamento lasco NOS - sw ad accoppiamento lasco su hw ad accoppiamento lasco NOS V0 NOS V1 - evoluzione di NOS V forme primitive di comunicazione e condivisione risorse - include File Server(s) condiviso(i) che gestisce(cono) file system globale - FS accetta le richieste da ogni programma sulla UE (read, write, open, close) - ogni richiesta è esaminata e servita e il risultato trasmesso al chiamante - FS mantiene un file system gerarchico - UE può montare arbitrariamente parte del file system globale nel proprio fs locale - diverse viste di utenti possibili - stesso programma eseguito su diverse UE può lavorare su gerarchie diverse - la comunicazione fra processi applicativi può avvenire tramite file condivisi SD implementazione di programmi distribuiti richiede attenzione a manipolazione ed uso di nomi di risore Es: FS mantiene file systems con path /public/work/file1 UE monta o importa file1 in /home/work/file1 il programma applicativo eseguito su UE contiene il nome esplicito fd=open( /home/work/file1,r); non portabile, ovvere eseguibile solo su quella UE e non sul File Server NOS V1 gestisce comunicazioni fra UE e FS - le UE possono eseguire sotto diversi OS - NOS V1 deve garantire concordanza almeno del FORMATO dei messaggi scambiati delle REGOLE secondo cui devono essere scambiati (standard dei PROTOCOLLI) - NON effettua coordinamento di attività ed esecuzione di programmi - NON maschera o nasconde l eterogeneita dei SO SD2.30

15 DOS - sw ad accoppiamento stretto su hw ad accoppiamento lasco DOS - Distributed Operating System implementa l astrazione di un singolo sistema time-sharing (single system image, virtual processor) su un insieme di macchine anche eterogenee interconnesse e operanti sotto lo stesso sistema operativo Trasparenza: gli utenti (programmi) non hanno visibilità della distribuzione delle risorse - IPC comune supporta le interazioni fra ogni coppia di processi - protezione globale combinazione di schemi (es. lista di controllo, capabilities, bit di protezione) maggiore complessità - gestione di processi identica su ogni macchina (es. set di primitive, create, destroy, start, suspend, ) - file system vista identica da ogni macchina - interfaccia di sistema identica su ogni macchina (stesso nucleo, più semplice coordinamento es.: start, i nuclei cooperano per decidere dove eseguire un processo) DOS - sw ad accoppiamento stretto su hw ad accoppiamento lasco Ogni nucleo ha controllo sulle risorse locali - non vi è memoria condvisa, ogni UE gestisce la memoria locale - eventuale uso di paging e/o swapping localmente - se vi è multiprogrammazione ogni nucleo gestisce lo scheduling locale => se la gestione fosse globale occorrerebbe la nozione di stato globale del sistema distribuito, solitamente non realizzabile Sistemi multicalcolatori omogenei vs sistemi eterogenei Sistemi omogenei: DOS Sistemi eterogenei: Middleware SD2.31 SD2.32 Middleware Middleware Applicazione Interfaccia Applicazione Protocollo comune In un sistema distribuito aperto basato sul middleware i protocolli usati in ogni strato middleware dovrebbero essere gli stessi middleware, come le interfacce offerte alle applicazioni SD2.33 SD2.34

16 DOS - sw ad accoppiamento stretto su hw ad accoppiamento lasco MOS - sw ad accoppiamento stretto su hw ad accoppiamento stetto Multiprocessor Operating System - MOS - special purpose: macchina data base - general purpose: time sharing OS (es. UNIX) su multiprocessore Caratteristica: coda di esecuzione UNICA (globale) struttura dati mantenuta da MOS in memoria condivsa e contenente processi in stato di ready CPU X Processo A cache CPU Y Processo B cache... CPU Z Processo C cache Memoria E ready D ready C running B running A running RUN Q: D,E MOS SD2.35 BUS SD2.36 MOS - sw ad accoppiamento stretto su hw ad accoppiamento stetto Scheduling Esempio: - il processo B in CPU Y blocca - CPU Y lo sospende e cerca un nuovo processo in RUN Q - CPU Y esegue MOS allocato in memoria condivisa - salva lo stato di B - entra nella regione critica per eseguire lo scheduler - evita a diverse CPU di prelevare lo stesso processo - controlla la mutua esclusione della coda - ottenuto l accesso esclusivo a RUN Q, la CPU Y - rimuove il processo D da RUN Q - esce dalla regione critica - esegue D Nota - nella cache inizialmente ci sono dati e istruzioni di B, per cui D è inizialmente penalizzato - allocazione dei processi: le CPU non hanno ML per cui non ha importanza chi lo esegue, ma il tempo di esecuzione è influenzato dalla presenza dei dati e programmi in cache => conviene allocare il processo alla CPU libera che più recentemente lo ha eseguito MOS - sw ad accoppiamento stretto su hw ad accoppiamento stetto File System MOS tradizionale con caching di blocco - accesso al File System causa MOS trap - MOS entra nella regione critica (con semafori, monitor, ) - esegue la system call escludendo le altre CPU dall accesso ai dati condivisi Es: write (fd,&buff,nbytes) - lock di blocco nel file identificato da fd - scrive nbytes da buff in blocco locked - rilascia il lock Organizzazione di MOS con CPU dedicata ad eseguire MOS e altre riservate ad applicativi svantaggio: MOS diventa collo di bottiglia SD2.37 SD2.38

17 Confronto Sistemi distribuiti - Progetto 1/2 Organizzazione sw per n macchine Categoria NOS DOS - Middleware MOS Trasparenza NO SÌ - SÌ (alta) SÌ Stesso OS NO SÌ - NO SÌ Copie di OS n n 1 Comunicazione file condivisi messaggi- dip. mod. memoria condivisa Protocolli di comunicazione SÌ SÌ - dip. modello NO comuni RUN Q singola NO NO SÌ Condivisione di file con non necessariamente SÌ SÌ semantica comune Scalabilità SÌ Moderata - dip. mod. NO Openess aperto chiuso - aperto chiuso trasparenza immagine di un singolo sistema, time-sharing uniprocessore * della localizzazione delle risorse: dove sono? * alla migrazione delle risorse: cambiamenti di localizzazione * alla replicazione dei file: quante copie? * alla concorrenza fra utenti: accesso a risorse condivise * al parallelismo: attività eseguibili in parallelo flessibilità * kernel monolitico s.o. centralizzato + opzioni di rete e servizi remoti * microkernel comunicazione fra processi - gestione memoria gestione processi e schedulazione a basso livello I/O a basso livello più flessibile SD2.39 SD2.40 Sistemi distribuiti - Progetto 2/2 affidabilità disponibilità (Availability): fraz. di tempo in cui il sistema è utilizzabile, funzionante ridondanza: tecnica per aumentare A consistenza fra copie multiple sicurezza tolleranza ai guasti (fault tolerance) prestazioni metriche: tempo di risposta, throughput, utilizzo, banda, caratterizzazione del carico colli bottiglia load balancing definizione della grana (fine o grossa) di parallelismo scalabilità grande dimensioni evitare componenti, dati e algoritmi centralizzati SD2.41

18 Modelli di Sistemi Modelli concettuali di supporto allo studio dei sistemi distribuiti Modelli architetturali Descrizione ad alto livello della distribuzione delle funzionalità delle componenti e loro relazione Modelli di comunicazione e interazione Distribuzione dei dati e dei processi sulle u.e. Valutazione qualitativa (proprietà) e quantitativa (prestazioni, affidabilità, scalabilità) Modelli fondamentali Descrizione verticale o parziale di alcuni aspetti dei s.d. Insieme di aspetti di progetto Modello di interazione Modello di guasti Modello di sicurezza Modello di mobilità Modelli Architetturali Astrazione del sistema - componenti e struttura - distribuzione delle funzionalità Processi client server peer Comunicazione Coordinamento Modello cliente-servente Modello peer processes Impatto su prestazioni - affidabilità - scalabilità - costo -sicurezza -... S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.3 Livelli di servizi hardware e software in un sistema distribuito Invocazione di clienti ad un servente Applicazioni e servizi Client invocazione invocazione Server Middleware risultato Server risultato Client Sistema Operativo Processo: Computer: Piattaforma Rete e hardware Annidamento S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.5 S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.4

19 Interazione cliente - servente Architettura multi-tier Diverse organizzazioni possibili per l interazione cliente-servente S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.6 S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.7 Architettura multi-tier Servizio fornito da un insieme di serventi Service Client Server Server Client Server Esempio di servente che a sua volta è cliente. S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.8 Serventi multipli Replicazione / partizione degli oggetti Tolleranza ai guasti Prestazioni S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.9

20 Esempio Web proxy server Client Proxy server Web server Client Web server Esempio di architettura a distribuzione orizzonale per la realizzione di un web service Cache Tolleranza ai guasti Prestazioni: riduzione del carico di rete e server S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.11 S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.10 Applicazione distribuita basata su peer processes Varianti del modello cliente-servente Oggetti condivisi Peer 1 Applicazione Peer 2 Applicazione Peer 3 Applicazione Mobilità del supporto (U.E.) del codice dei dati Dinamicità Mobilità del codice Peers 5... N Processi paritari cooperanti Peer 4 Applicazione Mobilità del codice e dati agenti mobili Network computer limiti: sicurezza verso i nodi e verso gli agenti scarica SO e applicazioni da FS remoto; esecuzione locale; file gestiti in remoto Thin client Consistenza delle risorse Sincronizzazione delle azioni S. Balsamo Università Ca Foscari di Venezia 13:59 SD.3.12 S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.13

21 Web applets Thin clients and compute servers a) la richiesta del cliente provoca il downloading del codice applet Client Applet code Web server Network computer or PC Thin Client network Compute server Application Process b) il cliente interagisce con la applet Client Applet Web server Thin client: strato sw di interfaccia a finestre sul locale dell utente esecuzione remota possibile latenza per interfaccia S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.15 S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.14 Esempio di networking spontaneo in un hotel Modelli fondamentali Internet gateway Music service Alarm service DEPENDABILITY correttezza, affidabilità, sicurezza, prestazioni Discovery service Hotel wireless network Camera Modelli di interazione Modelli di guasto TV/PC Laptop PDA Guests devices Modelli di sicurezza Modelli di prestazione Integrazione di periferiche (mobili e non) Possibilità di connessione ad una LAN Integrazione di servizi Connessioni temporanee Sicurezza - privacy S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.17 S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.16

22 Modelli di interazione Ordinamento di eventi in sistemi real-time Algoritmi distribuiti: evoluzione dei processi trasmissione dei messaggi fra processi Limiti dovuti alla comunicazione (prestazioni, affidabilità) latenza (servizio - accesso - trasmissione) banda jitter - tempo per consegnare un insieme di messaggi Mancanza di un tempo globale sincronizzazione di orologi fisici - logici ordinamento degli eventi X Y Z A send 1 m1 2 receive send 3 receive m 2 receive receive 4 send receive m 3 receive m 1 m 2 receive receive receive t1 t2 t3 Tempo reale Sistemi distribuiti sincroni - bound ai tempi di esecuzione/trasmissione/deviazione clock asincroni - nessun bound Es: A riceve in ordine diverso S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.19 S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.18 Modelli di guasto Processi e canali Tipi di guasto omissioni arbitrari di tempo processo p send m processo q receive Outgoing message buffer Canale di comunicazione Incoming message buffer S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.21 S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.20

23 Omissioni e guasti Guasti di tempo Tipo di guasto Su Descrizione Fail-stop Processo Il processo si ferma. Altri processi possono riconoscere lo stato. Crash Processo Il processo si ferma. Altri processi possono non riconoscere lo stato. Omissione Canale Un messaggio inserito in un buffer di uscita non arriva mai all altro estremo del buffer. Send-omission Processo Un processo completa la send,ma il messaggio non è messo nel buffer di uscita. Receive-omission Processo Un messaggio è posto in un buffer di ingresso di un processo ma processo non lo riceve. Arbitrario (Bizantino) Processo canale Un process/canale si comporta in modo arbitrario: può inviare/trasmettere messaggi qualsiasi a tempi qualsiasi. commit omissions; un processo può fermarsi o fare un passo sbagliato. Tipo di guasto Su Descrizione Clock Processo Il clock locale del processo eccede il limite sul tasso di sfasamento rispetto al tempo reale. Performance Processo Un processo eccede il limite di intervallo fra due passi Performance Canale Una trasmissione di messaggio richiede più tempo di quanto stabilito. NB Solo in sistemi sincroni Dove esistono bound sul tempo S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.23 S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.22 Modelli di sicurezza Oggetti e principals Sicurezza dei processi delle interazioni degli oggetti invocation Access rights Object Proprietà Client result Server Protezione - Diritti di accesso Principal (user) Network Principal (server) Canale sicuro crittografia autenticazione Attacchi a processi - canali - negazione del servizio Comunicazione affidabile: validità i messaggi vengono consegnati integrità i messaggi consegnati sono corretti e in ordine S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.25 S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.24

24 Possibile attacco S. Balsamo Università Ca Foscari di Venezia 14:00 SD.3.26 Comunicazione cliente servente Indirizzamento 1/3 Aspetti di progetto indirizzamento (localizzazione del servente) primitive tipo di (sincrone/asincrone) con o senza uso di buffer protocolli (tipi di messaggi, frammentazione e ricomposizione) affidabilità: tolleranza ai guasti e semantica dell interazione in linguaggi di programmazione S. Balsamo Università Ca Foscari di Venezia Su una LAN Indirizzamento: <macchina.processo> cliente nucleo request reply servente nucleo LAN Le richieste sono inviate all indirizzo fisico I livelli inferiori sono tipicamente hw (es. Ethernet, Token ring) Request/reply Data link Fisico I livelli superiori sono semplici chiamate send(dest,&m) e receive(addr,&m) Il cliente conosce l indirizzo fisico del servente => manca la trasparenza di locazione => non conveniente per poter rilocare il servente senza modificare il codice del cliente 13:13 SD.4.2

25 Indirizzamento 2/3 Broadcast di un pacchetto locate cliente 3:request servente 4:reply nucleo nucleo Indirizzamento 3/3 Uso del Name Server NS 1:lookup cliente 3:request nucleo 2: NS-reply nucleo 4:reply servente nucleo 1:locate 2:IAH 1 il cliente invia in broadcast un pacchetto speciale di locate 2 il servente risponde con un messaggio I Am Here con il suo indirizzo fisico 3 il cliente invia la richiesta a quell indirizzo 4 il servente invia reply al cliente => aumento del traffico dovuto al broadcast, overhead LAN 13:13 SD.4.3 Il Name Server è noto, e conosciuto ai clienti l indirizzo NS mantiene il mapping fra i nomi logici dei serventi e gli indirizzi fisici 1 il cliente invia ad NS una richiesta di lookup per ottenere l indirizzo del servente 2 NS risponde con un messaggio reply con l indirizzo fisico del servente 3 il cliente invia la request al servente 4 il servente invia reply al cliente NS è una componente centralizzata - eventuale replicazione per robustezza => complessità per mantenere la consistenza delle copie 13:13 LAN SD.4.4 Primitive SINCRONE send il mittente specifica il buffer di invio e l indirizzo di destinazione rimane bloccato finché il buffer non è stato inviato receive l invocazione non restituisce il controllo al processo invocante finché il messaggio non è stato ricevuto e depositato in un buffer di destinazione, specificato dall invocante ASINCRONE send restituisce il controllo all invocante appena il buffer da inviare è stato copiato nel buffer del nucleo (locale) receive indica al nucleo locale l indirizzo e la dimensione del buffer dove ricevere i dati e restituisce il controllo all invocante Primitive asincrone Vantaggi: permette all invocante di continuare l elaborazione in parallelo alla comunicazione Svantaggi: riconoscere la terminazione della comunicazione - alternative di implementazione della send asincrona il buffer da inviare è nello spazio utente => l invocante non può modificarlo finché non è trasmesso il buffer da inviare è nello spazio nucleo => costo dell operazione di copia - terminazione: interrupt dal nucleo appena il buffer è stato trasmesso non richiede la copia il mittente può riusare il buffer dopo l interrupt complessità di programmazione del mittente per gestire l interrupt - receive asincrona - terminazione primitiva test che controlla il nucleo per verificare lo stato primitiva conditional_receive che restituisce o il messaggio o un fallimento interrupt dal nucleo per segnalare la terminazione (messaggio ricevuto) Spesso le primitive sincrone sono preferite per maggior semplicità di implementazione 13:13 SD :13 SD.4.6

26 Primitive con o senza buffer Primitive con buffer - il processo che invoca la receive chiede al nucleo di creare la mailbox e specifica il proprio indirizzo locale (es. numero di porta) e i blocchi - il nucleo mantiene la mailbox nello spazio del nucleo - i messaggi in arrivo che contengono l indirizzo del processo sono depositati in quella mailbox del processo; se esiste una receive pendente questa è terminata sbloccando il processo, oppure il messaggio è mantenuto finché non arriva una invocazione di receive relativa. - se la mailbox è piena => il nucleo potrebbe scartare messaggi Primitive senza buffer - receive(addr,&m) per ricevere un messaggio da un processo di indirizzo addr nel buffer puntato da m, nello spazio di memoria dell invocante - l invocante si blocca dopo l invocazione - il nucleo sblocca l invocante quando il messaggio è ricevuto e copiato nel buffer m - se il messaggio è ricevuto e non ci sono receive pendenti - il nucleo elimina il messaggio - il cliente riprova - se la receive è invocata da un servente, si ha una race condition se il server sta eseguendo operazioni per un cliente e un altro cliente lo richiede (il secondo deve attendere una nuova invocazione di receive del server) Protocolli Frammentazione e ricomposizione dei messaggi: i messaggi a livello applicazione possono dover essere frammentati, a causa di limitazioni sul massima dimensione (dei pacchetti) Codifica Tipo Da A TIPI di MESSAGGI 1.REQ request C S il cliente chiede un servizio 2.REP reply S C il servente invia la risposta 3.ACK ack C/S S/C il msg precedente è arrivato 4.AYA are you alive? C S richiesta al servente se sta funzionando 5.IAA I am alive S C risposta del servente 6.TA try again S C servente occupato, non ha spazio 7.AU address S C nessun processo usa questo indirizzo unknown 13:13 SD :13 SD.4.8 Tipi di messaggi 1-2 sono essenziali 3 aumenta l affidabilità (perdita di messaggi) 4-7 non necessari per servizi di base ma utili per aggiungere funzionalità - necessità di 4-5 se un cliente invia una richiesta e se la risposta non ritorna dopo un tempo ragionevole: il servente lavora correttamente o no? -> il cliente usa un messaggio AYA per testare il servente se la risposta è un messaggio IAA o REP, bene, altrimenti rinvia AYA dopo un certo numero di ripetizione può assumere che il server non sia vivo - 6 talora il servente non può accettare un REQ -> il server non ha spazio di buffer per nuovi msg (ne ha ricevuti molti) -> il server è sovraccarico, rifiuta ulteriori richieste per un certo tempo -7 indirizzo errato (non esiste un processo a quell indirizzo) -> il cliente non deve riprovare inutilmente 13:13 SD.4.9 Cliente Esempi di interazione cliente servente REQ REP Protocollo con ack per ogni msg Cliente REQ REP ACK Protocollo con ack e test Servente Cliente Servente Cliente Protocollo semplice senza ack REQ ACK ACK REP Servente Protocollo dove REP è anche ack REQ ACK AYA IAA REP ACK Servente SD :13

27 Comunicazione e interconnessione: reti Reti e interconnessione Comunicazione nei sistemi distribuiti Uso della rete Tipi di rete: LAN, MAN, WAN, wired, wireless Qualitá e caratteristiche: qualitá del servizio: prestazioni elevate (banda, latenza, velocitá di trasmissione) affidabilitá sicurezza scalabilitá mobilitá Principi di progettazione modelli con struttura a livelli protocolli e algoritmi Tipi di rete Wired: Esempio Estensione Banda (Mbps) Latenza (ms) LAN Ethernet 1-2 kms WAN IP routing geografica MAN ATM 250 kms Internetwork Internet geografica Wireless: WPAN Bluetooth ( ) 10-30m WLAN WiFi (IEEE ) km WMAN WiMAX (802.16) 550 km WWAN GSM, 3G phone nets geografica S. Balsamo A.A Università Ca Foscari di Venezia S. Balsamo A.A Università Ca Foscari di Venezia Reti - richiami Reti - richiami - modello TCP/IP Messaggio inviato Messaggio ricevuto Livello n Livello 2 Livello 1 Mittente Mezzo di comunicazione Ricevente Modello a livelli Application-layer message Servizi e protocolli PDU Protocol Data Unit - per ogni livello Presentation header Incapsulamento delle informazioni ( buste ) Session header Livelli Applicazione Trasporto Internet Interfaccia di rete Rete sottostante Messaggio Messages (UDP) or Streams (TCP) Messaggi UDP o TCP IP datagrams (pacchetti) Network-specific frames Applicazione Applicazione Transport header TCP UDP Network header IP S. Balsamo A.A Università Ca Foscari di Venezia S. Balsamo A.A Università Ca Foscari di Venezia

28 Comunicazione fra oggetti distribuiti Livelli Middleware RMI RPC Eventi invocazione di metodo remoto - gli oggetti remoti ricevono le RMI interfaccia remota meccanismo per la comunicazione cliente servente come primitiva di un linguaggio di programmazione notifica asincrona agli oggetti di eventi Analogia con l invocazione di un metodo (locale) e la chiamata di procedura (locale) Diversa implementazione Applicazioni RMI, RPC ed eventi Protocollo Request Reply Rappresentazione di dati esterni livelli Middleware Servizio a livello RPC è un modulo che interfaccia per esportare operazioni su un tipo di dato astratto o risorsa Sistema Operativo Specifica I parametri di I/O (input al servente, procedura) (output al cliente nel reply) Se i parametri sono passati per reference indicare se sono I o O o I/O Esecuzione remota (non si può usare l ambiente globale del chiamante) Non si possono usare puntatori a locazioni di memoria Trasparenza - di locazione - dai protocolli - dalla piattaforma (s.o. e hw) - dal linguaggio di programmazione con uso di interfacce (es. Corba IDL) S. Balsamo Università Ca Foscari di Venezia 1 16:15 SD.5.2 Trasparenza e implementazione Binding La trasparenza - come per le chiamate di procedura locali MA RPC più soggette a guasti -> minor trasparenza per distinguere locale/remoto interfacce diverse se non c è trasparenza anche diverse implementazioni Implementazione supporto alla RPC, supporto a RMI interfaccia integrazione nel linguaggio di programmazione usuale marshalling connessione alla procedura del server comunicazione messaggi request e reply binding connessione del server Interfaccia programmi come insieme di moduli comunicanti identificazione di procedure all interno di cliente e servente o dei moduli inclusa nei messaggi di richiesta Procedure stub cliente converte la chiamata locale in remota servente seleziona la procedura adatta (con l identificatore) decodifica gli argomenti - la esegue - ricodifica il risultato 16:15 SD.5.3 Collegamento nome -> oggetto (identificatore) Es: servizio -> porta del server (identificatore di connessione) Es: Unix indirizzo socket (indirizzo IP, numero porta) Es: Mach, Amoeba, Chorus indirizzo porta indipendente dalla locazione Se il cliente usa l indirizzo IP dell host è dipendente dalla locazione e in caso di modifica di allocazione del server, il cliente deve essere ricompilato Binder servizio di collegamento nomi -> porte del server rende visibili i nomi delle porte dei server ai clienti Es: procedure Nel server: register(nome_servizio: stringa; porta_servizio:porta; versione:int); withdraw (nome_servizio: stringa; porta_servizio:porta; versione:int); Nel client: Lookup (nome_servizio: stringa; versione:int): porta; 16:15 SD.5.4

29 Interfacce Esempio CORBA IDL I moduli sono implementati in modo da rendere trasparente la realizzazione del operazioni. L interfaccia contiene le sole informazioni utili per l uso dei metodi invocati. Interfaccia per RPC o RMI. Non vi è accesso diretto alle variabili del modulo. Se il middleware permette diversi linguaggi di programmazione (es. CORBA), si usa un linguaggio di definizione di interfaccia (IDL - Interface Definition Language) - specifica la notazione per def. le interfacce con specifica dei parametri (I/O e tipo) Interfaccia di servizi - specifica di procedure rese disponibili al cliente Interfaccia remota - specifica i metodi di un oggetto remoto che sono invocabili da altri processi, indica gli argomenti I/O NON si ha mai l accesso diretto alle variabili Esempi: CORBA IDL (IDL per RMI), Sun XDR (IDL per RPC), DCE(Ditributed Common Object Model) IDL, DCE (Distributed Computing Environment, OSF) IDL JAVA RMI: integrazione RMI in un linguaggio OO 16:15 SD.5.5 // In file Person.idl struct Person { string name; string place; long year; Nome interfaccia } ; interface PersonList { readonly attribute string listname; void addperson(in Person p) ; void getperson(in string name, out Person p); long number(); }; Metodi disponibili ad un RMI che implementa questa interfaccia 16:15 SD.5.6 Modello orientato ad oggetti Metodi di invocazione remota e locale Modello orientato ad oggetti è naturale in ambito distribuito Insieme di oggetti - insieme di dati + metodi Riferimenti ad oggetti (object reference) valori - possono essere passati come argomenti o ottenuti come risultati Interfacce : definizione dei metodi (tipo degli argomenti, valori risultato, eccezioni) senza riferimento all implementazione Metodi : sono implementati se compaiono nell interfaccia sono invocati -> modifica lo stato dell oggetto invocato può causare altre invocazioni possono avvenire eccezioni: reazioni ad azioni inaspettate o errori A invocazione remota B locale locale C locale E D invocazione remota F Java: una classe può implementare più interfacce i metodi di una interfaccia possono essere implementati da qualsiasi classe B e F oggetti remoti Necessità di tecniche di garbage collection per il recupero di spazio di memoria di oggetti non più invocati Modello cliente-servente Reference - identificatore di oggetto remoto interfaccia remota - i metodi sono implementati dalla classe dell oggetto remoto 16:15 SD :15 SD.5.8

30 Un oggetto remoto e la sua interfaccia remota Semantica dell invocazione Implementazione della invocazione con protocollo Request-Reply Oggetto remoto interfaccia Data remota m1 m2 implementazione { m3 dei metodi m4 m5 m6 Interfaccia remota: specifica quali metodi possono essere invocati remotamente se in UDP si possono verificare i guasti di: - omissione del messaggio - disordine - duplicazione possibile guasto del processo (crash o arbitrario) => non si può garantire una semantica Exactly Once come per le operazioni locali Semantica dell invocazione: scelte implementative - ritrasmissione della richiesta - filtro dei duplicati al servente in caso di ritrasmissione - all arrivo di ritrasmissione: riesecuzione o rinvio risultati => diverse possibili semantiche 16:15 SD :15 SD.5.10 Semantica dell invocazione Semantiche dell invocazione Semantiche dell affidabilità della invocazione remota (o della RPC) rispetto al chiamante Ritrasmissione del messaggio request No Sì Sì Misure di tolleranza ai guasti Filtro dei duplicati Non applicable No Sì Procedura di riesecuzione o ritrasmissione di reply Non applicable Riesegui la procedura Ritrasmetti reply Nella invocazione locale la semantica è exactly one Semantica della RPC Semantica della invocazione At-least-once At-most-once 16:15 Maybe SD.5.11 Maybe nessuna misura di tolleranza ai guasti guasti di omissione (invocazione o risultato perso), crash (server) non riprova la trasmissione il cliente non sa il motivo e se la RMI o RPC è avvenuta Almeno una volta ritrasmissione esegue i possibili duplicati guasti di crash (server), guasti arbitrari idempotenza necessaria Al più una volta ritrasmissione senza riesecuzione Esempi: Java RMI at most once CORBA at most once o maybe SUN RPC at least once 16:15 SD.5.12